核心论点前面多篇规则即代码 → 精准输入 → Plan 模式 → Agent 流水线 → Skills → 权限管控讲的都是在 IDE 里人在屏幕前用 AI 编码。但当 AI Agent 跑在 CI 流水线里、没人盯屏时方法论需要一套完全不同的设计——把人的判断力编码成流水线的检查点。从 IDE 到 CI问题的本质变了回顾前面多篇文章建立的工作流IDE 模式人在回路 你提需求 → AI 出方案 → 你审核 → AI 写代码 → 你 review diff → Accept CI 模式人在睡觉 PR 触发 → AI 自动审查 → AI 自动补测试 → AI 跑评估 → 输出报告在 IDE 里所有 AI 的产出都要过你的眼睛——你是最后一道防线。但在 CI 里AI 做判断、AI 改代码、AI 决定通过/不通过——你没有机会逐行审查。这不是要不要用 AI的问题——如果你的团队已经在用 AI 写代码PR Review 阶段大概率已经有 AI 生成的代码在里面了。问题是谁来 review AI 写的代码如果是另一个 AI——它凭什么比写代码的那个 AI 更可靠核心设计原则流水线里没有人但要有人的判断力Shop-Agent 项目把人的判断力编码成三条规则跑在 CI 里规则 1AI 只能提建议不能直接合入代码 规则 2AI 的判断必须有证据——不能只输出看起来没问题 规则 3同一个 AI 不能既写代码又审查代码角色隔离这三条规则贯穿 CI 流水线的三个关卡。关卡 1自动 PR Review——AI 的审查不可替代但必须可验证为什么需要 AI 做 PR Review人类 reviewer 容易疲劳漏掉规范一致性和性能模式匹配——命名规范、重复代码、N1 查询这类问题每次 PR 都该查但每次都要人逐行比对效率低容易遗漏。AI review 的优势恰好在此它读完了全部 rules 和组件清单不会漏、不会烦。但 AI review 不懂业务逻辑——它看不出这段代码在业务流程里是对是错。所以 AI review 的定位是辅助而非替代把规范检查交给 AI把业务判断留给人。怎么配置核心就两步——跑 code-reviewer Agent把结果贴到 PR comment。在 GitHub Actions 的 PR workflow 中加入cbc --agent code-reviewer \ --permission-mode acceptEdits \ --prompt Review this PR diff: $(git diff origin/main...HEAD) 输出审查报告分「严重问题」和「建议改进」两栏然后用github-script把输出的review-report.md贴到 PR comment 即可。必须做的三件事AI 只评论不合入——Comment 到 PR不自动 Approve输出分级——“严重问题” vs “建议改进”给人明确的优先级每次 PR 都跑——一致性 单次准确性关卡 2自动补测试——覆盖率驱动的闭环PR review 发现问题后一个常见的瓶颈是人改完代码测试没跟上。Shop-Agent 的做法pytest 跑完覆盖率之后如果低于 80% 阈值用cbc --agent test-generator把覆盖率 JSON 喂给 AI让它建议缺失的测试——但只输出建议不改代码。关键设计不是在 CI 里修代码而是在 CI 里标记为什么不在 CI 里自动合入 AI 写的测试AI 生成的测试可能 mock 错了对象、断言了错误的假设。测试代码比功能代码更需要人审——因为测试的 bug 比功能的 bug 更难发现测试过了不代表逻辑对。关卡 3安全门禁——无人值守的最后防线关卡 1 和 2 是在 CI 里跑 AI关卡 3 是在 CI 里限 AI。IDE 里你做rm -rf /会被自己拦住CI Runner 的权限可能更大——沙箱是唯一硬防线。《权限管控》篇讲了 deny/allow/ask 权限模型。CI 环境需要比 IDE 更严格denyEdit(.github/**)防止 AI 改 CI 配置denyEdit(.env*)/Read(.env*)防止碰密钥denyBash(curl:*)/Bash(wget:*)禁止外部下载外加 Sandbox 网络白名单只放行 pypi.org。CI 沙箱比本地沙箱更关键本地你做rm -rf /会被你自己拦住。CI 里 AI 跑在一个可能比本地权限更大的 Runner 上——沙箱是唯一硬防线。定时任务把 AI 放进 Cron三个关卡覆盖了 PR 触发流程但有些事不跟着 PR 走——技术债扫描、Agent 评估跑分这些适合按日历触发。《Skills 与 Automation》篇讲的 Automation 在这里有了新用途每周一AI 驱动的技术债扫描Cron 每周一触发跑同一个 code-reviewer Agent但检查维度不同——重复代码、未使用导入、异常处理不一致、缺少类型注解、超期 TODO/FIXME——输出 Markdown 报告不改代码。每日Ragas 评估指标跑分跑完 Ragas 评估脚本后用cbc --agent performance-optimizer对比昨日指标输出降幅最大的维度和修复建议。三个常见误区误区 1在 CI 里让 AI 自动修代码❌ CI → AI 发现规范问题 → AI 自动改 → 推新 commit → 再触发 CI → ... → 无限循环或者改出你不想看到的东西 ✅ CI → AI 发现规范问题 → 输出 Comment 建议把这里的 except: pass 改成 logger.warning → 人决定是否修误区 2AI 自动 Approve PR❌ AI review 通过 → 自动 merge → AI 不懂业务逻辑通过了不代表没有逻辑 bug ✅ AI review 通过 → 输出报告 → 人看报告 人看业务 → 人 merge → AI 辅助人不是替代人误区 3CI 里的 AI 和 IDE 里的 AI 用同一套权限❌ CI 里 allow 了 Bash(git:*) → AI 可以 force push CI 里 allow 了 Edit(*) → AI 可以改 CI 配置 ✅ CI 环境单独配 .codebuddy/settings.ci.json deny 一切危险操作只 allow 必要的读写路径投入顺序阶段做什么耗时效果本周给 PR 加 AI review comment30 分钟每次 PR 有自动规范检查下周加 CI 环境 deny 配置15 分钟防止 CI 中 AI 误操作本月加覆盖率驱动的自动补测试建议1 小时覆盖率稳步上升持续定时任务技术债扫描 评估每次 30 分钟持续监控代码质量核心要点CI 里的 AI 不能自动合入代码。产出应该是报告和建议最终决策权永远在人。CI 环境需要单独的权限配置——比 IDE 更严格。deny 所有危险操作只 allow 必要的路径。AI review 的优势在一致性——人类 reviewer 会疲劳AI 每次都检查同一条规范。把规范检查交给 AI把业务判断留给人。同一个 AI 不能既写代码又审查代码角色隔离——PR 里的代码可能是 AI 写的但 review 它的必须是独立的 Agent 调用。AI 补测试的价值是建议而不是直接合入——测试的 bug 比功能的 bug 更难发现AI 生成的测试必须经过人的二次确认。