Part 0 · 公开分享：给 AI 套上缰绳（60 分钟）

Part 0 · 公开分享：给 AI 套上缰绳（60 分钟）#

把整本《Harnessing AI》压成一小时，让同行一次听懂 Harness Engineering 在讲什么、为什么非做不可、以及周一上班 可以从哪一行代码开始。

使用说明

这一部分不是一章独立的技术内容，而是整本书的 60 分钟公开分享版。 面向的是 对 AI 编码实践感兴趣的同行 —— 软件工程师、架构师、技术负责人， 大多数人用过 Cursor / Codex / Claude Code，但没专门做过 harness 系统设计。节奏是 8 段 × 约 7 分钟 + Q&A 4 分钟。

  • index.md（本文）—— 可直接通读的讲稿，讲者可以当"口水稿"用。

  • outline.md —— 分钟级 speaker outline，精确到每分钟讲什么， 含目标 / 钩子 / 可跳 / 别讲 / 深一层五段式。

  • slides.md —— 每页一张 slide 的大纲（每 ## 对应一张）， > 引用块是 speaker notes，方便复制到 Keynote / Google Slides 的 Outline 视图一次性导入。

  • ../_handson/13-one-hour-talk/SLIDES.md —— 已经排版好的 Marp 兼容版幻灯片（带讲者备注），可直接投影或导出为 PDF。

书中所有用到的概念、数字、引用，都指向后续章节里的某一章。 这一讲只给 主脊 —— 不陷入任何一个细节 —— 细节请回到相应 Part。

术语约定：讲稿里涉及 AGENTS.md / CLAUDE.md 兼容层 / SKILL.md / MCP / pre-commit / Bridle / Fence / Paddock / Groom / SDD / TDD / MDD / HarnessCard 这些概念时，保留英文原词。这些词 在书里都有精确定义，硬翻反而会丢掉它们的工程意涵。

F.0 · 开场（2 分钟）#

为什么今天站在这里#

一句话中心论点. 2026 年，AI 编码的杠杆点 从模型本身移到了 模型周围的环境；软件团队写代码的方式正在被这一转移重塑，而且 再不讨论一次，下一轮 code review 上很容易各说各话。

白板时刻. 在白板左边写一个大写的 "M"（Model），右边写一个 大写的 "E"（Environment）。画一个箭头从 "M" 指向 "E"，箭头上写 "2022–2024"；再画一个箭头从 "E" 指向 "M"，写 "2026"。说： 「过去我们想着怎么把模型调得更听话；现在我们想着怎么把环境建 得让一个普通模型也干不坏事。」

三条 2026 年的事实. 每条 15 秒：

  • OpenAI 的 Codex 团队，8 周内上线约 100 万行生产代码， 其中 0 行由人手写。

  • LangChain 团队 没换模型，只改了模型 周围的脚手架，就把 Terminal Bench 2.0 成绩从第 30 名冲进前 5。

  • Anthropic 在 权限弹窗、技能编写规范、MCP server 契约 上 花的工程时间，比花在模型权重上的多。

回书链接. 第 01 章《前言》及第 02 章《四阶段演进》。

F.1 · 起点：四个阶段（7 分钟）#

从 Prompt 到 Harness，为什么每一步都卡在下一步面前#

一句话中心论点. 工作工程师跟大模型协作的方式，在 2022–2026 年 间经历了 四阶段演化；每一个阶段都解决了上一阶段无法解决的问题， 也都有一个上一阶段观察不到的新问题。

白板时刻. 画一条时间轴，标四个节点：

2022–2024     2025          2025–2026       2026–
Prompt   →   Context   →   Skill       →   Harness
怎么问？    给看什么？    怎么把流程写下来？  造什么环境？

每一步的 主要人工制品：

  • Prompt：一条巧妙的提示字符串。

  • Context：一张检索 ／ 上下文图。

  • Skill：一份 SKILL.md 或 command 定义。

  • Harness：仓库本身 —— AGENTS.md ＋ 护栏 ＋ 钩子 ＋ 巡检。

两句要带走的话.

  1. 前三个阶段都在调「询问层」，Harness 阶段把干预点移到了「环境层」。

  2. 前三个阶段可以一个工程师单独做，Harness 必须以仓库为单位做。

