目录
从可靠的 Agent 编程到规模化开发与组织治理，构建百倍生产力的软件交付制度。
导读
卷一：可靠的 Agent 编程（1→10x）
- 02A
意图对齐：Vibe Coding 为什么失败
如果你曾经有过当"甲方"外包工作给其它团队的经验，无论是软件开发、还是新家装修，你大概率会有一个明确的感受：无论你请到的外包团队水平有多么高超，外包任务的推进仍然会缓慢而痛苦，因为瓶颈从来就不在外包团队的能力，而是确保团队完全理解了你...
- 02B
用结构传达意图：分层与维度
上一节诊断了三种 vibe coding 的失败模式：早期指令被挤出注意力范围，前后矛盾的指令没有优先级，compaction 主动删除信息。这三个问题有一个共同的结构性原因：意图活在对话里。
- 02C
迭代出一份可执行的规约
前面两节建立了一个方法论框架：信息要分层，每层有三个维度，层与层之间用交叉验证检测漂移。这一节讲拿到这个框架之后，面对一个具体的需求，你实际上怎么操作。
- 02D
实践：AILock-Step Feature Workflow
前面几节建立了规约的方法论框架：信息分层、三个维度、交叉验证、迭代循环。这些概念回答了"为什么"和"是什么"。这一节回答"在真实项目里长什么样"。
- 03
验证：确保代码忠实于规约
上一章的 OKR 案例里，spec 经过两轮迭代修正，13 条 acceptance criteria 和 5 条 business rules 全部定义清楚。Agent 根据这份 spec 生成了 12 个后端文件、4 个前端文件。...
- 03A
测试基建前置：把规约变成可执行约束
测试是 spec 的可执行形式。验收标准写的是自然语言，测试把它翻译成机器能运行的断言。这个翻译必须在第一行业务代码之前完成，这样 Agent 从执行的第一步开始就有反馈信号：这一步是否忠实于 spec。
- 03B
Code Review：补位测试覆盖不到的意图漂移
测试验证的是行为：spec 说的功能，代码做到了吗。但代码中还有一类问题，行为层面完全正确，测试全绿，意图却在悄悄偏离。Code review 的工作就是捕获这些测试的盲区。
- 03C
实践：AILock-Step 的验证链路
前面两节建立了原则和机制。这一节用 02d 的 OKR 系统案例继续，展示这些机制在 AILock-Step Feature Workflow 框架中怎么落地。02d 展示了 spec 从一句话到可执行文档的全过程。这里接着看：spe...
- 演进
演进：规约与验证的持续迭代
引言定义了 harness 的两个原则：闭环控制和持续演进。前两章建立了闭环，用规约定义意图，用验证确认执行。但我们还没有触碰第二个原则。
- 回顾
卷一回顾：从闭环到演进
三章读下来，Agent 开发和传统开发之间的结构性差异应该已经从一组模糊的症状变成了可以诊断的问题。意图丢失不再是"Agent 不够聪明"，而是 context 中缺少了显式的 spec。验证失败不再是"测试没写好"，而是验证的锚点对...
卷二：规模化 Agent 开发（10→100x）
- 04
规约：让意图能被并行分发
卷一里 spec 是一份共享工作台。你和一个 Agent 在这份工作台上来回。你写方案，它执行，你审核，你修改。所有意图对齐都在这个来回里完成。
- 04A
规约规模转变：人类脱离循环
想一下你在卷一里怎么和 Agent 做事。你打开对话，让 Agent 读一份 spec，让它按照 spec 写代码。你在旁边盯着。它写到某个函数的时候需要处理错误，选了返回 null。你觉得这里应该抛异常，你打断它，说"这个函数错的时...
- 04B
设计原则：自包含
上一节说到卷二要把原本对话承载的东西都装进 spec，让它变成一份独立的载体。这一节回答一个具体的问题。载体应该长什么样。什么样的载体才能真的支持多个 Agent 独立执行。
- 04C
产出方式：可判定决策驱动
上一节推出的结论是：卷二的载体规模比卷一大一个数量级。承载几千个决策，每个决策带推理、边界、边缘情况，块之间保持冗余，块间的一致性还要能维护。这样一份载体，产出方法是什么。
- 04D
实践：博客系统审核队列
前面几节讲了载体的原则和产出方法。这一节用一个真实项目走完全程。看粗略意图怎么在多轮共同产出里变成一份满足原则的载体。
- 05
验证：当人不再能兜底
卷一里验证的最后一道是人。测试查行为，code review 查意图，人对项目的理解补前两者的漏。三层配合工作，人在第三层做兜底。
- 05A
验证责任转移
上一章讲了 spec 从工作台变成载体。同一条物理事实（执行时人不在每个子空间的现场）对验证也起作用，方向不同。载体解决的是意图怎么在人不在场时被传输。验证解决的是产出怎么在人不在场时被判定可信。这一章从后一个问题开始。
- 05B
大规模验证的锚点
上一节推出验证责任要从人转移到机制。这一节问一个更具体的问题：机制承担什么责任才能可信。
- 05C
三层机制：硬门禁、软门禁、集成验证
从两个漂移地点推出机制的具体形态。代码与载体块之间的漂按机制性质拆两层，一层用脚本，一层用模型。载体块之间的漂独立成一层，用跨块行为的预演机制。三层加起来在两个地点上都有专门机制，失效边界两两互补。
- 05D
实践：博客审核队列的验证链路
原则和机制都已经清楚。这一节用规约章建立的博客审核队列的载体走一遍完整流程。前半段展示三层机制怎么从载体派生加人判定失效边界建起来。后半段展示建成的机制跑一遍五份产出，抓到三种漂移。整个流程沿用规约章的共同产出框架。
- 演进
演进：harness 必然演化
到上一章结束，harness 已经建成。载体承载完整意图，三层机制在两个漂移地点上都有覆盖，五个 Agent 并行工作产出可以合并。这一整套东西一旦跑起来，看起来就是完成品。
- 回顾
卷二回顾：迭代的harness系统
三章走下来，卷一里的三个诊断都出现了新的形态。意图丢失原来是 spec 没写出来，现在是载体的块之间失去一致性。验证漏了原来是测试没写好，现在是三层机制的某一层失效边界跟实际范围偏了。harness 腐烂原来是文档跟不上代码，现在是 ...
卷三：治理百倍速的组织
- 06
组织重构：当 Agent 改变了协作的前提
卷二解决的是个人效率问题。一个人指挥多个 Agent 并行，个人产出可以达到几十倍。但当团队里有几个人都开始这样做的时候，一个新的瓶颈出现了：团队的分工和流程是为人类执行速度设计的，它扛不住 Agent 的产出速度。
- 06A
为什么旧结构失效了
传统团队按功能分工：前端两人，后端三人，QA 一人。这种结构的隐含假设是每个人的产出能力大致相当，工作量可以按人头均分。当 Agent 让个人产出差异从两倍拉大到十倍，这个假设就不成立了。同一个级别的两个后端工程师，一个用 Agent...
- 06B
瓶颈转移：从代码到组织
传统软件团队的瓶颈在执行层：代码写得不够快，功能交付赶不上需求。Agent 消除了执行瓶颈之后，新的瓶颈浮现在组织层。review 队列堆积，reviewer 的时间成为稀缺资源。部署窗口为人类节奏设计，一天两次的发布频率扛不住 Ag...
- 06C
让流程匹配 Agent 速度
Code review、部署流水线、测试流程、发布审批，这些流程在人类开发速度下是质量保障机制。Agent 的产出速度把它们变成了吞吐瓶颈。但不能因为它们变慢了就一刀切地去掉，每个流程当初存在都有其质量理由。
- 07
角色重定义：从执行者到治理者
团队里最好的工程师已经几乎不写代码了。他们设计规约，搭建验证体系，管理 Agent 舰队，定义模块边界和接口契约。但他们的 title 还是 Senior Engineer，JD 上写的是"设计和实现软件系统"，绩效考核还在数代码产出...
- 07A
围绕治理重新设计角色
当 Agent 接管了执行层，工程师的日常工作从"写代码实现功能"变成了"设计和维护 Agent 高效执行的环境"。这个环境包括规约体系、验证框架、Skill 库、上下文工程策略、反馈基础设施。维护这个环境的能力，和写出高质量代码的能...
- 07B
用机制替代人际协调
张三的 Agent 重构了支付模块的接口，李四的 Agent 还在用老接口调用。以前张三会在站会上提一句"我今天要改支付接口"，李四听到就知道先别动相关代码。这种非正式协调几乎零成本，依赖人类"听到之后记住并调整行为"的能力。Agen...
- 演进
演进：组织资产与新护城河
传统软件公司的核心资产是两样东西：代码和人。