做这个 Skill 的起因其实很简单。
我自己平时写代码，改完了之后经常想让 Claude Code 帮我 review 一下。直接跟它说"帮我看看代码有没有问题"，它确实会给你一些反馈，但说实话，质量参差不齐。
这就跟新来的实习生做 Code Review 一样，不是他不想认真看，是他不知道该看什么、怎么看、按什么优先级来。
所以问题的本质是：模型需要一套结构化的 Review 框架，告诉它该检查什么、怎么分级、用什么格式输出。
这不就是 Skill 最擅长干的事吗？
code-review-expert 是什么
一句话概括：一个让 AI 用资深工程师的视角帮你做 Code Review 的 Skill。
作者：神三元
链接：https://juejin.cn/post/7606548472223137834
来源：稀土掘金
整个 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 mergeP1高危应该在合并前修复P2中等这个 PR 修或者建个 follow-upP3低优可选优化
发完推之后，仓库几天内涨到了 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 体验AI代码助手 代码解读复制代码code-review-expert/
├── SKILL.md # 主文件，定义整个 review 流程
├── agents/
│ └── agent.yaml # Agent 配置
└── references/
├── solid-checklist.md # SOLID 原则检查清单
├── security-checklist.md # 安全检查
评论