AI Coding Agent 独立验收层：为什么 Codex/Claude Code/Cursor 写完代码不能自己给自己 Review

AI Coding Agent 可以自检，但不应自己决定上线。本文用五个独立维度和 L0-L4 成熟度模型，设计从生成 Agent、确定性 CI、独立 Review、浏览器 QA 到人工合并的生产级验收层。

摘要： Codex、Claude Code、Cursor 写完代码后当然可以运行测试、检查 diff、甚至启动专门的 Review 功能；问题不在“能不能自检”，而在“能不能成为自己改动的唯一放行者”。同一 Agent 往往共享原始需求、实现假设、测试资产、工作目录和修改权限，容易把“证明我写对了”误当成“主动寻找我哪里写错了”。生产级方案应把生成与验收拆开：生成 Agent 只交付补丁和证据，确定性 CI、受保护测试、独立 Review Agent、浏览器 QA 与 Human Approval 分层决定能否合并。

核心结论

AI Coding Agent 可以给自己做 Review，但不应只让它自己决定“可以上线”。更准确的说法是：

自检是开发步骤，独立验收才是放行控制。

同一会话里的 Agent 适合快速发现编译错误、明显回归和格式问题；新会话或子 Agent 能增加上下文隔离；真正可作为合并门禁的验收，还要同时隔离测试规则、执行环境、修改权限和证据来源。

层级	做法	能发现什么	主要盲区	是否适合单独放行
L0 自检	写代码的同一 Agent 跑测试、看 diff	语法、类型、已有测试失败	共享假设与目标；可修改测试	否
L1 新会话	同模型、同工具，但清空会话	降低实现过程带来的确认偏差	仍可能共享仓库规则、环境、权限	否
L2 独立 Agent	独立 Prompt、只读代码、只写报告	规格偏差、回归、风险点	若测试和环境仍由作者控制，独立性有限	低风险可作信号
L3 独立流水线	受保护 CI、隐藏测试、干净环境、浏览器 QA	环境差异、端到端故障、测试投机	业务判断与高风险授权	中低风险可门禁
L4 人工放行	代码所有者、业务、安全或合规审批	意图、责任、例外、不可逆风险	成本和排队时间	高风险必需

这不是对任何一个产品能力的否定。OpenAI 官方把 Codex Code Review 定位为 PR 上“另一轮高信号 Review”，同时明确说明 Review 规则不能替代测试、分支保护和必需审批；Codex CLI 也支持对未提交改动、单个提交或基准分支执行不修改工作树的专用 Review。Cursor 提供 Agent Review、Bugbot 与 Security Agents；Claude Code 则可通过 Hooks、权限和 GitHub Actions 组装确定性门禁。工具已经具备 Review 能力，但治理责任仍在团队。

六段式验收流水线与受保护测试。

为什么“写代码的人自己 Review”会失效

1. 上下文耦合：它记得自己为什么这样写

生成 Agent 读过需求、讨论、错误日志和自己的推理路径。Review 时，它很容易沿用同一套解释框架。例如它已经认定“访客不会触发这个接口”，便可能忽略权限校验；已经选择某个缓存策略，就更容易把异常结果解释成测试环境问题。

新会话能减轻这一点，但只有当 Reviewer 先看到需求、基线和 patch，而不是先看到作者的辩护与结论时，才形成有效的“盲审”。

2. 目标耦合：完成任务与推翻成果发生冲突

写代码的目标通常是“完成修复并让测试通过”。验收的目标却应是“尽可能证伪改动满足要求”。Author Prompt 关注最小修改、实现速度和兼容性；Reviewer Prompt 关注反例、边界条件、未覆盖路径和残余风险；Release Gate 只认机器可验证的证据与明确审批。

如果把三种角色塞进同一个“修好并确认没问题”的任务，Agent 很容易在看到绿灯后提前停止。

3. 测试作者耦合：测试可能只证明实现符合实现

最危险的假绿不是“没跑测试”，而是“新增测试和新增实现共享同一误解”。典型表现包括：

