前两章我们已经把两件事说清楚了：
- 小任务可以直接用 prompt
- 任务变复杂后，需要加 Harness
但还有一个更关键的问题：
当任务开始反复失败、开始跨文件影响、开始需要恢复时，系统到底靠什么继续往下走？
答案是：状态。
在这本书里，状态不是为了显得系统更复杂，而是为了让 AI 在高风险任务里知道：
- 现在处于什么阶段
- 下一步允许做什么
- 做完以后是否真的可以继续
如果没有状态，AI 每一轮都可能像重新开始一样，只能根据当前上下文猜下一步。
一旦任务跨越了单轮 prompt 能承受的范围，系统就需要把关键事实写到外部状态里。
1. 为什么 Harness 之后还需要状态？
Harness 负责控制，状态负责记住。
这两者不一样。
Harness 更像是“这一轮怎么做”：
- 任务范围是什么
- 哪些文件允许修改
- 怎么检查结果
- 如果失败，下一步怎么办
状态更像是“当前项目已经走到哪一步”：
- 当前任务是什么
- 已知问题有哪些
- 哪些地方已经验证过
- 哪些地方还不能动
如果只有 Harness，没有状态，那么系统虽然知道“这一轮怎么做”，但下一轮还得重新猜。
而高风险任务最怕的，就是反复猜、反复改、反复绕。
所以，一旦任务开始出现以下情况，就该引入状态：
- 重复失败
- 跨文件影响
- 需要恢复
- 需要交接
- 需要长期维护
2. 状态到底记录什么？
本书里的状态不是“把所有内容都记下来”，而是只记对下一步有用的事实。
比如：
- 当前项目状态
- 当前任务
- 允许范围
- 已知问题
- 最近一次修改
- 验收结果
- 失败原因
- 下一轮建议
这些内容，分别对应不同的状态文件，比如：
project_map.mdcurrent_task.mdrevision_log.mdopen_issues.md
它们的作用不是堆信息，而是把项目里真正重要的东西拆开存。
project_map.md
负责放长期稳定的项目认知，比如：
- 项目的目标
- 核心文件
- 关键约束
- 读文件顺序
current_task.md
负责放当前这一轮要做什么，比如：
- 本轮任务
- 允许修改的范围
- 禁止修改的范围
- 验收条件
revision_log.md
负责记录为什么这么改，比如：
- 修改动机
- 修改范围
- 验证结果
- 还遗留什么问题
open_issues.md
负责记录暂时不能解决、但不能忘掉的问题，比如：
- 证据不足
- 范围外风险
- 还需要人判断的地方
3. 为什么状态会让系统更容易收敛？
因为状态把“重复试错”变成了“带反馈继续”。
没有状态的时候，AI 很容易这样跑：
- 读当前任务
- 猜一个修改
- 改完再看
- 发现不对，再重新猜
这个过程看起来像在努力，实际上可能是在原地打转。
有状态之后，系统就能记住：
- 哪些路已经试过了
- 哪些修改失败了
- 哪些范围已经确认不能动
- 哪些问题要单独处理
这样，下一轮就不是“重新开始”，而是“带着失败轨迹继续做”。
这就是状态最重要的价值：
它让循环有机会收敛，而不是一直摆动。
4. 本书里的状态和论文修改例子
本书一直用论文修改引言（Introduction）作为例子。
比如任务是：
“润色引言，让表达更学术，并降低过强的主张。”
这类任务如果没有状态，就很容易出现两个问题：
第一，范围漂移
本来只想改引言，结果 AI 顺手改了摘要、结论，甚至相关引用和符号定义。
第二，语义漂移
本来只是想弱化表达，结果 AI 把原本合理的主张改得过弱，甚至把贡献写没了。
状态的作用，就是把这些边界写清楚、记下来、下一轮继续用。
比如：
current_task.md说明这轮只改引言revision_log.md记录这轮弱化了哪些主张open_issues.md记录范围外的问题，比如摘要是否也需要后续调整
这样，系统就不会每轮都重新猜“到底该改多少”。
5. 什么时候应该收紧状态，什么时候应该放松？
这本书里一个很重要的观点是：
状态不是越多越好，控制也不是越重越好。
状态应该跟任务风险匹配。
低风险任务
如果只是一个简单修改，状态可以很轻：
- 一个任务描述
- 一个结果记录
- 不需要很多额外文件
中等风险任务
如果开始涉及多步修改、循环验证、局部恢复，就需要更清楚的状态：
- 当前任务
- 项目地图
- 修改日志
- 失败记录
高风险任务
如果任务会跨文件、会影响后续判断、会进入长期协作，那就必须有更完整的状态结构：
- 当前任务
- 项目地图
- 修改日志
- 开放问题
- 验收结果
- 恢复条件
所以，状态不是一次性全铺开，而是按任务复杂度逐步引入。
6. 状态和 Harness 的关系
这一点很容易混。
Harness 做什么？
- 限制动作
- 检查结果
- 执行验证
- 约束下一步
状态做什么？
- 记录当前事实
- 保存项目认知
- 累积失败轨迹
- 为下一轮提供输入
简单讲：
- Harness 是控制器
- 状态是记忆
没有 Harness，状态容易变成一堆没人管的笔记。
没有状态，Harness 每一轮都要重新解释任务，系统就会越来越累。
所以这两者是配合关系，不是替代关系。
7. 一个最小的状态结构可以是什么样？
本书不主张把状态做成大而全的数据库。
最小状态只要能支持下一轮决策就够了。
可以先记成这样：
current_task:-只修改引言-不修改摘要 / 方法 / 结论project_map:-paper.md 是主文档-revision_log.md 记录修改原因-open_issues.md 记录未决问题open_issues:-摘要是否需要后续同步-主张强度是否仍然偏强last_result:-已完成一次局部弱化-未越界修改这个结构的目的不是“看起来完整”，而是能让下一轮知道：
- 现在在哪
- 做过什么
- 还有什么没解决
8. 什么时候状态会变成负担？
如果把状态做得太重，它就会开始拖慢系统。
比如：
- 每轮都要维护很多无关文件
- 很多状态长期不更新
- 每次修改都要同步一大堆记录
- 任务还没复杂到那个程度，状态已经比任务本身还重
这就违背了本书的原则。
所以，状态只保留两类东西：
- 会影响下一轮动作的事实
- 会影响长期判断的记录
其余的临时内容，能不保留就不保留。
9. 本章小结
这一章想说明的核心是：
状态不是为了让系统看起来更工程化，而是为了让 AI 在复杂任务里知道自己走到哪一步。
当任务开始反复失败、跨文件影响、需要恢复或者需要交接时，就不能只靠 prompt 和 Harness 了。 这时必须把项目认知、当前任务、修改记录和未决问题写成状态，让下一轮继续时不是重新猜，而是基于事实推进。
下一章，我会继续讲：状态机到底怎么描述转移，以及“现在处于哪里、下一步能做什么”为什么要写成可检查的规则。
