前面几篇我们已经把程序项目里最重要的几件事说清楚了任务可以从prompt开始复杂后可以加Harness任务推进需要state状态机和SIADOS负责让任务一轮一轮往前走工作台负责把代码、状态和验收分开摆好长期维护负责让通过后的结果继续稳定长期项目负责让每次运行都能接着上一次继续这一篇是收束章。它不再讲新机制而是讲一个更现实的问题控制层用久了最容易在哪些地方变坏因为Harness、状态文件、验收和回写本质上都像是给 AI 加的一组传感器。传感器一旦失真AI 就会看错控制规则一旦腐烂项目就会越修越乱。所以本章要讲的不是“怎么继续加控制”而是怎么识别控制层开始变坏并及时瘦身。1. 反模式不是零散错误而是重复失效方式这里说的“反模式”不是某一次手滑而是控制层在长期运行中最容易重复出现的坏法。它们有一个共同点一开始看起来合理用一段时间以后开始失真最后会让系统更难维护以购物车程序为例一开始只是修空购物车结算后来如果不整理就可能变成规则越来越多状态越来越旧日志越来越空任务越来越漂人越来越累Harness越来越重这不是偶发问题而是控制层在长期运行中的典型失效方式。2. 反模式一规则膨胀它是什么每次出错系统都再加一条规则不能改这个文件不能碰那个路径不能在这种情况下提交不能使用某个词不能扩展到别的模块它怎么出现某个问题刚出现时新增一条禁令确实能挡住。但随着问题越来越多规则会越叠越厚。它为什么危险最后系统会变成规则互相重叠优先级说不清新人看不懂老人记不住怎么判断已经发生每次都要翻很长一份规则同一个约束被写了好几遍新规则一加旧规则就忘了怎么修合并重复规则分层管理规则删掉被测试完全覆盖的规则保留最核心的边界3. 反模式二状态老化它是什么project_map.md、current_task.md、revision_log.md、open_issues.md长时间不更新开始和真实项目脱节。它怎么出现项目改了但状态文件没跟着改。下一轮读到的是旧事实不是当前事实。它为什么危险AI 会把旧信息当成当前信息然后在错误的前提上继续推进。怎么判断已经发生地图里的路径已经不存在了当前任务已经结束但文件还挂着旧目标开放问题堆了很多但没人清理修改日志只剩过程没了结果怎么修把状态文件当作活的输入不是档案每轮结束后回写事实定期清理过期条目给关键路径加新鲜度检查4. 反模式三日志空心化它是什么日志看起来很多实际上没什么信息。它怎么出现人和 Agent 习惯写今天修了一些问题优化了部分逻辑做了若干调整看起来更稳定了它为什么危险下一轮根本不知道为什么改改了什么哪些验证过了还有什么没解决怎么判断已经发生日志很长但没人愿意读日志里只有过程没有决策日志不能帮助恢复上下文怎么修好的日志应该回答四件事为什么改改了什么验证如何下一步是什么以购物车为例比“今天修了结算问题”更有用的是空购物车路径已修复正常结算未受影响支付接口未被误调用旧调用方行为仍待确认重试路径需补回归测试5. 反模式四任务漂移它是什么本来这一轮只该修一个点但 Agent 在执行中把建议自动升级成了新任务。它怎么出现Agent 发现了一个顺手可以做的事顺便补一个 dashboard顺便重构一下结构顺便把文档也整理了顺便把别的模块也修了它为什么危险任务边界开始膨胀一轮变成多轮局部修改变成全局扩散。怎么判断已经发生一开始只修购物车后来改到支付、库存、文档计划越来越长但当前任务没真正收束每次都在“顺便”却很少真正完成怎么修建议和任务分开建议写进open_issues.md是否升级任务由人或调度器决定当前轮只做已授权范围6. 反模式五人工过载它是什么每一步都要人确认最后人开始机械点头。它怎么出现为了防止越界系统把所有动作都交给人审核每个文件都要确认每次 patch 都要点头每条命令都要审核每个修改都要解释它为什么危险人会疲劳会把高风险动作和低风险动作混在一起最后真正该拦的反而被放过。怎么判断已经发生人开始无意识地批准低风险动作真正关键的动作因为太多确认而被淹没团队越来越依赖“盯着看”怎么修只在人类真正需要介入的地方设关口让人看方向不是看每一次呼吸低风险动作批量授权高风险动作单独确认7. 反模式六Harness 肥胖它是什么Harness一开始很轻后来越来越重。它怎么出现随着失败案例增多系统不断补规则、补例外、补检查、补状态。它为什么危险最后虽然更严谨了但维护成本也越来越高系统开始变得难用。怎么判断已经发生规则越来越多检查越来越慢新人一看就头大简单任务也要走很重流程怎么修合并重复规则删除已被测试覆盖的规则把一次性事故规则迁进回归样例定期审查哪些规则已经没有必要8. 购物车程序里的反模式长什么样还是用空购物车结算这个例子。假设最开始只是修一个边界但后来系统变成这样project_map.md还写着旧路径current_task.md没有及时更新revision_log.md只记了“优化”open_issues.md堆了一堆没整理的猜测验收规则越来越长新规则不断加旧规则不删除这时系统看起来很完整但实际上已经越来越不好维护了。这就是控制层腐烂的典型征兆。9. 怎么让控制层保持健康可以记住四个字分层系统边界、项目不变量、当前任务约束要分开看。去重重复规则合并重复状态清理重复日志删减。归档已经解决的问题要关闭过期信息要归档。瘦身超过收益的规则要删超过必要的检查要减。这四个动作做对了控制层就不容易变成负担。10. 一个最小的瘦身模板rule_review:keep:-scope boundary-acceptance checks-critical safety rulesmerge:-duplicated file guards-repeated log notesarchive:-stale open issues-obsolete pathsremove:-rules covered by tests-rules no longer needed这个模板的重点不是格式而是它表达了一个很清楚的事实规则要有生命周期旧规则不是永远保留被测试覆盖的规则可以减少重复失效的规则应该删掉11. 本章小结这一章想讲清楚的核心是程序项目里的控制层不是越加越强而是要不断识别哪些地方该保留、哪些地方该合并、哪些地方该删除。以购物车程序为例最容易踩的坑就是规则越加越多状态越来越旧日志越来越像流水账建议自动升级成任务人类被迫频繁救火Harness越来越重所以长期维护真正要做的不只是加控制而是让控制一直保持有效。这也就是这本书最后真正想说的不是把系统管得越来越死而是让它在变化里依然能稳稳地往前走。