Code Factory：如何配置你的仓库，让 AI 代理自动编写并审查 100% 的代码

确定性顺序不可动摇：预检门控必须在 CI 扇出前完成当前 HEAD SHA 匹配是铁律重跑请求只能有一个规范写入者审查摘要解析要把“漏洞语言”和“低置信度”总结都视为可行动项自动解决纯机器人对话能大幅降低噪音，但必须建立在当前 HEAD 干净证据之上只要守住严格的护栏，修复代理能把循环时间缩短好几倍。

紫微AI

759人浏览 · 2026-02-27 07:19:58

紫微AI · 2026-02-27 07:19:58 发布

Code Factory：如何配置你的仓库，让 AI 代理自动编写并审查 100% 的代码

在 AI 编码代理越来越强大的今天，很多团队已经实现了“代理写代码、人类只管验收”的工作流。但要真正做到 100% 自动化、零人工干预，还需要一套严谨的仓库治理机制。今天分享我们实际跑通的完整方案：让代理不仅能写代码，还能通过仓库内置的“风险感知 + 机器验证”闭环，实现自动审查、自动修复、自动合并。

我们的核心目标

打造一个真正的闭环：

编码代理负责编写代码
仓库在合并前强制执行风险感知检查
代码审查代理自动验证 PR
所有证据（测试、浏览器交互、审查结果）都可由机器验证
发现的问题自动转化为可重复的测试用例

具体用哪家审查代理都行——CodeQL + 策略逻辑、自定义 LLM，甚至其他服务都 OK。只要控制平面的模式不变，整个系统就能稳定运行。
在这里插入图片描述

高层流程：9 个关键步骤

1. 维护一个机器可读的统一契约

把所有规则写进一个 JSON 文件，作为整个仓库的“宪法”：

{
  "version": "1",
  "riskTierRules": {
    "high": [
      "app/api/legal-chat/**",
      "lib/tools/**",
      "db/schema.ts"
    ],
    "low": ["**"]
  },
  "mergePolicy": {
    "high": {
      "requiredChecks": [
        "risk-policy-gate",
        "harness-smoke",
        "Browser Evidence",
        "CI Pipeline"
      ]
    },
    "low": {
      "requiredChecks": ["risk-policy-gate", "CI Pipeline"]
    }
  }
}

这个契约定义了：

按路径划分的风险等级
各等级必须通过的检查项
控制平面变更的文档漂移规则
UI/关键流程的证据要求

有了它，脚本、工作流、策略文档再也不会“各说各话”。

2. 在昂贵 CI 之前先跑预检门控

可靠的做法是：

先执行 risk-policy-gate，快速验证策略是否合规、审查代理状态是否就绪。只有通过后，才启动测试、构建、安全扫描等并行任务。

这样能大幅节省 CI 分钟数，避免把时间浪费在已经被策略卡死的 PR 上。

核心代码逻辑大致是：

const requiredChecks = computeRequiredChecks(changedFiles, riskTier);
await assertDocsDriftRules(changedFiles);
await assertRequiredChecksSuccessful(requiredChecks);

if (needsCodeReviewAgent(changedFiles, riskTier)) {
  await waitForCodeReviewCompletion({ headSha, timeoutMinutes: 20 });
  await assertNoActionableFindingsForHead(headSha);
}

3. 严格遵守“当前 HEAD SHA”纪律

这是我们从真实 PR 循环里吸取的最大教训。

审查结果只有在完全匹配当前 PR 的 HEAD commit 时才有效。必须：

只等待当前 headSha 的审查检查
忽略所有旧 SHA 的陈旧总结评论
如果最新审查失败或超时，直接阻塞
每次 push/synchronize 后强制重新运行
通过在相同 HEAD 上重跑策略门控来清除旧失败状态

跳过这一步，就可能用“过期的干净证据”把问题代码合并进去。

4. 使用单一的“重跑请求”评论写入器 + SHA 去重

多个工作流同时请求重跑时，容易出现重复机器人评论和竞态条件。

解决办法：只让一个工作流作为规范的请求者，用标记 + sha:<head> 去重。

const marker = '<!-- review-agent-auto-rerun -->';
const trigger = `sha:${headSha}`;
const alreadyRequested = comments.some((c) =>
  c.body.includes(marker) && c.body.includes(trigger),
);

if (!alreadyRequested) {
  postComment(`${marker}\n@review-agent please re-review\n${trigger}`);
}

5. 添加自动化修复闭环（高杠杆，可选但强烈推荐）

当审查代理发现可操作问题时，自动触发修复代理：

读取审查上下文
打补丁修改代码
本地快速验证
把修复 commit 直接 push 到同一 PR 分支

然后让 PR 的 synchronize 事件触发正常的重新审查流程。关键是要保持确定性：固定模型和努力程度、跳过不匹配当前 HEAD 的陈旧评论、绝不绕过策略门控。

6. 仅在干净重跑后自动解决纯机器人对话

一个贴心的质量提升步骤：

当前 HEAD 重跑通过后
自动解决所有仅包含审查机器人评论的未解决对话
绝不自动解决有人类参与的对话

然后重新运行策略门控，让“必须解决所有对话”的规则及时更新。

7. 把浏览器证据当作一等公民

对于 UI 或用户流程变更，必须在 CI 中提供可验证的证据清单（而不仅仅是 PR 里的截图）：

要求的流程是否存在
是否使用了正确的入口点
登录态流程是否带上了正确的账号身份
产物是否新鲜有效

命令示例：

npm run harness:ui:capture-browser-evidence
npm run harness:ui:verify-browser-evidence

8. 用测试套件缺口循环保存“事故记忆”

生产环境回归 → 发现测试套件缺口 → 加入新用例 → 追踪 SLA

这样一次性的修复就能变成长期覆盖，知识不会随人员流动而丢失。

9. 我们跑了几个月后总结的最重要经验

确定性顺序不可动摇：预检门控必须在 CI 扇出前完成
当前 HEAD SHA 匹配是铁律
重跑请求只能有一个规范写入者
审查摘要解析要把“漏洞语言”和“低置信度”总结都视为可行动项
自动解决纯机器人对话能大幅降低噪音，但必须建立在当前 HEAD 干净证据之上
只要守住严格的护栏，修复代理能把循环时间缩短好几倍

10. 通用模式 vs. 具体实现

通用模式只有三个核心概念：

代码审查代理
修复代理
风险策略门控

我们自己的具体实现是：

审查代理：Greptile
修复代理：Codex Action
重跑工作流：greptile-rerun.yml
自动解决对话工作流：greptile-auto-resolve-threads.yml
预检策略工作流：risk-policy-gate.yml

如果你用别的审查工具，只需替换集成点，保持控制平面语义不变即可。

常用命令集（直接复制粘贴就行）

npm run typecheck
npm test
npm run build:ci
npm run harness:legal-chat:smoke
npm run harness:ui:pre-pr
npm run harness:risk-tier
npm run harness:weekly-metrics