第 10 章：不止于代码
论点：任何可以拆成独立子任务的脑力劳动，都遵循同样的规则。写代码只是第一个把整个闭环跑通的领域——理解这一点，就能预测下一个会被跑通的是哪里。
为什么代码是第一个
如果本书框架（三个卡点、三把钥匙、四种调度模式、磨合期）其实讲的是知识工作，为什么代码先到这一步？
三个结构原因，它们值得命名，因为它们预测下一个这套传给谁：
- 代码有形式化验证。 测试给你"这是对的吗？"一个自动答案。你能跑、得到绿或红、Agent 能闭合自己的循环。几乎别的知识工作没有这个原生属性。
- 代码有廉价失败。 错实现被测试几秒内抓到。错的诊断、错的策略备忘、错的设计被一个人在更晚时候、用更高代价抓到。
- 代码有成熟的工程文化。 软件工程关于模块化、测试、接口设计已经吵了几十年。Agent 到来时，有一套词汇（Ousterhout、Martin、Beck）准备好被编码成 skill。大多数别的领域缺这个。
把这三个拿掉，你得到相反：Agent 不能自验证、失败昂贵、没有继承的纪律可编码。那个领域不能跑三把钥匙剧本。能跑它的那些领域，是和这三个条件有最强类比的那些。
同一框架，重新应用
考虑数据分析。把"代码"换成"分析"：
- 卡点 1（需求对齐）：我们用这份数据到底想决定什么？哪个利益相关方会据此行动？
- 卡点 2（正确性）：分析方法论上站得住吗？假设成立吗？这是难的那个——没有
npm test等价物。但有一份"分析的测试计划"：假设清单、敏感性检查、替代切片。Agent 能跑这些。 - 卡点 3（可维护性）：下一个碰这份数据集的人理解做了什么吗？推导可重现吗？管道有文档吗？
三把钥匙直接翻译：
- 需求对齐 → 定义分析要驱动的决策。用第 3 章的两种技术，不动改。
- 正确性当契约 → 在分析之前构造方法论检查表。让 Agent 跑并报告失败。
- 纪律编码 → 把数据团队约定（notebook 怎么组织、中间产出住哪、单位和来源怎么文档化）编码成 skill。
flowchart TB
D[可拆分的知识型任务]
D --> Q1{正确性检查<br/>能否被规格化？}
Q1 -->|强| K[三把钥匙 + 并行模式适用]
Q1 -->|弱 / 主观| H[人审为主<br/>并行面收窄]
这不是推测。一些团队在做。磨合期看起来熟悉：第一阶段混沌、第二阶段觉察、第三阶段模板、第四阶段杠杆。同样的曲线。
闭环正在关上的其它领域
一份带主观倾向的部分清单，按接近程度粗排：
- 数据分析。 已经走得挺远。带 Agent 写方法论的分析 notebook、对着方法论清单跑、用 skill 编码团队约定。今天一些团队已经能出货。
- 研究 / 文献综述。 测试计划类比是"什么算相关来源"和"综述必须 address 的主张"。多个 Agent 能在不同子问题上并行评审。合并是总结。
- 设计 / UX 探索。 best-of-N 是自然动作：对着共享 spec 的多次设计尝试，人挑。skill 编码设计系统。Agent 能对着无障碍和一致性检查表批评彼此工作。
- 写作（长篇、技术）。 这本书就在这样起草。章节大纲是需求。一致的声音是测试计划（Agent 当读者检查声音断裂）。skill 编码风格指南。多章并行起草。
- 法律 / 合规评审。 契约清晰（"这些条款必须 / 禁止出现"）。成熟；瓶颈是职业责任，不是技术。
- 策略 / 决策备忘。 更难，因为没有自动"对答案"测试。但对齐先 + 多尝试 + 筛这个模式在立 frame 上仍大有帮助。
- 运维 / 事件响应。 第 8 章的分诊层本身就是一个版本。Agent 驱动的 runbook 执行、分诊只在新颖失败时路由给人，正在快速演进。
注意模式：走得最远的领域是"什么算对"可以被规定、即便不能被完全自动化的领域。 落后的领域是正确性真正主观、抗拒编码的领域。
什么还翻译不过来（暂时）
诚实谈极限：
- 硬件受限工作。 Agent 能规划和文档化物理实验；它不能跑实验室。直到机器人学跟上，物理迭代循环留给人。
- 要大量隐性判断力的工作。 临床医学、高级谈判、法庭辩护。Agent 能准备和辅助；它目前不能替代一个看过一万个案例的从业者的隐性能力。
- 一次错的产出不可恢复的任何东西。 运载火箭代码。外科。货币政策。廉价失败假设（第 6 章）崩塌，整个并行剧本急剧收紧。你仍然可以用，但你要给廉价失败重新定价。
边界会挪。机器人学会关上硬件缝隙。更好的 Agent 不确定性校准会扩展高风险工作的安全范围。当前"翻译不过来"清单是一个快照，不是判决。
这对读者意味着什么
如果你是拿这本书做代码的工作工程师，最后一章仍然可操作：你在磨合期里建的 skill 能泛化。不是具体代码 skill——那些绑在你代码库上——而是元 skill：
- 怎么结构化需求对齐。
- 怎么写一份实际是验收契约的测试计划。
- 怎么把纪律编码成可加载文档。
- 怎么在不被产出淹没的情况下调度并行工作。
- 怎么保护你的缝隙不被杠杆抢走。
这些元 skill 比任何具体代码库 skill 都值钱，因为它们迁移。你代码之后进入的每个新领域都会有它自己版本的三个卡点、三把钥匙、四种模式。你会比别人更快认出它们，因为你先在代码里见过。
元框架，最后一次
把整本书剥到一句话：
并行 AI 生产力不是 Agent 能力。它是一种你和你的 Agent 通过机制化你的注意力过去被强制串行化的那三个位置、相互适应出来的工作流。你能机制化那三个位置的领域，就是这套东西能跑的领域。
这句话短到能记。它也几乎完整——磨合期、调度模式、廉价失败相变、第 9 章的诚实代价，都是它的隐含后果。
收尾
本书的框架带倾向。它也没完成。分诊层（第 8 章）在积极开发中。模式 4（第 7 章）真的是前沿。这一章讨论的向代码外的翻译是最早期的。如果你在一年后读这本书，有些细节看起来过时，论点的形状——瓶颈转移、钥匙解锁、磨合真实、诚实代价——应该还在。
如果那个形状也不在了，那是有人找到了更深的框架。那也是个好结局。
外部声音
- 支持：AI 增强工作流的写作在研究（各种"AI 辅助文献综述"帖）、写作（Ethan Mollick 的 Co-Intelligence）、策略（ops/strategy 圈新兴的"AI 辅助备忘"体裁）里都有。每一条都是在不同领域独立再发现三个卡点 / 三把钥匙的结构。
- 反驳：上面非代码领域的专家都有真实的、常常正确的理由怀疑"他们的领域是下一个"。听这些理由。大多数是"我们没有测试计划类比"的变体——这在当下成立，未来可能改变。
结尾
感谢你读到这里。剩下的是你的——你的磨合、你的 skill、你的项目、你的并行 Agent。这本书做不了你的工作。它只能告诉你那条路有个形状，以及那个形状是什么。
祝好运。交付得漂亮。保持休息。