卷一回顾：从闭环到演进

三章读下来，Agent 开发和传统开发之间的结构性差异应该已经从一组模糊的症状变成了可以诊断的问题。意图丢失不再是"Agent 不够聪明"，而是 context 中缺少了显式的 spec。验证失败不再是"测试没写好"，而是验证的锚点对准了代码而不是规约。体系腐烂不再是"文档没人维护"，而是缺少把文档演进变成工程动作的流程。

更重要的是，这三个问题都有了具体的操作方式。你有了一套从意图到 spec 的结构化方法，有了以 spec 为锚点的验证体系，有了用 change 包管理文档演进的流程。这些不是理论框架，OKR 案例从一句话的需求走到了 26/28 项合规检查通过，又从第一个 feature 的成功演进到了第二个 feature 的 delta 合并。

卷一建立了 harness 的完整定义：用闭环保证每次执行可靠，用演进保证闭环本身不退化。三章各解决一个问题，合在一起构成一个可持续运转的体系。

规约解决的是意图传达。Agent 只处理 context 中存在的信息，未写出的意图等于不存在。信息分层（vision → architecture → feature → task）让不同抽象层级的知识各有归属，三个维度（意图、验收、约束）确保每一层的关键问题都被显式回答。Spec 不是一次性文档，而是人和 Agent 之间意图对齐的持续载体。人是意图的唯一裁判，因为意图只存在于人的脑子里。

验证解决的是执行确认。验证的锚点是规约，不是代码。测试验证行为正确性（spec 说的功能代码做到了吗），code review 验证语义完整性（代码有没有偏离 spec 的框架）。两者覆盖不同维度，缺一不可。验证必须前置、过程中、模块化，因为 Agent 的漂移在执行过程中持续发生，等到最后再验证意味着面对几十个问题同时爆发。

演进解决的是体系维护。Spec 会过时，这是结构性必然。每次迭代都在制造 spec 和代码之间的漂移，过时的 spec 让闭环保护一个错误的目标。Change 包流程把文档演进变成可重复的工程动作：每次变更有 spec 级的完整描述，创建时和合并后各跑一次验证，归档保留决策链路，同步检测兜底残留漂移。

三章不是三个独立工具。规约为验证提供锚点，没有好的 spec，验证不知道在验证什么。验证为演进提供信心，能验证 spec 的一致性，才敢做增量更新。演进为规约续命，规约只有持续更新才能继续作为验证的锚点。三者构成一个循环，任何一个环节断裂，其他两个都会失效。

这套体系的执行主体是人。人写 spec，人做 review，人判断意图是否对齐，人维护文档的演进。在当前阶段，一个人顺序开发几个 feature，每个环节的成本都可控。但成本随项目规模增长。Feature 数量从个位数增长到几十个时，交叉检查、文档维护、同步检测的人工投入不再是每个 feature 半小时能覆盖的。这不是方法论的缺陷，而是 human-in-the-loop 模式的天然边界。

卷二的问题是：怎么让 Agent 承担更多的闭环维护，而人退到更高层的监督位置。从坐在 Agent 面前一步一步指导，到设计任务让 Agent 自主完成，再到同时调度多个 Agent 并行推进。这个转变的前提是卷一建立的闭环和演进机制。没有规约，Agent 的自主执行就是 vibe coding 的自动化。没有验证，Agent 的产出无法被信任。没有演进，体系在第一次迭代后就开始腐烂。放手的前提是有东西在兜底。

Harness Engineering Playbook · AgentsZone Community