评审意见别只写感想：/review 的 5 条硬规则

说明：本文是整理，不是新实测。内容来自完整版 commands/review.md 原文与 /review 公开 Gist。/review 是 Lite 版 3 条命令之一（Lite 版免费就有 /review、/commit、/test），完整版同款命令，另含其余 7 条命令与三套模板、速查表。本文只讲 /review 这一条，不编造新实测。

1. 先读全再下判断，不确定的意图标 [推测]

/review 的第一步不是给意见，是把涉及的文件读完、理解意图后再说问题。不确定的意图标 [推测]，不按推测扣分。

没读全就评，评出来的多半是“这段代码为什么这样写”而不是“这段代码有什么问题”。接手一段陌生代码时这条尤其重要：先搞清它想干什么，再说它哪里不对。

2. 只说五个维度的真问题，不凑数

五个维度是：正确性（边界、空值、异常路径、并发）、安全（注入、敏感信息、权限、资源未释放）、可读性（命名、函数长度、注释是否说清“为什么”）、性能（只说明显的数量级问题，如 N+1、重复计算、大对象拷贝）、测试（关键分支是否有用例覆盖）。

每个维度只说真问题，某个维度没问题就空着，不为凑齐五个维度硬找。凑出来的意见接手的人改不动，还会把真正的问题淹没。

3. 分级输出，[必须改] 只留 bug 和安全问题

分三级：[必须改]（bug 或安全）/ [建议改]（可读性、性能）/ [可忽略]（个人偏好，最多 2 条）。

风格之争（单引号还是双引号）不在评审里讨论，用 linter 解决；“只想听夸奖”也不要用这个命令，它只说真话。分级的作用是让接手的人先改会出事的，再改可以更好的，最后才看个人偏好。

4. 每条意见固定四段式，给代码片段不只给方向

格式：文件:行号 — 问题一句话 — 为什么这是问题 — 改法建议（给代码片段，不只说“建议优化”）。

示例取自命令自带示例：orders.py:8 — 文件打开后未关闭，异常时泄漏句柄 — 用 with open(...) 包裹：

with open(path) as f:
return json.load(f)

没有“为什么”和“改法”，意见就落不了地；没有文件:行号，意见就找不到位置。评审结论也只有一句话：可合并 / 需修改后合并 / 建议重构。

5. 上限 10 条，超了先重构再评审

超过 10 条说明代码需要重构而不是评审：直接说“建议先重构再评审”并给出重构方向，不要把 30 条意见一次性倒出来。

同样，超过 500 行的大文件不要一次性评审，先拆小、按模块分次评审；代码还没写完、自己都知道是草稿的，先写完再评，半成品评审浪费双方时间。

不用 /review 的场景

• 代码还没写完、自己都知道是草稿：先写完再评。
• 只想听夸奖：这个命令只说真话。
• 超过 500 行的大文件一次性评审：先拆小，按模块分次评审。
• 风格之争：用 linter 解决，不在评审里讨论。

价格与链接

完整版中文 AI 编程 CLI 工作流包：早鸟 ¥9.90（限前 100 份），正式 ¥19.90。/review 本身在 Lite 版免费版中已有，完整版是 10 条命令全量。

• Lite 版公开仓：https://github.com/alapha888/cn-ai-coding-workflow-lite
• 爱发电商品页：https://afdian.com/item/8c9c0932bd7711f19eb852540025c377
• /review 命令原文 Gist：https://gist.github.com/alapha888/bfad6db24e0971d4cbf87e778758615b