减少 AI 返工，我现在一般这么做

原文：Review AI-generated code 与 AI 代码审查实践的综合解读 作者：我（结合个人 AI 编程实践整理） 来源：GitHub、Uber、Cloudflare、Trellis 等公开资料，整理于 2026 年 08 月 26 日

AI 写代码越来越快，但返工并没有因此自动消失。我现在更关心的，不是 AI 一次写了多少，而是错误能不能更早暴露、修改能不能更小、人工判断能不能用在真正重要的地方。 这篇文章记录的，就是我目前用来减少 AI 代码返工的一条实践路径。

一、我以前把 AI 当成“写得更快的人”，后来发现它更像“放大器”

刚开始用 AI 写代码时，我最在意的是它能不能一次生成几百行、能不能把一个需求快速改完。后来真正经历了几轮线上问题、PR 返工和反复讨论，我才意识到：AI 放大的不只是产出速度，也会放大需求里的空白、上下文里的误导和开发者自己的错误判断。代码生成得越快，如果没有同步增加验证能力，Review 只是被动接收更多半成品。

我最近看了一些开发者分享和团队实践，大家的结论其实很接近：不要把“AI 写了多少代码”当成成功指标，而要看它是否减少了无效沟通，是否能在进入人工 Review 前被自动检查，是否让 reviewer 更快理解真正的风险。GitHub 的官方建议也很直接：先检查功能、上下文和意图，再看代码质量、依赖和安全；最终合并责任仍在开发者身上。我现在给自己的目标因此换了一个说法：不是保证 AI 一次写对，而是让错误尽可能早暴露，让每一轮修改尽可能小，让机器能判断的事情不要消耗人工判断，让必须由人判断的事情明确标出来。

二、写之前先做上下文盘点：不要让 AI “自己理解整个仓库”

我遇到过最浪费时间的一类任务，是直接对 Agent 说“先理解一下这个仓库，再实现功能”。小项目这样做问题不大，仓库一大，Agent 往往会先花很多时间猜目录结构，读到相似但已经废弃的实现，最后在错误的上下文上给出一份看起来很合理的方案。社区里有开发者把自己的流程总结成：先画仓库地图，再找相关文件，检查上下文是否足够，最后检查回答是否确实基于这些文件。我照着这个思路调整后，最大的变化不是回答更长，而是少了“改错文件”和“参考旧逻辑”的返工。

我现在会把任务拆成四步：

  1. 先定位：让 AI 只列出与任务直接相关的目录、入口、调用方、测试和配置，不要马上改代码。
  2. 再确认：让它说明每个文件为什么相关，哪些文件只是相似样例，哪些内容可能已经过期。
  3. 再补上下文：补充接口契约、数据库结构、历史 PR、业务规则和失败案例；如果这些信息没有提供，就明确标成未知。
  4. 最后锁范围：规定允许修改的文件和不允许顺手做的重构，要求它在动手前复述范围。

我会先使用这样的提示：

先不要写代码。请完成以下任务：
1. 列出本任务涉及的入口、调用链、数据结构、测试和配置；
2. 区分“已从仓库确认的事实”和“你的推测”；
3. 指出还缺少哪些上下文，以及缺失它们会影响什么判断；
4. 给出最小改动计划，列出准备修改和明确不修改的文件；
5. 等我确认计划后再实现。

这里有一个容易被忽略的细节：我不会把所有文档一股脑塞给 AI。上下文太多同样会稀释重点，我更倾向于使用“渐进披露”：先给仓库地图和任务相关文件，遇到具体问题再补充协议、ADR、历史 PR 或业务文档。AI 必须回答“我实际参考了哪些文件”，而不是笼统地说“我已经理解整个项目”。上下文的关键不是多，而是相关、最新、可核对。 如果它引用了过期文档，我会先停下来校正上下文，而不是继续修补错误答案。

三、把需求写成验收标准，再让 AI 小步实现

我以前的 Prompt 经常只有一句“帮我增加一个接口”，真正缺的不是措辞技巧，而是验收条件。现在我会先写一张很短的任务卡，至少包含五项：目标和非目标、改动范围、输入输出、业务约束、验收标准。验收标准最好能直接转成测试或检查命令，例如“未登录用户返回什么”“重复请求是否幂等”“旧字段是否继续兼容”“迁移失败时能否回滚”，而不是写成“保证健壮性”这种无法判断的句子。不能被判断的要求，通常也不能被有效 Review。

我会要求 AI 在开始实现前先输出：

  1. 它理解的目标和非目标；
  2. 它做出的关键假设；
  3. 正常路径、边界路径和失败路径；
  4. 计划新增或修改的测试；
  5. 仍然需要我确认的决策点。

如果它说“没有需要确认的问题”，我也不会直接相信，而是反过来检查它是否遗漏了权限、数据一致性、并发、超时、重试、幂等和兼容性。让 AI 反问有用，但“固定提五个问题”不是重点；重点是逼它把事实、假设和未知分开。反问环节不能代替产品和开发者做决定，它只是把隐含决定提前暴露出来。

计划确认后，我不会让 AI 一次生成整个功能，而是采用“一个可验证的小步一个提交”的方式：先补测试或接口契约，再实现最小逻辑，再处理异常和边界，最后做必要的重构。每一步都要求它说明改了什么、为什么改、如何验证。如果发现方向错了，回滚的只是一个小步骤，而不是一大团互相纠缠的代码。我宁愿多确认一次计划，也不愿意在一大团代码里寻找最初的错误假设。

我也逐渐放弃了“Prompt 越长越好”的想法。社区开发者常见的建议是：目标要窄，先做一个模块，不要一上来让 Agent “搭建整个平台”；把长期有效的规则放进项目里的说明文件、架构决策和 lessons learned，而不是每次在对话里重复二三十条要求。对我来说，短 Prompt 的前提不是少写约束，而是把约束放到了更稳定、能被团队共同维护的地方。