一个要提防的误读. "Harness 就是 prompt 长一点。" 不是。Prompt 是 一次对话一次性塞进去的文本；Harness 是留在仓库里、下一轮智能体 也会读到、且违反就被机械拒绝的那一组制品。

回书链接. 第 02 章《四阶段演进》完整论证，尤其是 Stage 1 / 2 / 3 各自裂缝的那三段。

F.2 · 定义：Harness Engineering 是什么（7 分钟）#

一句话定义，五条「是」，五条「不是」#

一句话中心论点. Harness Engineering 是一门 刻意设计、运行、 演化 AI 编码智能体周围结构 的工程学科，目的是让它产出的软件 可验证、可观测、可理解。

白板时刻. 在 "一句话定义" 下面写三个竖排的字：

可验证   verifiable
可观测   observable
可理解   understandable

然后说：「这三词不是修辞，每一个背后都有一门四十年历史的工程学科。 我们马上讲。」

五条「是」（快念）.

  1. 面向智能体的规约 —— AGENTS.md ／ CLAUDE.md 兼容层 ／ SKILL.md ／ MCP server manifest，把它们当代码 review。

  2. 审批门与护栏 —— pre-commit 钩子、lint 规则、PR 强制评审、 CI 必过项。无论作者是人还是 AI，坏制品一律拦。

  3. 沙箱 —— 容器 ／ VM ／ 只读挂载 ／ 临时 worktree，让智能体碰 不到生产。

  4. 面向智能体的文档 —— runbook ／ ADR ／ skill 文件，智能体自己 能读懂，以减少环境幻觉。

  5. 度量与反馈面 —— 测试通过率、每轮成本、lint 违规数、 from-fail-to-green 时间，团队 每周 看一次。

五条「不是」（更快念）.

  • 不是 推理运行栈（那是 AI Engineering）。

  • 不是 ML 评测基准（那是输入，不是本体）。

  • 不是 IDE 插件（Cursor ／ Copilot 是客户端，harness 住在仓库里）。

  • 不是 智能体框架 SDK（LangChain ／ AutoGen 是砖块，不是房子）。

  • 不是 部署流水线（DevOps 接管于 "commit 合入之后"）。

归属检验. 如果一件制品塑造智能体 在 commit 之前 试图 产出什么，它属于 harness；如果它塑造 commit 之后 发生什么， 它属于 DevOps。

回书链接. 第 03 章《什么是 Harness Engineering？》，尤其是 03.1 一句话定义与 03.2 的「IS ／ IS NOT」归属边界。

PDCA × Harness：同一圈螺旋，只是「动手的」换了人#

一句话中心论点. PDCA（Plan–Do–Check–Act）没有过时；在 AI 编程工具 场景里，Plan 主要由规约与任务切分承担（AGENTS.md ／ ADR ／ issue triage）， Do 由智能体与人在编辑器里完成，Check 交给测试、 类型检查、lint、CI 与人工评审，Act 体现为 Groom —— 更新规约、 收紧钩子、补测试、必要时 恢复。四步每转一圈，马具与代码一起进化。

白板时刻. 画一个小圆环四格 P → D → C → A，在 D 格里写一个很小的 「AI」；外圈写一句：跑偏最常发生在 D 很快、C 很慢的团队。

规则 / 校验 / 恢复 —— 三道闸（各约 15 秒）.

  • 规则（Rules） —— 把「允许什么 ／ 禁止什么」写成 作者无关、 机器可读 的条文：AGENTS.md 路径约束、成本上限、pre-commit 策略。 重点是 可执行，不是口号。

  • 校验（Check） —— 在合入前用客观信号回答「这轮改动有没有破坏 不变量」：单测、契约测试、静态分析、schema 校验。校验是 PDCA 里 Check 这一象限里 最该先自动化 的部分。

  • 恢复（Recover） —— 承认智能体有时会把局部改坏：小步提交、 可回滚分支、git revert、从已知 绿色 commit 重启会话上下文。 没有恢复预案的 Do 等于赌博。

一句收口. 防跑偏不靠「盯紧模型」，靠 P 足够清楚、C 足够硬、 A 真正改规则；恢复不是丢脸，是马具的一部分。

