dev-code-reviewlisted

# 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 <base>...<head>`／`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. **可读与复用** —— 重复实现、命名、分层与依赖方向、圈复