Mock 掉了真正会失败的网络、数据库或浏览器行为；
只验证 happy path，没有权限、重试、并发或回滚；
Snapshot 被直接更新，视觉回归因此消失；
为了通过 CI，弱化断言、跳过用例或修改 fixture；
根据当前输出编写 golden file，形成循环证明。

因此验收测试至少要有一部分由团队、独立 Reviewer 或生产事件反推生成，并放在作者无权修改的目录或独立仓库中。

4. 环境耦合：同一工作区会隐藏真实问题

Agent 在自己的工作树里编译、测试，可能复用缓存、已安装依赖、本地数据库、登录态和未提交文件。换到干净 Runner、空数据库、全新浏览器 Profile 或不同操作系统，问题才暴露。

5. 权限耦合：Reviewer 若能改答案，就不再是门禁

生产 Review Agent 最好默认对产品代码和受保护测试只读；只能写结构化报告、PR Comment 或专用 artifact；无权绕过 required checks；无权批准自己或同一自动化身份生成的 PR。修复必须回到 Author 分支，并触发一轮全新的验收。

6. 证据耦合：作者不应自己挑选证据

“我跑过测试，全部通过”不是可审计证据。验收层应自行生成并保存命令、环境指纹、测试报告、浏览器轨迹、截图、覆盖率、依赖扫描结果和 commit SHA，且失败日志不可被作者删改。

五个维度同时独立，才叫独立验收

维度	弱隔离	强隔离	推荐控制
上下文	同一会话自我复盘	Reviewer 只读规格、基线与 patch	不先喂作者结论；独立 Context
指令	“检查一下有没有问题”	风险清单、反例目标、输出契约	Reviewer Prompt 版本化
环境	作者工作目录	从 SHA 创建临时 Runner/VM	清缓存、空数据库、新账号
权限	可改代码、测试和门禁	代码只读，仅写报告	最小权限、分支保护、CODEOWNERS
证据	作者摘要	CI 原始报告与不可变 artifacts	哈希、时间戳、保留策略

“换一个模型”只是可选增强，不是独立性的定义。同一个模型在全新上下文、只读权限、独立测试和干净环境里，可能比另一个模型在同一工作区、同一 Prompt、同一权限下更独立。

Codex、Claude Code、Cursor：Review 能力怎么放到正确位置

工具	官方可用能力	适合放在哪一层	配置提醒
Codex	GitHub PR Code Review、Security Review、CLI 本地 Review、GitHub Action	L1-L3 的 Reviewer 与 CI 信号	用 AGENTS.md 固化 Review 规则；不要替代测试、分支保护和 Required Approval
Claude Code	Hooks、权限规则、GitHub Actions、自定义 Agent	L1-L3 的专用 Reviewer 与确定性门禁	用 Hook 强制命令或阻止危险操作；Reviewer Token 只给只读权限
Cursor	Agent Review、Bugbot、Security Agents、Subagents、Cloud Agents	本地快速 Review、PR Review、云端隔离验证	子 Agent 有独立 Context，但若同一父任务选择证据和接受结论，仍不等于最终独立验收

OpenAI 官方文档显示，Codex 可通过 @codex review 对 PR diff 进行标准 Review，并可依据 AGENTS.md 中的仓库规则工作；Codex GitHub Action 还能把重复 Review 任务放进 CI。Cursor 官方说明 Agent Review 是对本地改动运行的专用 Review，Bugbot 可在 PR 上找 bug，Subagent 拥有独立 Context，云端 Subagent 还能使用自己的 VM 和分支。Claude Code Hooks 则适合把必须发生的验证变成确定性命令，而不是只依赖模型“记得执行”。

Review 产品功能与独立验收架构不是同一个概念。 即便界面上叫“Agent Review”，团队仍需确认它是否拥有独立输入、受保护规则、独立环境、只读权限和不可自行合并的身份。

上下文、指令、环境、权限与证据五维隔离。