回书链接. 第 09 章《运行一具马具》（工作流、钩子、恢复心智）， 第 07 章三护法与 Check 的对应；Fence ／ Paddock 清单见第 08 章。

Agent Loop：驯服时把手放在哪一层#

一句话中心论点. 智能体跑偏通常不是「模型性格不好」，而是 Agent Loop 的某一层缺规约、缺护栏、缺观察。看清 loop，才知道该改 prompt、改 context、收紧工具，还是补仓库里的 harness。

白板时刻. 画一条最小 loop，不要展开成系统架构图：

用户输入 → context → decision → tools → observation
              ↑          memory / skill / controller          ↓
              └────────────────── output ─────────────────────┘

五个把手（各约 15 秒）.

  1. 输入契约 —— 任务边界、验收标准、禁止事项；决定 agent 从哪里出发。

  2. context / memory —— 检索什么、注入多少、何时裁剪；决定它以为自己 知道什么。

  3. tools / sandbox —— terminal、API、MCP、文件写权限；决定它能对世界 做什么。

  4. skill / controller —— 分解步骤、循环节奏、何时停下求证；决定它按 什么顺序做。

  5. harness / evidence —— AGENTS.md、钩子、测试、审计记录、恢复路径； 决定它在什么制度下写你的代码。

驯服顺序（给听众的行动建议）. 工具跑偏时，先看 trace：输入是否含糊、 context 是否污染、工具是否太宽、observation 是否被忽略、输出有没有证据。 再用 F.4 的 3×4 矩阵问：哪一格缺了、哪一格只是写了没人看。 真正能让 agent 长时间少人工纠正的，不是某个神奇提示词，而是一个清楚的 Autonomy Envelope：允许它自己跑的范围、必须停下来的条件、以及失败后 怎么恢复。

少即是多：不要把整座图书馆塞进 context. LLM 已经知道很多通用知识； 工程师要补的不是「更多背景」，而是 收敛方向、规定边界、给出判据。 好的 harness 像一份总分总结构：开头给目标和边界，中间按步骤 progressive disclosure（需要时才展开细节），结尾要求证据、测试和 下一步。塞得越满，越容易把 agent 诱导到无关细节里；立规矩、分层披露， 反而让它更稳定。

回书链接. 第 03B 章《AI Agent 与编程工具的结构》；第 08 章《马具解剖》； 附录 F《工程师落地手册》。

（与 F.3 的接头）三护法是 PDCA 里被顶到前面的「规约 + 证 + 观」#

一句过渡：SDD 把「想清楚再干」塞进 Plan；TDD 把 Check 自动化；MDD 让 Act 有据可查。 —— 下面 F.3 展开三护法的因果翻转。

F.3 · 三护法：SDD → TDD → MDD（7 分钟）#

为什么有了智能体以后，因果顺序反了#

一句话中心论点. Harness Engineering 不发明新学科，它 征召三门 旧学科，把它们 重新排序、前置到智能体动笔之前：SDD → TDD → MDD。 传统软件工程没有失效；在 AI 编程时代，很多原则反而更亮了，因为 agent 把模糊需求、缺测试、缺监控这些旧问题放大得更快。

白板时刻. 画两条因果链，上下对照：

传统软件工程 ：   test   →   implement   →   observe
(人写代码)          TDD         (人)           MDD

AI 辅助工程  ：   specify   →   test     →    observe
(智能体写代码)     SDD          TDD           MDD

为什么翻转？ 在人写代码时代，测试是第一份可执行规约，人会 顶着它改到合为止；在智能体时代，人写的主要制品移到更上游 ——AGENTS.md ／ CLAUDE.md 兼容层 ／ skill 文件。如果规约含糊， 智能体会非常自信地幻觉出一种行为，这时写的测试只会把幻觉钉住， 而不是抓住它。

不是推翻，是复用. 需求澄清、模块边界、代码评审、TDD、CI、可观测性、 postmortem，这些老方法没有退场；它们只是从「约束人」变成了 「约束人 + agent 的共同环境」。AI 编程让工程速度上升，也让坏习惯的 传播速度上升，所以传统软件工程里那些朴素原则 —— 小步提交、先定义 done、测试先行、可回滚、可追踪 —— 现在更值钱。

