前两天随手写了个 Claude Code 的 Skill，专门做 Code Review 的，发了条推之后就没太在意。
结果第二天醒来一看，GitHub Star 刷刷往上涨，评论区也炸了，不少人说"终于有个靠谱的 Code Review 工具了"。
说实话，有点意外。
倒不是说这个 Skill 有多了不起，而是它戳中了一个很真实的痛点------大部分团队的 Code Review，要么走过场，要么全靠人肉。
先说说为什么要做这个
做这个 Skill 的起因其实很简单。
我自己平时写代码，改完了之后经常想让 Claude Code 帮我 review 一下。直接跟它说"帮我看看代码有没有问题"，它确实会给你一些反馈，但说实话，质量参差不齐。
这就跟新来的实习生做 Code Review 一样，不是他不想认真看，是他不知道该看什么、怎么看、按什么优先级来。
所以问题的本质是：模型需要一套结构化的 Review 框架，告诉它该检查什么、怎么分级、用什么格式输出。
这不就是 Skill 最擅长干的事吗？
code-review-expert 是什么
一句话概括：一个让 AI 用资深工程师的视角帮你做 Code Review 的 Skill。
安装方式就一行：
bash
npx skills add sanyuan0704/code-review-expert装好之后在 Claude Code 里输入 /code-review-expert，它就会自动 review 你当前的 git changes。
整个 review 流程我是精心设计过的，分成这么几步：
第一步：Preflight（了解改动范围）
它会先跑 git diff 看看你改了哪些文件、改了多少行。如果改动量超过 500 行，它会先按模块分批 review，不会一口气全看完然后给你一堆乱七八糟的反馈。
第二步：SOLID + 架构检查
这一步是我花了最多时间打磨的。我写了一份详细的 SOLID checklist，把每个原则对应的"坏味道"都列出来了。
比如检查 SRP（单一职责），它不会只是泛泛地说"这个文件职责太多了"，而是会问一个很具体的问题："这个模块有几个不同的修改理由？" 如果一个文件既管 HTTP 请求，又管数据库操作，还管业务逻辑，那它大概率违反了 SRP。
第三步：发现可以删掉的代码
这步其实挺有意思的。很多项目里都有一堆死代码------feature flag 关掉的、被废弃的 API、没人用的工具函数。它会帮你找出来，并且区分"可以直接删"和"需要制定计划再删"两种情况。
第四步：安全扫描
XSS、SQL 注入、SSRF、路径穿越、竞态条件、密钥泄露......这些它都会检查。
其中竞态条件（Race Condition）这块我写的特别详细，因为这是很多人在 review 时最容易忽略的。它会专门去找 check-then-act 模式、读-改-写操作、并发数据库访问这些容易出问题的场景。
第五步：代码质量扫描
错误处理有没有吞掉异常？有没有数据库的 N+1 查询？空值检查到不到位？这些"小问题"在生产环境里都可能变成大事故或者性能问题。
最后：结构化输出 + 确认
所有发现按严重程度分成四个等级：
| 等级 | 含义 | 怎么处理 |
|---|---|---|
| P0 | 严重 | 必须 block merge |
| P1 | 高危 | 应该在合并前修复 |
| P2 | 中等 | 这个 PR 修或者建个 follow-up |
| P3 | 低优 | 可选优化 |
输出之后，它不会自作主张去改代码。而是先问你：要修全部，还是只修 P0/P1，或者修指定的。
这个"先 review 再确认"的设计是我特意做的------Code Review 的价值不只是发现问题，更重要的是让你理解问题。如果 AI 直接帮你改了，你连有什么问题都不知道，那这个 review 就没意义了。
为什么我觉得它火了
发完推之后，仓库几天内涨到了 460+ Star，40+ Fork。
评论区和私信里，大家反馈最多的是两点：
第一，"终于有个体系化的 Review 方案了"
很多独立开发者和小团队，根本没有 Code Review 的流程。不是不想做，是没人帮你 review。有了这个 Skill，相当于随时有个资深工程师帮你把关。
这个需求其实比我想象的要大。我之前以为 Code Review 主要是大厂的需求，没想到独立开发者和小团队对这块的渴求更强烈------因为他们更没有犯错的资本。
第二，"终于不是 AI 味十足的泛泛建议了"
这要归功于那几份 checklist。我把 security-checklist、solid-checklist、code-quality-checklist 都放在了 references/ 目录下，每份都是实打实的检查清单，不是那种"注意安全问题"之类的废话。
比如安全检查那份，光竞态条件就列了四个子类：共享状态访问、TOCTOU（检查后使用）、数据库并发、分布式系统。每个子类下面都有具体的代码模式和需要问的问题。
这就是 Skill 的魅力------你把专业知识结构化地喂给模型，它的输出质量会有质的提升。
怎么做到的？聊聊 Skill 的设计思路
这个 Skill 的结构很简单：
bash
code-review-expert/
├── SKILL.md # 主文件，定义整个 review 流程
├── agents/
│ └── agent.yaml # Agent 配置
└── references/
├── solid-checklist.md # SOLID 原则检查清单
├── security-checklist.md # 安全检查清单
├── code-quality-checklist.md # 代码质量检查清单
└── removal-plan.md # 代码清理计划模板核心设计有几个关键点：
1. references 实现按需加载
这是 Skill 体系最优雅的地方。
四份 checklist 的内容加起来好几千字，如果全塞进 SKILL.md，一上来就会吃掉大量上下文窗口。所以我把它们放在 references/ 里，SKILL.md 里只在需要的步骤写 Load references/xxx.md。
模型执行到那个步骤时才会去读对应的文件，用完就可以"忘掉"了。这就是之前文章里讲过的 Progressive Disclosure（渐进式加载），Skills 最精妙的设计之一。
2. Workflow 要设计得有节奏感
我试过把所有检查点平铺在一起，效果很差------模型会东一榔头西一棒子，安全问题和命名规范混在一起说。
最后我按照真实的 Code Review 流程来编排：先看改动范围，再看架构设计，然后看安全，最后看代码质量。每一步之间是递进关系，从宏观到微观。
这个设计借鉴了人来做 Code Review 的习惯------好的 reviewer 不会上来就抠细节，而是先理解整体改动的意图和影响范围。
写在最后
你猜我写这个 skill 花了多久？
3,2,1,揭晓答案。
我只花了 10 分钟。不可思议吧。
怎么做到的？现在 claude 官方有一个叫 skill-creator 的 skill，帮你来写 skill，然后基于它可以很快搭出骨架来。后续，就是基于我的专业经验，引导 agent 帮我把一些关键的原则拆分为各个 checklist 文档，聊个几轮，这个高质量的 skill 就完工了。
回头看这件事，我觉得这也是 Skills 生态最让人兴奋的地方：每个有专业积累的开发者，都可以很快把自己的经验沉淀成一个 Skill，让 AI 帮更多人受益。
你不需要会写 MCP Server，不需要懂协议，不需要搞 OAuth 鉴权。就是一个 Markdown 文件 + 几份参考文档，仅此而已。
仓库在这里，欢迎 Star 和提 PR：
GitHub : sanyuan0704/code-review-expert
安装：
npx skills add sanyuan0704/code-review-expert
如果你也在做 Skill 开发，或者有什么好用的 Skill 推荐，评论区欢迎来聊。