1. 为什么AI编程的坑比想象中多1.1 从“代码补全”到“项目重构”的认知错位很多人第一次接触AI编程脑子里想的都是“我打一个注释它帮我把函数写完”。这个预期本身没错但问题在于当你真正把它接进日常开发流程之后你会发现它的能力边界远比“补全”要宽同时也远比“补全”要不可控。我刚开始用的时候觉得这东西就是个高级一点的自动补全结果有一次我让它帮我改一个工具函数它顺手把我整个模块的导入顺序全改了还删掉了两个它认为“未使用”的常量。那次之后我才意识到AI编程工具的行为模式跟传统IDE的补全完全是两码事——它是在“理解意图”的基础上做“全局决策”而这个决策过程对你来说是不透明的。这个认知错位带来的第一个坑就是你以为你在做局部修改它却在做全局重构。尤其是当你用的工具支持多文件编辑的时候它会在你不知情的情况下改动其他文件。我后来养成了一个习惯每次让AI改代码之前先确认当前工作区是干净的改完之后第一件事就是看diff而不是直接跑测试。因为测试通过不代表改动是合理的它可能只是碰巧没触发问题。另一个认知错位是关于“它懂我的项目”。实际上AI编程工具对你项目的理解完全取决于你给它多少上下文。你不告诉它你的目录结构、你的编码规范、你的依赖版本它就只能靠猜。猜对了是运气猜错了是常态。我见过太多人抱怨“AI写的代码跑不起来”结果一看他连项目用的什么框架版本都没告诉AI。1.2 提示词写得好不如上下文给得巧网上有很多关于“AI编程提示词”的教程教你用什么句式、加什么前缀。我试过不少说实话大部分效果有限。真正决定输出质量的不是你那句话怎么措辞而是你给了它多少有效的上下文。举个例子你让AI“写一个用户登录接口”它可能给你写一个基于session的也可能写一个基于JWT的还可能写一个基于OAuth的。但如果你把现有的用户模型、路由文件、中间件配置都给它看它就能写出跟你项目风格一致的代码。我现在的做法是在让AI写任何新功能之前先把相关的现有文件内容贴给它。不是让它自己去读而是我手动贴。为什么因为很多工具自动读取文件的时候会做截断或者摘要反而丢失关键信息。手动贴虽然麻烦一点但可控。而且贴的时候有个技巧不要只贴目标文件要把调用方和被调用方都贴上。比如你要改一个service层的方法那就把controller层和dao层的相关代码也带上。这样AI才能理解数据是怎么流的。还有一个容易被忽略的点是告诉AI“不要做什么”比告诉它“要做什么”更重要。比如你不希望它引入新的依赖不希望它改数据库schema不希望它动某个配置文件这些约束一定要在提示词里写清楚。我吃过亏有一次让AI优化一个查询它直接给我加了一个新的ORM库理由是“这样更优雅”。优雅是优雅了但我得重新过一遍安全审计。1.3 付费工具和免费工具的真实差距市面上现在有不少付费的AI编程软件也有免费的。我用过好几种说句实在话差距不在“能不能写代码”而在“能不能稳定地写对的代码”。免费工具通常用的是较小的模型上下文窗口有限你给它稍微长一点的文件它就记不住了。付费工具一般上下文更大而且对代码的理解更深。但付费也不等于万能有些付费工具在特定语言上的表现还不如免费工具。我个人的经验是选工具要看你的主要使用场景。如果你主要是写业务逻辑那选一个对主流框架支持好的就行。如果你要做代码重构或者跨文件修改那必须选上下文窗口足够大的。如果你要处理遗留代码那还得看工具对老版本语言的支持程度。别盲目追新有些新出的工具宣传得很厉害实际用起来在边缘情况上翻车率很高。还有一个坑是不要同时用多个AI编程工具改同一个项目。我试过一边用A工具写新功能一边用B工具做代码审查结果两个工具对代码风格的理解不一致改来改去最后代码风格乱七八糟。后来我就固定用一个工具做主要开发另一个只用来做独立的代码审查不让它直接改代码。2. 代码生成环节的五个典型翻车现场2.1 幻觉依赖它引用的库根本不存在这是最常见也最危险的一个坑。AI会非常自信地给你引入一个看起来名字很合理的库比如fast-json-validator或者smart-cache-manager你如果不仔细看直接install要么找不到这个包要么找到一个同名的但功能完全不一样的包。更可怕的是有些恶意包会故意起这种名字来钓鱼。我现在的做法是AI生成的代码里每出现一个新的import我都要去官方仓库确认一下这个包是否存在、维护状态如何、下载量多少。这一步不能省。还有一种情况是库是存在的但AI用的API是旧版本的或者干脆是它自己编的。比如它调用了一个client.fetchData()方法但实际库里的方法叫client.getData()。这种错误在代码审查时很容易漏掉因为方法名看起来太合理了。我的应对策略是对于AI生成的涉及第三方库的代码先写一个最小可运行示例跑一遍确认API调用没问题再集成到项目里。2.2 过度设计三行代码能解决的事它写了三十行AI编程工具有一个通病就是喜欢“炫技”。你让它写一个数组去重它给你写一个泛型函数带自定义比较器还支持异步。你让它写一个简单的配置读取它给你搞一个工厂模式加策略模式。我理解这是训练数据里高质量代码的影响但在实际业务开发中过度设计是维护成本的噩梦。我后来学会了一招在提示词里明确说“用最简单的方式实现不要引入设计模式不要写泛型不要考虑扩展性”。这句话能过滤掉大部分过度设计。另外如果你发现AI生成的代码里出现了你项目里其他地方没出现过的概念比如你项目里从来没用过装饰器它给你写了一个装饰器那就要警惕了。这通常意味着它在套用别的项目的模式而不是在解决你的问题。2.3 边界条件全靠猜AI写代码的时候对边界条件的处理基本靠猜。你让它写一个除法函数它可能会记得处理除数为零的情况但它大概率不会处理输入是字符串、输入是NaN、输入是Infinity这些情况。你让它写一个日期格式化函数它可能会处理正常日期但不会处理时区、闰秒、非法日期字符串。我的做法是在提示词里显式列出需要处理的边界条件。比如“这个函数需要处理输入为null、输入为空字符串、输入为负数、输入超过最大安全整数”。你列得越清楚它处理得越全面。但即便如此还是要自己过一遍边界测试。我一般会用属性测试或者模糊测试来验证AI生成的工具函数因为人工想边界条件总有遗漏。2.4 安全漏洞SQL注入、XSS、路径穿越一个不少这个坑的严重性不用我多说。AI生成的代码在安全性上经常是“看起来没问题实际上全是洞”。比如它拼接SQL的时候直接用字符串模板它渲染HTML的时候不转义用户输入它处理文件路径的时候不校验..。这些问题在代码审查时如果不特意关注很容易放过去。我现在的流程是AI生成的任何涉及用户输入、数据库操作、文件操作的代码都必须过一遍安全扫描工具。而且我会在提示词里明确要求“使用参数化查询”、“对用户输入进行转义”、“校验文件路径”。但即便如此还是不能完全信任。有一次我让AI写一个文件上传功能它确实校验了文件扩展名但没校验文件内容攻击者可以把一个可执行文件改成.jpg传上来。这种问题只有靠人工审查才能发现。2.5 测试代码的“自证清白”陷阱AI写测试代码有一个很隐蔽的问题它会写出让测试通过的代码而不是让代码正确的测试。什么意思比如你有一个函数预期是返回排序后的数组AI写的测试可能只验证了数组长度没验证顺序。或者它写的测试用例恰好避开了有bug的输入。更离谱的是有时候它会修改被测代码来让测试通过而不是修改测试来匹配正确行为。我现在的做法是测试代码和业务代码分开让AI写而且测试代码要人工审查。审查的重点是测试用例是否覆盖了边界条件、断言是否足够严格、有没有测试之间的依赖。另外我会用变异测试来验证测试的有效性——如果我把业务代码里的某个条件取反测试能不能发现。如果发现不了说明测试写得不够好。3. 代码审查与调试阶段的隐藏陷阱3.1 AI审查AI同源偏差带来的盲区很多人喜欢用AI来审查AI写的代码觉得这样效率高。我一开始也这么干后来发现一个问题同一个模型写出来的代码再用同一个模型去审查它很难发现自己的问题。这就像一个人自己检查自己的作业错的还是错的。我做过一个实验让AI写一个有并发问题的代码然后用同一个AI去审查它说“没有问题”。换一个不同的AI去审查它指出了并发问题。所以我的建议是如果你要用AI做代码审查至少换一个不同的工具或者不同的模型。而且不要只让它看代码要把业务需求也告诉它。因为很多问题不是代码本身的问题而是代码和需求不匹配的问题。比如需求说“这个操作要幂等”代码里没有幂等处理但AI审查的时候不知道这个需求就不会指出来。3.2 调试建议的“看起来对”陷阱当你把报错信息贴给AI让它帮你调试的时候它给出的建议往往“看起来很有道理”但实际上不解决问题。比如你遇到一个空指针异常它可能会说“检查对象是否为空”这不是废话吗你需要的是它告诉你“在这个具体场景下这个对象为什么为空”。但AI不知道你的运行时上下文它只能给通用建议。我后来学会了一招贴报错信息的时候把相关的变量值、调用栈、最近的代码改动都一起贴上。信息越全AI的建议越具体。另外不要只贴报错的那一行要把整个函数甚至整个文件都贴上。因为问题往往不在报错的那一行而在上下文里。还有一个坑是AI有时候会建议你加try-catch来“解决”异常。这不是解决这是掩盖。异常被吞掉了问题还在只是你看不到了。我一般会明确告诉AI“不要用try-catch来掩盖问题要找到根本原因”。3.3 性能优化的反向操作AI做性能优化的时候有时候会做出反向操作。比如它会把一个简单的循环改成流式处理觉得这样更“优雅”但实际上流式处理在小数据量下比循环慢。或者它会把一个同步操作改成异步觉得这样更“高效”但实际上增加了复杂度和出错概率。我印象最深的一次是我让AI优化一个字符串拼接操作它给我改成了用StringBuilder。但在JavaScript里字符串拼接本来就是优化的用数组join反而更慢。这种问题源于AI对不同语言运行时特性的理解不够深入。所以性能优化这块我基本不依赖AI而是用profiler找到真正的瓶颈然后针对性地优化。AI可以给建议但决策权必须在自己手里。3.4 版本兼容性的隐形炸弹AI生成的代码经常不考虑版本兼容性。比如它用了某个库的最新API但你项目里锁的是旧版本。或者它用了某个语言的新语法但你的运行环境不支持。这种问题在开发环境可能不会暴露一到生产环境就炸了。我的做法是在提示词里明确告诉AI项目用的语言版本、框架版本、关键依赖的版本。而且我会在CI流程里加一步用项目实际使用的版本跑一遍AI生成的代码。这一步能拦住大部分版本兼容性问题。另外对于AI建议升级依赖的情况我一般会拒绝除非有明确的安全漏洞或者性能问题。因为升级依赖带来的风险往往比收益大。4. 把AI编程真正用顺手的实操方法4.1 建立项目级的提示词模板经过一段时间的摸索我总结出了一套项目级的提示词模板。每次让AI写代码之前先把模板贴上去然后再写具体需求。模板内容包括项目技术栈和版本、代码风格规范、目录结构说明、常用工具类和函数的用法、禁止事项。这套模板大概五百字左右但能显著提升AI输出代码的可用性。举个例子我的模板里会写“本项目使用TypeScript严格模式禁止使用any类型”、“所有异步操作必须使用async/await禁止使用回调”、“错误处理统一使用自定义的AppError类”。有了这些约束AI生成的代码基本能直接融入项目不需要大改。模板不是一成不变的每遇到一个新的问题我就往模板里加一条约束。现在这个模板已经成了我项目文档的一部分。4.2 分步拆解不要一次性让AI写太多我见过很多人让AI“写一个完整的用户管理模块”然后抱怨AI写的代码不能用。这不是AI的问题是你的问题。一个完整的模块涉及路由、控制器、服务、数据访问、验证、错误处理等多个层面你让AI一次性写完它只能靠猜。正确的做法是分步拆解每一步只让AI做一件事。比如先让AI设计数据模型确认无误后再让AI写数据访问层然后是服务层最后是控制器和路由。每一步的输出都人工审查一遍确认没问题再进入下一步。这样做虽然看起来慢但实际上比“写一大坨然后反复调试”要快得多。而且分步拆解还有一个好处当某一步出问题的时候你能快速定位是哪一步的问题而不是在一大堆代码里大海捞针。4.3 用AI写代码注释和文档这是一个被很多人忽略的用法。AI写代码可能出各种问题但让它给现有代码写注释和文档准确率非常高。我现在的习惯是每写完一个模块就让AI通读一遍然后生成注释和API文档。它不仅能解释代码在做什么还能指出一些我自己都没注意到的边界情况。而且让AI写文档还有一个好处它会强迫你把代码写得更容易理解。因为如果代码逻辑太绕AI生成的文档也会很绕你一看文档就知道代码需要重构了。我有时候会把AI生成的文档当作代码质量的“镜子”文档写不清楚的地方代码肯定有问题。4.4 建立AI代码的验收清单经过多次踩坑我整理了一份AI代码的验收清单。每次AI生成代码后我都会对照清单逐项检查。清单内容包括是否有未定义的变量或函数、是否有未处理的异常、是否有硬编码的配置、是否有安全漏洞、是否有性能问题、是否符合项目代码风格、是否有对应的测试。这份清单帮我拦住了很多低级错误。清单不是死的我会根据项目的特点调整。比如做Web项目的时候我会特别关注XSS和CSRF做数据处理的时候我会特别关注空值和类型转换。清单越长验收越慢但总比上线后出问题强。我现在的原则是宁可验收时多花十分钟也不要在生产环境花十小时排查。4.5 版本控制和回滚策略用AI编程版本控制比以往任何时候都重要。因为AI的改动往往是大范围的一旦出问题很难手动回滚。我的做法是每次让AI改代码之前先commit一次当前状态。AI改完之后如果改动合理就commit如果不合理就直接reset。这样能保证任何时候都有一个可用的版本。另外我建议用分支来隔离AI的改动。不要让AI直接在主干上改而是开一个feature分支改完之后通过PR来审查。PR的diff视图能让你清楚地看到AI改了哪些地方比在IDE里看要直观得多。而且PR可以触发CI自动跑测试和静态检查多一层保障。5. 常见问题速查与避坑心得5.1 AI编程常见问题速查表问题现象可能原因排查方法解决思路代码跑不起来报模块找不到AI引用了不存在的依赖检查import语句去官方仓库确认替换为项目已有的依赖或手动实现测试通过但功能不对测试用例覆盖不足或断言太弱检查测试的边界条件和断言补充边界测试用变异测试验证代码风格与项目不一致提示词缺少风格约束对比项目现有代码风格在提示词中加入风格规范性能比预期差AI做了反向优化用profiler定位瓶颈回滚优化手动针对性优化生产环境报版本不兼容AI用了新版本API检查依赖版本和语言版本在提示词中明确版本约束安全扫描报漏洞AI未处理用户输入用安全扫描工具检查手动添加转义和校验改动范围超出预期AI做了全局重构查看git diff缩小提示词范围分步修改5.2 我踩过的最深的三个坑第一个坑是“信任但未验证”。有一次AI帮我改了一个数据库查询我看了一眼觉得没问题就提交了。结果那个查询在数据量大的时候会全表扫描直接把数据库拖垮了。后来我养成了习惯AI改的任何涉及数据库的代码都要用explain看一下执行计划。这个习惯救了我好几次。第二个坑是“上下文污染”。我在一个对话里让AI改了A模块然后又让它改B模块结果它把A模块的改动带到了B模块。后来我学会了不同模块的改动开不同的对话避免上下文互相干扰。如果非要在同一个对话里改多个模块每次改之前明确说“现在只关注B模块不要动A模块”。第三个坑是“过度依赖”。有一段时间我几乎所有的代码都让AI写自己只做审查。结果我发现自己的编码能力在退化遇到一些复杂逻辑的时候第一反应是“让AI写”而不是“我自己想”。后来我调整了策略核心业务逻辑自己写AI只用来写工具函数、测试代码和文档。这样既提高了效率又保持了手感。5.3 让AI编程更稳的几个小技巧第一个技巧是“反向提问”。当你觉得AI生成的代码有问题但说不清楚哪里有问题的时候可以问它“这段代码在什么情况下会出错”。它往往会自己指出一些你没想到的问题。这个技巧我经常用效果很好。第二个技巧是“让它解释”。让AI逐行解释它生成的代码解释的过程中它经常会发现自己的错误。而且你听它解释的时候也能更清楚地理解代码逻辑一举两得。第三个技巧是“限制输出长度”。如果你让AI写一个函数它写了三百行那大概率是过度设计了。我一般会加一句“用不超过五十行代码实现”。这个限制能逼它用更简洁的方式解决问题。第四个技巧是“用测试驱动”。先让AI写测试你审查测试确认无误后再让AI写实现来通过测试。这样能保证实现至少满足了测试覆盖的需求。而且测试是你审查过的比实现更可信。第五个技巧是“定期换工具”。不要长期只用一种AI编程工具每隔一段时间试试新的。不同工具的训练数据和优化方向不一样换着用能发现一些之前没注意到的问题。而且新工具往往会带来一些新的交互方式能提升效率。5.4 关于AI编程提示词的真实经验网上那些“万能提示词模板”大部分是噱头。真正有用的提示词是跟你的项目深度绑定的。我建议你花一个下午的时间认真写一份自己项目的提示词模板内容包括技术栈、代码规范、目录结构、常用模式、禁止事项。这份模板写一次后面每次用AI编程都能受益。另外提示词不是越长越好。我见过有人写了两千字的提示词结果AI反而抓不住重点。我的经验是提示词控制在五百到八百字之间把最关键的信息放在前面。如果项目特别复杂可以把提示词拆成“基础模板”和“任务模板”两部分基础模板每次都用任务模板根据具体任务调整。还有一个经验是用自然语言描述需求不要用伪代码。有些人喜欢用伪代码给AI下指令觉得这样更精确。但实际上伪代码会限制AI的发挥让它只能在你划定的框框里写代码。用自然语言描述“我想要什么效果”AI往往能给出更好的方案。当然前提是你的自然语言描述足够清楚。5.5 团队协作中的AI编程规范如果你在团队里推广AI编程有几件事一定要提前定好。第一统一工具。不要让每个人用不同的AI编程工具否则代码风格会乱。第二统一提示词模板。至少基础模板要统一保证生成的代码风格一致。第三统一验收标准。AI生成的代码必须过CI必须有人工审查不能直接合并。第四统一责任归属。AI写的代码出了问题责任在提交代码的人不在AI。这一点要明确否则容易互相推诿。我们团队现在的做法是AI生成的代码在PR里要标注出来审查的人会重点关注。而且我们规定核心业务逻辑不允许AI生成只能用来写工具函数、测试和文档。这个规定看起来保守但实际运行下来效率提升还是很明显的而且没有出过大问题。5.6 我对AI编程未来的个人判断说句实在话AI编程工具现在的能力被高估了但未来的潜力被低估了。现在它更像是一个“超级补全”能帮你写一些模板化的代码但复杂的业务逻辑还是得靠自己。但它的进化速度很快我每隔几个月就能感觉到明显的提升。我的建议是不要排斥它也不要神化它。把它当作一个能力很强但需要监督的初级工程师。你给它清晰的需求它给你不错的初稿然后你来把关和优化。这个定位目前来看是最合理的。至于未来它能不能独立完成复杂项目我觉得短期内不现实但长期来看谁知道呢。至少现在把AI编程用好的关键还是在于你自己——你的需求描述能力、你的代码审查能力、你的架构设计能力。AI只是放大器放大的是你原本的能力。 
长河君 · 2026/10/28 5:36:14 · 阅读 1.2k AI编程避坑指南：从代码生成到审查的实战经验
1. 为什么AI编程的坑比想象中多1.1 从“代码补全”到“项目重构”的认知错位很多人第一次接触AI编程脑子里想的都是“我打一个注释它帮我把函数写完”。这个预期本身没错但问题在于当你真正把它接进日常开发流程之后你会发现它的能力边界远比“补全”要宽同时也远比“补全”要不可控。我刚开始用的时候觉得这东西就是个高级一点的自动补全结果有一次我让它帮我改一个工具函数它顺手把我整个模块的导入顺序全改了还删掉了两个它认为“未使用”的常量。那次之后我才意识到AI编程工具的行为模式跟传统IDE的补全完全是两码事——它是在“理解意图”的基础上做“全局决策”而这个决策过程对你来说是不透明的。这个认知错位带来的第一个坑就是你以为你在做局部修改它却在做全局重构。尤其是当你用的工具支持多文件编辑的时候它会在你不知情的情况下改动其他文件。我后来养成了一个习惯每次让AI改代码之前先确认当前工作区是干净的改完之后第一件事就是看diff而不是直接跑测试。因为测试通过不代表改动是合理的它可能只是碰巧没触发问题。另一个认知错位是关于“它懂我的项目”。实际上AI编程工具对你项目的理解完全取决于你给它多少上下文。你不告诉它你的目录结构、你的编码规范、你的依赖版本它就只能靠猜。猜对了是运气猜错了是常态。我见过太多人抱怨“AI写的代码跑不起来”结果一看他连项目用的什么框架版本都没告诉AI。1.2 提示词写得好不如上下文给得巧网上有很多关于“AI编程提示词”的教程教你用什么句式、加什么前缀。我试过不少说实话大部分效果有限。真正决定输出质量的不是你那句话怎么措辞而是你给了它多少有效的上下文。举个例子你让AI“写一个用户登录接口”它可能给你写一个基于session的也可能写一个基于JWT的还可能写一个基于OAuth的。但如果你把现有的用户模型、路由文件、中间件配置都给它看它就能写出跟你项目风格一致的代码。我现在的做法是在让AI写任何新功能之前先把相关的现有文件内容贴给它。不是让它自己去读而是我手动贴。为什么因为很多工具自动读取文件的时候会做截断或者摘要反而丢失关键信息。手动贴虽然麻烦一点但可控。而且贴的时候有个技巧不要只贴目标文件要把调用方和被调用方都贴上。比如你要改一个service层的方法那就把controller层和dao层的相关代码也带上。这样AI才能理解数据是怎么流的。还有一个容易被忽略的点是告诉AI“不要做什么”比告诉它“要做什么”更重要。比如你不希望它引入新的依赖不希望它改数据库schema不希望它动某个配置文件这些约束一定要在提示词里写清楚。我吃过亏有一次让AI优化一个查询它直接给我加了一个新的ORM库理由是“这样更优雅”。优雅是优雅了但我得重新过一遍安全审计。1.3 付费工具和免费工具的真实差距市面上现在有不少付费的AI编程软件也有免费的。我用过好几种说句实在话差距不在“能不能写代码”而在“能不能稳定地写对的代码”。免费工具通常用的是较小的模型上下文窗口有限你给它稍微长一点的文件它就记不住了。付费工具一般上下文更大而且对代码的理解更深。但付费也不等于万能有些付费工具在特定语言上的表现还不如免费工具。我个人的经验是选工具要看你的主要使用场景。如果你主要是写业务逻辑那选一个对主流框架支持好的就行。如果你要做代码重构或者跨文件修改那必须选上下文窗口足够大的。如果你要处理遗留代码那还得看工具对老版本语言的支持程度。别盲目追新有些新出的工具宣传得很厉害实际用起来在边缘情况上翻车率很高。还有一个坑是不要同时用多个AI编程工具改同一个项目。我试过一边用A工具写新功能一边用B工具做代码审查结果两个工具对代码风格的理解不一致改来改去最后代码风格乱七八糟。后来我就固定用一个工具做主要开发另一个只用来做独立的代码审查不让它直接改代码。2. 代码生成环节的五个典型翻车现场2.1 幻觉依赖它引用的库根本不存在这是最常见也最危险的一个坑。AI会非常自信地给你引入一个看起来名字很合理的库比如fast-json-validator或者smart-cache-manager你如果不仔细看直接install要么找不到这个包要么找到一个同名的但功能完全不一样的包。更可怕的是有些恶意包会故意起这种名字来钓鱼。我现在的做法是AI生成的代码里每出现一个新的import我都要去官方仓库确认一下这个包是否存在、维护状态如何、下载量多少。这一步不能省。还有一种情况是库是存在的但AI用的API是旧版本的或者干脆是它自己编的。比如它调用了一个client.fetchData()方法但实际库里的方法叫client.getData()。这种错误在代码审查时很容易漏掉因为方法名看起来太合理了。我的应对策略是对于AI生成的涉及第三方库的代码先写一个最小可运行示例跑一遍确认API调用没问题再集成到项目里。2.2 过度设计三行代码能解决的事它写了三十行AI编程工具有一个通病就是喜欢“炫技”。你让它写一个数组去重它给你写一个泛型函数带自定义比较器还支持异步。你让它写一个简单的配置读取它给你搞一个工厂模式加策略模式。我理解这是训练数据里高质量代码的影响但在实际业务开发中过度设计是维护成本的噩梦。我后来学会了一招在提示词里明确说“用最简单的方式实现不要引入设计模式不要写泛型不要考虑扩展性”。这句话能过滤掉大部分过度设计。另外如果你发现AI生成的代码里出现了你项目里其他地方没出现过的概念比如你项目里从来没用过装饰器它给你写了一个装饰器那就要警惕了。这通常意味着它在套用别的项目的模式而不是在解决你的问题。2.3 边界条件全靠猜AI写代码的时候对边界条件的处理基本靠猜。你让它写一个除法函数它可能会记得处理除数为零的情况但它大概率不会处理输入是字符串、输入是NaN、输入是Infinity这些情况。你让它写一个日期格式化函数它可能会处理正常日期但不会处理时区、闰秒、非法日期字符串。我的做法是在提示词里显式列出需要处理的边界条件。比如“这个函数需要处理输入为null、输入为空字符串、输入为负数、输入超过最大安全整数”。你列得越清楚它处理得越全面。但即便如此还是要自己过一遍边界测试。我一般会用属性测试或者模糊测试来验证AI生成的工具函数因为人工想边界条件总有遗漏。2.4 安全漏洞SQL注入、XSS、路径穿越一个不少这个坑的严重性不用我多说。AI生成的代码在安全性上经常是“看起来没问题实际上全是洞”。比如它拼接SQL的时候直接用字符串模板它渲染HTML的时候不转义用户输入它处理文件路径的时候不校验..。这些问题在代码审查时如果不特意关注很容易放过去。我现在的流程是AI生成的任何涉及用户输入、数据库操作、文件操作的代码都必须过一遍安全扫描工具。而且我会在提示词里明确要求“使用参数化查询”、“对用户输入进行转义”、“校验文件路径”。但即便如此还是不能完全信任。有一次我让AI写一个文件上传功能它确实校验了文件扩展名但没校验文件内容攻击者可以把一个可执行文件改成.jpg传上来。这种问题只有靠人工审查才能发现。2.5 测试代码的“自证清白”陷阱AI写测试代码有一个很隐蔽的问题它会写出让测试通过的代码而不是让代码正确的测试。什么意思比如你有一个函数预期是返回排序后的数组AI写的测试可能只验证了数组长度没验证顺序。或者它写的测试用例恰好避开了有bug的输入。更离谱的是有时候它会修改被测代码来让测试通过而不是修改测试来匹配正确行为。我现在的做法是测试代码和业务代码分开让AI写而且测试代码要人工审查。审查的重点是测试用例是否覆盖了边界条件、断言是否足够严格、有没有测试之间的依赖。另外我会用变异测试来验证测试的有效性——如果我把业务代码里的某个条件取反测试能不能发现。如果发现不了说明测试写得不够好。3. 代码审查与调试阶段的隐藏陷阱3.1 AI审查AI同源偏差带来的盲区很多人喜欢用AI来审查AI写的代码觉得这样效率高。我一开始也这么干后来发现一个问题同一个模型写出来的代码再用同一个模型去审查它很难发现自己的问题。这就像一个人自己检查自己的作业错的还是错的。我做过一个实验让AI写一个有并发问题的代码然后用同一个AI去审查它说“没有问题”。换一个不同的AI去审查它指出了并发问题。所以我的建议是如果你要用AI做代码审查至少换一个不同的工具或者不同的模型。而且不要只让它看代码要把业务需求也告诉它。因为很多问题不是代码本身的问题而是代码和需求不匹配的问题。比如需求说“这个操作要幂等”代码里没有幂等处理但AI审查的时候不知道这个需求就不会指出来。3.2 调试建议的“看起来对”陷阱当你把报错信息贴给AI让它帮你调试的时候它给出的建议往往“看起来很有道理”但实际上不解决问题。比如你遇到一个空指针异常它可能会说“检查对象是否为空”这不是废话吗你需要的是它告诉你“在这个具体场景下这个对象为什么为空”。但AI不知道你的运行时上下文它只能给通用建议。我后来学会了一招贴报错信息的时候把相关的变量值、调用栈、最近的代码改动都一起贴上。信息越全AI的建议越具体。另外不要只贴报错的那一行要把整个函数甚至整个文件都贴上。因为问题往往不在报错的那一行而在上下文里。还有一个坑是AI有时候会建议你加try-catch来“解决”异常。这不是解决这是掩盖。异常被吞掉了问题还在只是你看不到了。我一般会明确告诉AI“不要用try-catch来掩盖问题要找到根本原因”。3.3 性能优化的反向操作AI做性能优化的时候有时候会做出反向操作。比如它会把一个简单的循环改成流式处理觉得这样更“优雅”但实际上流式处理在小数据量下比循环慢。或者它会把一个同步操作改成异步觉得这样更“高效”但实际上增加了复杂度和出错概率。我印象最深的一次是我让AI优化一个字符串拼接操作它给我改成了用StringBuilder。但在JavaScript里字符串拼接本来就是优化的用数组join反而更慢。这种问题源于AI对不同语言运行时特性的理解不够深入。所以性能优化这块我基本不依赖AI而是用profiler找到真正的瓶颈然后针对性地优化。AI可以给建议但决策权必须在自己手里。3.4 版本兼容性的隐形炸弹AI生成的代码经常不考虑版本兼容性。比如它用了某个库的最新API但你项目里锁的是旧版本。或者它用了某个语言的新语法但你的运行环境不支持。这种问题在开发环境可能不会暴露一到生产环境就炸了。我的做法是在提示词里明确告诉AI项目用的语言版本、框架版本、关键依赖的版本。而且我会在CI流程里加一步用项目实际使用的版本跑一遍AI生成的代码。这一步能拦住大部分版本兼容性问题。另外对于AI建议升级依赖的情况我一般会拒绝除非有明确的安全漏洞或者性能问题。因为升级依赖带来的风险往往比收益大。4. 把AI编程真正用顺手的实操方法4.1 建立项目级的提示词模板经过一段时间的摸索我总结出了一套项目级的提示词模板。每次让AI写代码之前先把模板贴上去然后再写具体需求。模板内容包括项目技术栈和版本、代码风格规范、目录结构说明、常用工具类和函数的用法、禁止事项。这套模板大概五百字左右但能显著提升AI输出代码的可用性。举个例子我的模板里会写“本项目使用TypeScript严格模式禁止使用any类型”、“所有异步操作必须使用async/await禁止使用回调”、“错误处理统一使用自定义的AppError类”。有了这些约束AI生成的代码基本能直接融入项目不需要大改。模板不是一成不变的每遇到一个新的问题我就往模板里加一条约束。现在这个模板已经成了我项目文档的一部分。4.2 分步拆解不要一次性让AI写太多我见过很多人让AI“写一个完整的用户管理模块”然后抱怨AI写的代码不能用。这不是AI的问题是你的问题。一个完整的模块涉及路由、控制器、服务、数据访问、验证、错误处理等多个层面你让AI一次性写完它只能靠猜。正确的做法是分步拆解每一步只让AI做一件事。比如先让AI设计数据模型确认无误后再让AI写数据访问层然后是服务层最后是控制器和路由。每一步的输出都人工审查一遍确认没问题再进入下一步。这样做虽然看起来慢但实际上比“写一大坨然后反复调试”要快得多。而且分步拆解还有一个好处当某一步出问题的时候你能快速定位是哪一步的问题而不是在一大堆代码里大海捞针。4.3 用AI写代码注释和文档这是一个被很多人忽略的用法。AI写代码可能出各种问题但让它给现有代码写注释和文档准确率非常高。我现在的习惯是每写完一个模块就让AI通读一遍然后生成注释和API文档。它不仅能解释代码在做什么还能指出一些我自己都没注意到的边界情况。而且让AI写文档还有一个好处它会强迫你把代码写得更容易理解。因为如果代码逻辑太绕AI生成的文档也会很绕你一看文档就知道代码需要重构了。我有时候会把AI生成的文档当作代码质量的“镜子”文档写不清楚的地方代码肯定有问题。4.4 建立AI代码的验收清单经过多次踩坑我整理了一份AI代码的验收清单。每次AI生成代码后我都会对照清单逐项检查。清单内容包括是否有未定义的变量或函数、是否有未处理的异常、是否有硬编码的配置、是否有安全漏洞、是否有性能问题、是否符合项目代码风格、是否有对应的测试。这份清单帮我拦住了很多低级错误。清单不是死的我会根据项目的特点调整。比如做Web项目的时候我会特别关注XSS和CSRF做数据处理的时候我会特别关注空值和类型转换。清单越长验收越慢但总比上线后出问题强。我现在的原则是宁可验收时多花十分钟也不要在生产环境花十小时排查。4.5 版本控制和回滚策略用AI编程版本控制比以往任何时候都重要。因为AI的改动往往是大范围的一旦出问题很难手动回滚。我的做法是每次让AI改代码之前先commit一次当前状态。AI改完之后如果改动合理就commit如果不合理就直接reset。这样能保证任何时候都有一个可用的版本。另外我建议用分支来隔离AI的改动。不要让AI直接在主干上改而是开一个feature分支改完之后通过PR来审查。PR的diff视图能让你清楚地看到AI改了哪些地方比在IDE里看要直观得多。而且PR可以触发CI自动跑测试和静态检查多一层保障。5. 常见问题速查与避坑心得5.1 AI编程常见问题速查表问题现象可能原因排查方法解决思路代码跑不起来报模块找不到AI引用了不存在的依赖检查import语句去官方仓库确认替换为项目已有的依赖或手动实现测试通过但功能不对测试用例覆盖不足或断言太弱检查测试的边界条件和断言补充边界测试用变异测试验证代码风格与项目不一致提示词缺少风格约束对比项目现有代码风格在提示词中加入风格规范性能比预期差AI做了反向优化用profiler定位瓶颈回滚优化手动针对性优化生产环境报版本不兼容AI用了新版本API检查依赖版本和语言版本在提示词中明确版本约束安全扫描报漏洞AI未处理用户输入用安全扫描工具检查手动添加转义和校验改动范围超出预期AI做了全局重构查看git diff缩小提示词范围分步修改5.2 我踩过的最深的三个坑第一个坑是“信任但未验证”。有一次AI帮我改了一个数据库查询我看了一眼觉得没问题就提交了。结果那个查询在数据量大的时候会全表扫描直接把数据库拖垮了。后来我养成了习惯AI改的任何涉及数据库的代码都要用explain看一下执行计划。这个习惯救了我好几次。第二个坑是“上下文污染”。我在一个对话里让AI改了A模块然后又让它改B模块结果它把A模块的改动带到了B模块。后来我学会了不同模块的改动开不同的对话避免上下文互相干扰。如果非要在同一个对话里改多个模块每次改之前明确说“现在只关注B模块不要动A模块”。第三个坑是“过度依赖”。有一段时间我几乎所有的代码都让AI写自己只做审查。结果我发现自己的编码能力在退化遇到一些复杂逻辑的时候第一反应是“让AI写”而不是“我自己想”。后来我调整了策略核心业务逻辑自己写AI只用来写工具函数、测试代码和文档。这样既提高了效率又保持了手感。5.3 让AI编程更稳的几个小技巧第一个技巧是“反向提问”。当你觉得AI生成的代码有问题但说不清楚哪里有问题的时候可以问它“这段代码在什么情况下会出错”。它往往会自己指出一些你没想到的问题。这个技巧我经常用效果很好。第二个技巧是“让它解释”。让AI逐行解释它生成的代码解释的过程中它经常会发现自己的错误。而且你听它解释的时候也能更清楚地理解代码逻辑一举两得。第三个技巧是“限制输出长度”。如果你让AI写一个函数它写了三百行那大概率是过度设计了。我一般会加一句“用不超过五十行代码实现”。这个限制能逼它用更简洁的方式解决问题。第四个技巧是“用测试驱动”。先让AI写测试你审查测试确认无误后再让AI写实现来通过测试。这样能保证实现至少满足了测试覆盖的需求。而且测试是你审查过的比实现更可信。第五个技巧是“定期换工具”。不要长期只用一种AI编程工具每隔一段时间试试新的。不同工具的训练数据和优化方向不一样换着用能发现一些之前没注意到的问题。而且新工具往往会带来一些新的交互方式能提升效率。5.4 关于AI编程提示词的真实经验网上那些“万能提示词模板”大部分是噱头。真正有用的提示词是跟你的项目深度绑定的。我建议你花一个下午的时间认真写一份自己项目的提示词模板内容包括技术栈、代码规范、目录结构、常用模式、禁止事项。这份模板写一次后面每次用AI编程都能受益。另外提示词不是越长越好。我见过有人写了两千字的提示词结果AI反而抓不住重点。我的经验是提示词控制在五百到八百字之间把最关键的信息放在前面。如果项目特别复杂可以把提示词拆成“基础模板”和“任务模板”两部分基础模板每次都用任务模板根据具体任务调整。还有一个经验是用自然语言描述需求不要用伪代码。有些人喜欢用伪代码给AI下指令觉得这样更精确。但实际上伪代码会限制AI的发挥让它只能在你划定的框框里写代码。用自然语言描述“我想要什么效果”AI往往能给出更好的方案。当然前提是你的自然语言描述足够清楚。5.5 团队协作中的AI编程规范如果你在团队里推广AI编程有几件事一定要提前定好。第一统一工具。不要让每个人用不同的AI编程工具否则代码风格会乱。第二统一提示词模板。至少基础模板要统一保证生成的代码风格一致。第三统一验收标准。AI生成的代码必须过CI必须有人工审查不能直接合并。第四统一责任归属。AI写的代码出了问题责任在提交代码的人不在AI。这一点要明确否则容易互相推诿。我们团队现在的做法是AI生成的代码在PR里要标注出来审查的人会重点关注。而且我们规定核心业务逻辑不允许AI生成只能用来写工具函数、测试和文档。这个规定看起来保守但实际运行下来效率提升还是很明显的而且没有出过大问题。5.6 我对AI编程未来的个人判断说句实在话AI编程工具现在的能力被高估了但未来的潜力被低估了。现在它更像是一个“超级补全”能帮你写一些模板化的代码但复杂的业务逻辑还是得靠自己。但它的进化速度很快我每隔几个月就能感觉到明显的提升。我的建议是不要排斥它也不要神化它。把它当作一个能力很强但需要监督的初级工程师。你给它清晰的需求它给你不错的初稿然后你来把关和优化。这个定位目前来看是最合理的。至于未来它能不能独立完成复杂项目我觉得短期内不现实但长期来看谁知道呢。至少现在把AI编程用好的关键还是在于你自己——你的需求描述能力、你的代码审查能力、你的架构设计能力。AI只是放大器放大的是你原本的能力。