O'Reilly快报：代理开发中规格的恰当程度
内容提要
在代理开发中，详细规格并非过时，而是关键。代码成本降低后，难点在于定义“正确”并可靠验证。零规格或过度规格均非最优，应根据任务类型调整：确定性任务需更多可执行契约，探索性任务则侧重边界。多代理系统需强接口契约，规格需定期精简，API设计可辅助。验证规格优先于扩展实现，敏捷与XP的反馈逻辑仍适用。
延伸解读
规格的平衡点
文章指出，代理开发中规格并非越多越好，也非越少越好，关键在于找到总成本最低的平衡点。零规格会导致反复修正，而过度规格则增加前期成本。对于确定性任务（如CRUD、API集成），应增加可执行契约；对于探索性任务（如架构设计），则侧重边界约束。多代理系统需要强接口契约，而单一代理的小任务只需结构化意图。
规格验证的重要性
文章强调，规格本身需要被审查和验证，否则代理可能忠实执行有缺陷的规格，导致问题难以诊断。建议在实现前检查规格的一致性、完整性、可测试性，并明确依赖人工判断的部分。可以利用代理生成最小规格草案，再由另一个代理攻击性审查，以降低达到有效规格的成本。
上下文膨胀与规格过期
文章提到，随着上下文增长，模型性能会下降，且过多的设计文档、旧注释等会导致指令漂移。因此，规格应有“过期日期”，在代码实现后，详细设计文档应精简，只保留代码无法表达的部分（如业务理由、非目标、安全约束）。否则，代理可能同时遵循多个冲突的“真相源”。
API设计作为规格载体
文章认为，良好的API设计能让代码本身成为规格，减少对散文式文档的依赖。显式命名、强类型、可读验证、有用错误信息等，使代理能更容易地理解和使用API，从而减少猜测和错误。这适用于内部服务边界和公共SDK，有助于代理将代码视为权威规格。
Q&A
在代理开发中，为什么详细规格仍然重要？
因为代码成本降低后，难点转移到定义“正确”并可靠验证。零规格会导致昂贵的修正循环，而详细规格（如验收标准、契约测试）可以将部分人工判断转化为可执行检查，降低总成本。
代理开发中，零规格和过度规格各有什么风险？
零规格会导致昂贵的修正循环，因为需要人工反复审查和澄清意图；过度规格会增加前期成本，并可能因上下文过长导致模型性能下降（如上下文腐烂），且过时的文档会混淆模型。
如何验证代理开发中的规格？
在实现前，需要检查规格的内部一致性、完整性、可测试性，并明确依赖人工判断的部分。可以使用两个代理：一个起草最小规格，另一个攻击它，找出矛盾、歧义、隐藏依赖、不可测试的声明和缺失的失败模式。
为什么多代理系统需要更强的接口契约？
因为一个代理的输出会成为另一个代理的输入，解释漂移会累积，错误会被放大。因此，需要定义模式、不变量、验证规则和显式失败行为，并使用契约测试、类型化接口和机器可检查的交接格式。
规格为什么需要过期日期？
因为随着上下文增长，模型性能会下降（上下文腐烂），且过时的设计文档、注释等会与当前代码冲突，导致指令漂移。因此，当接口、测试和不变量实现后，应删除冗余的散文，只保留必要的业务理由、非目标、安全约束和外部契约。
API设计如何帮助代理将代码视为规格？
通过显式命名、任务级方法、强类型、可读验证、有用示例和可操作错误，使API易于发现和检查，代理就能从代码本身获取规则，减少对散文的依赖。
对于不同类型的任务，规格的合适程度有何不同？
对于小型有界任务，通常只需结构化意图（目标、示例、非目标、验收标准）；对于确定性任务（如CRUD、API集成），需要更多可执行契约（BDD、契约测试）；对于探索性任务（如架构选项、研究综合），应指定边界而非结果；对于多代理流水线，每个边界都需要契约。
敏捷和XP的哪些原则在代理开发中仍然适用？
反馈逻辑、短周期、薄垂直切片、客户评审、测试优先、持续集成、重构、结对编程（人机或模型间）和小批量发布仍然重要。它们帮助快速发现错误，而仪式性部分（如每日站会、过度估算）会减弱。
