首页 / AI Coding的使用心得
#

AI Coding的使用心得

#
17669次浏览 189人互动
你在使用时,有没有遇到过那些意外的难题,或者是某些小技巧让你大大提高了效率?欢迎来聊聊你的心得,和牛友们一起来探索如何更高效地使用AI Coding>>
此刻你想和大家分享什么
热门 最新
前端开发中的AI–coding: 30%教我写代码,70%教我做人
随着ai ide工具的迅猛发展和在前端开发中的运用,网络上出现了很多吹捧ai技术的言论或者ai取代前端的论断。然而作为一个经验有限的小白,我的感受却和某些大佬们几乎截然不同,总觉得ai还是不够强,不够聪明,接下来聊一聊我的看法供参考,仅代表本人观点。实习和学习期间,cursor,Claude code,trae这些ide我都用过,我大体的结论是:对于常规业务需求,ai ide工具必须在以下几点条件下才能有较为良好的表现,但是对于企业级项目而言,前端开发本质上是企业的商业目标在技术上的实现,和任何一项工程实践一样,都面临着极其复杂的上下文环境,以及多主体的沟通协作,因此以下的要求都很难完全满足。第一,简单明确并且一次性的业务需求。显而易见,需求的复杂度在很大程度上决定了工程的复杂度,以及指令描述的清晰程度。就拿企业里面常见的支付下单链路来说,涉及十几种订单状态和流转步骤,理解业务的过程必须由开发者完成,ai仅仅是辅助。至于迭代次数大家懂得都懂,企业级项目迭代频率是非常快的。第二,低交互,短链路的界面和低性能的要求。c端业务对性能要求通常较高,即使是b端业务也会有较为复杂的交互链路。而这一点是前端开发特有的难度,毕竟前端构建的是UI界面,如果交互效果复杂(UI方面比如阴影渐变,淡入淡出,交互方面比如拖拽展开折叠等),则会非常难以用文字进行描述,对ai来讲也非常不友好。第三,有限的工作区边界和上下文规模这点前端相比后端更容易做到。后端开发常常涉及接口,数据库,中间件,路由等各种模块之间的复杂调用关系,而前端相对来讲更容易把UI组件拆的很细,进而约束工作区和上下文规模。但这项工作涉及组件拆分和数据管理和接口设计,也需要由前端开发者完成,而非完全交由ai工具。第四,命令式的指令和明确的技术规范所谓的命令式,指的是需要把开发步骤详细拆分,而非仅仅声明式地描述结果。举个例子,你不能只说“在这个组件实现登录和注册功能,”,那样的话写出的代码质量很低。你应该和他说 先实现静态约面,再添加交互,校验输入,最后提交结果,并且附上把每一步的效果。此外,请求库用哪个 请求函数是否封装 样式方案用哪个 需不需要拆分文件 开发中有哪些格式规范 函数变量命名怎么样 这些都是需要开发者去约定的。接下来举几个日常前端开发中的情景,这也是我为什么会得到以上的结论和感受。1.你刚进公司开发第一项需求,项目需要同时在web端和移动端运行,请问你如何解决手机端调试(让手机打开localhost),开发阶段跨域和登录状态共享(拿到其他域名的登录态)的问题?ai可能会给你一些常规的方法,什么webpack vite的proxy代理解决跨域,然后局域网监听,内网穿透让手机访问网址,修改host可以共享cookie等等,这些我也都不太懂。但其实公司里面大概率早已有成熟的解决方案,只需要访问一个共享的中间网站,让手机扫个码就能一站式解决所有问题,连proxy都不用配。所以你要做的是熟悉文档,判断问题和沟通提问的能力,以及一些超越前端范畴的网络知识。这些都是ai无法替你获取的信息。毕竟对ai来说,所有的问题都是你的问题,但对你来说并不是哈哈哈。2.假设你正在开发一个商品展示的详情页,现在拿到的是设计稿和prd,懒得一点点敲样式,打算把它甩给ai,直接告诉他在中让他直接生成静态代码。但很快你会碰到很多问题。首先是你要清楚你们项目样式方案要用哪一个,moduleCSS,CSS in JS还是原子化CSS,不说的话ai可能就直接把style塞到标签里了。其次是一些响应式问题,页面宽度不够时布局需不需要换一种展示方式,文字溢出怎么展示?页面宽度拉长的时候圆角比例不对了可以接受吗?页面上的icon怎么都不一样能不能统一复用?这些都需要和设计师一点点沟通甚至battle。第三是交互逻辑,用户体验以及一致的UI界面。滚动到底部有没有loading状态?滚动事件要不要节流函数?函数自己写还是用第三方库?用哪个版本?移动端支持度怎么样?商品的数据量有多少,需不需要虚拟列表?没数据的时候页面展示什么?高度是不是固定?此外,弹窗和loading 按钮是不是已经有通用的组件了,没有的话需不需要封装?需要封装到什么程度?需不需要发布npm包?这些都是由你和团队决定的,而不是完全交给ai,否则它可能用一大堆代码还原了一个你引入几行代码就能搞定的东西。AI不是不考虑这些问题,而是不符合你的预期,增加后续维护成本。有可能ai给你用antd写了一堆,但是明明你们部门之前有自己二次封装antd,也有可能它引入的包和你项目的某个框架不兼容。这要求你对部门技术有基本的了解甚至熟悉。3.进入联调阶段,你开始换账号测试,突然发现换到某一个账号后下单按钮疯狂点击没反应,开始排查。原因是这个用户在这个协议里受到了某些限制不能下单,后端数据库里拿不到数据,返回操作失败,前端也无法跳转下一步。理论上,登录之后如果他受到协议限制没权限,按钮应该隐藏,提示用户没权限。问题出现的原因,大家都应该背锅:产品: prd里面没写,逻辑和之前一样,因为默认大家都懂。没权限按钮肯定点不了啊设计: 照着prd画的,总不可能有按钮没按钮都画一遍前端: 你当时梳理业务的时候是给ai梳理的,ai打死也不知道你这按钮还会隐藏的,所以你没问产品,也没找后端加字段。后端: 只看prd,prd没写就没做。开发阶段前端也没说要加字段,就没加。现在你提出了解决方法,让后端加上一个字段hasRight,前端判断是否有权限,没有的话按钮隐藏掉。但是后端看了一下项目,发现这个字段的判断逻辑在另一个旧项目里面,所以让你去调用旧的接口拿字段。你求着后端说能不能聚合一下,后端说太麻烦不好做,而且不要重复开发,最好前端发个请求去拿就行了,所以为了一个新的字段前端要去另一个页面找请求是怎么发的。前端很委屈,但是也很无奈。新项目的页面用到老项目的接口,于是你打开线上页面,打开控制台翻请求看看参数怎么传的,发现那些参数完全没见过都根本看不懂啥意思。复制给ai它能帮你吗?恐怕不太行吧。无奈之下,你又只能去找这个项目的前端代码,在套了一层又一层的屎山里面翻来覆去,总算找到了那些请求参数的依赖逻辑,万幸的是这些参数都通过在新项目的现有数据推导计算出来,有些只是换了个名字。不过很快你又发现新的问题,这个老项目部署在a.com域名上,但是你现在开发的新项目部署在b.com上,即使你参数都准备好了,也会因为跨域拿不到数据。难道说还要在本地配置代理吗?甚至可能还要开发一个node中间层作为转发?开发阶段好说,测试和生产又怎么办?难道因为一个字段导致项目架构都要变动吗?要不还是找后端协调一下?怎么办呢? ai能帮你吗?你要是问题说不清楚,它真有可能给你本地整一个node转发层出来。。。4.提测阶段,第一天测试就拿了bug截图甩你脸上。你发现页面按钮全部挤一起,怎么回事呢?调试了半天才发现原来你习以为常的flex布局gap属性在某些安卓旧式机上不兼容。所以只能把项目里面手动把gap一个个换成margin–right和margin bottom。。。你好奇ai为什么没和你说?ai能知道就怪了。。。而且鬼知道你用什么机子测。测试的最后一天,产品突然说要加个埋点,问就是老板要,于是你只能拉回代码加埋点,本来想问ai,但是ai怎么可能知道你们部门埋点工具的逻辑呢?于是你只能去翻文档一点一点对照着写。最后看着卡着一动不动的cicd流水线感慨,为什么ai不能再聪明一点呢。以上场景都是我的亲身经历,实习几个月代码和技术没学多少,反倒是看到了不少甩锅和妥协。看到这你可能会理解,为什么我认为即使ai工具在我们日常开发中完成了大部分编码工作,它对我们的帮助程度仍然有限,大概占所有工作的30%-40%左右。我这还是个初级的实习生,对于更高级的程序员,这个比例只会大幅度降低。从最开始的业务理解,需求分析,到前期的架构设计,技术选型,旧项目的技术债务梳理,迭代成本评估,到具体的代码实现,安全性测试,bug调试,再到最后的生产上线,性能调优,前端开发涉及到产品需求提出到落地到后续迭代的全链路,在这中间很多事情是需要我们人去一点一点理解和实现的。很多时候我们面临的不仅仅是工作区的窗口那几个文件和几行代码,甚至都不是单纯的技术问题,是一个带有历史包袱和庞大上下文的复杂系统。所以我们要做的是打好地基,搭好框架,尽最大的可能缩减需求边界,明确限制条件,这样ai才能成为你得力的执行者,做好最后的搬砖工作,而不是一上来就让ai建造一整座房子。
点赞 评论 收藏
分享
Vibe Coding 使用心得
1.确定总体需求在开发前我们需要明确需求,知道我们要做什么,怎么做,得到什么交付件。2.需求描述这一步就是要求我们说清楚我们要做什么。最重要的就是我们需要列出我们的核心功能,例如基本的用户登录注册功能,也可以在一个用户的视角说明功能,通过说明用户可以进行什么操作说明。我们也可以说清楚我们所需要的性能要求,安全要求,并且我们需要适配什么平台。3.技术描述这一步如果你知道什么功能使用什么技术背景。正向使用技术:我们要求工具使用指定的技术进行开发,前端(Vue3/Vite/TS)、后端(Node.js/Express、Python/FastAPI)等等。反向技术:我们要求不要模型不要使用某些工具开发,例如数据库不是用原生SQL语句等等。4.交付件描述这一步就是我们需要得到的内容是什么,主要包括以下几个方面:项目的结构目录,Readme,单元测试,执行和部署步骤,API文档等内容。------------------以上我们可以得到一个基础的prompt内容:我需要开发一个法律隐私生成项目,该项目是前后端分离的。功能要求如下:要求有一个前端界面,该界面包含2个输入模式,问卷模式和自由输入模式,并且具备用户登录功能。后端界面对接dify后端workflow接口,完成法律隐私的生成。技术要求如下:前端使用react框架完成,后端使用python/FastAPI完成。交付件要求如下:交付物:项目的结构目录,Readme,单元测试,执行和部署步骤,API文档。额外步骤:1.首先让AI输出设计方案,然后再编码可以添加额外的提示词:请根据我提出的以上需求,首先输出以下内容:项目的目录结构,核心模块的交互逻辑,关键接口的定义,核心算法的逻辑等。这样的好处在于,我们可以适当调整他的项目架构和逻辑,是否合理是否考虑周全。2.分模块生成代码让AI根据模块生成代码:例如首先生成前端的自由写入模块的代码,再生成登录模块,随后生成和Dify的交互模块。每一次完成一个模块的生成,需要干2个事情。输出该模块的实现逻辑,避免维护困难。如何验证,生成测试用例,查看功能是否可验证。期间遇到问题或者不对的地方都可以让他修复,并且修改。纠错与修复当我们遇到报错的内容的时候,我们只需要讲完整的错误日志以及相关的出错的代码,以及是如果出错的操作步骤告诉AI,然后说明一下:请帮我排查问题并且修改代码即可。🤔 我在执行xxxxxx动作的报错:报错日志:xxxxxxx请帮我排查问题并修改代码。最好的办法就是没生成一次步骤就让他生成一次单元测试,并且手动检查一下接口的问题。增加维护性因为我们每一步都会让它生成一次功能的描述和项目的结构,因此我们对项目的整体的逻辑一定是有一个整体的把控的。因此我们需要让AI生成Readme文档,里面说明了项目的部署情况,API情况,以及每个模块的交互和内部实现逻辑等。如果后续有更新那个也可以使用一下提示词:现有法律隐私生成Agent已实现xxxxx功能,现在需要新增xxxxx功能:1.需求描述:xxxxxx2.技术描述:xxxx3.交付件描述:xxxxxx4.约束:请注意xxxxx请基于现有项目结构,生成响应的代码,解释内部逻辑,并且补充测试用例以及模块交互说明在对应文档中。总结:明确需求 → 设计方案 → 分模块生成(期间逐段验证)→ 调试优化 → 文档补全(可维护性)
点赞 评论 收藏
分享
最近使用 AICoding 的感受
累计投入了约40个小时,随着项目复杂度的上升,不得不提前终止“完全基于AI开发”,尝试做成了插件,小程序,正在做APP,接下来还是要返璞归真,开始补习代码基础知识。在整个AI开发过程中有如下发现:1.小白使用cursor的时候,需要规避跟cursor产生过多纠缠,及时使用coze充当中介,能解决小白不懂代码/cursor只懂执行命令的尴尬;cursor用的好的人,是最会用prompt提问的人,最会提问的人,往往是产品经理,而不是程序员2.上下文看似制约,其实不是制约的本质,因为真正的项目其复杂度是远超2万甚至200万Token上线的。所以当我从windsurf和cursor切换到cline,并拉满上下文后,确实短期解决了项目的瓶颈,推进了一大步,但终究无法应对越来越膨胀的代码。真正的制约是你能否有效管理项目中的各类概念,并并并有条地向AI分配任务。但如果你能做到,你就不是小白呀?3.Alcoding不仅仅需要描述清楚需求,更需要清楚代码逻辑。所以小白一般在刚开始最快乐,在中间能稍微解决,在后期逐渐崩溃。因为小白真的对各类概念一无所知。看起来是一个“为什么文字底部不能加色块”的问题,会衍生类、CSS、HTML渲染、JS执行等等一系列陌生的概念,技术的学习还是绕不开4.AI很擅长后端逻辑,因为他是清晰,明确的,我花在后端上的实际差不多仅占1/10。但AI不擅长UI、样式,因为这是和人的审美相关的。偏偏审美又是模糊的,很容易陷入甲方的五彩斑斓黑陷阱。5.最后是一些普世的使用建议:-有进展了,千万用Git随手保存-尽可能各个能力封装模块化-有较大更新后让他写进Readme中,后面可以拿这个给他看-一开始可以说复杂需求,后续尽可能一次描述一个小需求-邀请他追问细节-认真阅读他的每一步操作,不求看懂代码,至少看懂逻辑-可以让他在敲代码前先给出分析和逻辑说明,也可以让他在有更新后写入Readme,这些都可以放到预置的Prompt-提前思考好你的项目逻辑(我指技术实现部分),在外部文档上敲下来,而不是在打开Alcoding的那一刻才开始思考以上。
点赞 评论 收藏
分享
我觉得vibe coding的问题
作为程序员,我发现ai写代码总是会出一些bug我最近想到一个可能的原因:代码本质上不是“顺序的文本”,但 AI 模型是按照语言的逻辑在生成。先说语言。语言是天然的时序性信息:一个词接着一个词,说话的人一句一句说,听的人一句一句听。Transformer 这样的模型,就是把前面的词作为输入,再预测下一个词,然后继续往下推。这个逻辑完全符合语言的规律但代码不一样。编程语言里的很多东西,顺序其实没那么重要。比如在 C 里,你先定义结构体再引用,还是先引用再定义,只要编译器能找到,结果是一样的。代码更像一幅画,画家是一步步画出来的,但观众在看时看到的是完整的一张画。计算机存储图像时,也不会去记录画家的每一笔,而是一次性把每个像素的位置都保存下来。代码其实也差不多,虽然我们是逐行写,但真正运行时,它是作为一个整体被处理的。问题就出在这里。我们现在让 AI 用“写故事”的方式去“写程序”,它自然会经常出错。就算有些 Agent 会不断自我纠错,它折腾半天,还是没能改对,就会怀疑:是不是一开始把代码当成语言来处理,就是方向错了?也许未来的代码模型,不应该完全依赖时序展开,而是要找到一种新的结构?既能理解 token,又能直接理解代码的整体逻辑
点赞 评论 收藏
分享
02-02 18:11
门头沟学院 Java
AI coding工具怎么选?
点赞 评论 收藏
分享
我的ai-coding使用心得
首先需要明确上下文,这是 AI Coding 的 “地基”。AI 生成代码的准确性,完全依赖你提供的 “已知信息” 是否完整:明确技术栈上下文:不能只说 “写个接口”,要把核心技术栈、框架版本、编码规范一次性交代清楚。比如对 Java 开发来说,优质的上下文描述是:“基于 Spring Boot 3.2 + MyBatis-Plus 3.5,遵循阿里巴巴 Java 开发手册,写一个用户登录接口,要求用 JWT 做身份校验,密码采用 BCrypt 加密,返回结果统一封装成 {code:xxx, msg:xxx, data:xxx} 格式”—— 这些细节能避免 AI 生成 Spring Boot 2.x 的旧代码,或用 MD5 这种不安全的加密方式。补充业务上下文:AI 不懂你的业务场景,必须把核心规则说透。比如写 “订单状态更新接口”,要说明 “订单从‘待支付’到‘已支付’时,需同步扣减库存、生成支付记录,且库存不足时返回特定错误码(5001)”,而非只说 “写订单状态更新接口”;如果是迭代开发,还要补充 “该接口需兼容现有数据库表结构,表名 t_order,状态字段 status 枚举值为 WAIT_PAY/PAYED/CANCEL”,避免 AI 凭空设计表结构。限定场景上下文:比如明确 “该接口需支持 1000QPS 的并发,要做接口幂等性处理(基于订单号 + 用户 ID)”“前端是小程序,返回数据需做脱敏(手机号隐藏中间 4 位)”,这些场景细节能让 AI 生成的代码直接适配生产环境,而非仅满足 “能运行”。其次是prompt提示词。Prompt 提示词的设计技巧,这是让 AI “精准干活” 的关键,核心是 “结构化、指令化、分层化”:结构化 Prompt:用 “指令 + 要求 + 示例” 的格式新手常写模糊 Prompt:“帮我写个分页查询接口”;优质 Prompt 是:【指令】基于Spring Boot+MyBatis-Plus实现用户列表分页查询接口【技术要求】1. 请求参数:页码pageNum(默认1)、页大小pageSize(默认10)、用户昵称nickname(模糊查询)、用户状态status(精确查询)2. 分页插件使用MyBatis-Plus的PaginationInterceptor3. 返回结果包含:总条数total、当前页列表records、页码、页大小4. 异常处理:参数非法时抛自定义BusinessException,错误码1002【示例】请求URL:/api/user/page请求方式:GET请求示例:/api/user/page?pageNum=1&pageSize=10&nickname=张三&status=1返回示例:{"code":200,"msg":"成功","data":{"total":100,"records":[{"id":1,"nickname":"张三","status":1}],"pageNum":1,"pageSize":10}}结构化的 Prompt 能让 AI 聚焦核心要求,避免遗漏关键逻辑。
点赞 评论 收藏
分享
AI Coding 使用心得:从 “只会抄代码” 到 “真・效率倍增”用 AI Coding 也有一段时间了,从一开始图省事直接复制答案,到现在把它当成辅助工具 + 私人教练,感受真的挺不一样。尤其在刷题、写算法、赶项目、debug 这段时间,确实帮我省了很多力气,但也踩过不少坑。简单分享一下自己的心得和小技巧,欢迎大家一起交流。一、最明显的提升:效率真的快了很多语法 / 模板秒出像并查集、线段树、单调队列、DP 常见模型、快读快写、多测清空这些,手动写很容易漏细节、手滑写错。直接让 AI 给标准模板 + 注释,再按题目微调,比自己从头敲快太多,也减少低级 bug。Debug 效率翻倍有时候 WA 半天,肉眼看不出问题:边界没考虑、数组越界、变量没初始化、逻辑写反、精度问题……把代码 + 样例 + 错误信息贴给 AI,它通常能快速定位到行,甚至直接指出:这里应该是 <= 不是 <多组输入没清空数组递归爆栈 / 空间超限比自己干瞪眼看强太多。思路卡住时的 “破局点”完全没思路时,不直接要代码,而是让 AI:提示这题属于什么算法(贪心 / DP / 二分 / 图论)给一步一步的思考过程,而不是直接丢答案相当于有个随时在的 “思路引导员”,比干想一晚上有效。二、意外遇到的坑(真的很真实)AI 也会写假算法、假解法尤其是偏难的思维题、构造题、数据结构卡常题,AI 偶尔会给出:看起来很对、实际逻辑错误的代码复杂度不对,会 TLE 的 “假优化”变量名混乱、逻辑跳跃直接复制必 WA,必须自己看懂 + 手推样例 + 验证复杂度。过度依赖,会越来越不会独立思考一开始很爽:不会就问,秒出代码。但一段时间后发现:自己写代码变慢、思考变懒、面试手写容易慌。尤其是秋招面试,不可能带 AI,思路还是要刻在自己脑子里。细节不严谨,坑在小地方多组输入忘记 memset/clear数据范围没开 long long排序 comparator 写反、爆 intAI 有时也会犯这种低级错误,不能完全当 “标准答案” 信。三、我自己总结的高效使用技巧(亲测好用)先自己想 15–20 分钟,再求助 AI强制自己先写思路、画样例、写伪代码,实在卡壳再用 AI 看思路缺口,而不是一上来就要完整代码。提问要具体,别只丢一句 “帮我写这道题”效果更好的 prompt 示例:这题我的思路是 xxx,哪里有问题?帮我找这段代码的 bug,样例输入 xxx 输出应该是 xxx用 C++ 写,要求时间 O (n) / 空间 O (1),不要冗余写法帮我把代码改成更简洁、比赛风格的写法描述越清楚,AI 给的结果越精准。让 AI 做 “注释 + 讲解”,而不只是代码我现在固定会加一句:每一步加注释,讲清楚为什么这么写,时间 / 空间复杂度是多少。长期下来,相当于在被动学习,而不是单纯抄作业。用 AI 整理模板 & 错题笔记把一类题(比如区间 DP、数位 DP、最短路、拓扑排序)丢给 AI:帮我总结这类题的通用思路整理成可直接背的比赛模板刷题效率会高很多。拿来当 “模拟面试官”,练口述思路尤其备战面试时,可以让 AI:给我出一道同类型模拟题让我讲思路,它来点评、追问、挑错对面试表达提升很明显。四、总结:AI 是工具,不是替代品对我来说,AI Coding 更像:一个24 小时在线的助教:帮你 debug、补细节、理思路一个提速工具:减少重复劳动,把时间留给思考但它不能替代:自己手推样例、证明复杂度独立写代码、独立造数据卡自己真正理解算法本质用好的关键:不迷信、不依赖、会验证、会提问,把 AI 当成 “放大器”,而不是 “拐杖”。这段时间用下来,确实感觉 coding 速度、debug 速度、刷题量都上去了,但也时刻提醒自己:代码可以 AI 帮写,思路必须自己掌握。
点赞 评论 收藏
分享
玩命加载中
牛客网
牛客网在线编程
牛客网题解
牛客企业服务