AI渐进编程之十三：一轮程序修改是怎么跑完整个循环的？
前面一篇我们讲的是工作台怎么摆。
这一篇继续往下，讲一个更关键的问题：
当工作台已经搭好之后，一轮程序任务到底是怎么从开始走到结束的？
本书把这个过程叫做完整循环。
它不是“改一处代码”这么简单，
而是要经历：
- 先看清项目地图
- 再确认当前任务
- 然后改代码
- 接着跑验证
- 最后把结果写回状态
- 如果通过，就进入可提交状态
- 如果没通过，就把问题留给下一轮
这才是一个真正能收敛的程序任务循环。
1. 为什么要把完整循环写出来？
因为很多程序任务看起来像是在推进，
实际上只是不断试错。
比如：
- 改一版
- 看不对
- 再改一版
- 还是不稳
- 继续猜
- 继续扩散
如果没有一个清楚的循环，
系统就会越来越像“边做边乱撞”。
所以本章要讲的是：
程序任务不是一次性动作，而是一轮一轮沿着清楚的流程推进。
这个流程越清楚，系统越容易收敛。
2. 购物车程序的一轮任务，通常从哪里开始？
还是用空购物车结算修复来举例。
假设当前任务是：
修复空购物车结算路径，避免空购物车直接进入下单或支付流程。
这一轮通常不是一上来就改代码，
而是先做三件事：
2.1 先读项目地图
看清楚：
- 项目目标是什么
- 主文件在哪里
- 哪些边界不能碰
- 这类任务以前怎么处理过
2.2 再读当前任务
确认：
- 这轮到底修什么
- 哪些文件可以改
- 哪些文件不能碰
- 什么结果算通过
2.3 最后再看相关代码和测试
先看：
checkout/service.pytests/test_checkout.py
这样做的目的很简单：
先建立正确的上下文，再开始动作。
3. 一轮程序修改的六个阶段
如果把这轮任务压缩成一个最小循环，可以写成这样：
3.1 State
装载当前状态：
project_map.mdcurrent_task.mdrevision_log.mdopen_issues.md
这一步的意义是：
让系统知道自己现在在哪。
3.2 Input
这一轮输入通常来自人类或上一轮结果。
比如：
“空购物车结算时要返回安全错误，不要继续调用支付流程。”
这个输入不是全部任务，
而是这一轮要处理的具体目标。
3.3 Analysis
分析这轮该怎么做。
这里要判断：
- 任务范围是什么
- 哪些代码需要看
- 哪些代码不能动
- 需要补哪些测试
- 有没有潜在风险
以购物车为例，分析后可能得到：
- 修改点在结算逻辑
- 回归测试要覆盖空购物车路径
- 正常购物车路径不能被破坏
- 支付接口不能被误调用
3.4 Driver
真正执行修改。
这一步就是把分析结果变成代码动作。
比如：
- 在
checkout/service.py里增加空购物车判断 - 在
tests/test_checkout.py里补测试 - 不动认证、支付、文档和其他模块
Driver 的重点不是“改得多”，
而是“改得准”。
3.5 Output
输出这一轮的结果。
输出通常包括：
- 修改后的代码
- 测试结果
- 变更范围
- 还剩什么问题
如果这一轮做对了，
输出就不只是“代码变了”，
而是“变化已经可以被验证”。
3.6 State Update
把这一轮真正有用的事实写回去。
例如：
revision_log.md记录为什么这么改open_issues.md记录还没解决但不能忘掉的问题current_task.md标记当前轮是否完成project_map.md如果长期认知变化，再同步更新
这一步非常重要。
因为下一轮能不能接着做，
就看这一轮有没有把关键事实写回状态。
4. 一个最小的完整循环可以长什么样？
可以先把它写成这样：
state:project_map:loadedcurrent_task:fix empty-cart checkoutopen_issues:[legacy caller behavior unclear]input:request:empty cart should fail safelyconstraint:do not affect normal checkoutanalysis:scope:checkout/service.py + tests/test_checkout.pyrisk:regression on normal checkoutplan:add guard + add regression testdriver:action:apply_patchoutput:changed_files:-checkout/service.py-tests/test_checkout.pyvalidation:pendingnotes:-empty-cart path handled-normal path preservedstate_update:revision_log:updatedopen_issues:[legacy compatibility review]current_task:ready_for_validation这个结构的重点不是 YAML，
而是它表达了一个很清楚的事实：
- 这一轮不是只做修改
- 这一轮是要把修改、验证、回写串起来
- 下一轮不是重新猜，而是基于结果继续
5. 为什么验证一定要夹在中间？
因为代码改完以后，
不能直接假设“应该没问题”。
程序任务最容易出现的问题是：
- 局部修好了
- 但别的路径坏了
- 单测过了
- 语义却变了
- 表面通过
- 实际越界
所以验证不能放在最后一句“应该没问题”里，
而要成为循环中的一环。
在购物车程序里，验证至少要看：
- 空购物车是否返回安全错误
- 正常购物车是否仍然可结算
- 支付接口是否没有被误调用
- 修改范围是否没有越界
- 剩余问题是否已经写回状态
只有这些都过了，
这轮任务才算真正完成。
6. 如果验证没通过，系统该去哪里？
没通过不等于失败结束。
没通过的意思是：
这一轮的路径还不能提交，必须进入下一轮处理。
这时系统应该做三件事：
6.1 记录失败原因
写进revision_log.md或open_issues.md，说明为什么没过。
6.2 缩小下一轮动作
不要继续乱扩散，
而是只围绕失败点继续改。
6.3 保留已经确认的结果
已经验证通过的部分不要回滚掉，
避免把已经稳定的结果重新打碎。
这就是完整循环和乱试错最大的区别。
完整循环不会把失败当成终点，
而是把失败变成下一轮的输入。
7. 为什么这个循环会让系统更容易收敛？
因为每一轮都在回答三个问题：
- 现在在哪
- 这轮做了什么
- 下一轮该接什么
如果这三个问题都清楚，
系统就不会一直在同一层面绕圈。
以空购物车修复为例：
- 先确定项目边界
- 再确认当前任务
- 然后做最小修改
- 接着验证
- 最后写回状态
这样下一轮拿到的不是“又一堆新猜测”，
而是“已经被验证过的事实”。
事实越多，猜测越少。
猜测越少，收敛越快。
8. 一个完整循环和提交状态是什么关系？
如果验证通过，
系统就可以进入更稳定的状态：
- 当前任务完成
- 修改日志写好
- 开放问题记录好
- 项目地图如有需要再更新
- 代码进入可提交状态
这时的“提交”，不是只是 Git commit，
而是整个任务链条已经完成闭环。
也就是说：
代码通过不是终点，
它只是让系统进入下一轮的起点。
9. 本章小结
这一章想讲清楚的核心是：
程序任务不是改完就算完，而是一轮一轮经过状态、输入、分析、执行、输出和回写，最后走到可验证、可提交的闭环。
以购物车程序为例，完整循环的价值在于：
- 先看清楚再动手
- 只改授权范围内的内容
- 先验证再提交
- 把结果写回状态
- 让下一轮接着已有事实继续推进
这就是本书里“程序项目如何收敛”的真正底层逻辑。
下一章，我会继续讲：当程序任务已经能跑完整个循环后，为什么还要谈长期维护和任务升级。