摘要：AI 编程真正的价值，也许不是让团队更快地堆代码，而是让开发者更系统地设计、审查、验证和取舍。慢一点，不是拖延，而是把未来的返工、事故和认知负担提前处理掉。
AI 编程工具最常见的宣传语，是“更快”。更快生成样板代码，更快补全函数，更快搭出一个 demo，更快把需求变成 pull request。于是很多团队开始把 AI 当作“代码喷射器”：写得越多越好，提交得越快越好，最好一个下午就把过去一周的代码量都堆出来。
但 Nolan Lawson 最近的一篇文章，提出了一个反直觉的观点：AI 不只可以用来更快地写代码，也可以用来更慢、更细、更认真地写出更好的代码。他把 LLM 的输出看作第一稿，真正的工作从代码审查开始。(Read the Tea Leaves)
这恰好击中了 AI 编程的核心误区。代码质量从来不等于代码产量。一个功能能跑，不代表它可维护；一个测试通过，不代表边界条件安全；一个 PR 看起来完整，不代表架构方向正确。AI 最大的价值，也许不是替我们少想一点，而是迫使我们想得更全面。
一、把 AI 当成“搭档”，不是“外包团队”
很多糟糕的 AI 代码，来自一个错误姿势：把需求丢给模型，然后等待成品。模型当然会给你成品，甚至会给得很自信。但它并不知道你真正的业务约束、历史债务、团队习惯、部署风险和长期演进方向。它擅长生成看起来合理的代码，却不天然理解“这段代码以后会不会让团队痛苦”。
更好的方式，是把 AI 放进开发流程的多个阶段，而不是只让它承担“写代码”这一个动作。
在设计阶段，让 AI 帮你找遗漏：这个方案有哪些失败模式？数据库索引是否足够？并发场景下会不会出现竞态？权限边界是否清楚？在实现阶段，让 AI 处理局部、明确、可验证的任务：补测试、改重复代码、生成迁移脚本、实现一个已有接口下的小函数。在审查阶段，再让另一个模型或另一个上下文来挑刺：哪里可能空指针？哪里可能性能退化？哪里违反了团队规范？哪里只是“看起来对”？
Lawson 描述的做法，正是这种多阶段思路：让 Claude、Codex、Cursor Bugbot 等工具参与 PR 的 bug 搜索和分级，然后由人判断哪些必须修、哪些可以放弃、哪些说明整个方案应该重来。(Read the Tea Leaves)
二、AI 写出的第一版，只是草稿
人类程序员写代码时，第一版也常常不是最终版。我们会重构，会补测试，会删除刚写下的东西，会突然意识到抽象错了。AI 生成的代码也一样，甚至更需要这种“第二遍工作”。
问题是，AI 让第一版来得太容易了，于是我们误以为第一版就可以合并。过去手写代码时，我们会因为写得慢而被迫思考；现在 AI 把键盘速度提高了，思考反而更容易被跳过。高质量 AI 编程的关键，就是把省下来的打字时间重新投入到理解、验证和取舍上。
一个实用原则是：凡是 AI 生成的代码，都先默认它是“候选方案”，而不是“正确答案”。你需要问它四类问题：
第一，这段代码解决的到底是不是原问题？第二，它在哪些输入、状态或权限下会失败？第三，它有没有引入新的复杂度、重复逻辑或隐性依赖？第四，如果半年后别人维护它，能不能快速理解？
这些问题比“帮我写一个函数”更有价值。因为好代码不是一堆语法正确的 token，而是一组被充分解释、充分约束、充分验证的工程决策。
三、让多个模型互相审查，但最终由人负责
一个很有用的实践，是不要让同一个 AI 同时扮演作者和审稿人。人类团队不会让作者自己完成全部 code review，道理相同。你可以让一个模型实现，让另一个模型审查；让一个模型关注安全，让另一个模型关注性能；让一个模型检查可访问性，让另一个模型检查测试覆盖。
但多模型并不等于多真理。AI 审查经常会产生看似严肃但实际无关紧要的建议，也可能夸大一个边界情况的风险。Lawson 的流程里有一个重要动作：不是把所有发现都机械修掉，而是按 critical、high、medium、low 分级，优先修关键问题；对于代价过高、收益很窄的边界情况，可以选择不修；如果关键问题太多，说明 PR 的方向可能错了，应该放弃重来。(Read the Tea Leaves)
这就是人类工程判断不可替代的地方。AI 可以扩大检查面，但不能替你决定什么值得做。好的开发者不是“听 AI 的话”，而是利用 AI 产生更多备选判断，再用自己的上下文和责任感筛选。
四、慢，不是低效，而是把成本提前支付
Hacker News 的讨论里，有人指出 AI 辅助流程有时会变成漫长的来回拉扯，甚至不比自己手写更快；也有人认为，这种慢类似 code review：局部看降低速度，整体看提升质量。(Hacker News)
这句话很重要。软件工程里很多真正有价值的活动，短期看都“不快”：写测试不快，做设计评审不快，重构不快，补文档不快，删除错误抽象也不快。但它们减少的是未来的返工、线上事故、认知负担和团队摩擦。
AI 如果只被用来加速产出，很容易把技术债也一起加速。如果它被用来提前发现失败模式、补齐测试、解释复杂路径、比较方案取舍，那么它增加的不是代码量，而是代码可信度。
所谓“用 AI 慢慢写好代码”，并不是崇拜慢，而是拒绝把快当成唯一指标。真正的速度，是系统长期演进时仍然可理解、可修改、可验证。
五、一套可落地的 AI 编程流程
可以把 AI 辅助开发拆成六步。
1. 先写问题定义，而不是马上写代码
告诉 AI 当前目标、非目标、约束、已有架构、不能破坏的行为。让它先复述需求，并列出不确定点。
2. 让 AI 给出两到三个方案
不要只要“最佳方案”，而要比较简单方案、稳妥方案和可扩展方案。要求它说明各自的失败模式。
3. 由人选择方案，并缩小实现范围
越复杂的任务，越不要一次性让 AI 端到端完成。把任务切成小 PR、小函数、小测试、小迁移。
4. 让 AI 实现，但要求它同时生成测试
没有测试的 AI 代码，审查成本会迅速上升。测试不是装饰，而是把模型的输出变成可验证对象。
5. 换模型或换提示词做审查
让它按严重程度列出问题，并明确区分“确定的 bug”“可能的风险”“风格建议”。这一步的目标不是让 AI 显得聪明，而是帮你发现自己没想到的角落。
6. 人类做最终裁决
修关键问题，忽略低价值建议，必要时推翻整个实现。永远不要因为“AI 已经这么写了”就迁就一个坏设计。
六、好提示词的本质，是好工程习惯
很多人把 prompt 当成魔法句式，其实好提示词往往只是好工程习惯的文字化。你越能清楚描述上下文、边界、验收标准、风险偏好，AI 越容易给出可用结果。
“帮我实现登录功能”是弱提示。
“在现有 OAuth 流程中增加 GitHub 登录，不改变邮箱登录；必须支持 CSRF 防护；失败时保留现有错误页；新增单元测试和一个集成测试；不要引入新框架；先列方案再写代码”就是强提示。
前者把责任推给模型，后者把工程约束交给模型。差别不在 AI，而在开发者是否仍然掌握问题。
结语：AI 不是替代思考，而是放大思考
用 AI 写好代码，关键不是找到最强模型，而是建立正确流程。让 AI 帮你写第一稿，也帮你拆解风险；让它生成代码，也让它攻击代码；让它节省重复劳动，但不要让它偷走你的判断。
最快的 AI 编程方式，是不加审查地合并。最慢的 AI 编程方式，是和模型无休止争论。真正成熟的方式，在两者之间：小步生成，严格验证，多轮审查，人类负责。
当我们不再问“AI 能让我一天写多少代码”，而是问“AI 能不能让我少犯一些昂贵的错误”，AI 编程才开始进入真正的软件工程阶段。