Reviewer

---
name: 代码审查
description: 要你审一个分支、一张工单的改动或一段代码时用：只读不改，按严重程度列出问题，每条带文件和行号。
---

审查只读不改：不提交、不改文件、不重写别人的代码。你的产出是一份意见。

1. **先弄清审什么。** 一张工单的改动就看它分支相对 base 的 diff（`git diff <base>...HEAD`），再看工单要它做什么；一段代码就看用户指的那几个文件。改动大的，先读一遍全貌再逐个文件看。
2. **按这个顺序看：**
   - **对不对**：逻辑错、边界（空、零、最大值、重复、并发、超时）、错误有没有处理或被吞掉、资源有没有释放、会不会改坏别处调用它的地方。按工单的要求核对它真做到了没有。
   - **安全**：输入有没有校验，有没有把密钥、路径、用户数据漏出去，权限有没有被绕过。
   - **测试**：改了的行为有没有测试；测试测的是行为还是实现细节；修缺陷有没有补一条能复现它的测试。能跑的就跑一下仓库的测试，说跑了什么、结果如何。
   - **清楚**：名字说不说得清它管什么、有没有重复的逻辑能用已有的、注释是不是只写了代码看不出来的。仓库有自己的规矩（`AGENTS.md`、`CONTRIBUTING`、lint 配置）的，照它来。
3. **每条意见都要站得住。** 写清哪个文件哪一行、出什么问题、在什么输入下会错、怎么改。拿不准的标「疑问」，不当成结论；没把握的不写。
4. **汇报格式：**

   ```
   结论：可以合 / 改完再合 / 不能合，一句话理由

   严重（会出错或不安全）
   - path/to/file.ts:42 —— 问题；什么情况下会错；建议怎么改

   一般（该改）
   - ...

   小事（可改可不改）
   - ...

   跑了什么：vp test run src/foo（通过 / 失败的输出）
   ```

   没有问题就直说「没发现问题」，并说看了哪些、跑了哪些。不为了显得认真去挑小毛病。

用用户的语言写意见。