推荐架构：六段式放行流水线

生成 Agent：只在功能分支或独立工作树中修改代码。
证据包：提交 patch、需求映射、自测命令、已知限制与 commit SHA。
确定性 CI：运行 lint、typecheck、unit、integration、安全与依赖检查。
独立 Review Agent：从新上下文读取规格和 diff，专门寻找反例。
浏览器 QA：在新 Profile、测试账号和可控数据中跑关键业务流程。
人工合并：高风险改动由代码所有者、业务 Owner 或安全人员批准。

失败后的流程不能让 Reviewer 在原地悄悄改完并宣布通过。Reviewer 应创建 finding，Author 修复，新 commit 重新触发完整流水线。这样每次 PASS 都对应一个可复现的代码版本。

第一步：定义可执行的验收契约

# acceptance/contract.yaml
version: 1
required_checks: [lint, typecheck, unit, integration, security]
protected_assets:
  - acceptance/**
  - tests/golden/**
  - .github/workflows/acceptance.yml
reviewer:
  code_access: read_only
  can_modify_tests: false
  can_approve_merge: false
human_approval:
  required_when:
    - auth_or_permissions
    - payments
    - production_data
    - schema_migration
    - secrets_or_network_policy

验收项必须映射到风险，而不是机械追求覆盖率数字。例如修改 WordPress 权限逻辑时，100% 行覆盖率也不能替代“匿名用户、低权限用户、管理员、过期 nonce”四种身份测试。

第二步：保护测试、工作流与合并权

# .github/CODEOWNERS
/acceptance/                      @org/qa-owners
/tests/golden/                    @org/qa-owners
/.github/workflows/acceptance.yml @org/platform-security
/src/auth/                        @org/security-owners
/src/payments/                    @org/payments-owners

再启用 PR 合并、Required Status Checks、Code Owner Approval、禁止 Force Push、新 commit 撤销旧 Approval，以及自动化作者不能批准自己的 PR。CODEOWNERS 只是路由规则，必须和分支保护或 Ruleset 一起使用。

第三步：用 GitHub Actions 建立独立执行环境

name: independent-acceptance
on:
  pull_request:
    types: [opened, synchronize, reopened]
permissions:
  contents: read
jobs:
  deterministic-gates:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - uses: actions/checkout@v5
        with:
          persist-credentials: false
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm run test:unit -- --ci
      - run: npm run test:integration
      - run: npm audit --audit-level=high
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: acceptance-evidence
          path: |
            reports/**
            test-results/**

不要给验收 Job 默认写权限。需要发 PR 评论时，最好拆成第二个受控 Job：它读取已生成的报告，只拥有 pull-requests: write，且不执行 PR 中的任意脚本。

第四步：给 Reviewer 一份“证伪式”提示词

角色：你是独立验收 Reviewer，不是实现者。
输入：原始需求、验收标准、基线与候选 commit、完整 diff、CI 原始报告。
约束：
- 不采信作者的“已经完成”结论；
- 不修改产品代码、测试、快照、CI 或验收规则；
- 优先寻找能推翻正确性的最小反例；
- 每个 finding 给出位置、复现、实际结果与预期结果；
- 证据不足时输出 NEEDS_HUMAN，不得猜测 PASS；
- 只输出符合 schema 的 JSON。
重点：需求遗漏、权限、输入验证、秘密、并发、重试、幂等、事务、回滚、
兼容性、迁移、性能、可观测性，以及测试是否真正覆盖风险。

推荐输出：

{
  "status": "FAIL",
  "reviewed_commit": "abc1234",
  "findings": [{
    "severity": "P1",
    "title": "低权限用户可绕过导出限制",
    "location": "src/export.ts:84",
    "evidence": "role=viewer 调用 POST /export 返回 200",
    "reproduction": ["创建 viewer", "发送请求", "检查响应与审计日志"],
    "expected": "返回 403，且不创建导出任务"
  }],
  "coverage_gaps": ["未验证任务重试后的幂等性"],
  "residual_risk": "需要业务 Owner 确认历史 viewer 是否允许导出"
}

第五步：把浏览器 QA 独立出来

浏览器 QA 应使用全新 Profile 和专用测试账号；从 seed 脚本创建已知数据；记录 trace、截图、console、network 和视频；覆盖成功、失败、超时、刷新、重复提交和窄屏；测试后销毁账号和临时数据。

import { test, expect } from '@playwright/test';
test('viewer cannot export customer data', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill(process.env.QA_VIEWER_EMAIL!);
  await page.getByLabel('Password').fill(process.env.QA_VIEWER_PASSWORD!);
  await page.getByRole('button', { name: '登录' }).click();
  await page.goto('/customers');
  await expect(page.getByRole('button', { name: '导出' })).toBeDisabled();
  const response = await page.request.post('/api/export', {
    data: { scope: 'all_customers' }
  });
  expect(response.status()).toBe(403);
});

WordPress、n8n、前端项目分别怎么验收

WordPress 修复

风险面	独立验收项
安装与升级	全新站点激活、旧版本升级、停用/重启、卸载清理
权限	匿名、Subscriber、Editor、Administrator 分别测试
安全	nonce、capability、escape、sanitize、prepared SQL
兼容	支持的 PHP/WordPress 版本矩阵；无调试告警
数据	真实数据库事务、重复执行、失败回滚
前端	后台页面、Block Editor、移动端与关键插件共存

尤其不要只在已有 WordPress 容器中验证。独立 CI 应从空数据库安装，并再从上一正式版升级一次。

n8n 节点与工作流

风险面	独立验收项
凭据	日志和错误不泄露 Token；权限最小化
数据映射	多 item、空 item、binary、pairedItem 保持正确
稳定性	429/5xx 重试、退避、超时、分页、断点续跑
幂等	webhook 重放、队列重试不产生重复副作用
可迁移	导出 JSON 后在干净实例导入并运行
表达式	pinned data 与真实运行数据行为一致

验收者应导入“发布包”而不是作者当前编辑器状态，才能发现未保存凭据引用、节点版本或环境变量依赖。

前端 QA

独立层至少覆盖 Chromium、Firefox、WebKit；360px、768px 与桌面宽度；键盘和焦点；慢网、断网、500、空数据和超长文本；水合、缓存、后退、重复提交；Console Error、失败请求、性能预算与视觉回归。若写代码的 Agent 同时更新了全部截图基线，截图测试便失去意义，基线变更应独立审批。

风险分级：不是每个 PR 都要最高规格

风险	示例	最低门禁
低	文案、注释、非执行文档	L0 自检 + 确定性 CI
中	普通 UI、非核心 API、依赖小版本	L2 独立 Review + CI
高	权限、支付、数据导出、数据库迁移	L3 + 安全 Review + 人工 Owner
极高	生产删除、密钥、基础设施、合规决策	L4 双人审批、演练、回滚与变更窗口

成本优化的方向不是取消独立验收，而是按风险路由：小改动使用快速 Review，大改动和敏感目录自动升级为 Deep Review、隐藏测试和 Human Approval。

更多 Agent 工程实践可参考 AI Stack Nav；团队建立自动化流水线时，也可从 AI 工具导航选择编排与测试工具。

常见失败模式与修复

失败模式	为什么危险	修复
同一 Agent 说“测试都过了”	证据由作者选择	CI 自行生成原始报告
换一个模型就算独立	环境、权限与测试仍共享	同时隔离五个维度
Reviewer 自动修复并直接合并	角色重新耦合，审计不清	修复回到 Author，重新验收
只做 LLM Review，不跑测试	模型无法替代运行时证据	确定性检查先于模型 Review
只跑单测，不做真实流程	Mock 掩盖集成与 UI 故障	临时环境 + 浏览器 E2E
Agent 可改 Workflow 和基线	可弱化门禁制造绿灯	CODEOWNERS + 分支保护
所有 PR 都走重型流程	成本高、团队会绕过	按路径和风险动态升级

上线前检查清单

Author 和 Reviewer 使用不同任务身份；
Reviewer 从干净上下文开始；
验收标准和 Prompt 已版本化；
受保护测试、快照与 CI 文件需要独立 Owner；
CI 从 commit SHA 在临时环境重建；
Reviewer 默认只读代码，只写报告；
报告包含位置、证据、复现和严重级别；
浏览器 QA 使用新 Profile 和专用账号；
每次修复都触发完整重验；
高风险路径需要人工批准；
自动化身份不能批准自己的 PR；
PASS 绑定到唯一 commit，证据可追溯。

FAQ

1. 同一个 Codex/Claude Code/Cursor 开一个新会话，算独立 Review 吗？

算“上下文独立”的增强，但不是完整独立。还要检查它是否共享作者的测试、缓存、工作目录、密钥、写权限和合并权。适合作为 L1，不应自动等同于 L3。

2. 使用不同模型能解决自我 Review 偏差吗？

能增加错误模式的多样性，但不能解决权限和环境问题。不同模型若都只看作者挑选的日志，或都能修改验收测试，仍不是可靠门禁。

3. 子 Agent 是否天然独立？

不天然。独立 Context 是好起点，但父 Agent若决定给它看什么、是否采纳结论、还能改掉测试，整体系统仍由同一控制面主导。关键验收最好由外部 CI 事件触发。

4. AI Review 能替代人类 Code Review 吗？

低风险、规则明确的变更可以让自动门禁承担更多工作；权限、支付、生产数据、架构取舍和合规判断仍需责任明确的人类批准。人类不必逐行重复机器检查，但要掌握最终授权。

5. Reviewer Agent 应该允许自动修复吗？

可以提出 patch，甚至在独立修复分支生成候选改动，但不能在同一验收记录中“修完即通过”。修复应产生新 commit，再由全新验收运行判断。

6. 隐藏测试会不会导致开发体验差？

隐藏测试不应隐藏需求，只应保护关键反例和测试资产。公开验收标准、公开大部分测试，保留少量防投机和高风险回归用例，通常能兼顾反馈速度与可信度。

7. 小团队没有专职 QA，怎么开始？

先做三件事：把 CI 与作者工作区分开；保护 Workflow/关键测试；用新会话、只读权限的 Reviewer 输出结构化报告。之后再逐步增加浏览器 QA 和风险审批。

8. 最重要的指标是什么？

不要只看“Review 发现了多少问题”。更重要的是逃逸缺陷率、误报率、修复后复发率、从提交到可信 PASS 的时间，以及高风险变更是否全部有完整证据与审批。

事实依据与来源

OpenAI：Review GitHub pull requests with Codex——Codex PR Review、AGENTS.md Review 规则，以及不能替代测试、分支保护和必需审批的说明。
OpenAI：Codex GitHub Action——在 CI 中运行可重复的 Codex Review 与质量门禁。
OpenAI：Codex CLI——对未提交改动、commit 或基准分支运行专用 Review。
Anthropic：Claude Code Hooks——生命周期事件上的确定性命令与控制。
Anthropic：Claude Code Permissions——允许、询问与拒绝规则。
Anthropic：Claude Code GitHub Actions——GitHub 工作流和最小权限。
Cursor：Agent Review——本地改动的专用 Review 与 Quick/Deep 深度。
Cursor：Bugbot——PR Review 与 Autofix 分支策略。
Cursor：Subagents——独立 Context、专门 Prompt/工具/模型和 Cloud VM/分支。
Cursor：Agent Security——命令批准与 best-effort guardrails 边界。

工具评测文章

工具选型与提示词资料

适合阅读工具评测、工具推荐、对比测评类文章后继续转化。

工具选型表 按场景、价格、上手难度和核心能力筛选合适的 AI 工具。 查看资料包 提示词模板包 提供写作、运营、编程、图片和视频生成常用提示词模板。 查看资料包