Spec Growth Engine 提出合并阻塞的规范检查

Hartwig Grabowski 的规范增长引擎提案针对两个常见的 AI 辅助开发问题：“上下文爆炸”和“静默规范-代码漂移”。该框架的执行钩子是一个漂移门，当代码与机器可读规范偏离时，它会阻止合并。

规范增长引擎提出了上下文爆炸和规范漂移的解决方案

AI 编码代理可以快速交付可用功能，但规范增长引擎提案认为，这种速度掩盖了两个后期成本高昂的失败模式：“上下文爆炸”和“静默规范-代码漂移”。该论文由 Hartwig Grabowski 于 2026 年 6 月 25 日提交，框定了核心问题为范围管理而非模型智能。

第一个失败模式是上下文爆炸，输出质量随着代理被迫在整个代码库上推理而下降，且上下文窗口充满了无关的文件、依赖项和历史记录。第二个是静默规范-代码漂移，迭代的代理驱动的变化不断出现，而规范保持不变，导致不匹配，只有在错误或回归迫使进行意图的法医重建时才会显现出来。

对于加密团队来说，这个提案更少涉及开发者的工作舒适度，而更多关注运营风险。协议代码库、交易所后端和链上自动化堆栈已经在严格的变更控制约束下运行。如果AI 代理加速变更而不加强执行，失败模式就不是“糟糕的代码”，而是未被追踪的偏差在审查中存活并被交付。

Spec Growth Engine被描述为四个相互关联的机制，直接映射到两种失败模式。它始于一个机器可读的规范图，这是一个结构化的规范格式，工具可以解析和检查。在提案中，规范节点将“合同”（组件承诺的内容）与“设计”（实现方式）分开，因此审查者和代理人对意图与实现有了更清晰的参考。

为了解决上下文爆炸问题，该框架引入了一个“脊柱”上下文组装器，将代理人的工作上下文范围限定到特定的“所有权路径”，而不是整个代码库。所有权路径是这里的边界概念：与组件或团队边界相关的代码库的定义切片，旨在使代理人的提示集中于其实际需要处理的内容。

垂直切片增长协议是序列层。它强制执行“最难优先”的开发任务排序，将最具架构定义性的工作推到前面，而不是让代理人磨蹭在简单的表面区域，直到最后再推迟艰难的决策，那时返工的成本更高。

强制执行杠杆是漂移门。它使规范代码的偏离成为合并阻塞条件，这意味着不匹配的代码在解决不匹配之前不能进入主分支。从机制上讲，这就是“我们尽量保持规范更新”和“管道拒绝发送漂移”之间的区别。

该论文将其定位为一种轻量级综合，而不是一种新的重量级方法，明确借鉴了包括Parnas的信息隐藏、C4架构模型、架构决策记录（ADRs）、行走骨架模式、反射模型和适应性函数在内的既有软件工程理念。它还明确表明自己旨在避免与重量级框架（如RUP（理性统一过程）和MDA（模型驱动架构））相关的开销。

短期问题不是组件是否可读，它们是可读的。问题是团队是否能够在不将“机器可读规范”变成另一个陈旧工件的情况下将其操作化，以及漂移门是否可以精确到足以阻止真实的偏离，而不会变成嘈杂的合并税。

证据缺口很简单：该数据包不包括任何实证结果、基准、采用数据或现实世界的部署结果。它也没有包括直接的链接到基础论文、其发表地点或任何超出“提交”声明之外的同行评审状态，提交日期为2026年6月25日。

这使得下一个信号异常具体。公开的论文和发表地点链接至少可以让构建者检查定义、假设和任何评估方法论。之后，首个有意义的验证将是发布的基准或案例研究，展示漂移门在实践中捕捉规范代码的偏差，或者脊柱上下文汇编器在大型代码库中减少上下文爆炸。

采用的信号可能是工具，而不是推文：机器可读的规范图的开源实现加上合并阻塞漂移检查，这些都可以插入常见的CI工作流程。如果这仍然是一个没有参考实现的概念框架，它将更像是一篇过程论文，而不是工程原语。

重要的阈值是漂移门是否可以做到严格且低噪声，因为这是唯一在截止压力下真正迫使行为改变的部分。通过所有权路径的范围上下文是对上下文爆炸的合理响应，但除非管道强制执行代理可以看到和接触的内容，否则它仍然是一种约定。

该框架的核心赌注是，AI编码的可靠性更多地与范围控制和执行有关，而不是更智能的模型。如果团队能够保持规范图的更新，以便漂移门可以被信任，那么该设置开始看起来像是一种操作控制，而不是文档仪式。