前面一篇我们讲的是工作台怎么摆。这一篇继续往下讲一个更关键的问题当工作台已经搭好之后一轮程序任务到底是怎么从开始走到结束的本书把这个过程叫做完整循环。它不是“改一处代码”这么简单而是要经历先看清项目地图再确认当前任务然后改代码接着跑验证最后把结果写回状态如果通过就进入可提交状态如果没通过就把问题留给下一轮这才是一个真正能收敛的程序任务循环。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. 本章小结这一章想讲清楚的核心是程序任务不是改完就算完而是一轮一轮经过状态、输入、分析、执行、输出和回写最后走到可验证、可提交的闭环。以购物车程序为例完整循环的价值在于先看清楚再动手只改授权范围内的内容先验证再提交把结果写回状态让下一轮接着已有事实继续推进这就是本书里“程序项目如何收敛”的真正底层逻辑。下一章我会继续讲当程序任务已经能跑完整个循环后为什么还要谈长期维护和任务升级。