企业官网建设流程全解析

前面一篇我们讲的是工作台怎么摆。
这一篇继续往下，讲一个更关键的问题：

当工作台已经搭好之后，一轮程序任务到底是怎么从开始走到结束的？

本书把这个过程叫做完整循环。

它不是“改一处代码”这么简单，
而是要经历：

• 先看清项目地图
• 再确认当前任务
• 然后改代码
• 接着跑验证
• 最后把结果写回状态
• 如果通过，就进入可提交状态
• 如果没通过，就把问题留给下一轮

这才是一个真正能收敛的程序任务循环。

1. 为什么要把完整循环写出来？

因为很多程序任务看起来像是在推进，
实际上只是不断试错。

比如：

• 改一版
• 看不对
• 再改一版
• 还是不稳
• 继续猜
• 继续扩散

如果没有一个清楚的循环，
系统就会越来越像“边做边乱撞”。

所以本章要讲的是：

程序任务不是一次性动作，而是一轮一轮沿着清楚的流程推进。

这个流程越清楚，系统越容易收敛。

2. 购物车程序的一轮任务，通常从哪里开始？

还是用空购物车结算修复来举例。

假设当前任务是：

修复空购物车结算路径，避免空购物车直接进入下单或支付流程。

这一轮通常不是一上来就改代码，
而是先做三件事：

2.1 先读项目地图

看清楚：

• 项目目标是什么
• 主文件在哪里
• 哪些边界不能碰
• 这类任务以前怎么处理过

2.2 再读当前任务

确认：

• 这轮到底修什么
• 哪些文件可以改
• 哪些文件不能碰
• 什么结果算通过

2.3 最后再看相关代码和测试

先看：

• checkout/service.py
• tests/test_checkout.py

这样做的目的很简单：
先建立正确的上下文，再开始动作。

3. 一轮程序修改的六个阶段

如果把这轮任务压缩成一个最小循环，可以写成这样：

3.1 State

装载当前状态：

• project_map.md
• current_task.md
• revision_log.md
• open_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. 本章小结

这一章想讲清楚的核心是：

程序任务不是改完就算完，而是一轮一轮经过状态、输入、分析、执行、输出和回写，最后走到可验证、可提交的闭环。

以购物车程序为例，完整循环的价值在于：

• 先看清楚再动手
• 只改授权范围内的内容
• 先验证再提交
• 把结果写回状态
• 让下一轮接着已有事实继续推进

这就是本书里“程序项目如何收敛”的真正底层逻辑。

下一章，我会继续讲：当程序任务已经能跑完整个循环后，为什么还要谈长期维护和任务升级。