---
name: review
description: 用户要求 review、CR，让你看看某个改动、PR、MR、设计或方案有没有问题，或者要判断它能不能合并、交付时使用。独立冷读准确的对象，查完影响范围，每个问题先试着推翻再报告，最后给出结论。只想弄懂改了什么时用 walkthrough；自己刚写完代码的日常自查不用。
---

# review

像一位没参与编写、熟悉这个项目的维护者那样冷读：不采信作者的说法，自己从代码和证据重建判断。作者的摘要、测试名称和之前的评审意见都只是线索。

## 锁定对象

先确认审的是什么：哪个分支、提交或 diff，和哪个版本比较，工作树里有没有未提交的改动，这次改动要达成什么（有 `.agents/tasks/<任务>/shape.md` 时，读其中的目标和验收标准）。对象或比较版本不清楚、又会影响结论时，先查清或问清，不自己挑一个方便的版本。

## 查完影响范围，按风险分配精力

从改动出发，列出它真正影响到的东西：改动的每个文件，以及受影响的调用方、公共接口、权限、数据和状态、异步过程和下游消费者。每一项要么检查过，要么有证据说明不受影响，要么写成没查到的缺口。精力按风险分配：公共接口、安全边界、数据与恢复路径、热路径值得深挖，其余看一遍即可。发现第一个问题后继续看完。

除了正确性，也看改动本身是否干净：每处改动能否对应到本次目标，有没有夹带范围外的修改、重复实现或绕开项目已有做法，测试是否真正约束了新行为，新增的抽象和公共接口以后由谁维护。

只把本次引入或明显放大的问题算在这次改动上。既有问题只在用户要求整体审计，或它会改变本次结论时提出，并注明是既有的。

## 每个问题都要走通证据

报告的每个问题都要说清：什么输入、状态或调用方会触发它，经过哪些代码，最后导致什么错误结果、破坏什么约定或带来什么长期成本，并附上能打开的证据（代码位置、命令输出、日志或运行结果）。风格偏好、走不通的理论路径、说不出具体代价的"应该重构"，都不算问题。

报告前把每个候选当作未证实的假设，主动找能推翻它的东西：上游校验、类型或权限保证、调用约定、已有的补偿逻辑、相反的运行结果。被推翻的删掉；部分成立的改正描述；证据不够的写成待查的缺口，不当作问题报告。

## 严重程度和是否需要用户决定

每个问题标一个严重程度：

- **高**：现实中会触发的严重错误，如数据损坏、越权、主流程失败，不修不能合并。
- **中**：具体、会发生的错误，或明显的维护代价，应该修。
- **低**：影响小，但值得改进。

再标明它的处理是否需要用户决定。修复需要改变目标或范围、接受某种风险，或引入超出原请求的机制（迁移、兼容层、新的公共接口、大规模重构）时，需要用户决定；其余可以直接修。

## 给出结论

结论只有三种：

- **可以合并**：没有高或中的问题，关键证据足够。
- **需要修改**：有可以直接修的高或中问题。
- **需要你决定**：有问题的处理需要用户决定；写清要决定什么、有哪些选择、各自的代价。

可能改变结论的证据缺口要写明，不能默认当作通过。

## 评审和修改分开

默认不改正在审的代码。用户要求审完就修时，先给出评审结论，只修不需要用户决定的问题，需要决定的等用户决定；修完后重新核对原问题和新的 diff。

默认在对话里输出：问题在前，按严重程度排序；然后是结论、检查过的范围和没查到的部分。当前任务有 `.agents/tasks/<任务>/` 目录且需要保存时，写到那里的 `review.md`。