机制分析
一条过于严格的规则，也可能是坏提案
案例从一次假绿灯失败出发：执行方改写了测试，原验收规则只看通过数量与环境条件，不能可靠识别问题。新提案需要检查测试依据、任务归属、代码版本与报告完整性。失败原件先留档，现行规则暂时不动。
第一份提案额外要求“只接受第二版代码”。熟悉的目标样例都使用第二版，因此检查全过。保留组加入后续第三版的合法交付，这个规则却错误拒绝。它记住了具体版本号，未表达真正的约束：报告应属于当前代码，而不是只能属于某一个固定号码。
修订后，规则改查任务与证据是否一致，不再写死版本。提案一变，旧验证凭据清空，再运行两组检查，最后让新版与对应凭据一起发布。测试结果属于特定提案，不能拿旧提案的报告为新规则背书。
| 阶段 | 允许改变什么 |
|---|---|
| 收集失败 | 增加原始记录与问题线索，现行行为不变 |
| 提出候选 | 修改隔离的待验证规则 |
| 运行目标与保留任务 | 生成候选对应的检查结果，失败则拒绝发布 |
| 受控发布 | 切换现行版本，同时保留上一稳定版 |
| 发现运行异常 | 暂停自动交付，按原因决定回滚及后续恢复 |
保留组被用来修订后，还独立吗？
第一次检查时，第三版样例没有参与提案设计，可以暴露熟悉样例之外的问题。一旦看过结果并据此修改规则，这组样例就成为已知回归用例。再次通过能证明这些已知问题得到修复，不能继续作为未见任务上的独立泛化证据。
工程取舍
改哪里，比“让系统学习”更具体
知识、指令、程序，还是参数？
缺少资料，可以考虑更新知识；流程说明不足，可以修改指令或 Skill；有明确可执行约束，可以调整程序或 Harness。需要改变模型行为时，才进一步评估参数更新的数据与验证条件。这些载体不是可互换的按钮：补一条说明不等于模型保证遵从，保存一份知识也不等于已经训练权重。本页只有程序规则路线实际运行回归。
多快接受一次经验？
快速修复能降低已知失败的持续成本，却也可能把偶然特征固化成新约束。对可逆且影响有限的规则，可以小范围验证后逐步使用；影响广的更新需要更广的任务覆盖与观察。任何做法都应明确当前检查范围，不能把本例八个固定样例换成一个泛化能力分数。
异常时回滚，还是先恢复外部服务？
演示在发布后模拟证据服务超时。回滚恢复的是本地规则版本，不会修好外部依赖，所以自动交付仍保持暂停。真实系统应先辨认异常来源：若故障来自新逻辑，回滚可能直接有用；若来自外部服务，仍需恢复依赖并重新验收。不能把“版本已回退”当作“任务已恢复”。
落到实现
让提案、证据和生效版本相互对应
更新记录应能回答：依据哪次失败、改变哪个载体、运行哪些检查、谁批准生效、异常时退回哪里。提案隔离与验证凭据失效规则，可以由程序明确执行，减少未经验证的经验直接进入现行系统的机会。
本页只改变浏览器中的规则对象，没有模型采样、梯度更新或真实服务器发布。目标和回归判断来自固定标签；真实系统仍需新的独立评估与运行验证。示范与奖励也各有数据质量和目标偏差问题，不能由一次演示替代完整训练与发布过程。
经验的价值，需要通过可检查的更新体现出来。保留失败、隔离提案、验证回归和观察运行，才让下一版系统的改变有据可循。