AI渐进编程之十五：长期维护里，控制层怎么松紧？

前面一篇我们讲的是：程序任务通过以后，不能马上结束，
而是要把修复沉淀成长期维护的一部分。

这一篇继续往下，讲的是一个更细的问题：

当项目已经进入长期维护后，控制层到底应该继续收紧，还是可以适当放松？

本书的答案很简单：

• 稳定的地方可以放松
• 反复出问题的地方必须收紧
• 控制层不是一直加重，也不是一次性放掉
• 它要跟着风险变化
• 它也要跟着模型能力、测试能力和流程成熟度，逐步收缩到最小必要控制

这就是长期维护里的动态控制。

1. 为什么长期维护不能一直用同一套控制？

因为项目的状态会变。

一开始，一个地方可能经常出错，
所以需要很强的控制：

• 限制修改范围
• 强制回归测试
• 每轮都写日志
• 任何变化都要验收

但如果这个地方后来已经稳定了，
还一直用最重的控制，系统就会开始变笨：

• 每次改动都很重
• 简单修改也要走很长流程
• 人和 AI 都会觉得麻烦
• 控制成本超过了错误成本

所以，长期维护不能永远“一刀切”。
它要学会根据项目状态，决定哪里该继续收紧，哪里可以放松。
而且，随着模型能力增强、测试更成熟、状态更稳定，原本由Harness承担的一部分工作，也应该逐步被吸收到测试框架、静态规则和模型能力里去。

换句话说：

控制层不是越加越好，
而是先把任务稳住，再慢慢收回到最小必要控制。

2. 什么叫“收紧”？

收紧不是把系统锁死，
而是把风险大的地方看得更严。

比如购物车程序里，有些地方就要继续收紧：

• 结算入口
• 支付调用
• 库存扣减
• 幂等重试
• 边界条件判断

这些地方一旦出问题，影响就会比较大。
所以它们需要：

• 更明确的验收
• 更严格的测试
• 更清楚的状态回写
• 更谨慎的修改范围

收紧的目标不是让 AI 不动，
而是让它只在安全边界内动。

3. 什么叫“放松”？

放松不是放掉控制，
而是让已经稳定的部分少一些临时约束。

比如有些内容已经很稳了：

• 某个回归测试已经长期通过
• 某条规则已经写进项目地图
• 某个边界已经被确认不会再变
• 某些开放问题已经关闭

这时就没有必要继续每轮都重压这些内容。

可以适当放松的地方包括：

• 不再重复记录已经稳定的事实
• 不再对已确认区域做过多检查
• 不再为低风险修改开很重的流程
• 不再让临时状态长期保留

放松的目标是：
只保留当前任务真正需要的最小约束。

4. 购物车程序里，哪些地方该收紧，哪些地方可以放松？

还是用空购物车结算修复这个例子。

4.1 继续收紧的地方

这些地方风险高，不能松：

• 结算入口
• 支付接口
• 重试逻辑
• 空购物车边界
• 订单创建路径

原因很简单：
这些地方一旦放松，容易重新把问题放出来。

4.2 可以放松的地方

这些地方如果已经稳定，可以少管一点：

• 已经通过的回归测试
• 已经写好的修改日志
• 已经关闭的开放问题
• 已经固化的项目认知

这些东西不需要每轮都重新解释，
只要它们没有变化，就可以作为稳定背景保留。

4.3 能被吸收的控制

还有一类控制，不是简单地“收紧”或“放松”，
而是会随着项目稳定逐步被吸收掉。

比如：

• 某些边界检查最后会被测试覆盖
• 某些重复日志最后会被自动化记录替代
• 某些临时限制最后会变成稳定规则
• 某些人工确认最后会被静态校验接住

这类控制不是“永久保留”，
而是先用来救场，之后慢慢退回最小必要状态。

5. 怎么判断该收紧还是放松？

这本书不主张靠感觉，
而是看几个实际信号。

5.1 失败频率

如果某个地方总是出错，
说明它还不稳，需要继续收紧。

