# Dev Code Review > 对**一次改动**做成文的代码评审：工作区 diff／分支／PR／指定路径都能评，产出带证据行（`file:line`）、 严重级与整改闭环的评审报告，落 `dev/reports/`。 能力：(1) 先圈定评审范围与规格真源，再按八个维度逐项过 (2) 每条意见必须指到实处并经一轮自我反驳 (3) 按交付模式分档（快速／标准／严格）(4) 整改后回填闭环状态，不留「已知问题」当交付物。 触发词：「代码评审」「review 一下这段代码」「帮我看看这个 PR」「合并前把关」「这次改动有没有问题」 「评审报告」「code review」「MR 评审」「提交前审一遍」「谁来把个关」， 或在 `dev-master` 阶段 10 之前需要人工／AI 把关时。 与内置 `/code-review` 的关系：Claude Code 内置命令适合**即时看 diff、不留档**； **本技能面向 Codex / Cursor（没有那个命令）以及需要成文报告、按维度全覆盖、要闭环追踪的场景**。 不适用：文档意图 vs 代码实现的差距审计（`pm-ai-ship-audit`）、具体故障定位（`systematic-debugging`）、 「说做完了是不是真做完」的终检（`verification-before-completion`）、测试用例设计（`pm-test-cases`）。 - Skill: `idwong/dev-code-review` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add idwong/dev-code-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/idwong/dev-code-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: iDWong (https://skillmd.com/u/idwong) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/idwong/dev-code-review --- # dev-code-review：成文的代码评审 > 一句话定位：**看的是「这次改动」，不是整个仓库**；产出的是**能直接照着改的意见清单**，不是评语。 ## 与相邻技能的边界（先确认你要的是哪一个） | 你想要什么 | 用谁 | 它看什么 | |---|---|---| | 这次改动写得对不对、有没有坑 | **本技能** | 改动集（diff / 分支 / 路径） | | 文档写了但代码没做到的差距、权限矩阵漏洞、密钥入库 | `pm-ai-ship-audit` | 全仓 + 文档基线 | | 这个 bug 是怎么回事 | `systematic-debugging` | 一个具体故障 | | 说做完了，真的做完了吗 | `verification-before-completion` | 任务清单 vs 实际产出 | | 该测哪些用例 | `pm-test-cases` | 需求，不是代码 | **同时需要时的顺序**：本技能（改动级）→ `verification-before-completion`（终检）→ `pm-ai-ship-audit`（上线前全仓）。 ## Step 0：圈定范围（不做这步不许开评） 必须落定四件事，写进报告抬头： | 项 | 怎么定 | 缺了会怎样 | |---|---|---| | **评审范围** | `git diff ...`／`git diff`（工作区）／PR 号／指定路径 | 不圈范围会滑成"通读全仓"，意见发散且评不完 | | **规格真源** | `SPEC_SOURCE`（`dev/SRS/*.md`；存量项目在 `docs/SRS/`） | 没有真源就只能评"写法"，评不了"做得对不对" | | **交付模式** | 快速／标准／严格，默认**标准**；上游 `dev-master` 传入时以它为准 | 决定覆盖广度与是否逐文件通读 | | **是否允许改代码** | 默认**只评不改**；用户说「顺手修了」才改 | 评审里夹带修改会让人无法分辨"意见"和"既成事实" | 非 git 项目（本机就有这种）没有 diff 可取：让用户点出改动涉及的文件或模块，按路径评，并在报告里标「范围由用户指定，非 diff」。 ## 档位 | 档 | 覆盖 | 停在哪 | |---|---|---| | 快速 | 只看**正确性 + 安全**两个维度，改动文件全过一遍 | 出意见清单即止 | | **标准**（默认） | 八个维度全过；改动文件逐个通读，关联调用点抽查 | 出报告 + 整改建议 | | 严格 | 标准 + 逐条追到关联路径（调用方、数据库、前后端契约两侧）+ 补测试建议 | 出报告 + 整改 + 回归验证结论 | ## 八个维度 逐维度过，检查项见 `references/checklist.md`（**进入评审时读它，不要凭记忆**）： 1. **正确性与规格一致** —— 字段、枚举、边界值、状态流转是否与 SRS／详细设计一致 2. **并发与事务** —— 竞态、重复提交、事务边界、幂等、锁粒度 3. **错误处理** —— 错误码与响应体口径、吞异常、日志脱敏、超时与重试 4. **权限与数据范围** —— 鉴权缺失、越权（IDOR）、数据可见性、批量接口的范围过滤 5. **性能** —— N+1、请求瀑布、大列表、缺索引、无界查询、同步阻塞 6. **可读与复用** —— 重复实现、命名、分层与依赖方向、圈复杂度、死代码 7. **测试** —— 改动是否有对应用例、异常分支是否覆盖、测试本身是否有效（不是只跑不断言） 8. **交付卫生** —— 硬编码密钥／假数据、遗留 `TODO`、调试残留、与设计稿的偏差未说明 ## 硬规则 - **每条意见必须带证据行**：`path/to/file.ts:42` + 原文片段。指不到行的意见**不算一条意见**。 - **自我反驳一轮**：每条写完问一句「我真的读过这段上下文吗，还是在按模式猜？」——没读过就去读，或降级为「待确认」。 - **不写空话**：「建议加强错误处理」「代码质量尚可」这类不计入，必须写成「哪一行、会怎么坏、改成什么」。 - **严重级四档**：致命（数据错误／越权／密钥泄露／线上不可用）、严重（主流程功能错误、性能塌陷）、 一般（边界与体验问题）、建议（可读性与风格）。**致命与严重必须整改后才放行**。 - **只评不改**（除非用户明说）；确需示例时给最小代码片段，不直接落盘。 - **不重复别人已经拦下的**：仓库有 lint／类型检查／CI 时先看它们的结论，别把工具能报的错当人工意见凑数。 ## 产出 落 `dev/reports/代码评审-{范围简称}-{YYYYMMDD}.md`（存量项目文档在 `docs/` 时按实际目录，不搬家）： ```markdown # 代码评审 · {范围简称} · {日期} ## 一、评审范围 | 项 | 值 | |---|---| | 范围 | `git diff main...feat/x`（12 个文件，+486 / -73） | | 规格真源 | `dev/SRS/…-V1.2.md` | | 档位 | 标准 | | 结论 | 通过 / 有条件通过（致命 0 / 严重 2 未闭环）/ 不通过 | ## 二、意见清单 | # | 维度 | 严重级 | 证据（file:line） | 问题 | 会怎么坏 | 改成什么 | 状态 | |---|---|---|---|---|---|---|---| | 1 | 权限 | 致命 | `server/internal/handler/post.go:88` | 详情接口未校验归属 | 换 id 可读他人草稿 | 加 `ownerOf(ctx)` 过滤 | 已整改 | ## 三、未覆盖与待确认 （读不到上下文、依赖外部系统、需要用户确认口径的，逐条列出——**不要写成"通过"**） ## 四、整改闭环 | # | 整改内容 | 验证方式 | 验证结论 | ``` ## 整改闭环 致命／严重项**当场整改**（用户同意改代码时）或列给责任人；改完回填「验证方式 + 验证结论」。 全部闭环前，报告结论只能是「有条件通过」或「不通过」。 ## 在 dev-master 流程里的位置 挂 **阶段 10（调试与验收）** 的 `also`：阶段 9 测试通过后先评审，再做 `verification-before-completion` 终检， 最后进阶段 11 `pm-ai-ship-audit`。三者视角不同，不要互相替代。 **门禁（进阶段 11 前）**：致命与严重项全部闭环，或已列入遗留风险并经用户确认。