前面三篇我们已经把三件事讲清楚了小任务可以直接用 prompt任务复杂了需要加 Harness任务开始需要长期推进时就要引入状态到了这里问题就变成了状态到底怎么组织系统怎么从一个阶段走到下一个阶段这就是状态机要解决的事。在这本书里状态机不是为了“显得高级”而是为了把“现在在哪里、下一步能做什么、什么算通过”写成可检查的规则。只有这样AI 编程才不是凭感觉乱跑而是能沿着明确的转移关系继续推进。1. 为什么需要状态机而不只是状态如果只有状态没有状态机那么系统就只能记住“现在是什么样子”但不知道为什么会走到这里下一步允许什么动作什么时候可以转过去什么时候应该停下来换句话说状态只是静态事实状态机才是动态关系。这很重要因为 AI 编程里的任务不是静止的。它会经历读取任务分析边界修改内容检查结果记录反馈决定是否继续如果没有状态机这些动作就很容易变成散乱的步骤。有了状态机系统就能把这些步骤串成一条清楚的转移链。2. 状态机最核心的三个问题状态机本质上只回答三个问题2.1 现在在哪系统当前处于什么状态比如任务待处理正在分析正在修改正在验证已提交被阻断2.2 下一步能做什么在当前状态下允许哪些动作比如允许读取current_task.md允许修改paper.md的引言不允许修改摘要和结论允许记录open_issues.md2.3 什么算转移成功什么条件满足后系统才可以进入下一状态比如修改范围正确主张强度没有增强状态文件已同步更新验证通过这三个问题一旦讲清楚状态机就有了。3. 论文修改里的状态机例子这本书一直用论文修改来说明问题。比如当前任务是“只修改引言降低过强的主张。”那它对应的状态机大概会这样走3.1 Ready刚收到任务还没开始。系统要先确认当前任务是什么允许范围是什么有没有已知问题3.2 Analyzing开始分析任务边界。这一步通常会看引言里哪些句子主张太强哪些内容可以改哪些内容不能碰3.3 Editing开始执行修改。这时系统只能在允许范围内动作。比如只改引言不动摘要、方法和结论。3.4 Validating修改完成后进行检查。要确认是否只改了授权部分主张是否被适度弱化状态文件是否更新3.5 Committed通过验收进入已提交状态。这意味着当前轮任务完成系统可以进入下一轮。3.6 Blocked如果发现越界、冲突或验证失败系统就不能继续推进。这时要记录失败原因而不是假装没事。4. 一个状态机应该怎么写得像样状态机最重要的不是图画得多复杂而是边界清楚。可以先用最简单的形式理解Ready - Analyzing - Editing - Validating - Committed \- Blocked这个图不复杂但它已经表达了本书最关键的思想任务不是一次性完成的每一步都要有前提每一步都要能检查失败不能消失要进入阻断状态这和“直接 prompt 一把梭”完全不同。5. 状态机为什么比“随便写写状态”更可靠因为它把“状态之间的关系”显式化了。如果只是写几个状态名系统还可能乱跳状态跳过验证忽略失败把临时结果误当成最终结果但如果有状态机就意味着每个状态都有进入条件允许动作转出条件失败分支这就让系统更像一个工程系统而不是一个聊天记录合集。6. 状态机和 Harness 的关系这一点很容易混。Harness 负责什么控制本轮动作检查当前结果限制可执行范围记录失败和反馈状态机负责什么定义阶段之间怎么转定义什么时候能进入下一步定义失败后该去哪里定义哪些状态之间不能乱跳可以这样理解Harness 是执行层的控制器状态机是控制层的骨架没有状态机Harness 容易变成一堆临时规则。没有 Harness状态机又只是纸面结构落不到实际动作上。7. 为什么状态机要写成可检查的规则因为 AI 编程不能只靠“人看起来合理”。很多任务表面上像是做对了实际上改了不该改的地方没有保留证据把问题藏起来了只是暂时没爆出来状态机的价值就在于它要求系统把“应该怎么转”写出来把“为什么能转”检查出来。这样系统不是靠印象推进而是靠规则推进。8. 一个最小的状态机结构如果把它写得更工程一点可以先有这样的结构states:-ready-analyzing-editing-validating-committed-blockedtransitions:ready - analyzing:condition:task_loaded trueanalyzing - editing:condition:scope_defined trueediting - validating:condition:diff_generated truevalidating - committed:condition:validation_passed truevalidating - blocked:condition:validation_failed true这里的重点不是 YAML而是它表达了一个清楚的事实不是任何状态都能跳不是任何动作都能做不是任何失败都能忽略9. 状态机最容易出的问题状态机如果写不好也会变成负担。常见问题有三个9.1 状态太多状态分太细反而没人维护。9.2 转移太乱状态之间允许的路径太复杂最后谁也记不住。9.3 失败分支不清楚如果失败后不知道去哪系统就会卡死或者乱跳。所以状态机不是越复杂越好。它应该服务于任务推进而不是服务于形式感。10. 本章小结这一章想说明的核心很简单状态机的作用是把“当前在哪里、下一步做什么、什么算通过”写成明确的转移规则。这样AI 编程才不会只是“看起来在推进”而是能够在一轮一轮的检查和反馈里真正沿着可控路径继续往前走。下一章我会继续讲状态更新与收敛以及为什么循环里的反馈比一次性输出更重要。