AI 编码进入 CI 流水线——自动 PR Review 与无人值守安全执行

暗黑小白

52人浏览 · 2026-07-01 10:56:18

暗黑小白 · 2026-07-01 10:56:18 发布

核心论点：前面多篇（规则即代码 → 精准输入 → 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 里：

规则 1：AI 只能提建议，不能直接合入代码
规则 2：AI 的判断必须有"证据"——不能只输出"看起来没问题"
规则 3：同一个 AI 不能既写代码又审查代码（角色隔离）

这三条规则贯穿 CI 流水线的三个关卡。

关卡 1：自动 PR Review——AI 的审查不可替代，但必须可验证

为什么需要 AI 做 PR Review

人类 reviewer 容易疲劳漏掉"规范一致性"和"性能模式匹配"——命名规范、重复代码、N+1 查询这类问题每次 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 更严格：deny Edit(.github/**) 防止 AI 改 CI 配置，deny Edit(.env*) / Read(.env*) 防止碰密钥，deny Bash(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" → 人决定是否修

误区 2：AI 自动 Approve PR

❌ AI review 通过 → 自动 merge
   → AI 不懂业务逻辑，通过了不代表没有逻辑 bug

✅ AI review 通过 → 输出报告 → 人看报告 + 人看业务 → 人 merge
   → AI 辅助人，不是替代人

误区 3：CI 里的 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 comment	30 分钟	每次 PR 有自动规范检查
下周	加 CI 环境 deny 配置	15 分钟	防止 CI 中 AI 误操作
本月	加覆盖率驱动的自动补测试建议	1 小时	覆盖率稳步上升
持续	定时任务（技术债扫描 + 评估）	每次 30 分钟	持续监控代码质量