代码评审
核对结果，处理 review 意见，批准最终要合并的改动。
本页内容
1. 运行 PR 评审
Skill
pr-reviewCodex
$neutron:pr-review 对照关联的 Jira ticket 评审 [PR 链接]。通过已连接的 Jira MCP 或已认证的 acli 读取描述、验收标准和评论；访问不了就让我贴详情。 针对 PR 当前的 commit，给出可以落地的 review 意见，每条附上文件和行号、影响、支撑证据，以及验证缺口。评审保持只读。
Claude Code
/pr-review 对照关联的 Jira ticket 评审 [PR 链接]。通过已连接的 Jira MCP 或已认证的 acli 读取描述、验收标准和评论；访问不了就让我贴详情。 针对 PR 当前的 commit，给出可以落地的 review 意见，每条附上文件和行号、影响、支撑证据，以及验证缺口。评审保持只读。
- 在全新的评审会话里运行这个 skill，提供 PR、ticket 和仓库说明，让 agent 独立做出判断。
- 确认评审针对的是 PR 的最新 commit 和正确的 Jira ticket。
- 优先关注行为错误、权限漏洞、数据丢失、回归，以及新增或升级的依赖。格式问题交给仓库的自动检查。
2. 核实 review 意见并修复缺陷
- 对照验收标准检查测试。agent 写的代码和测试，可能带着同一个错误假设。
- 负责人能解释每一处改动，以及它会怎么出问题。代码是 agent 写的，责任不会因此转移。
场景： ENG-123 的 PR 评审返回了十二条 review 意见。
较差的 prompt
把 review 意见都改了。
更好的 prompt
逐条处理 review 意见：复现它，或者用证据说明它不成立。只修确认的缺陷，每个都补一个测试。列出不采纳的 review 意见和理由。review 意见没涉及的代码不要动。
原因： review 意见只是一个判断，不是证据。不分对错全改，只会多出没必要的改动，还可能把本来对的代码改坏。
- 确认每个缺陷都有修复和测试，每条不采纳的 review 意见都有证据。
- 重新运行受影响的检查；有实质性改动后，再评审一轮。
非管理员可以导出本商户的订单。导出接口校验了商户归属，但没有校验管理员权限。
- 复现：用非管理员账号登录，直接调用导出接口。导出照常排队，下载链接也能拿到文件；而 ticket 要求拒绝访问。
- PR 证据为什么没发现：权限测试只检查了非管理员看不到导出按钮。代码和测试带着同一个假设。
- 修复：在服务端校验管理员权限，并补一个拒绝访问的测试。只隐藏按钮，接口照样能访问。
3. 批准并合并
- 被评审的 commit 必须通过所有必需的 CI 检查。检查被跳过的 job 和只报告、不拦截的扫描结果；总体显示全绿，也可能缺了证据。
- 合并前要有一个人批准；AI 评审只提建议。谁可以批准由项目决定，并由分支保护规则强制执行。
- 按项目的 runbook 确认谁可以批准。批准人评审最终的 diff 和证据，并确认目标分支。
- 会挡住合并的 review 意见，合并前解决。延后的发布检查要有负责人和关联 ticket，并在发布前完成。
- 把批准的 PR 合并到约定的目标分支。