AI渐进编程之五：SIADOS 状态转移方法

原创已于 2026-06-28 15:31:26 修改 · 283 阅读

4 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#人工智能

于 2026-06-28 13:30:32 首次发布

前一篇我们讲的是状态机怎么描述转移。
这一篇继续往前走，重点不在“状态怎么摆”，而在一轮任务推进里，状态怎么更新，系统怎么靠反馈继续往前走。

为了说明这个过程，本书把一轮任务拆成六个部分，称为 SIADOS：

S：State
I：Input
A：Analysis
D：Driver
O：Output
S’：State Update

这六步不是为了显得复杂，而是为了把 AI 编程从“一次性输出”变成“有反馈的持续推进”。

1. 为什么要从一次输出，变成 SIADOS？

如果只有一次输出，系统最多只能回答“这一轮做了什么”。
但真实任务不是一轮结束的，尤其是这些情况：

论文要反复修改
代码要多轮修复
状态要持续维护
失败要留下轨迹
下一轮要基于上一轮继续推进

这时，真正重要的就不是“这一轮写了什么”，而是：

这一轮之前系统处于什么状态
这一轮输入了什么
这一轮分析出了什么
这一轮执行了什么
这一轮输出了什么
这一轮之后状态变成了什么

这就是 SIADOS 的意义。

2. SIADOS 里的六步分别做什么？

2.1 S：State

State 不是聊天记录，而是当前项目已经确认的事实。

比如：

当前任务是什么
当前允许修改的范围是什么
已知问题有哪些
上一轮结果是什么

2.2 I：Input

Input 是这一轮新的输入。

它可以来自：

人类的新要求
上一轮的验证结果
当前任务的补充信息
新发现的约束或问题

2.3 A：Analysis

Analysis 是分析任务边界和风险。

这一轮能不能做、该不该做、要不要缩小范围，通常都在这一层判断。

2.4 D：Driver

Driver 是真正执行动作的部分。

它负责把分析结果变成修改、调用或其他受控动作。

2.5 O：Output

Output 是这一轮产生的结果。

可能是：

文本修改
代码 diff
验证结果
问题记录
新状态的候选内容

2.6 S’：State Update

State Update 是最关键的一步之一。

它把这一轮真正有用的事实写回状态，供下一轮继续使用。

3. 为什么状态更新比一次性输出更重要？

因为 AI 编程真正难的地方，不是开始做事，而是：

做完之后，下一轮怎么接着做
失败之后，下一轮怎么避免重复失败
状态变化之后，系统怎么知道自己有没有在往前走

如果没有状态更新，SIADOS 就只是一次普通输出。
但有了状态更新，SIADOS 才变成一个真正的循环。

4. 为什么失败也必须写回状态？

很多人会下意识觉得，失败就失败了，重来就行。
但在 AI 编程里，这样做很容易让系统一直重复同一种错。

所以失败不能只停留在“结果不对”，
还要进入状态，变成可复用的反馈。

比如：

这次为什么失败
哪些路径已经试过
哪些动作已经证明无效
下一轮不要再走哪条路

这就是为什么本书一直强调：

失败不是消失，而是要被保存下来。

5. 什么叫收敛？

收敛不是一个很玄的词。
在这本书里，它的意思其实很朴素：

系统在多轮运行后，不再原地摆动，而是逐步接近一个可接受结果。

也就是说，收敛至少要满足三个迹象：

修改范围越来越清楚
失败路径越来越少
状态越来越稳定

如果系统每一轮都在换方向、换文件、换理由，那就不是收敛，
而是摆动。

6. 为什么循环里的反馈比一次性输出更重要？

因为一次性输出只能说明“这一轮给出了什么”，
循环里的反馈才能说明“系统有没有越走越对”。

举个很简单的例子：

只看一次输出

你可能看到 AI 改了文本，看起来也通顺，似乎没问题。

看循环反馈

你会继续观察：

它是不是只改了允许范围
它有没有把问题写回状态
下一轮是不是还在重复同样的错误
失败后它有没有修正方向

这就是循环的价值。
它让 AI 不只是“能说”，而是“能在反馈里修正自己”。

7. 状态更新和收敛之间是什么关系？

这两者是连在一起的。

状态更新做对了

下一轮就能拿到正确的输入。

下一轮输入正确了

系统才有机会继续往收敛方向走。

如果状态更新错了

下一轮就会在错误基础上继续跑，最后越来越偏。

所以，状态更新不是附属动作，
它本身就是收敛的一部分。

8. 一个最小的 SIADOS 例子

可以先这样理解：

state:
  current_task: revise Introduction
  scope: [Introduction]
  issues: [claim too strong]

input:
  request: reduce claim strength
  constraint: do not touch Abstract / Conclusion

analysis:
  scope_ok: true
  risk: cross_section_drift
  action_plan: revise Introduction only

driver:
  action: apply_patch

output:
  changed_sections: [Introduction]
  validation: pending
  notes: [claim weakened, no scope violation]

state_update:
  current_task: revise Introduction
  scope: [Introduction]
  issues: [abstract may need later review]
  last_result: local refinement done