四、Review 之前先建立“机器地板”，AI Review 只做有边界的辅助

社区中最有价值的一条经验，是先把确定性检查做扎实，再谈更复杂的 AI Review。格式化、编译、类型检查、单元测试、依赖扫描、秘密扫描和静态分析，虽然不够聪明，却便宜、稳定、可重复。能写成 lint 规则的命名约束，就不要依赖 AI 每次提醒；能写成测试的业务反例，就不要只放在 checklist 里；能在 CI 阶段统一执行的检查，就不要只依赖开发者本地是否记得运行。

我现在的 Review 顺序是：

  1. 先看变更边界：看完整 diff 和文件列表，确认没有无关重构、异常依赖、生成物污染或意外删除。
  2. 再看机器结果：确认格式化、类型、测试、静态分析、安全扫描和迁移检查都基于当前提交执行过，而不是复制上一轮结果。“通过”必须能追溯到具体提交和具体输出。
  3. 再看需求路径：沿着验收标准检查主路径、反例和失败处理，确认测试不是“为了通过而写”。
  4. 再用 AI 找候选风险：要求它只报告有证据的问题，给出文件位置、触发条件、影响范围和验证方式，并区分确定问题与推测风险。没有证据的风险只能标成“待验证”，不能写成结论。
  5. 最后做人类判断：审查架构取舍、业务意图、权限边界、上线顺序、回滚方案以及对现有行为的影响。

AI Review 最容易犯的错误不是完全没用，而是评论太多、太泛、太像正确废话。Uber 分享过他们做 AI Review 的经验：评论质量比数量重要，需要按置信度过滤、合并重复意见、删除历史上价值很低的类别；他们还发现，仅看代码本身，无法可靠判断数据库结构、功能开关、技术文档和系统设计。因此我会在 Prompt 中加上“不要为了凑数量而评论；无法定位到证据就标为未知；重复问题合并；低置信度建议不阻塞合并”。AI Review 的目标是提高信噪比，不是增加评论数量。

我不会让 AI 代码审查工具直接拥有“批准”或“阻塞合并”的最终权力。Cloudflare 的实践给了我另一个启发：可以根据改动行数、文件数量和风险类型分层调用不同的审查能力，小改动跑轻量检查，大改动再增加安全、性能、发布和合规审查。但无论自动化多完善，架构、业务目标和部署协调仍然需要人负责。AI Review 是第二双眼睛，不是替你签字的人。 对涉及权限、资金、隐私、迁移和并发的代码，我会主动提高人工 Review 等级，而不是因为 AI 给了绿色结论就降低警惕。

五、用数据和反馈闭环，真正减少下一次返工

我过去发现 Review 问题后，通常只改代码，然后继续往前走。这样同一类问题会反复出现。现在我会给每个问题归类：是需求没有写清楚，是上下文找错了，是业务规则缺失，是测试没覆盖，是确定性工具没配置，还是人工判断遗漏。不同原因要回到不同的位置修复：需求问题补任务卡，上下文问题补项目地图或文档，业务问题补规则和反例，测试问题补回归用例，工具问题补 lint 或 CI，Review 问题则更新检查清单和风险分级。

团队实践里还有一个我很认可的做法：不要只统计“AI 发现了多少问题”，还要记录哪些评论被采纳、哪些是误报、哪些问题后来由 lint 或测试接管、哪些问题仍然只能由人判断。Trellis 分享过一组自己的 PR 分析：他们发现自动化可以覆盖一部分重复性的 Review 请求，但 AI Review 的覆盖率只是“可自动化上限”，不是保证捕获率；仍有一部分涉及新设计、意图、领域知识和发布协调的问题必须留给人。这个区分很重要，因为它提醒我，自动化的目标不是制造“无人 Review”的幻觉，而是把人的时间集中到机器确实无法可靠判断的地方。我真正想追踪的不是 AI 说了多少，而是哪些问题被可靠地提前拦住了。

我现在会用下面这套最小闭环：

  1. 任务开始前写目标、范围、约束和验收标准。
  2. 让 AI 先建立相关上下文，列出事实、假设和未知。
  3. 确认最小改动计划，按小步实现。
  4. 先运行确定性检查，再让 AI 基于真实结果做辅助审查。
  5. 人工按风险等级审查完整 diff，而不是只看 AI 的摘要。
  6. 把发现的问题归类，补回需求、文档、测试、工具或 checklist。
  7. 定期清理过期规则，检查 AI 是否产生过多误报。

结论

如果只记住一句话，我希望是：减少 AI 代码返工，不靠一句更复杂的 Prompt，而靠一条更短、更硬的反馈链：明确目标，限制上下文，小步修改，自动验证，人工负责，错误回写。 AI 可以帮我写代码、补测试、找候选问题，也可以帮我整理团队经验；但它不能替我理解业务、承担上线责任，更不能因为它说“没有发现问题”就让人停止思考。真正的提效不是少做 Review，而是少把低价值问题带到 Review。

给读者的启示

  1. 大仓库先做“仓库地图—聚焦上下文—覆盖检查”，不要让 AI 盲目扫描整个项目。
  2. Prompt 先写验收标准和边界，再写实现要求；长期规则放进可维护的项目文档。
  3. 把能确定判断的内容交给格式化、测试、lint、类型检查和 CI，把 AI 留给需要语义理解的候选风险。
  4. AI Review 要追求少而准，必须允许它说“未知”，并记录误报和漏报。
  5. 人工 Review 不会消失，只会从重复检查转向架构、业务意图、风险和责任判断。

我参考的公开实践：