AI Agent 评估需要可执行规格（Executable Specs）

代码审查之所以慢，并不是因为工程团队忘记了如何审查代码。它慢，是因为我们能生成的代码量已经超出了我们对输出结果的信任。

我每周都能看到这种情况。我与从五人初创公司到拥有数千名开发者的组织等各类工程团队交流。模式是一致的：AI 编码智能体正在帮助团队产出更多的拉取请求，但这些拉取请求却要花更多时间等待审查。速度本应提升。但在许多地方，它只是把瓶颈挪了个位置。

在 AI Native DevCon London 上，我谈到了为什么会发生这种情况，以及我们能做些什么。这场演讲背后的核心问题很简单：到了 2026 年，为什么 AI 代码审查在工程团队中仍然是一个瓶颈？

简短的回答是信任。编码智能体在生成代码方面越来越擅长，但它们还没有始终如一地专注于验证功能是否符合最初的产品意图。如果我们想让智能体式编码在真实团队中规模化，就需要在规格说明与最终交付行为之间，加入一个验证层。

把这场演讲用作智能体上下文

如果你想把我在 AI Native DevCon 演讲中的想法付诸实践，Tessl 已经把这场演讲变成了一个可供你的智能体用作上下文的技能。你也可以观看完整录像。

AI 智能体评估必须从意图开始

AI 智能体评估是检查智能体是否达成了预期结果，而不仅仅是它是否产出了看似合理的代码。对于编码智能体来说，这意味着将实现的行为与功能规格、产品约束、视觉要求以及重要的用户流程进行对比。

这种区分很重要，因为智能体可能看起来成功了，但实际上是错的。

在最近的一个例子中，我让一个智能体为一个引导流程添加集成。我还附上了一段之前的录像，其中展示了一个具体的 UI 缺陷：一个按钮与另一个元素重叠。我的指令很明确。不要重复这个问题。

当开发者把预览环境发给我时，继续按钮恰恰就在我要求它不要出现的位置。

这不是一个复杂的分布式系统问题。这是一个直截了当的前端任务，且有一个可见的失败案例。如果一个智能体连这都能漏掉，那么当它跨权限、支付、引导、集成和业务逻辑工作时，我们就应该预期会出现多得多的困难失败。

更深层的问题在于，我们的工作流往往要求人类在智能体完成之后去发现这些错误。这就把产品经理、工程经理和审查者变成了验证系统。

可执行规格把产品意图转化为检查

可执行规格是智能体可以转化为具体验证工作的规格说明。它们不仅仅是给人看的文档。它们会成为智能体的输入，让智能体能够提取需求、检查预览环境、将行为与意图进行对比，并返回一个判定结果。

大多数优秀的工程团队已经有了原材料。它存在于 Jira、Linear、Monday、Notion、GitHub issues、Figma 文件、产品文档、支持记录和拉取请求描述中。缺失的一环是一个能够测试实现是否尊重该意图的系统。

我们规格审查器的第一个版本试图用一个智能体来完成这项工作。它可以访问功能规格、设计稿和已部署的预览环境。目标很简单：提取所有需求，并检查它们是否已实现。

它很快就遇到了瓶颈。一个智能体既要理解规格、规划工作、浏览应用、检查 UI，还要生成有用的报告，很容易耗尽上下文或失去一致性。解决方案是拆分工作。

一个智能体成为规划者。它的工作是阅读规格并识别需求、子需求、边界情况和潜在故障模式。其他智能体成为验证者。它们的职责更窄：检查应用的相关部分，一次验证一个需求。

这改变了输出的质量。不再是一个通用智能体试图审查所有内容，我们可以并行运行许多专注的智能体。每个都返回一个判定。然后一个编排器将结果收集成一份团队真正能用的报告。

规格加代码才是验证层

下一个教训是，仅有规格是不够的。

