规范之重：AI 时代为何"大致目标"不再够用
在关于 AI Agent 的讨论中，一个观点反复出现：详细的规范文档已是过时的负担。给模型一个粗略的目标，让它自行探索，发现问题再修复——听起来高效，却隐藏着真实的成本。
旧世界的权衡与新问题
初看起来，简短的提示词廉价且诱人——它能立即启动实现。但随之而来的是修正循环：审核&查验输出、澄清意图、要求修改、重新测试、发现下一个缺口，周而复始。最终仍然需要有人判断结果是否符合真实目标——这个人成了"神谕"。
另一端是完全形式化规范：编写验收标准、契约测试或行为驱动开发（BDD）场景 upfront 成本显而易见，但下游成本结构完全不同——因为更多"神谕"职责变成了可执行代码。测试每次检查相同的条件，不会疲劳、不会被催促、不会在午餐前五分钟变得乐观。
真正的权衡不在于规范好与坏，而在于最小总成本落在何处。对大多数 Agent 工作流来说，答案在中间某处：足够的结构约束工作范围、足够的示例使意图具体、足够的可执行检查让审核&查验不再是猜测。
零规范不是"智能且精简"，只是代价被隐藏在了氛围编码里。
瓶颈移位了，但没有消失
软件工程的核心从来不是打字，甚至不是产出代码。它关乎：决定什么应该存在、什么永不能发生、哪些权衡是重要的，以及当问题触及现实世界时"完成"意味着什么。
过去，团队通过人力摩擦来发现缺失的规范。评审者注意到边缘情况、QA 发现无人描述的路径、高级工程师在脑中携带一半真实需求并在一次次会议中转化出来。这些都不优雅，但确实迫使模糊性浮出水面。
Agent 改变了这一点。它们使实现大幅降价且提速——这意味着一个需求不明确的想法，可以在任何人真正认同系统应该做什么之前，就变成一套看似合理的系统。旧世界中，模糊需求撞上的是人的缓慢；Agent 世界中，模糊需求撞上的是机器速度。
这就是规范突然再次变得重要的原因。它一直很重要，只是过去我们用实现成本作为粗粒度的强制函数，并把结果称为"流程"。
光写规范不够
这是最常被跳过的部分。人们往往以为流程很简单：写规范，然后让 Agent 实现。缺失的那一步才是昂贵的。
规范本身需要审核&查验。
即使一份严谨的规范也可能以熟悉的方式失败：自相矛盾、只覆盖愉快路径而对重试、限速或部分失败语焉不详、描述听起来精确却无法真正被验证。有时规范精确到了错误的方向——写了你想说的，而不是你实际想的。
当 Agent 忠实地执行了一份有缺陷的规范，诊断失败变得更难。实现看起来可能连贯，甚至能通过你提供的检查——但真正的问题在上游，在规范本身，修复意味着同时回滚代码和推理。
因此，规范验证值得单独列入成本清单。在实现开始前，需要有人提出几个直白的问题：
- 规范内部是否一致？
- 对当前任务来说是否足够完整？
- 哪些部分可测试？
- 我们仍在依赖人类判断的地方在哪里？
- 哪些失败模式因为所有人默默假设而缺失了？
Agent 可以帮助完成规范验证，但前提是你让它做的事比"写需求"更有用。那个提示通常产生的是精心包装的迷雾。更有效的提示需要具体得多——在规范草案完成后，可以将其交给另一个 Agent 并要求它主动攻击结果。
即使是这样简单的工作流，也能降低"让规范值得人类判断"的总成本。
多 Agent 系统需要更强的契约
单个 Agent 处理小型、边界清晰的任务时，往往能从宽松指令中恢复。反馈环紧密、影响范围本地化，人类在它偏离时通常能轻易发现并纠正。
多 Agent 系统则是完全不同的问题。一旦一个 Agent 的输出成为另一个 Agent 的输入，解释性偏差开始叠加。Agent B 不知道 Agent A 误解了 10% 的需求——它只是将输出视为既定事实并继续前进。当人类看到结果时，最初的错误可能已埋藏在多层看起来胜任的工作之下。
到了这个阶段，规范不再是单纯的指导文件，更像是一份契约。
这份契约需要的不仅是一段意图声明。它需要模式定义、不变式、允许的模糊性边界、验证规则和明确的失败行为。在许多场景下，它还需要契约测试、类型化接口和机器可检查的交接格式。交接本身就是产品的一部分——这不如人们期望的那样光鲜，但更接近现实。
这也正是 BDD 和可执行验收测试的用武之地。它们的真正价值不仅是方法论本身，而是将部分"人类神谕"职责迁移到了可重复的事物中。当行为足够稳定到可以精确描述时，可执行规范往往比又一轮人工审核&查验更划算。
规范应有保质期
团队还容易犯另一个错误：不断在规范曲线上加码，仿佛更多文字总是更安全。至少对当前模型而言，答案是否定的。
Chroma 在上下文方面的研究 揭示了问题的第一层：随着输入增长，模型性能可靠性下降，即使在简单任务上也如此。在编码项目中还存在第二层问题：你塞进上下文的设计文档、示例、计划、注释、工单和旧验收标准越多，哪些是指令、哪些是产物的边界就越模糊。
核心建议
- 不要把"零规范"当成高效——它只是把成本转嫁给了审核&查验与修正循环。
- 在实现前增加规范验证环节——用另一个 Agent 或人类主动攻击草案，发现内部矛盾和缺失的失败模式。
- 多 Agent 场景下将规范视为契约——需要模式、不变式、可测试的验收条件和类型化接口，而非仅一段意图声明。
- 规范需要定期精简——过长或过旧的上下文会降低模型可靠性，定期清理已过期的设计决策和工件。
当上下文成为噪音：多源规范的反效果
我不愿将这种情况称为"提示词注入"——至少不是安全意义上的那种。没有人试图攻击模型。这更像是自我诱发的指令漂移（self-inflicted instruction drift）。
问题的根源在于上下文中混杂了太多东西：最初的设计意图、过时的实现方案、半有效的示例、多个会话前生成的计划，甚至可能是一份早已过时的软件设计文档，里面描述的类早已不存在。在这种情况下，模型并非在读取一份规范，而是在对多个相互竞争的"真相来源"做平均。
当过度规范开始让模型困惑而非帮助它时，规范本身就从资产变成了负担。模型无法判断某个段落是活跃的需求、历史注记，还是代码早已替换掉的内容。
文档的生命周期：早期有用，后期必须精简
设计文档在早期有用，是因为代码还不存在。但随着开发推进，文档需要同步缩减。一旦接口、测试和约束条件成为具体实现，详细的构建计划就应该开始退出舞台。
真正值得保留的，是代码本身难以表达的内容：业务逻辑、非目标（nongoals）、安全约束、外部契约，以及那些不希望通过试错被重新发现的不变式。至于那些只是用 prose 重复描述类和方法已做之事的内容，删掉就好。
否则，你最终会得到两份规范。人类会在 code review 中抱怨，模型则往往会同时服从两份——而这两份可能相互矛盾。
API 设计如何让代码成为规范
事情也有更乐观的一面。某些代码库比另一些更快达到"代码即规范"的阶段，API 设计是重要原因。
如果内部 API 将行为隐藏在惯例、弱类型参数、隐式初始化和泛化错误之后，模型就无法将代码当作规范。它只能从分散的文档和反复试错中重建规则——这对人类效率很低，对模型更糟。
反过来，结论同样成立：一个拥有显式命名、任务级方法、强类型、可读验证、有用示例和可操作错误提示的 API，给了模型一个可以立足的具体支点。模型若能检查表层接口、理解方法行为、明白何种输入合法、不靠猜测就能从错误中恢复，代码本身就能承担更多规范职责。
这正是 AI 友好 API 设计理念的实际价值所在：
- 显式可发现性优于隐式惯例
- 方法应与真实任务对齐，而非强迫模型穿越十几个脆弱步骤
- 类型和验证应展示合法输入的样貌
- 错误信息应指向下一步修复方向，而非仅宣告失败
- 内省机制和代码示例帮助模型从已有代码库中学习 API 形态
- 性能透明度同样重要——API 若不给出线索，模型会毫不犹豫地为高开销调用写出"正确但灾难"的循环
这些原则不只适用于公共 SDK，同样适用于内部服务边界、库客户端、仓库抽象层，乃至于大型单体仓库中的辅助类。API 越容易发现和检查，模型就越容易将代码视为权威规范，而无需将更多 prose 塞入上下文。
规范投入的策略取决于工作类型
我强烈相信：没有唯一正确的规范数量。答案取决于你在做什么类型的工作。
小型边界清晰的任务
对于这类任务，甜蜜点通常是结构化意图（structured intent）：目标、几个示例、非目标（nongoals）和明确的验收标准。这通常足以让模型保持高效，同时不会让准备工作比任务本身还重。
确定性领域：CRUD、API 集成、数据转换
这类 domain 容易约束、容易测试，规范的边际效益更快回正。更多规范很快就能自我偿还，因为它减少了反复 review 和返工。BDD、契约测试、可执行验收标准在这里最有价值。
探索性工作：架构选型、研究综合、全新产品思路
这类工作规范最优点再次左移。过度规范可能扼杀让模型发挥价值的灵活性。此时更应指定边界而非结果：什么是必须为真、什么是不能发生、需要什么证据、以及哪些决策仍需人类介入。
多智能体流水线
一旦涉及多 Agent 协作，规范最优点再次右移。每个 Agent 之间的边界都需要契约。没有契约，你协调的不是系统，而是一摞叠加的解释，然后祈祷它们相互抵消。
贯穿四类场景的共同规则很简单：在扩大实现规模之前，先验证规范本身是否有效。
Agile 和 XP，哪些经验仍然有效
模型不会让 Agile 或 XP 变得无关。它们只是让有用的部分更容易从人们早已在忍受的部分中分离出来。
首先被淘汰的是那些主要用来按小时协调人类工作的仪式。每日站会、膨胀的 backlog 仪式、以及那些自信程度远超信息量的估算，不会因为代码是模型写的就变得更强。实际上，模型能如此迅速地改变任务形态，老旧的工作估算变得比以往更快失效。这不是说规划消失了——而是说规划必须停止假装自己在代码慢的时代拥有同样的成本预测舒适度。
Agile 中真正存活下来的是反馈逻辑：短周期仍然重要、纵向切片仍然重要、用户或利益相关者 review 仍然重要、可工作的软件仍然优于进展剧场——因为模型能以惊人速度生成大量令人信服的错误。
XP 的存活状态更好，因为它本质上是让学习紧贴代码。测试先行思维仍然重要，因为当实现成本降低时，可执行检查变得更有价值。持续集成仍然重要，因为每个模型的变更都需要一道关卡。重构仍然重要，因为模型能生成通过少量测试却让下月维护者绝望的结构——机器在这里没有自尊心，它会以完美自信生成一团乱麻。
Pair programming 改变了形态，但核心价值从未消失。我始终相信，设计判断需要紧挨着代码生成——无论是人类工程师直接和一个编程 Agent 协作，还是一个模型生成代码、另一个模型以更窄的 brief 进行审核&查验，形式虽有不同，本质是一样的。配对编程真正的价值，从来不是两个人坐在咖啡馆里键盘和谐共舞，而是在代码定型之前获得快速的设计反馈。
小版本发布同样经受住了时间考验，原因或许没那么浪漫：当 Agent 能够以极低成本完成大规模改动时，接受大版本差分也变得廉价——这恰恰是个糟糕的主意。审核&查验、回滚和问题诊断在小批量场景下都更容易执行。一个短生命周期的功能分支，远比四千行巨无霸分支更容易理解和推理。
褪去的是作为"心理安慰"的方法论，留下来的是作为"错误检测"的方法论。敏捷和极限编程在最辉煌的年代，做得最对的一件事就是：让团队发现自己对问题理解不足的代价变得更低。这项使命没有改变，只是 AI Agent 时代移除了几个借口，同时提供了高速犯错的新方式。
真正的杠杆
Agent 式开发的承诺是真实的。Agent 可以让实现成本大幅下降，但一旦代码变得廉价，规范（specification）和验证（verification）反而成为项目成败的决胜之地。
真正能拿到最大杠杆的团队，不是那些规范写得最少的团队，而是那些清楚知道何时三个要点足够、何时需要正式契约、何时契约必须变成可执行代码的团队。
Agent 能力在持续进化，但决策权依然在我们手中。
评论