# 代码评审

> 核对结果，处理 review 意见，批准最终要合并的改动。

开发与评审 · /zh/code-review/ · 2026-11-05

## 1. 运行 PR 评审

**Codex**

```text
$neutron:pr-review 对照关联的 Jira ticket 评审 [PR 链接]。通过已连接的 Jira MCP 或已认证的 acli 读取描述、验收标准和评论；访问不了就让我贴详情。
针对 PR 当前的 commit 给出具体的 review 意见，让作者能据此修复问题。每条附上文件和行号、影响、支撑证据，以及验证缺口。评审保持只读。
```

**Claude Code**

```text
/pr-review 对照关联的 Jira ticket 评审 [PR 链接]。通过已连接的 Jira MCP 或已认证的 acli 读取描述、验收标准和评论；访问不了就让我贴详情。
针对 PR 当前的 commit 给出具体的 review 意见，让作者能据此修复问题。每条附上文件和行号、影响、支撑证据，以及验证缺口。评审保持只读。
```

- 在全新的评审会话里运行这个 skill，提供 PR、ticket 和仓库说明，让 agent 独立做出判断。
- 确认评审针对的是 PR 的最新 commit 和正确的 [Jira ticket](/zh/deliver-a-change/#1-understand-the-ticket)。
- 优先关注行为错误、权限漏洞、数据丢失、回归，以及[新增或升级的依赖](/zh/security/#r-sec-2)。格式问题交给仓库的自动检查。

## 2. 核实 review 意见并修复缺陷

- **AI-3** (中风险; 由代码评审检查): **对照验收标准检查测试。** agent 写的代码和测试，可能基于同一个错误假设。
- **PR-4** (高风险; 由代码评审检查): **负责人能解释每一处改动，以及它会怎么出问题。** 代码是 agent 写的，责任不会因此转移。

场景：ENG-123 的 PR 评审返回了十二条 review 意见。

**较差的 prompt**

```text
把 review 意见都改了。
```

**更好的 prompt**

```text
逐条处理 review 意见：复现它，或者用证据说明它不成立。只修确认的缺陷，每个都补一个测试。列出不采纳的 review 意见和理由。review 意见没涉及的代码不要动。
```

原因：review 意见只是一个判断，不是证据。不分对错全改，只会多出没必要的改动，还可能把本来对的代码改坏。

- 确认每个缺陷都有修复和测试，每条不采纳的 review 意见都有证据。
- 重新运行受影响的检查；有实质性改动后，再评审一轮。

> **示例: ENG-123 · review 意见**
>
> 非管理员可以导出本商户的订单。导出接口校验了商户归属，但没有校验管理员权限。
>
> - 复现：用非管理员账号登录，直接调用导出接口。导出照常排队，下载链接也能拿到文件；而 ticket 要求拒绝访问。
> - 漏检原因：权限测试只检查了非管理员看不到导出按钮。代码和测试基于同一个假设。
> - 修复：在服务端校验管理员权限，并补一个拒绝访问的测试。只隐藏按钮，接口照样能访问。

## 3. 批准并合并

- **PR-3** (中风险; 由 CI 检查): **被评审的 commit 必须通过所有必需的 CI 检查。** 检查被跳过的 job 和只报告、不拦截的扫描结果；总体显示全绿，也可能缺了证据。
- **PR-6** (高风险; 由配置和 CODEOWNERS 检查): **合并前必须由一位评审人批准；AI 评审只提建议。** 谁可以批准由项目决定，并由分支保护规则强制执行。

* 按项目的 runbook 确认谁可以批准。批准人评审最终的 diff 和证据，并确认目标分支。
* 合并前，解决所有阻止合并的 review 意见。延后的发布检查要有负责人和关联 ticket，并在发布前完成。
* 把批准的 PR 合并到约定的目标分支。

下一步：把合并后的 commit、剩下的发布检查和恢复说明，交给[发布与收尾](/zh/release-mgmt/)。