5.2 修改代价

如果改这里的风险很高，
那就说明它还不能放松。

5.3 状态是否稳定

如果相关状态文件长期没变、验证长期通过，
那说明可以适当放松。

5.4 是否仍然需要人工关口

如果一个地方每次都要人来救火，
那就不能放松，必须继续收紧。

5.5 是否已经被其他机制接管

如果某个检查已经被测试框架、静态规则或模型能力稳定承担，
那就可以把Harness里的那部分职责慢慢收回来。

6. 长期维护里最容易出的问题是什么？

最常见的误区有两个。

6.1 一直收紧

有些系统一旦出过一次错，
就从此把所有地方都加重控制。

结果就是：

• 简单任务也变得很重
• 小改动也要走长流程
• 控制成本越来越高
• 没人愿意继续维护

这会让系统越来越僵。

6.2 过早放松

另一种错误是，
任务刚刚稳定一点，就立刻把控制放掉。

结果就是：

• 临时补丁被当成长期规则
• 状态没写完整就结束
• 旧问题没关闭，新问题又冒出来
• 下一轮又要重新猜

这会让系统越来越散。

所以真正正确的做法是：

看风险决定控制强度，
不是看心情，也不是看习惯。

7. 一个最小的动态控制模板

如果把长期维护的控制层压缩一下，可以先这样理解：

maintenance_control:hot_zones:-checkout entry-payment call-retry logicstable_zones:-closed issues-passed regression tests-fixed project mappolicy:hot_zones:keep_strictstable_zones:reduce_noise

这个模板的重点不是格式，
而是它表达了一个很清楚的事实：

• 不是所有地方都要一样管
• 热点区域继续收紧
• 稳定区域可以放松
• 控制强度要跟风险匹配
• 已经被测试或规则接住的部分，可以逐步从 Harness 里退出来

8. 为什么动态松紧会让系统更稳？

因为它让控制层保持弹性。

如果系统永远只会变重，
它最后会变成一个没人愿意碰的重装系统。

如果系统永远只会变轻，
它最后又会变成一个没人能兜住风险的松散系统。

动态松紧的价值就在于：

• 把控制集中在真正危险的地方
• 把稳定区域从重复管理里释放出来
• 让状态文件保持精简
• 让下一轮更容易推进
• 让控制层最终回到最小必要状态

这就是长期维护真正该做的事：
让系统既不散，也不僵。

9. 状态文件在这个阶段怎么配合？

长期维护阶段，四个状态文件的角色也会变化。

project_map.md

继续保留长期认知，但只保留稳定部分。
已经确认的规则写进去，过时的信息要清理。

current_task.md

只负责这一轮具体要做什么。
任务结束后及时更新，不要让它变成历史堆积。

revision_log.md

记录这次为什么收紧，为什么放松，
哪些规则已经稳定，哪些还要继续观察。

open_issues.md

继续保留未解决但重要的问题，
但要定期清理，避免它变成杂项垃圾桶。

所以长期维护不是“加更多文件”，
而是让这些文件更有分工。

同时也要记住：
这些文件本身也像是给 AI 加的传感器。
当项目稳定下来以后，传感器不需要一直加厚，
而是要保持清晰、准确、够用。

10. 本章小结

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

程序进入长期维护后，控制层不应该永远同样重，也不应该一下子全放掉，而要根据风险动态调整松紧。

在购物车程序里，
应该继续收紧的，是结算、支付、重试和边界；
可以适当放松的，是已经稳定的状态、测试和认知。
而那些已经被测试、规则或模型能力稳定接住的部分，
则应该逐步从 Harness 里收回来，回到最小必要控制。

这样，项目才会真正进入一种健康状态：

• 稳定的地方不再被过度打扰
• 高风险的地方仍然被重点看守
• 状态文件保持清楚
• 下一轮也能继续收敛

下一章，我会继续讲：一次性任务是怎么演进成长期项目的，以及为什么程序一旦开始长期运行，就必须有可恢复、可暂停、可交接的结构。