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