为什么AI编程智能体仍然需要明确的规格说明

本文原载于Markus Eisele的新闻通讯《The Main Thread》，经授权转载。

开发者社区中正流行一种心智模型：智能体足够聪明，能自己搞清楚事情，因此繁重的前期规格化是不必要的官僚开销。只需宽松描述目标，让智能体探索，然后边走边修正。快速、灵活、现代。

这种观点是错误的。不是因为智能体能力不足——它们往往很出色——而是因为账算错了。你并没有消除成本，而是将其推迟、碎片化，并使其更难发现。

让我们看看实际的分类账。

两个极端，两种隐藏成本

一个极端是最小化规格：你宽松描述意图，智能体自由解释，工作立即开始。前期人力成本接近零。但你不会立即看到的是下游累积的成本：修正循环，每次携带代币成本和人类重新投入时间。审查周期中，人类成为每个输出的神谕——决定智能体产生的是否正是原本意图。当不符合时则返工。

另一个极端是全面正式规格：测试驱动开发（TDD）、行为驱动开发（BDD）、Gherkin场景、验收标准在代码运行前锁定。前期人力成本真实可见。但下游验证成本完全不同，因为测试就是神谕。通过或失败。人类无需亲自评估每个输出——规格自动、重复、不疲劳地做这件事。

你实际上是在交换支付时间和货币。最小化规格前置代币成本，后置人类判断。全面规格前置人类努力，后置几乎为零——自动验证不随运行次数扩展。

当将总成本对规格完整性作图时，两条曲线呈现U形。曲线的最低点——即最佳点——位于结构良好的验收标准或BDD场景附近。不在零规格，也不在40页的正式需求文档。

一旦绘制完整的分类账，陷阱便显现。最小化规格看起来很便宜，只有在下游返工未计入时。多智能体工作将最低点进一步右移，因为漂移在交接中累积。

老问题始终是规格

软件工程中真正的挑战始终是规格。

不是类型、语法，甚至不是抽象架构。困难在于达成一致：应该存在什么？绝不应发生什么？哪些权衡重要？系统允许忘记什么？当世界比工单更混乱时，“完成”意味着什么？

智能体并未消除那个问题。它们使其更加可见。

几十年来，我们将规格问题隐藏在会议、积压工作、代码审查、QA周期、事故复盘和高级工程师的私人心智模型中。大量软件工程从来不是“写代码”。而是将未充分指定的想法通过足够多的摩擦，迫使缺失部分暴露出来。

智能体减少了生成代码的摩擦。这很棒。但这也意味着缺失部分在更晚的阶段浮出水面，因为系统现在可以在任何人真正决定实现应意味着什么之前，产生一个看似合理的实现。

在旧世界中，模糊的需求撞上人类的缓慢。在智能体世界中，模糊的需求撞上机器的速度。

当实现变得更便宜时，瓶颈并未消失。它转移到规格和验证。

但编写规格只是问题的一半

几乎每种对此权衡的框架都遗漏了：在你将规格交给智能体之前，必须对其进行验证。

这听起来显而易见，但实际上被系统性地忽视。

编写规格时——即使非常小心——它可能以在智能体执行前不可见的方式失败。可能内部不一致：两个相互矛盾的需求，孤立看都不明显错误。可能不完整：充分覆盖快乐路径，但对第三方API返回429时只字不提。可能技术上正确但不可测试：描述的行为无法机械验证。最阴险的是，可能正是你写的，但不是你本意的。

智能体忠实地执行有缺陷的规格，产生难以调试的东西。它通过了所有给定的检查。问题不在实现——而在上游，规格本身。现在修正循环更昂贵，因为你必须撤销的不仅是代码，还有推理。

因此，规格验证是一个独立的成本类别，位于“写规格”和“运行智能体”之间。它询问：此规格内部一致吗？是否足够完整以有用约束智能体，但不过度约束有效解决方案？它是否实际描述了我们打算构建的东西？

该验证工作是人力时间，或是智能体时间，或理想情况下两者皆是——但它不为零。一旦你诚实地将其记入分类账，图像就会改变。

智能体如何编写规格

还有第三种策略被这两极框架系统性地忽略：使用智能体来编写和验证规格，然后使用实现智能体来执行它。

这改变了规格侧成本结构。不是繁重的人力来产生验收标准或BDD场景，而是规格起草智能体从粗略意图产生第一版。规格验证智能体——具有不同角色和系统提示，可能带有搜索或领域知识——压力测试该草稿的一致性、完整性和可测试性。测试编写智能体将存活的声明转换为可执行检查。你审查结果，这比从头编写更快。