三护法各一句.

  • SDD — Specification-Driven Development. 可理解性护法。 把意图变成智能体能读的规约（AGENTS.md ／ ADR ／ prompt 规约）。

  • TDD — Test-Driven Development. 可验证性护法。 先写那条 "还红着" 的测试，作为智能体对规约的解释之证伪面。

  • MDD — Metric-Driven Development. 可观测性护法。 把每轮 turns-to-green、每月成本、lint 违规数等指标写下来，每周看。

一个要提防的误读. 「我们已经有 CI 了啊。」CI 只是 TDD ／ MDD 的 牧场。它在合入那一刻才发声；Harness 的问题是在键盘按下那一刻 发声。

回书链接. 第 07 章《三大护法》，特别是「为什么因果 顺序要翻转」那一节。

F.4 · 骨架：3 × 4 矩阵（7 分钟）#

一张表，十二格，装下整个框架#

一句话中心论点. 画不出来的框架是口号，不是分析工具。本书的 分析骨架是一张 3 × 4 矩阵：三行 ＝ 三护法，四列 ＝ 四区域。

白板时刻. 直接画这张表：

              缰绳           护栏         牧场          梳理
              Bridle         Fence        Paddock       Groom
              (写前引导)     (写时拒绝)    (写后边界)     (维持本身)

SDD (说)      AGENTS.md      prompt-lint  acceptance   sources-of-truth
                             schema 校验   gate         索引

TDD (证)      pre-edit       pre-commit   CI / 集成     flaky
              钩子导引        钩子拒绝     测试          隔离

MDD (观)      北极星指标      成本上限      SLI 面板      指标元审
              放在显眼处      触顶拒调用    红线          季度轮替

四区域各一句.

  • Bridle（缰绳） —— 智能体敲第一个键之前 看什么、听什么。

  • Fence（护栏） —— 不管作者是谁，一律拒绝 坏制品。

  • Paddock（牧场） —— 智能体 可以撒欢的那块地 的边界。

  • Groom（梳理） —— 维护 马具本身 的那些重复性工作。

三个配对的学术框架（各 10 秒）.

  • CAR ／ HarnessCard（学术参考）：Control ／ Agency ／ Runtime 三层分解，配一份标准化披露格式。本书案例研究打分的骨架。

  • Thoughtworks 三分法：context engineering ＋ architectural constraints ＋ garbage collection。最像 DevOps 的那一种。

  • LangChain 五件套：prompts / tools / middleware / memory / harness。 对单个 agent 实例最细的切法。

回书链接. 第 08 章《马具解剖》的"出处"与"05.全景"两节。

F.5 · 四个案例研究的教训（7 分钟）#

同样的矩阵，落到四个真实项目上会怎样#

一句话中心论点. 同一张 3 × 4 矩阵，落到 运行时、技能库、 工作流、闭源产品 这四类项目上，会凸显 不同的强项与不同的风险。

白板时刻. 画一条横轴，从左到右四个点：

OpenHarness   Superpowers   lazy-scrum-team   Claude Code
运行时 + 沙箱  技能库        工作流编码         闭源产品

每一个案例一句话.

  • OpenHarness（第 10 章，港大 DS Lab，开源） —— 唯一一份 "就像读过第 08 章之后才写的" 开源参考实现。十个子系统整齐对 应到矩阵格子；Runtime 层 Paddock 尤其强。警醒：它是参考实现， 不是你的运行时。

  • Superpowers（第 11 章，Joseph Vincent，开源） —— OpenHarness 的哲学反面。只出技能库，不出运行时。三十几份 SKILL.md， 强在 SDD × Bridle。警醒："光靠技能能不能做我们的马具？" —— 不能，少了 Fence 与 Paddock。

  • lazy-scrum-team（第 12 章，开源 skill 包） —— 把 Scrum 角色 与交接本身当马具。三件可复用的模式：Artefact State Model、 Rework Matrix、Hard vs Soft Gates。

  • Claude Code（第 13 章，Anthropic，闭源；经由张汉东《马书》分析） —— 本书唯一的闭源案例。马具职责分布在 bundled prompt ＋ hooks 契约 ＋ skills 系统 三处。警醒：闭源意味着你看得到行为但拿不到源， 分析结论永远带一个有效期标注。

