AI代码生成最佳实践
遵循经过验证的最佳实践，利用AI助手更快地编写更好的代码。
提供上下文，而不只是指令
最常见的失败模式是：不展示已有的代码就直接索要代码。看不到你的技术栈、规范和现有模式的模型，只会生成与你的架构相互冲突的通用代码。
对比同一任务的两条提示词。改进前：写一个处理退款的函数。这样得到的是看似合理但泛泛而谈的代码，错误处理和类型都是凭空捏造的。改进后：为我们的Express API写一个TypeScript函数，通过我们的PaymentGateway封装层处理退款。遵循下面refundService.ts的结构，失败时通过我们的AppError类抛出，并用我粘贴的Zod schema验证输入。第二条提示词配合实际附上的参考文件，产出的代码只需极少改动就能融入你的代码库。
让这件事变得省力的实用习惯：
- 每次请求新模块时，粘贴一个有代表性的现有文件，让模型照着模仿命名和结构。 - 明确说明技术栈和版本——框架、数据库、运行时——因为默认行为在不同版本间会有差异。 - 错误处理和日志规范每个会话提前说明一次，而不是每次都在审查时返工。 - 描述业务规则，而不只是函数签名；边界情况就藏在业务规则里。
像审查初级开发者的代码那样审查
AI生成的代码能编译通过、看起来符合惯用写法的频率，远高于它实际正确的频率。请把它当作一位能干但无人监督的初级开发者提交的pull request来对待：逐行阅读、质疑每个假设、在信任之前先运行。值得刻意检查的高频bug类型：
- 循环、切片和分页边界处的差一（off-by-one）错误。 - null和undefined处理，尤其是API响应中的可选字段周边。 - 异步代码中的竞态条件：未await的Promise、共享可变状态、缺失的锁。 - 微妙错误的API用法——真实存在的方法但参数顺序错了、用了已弃用的重载、依赖了在版本间发生变化的默认值。 - 本应来自配置却被硬编码的值。
一个有用的纪律是：在合并之前，用一句话解释每个生成函数的作用。如果说不出来，就说明你还没有真正审查过它。
幻觉API与不存在的包
模型会经常性地凭空发明方法、选项，甚至整个软件包。这些幻觉出来的名字之所以危险，恰恰因为它们看起来合理——往往是两个真实库的混合体，或是存在于另一个框架里的方法。在任何不熟悉的API上构建代码之前，先在官方文档中核实，并在编写周边代码之前先单独试一下导入。
这里还有一个实实在在的安全问题。攻击者已经用AI模型常见的幻觉名称发布过恶意软件包，这是typosquatting（误植域名抢注）的变种，有时被称为slopsquatting。绝不要仅仅因为助手推荐就安装一个包。先检查注册表页面、下载量、维护者历史，最好再看一眼源码仓库。在广泛流传的AI编程会话分析中，凭空捏造的包名出现的频率之高，足以说明这项检查应当成为固定习惯，而非偶尔为之。
安全审查不是可选项
生成的代码经常省略那些不起眼的安全工作。每一次AI辅助的变更都要明确检查以下几点：
- 注入：数据库查询必须参数化，绝不能用字符串拼接；shell命令同理。 - 密钥：模型会毫不犹豫地把提示词里的API密钥和连接字符串硬编码进源文件。密钥应保存在环境变量或密钥管理器中，并且永远不要把真实凭证粘贴到提示词里。 - 输入验证：假设每一个边界——HTTP处理器、队列消费者、文件解析器——收到的都是恶意输入，并核实生成的代码确实做了验证。 - 授权：生成的端点往往检查了身份认证，却跳过了针对具体资源的授权检查。
让模型审查自己输出中的漏洞是值得做的二次检查，也确实经常发现真实问题，但它是对人工审查和静态分析工具的补充，而不是替代。
迭代打磨，而不是重新生成
当输出大体正确时，请克制推倒重来的冲动。重新生成会丢弃所有已经正确的部分，并引入新的、未经审查的变数。相反，应当点名具体缺陷：这个函数保持原样，只添加一个守卫：当items数组为空时返回空的summary对象。功能要分步构建——先数据模型，再端点，再接线——每个阶段都审查，让后续步骤建立在已验证的代码之上，而不是未经检查的输出之上。
先写测试
测试驱动开发与AI的配合出奇地好。测试要自己写——或者生成后严格审查——让它们编码你的真实需求，然后让模型实现能通过测试的代码。这样就颠倒了信任问题：你不再需要逐行审计不透明的逻辑，而是对照自己掌控的规格来验证行为。
对同一会话中同一模型在代码之后生成的测试要保持警惕。这类测试倾向于验证代码实际做了什么，而不是它应该做什么，会心安理得地把你本想捕捉的那些bug断言成正确行为。至少要审查生成的测试是否遗漏了边界情况：空输入、边界值、错误路径和并发访问。
什么时候不该用AI生成代码
- 几乎没有公开代码可供学习的新颖算法或小众领域——输出质量急剧下降，幻觉率上升。 - 加密、认证流程等安全关键原语：应使用经过审计验证的库，而不是生成的实现。 - 你没有能力评估的代码。如果你无法判断输出是否正确，就无法审查它，而未经审查的AI代码就是一笔负债。 - 每一行代码的来源和许可都可能被追问的合规敏感代码。
架构决策由人负责
模型只是在为看似合理的局部解优化；它们不为你的系统的长期形态承担责任。关于服务边界、数据流、依赖选择和故障模式的决策，应该由将与后果共存的人来做。可以用AI探索方案、通过索要反方论证来对设计做压力测试、在你设定的结构内完成实现——但决策本身，以及对决策的问责，必须留在人的手里。
把这些实践结合起来，AI代码生成就会从微妙缺陷的来源转变为真正的生产力倍增器：在起草和样板代码上获得实实在在的提速，而正确性仍然由合并代码的那个人来保证。