我们不再审查代码，而是开始验证意图
原文：We stopped reviewing code and started verifying intent — Tessl Blog，2026-10-20
作者：Ankit Jain，为 AI Native DevCon 而作
说明：以下为原文中文翻译，原文版权归原作者及 Tessl 所有。
Ankit Jain，Aviator 创始人兼 CEO，在 AI Native DevCon 分享这套“验证意图”的工作流。
作者：Ankit Jain，为 AI Native DevCon 而作
当你的团队合并的 PR 数量是一年前的四倍，而且几乎没有任何代码是人手敲出来的，你该怎么办？
这就是我的团队今天的处境。我们交付的几乎所有东西都是 AI 生成、人类辅助的，而且数量还在不断攀升。我们一开始做了最显而易见的事：尝试用 AI 审查工具或更严格的检查清单来扩展代码审查。但都没有用。
真正有效的是彻底放弃逐行阅读代码，转而在意图周围构建一层验证机制。
为什么把 AI 生成代码的审查规模化行不通
今年早些时候，我为 Latent Space 写了《如何干掉代码审查》。文章火了，从那以后我就一直在谈 AI 代码审查的瓶颈。
这个问题反复出现，因为它的成因并没有消失。在四倍的代码量下，审查成了交付流程中最慢的一步。
大多数使用 AI 编程工具的团队都会遇到代码审查瓶颈，并试图用更多审查者、增加 AI 代码审查工具，或对代码生成施加更严格规则等组合方案来解决。但真正的问题在于被审查的对象。diff 告诉你改了什么，却没有告诉你这个改动原本应该做什么。
这篇文章讲两个对我们影响最大的实践，以及它们最终形成的框架。
作为基础，我们现在维护一个共享 skill，叫 “offer-skill”，以最初发起它的工程师命名。它已经成了所有人用来理解代码改动的 skill。
审查意图，而不是 diff
传统观点认为，人的判断应该放在最后：有人读代码，然后决定它看起来对不对。
面对 AI 生成的代码，这会让审查者陷入困境。他们要读 400 行代码，然后试图反推这个改动原本想做什么。只有当团队有维护良好工单的纪律时，工单描述才有帮助。现实是，大多数工单写得很潦草，实际的意图和行为早已偏离工单。
所以我们把人的判断移到最前面。在生成任何一行代码之前，我们先审查意图：验收标准、约束条件和边界情况。这正是资深工程师的注意力最有价值的地方，因为在这个阶段修正一个错误想法的成本几乎为零。
然后，我们把这个意图当作一份可以验证的契约。每条标准都会得到一个确定性的结论，并附带证据。
现在的审查看起来不一样了。审查者不再滚动浏览 500 行 AI 生成的 diff，而是查看五条标准的验证结论，以及展示实际发生情况的截图和请求链路。
验证结果页：5 条验收标准 + 3 条不变量，全部通过，并附带截图和请求链路证据。
这对开发者意味着什么？在代码合并之前，作者和审查者都知道这段代码应该做什么。如果你在一个改动还不存在时都说不清它应该做什么，那么事后读代码也不会告诉你。
挖掘你的 PR 评论，它们就是等待被写成的不变量
每个团队都有一些活在资深工程师脑子里的标准。它们靠一条又一条评审评论来执行。
翻翻你的评审历史，你会看到同样的评论被一遍又一遍地写出来。那些就是藏在明文里的团队标准。在四倍的 PR 数量下，手工重复这些标准本身就成了一种瓶颈。
于是我们回溯了 X 条反复出现的评审评论，把它们变成了不变量（invariants）：一种可复用的规则，由机器在每次改动时强制执行。
译注：原文此处为 “X”，疑为占位符；结合上下文，应指团队反复出现的评审评论。
好的不变量枯燥而具体。例如：
- 任何涉及货币的地方都使用
Money类型。 - 不允许直接写
users表。 - 只使用结构化日志，不允许
print语句。
并不是每条评论都够格成为不变量。
不变量库：把反复出现的 PR 评论沉淀为可被机器执行的规则，并按可访问性、性能、安全等类别管理。
如果你想试试，从最近 1,000 条评审评论开始。你重复最多的那 20 条，就是你的第一批不变量。你不是在发明规则，而是在把已经存在的规则写下来。一旦某个标准变成了不变量，就不需要任何人再去指出它了。
要记住，这个转变不会一夜发生。第一个月，团队很可能会觉得在干双份活：既要审查代码，又要建立不变量。要和团队把预期说清楚：这个规则库需要时间积累。到了第二个月，规则库能拦住足够多的问题，审查量就会下降。到了第三个月，审查者读的是意图，而不是代码。
代码审查没有消失，只是改变了形态
我们仍然在审查。变的是审查的目的。上面两个实践，是我现在用来描述这套流程的五步形态中的一部分：
- 争论（Argue）。 在 PR 还不存在、改变方向成本最低的时候，让 Agent 互相挑战对方的方案。
- 记录（Capture）。 把意图和验收标准记录下来，并放到 PR 上。
- 固化（Codify）。 把团队反复重复的评论变成不变量。
- 讨论（Debate）。 把人的审查时间花在决策上，而不是 diff 上。
- 归属（Own）。 确定谁拥有那些验证代码的规则。
对我们来说，结果是代码审查不再是瓶颈。资深工程师不再阅读 500 行 AI 生成的 diff。
太长不看
- 让 diff 审查的规模跟上 AI 产出，是行不通的。
- 在代码生成之前审查意图，并用证据验证每条标准。
- 把反复出现的评审评论变成不变量。
- 让人专注于决策，以及规则的所有权。
当 AI 写下你大部分代码时，人的审查最有价值的地方，是判断这个改动应该做什么。我会在 AI Native DevCon 上完整讲解这套工作流，并现场演示不变量定义和前后对比指标。
作者简介：Ankit Jain 是 Aviator 的创始人兼 CEO。Aviator 是一个开发者生产力平台，帮助现代工程团队大规模交付 AI 生成的代码，同时避免审查瓶颈、构建失败和脆弱的部署。
写在最后：当审查从 diff 转向意图，模型接入层也该升级了
这篇文章里最值得记住的一句话是：diff 只告诉你改了什么，不告诉你这个改动原本应该做什么。 当团队把审查前移到意图、让多个 Agent 互相挑战方案、再把重复评论固化成不变量时，背后其实有一个共同的前提：模型不能绑死在一家厂商、一个工具链上。不同任务需要不同模型，不同 Agent 需要不同推理风格；如果每换一次模型都要重做接入，验证层就会变成新的瓶颈。
这正是 接口AI（jiekou.ai） 想帮团队解决的那一层。
接口AI 是一个多模型 API 聚合中转平台：一个账号、一个 API Key、一套 OpenAI 兼容接口，即可调用 GPT、Claude、Gemini、Grok、Qwen、DeepSeek 等 200+ 主流模型。已有 OpenAI 集成的项目，通常只需替换 base_url 和模型名，就能把“换模型”从一次架构改造变成一次配置变更。
对正在搭建“意图验证 + 多 Agent 协作”流程的团队，接口AI 能在三个地方帮上忙：
- 让 Agent 用上合适的模型：同一套接口下按任务选择不同模型，支持 Anthropic / Gemini 原生协议，Claude Code、Codex CLI 等编程工具可以直接接入；想让多个 Agent 互相挑战，不必为每家厂商维护一套 SDK。
- 把成本管起来：官方资源与低价专区并行，特惠资源包约 8 折，企业订阅包约 75 折；企业包包含 200 个团队席位、共享密钥池与统一账单，并支持企业开票。编程 Agent 场景还支持 Prompt Caching，缓存读写单独计价。
- 让调用可治理：企业包提供 API Key 管理（额度限制、IP 白名单）、调用日志、数据看板和智能模型网关，可按任务难度、成本和质量做动态路由——这正好对应文章里“把规则交给机器执行、人负责决策和所有权”的思路。
文章说，代码审查没有消失，只是改变了形态。对 AI 团队来说，模型接入层也是一样：不是“要不要网关”的问题，而是“什么时候把网关补上”的问题。先把统一入口搭起来，再谈多模型路由、成本优化和验证自动化，顺序会更顺。