前两章我们已经把两件事说清楚了小任务可以直接用 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 了。 这时必须把项目认知、当前任务、修改记录和未决问题写成状态让下一轮继续时不是重新猜而是基于事实推进。下一章我会继续讲状态机到底怎么描述转移以及“现在处于哪里、下一步能做什么”为什么要写成可检查的规则。
原理、配置与物联网低功耗设计实践)
