on
如何让 AI 100% 生成可靠的生产级代码
一、人是主厨，AI 是副厨
AI 能写代码，不能为代码负责
在2026 年，任意一个 AI 编码工具都能在 10 秒内生成一个 CRUD 接口。但"能生成"和"能上线"之间，隔着一条鸿沟：责任归属。
AI 不会在凌晨三点被报警电话叫醒，不会在代码审查时解释"这个地方没想到"，更不会因为一个内存泄漏导致用户流失而承担责任。对代码质量负最终责任的，只能是写 Prompt 的那个人。
这里隐藏着一个核心隐喻：人是主厨，AI 是副厨。 副厨可以切菜、备料、甚至炒几道菜，但端上桌之前，主厨必须尝过每一口。不是不信任副厨——是因为主厨的名字写在菜单上。
每一行都要审查，没有例外
“AI 写的代码看起来很对"是最危险的幻觉。
在 Luma 项目中，我给团队定了一条铁律：AI 生成的每一行代码，必须经过人工审查才能合入主分支。 这不是效率的倒退——正好相反。AI 也会偷懒——该处理边界条件时它写了个 // TODO，该拆分函数时它堆了 200 行，该加错误处理时它假装异常不会发生。这和人类开发者的坏习惯一模一样。区别在于，同事偷懒你可以对他发火，AI 偷懒你只能打回去重写。
审查的标准只有一个：这是我要上线的项目，每一行烂代码最终都是我来扛。 风格问题让 Linter 拦，逻辑问题让测试拦，但架构上的"看起来能跑但三个月后会炸”——只有人能在审查时嗅出来。
实操规则：
- AI 提交的 PR 必须附带接收到的 原始 Prompt，写在 PR description 里
- 审查时对照 Prompt 和实现，只判断"AI 是否理解错了需求"
- 代码风格、格式化等低级问题由 Lint/Format 工具自动拦下，不消耗人的注意力
全栈开发，减少沟通损耗
在团队开发中，一个容易被忽视的事实：当编码不再是瓶颈时，沟通成为新的瓶颈。
传统团队里，前端等后端接口、后端等产品确认、产品等 QA 出测试报告——每个环节都在发生信息损耗。AI 让单兵作战能力指数级增长，但前提是这个人能串起全链路。
全栈的意义不是贴标签，而是让全栈工程师对上下游有足够的判断力。当一个人既能写前端组件，又知道后端 API 怎么设计最合理时，Prompt 天然少了歧义——不需要向前端同事解释需求，因为自己就是那个同事。
判断力是 AI 时代最稀缺的资源
AI 可以替代经验中的"记忆"部分——不再需要记住 API 参数顺序、不再需要记住框架语法。但它替代不了判断力：
- 这个架构决策会影响三年后的扩展性吗？
- 这个第三方依赖明天还会维护吗？
- 这段代码的性能瓶颈在哪里——AI 不会主动指出
我的体会是：每到一个关键节点，人的判断力必须介入。 选型阶段，AI 可以列出所有方案的优缺点，但最终选 Go 还是 Rust、选单体还是微服务，这个决定只能人来做。AI 是工具，不是替代品。主厨的舌头，永远比副厨的刀更重要。
二、流程是刹车，不是束缚
AI 能在 10 秒内生成 500 行代码。这意味着如果流程不设防，10 秒内就能引入一个生产事故。传统开发中，打字速度本身就是一道限速——想快也快不到哪去。AI 打破了这道限速，流程就必须顶上。
但"流程"这个词容易让人反感。很多人觉得流程等于官僚、等于慢。我的看法相反：好的流程是刹车系统——没有刹车的车不是更快，是不敢开快。
在我自己的项目中，TDD 是给 AI 画跑道。以前写测试是为了验证代码对不对，现在写测试是为了告诉 AI"什么叫对"。测试有多细，AI 生成的代码就有多可靠。模糊的测试等于模糊的需求，AI 就会自由发挥。把边界条件、异常路径、返回值格式全写进测试，这份测试就是 AI 无法误解的可执行 Spec。我的工作流很简单：先写测试，再把测试文件和需求描述一起喂给 AI，它生成代码，跑测试——红灯打回重写，绿灯进入我的人工审查。
回归测试更关键。AI 改代码最让我头疼的问题：改了 A 模块，悄悄破坏了 B 模块，而 AI 根本不知道 B 模块的存在。所以每次 AI 提交，全量回归套件必须自动跑一遍。没变红才允许合入。一个反直觉的体会：AI 写的代码越多，回归测试的 ROI 越高。
多方案并行是我用 AI 之后最上瘾的玩法。同样的需求，同时让三个不同的模型各自生成一套实现，跑同一套测试，比性能、比简洁度，只留最好的那个。这在以前是不可想象的——谁会让三个工程师写同一段代码然后只留一份？但 AI 让这件事几乎没有额外心理负担。在 Luma 项目里我经常这么干，这种"AI 内部竞争"有效压低了单一模型输出的偏差。
流程不是为了限制 AI，是为了让 AI 跑得更快而不翻车。TDD 保证功能正确，回归测试保证没有连锁破坏，多方案并行保证没有局部最优。踩得住刹车，才敢踩油门。
三、拆到 AI 不会犯错为止
我用 AI 写代码最大的教训就一句话：粒度决定质量。
给它一个"重构整个支付系统"的任务，它会迷失在细节里，东拼西凑，产出一堆不可维护的代码。给它一个"实现 calculateRefund 函数，输入订单 ID 和退款金额，返回退款记录对象"，它几乎不会出错。差距不是 AI 的能力，是任务的清晰度。
我自己的检验标准很简单：如果 AI 生成的结果需要我花超过五分钟才能判断是否正确，说明拆得不够细，打回去再切。
拆小还不够，每项任务得配一份自包含的 Spec。我的 Spec 模板很固定——明确目标一句话、技术约束（语言、框架、API 契约、性能要求）、输入输出示例、边界条件（空值、超时、并发、错误处理）。没有 Spec 把任务丢给 AI，等于让副厨凭感觉炒菜。有了 Spec，AI 要做的就是翻译，不是创作。
四、三层开发循环
在实际工作中，我把 AI 开发分成三个时间尺度的循环。
最短的是五分钟内的内环：写 Spec → AI 生成代码 → 跑测试 → 我审查 → git commit。任务切得极细，每次微小的成功都提交，跑不通立刻回退，不积累问题。
中环管的是会话之间的上下文交接。AI 不像人类同事，不会记得上个会话做了什么，除非我主动把状态外化。现在我维护三样东西：项目进度文档（当前在做什么、下一步做什么）、架构决策记录（为什么选这个方案、不选那个），以及每次长会话结束后的简短总结。这些文档不需要华丽的格式，但必须在新会话开始时让 AI 读到。它们就是 AI 的"长期记忆"。
最长的外环是架构设计和基础设施。这些决策以月为单位，但影响以年为单位——用什么语言、选什么数据库、单体还是微服务、部署和监控怎么搭。一条我反复验证的经验：模块化和极简主义在 AI 时代更加重要。 AI 擅长在清晰的模块边界内工作。架构越模块化，每个模块越小越内聚，AI 的产出质量就越高。反过来，一个巨型单体里 AI 只会制造更多的耦合和意外。
五、AI 的工具链
MCP（Model Context Protocol）是我最近最关注的基础设施。它的核心价值就一点：让 AI 不再只能靠记忆和幻觉回答问题，而是真的调用外部工具和服务获取实时数据。配了 GitHub MCP 之后，AI 能直接读 Issues、创建 PR、看 CI 状态——不用我手动中转。配了数据库 MCP，它就能查线上数据。这些能力把 AI 从"代码补全工具"升级成了"开发环境的一部分"。
Puppeteer/Playwright 解决的是另一个致命盲区：纯文本模型看不见 UI。一段代码逻辑完全正确，但渲染出来布局错乱、移动端适配全炸——这是 AI 前端代码最高频的翻车类型。我现在让 AI 生成前端代码后，自动用 Playwright 打开无头浏览器渲染页面，截图对比前后版本。这些截图还能喂给多模态模型做视觉检查。
上下文管理也需要刻意为之。我在日常开发中做了个区分：聚焦型上下文（当前任务相关的代码、测试、Spec）是每次 Prompt 必带的，综合型上下文（项目 README、架构文档、编码规范）放在项目文档里按需引用。对于规模大的代码库，我还维护一份项目精华摘要——把 AI 需要知道的关键信息压缩到一页，包括技术栈、目录结构、核心模块职责、编码约定。这份文档就是 AI 的入职手册。
六、管理一个 AI 开发团队
当一个人加多个 AI 能完成过去一个团队的工作时，工作方式本身需要重新设计。
并行开发是我每天的常态。同一个需求分派给多个 AI 实例，各自产出，我跑同一套测试后选最优的合并。这背后需要一个清晰的标准来判断"哪个方案更好"——不只是测试通过率，还包括代码简洁度、性能指标、可维护性。我尽量把这些标准写成自动化检查规则，而不是每次凭感觉选。
多方案并行意味着合并频率很高，这也倒逼了模块化设计。如果代码耦合严重，并行产出的合并就是噩梦。所以我越来越倾向于先花时间定好模块边界和 API 契约，然后让 AI 在边界内各自发挥。
人和 AI 之间的协作，我把它拆成三个层面来想：工作本身怎么拆、怎么分派、怎么验收；工具和基础设施让 AI 有手脚；协作方式让人和 AI、AI 和 AI 之间的信息流动顺畅。想清楚这三层，一个人就是一个团队。
七、编码不再是瓶颈之后
编码效率提了十倍以后，我发现真正的瓶颈根本不在写代码上。
部署流程从 CI 到上线要三天？那我写再快也没用。Code Review 积压了二十个 PR？AI 只是更快地填满队列。所以我开始用 DORA 四指标来衡量效率：部署频率、变更前置时间、变更失败率、故障恢复时间。编码速度只是四个指标中的一环，如果部署、测试、监控跟不上，AI 只是在帮我更快地积累技术债务。
另一个被放大的问题是团队的"沟通税"。五个人有十条沟通链路，当 AI 让每个人效率翻三倍，沟通成本不会自动降。我的应对是模块化设计、清晰的 API 契约、每个人独立可验证的工作范围——这些在 AI 时代比以往任何时候都重要。
说到底，AI 会犯错，而且犯错速度比人快。唯一应对方式是让反馈循环足够短，让每次错误的影响范围足够小。在每一个关键节点保留自己的判断力——写什么代码交给 AI，但写不写这个功能、上不上这个方案，永远由我来决定。
本文框架受到《Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond》一书的启发。但这本书最重要的是让我意识到——AI 时代的核心竞争力不是"会用 Prompt"，而是判断力、流程设计能力和对质量的偏执。这三样东西，AI 一个也替代不了。