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 里收回来回到最小必要控制。这样项目才会真正进入一种健康状态稳定的地方不再被过度打扰高风险的地方仍然被重点看守状态文件保持清楚下一轮也能继续收敛下一章我会继续讲一次性任务是怎么演进成长期项目的以及为什么程序一旦开始长期运行就必须有可恢复、可暂停、可交接的结构。