上一章我们先把最轻的情况说清楚了：
如果任务很小，直接 prompt 就够了。
但一旦任务开始变复杂，问题就不再只是“模型会不会写”，而是“模型能不能在边界内持续做对”。
这时候，才需要给 AI 加一层 Harness。
在这本书里，Harness 不是一个花哨的概念，它就是放在模型外面的控制层。
它负责把任务范围、允许动作、验收条件和失败反馈组织起来，让 AI 不只是“能输出”，而是“能在约束下完成任务”。
1. 以修改论文为例
论文的常见结构：
- 摘要（Abstract）：用很短的篇幅说清楚这篇论文做了什么、为什么做、结果怎样。
- 引言（Introduction）：说明问题背景、研究动机、本文要解决什么。
- 相关工作（Related Work）：说明别人已经做过什么，本文和已有工作的关系是什么。
- 方法（Method）：说明你具体怎么做，系统、模型、流程或算法是什么。
- 结论（Conclusion）：总结本文贡献，并说明下一步可以怎么扩展。
2. Harness 解决的不是写作能力，而是控制问题
如果只靠 prompt，AI 可以开始做事，但它不一定知道：
- 当前任务到底限定在哪个部分
- 哪些内容可以改，哪些不能改
- 改完以后怎么判断通过
- 失败以后该不该继续
这就是为什么本书强调：
Prompt 解决“怎么说”，Harness 解决“能不能做，做完怎么验收”。
这两者不是同一层问题。
在轻量任务里，prompt 足够。
但当任务涉及多轮修改、跨文件影响、失败恢复和结果验收时，只靠 prompt 就不够了。
3. 什么时候该引入 Harness？
本书的判断标准很简单，不是看 AI 有多强，而是看任务有没有开始超过“纯 prompt”能承受的边界。
3.1 任务开始跨文件
如果一轮修改只改一个局部，还能直接处理。
但如果任务开始影响多个文件，或者修改可能波及正文、状态、日志和问题记录，那就需要 Harness。
因为这时，AI 很容易：
- 顺手改到授权范围外
- 忘记任务只允许改某个部分
- 把局部任务扩大成全局改动
3.2 任务开始有风险
当修改会影响：
- 论文的主张强度
- 章节之间的一致性
- 代码库的稳定性
- 状态文件的正确性
这类任务就不能让模型自由扩散。
必须先定义边界，再让它动。
3.3 任务需要持续推进
如果一次修改就能结束，直接 prompt 就行。
但如果任务需要反复检查、调整和继续，那就不能只停留在一次性输出。
这时 Harness 的作用，就是让每一步都在可检查的范围内推进。
4. Harness 在本书里到底管什么？
这本书里的 Harness，至少管四件事：
4.1 当前任务
当前任务写在 current_task.md 里。
它不是聊天记录，而是当前这一轮真正要做什么。
例如：
- 只修改论文的引言
- 不改摘要、方法、结论
- 修改后更新 revision_log.md
- 发现范围外问题就写入 open_issues.md
4.2 允许范围
Harness 要知道这轮能动哪些文件，不能动哪些文件。
这不是形式主义，而是为了防止模型把局部任务做成扩散修改。
4.3 结果检查
做完以后要检查：
- 有没有越界修改
- 主张强度有没有被偷偷增强
- 结果是不是和任务一致
- 状态文件有没有同步更新
4.4 失败记录
如果这一轮失败了，不能只停在“没做对”。
还要把失败轨迹留下来，供下一轮继续用。
这就是为什么书里会有：
- project_map.md
- current_task.md
- revision_log.md
- open_issues.md
它们不是额外负担，而是让下一轮继续推进的基础。
5. 贯穿全书的例子：修改论文引言
这本书一直用一个例子：
修改论文的引言，降低过强的主张。
这个例子很适合说明为什么要加 Harness。
任务输入
“润色引言，让表达更学术，并降低过强的主张。”
真正风险
模型很容易为了“全文一致”顺手去改：
- 摘要
- 结论
- 甚至相关术语和符号定义
如果没有 Harness，这种扩散很难被及时拦住。
有 Harness 以后
Harness 会先告诉模型：
- 只允许改引言
- 其他部分不能动
- 修改后必须检查 diff
- 结果要写回状态
这样，模型不是在整篇论文里自由游走，而是在一个明确边界里完成任务。
6. 为什么 Harness 会让系统更容易收敛？
因为它把“无边界试错”变成了“有边界循环”。
没有 Harness 的时候，模型可能这样跑：
- 改一点
- 看起来不对
- 再换个说法
- 再改一点
- 继续扩大范围
最后系统虽然还在动，但不一定是在收敛。
有 Harness 之后，流程会变成：
这时，循环不是空转，而是在把任务往前推。
7. 一个最小 Harness 可以长什么样？
本书不主张一上来就把系统做得很重。
一个最小 Harness，最关键的是把职责分开。
context:
– current_task.md
– project_map.md
– relevant files
permissions:
allow:
– paper.md#Introduction
– revision_log.md
– open_issues.md
deny:
– paper.md#Abstract
– paper.md#Method
– paper.md#Conclusion
checks:
– section diff
– claim strength
– scope compliance
– state update
这个结构的重点不是 YAML，而是它表达了本书的核心思想：
- 任务要明确
- 边界要明确
- 验收要明确
- 会影响下一轮的事实要回写
8. 什么时候该收缩控制层？
这里要讲严谨一点。
本书不是说任务结束后就“回到什么都不管的轻量模式”，
而是说：
- 临时状态要清理
- 已验证的长期状态要保留
- 控制层要根据后续任务风险降级
- 只保留当前任务真正需要的最小约束
也就是说，收缩的不是“知识”，而是“临时负担”。
可以清理的部分
- 一次性的草稿
- 中间产物
- 已经过期的试错轨迹
- 当前轮不再需要的临时缓存
应该保留的部分
- 已验证的项目地图
- 已确认的任务边界
- 需要长期追踪的 open_issues
- 对后续任务仍然有效的验收规则
所以，更准确的说法是：
任务完成后，清理临时状态，保留已验证的长期状态；控制层按任务风险降级，但不丢掉已经确认的规则和事实。
这样就不会让人误解成“系统又回到混沌状态”。
9. 本章小结
这一章想讲清楚的，其实就是一句话：
Harness 不是为了让 AI 更复杂，而是为了让 AI 在复杂任务里不乱跑。
它把任务范围、允许动作、结果检查和失败记录组织起来，让模型可以在边界内继续推进。
而当任务结束后，应该清理临时状态，保留已经验证过的长期状态，再按风险决定是否降级控制层。
这也就是本书从 prompt 走向 harness，再走向 state 的原因。
下一章，我会继续讲：什么时候需要引入状态，以及为什么状态会让循环更容易收敛。