一句带走. 矩阵是尺子，案例是用它量出来的刻度；不是照抄答案， 而是选一个最接近自己技术栈的参照。

回书链接. 第 07–10 章全部。每一章末尾都有一张填好的 HarnessCard， 可直接当"别人是怎么打分的"的参照。

F.6 · 自证其身：Lazy AI Coder 四幕（7 分钟）#

本书对自己的那座仓库做了一次审计，然后改了五处#

一句话中心论点. 如果这套框架连书的宿主仓库自己都打不分、 改不动，那它就是错的。 本书第 15 章把 3 × 4 矩阵扣在 walterfan/async-harness-book 自己头上，做了一场四幕实盘。

白板时刻. 画四个方块横向排开：

Act 1       Act 2         Act 3         Act 4
审计        短板          实盘修复       度量 delta
(Audit)     (Shortcomings) (Fixes)       (Measure)

四幕各一句.

  • Act 1 · 审计. 填一张初始 HarnessCard，落在矩阵的 左下角 ——SDD × Fence、SDD × Groom、TDD × Fence、MDD × Bridle ／ Groom 是五格最弱的。不是烂仓库，是「有普通可生存技术债」的仓库。

  • Act 2 · 短板. 列出五个具体短板，每一个都 打上严重度、 证据指针、落到哪一格。

    • 缺 make prompts-lint（SDD × Fence）

    • MCP 工具 schema 没对齐 handler（TDD × Fence）

    • 没有 LLM 调用的成本可观测面板（MDD × Bridle）

    • ……

  • Act 3 · 修复. 四笔修复 commit 进 main；reproduce.sh 可复现。

  • Act 4 · 度量 delta. 重新打分：

    • SDD 均值 1.75 → 3.00（+1.25）

    • TDD 均值 2.00 → 2.75（+0.75）

    • MDD 均值 1.50 → 1.50（+0.00，没动）

    • 总分 1.75 → 2.42（+0.67）

一个要提防的误读. 「HarnessCard 就是虚荣分数。」不是。只要你 把评分尺（附录 D）公开、把证据指针公开、把变化 delta 公开，它就 不是虚荣分数。"分数涨了但事故没少" ——那才是 vanity delta。

回书链接. 第 15 章《Lazy AI Coder 四幕剧实例》与附录 D《HarnessCard 模板》。

F.7 · 周一上班怎么办：30 ／ 60 ／ 90 天清单（7 分钟）#

最重要的一条：你不用一次性做完十二格#

一句话中心论点. 本书最重要的单一主张：你不必一次上 12 格。 你挑 一格，上它；然后上它所在的 整行 或 整列；再走一 次完整的 HarnessCard 评审。

白板时刻. 画三个里程碑：

Day 1–30        Day 31–60           Day 61–90
一格            一行 或 一列         一次完整评审
one cell        one row or column   full HarnessCard review

每一段的推荐切入点.

  • Day 1–30 · 一格. 推荐从下面三者挑一个：

    • SDD × Bridle —— 提交一份基于样本的 AGENTS.md。便宜，之后 每一轮都赚。

    • TDD × Fence —— 装一条 PreToolUse 钩子，测试红的时候拒绝 写文件。单兵也能受益。

    • MDD × Fence —— 给 LLM 调用加一个每会话成本上限。过线就 拒绝新调用。

  • Day 31–60 · 一行 或 一列. 把第一格扩到所在的整行（同一护法下 补齐四个区域）或整列（同一区域下补齐三个护法）。

  • Day 61–90 · 一次完整评审. 按附录 D 的评分尺打一张 HarnessCard， 公开 delta。

三条要提防的误读（快念）.

  • "Day 30 我们就搞定了"陷阱 —— 没人给马具本身排维护班，90 天后 那格的分数从 +1 掉回 +0.3。

  • "Groom 以后再说"陷阱 —— 一开始就没把梳理列入范围；没有 Groom 的马具不是马具，是装饰。

  • "凑齐了再发布"陷阱 —— 等到十二格都 ≥ 3 分才敢上线。错了。 你要的是「一格上线 ＋ 公开承认其余十一格的分数」，而不是 「全格就绪的神话」。

