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