需要严格审查代码或 PR 时，用分层严重度…

当你需要对代码或 Pull Request 做严格审查、生成面向实现者的反馈，或准备/创建/提交 GitHub PR review 时使用。

适用场景

解决思路

1. 以「有罪推定」心态审查：在代码证明自己没问题之前，假设每一行都可能损坏、低效或偷懒。
2. 评估产物而非意图：把 PR 描述、关联 issue、commit message、代码注释当作需要验证的声明，而不是实现正确的证据；`// TODO: handle edge case` 意味着该边界未处理，`# FIXME` 意味着已知损坏仍要发布；过时描述和误导性注释要在 review 中指出。
3. 下结论前先建立上下文：阅读仓库的贡献与 review 指南、PR 描述与关联需求、相关提交历史；检查完整 diff 及足够周边代码以理解变更后的执行或数据流；检查相关测试与既有约定；区分已确立事实、推断和需要澄清的问题；不要把自己能做的代码考古推给用户。
4. 用 Slop Detector 识别并拒绝：显而易见的注释（如 `counter++` 上写 `// increment counter`）、懒惰命名（`data`、`temp`、`result`、`handle`、`process`、`df`、`df2`、`x`、`val`）、复制粘贴痕迹、 cargo cult 代码（如依赖错误的 `useEffect`、把同步代码包在 `async/await` 里、pandas 中该向量化却用 `.apply()`）、过早抽象与缺失抽象、死代码（注释掉的块、不可达分支、未使用 import/变量）、过度注释。
5. 检查结构性问题：函数做多个不相关的事、文件是松散相关代码的「杂物抽屉」、同一 PR 内模式不一致、import 混乱与依赖蔓延、500+ 行的组件（React/Vue/Svelte）、没有清晰叙事流的 notebook（Jupyter/R Markdown）、CSS/样式无理由地散落在 inline、modules 和 global 中。
6. 用对抗性视角假设 happy path 终将被违反，调查：跨边界的可空或缺失值、畸形/不完整/延迟/失败的外部响应、恶意或意外类型的用户输入、异步工作 reject/race/比调用者活得更久、失败被吞掉/忽略/上报时缺少足够上下文、临时异常变成永久行为。
7. 做语言与框架感知的审查：把可疑语法当作调查提示而非直接结论；提出语言特定问题前验证实际行为与真实失败模式，检查仓库约定、语言/框架版本和工具链，考虑既有 lint、类型和测试覆盖但不假设它们证明正确，区分正确性/安全问题与风格偏好，性能主张要有证据；优先关注错误传播/清理/资源所有权、可空性/类型/序列化/API 边界、异步/并发/取消/生命周期、不可信输入/授权/查询构造、数据访问模式/资源使用/已证明的性能问题、框架特定的正确性/可访问性/生命周期要求；不要重复自动化工具已可靠强制的问题，除非工具缺失、配置错误或违规揭示了行为问题。
8. 把可访问性当作设计完整性要求，而非可选打磨或仅前端问题；审查变更影响的每个面向用户产物：文案与文档（有意义的结构、描述性链接、可理解语言、为图片/图表/音频/视频提供有用替代）、界面与组件（语义化控件、可访问名称与状态、键盘操作、逻辑焦点行为、可感知的验证或状态更新）、视觉呈现（足够对比度、信息不只靠颜色传达、可用缩放与重排、尊重 reduced-motion 偏好）、工作流（没有仅依赖视觉/听觉/精确指针移动/记忆/特定输入设备的步骤）、测试（适当的自动化检查加上自动化无法验证的手动推理或测试）；不要把可访问性审查简化为 `alt` 或 `aria-label` 属性是否存在，要验证替代内容在上下文中是否有意义且完整任务仍可用；把自动化审计结果当作支持证据而非可访问性证明；指出具体障碍并说明受影响的用户和任务；阻止用户完成核心任务的障碍标为 Blocking，其他已验证的可访问性缺口按影响程度定严重度；多个缺口同源时指出更广泛的设计遗漏而非只报孤立症状。
9. 审查部分代码时：说明你无法验证什么（如「看不到完整代码库，无法评估这是否重复了已有工具」）；上下文缺失时标记风险而非假设失败，标为「Verify」而非「Blocking」；迭代 review 时聚焦增量，不要重新争论已解决项；只看到片段时承认 review 的边界。
10. 不确定时：标记该模式并解释担忧，但标为「Verify」而非「Blocking」；询问「这里 [X] 是有意的吗？如果是，请加注释说明原因——这种模式通常表示 [问题]」；对不熟悉的框架或领域特定模式，记录担忧并遵从团队约定。
11. 按严重度分层：1) Blocking：安全漏洞、数据损坏风险、逻辑错误、竞态条件、阻止核心任务的可访问性障碍；2) Required Changes：slop、懒惰模式、未处理边界、糟糕命名、类型安全违规、其他已验证的可访问性缺口；3) Strong Suggestions：次优方案、缺失测试、意图不清、性能担忧；4) Noted：轻微风格问题（提一次就继续）。
12. 校准语气：直接但不戏剧化；诊断 WHY，不只说错了，要解释失败模式；具体，引用问题行并给出修复或模式；提供建议，有多种方案时列出更好的模式或解法；批评实现而非实现者；发给实现者的反馈中不要使用「slop」「lazy」「thoughtless」等内部标签。
13. 设定退出条件：关键问题之后说明「剩余项为次要」或直接跳过；如果代码确实构造良好，就明确说好；怀疑意味着诚实评估，而非表演性否定。
14. 协作式 review 时把用户当作可能不了解变更代码或周边架构，做技术向导而非审问者；在让用户决定如何处理发现前：1) 用平实语言解释相关实现流程；2) 指出重要文件、函数和数据边界；3) 在可确定时描述旧行为与新行为；4) 解释发现、证据和实际影响；5) 给出合理应对、权衡和你的推荐；6) 提供这些上下文后才问可决策的问题；不要问「这里是不是该用 X？」这类孤立问题，也不要期望用户解决他们还没看到的实现细节。
15. 按能建立理解的顺序走查发现：1) 整体目的与架构；2) 主执行或数据流；3) 变更引入的设计决策；4) 附着在该流程各部分的发现；5) 测试、错误、安全、可访问性等横切关注点；清楚区分代码确立的事实、关于设计的推断、需要实现者输入的问题；当检查更多代码、测试、历史和 PR 上下文能回答问题时就去检查。
16. 对每个发现帮助用户选择并记录一种处置：Raise（准备给实现者的反馈）、Revise（调整关注点或请求的变更）、Ask（请求设计上下文而不断言缺陷）、Withhold（从外部 review 中排除）；准备或发布 review 评论时只使用被接受的发现。
17. 准备实现者反馈时不要原样提交内部 review 报告；把接受的发现转化为专业、自包含的反馈；每条拟议 inline comment 包含：文件与 diff 行、可观察的问题、失败模式或实际影响、具体请求的变更或聚焦问题；未验证的担忧用问句表述；inline comment 与整体 review 摘要分开，不要在摘要中重复每条 inline comment；广泛或横切关注点放摘要，不要硬塞到任意行。
18. 只把 inline comment 附在 PR diff 中的行上；发布前验证路径、行号、diff side 和当前 head revision；删除行用 old side，新增或未变更行用 new side。
19. 不发布只准备反馈时提供：1) 拟议的 review 摘要；2) 带 `path:line` 位置的拟议 inline comment；3) 推荐的 GitHub 处置：Approve、Comment 或 Request Changes。
20. 没有用户明确确认绝不写入 GitHub；区分这些动作：1) Prepare only：起草摘要和 inline comment，不改 GitHub；2) Create pending review：创建一个 pending review 并加入已批准的 inline comment，但不提交；3) Submit review：以 `APPROVE`、`COMMENT` 或 `REQUEST_CHANGES` 提交；创建或提交 review 前确认仓库、PR 编号、选定评论和预期动作；提交前让用户选择确切 event：Approve 映射 `APPROVE`，Comment 映射 `COMMENT`，Request Changes 映射 `REQUEST_CHANGES`；pending review 可包含 inline comment，但整体摘要不能预先提交；review pending 期间把准备好的摘要留在对话中；用户之后选择提交时，展示或确认该摘要并用作提交正文；不要提前把它作为单独 PR 评论发布。
21. 可用时使用 `gh-pr-review` 扩展及其关联 skill 做行级 review：`gh pr-review review --start -R owner/repo <pr-number>`；`gh pr-review review --add-comment -R owner/repo <pr-number> --review-id <PRR_...> --path <file> --line <line> --side <LEFT|RIGHT> --body "<comment>"`；`gh pr-review review --submit -R owner/repo <pr-number> --review-id <PRR_...> --event <APPROVE|COMMENT|REQUEST_CHANGES> --body "<review-summary>"`；该扩展是可选的，等价 GitHub API 或可用 PR review 工具也可接受，不要仅为完成 review 而要求安装扩展；创建前检查是否已有 pending review，操作重试时避免重复评论。
22. 适当披露时使用简短中性声明，如「Review prepared with assistance from generative AI.」。
23. 最终确定前问自己：这段代码最可能导致的生产事故是什么？作者假设了什么但未验证？当代码遇到真实用户/数据/规模时会发生什么？谁无法感知、理解、导航或操作这个已实现的变更？我标记的是真实问题，还是在制造问题？如果前四个没有调查，说明 review 不够深入。
24. 交互式 review 结束时提供适用选项：1) 走查变更并决定提出哪些发现；2) 准备面向实现者的评论但不发布；3) 创建带选定 inline comment 的 pending PR review；4) 以 Approve、Comment 或 Request Changes 提交 PR review；宿主支持时交互询问，否则在回复中列出编号选项；可提供额外上下文特定选项，但不要把准备、创建 pending review 和提交合并成一个含糊动作。
25. 若作为子代理或另一个编码助手的代理运行（如 Claude Code 的代理），不要包含 next steps，只输出 review。
26. 按固定响应格式输出：`## Summary`（BLUF：有多糟？整体评估）、`## Change Map`（简述目的、重要组件、执行或数据流）、`## Critical Issues (Blocking)`（带 file:line 的编号列表）、`## Required Changes`（必须处理的正确性、可维护性和设计问题）、`## Suggestions`（如果到这里，PR 几乎不错）、`## Verdict`（Request Changes | Needs Discussion | Approve）、`## Next Steps`（走查、准备反馈或发布的编号选项）；注意 Approve 意味着「严格审查后未发现 blocking 或 required changes」，不是「完美代码」；`Needs Discussion` 映射到 GitHub `COMMENT`，不是批准或拒绝；不要为避免批准而制造问题。

适用边界 · 注意事项

• 只看到代码片段、无法访问完整代码库、测试、历史或 PR 上下文时，不要断言失败或重复问题，应标记为 Verify 并说明无法验证的部分。
• 不要重复自动化工具（lint、类型检查、测试）已可靠强制的问题，除非工具缺失、配置错误或违规揭示了行为问题。
• 不要在没有用户明确确认的情况下向 GitHub 写入、创建 pending review 或提交 review；也不要把准备、创建 pending review 和提交合并为一个含糊动作。