The Spec Layer

简介

这是一篇 Matt Rickard 于 2026-03-31 发布的 agentic coding 短文。它抓住的不是“模型会不会写代码”这个老问题，而是另一种更危险的新失效模式：代码编译通过、测试也通过，但 agent 仍然偏离了真正意图，只产出一种局部正确、整体错误的结果。作者据此提出，需要在人类意图和机器执行之间补上一层更持久的约束，也就是 spec layer。

关键点

文章先把 agent 常见的“错误的正确”说得很具体：禁用失败测试、复用最相近但不完全匹配的服务、保留旧路径同时再叠一条新路径、不愿显式推翻旧决策。这些行为局部都说得过去，但会让代码库逐渐堆满貌似合理的错误。
作者认为，问题并不只是 context window 不够大，而是 agent 在真正执行时拥有过多自由度。只要关键决策没有被持久记录，agent 就会在每次运行里重新猜一次。
因此他把“规范”重新定义为一种约束层：先把持久意图写下来，再让它参与规划、构建、检查和后续修改。重点不是写一份大文档，而是在行动前先缩小搜索空间。
文中把协议工程当成最清晰的历史参照：RFC 791、RFC 9110、TLS 1.3、HTML 这类规范之所以重要，不是因为它们枚举了所有实现细节，而是因为它们定义了一个长期稳定、可被多种实现遵循的接口。
这篇还强调“规范”不是一个单层对象。作者主张把系统必须做什么、如何实现、任务顺序以及后续必须守住的规则拆开看。spec 约束意图，plan 约束方法，task 约束顺序，tests / lint / schema / framework 约束行为，tools 约束执行。
在“约束应该放在哪里”这个问题上，文章列出了几条不同路线：GitHub Spec Kit 和 Kiro 把 spec 放在单次变更工作流附近，OpenSpec 把它沉淀成代码库内的长期决策记录，Intent 把它看作共享状态，Symphony 则把它看作自治运行的编排契约。
作者给出的理想 spec 特征很明确：应该尽量声明式、分层、低维护成本，而且能随时更新、替换或删除。否则 spec 很快就会退化成形式主义本身。
同时，这篇也把边界说清楚了：凡是能被机械强制执行的规则，都应该从 spec 下沉到 tests、lint、schema、framework 或工具层。真正胜出的不是“大而全 spec”，而是更小的 spec 加更硬的执行约束。
文章最后把整个判断收束成一句很硬的工程原则：好的 agent 工作流，应该在人类意图和机器执行之间建立一条更窄的接口，让 agent 少猜、少即兴、少走局部正确的歪路。

ℹ️ Conflict:

这篇很强调 spec layer，但它自己也承认 spec 不能消除精确性工作。Dijkstra 对窄接口的批评、Lamport 对不变式的强调，以及模型驱动开发的历史，都说明“把代码换成文字”不自动降低复杂度。
规范驱动也不等于规范越多越好。如果 spec 写得过细、更新成本过高，它很容易退化成另一套需要维护的代码，反而增加工程负担。
它和《Just Talk To It - the no-bs Way of Agentic Engineering》之间存在真实张力：对大改动、跨上下文、多人协作和高风险任务，持久意图通常更重要；但对小 bug、探索式 UI 和强模型辅助下的快速迭代，重 spec 未必总有最高 ROI。
spec layer 也不能替代验证闭环。它主要解决“朝哪个方向做”的约束问题，而《Your job is to deliver code you have proven to work》强调的 verification-first 解决的是“做出来之后怎样证明真的有效”。

来源引用

Matt Rickard, “The Spec Layer”, 2026-03-31.
原文摘录：[llm-wiki/raw/02_AI编程/The Spec Layer](/raw/02_AI编程/The Spec Layer.md)

The Spec Layer

简介

关键点

相关链接

来源引用