从这里出发，往哪走

一本不以清单收尾的书，就是一本不打算被拿来用的书。

16.1 —— 一页纸上的立论

本书的分析骨架，一页就装得下：三大护法 × 四区域 ＝ 十二格，每一格都是一件团队可以交付的制品。下表每一格都是一条 {ref} 链接，回指第 08 章里对应的 H3 小节。

	缰绳 —— 在下笔之前先掰方向	护栏 —— 拒掉不合格的活	牧场 —— 圈定智能体能跑的范围	梳理 —— 照看马具本身
SDD	SDD × 缰绳 —— 引导智能体的规约	SDD × 护栏 —— 在关卡处强制规约合法性	SDD × 牧场 —— 与规约相符的验收	SDD × 梳理 —— 让规约面持续鲜活
TDD	TDD × 缰绳 —— 先失败的测试作为给智能体的输入	TDD × 护栏 —— 拒绝红树 commit 的钩子	TDD × 牧场 —— CI 关卡与环境对等	TDD × 梳理 —— flake 维护与测试面演进
MDD	MDD × 缰绳 —— 真正在引导的那一个度量	MDD × 护栏 —— 成本上限与熔断器	MDD × 牧场 —— 发布 SLI 与 staging 浸泡	MDD × 梳理 —— 每周度量审计与仪表盘卫生

全部十二条 {ref} 链接都指向第 08 章中实打实的小节；读者点开任何一条，都会落在一件可用的制品与一则定义上。

16.2 —— 30/60/90 天行动清单

本书最重要的那一条主张是：你 不必 把十二格一次性全采纳。你挑 一格、把它交付、再把它所在的那一 列 或 行 交付，然后跑一轮完整的 HarnessCard 评审。下面是这三个子任务，带 hands-on 指针；独立副本放在 _handson/16-where-we-go-from-here/checklist-30-60-90.md。若你想直接把这套计划搬进团队会议，附录 F 的 附录 F —— 工程师落地手册 提供了一份更像工作手册的版本。

Day 1–30 · 一格

挑一格矩阵单元，为它交付一件制品，再拿附录 D 的 HarnessCard 评分尺跑一遍。

• SDD × 缰绳。 运行 agents-md-generate 做一次 repo discovery，再以 _handson/08-harness-anatomy/sdd-x-bridle/AGENTS.md.sample 为底，提交一份 AGENTS.md；与 SDD × 缰绳 —— 引导智能体的规约 相挂钩。

• TDD × 护栏。 以 _handson/08-harness-anatomy/tdd-x-fence/hooks.json 为底，装一条 PreToolUse 钩子；与 TDD × 护栏 —— 拒绝红树 commit 的钩子 相挂钩。

• MDD × 护栏。 采纳 _handson/08-harness-anatomy/mdd-x-fence/cost-cap.yaml 中那条"单次会话成本上限"；与 MDD × 护栏 —— 成本上限与熔断器 相挂钩。

Ford、Parsons 与 Kua [Ford et al., 2017] 提供了这件事的大框架：一次只上一条 fitness function，就已是一次真实的改进。

陷阱 —— 第 30 天 "我们搞完了" 的坑

一支团队在第 30 天交付了一格，庆祝、然后停下来。九十天之后，这格已经腐化——没有 Groom 任务被加上、没有评审节奏被建立、没有人署名持有这件制品。那个 +1 变成 +0.3，并在往 0 靠拢。为什么：单一格子是一粒种子，不是一茬庄稼。第 30 天的里程碑是为了证明这支团队 能 交付一件马具制品；第 60 天的里程碑则是为了证明这支团队 能让它活下来。跳过第二个里程碑的团队，季末拿到的还是当初那场马具剧场，只不过额外赔掉了一周工程师时间。解法：第 30 天的出口判据不是"制品已合并"，而是"这件制品有归属、有评审节奏、日志里至少有一次 refused 或 measured 事件"。没被用起来的格子是排练，不是演出。

Day 31–60 · 一行，或一列

扩展到完整一行（一位护法横跨全部四个区域），或完整一列（一个区域横跨全部三位护法）。

