iDWong 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（进入评审时读它，不要凭记忆）：
- 正确性与规格一致 —— 字段、枚举、边界值、状态流转是否与 SRS／详细设计一致
- 并发与事务 —— 竞态、重复提交、事务边界、幂等、锁粒度
- 错误处理 —— 错误码与响应体口径、吞异常、日志脱敏、超时与重试
- 权限与数据范围 —— 鉴权缺失、越权（IDOR）、数据可见性、批量接口的范围过滤
- 性能 —— N+1、请求瀑布、大列表、缺索引、无界查询、同步阻塞
- 可读与复用 —— 重复实现、命名、分层与依赖方向、圈复杂度、死代码
- 测试 —— 改动是否有对应用例、异常分支是否覆盖、测试本身是否有效（不是只跑不断言）
- 交付卫生 —— 硬编码密钥／假数据、遗留
TODO、调试残留、与设计稿的偏差未说明
硬规则
- 每条意见必须带证据行：
path/to/file.ts:42+ 原文片段。指不到行的意见不算一条意见。 - 自我反驳一轮：每条写完问一句「我真的读过这段上下文吗，还是在按模式猜？」——没读过就去读，或降级为「待确认」。
- 不写空话：「建议加强错误处理」「代码质量尚可」这类不计入，必须写成「哪一行、会怎么坏、改成什么」。
- 严重级四档：致命（数据错误／越权／密钥泄露／线上不可用）、严重（主流程功能错误、性能塌陷）、 一般（边界与体验问题）、建议（可读性与风格）。致命与严重必须整改后才放行。
- 只评不改（除非用户明说）；确需示例时给最小代码片段，不直接落盘。
- 不重复别人已经拦下的：仓库有 lint／类型检查／CI 时先看它们的结论，别把工具能报的错当人工意见凑数。
产出
落 dev/reports/代码评审-{范围简称}-{YYYYMMDD}.md（存量项目文档在 docs/ 时按实际目录，不搬家）：
# 代码评审 · {范围简称} · {日期}
## 一、评审范围
| 项 | 值 |
|---|---|
| 范围 | `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 前）：致命与严重项全部闭环，或已列入遗留风险并经用户确认。