如果你只给智能体规格和设计，它能理解理想结果，但也可能凭空捏造没人要求的需求。这会产生噪音，而噪音在审查工作流中是危险的。一旦审查者不再信任报告，系统就会变成另一个被忽视的东西。

更好的方法是让智能体同时基于规格和代码。规格是意图。代码是现实。两者结合，就是一座金矿。

一个令人惊讶的发现是，对照基础分支进行审查可能比只审查差异更有用。差异展示了开发者或智能体选择的实现路径。这可能会使审查者产生偏见。基础分支有助于验证系统更贴近产品问题：鉴于已有内容，这个功能应该改变什么，预览现在是否按那种方式运行？

范围也很重要。如果变更是一个前端功能，智能体不应仅仅因为能检查后端文件就生成无关的后端发现。验证需要边界。它应该知道正在审查什么类型的功能、哪些界面重要，以及哪些故障会真正阻碍团队。

这就是可执行规格从理论走向实践的地方。它们让团队从“请审查这个 PR”转向“检查这个实现是否满足所述需求和关键流程”。

验证必须在风险可控的地方运行

还有一个团队不应忽视的问题：安全。

为了验证预览环境，智能体可能每月需要多次点击未知链接。在正常的安全讨论中，我们会将其描述为网络钓鱼行为。现在想象一下，让那个智能体在靠近你的源代码、客户数据、凭证、云存储和模型密钥的地方运行。

这不是一个小运营问题。这是一个真实的架构风险。

我们的结论是，不应在产品内部随意构建危险的安全基础设施。对于 SDLC 中的高风险部分，使用经过验证的第三方沙箱通常比临时拼凑更好。在我们的案例中，每个需求都可以在隔离的浏览器会话中运行，返回一个判定，并避免暴露环境的其余部分。

这种模式也适用于验证新需求之外的场景。客户很快就问到了关键流程的回归问题。如果订阅流程出问题，公司可能会立即流失客户。我举了一个例子：看着客户尝试订阅 100 个席位，失败，然后离开产品。如果引导流程出问题，用户可能永远无法达到激活。如果仪表盘开始显示不一致的数据，用户可能会对整个系统失去信任。

这就是为什么我们的智能体不仅检查新功能是否符合其工单要求。它们还会浏览仪表盘、尝试集成、走通订阅流程，并测试登录和引导路径。这些流程并不是产品能做的所有可能的事情。它们是那些一旦出问题代价足够高、值得在每个拉取请求上重复验证的流程。

并非产品的每个部分都值得昂贵的智能体验证，但最重要的百分之一到百分之五通常值得。

这就是 AI 智能体评估的实用版本。它不是“让智能体永远探索整个应用”。而是“把智能体指向最重要的流程、需求和风险”。

机会在空白处

这项工作最深刻的教训是，上下文工程仍然很难。即使在 2026 年，复杂的智能体工作流也不会仅仅因为模型能力强就能开箱即用。它们需要规划、委派、限定范围的上下文、可靠的验证和安全的执行环境。

好消息是，大多数团队不需要发明新的真相来源。他们已经有规格说明。他们已经有代码。他们已经有预览环境。机会在于把这些资产连接成一个验证循环，帮助团队信任智能体产出的东西。

这也是为什么我不认为答案只是为想象中的场景生成数百个测试。测试有用，但最重要的场景往往已经在团队计划的工作中描述过了：产品规格、设计、工单，以及客户实际使用的关键流程。可执行规格从这一意图出发，然后对照运行中的产品进行检查。

对于初创公司和工具团队来说，这也是市场变得有趣的地方。大型编码智能体正在快速改进，但它们留下了空白。最好的机会往往在于团队需要专门层的地方：验证、工作流集成、安全性、报告或产品特定的评估。

这就是我思考可执行规格的方式。它们不只是更好的文档。它们是一种把产品意图转化为智能体可以行动、测试并向人类报告的东西的方式。

如果你想看完整演示，包括架构决策、失败、安全权衡和问答，你可以观看录像。