CI 智能修复接入前：一次候选补丁失败带来的边界设计
把模型接进 CI 后，最危险的误解是把“能生成 diff”当成“能安全修复”。下面讨论的是一套设计思路，不对应某次真实线上事故；其中的分支、命令和字段需要按团队的 Git 平台、权限模型与构建工具调整。
先把写权限缩到最小
智能节点不应拥有主干、发布分支或开发者功能分支的写权限。它可以读取当前提交、生成补丁，并创建一个受限的候选分支，例如bot/candidate/<pipeline-id>。候选分支的保护规则应与普通分支不同：禁止强推、禁止自动合并，合并请求必须由代码所有者确认。
这样做不只是为了防模型“写错代码”。模型输入包含日志、报错片段和工作区文件，任何提示词注入、上下文过期或工具调用失败，都可能让生成结果偏离原任务。把输出停在候选分支，至少把影响范围固定在可比较、可删除的对象上。
一份补丁应留下哪些可核对的信息
复盘时最有用的不是一段笼统的“AI 已修复”日志，而是能将结果还原到某个提交的记录。每次运行可以保存：基础 commit SHA、允许修改的路径、提示词模板版本、模型响应摘要、完整 diff、测试命令及其退出码。日志中的访问令牌、客户数据和环境变量要先脱敏；原始内容若确有留存需要，应放入有访问控制和保留期限的存储，而不是随构建产物公开下载。
建议把这些字段写进一个 JSON 清单，并让候选 PR 链接到清单。审核人看到补丁时可以先问三个具体问题：它基于哪个版本生成？改到了允许范围之外吗？验证命令是否真的在该 diff 上执行过？答不上来就不应进入合并队列。
验证不能只看编译通过
候选补丁的检查应分层进行。第一层做静态限制，例如拒绝改动 CI 配置、依赖锁文件和密钥相关目录；第二层运行格式化、类型检查与目标测试；第三层用git apply --check或干净工作区重新应用 diff，防止生成器在旧上下文中产出的补丁被误当成当前代码。
如果修复建议涉及数据库迁移、权限判断或删除数据，自动流程应止步于“提出建议”。这些变更即使测试全绿，也需要人工评估回滚路径和数据影响。模型可协助归纳失败原因，但不能代替变更审批。
失败时怎样收口
失败记录同样需要保留：是解析失败、补丁无法应用、测试失败，还是触发了路径策略。构建结束时应删除临时工作区和短生命周期凭据；候选分支可设置过期清理，但要保留必要的审计元数据。对同一任务多次重试时，必须以当前 commit 重新取上下文，不能复用旧 diff 直接推送。
CI 智能化的收益来自缩短定位和草拟修改的时间，而不是把代码合并权交给生成器。先有受限输出、可追溯记录和人工闸门，模型生成的补丁才值得进入评审流程。
一个简单的验收办法是故意让候选补丁修改受保护目录，并确认策略会拒绝它且留下可读原因；再让测试失败，确认不会产生任何合并动作。这样的反例测试比单纯观察一次成功构建更能证明闸门存在。