• 完整 SDD 行。 交付 _handson/08-harness-anatomy/sdd-x-*/ 下的缰绳 ＋ 护栏 ＋ 牧场 ＋ 梳理 四件制品。若是 monorepo，同时明确"nearest AGENTS.md wins"：根文件只放全局命令与索引，子包文件只放局部命令与边界。对应格子：SDD × 缰绳 —— 引导智能体的规约、SDD × 护栏 —— 在关卡处强制规约合法性、SDD × 牧场 —— 与规约相符的验收、SDD × 梳理 —— 让规约面持续鲜活。

• 完整护栏列。 交付 _handson/08-harness-anatomy/*-x-fence/ 下的 SDD ＋ TDD ＋ MDD 三道护栏。对应格子：SDD × 护栏 —— 在关卡处强制规约合法性、TDD × 护栏 —— 拒绝红树 commit 的钩子、MDD × 护栏 —— 成本上限与熔断器。

• 运行节拍。 采纳每周熵审计（_handson/09-operating-a-harness/entropy-audit.yml）与制品状态机（_handson/09-operating-a-harness/artefact-state-model.yaml）；这两件一起，把"梳理"那一行夯实 —— SDD × 梳理 —— 让规约面持续鲜活、TDD × 梳理 —— flake 维护与测试面演进、MDD × 梳理 —— 每周度量审计与仪表盘卫生。

Forsgren、Humble 与 Kim 的 DORA 度量工作 [Forsgren et al., 2018] 主张：季度节奏才是度量的合适单位；第 31–60 天就是你第一个季度的第二个月。

陷阱 —— 第 60 天 "一行还是一列？" 的瘫痪

一支团队在第 31 天时已经交付了一格，接下来三周全耗在一场委员会辩论里：是 一行 还是 一列？哪位护法？哪一区域？到第 60 天，第二件制品一件都没出；团队在回顾会上汇报"战略工作"。为什么：一行或一列，本身是一场"优化剧场"——任一方向都是真实改进，而"错误选择"（如果真有的话）在下一个季度都可救。选择时花掉的时间，就是没有交付的时间。解法：挑那个 最弱格子 最让你不好意思当众说出口的方向。如果今天把 AGENTS.md 给同事看你会脸红，就上完整 SDD 行；如果 CI 时不时挂、却没人去轮换那把能修它的密钥，就上完整护栏列。这个"尴尬测试"能在五分钟内解开这场瘫痪，并挑出那个原本就最重要的方向。

Day 61–90 · 一次生产级 HarnessCard 评审

在一份生产代码库上，用附录 D 的空白模板（见 空白模板）跑一次完整 HarnessCard 评审，合入至少一项由马具驱动的改进，并记录可度量的 delta。

• 打分。 把 空白模板 里那张十二格的空白 HarnessCard 填满 —— 每格给出 0–5 的分数与一行证据备注。用 _handson/15-lazy-ai-coder/HarnessCard-Act1.md 作为实例参考，跟 SDD × 缰绳 —— 引导智能体的规约、TDD × 护栏 —— 拒绝红树 commit 的钩子 与 MDD × 护栏 —— 成本上限与熔断器 交叉核对。

• 抬升一格。 选得分最低的那一格，合入一项收束在这一格里的修复（一个 make 目标、一个钩子、一段 YAML、一段脚本 —— 以 _handson/15-lazy-ai-coder/reproduce.sh 为已跑通的样板），并把这项修复绑回它所针对的那一格（例如 MDD × 牧场 —— 发布 SLI 与 staging 浸泡）。

• 重评并挂载。 用 _handson/15-lazy-ai-coder/HarnessCard-Act4.md 作模板，写出修复后的 HarnessCard，挂到发布 PR 上，并附一行 delta 备注：指名是哪一格在动（例如 SDD × 梳理 —— 让规约面持续鲜活）、动了多少。

Lehman 的演化定律 [Lehman, 1980] 解释了"季度重评"为什么不是可选项：无人维护的马具，默认就是会腐化。

陷阱 —— 第 90 天评审会翻车的三种方式

自打分。 交付修复的那位工程师同时也是打分人；分数平均偏移 +0.5。解法：第 90 天的打分人，不能是第 30 天的交付人。

投入而非产出。 格子得分在涨，DORA 指标却不动。每一项格子得分，都必须配一条它 被预言要移动 的产出指标（第 15 章的 虚荣 delta 陷阱对此做了完整展开）。

抬高顶、不抬低底。 团队把一个 4 抬成 5，而不是把一个 1 抬成 2；均值在升，承重最弱的那个维度却纹丝不动。解法：第 90 天的仪式必须去挑得分最低的那一格，哪怕更强的某一格更诱人。

16.3 —— 悬而未决的问题

最多七个方向——在这些方向上，本书提出了自己并未回答的问题。每一条至少配一处引用，勾勒相邻文献。

• 多租户 LLM 部署下的元马具版本化。 当供应商在季度中段推送模型变更、尤其当多个客户共享同一租户时，马具规则该如何存活？[Huyen, 2025]。

• 何时把博客体 .md 上下文迁移到结构化 RAG 管道。 Karpathy 的 context engineering 定义 [Karpathy, 2025] 与此相关，但并没有给出答案。

• 多语言 monorepo 与跨地域团队的 HarnessCard。 当分析单位被放大，这套 3 × 4 矩阵还扛得住吗？[Conway, 1968]。

• 连续型 vs 里程碑型熵度量。 熵的下降能在一次 sprint 中被连续度量吗？还是说"按里程碑"就已经是最高有用分辨率？[Lehman, 1980]。

• 能把好马具与坏马具区分开的基准测试。 Terminal-Bench 2.0 提供了一个暗示性的数据点，但尚未成为定论 [LangChain, 2026]。

• 安全关键型智能体的 HarnessCard 披露要求。 监管机构是否应像要求 SBOM 一样，要求 HarnessCard 式披露？[CAR Research Collective, 2025]。

• 一项技能的半衰期。 在 prompt 漂移把一份 SKILL.md 侵蚀掉之前，它还能承重多久？[Anthropic, 2024]。

16.4 —— 本书 并未 主张的事

一位读到这里的读者，有资格拿到一则诚实的脚注——说明本书的主张所包含、以及 不 包含的东西。

• 马具不能替代品味。 3×4 矩阵里没有一格会告诉一支团队 哪个问题值得解决、该采用何种架构、或某份 SKILL.md 在回答一个错问题。马具约束的是"智能体 怎样 写代码"；它不产生"什么 代码值得写"。第 02 章 Stage-4 的陷阱，在整本书层面同样成立。

• 并不是每支团队都需要每一格。 03.5 的"何时不用"并不是一段修辞让步；独自做的原型、一次性的脚本、一套被冻结的遗留系统，的确不会偿还这份马具投资。一支为了一段四十行 CSV 解析器就去采用十二格纪律的团队，无论自觉与否，都在上演一场马具剧场。

• 命名并未板上钉钉。 这份四区域词汇来自从业者（见 05.Provenance）。若 CAR [CAR Research Collective, 2025] 或 LangChain 的五部分解剖 [LangChain, 2026] 更适合你的团队，就用那一套框架，并做翻译即可。本书押注的是 三大护法 × 十二格分解 作为"周一早上可用的规划工具"，并未押注"这些区域名"成为终极分类法。

• 那些陷阱并未穷尽。 行内的 callout 只点出了作者自己调试过、看别人调试过、或读过可信记录的那些失败模式。它们是一份起步词汇表，不是一部完整异兽录——16.3 指出了下一轮新失败模式最可能冒出来的地方。

若本章的 30/60/90 清单、3×4 矩阵、以及这份陷阱词汇表，能在接下来九十天里给你的团队带来：一次被拒的 commit 事件、一条被度量的信号、一条被修订过的 AGENTS.md 条目——那本书的活儿就算干完了。

研究脉络

• DORA ／ Accelerate [Forsgren et al., 2018] —— 支撑 30/60/90 这一框架的节奏与度量谱系。

• Lehman 定律 [Lehman, 1980] —— 为什么 90 天评审必须周而复始。

• 演化式架构 [Ford et al., 2017] —— 支撑"一次一格"式改进的那条 fitness-function 谱系。

动手环节

在 source/_handson/16-where-we-go-from-here/ 下，住着两份可直接拷走的制品：

• checklist-30-60-90.md —— 以独立 markdown 形式交付的这份清单，适合直接粘进团队 wiki。

• open-questions.md —— 以独立文件形式交付的悬而未决问题清单，便于研究者引用。