企业官网建设流程全解析

前面几篇我们已经把程序项目里最重要的几件事说清楚了：

• prompt适合小任务
• Harness适合边界和验收
• state适合记住当前进展
• revision_log.md适合记录为什么这么改
• open_issues.md适合保存暂时不能解决的问题
• 工作台适合把这些东西分开摆好
• 完整循环适合把任务从开始跑到通过
• 长期维护适合让通过后的结果继续稳定下来

这一篇继续往下，只回答一个问题：

一个本来像一次性修补的小任务，为什么最后会变成长项目？

1. 一次性任务为什么会变长？

因为程序项目里，很多“小问题”修着修着就会冒出后续。

还是用购物车程序来举例。

一开始你可能只是想：

• 空购物车时不要进入结算

但真正开始做以后，你会发现还要继续处理：

• 正常购物车路径不能被破坏
• 支付接口不能被误调用
• 回归测试要补
• 旧调用方行为要确认
• 这次修复要写进日志
• 还有相似边界问题要留给后续

这时它就不再是“修一个点”这么简单了。
它已经开始带出一串后续动作。

所以一次性任务会变长，不是因为一开始就想得太大，
而是因为程序项目本身会不断暴露新的边界和后续。

2. 为什么上下文不够用？

因为上下文只适合当前这一轮，
不适合长期记住整个项目。

如果只靠对话记忆，AI 很容易：

• 忘记刚确认过的边界
• 把旧问题当成新问题
• 把临时讨论当成最终结论
• 下一轮还要重新猜

所以，任务一旦开始变长，就不能只靠“记住刚才说了什么”。
必须把关键事实写到外部状态里，让下一轮可以直接接着做。

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

• project_map.md
• current_task.md
• revision_log.md
• open_issues.md

它们不是装饰，
而是让任务能继续往下走的最小接力棒。

3. 为什么要把任务切成短事务？

因为长期项目不适合一口气做完。
更稳的方式，是把它拆成一串短事务。

以购物车程序为例，可以这样拆：

1. 先修空购物车不能结算
2. 再补测试
3. 再确认正常购物车没有坏
4. 再写修改日志
5. 再记录未决问题
6. 再决定下一步要不要继续收紧规则

每一步都不大，
但每一步都能检查、能回写、能继续。

这样做的好处是：

• 任务不会一下子扩散太大
• 每轮都知道自己在做什么
• 失败了也知道从哪一轮退回
• 下一轮能直接接着已有事实继续

4. 什么叫“可恢复”？

可恢复，就是中断以后还能继续。

真实项目一定会被打断：

• 今天只做到一半
• 明天才继续
• 中间换人
• 中间换机器
• 中间被别的任务打断

如果没有可恢复结构，
每次恢复都得重新猜：

• 上一轮做到哪了
• 哪些结果已经确认
• 哪些问题还没解决
• 下一步最安全的动作是什么

而可恢复的项目，应该让下一轮一看就知道这些事实。
这就是长期项目真正需要的能力。

5. 购物车程序里，什么时候说明它已经变成长项目了？

可以看几个很实际的信号：

• 同一个地方反复出问题
• 修完以后还有后续任务
• 状态文件开始变得有意义
• 别人接手时必须先读状态
• 一次修复已经不够，得连续做几轮才稳

比如空购物车结算这件事：

• 第一轮：先挡住空购物车结算
• 第二轮：补测试和日志
• 第三轮：确认旧调用方行为
• 第四轮：处理相似边界问题

到这里，它就已经不是一次修补了，
而是一个正在变长的项目。

6. 本章小结

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

一次性任务之所以会演进成长期项目，不是因为任务一开始就很大，而是因为它在推进过程中不断冒出新的边界、验证和后续。

以购物车程序为例，
一个空购物车修复最初看起来只是单次任务，
但当它开始涉及测试、日志、兼容、回写和后续边界时，
它就已经变成长期项目的一部分了。

这时最重要的不是一次做完，
而是让每一轮都能：

• 看得清
• 改得准
• 验得过
• 留得住
• 接得上

这就是任务能继续往前走的原因。

下一章，我会继续讲：程序项目里最容易踩的坑是什么，以及控制层为什么会越修越重。