AI 辅助编程熔断机制

AI 辅助编程的核心风险，不是偶尔生成一行错误代码，而是在缺乏充分确认时继续推进高风险动作：合并变更、引入依赖、扩大权限，甚至进入可能影响真实用户的发布流程。所谓“熔断机制”，就是预先定义自动化边界，一旦触及边界，AI 必须停止提交、合并、执行或发布，将控制权交还给人。

熔断并不等于拒绝 AI，而是限制它的下一步。较合理的流程可以分为生成建议、修改受控分支、创建合并请求和进入发布流程四个阶段。越接近合并与发布，自动化权限越应收紧；草拟、重构和补充测试可以保持较高效率，但涉及身份、权限、数据、外部依赖和发布边界时，不能继续自动推进。

四类必须停下来的信号

第一类是修改权限、身份或敏感操作路径，包括登录、角色判断、密钥读取、数据导出和删除逻辑。触发后应禁止自动合并和后续发布，保留完整变更记录，并标记权限差异。审核不能只由提交者完成，还应由负责业务权限模型的人确认：新增能力是否必要、权限是否被意外扩大、异常路径是否默认放行。

第二类是测试覆盖不足却准备合并。检查通过不代表关键行为已经得到验证。审核者需要明确变更影响了哪些行为，哪些已经验证，哪些风险仍未覆盖。代码负责人关注模块边界，测试责任人关注正常路径、失败路径和关键边界条件；无法说明清楚时，应保持阻塞或缩小改动范围。

第三类是新增或替换未知依赖。流程应停在“提出变更”，而不是自动接入。人工需要确认依赖是否必要、是否存在认可的替代方案、是否扩大数据传递或权限范围，以及由谁负责维护。新依赖最好先隔离在适配层，避免深度散落在核心业务代码中。

第四类是变更范围突然扩大。AI 为了“顺手修复”而改动多个模块，往往会使审查成本和验证范围超出原任务。此时应暂停自动合并，重新确认扩展是否必要；与原任务无关的重构应拆成独立变更，而不是一并推进。

熔断后的交接必须可执行

人工确认不能只留下“已审核”。记录至少应包含触发信号、停止动作、确认角色、必须回答的问题、恢复条件和回退方案。每次 AI 参与的变更也应保持小而可逆，避免与无关重构混在一起。这样出现判断不一致时，可以精确撤销某项改动，而不必回滚整组变更。

团队不宜一开始就拦截所有变化。优先覆盖权限改动、关键测试缺口、未知依赖和明显越界的修改，再根据触发记录调整规则。熔断机制的成熟标志，不是停止次数最多，而是每次停止都能说明为什么停、谁来确认，以及满足什么条件后才能继续。