起因
很多团队买了 Cursor、上了 Copilot，发现程序员写代码确实快了。但一问交付数据，PR 堆积、review 排队、bug 率没降反升。1.5 倍工程师是普遍体感，离十倍百倍差得远。
AgentsZone 社区跟上百位开发者交流后得出了结论：差距在制度。用人类时代的旧流程指挥 Agent，就像用马车交规管高速公路。Harness Engineering Playbook 把这件事系统化了：从单 Agent 可靠编程，到多 Agent 并行开发，到组织级治理，三卷搭出完整的阶梯。
Playbook 内容密度很高，直接丢给团队看大概率没人看完。下面这份课程把最核心的东西压缩成半天能消化的节奏，五个模块，每个模块解决一个具体问题。
第一课：用规约驱动 AI 改造功能和修 Bug
Vibe Coding 为什么走不通
大多数人用 AI 写代码的方式，本质上是 Vibe Coding。凭感觉写 prompt，接受结果，觉得”看起来对”就过了。这是个开环系统：发出指令，接受产出，没有验证。
开环在一次性脚本上勉强能用，放到持续迭代的项目里，随机性就不可接受了。衡石科技的刘诚忠分享过一个观察：“代码生成速度彻底击穿了人类审查带宽。“代码产得快，审得慢，审不过来就是债务堆积。
Playbook 给出的解法是闭环。规约定义”对”是什么，自动化验证检查产出是否符合意图，偏差即时发现并纠正。两个原则贯穿全书：闭环保证每一步可靠，演进保证系统越来越好。
修 Bug 的正确姿势
遇到 bug，不要直接告诉 AI “修一下排序 bug”。Agent 忠实执行输入，模糊的地方会变成随机决策。你写”修一下排序”，Agent 可能改了排序、改了数据类型、还顺手重构了组件。
正确做法是先花两分钟把 bug 结构化成规约：
## Bug: 订单列表排序错误
**预期行为**: 金额字段按数值大小降序排列
**当前行为**: 按字符串字典序排列（"99" 排在 "100" 前面）
**影响范围**: src/components/OrderList.tsx 的 sortFunction
**验证标准**:
- [100, 20, 3] 应排序为 [100, 20, 3]
- ["100", "20", "3"] 当前错误排序为 ["100", "20", "3"]
- 修复后排序结果应为 [100, 20, 3]
然后让 Agent 按照规约执行修复，约束它只动涉及排序的部分。写好的验证标准直接变成测试用例，跑测试，过就过，不过就打回去。
给现有功能加新逻辑
加新功能和修 bug 的原则一样：先写 spec，再让 Agent 执行，最后用测试收口。区别在于新功能需要额外定义清楚跟现有代码的边界：
## Feature: 订单列表日期筛选
**新增文件**: src/hooks/useDateFilter.ts
**修改文件**: src/components/OrderList.tsx（仅筛选相关 props 和回调）
**不动**: 排序逻辑、样式文件、API 调用层
**验收标准**:
- 默认不筛选，显示全部订单
- 选择"最近 30 天"后只显示该范围内订单
- 清除筛选恢复全部显示
这几点缺一不可。“新增文件”告诉 Agent 在哪里写代码。“修改文件”限定改动范围。“不动”防止 Agent 过度修改。验收标准是最后的闸门。
跟 AI 协作，人的核心工作从”写代码”变成了”写规约 + 验收产出”。代码生成是最便宜的环节，设计和验证才值钱。
第二课：测试用例设计与自动化验证
为什么测试成了唯一的解法
AI 产出速度太快，人类 review 成为瓶颈。传统靠人肉 review 保质量的路走不通了。刘诚忠把这个做法叫”饱和式测试”，用 AI 补齐 100% 甚至冗余的测试用例来驾驭复杂度。
Playbook 卷一的核心概念是”测试基建前置”：把 spec 变成可执行的约束，在代码还没写的时候就把验证标准定好。
让 AI 生成测试用例清单
拿”日期筛选”功能的 spec 做例子。先让 AI 读 spec，列出需要覆盖的测试场景。要求覆盖正常路径、边界值、异常输入，每个用例一句话描述输入和预期输出，只列场景不写代码。
AI 会列出代码层面的边界值（空值、undefined、超长字符串）。但业务语境下的异常场景还得人来补：
- 跨时区怎么处理？服务器时间和用户本地时间不一致怎么办？
- 筛选状态下翻页，第二页要不要保持筛选？
- 30 天内没有订单时，空状态怎么展示？
AI 擅长技术边界，人擅长业务边界，两份清单合并才完整。
验证闭环
把确认后的测试清单交给 AI 写成测试代码，跑一遍，通过的提交到 CI 做回归保护。整个链路是这样的：
Spec → 测试用例清单 → 测试代码 → CI 自动执行 → 回归拦截
这条链路一断，Agent 就会积累错误。因为 Agent 会忠实复制代码库里已有的模式，包括坏模式。合并后的代码成为后续生成的参考集。没有持续验证，系统会自我强化地滑向退化。
Playbook 反复强调一件事：验证链路必须有，而且要持续运转。这是整个方法论的地基。
第三课：模型选型
被问得最多的问题：做前端、做设计、做产品，用什么模型最好？
2026 年上半年，没有哪个模型在所有场景都碾压。但有明确的选择逻辑。
代码生成和重构（含前端）
Claude Opus/Sonnet 在结构化代码生成上稳定性最好，尤其适合需要遵循现有代码风格的场景。GPT-4o 在创意性生成上有时更灵活。前端组件开发两个都能用，差别在 10-15% 左右。别纠结选型，先固定一个主力模型跑通流程。等流程跑顺了再对比，否则永远在换模型，永远在调 prompt。
产品设计和需求分析
把 PRD 结构化、把模糊需求拆成可执行 spec，Claude 更稳。它更擅长遵循结构化模板，输出也更一致。
体验设计和交互
这是多模型协作的场景。用大模型把用户旅程和交互逻辑结构化，用专门的视觉模型生成设计稿，再用代码模型把设计稿转成组件。目前没有单一模型能端到端做好这件事。
视觉设计
图像生成用 Midjourney 或 DALL-E 3，设计系统和组件规范用 Claude/GPT 来维护。别指望一个模型搞定所有视觉设计工作。
第四课：AI 研发流程哪些能砍
传统流程里有一堆环节是为人类执行者设计的，Agent 不需要。
能砍的
站会。Agent 不需要每天同步进度，它的进度在 .status 文件里。
迭代计划会议。Agent 不需要参与 Sprint Planning，给它 spec 和任务列表，它就按顺序执行。
详细的任务分配会。不需要把大需求拆成前端、后端、测试任务再分别分配。给 Agent 一个完整的 spec，它自己能端到端走完。
代码 review 中的格式和风格检查。交给 linter 和 CI。
砍不了的
需求定义。Agent 对模糊需求的处理方式是随机决策，比人类差得多。PRD 的质量直接决定产出质量。
验收标准。每条 spec 都要附带可执行的验证条件。没有验收标准的 spec 就是给 Agent 发了一张空白支票。
架构决策。Agent 能写代码，但不能替你决定系统的架构方向。模块边界、API 契约、数据模型，这些必须在 Agent 上手之前定好。
嘉宾在分享中提到一个很真实的瓶颈：“现在的瓶颈已经不在代码生成，需求供给跟不上 Agent 的进度，变成 TO 每天追着 CPO 要需求。“Agent 干活太快，需求定义成了新的卡点。
第五课：组织调整与一把手怎么跟上
团队结构正在瓦解
刘诚忠在分享里说了一句很直白的话：“Leader 已经没办法 Leader 下属了，因为 Leader 可能还没下属会用 AI。”
传统基于角色协作的模式正在瓦解。前端、后端、QA、产品，各自负责一块，通过站会和评审会同步进度。AI 帮助下，一个人就能打通全流程。衡石内部做了实验：设立 AI Pod，里面的人不受传统管理约束，以代码提交强度和结果为准，形成了一种小型精英组织。
Playbook 卷三提出了三角色分工模型：
- PO（产品负责人）：写高质量、自包含的 PRD，定义”做什么”
- QO（质量负责人）：定义验收标准和 Benchmark，确保”什么是对的”，通过对抗性机制约束 AI
- TO（技术负责人）：编排 Agent 工作流，负责”怎么做”
这三个人都不写代码。写代码的事交给 Agent。他们的核心工作是定义问题、验收结果、编排流程。
嘉宾分享里提到一个银行流水分类引擎的案例：4.5 个人替代了原来的 63 人。人员结构发生了剧变，送走了外包团队和无法驾驭 Agent 的初级分析师，转而聘请能定义问题的资深精英。形成了”少数精英指挥智能体军团”的终局形态。
最大的坑：黑灯工厂
嘉宾专门讲了”怎么搞砸 AI Coding”。最大的坑是完全无人化的”黑灯工厂”思维。无人化会导致代码风格不一致、理解偏差产生垃圾产出。看起来每个人都在省事，实际上系统在失控。
嘉宾的结论很清楚：“不要相信’挂机写代码’的鬼话，工程永远是一件难受且充满对抗的事情。“
一把手怎么办
对于不在一线写代码的管理者，跟上 AI 变化有几件实际的事可以做。
自己用。不写代码没关系，用 AI 做日常的事：写方案、做分析、整理会议纪要。体感这个东西不用不会有。不需要成为程序员，但需要理解”跟 AI 协作”到底意味着什么。
看交付物，不看过程。传统管理关注过程：每天站会、周报、Sprint Review。Agent 时代关注产出：spec 写清楚了没有，测试覆盖率多少，CI 绿不绿。管理重心从过程监控转向结果验收。
投资测试基建。这是性价比最高的投入。测试基建好了，Agent 的产出质量有保障；测试基建差，Agent 产得越多，债务积累越快。衡石的做法是饱和式测试，用 AI 补齐测试用例到 100% 覆盖。
找到你的 AI Pod。在组织里划出一个小团队，不受传统管理流程约束，按 Agent 时代的节奏工作。让他们跑通整个流程，再把经验扩散到其他团队。
关注决策智能。衡石的 Jarvis 决策中枢解决了一个实际问题：AI 记忆碎片化。通过结构化记忆（文档、代码、历史问题合集）建立共识，让 AI 知道”病历本和历史”。这个思路也适用于组织内部的知识管理。
收尾
半天时间能做的有限。当场变成 100 倍工程师不现实，但可以建立正确的认知框架：跟 AI 协作的核心工作是定义问题；闭环比开环可靠，规约和验证必须配对；测试基建是地基，没有地基别盖楼；组织要适配新的工作方式。
回去之后建议用 Playbook 卷一作为深入学习的材料。先把规约和验证两件事做到位，再考虑多 Agent 并行和组织级转型。
刘诚忠在分享里说：“现在是最坏的 AI 创业时代，因为每个人手里拿的都是加农炮，只能互轰。“竞争确实在加剧。但加农炮也得有人会瞄准，光有火力不够。这套课程教的，就是瞄准。