回书链接. 第 16 章《从这里出发，往哪走》12.2「30／60／90 天行动清单」与其配套的陷阱框。

F.8 · Q&A ／ 收尾（4 分钟）#

三句要被记住的话 ＋ 三道常见问#

三句要被记住的话（逐字念）.

  1. Harness Engineering 不是给流程再加一层；是在一组已经过载 的清单中 提取出那一小撮会机械拒绝坏工作的制品，其余皆为 装饰。

  2. SDD → TDD → MDD，顺序不能乱；在 AI 辅助时代，规约是人写 的主要制品，测试是对智能体解释的证伪面，度量是闭环信号。

  3. 不要一次做 12 格；挑 1 格，30 天内上线，60 天内扩到一行一列， 90 天内公开一次 HarnessCard。

三道常见问（每问 60–90 秒）.

  • Q：这跟我们现有的 CI 流水线有什么区别？

    • A：CI 是 TDD ／ MDD 的 牧场。它在合入那一刻发声；马具在 键盘按下那一刻发声。如果你家 CI 周五晚上才抓到周二早上可以 在 commit 时抓住的 bug，你缺的是 Fence，不是又一条 CI 规则。

  • Q：三个护法一定要全上吗？

    • A：不用。30／60／90 清单说得很明白：Day 30 上一格就算一步实 质性进展。单兵先做 TDD × Fence；团队通常从 SDD × Bridle 起步。

  • Q：这不就是 DevOps 的重新包装？

    • A：不是。归属检验很简单：塑造 commit 之前 的，是马具；塑造 commit 之后 的，是 DevOps。Harness 比 DevOps 早发生一拍。

收尾画面. 把开场那张 M → E 图擦掉一半 —— 只留下 E。说： 「从今天起，讨论 AI 编码时，先从环境开始。回到你的项目后，谁愿意做 Day 30 的那一格？」

回书链接. 附录 A（FAQ）、附录 B（术语表）、附录 D（HarnessCard 模板）、附录 E（CLAUDE.md 兼容样板）。

F.App · 给讲者的附加说明#

时间表#

00:00–00:02   F.0 开场
00:02–00:09   F.1 四阶段演化
00:09–00:16   F.2 定义
00:16–00:23   F.3 三护法
00:23–00:30   F.4 3×4 矩阵
00:30–00:37   F.5 四个案例
00:37–00:44   F.6 Lazy AI Coder 四幕
00:44–00:51   F.7 30/60/90 清单
00:51–00:55   F.8 Q&A 收尾
00:55–01:00   缓冲 / 追问

讲稿使用建议#

  • 投影比例. 每节 1–2 张幻灯片即可；矩阵表格那一张（F.4） 与 30 ／ 60 ／ 90 里程碑那一张（F.7）建议单独成页。

  • 白板优先. F.0、F.1、F.3、F.4、F.6 都带有「白板时刻」—— 它们比幻灯片更能让听众跟着你的因果链走一遍。

  • 延伸阅读. 现场可以把附录 C 的阅读单当作 handout 打印一张。

  • 现场动手（可选，把 90 分钟场做成工作坊）. F.8 之前加一段 「每人填一张 HarnessCard 的 SDD × Bridle 格」，评分 0–5，证据 写自己仓库里那份 AGENTS.md 或它的缺席。

一键资源链接#

  • 本书仓库：walterfan/async-harness-book

  • 配套幻灯片（Marp 兼容，带讲者备注）： _handson/13-one-hour-talk/SLIDES.md（见同目录 README.md 的 三种用法说明 —— 直接阅读、Marp 导出、粘贴进 Keynote／PPT）

  • 分钟级 speaker outline： 同目录下的 outline.md

  • 每页一张 slide 的文字大纲： 同目录下的 slides.md

  • 30/60/90 清单：_handson/16-where-we-go-from-here/checklist-30-60-90.md

  • HarnessCard 模板：附录 D

  • CLAUDE.md 兼容样板：附录 E

  • Agent Loop 与 Autonomy Envelope：第 03B 章

  • 工程师落地手册：附录 F

  • 精选阅读单：附录 C