重要的是，智能体不应仅仅“编写需求”。那会产生精美的迷雾。

一个有用的规格编写智能体更像一个怀疑的产品工程师，而不是速记员。它应命名假设。应分离目标与非目标。应产生示例和反例。应说明哪些需求可机械测试，哪些仍依赖人类判断。应识别懒惰实现可能遗漏的失败模式。应询问什么是有效解决方案必须不变的。

最好的提示不是“给我写一份规格”。更接近于此：

起草能让另一个智能体安全实现的最小规格。包括假设、非目标、验收标准、边界情况、可观察结果和开放问题。然后标记哪些部分可成为自动测试，哪些需要人工审查。

然后你运行不同的智能体针对输出：

攻击此规格。找出矛盾、歧义术语、隐藏依赖、不可测试的声明、缺失的失败模式，以及实现能通过书面标准但仍违反意图的地方。

最佳点不是智能体撰写的散文。而是经过人类批准、智能体起草、对抗性审查的规格，并尽可能让神谕可执行。

智能体并未消除对规格的需求。它们可以降低向曲线有用部分移动的成本，其中规格足够完整以指导实现，但仍由人类审查。

这并未使规格验证消失。它改变了谁做以及成本如何。结构性要求——实现智能体运行前必须验证规格——仍然存在。变化是智能体现在承担了部分工作。

BDD如何部分解决此问题

行为驱动开发（如果做得好）将规格编写和规格验证折叠到同一工件中。Gherkin场景同时是意图描述和可执行测试。你可以针对骨架实现立即运行规格，并观察描述是否产生一致行为。使规格可执行的行为强制了散文验收标准所没有的一种验证——某些歧义必须在场景运行前解决。

这就是为什么总成本曲线的最低点不仅仅反映减少的返工。它反映了验证内置于格式中的结构优势。

当BDD将判断从重复人工审查转移到可执行神谕时，它就发挥了作用。这就是为什么其最佳点出现在足够稳定可测试的行为附近。

问题是仍然有人必须写好场景。Gherkin可能写得差。业务语言规格可能以BDD框架无法捕捉的方式模糊，因为歧义存在于语义而非语法。格式有帮助，但不能替代纪律。

多智能体管道破坏一切

如果你在良好边界任务上运行单个智能体，未充分指定是可以恢复的。反馈环路紧密，修正是局部的，成本有界。

多智能体管道完全是另一类问题。

当智能体A的产出成为智能体B的输入时，A的任何解释性漂移都会加剧到B的执行中。B不知道A稍微偏离轨道。B努力工作且自信地建立在错误基础上。当产出到达人类时，错误已通过多层看似一致的工作被放大并掩盖。

这使盈亏平衡点决定性地移向规格。在多智能体系统中，规格不仅是单个执行的指导——它是智能体间的协调契约。该契约越不精确，每个智能体的解释自由度引入的方差就越大。你希望智能体之间有强类型接口，而不是松散的对话式交接。

对于多智能体工作，x轴不再只是“我们指定了多少？”而是“交接契约有多强？”最低点移向类型化契约和可执行验证器。

该契约的验证相应地更重要。如果协调智能体的规格有缺陷，你不会只有一个智能体做错事——而是所有智能体同时做着不同错误的事。

方法论中幸存的内容

那么，这是否使我们关于协调软件团队所学的一切都过时了？

不。但它确实改变了哪些部分是承重的。

作为仪式的敏捷很麻烦。人们向空中背诵状态的站会、产生虚构精度的估算仪式、主要功能是安抚管理层认为不确定性已被驯服的工单仪式——智能体不需要这些。老实说，人类也不需要。

作为反馈哲学的敏捷幸存。短周期幸存。工作软件胜过抽象进展幸存。客户协作幸存。当现实说话时计划应弯曲的坚持幸存。如果有变化，智能体使之更重要，因为它们能快速产生大量令人信服的错误。反馈环路必须更紧，而不是更松。

极限编程（XP）甚至更好地幸存。测试优先思维幸存，因为在实现更便宜时，可执行神谕更有价值。结对编程演变为人类-智能体配对，但基本思想保持不变：保持设计判断接近代码生产。持续集成幸存，因为每个智能体变更都需要快速、公正的门禁。重构幸存，因为智能体能产生工作代码，但局部正确而结构平庸。小型发布幸存，因为大的不可见增量是人类和智能体都迷失的地方。

可能消失的是作为大型群体协调戏剧的方法论。

[原文为控制成本而截断]