# Code Review Checklist

> 对一段 diff 或改动做结构化审查，按正确性、边界情况、安全、可读性、测试覆盖分类给出具体发现，而不是笼统的"看起来不错"。当用户说"帮我审查一下这段代码"、"看看这个 PR 有没有问题"、"这段改动能合并吗"、"帮我 review 一下"时使用。只做只读审查，不直接修改代码；如果用户想要"审查完顺便把问题改了"，先完成审查、列出发现，再单独确认是否要动手改。

- Skill: `fengyan3141/code-review-checklist` (Agent Skill)
- Install (CLI): `npx skillmds@latest add fengyan3141/code-review-checklist`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fengyan3141/code-review-checklist/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: fengyan3141 (https://skillmd.com/u/fengyan3141)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/fengyan3141/code-review-checklist

---


# code-review-checklist

## 目标

产出具体、可核实的审查发现——每条发现都要能回答"在什么输入/场景下，会出什么错"，而不是空泛的风格意见。找不到真实问题时如实说"没有发现明显问题"，不要为了显得"审查得很认真"硬凑问题。

## 审查步骤

1. **理解改动的意图**：先看清楚这段改动想解决什么问题、涉及哪些文件，再逐处检查，不要孤立地看单个文件而不管上下文。
2. **按以下五个维度过一遍，不是每个维度都会有发现，跳过没问题的维度**：
   - **正确性**：逻辑是否符合意图？有没有明显的笔误、条件写反、off-by-one？
   - **边界情况**：空输入、null/undefined、极大极小值、并发/竞态、网络/IO 失败时会怎样？
   - **安全**：有没有引入注入、越权访问、敏感信息泄露、不受信输入未校验直接使用等问题？
   - **可读性与维护性**：命名是否清楚？有没有重复到应该抽取的逻辑？复杂逻辑有没有必要的说明？（风格类的小事，比如空格、引号统一，除非项目有明确规范否则不用纠结）
   - **测试覆盖**：新增/改动的行为有没有对应测试？测试是否真的验证了行为而不是形式上凑数？
3. **每条发现都要包含**：具体位置（文件名/行号或代码片段）、问题描述、触发条件（什么情况下会出问题）、以及可能的修复方向。
4. **分级**：区分"会导致错误行为的问题"和"值得改进但不影响正确性的建议"，让用户知道哪些必须处理、哪些可以自行取舍。

## 输出格式

按维度分组列出发现，每条一两句话说清楚位置和问题；维度下没有发现就不要列出该维度标题。最后给一句总体结论（可以合并 / 建议先处理关键问题 / 需要作者确认某个设计决策）。

## 边界

- 只读审查，不直接修改代码，除非用户明确要求"审查完直接改"。
- 不评价与本次改动无关的历史代码，除非它直接影响这次改动的正确性。
- 拿不到完整上下文（比如看不到被调用的函数实现）时，如实说明这一点，不要假设它的行为。