Code Review Skill: 让 AI 替你把关每一次提交

Code Review 这件事，嘴上都说重要，实际做起来能拖就拖。PR 挂了两天没人看，reviewer 扫一眼点了 approve，合进去才发现漏了个空指针。这不是哪个团队的问题，是所有团队的通病。

Zapier 的 Code Review 这个 Skill 试图解决的就是这件事。它不替代人类 reviewer，不要求你改 workflow，也不在代码仓库里加一堆 bot 配置。它的定位很明确：在你的 AI 编程助手里面装一个审查者，每次你写完代码喊一声 review，就能拿到一份结构化的反馈。

这篇文章会带你走一遍这个 Skill 的安装、工作原理和实际效果。更重要的是，我想聊聊它背后那套”AI 做 CR”的设计逻辑，哪些地方做得聪明，哪些地方暴露了 LLM 审查的天然局限。

在 Smithery 上，这个 Skill 已经有 13,500 次下载，评分 4.6。Zapier 自己也在用它做内部 PR 预审查。但你得知道它不是什么银弹，它是一个设计得很节制的工具，知道了边界才能用对地方。

环境准备

安装很简单，前提是你的 AI 客户端支持 Agent Skills 标准。目前主流编程助手基本都覆盖了：

• Claude Code
• Cursor
• Codex
• Copilot CLI

换句话说，只要你用的不是太偏门的客户端，大概率都能装上。

npx skills add https://github.com/zapier/zapier-mcp --skill 'Code Review'

跑完之后，skill 会自动注册到你的技能列表里。不需要额外的 API key 或服务端配置，审查能力完全依赖你当前客户端的 LLM。

验证是否装好也很直观，在项目目录下随便改点代码，然后对你的 AI 助手说一句”review my changes”。如果它开始读 diff 并产出结构化的反馈，说明到位了。如果没反应，八成是 skill 没有被正确索引，重新跑一次 install 命令通常能解决。

有一个容易踩的坑：这个 Skill 依赖 git 工作区。如果你的改动还没有 stage 或者 commit，它默认审查未暂存的修改。如果是 PR 场景，确保你的本地分支已经 push 到远端，否则它拿不到完整的 diff 上下文。

操作流程

这个 Skill 的工作方式没有花哨的 UI，整个流程在对话窗口里完成。但真正有价值的是它审查的分层逻辑，而不是表面那几步操作。

第一步，触发审查。最自然的用法是在提交前对你的 AI 说”review this”，它自动获取当前分支的 diff。如果是 GitHub PR 场景，传入 PR 编号也可以。整个过程不需要离开编辑器，不需要切到 GitHub 页面，对话就是界面。

第二步是分析维度切换，这步决定了审查质量的上限。Skill 会让 LLM 从四个维度依次扫描代码：

• 代码质量：命名规范、函数复杂度、未使用的变量、类型安全性
• 安全性：SQL 注入风险、未校验的输入、敏感信息硬编码
• 性能：N+1 查询、不合理的循环嵌套、内存泄漏隐患
• 最佳实践：错误处理是否完整、测试覆盖缺口、模块边界是否清晰

第三步是输出结构化反馈。每个发现都会标记严重程度和具体位置。这种格式的好处很明显：reviewer 可以快速扫描关键问题，作者也不用在海量文本里翻找有效评论。但实话说，LLM 审查的准确率跟模型能力强绑定，用弱模型跑的话假阳性会非常烦人。

第四步，反馈闭环。Skill 的设计假设是人工最终拍板，它不给”自动合并”或”自动拒绝”的选项。所有发现都是建议性的，这其实是最务实的定位。

关键设计

仔细看这个 Skill 的 SKILL.md 结构，能发现几个值得聊的设计决策。

第一，零配置哲学。Skill 没有任何 YAML 配置文件、没有 .code-review.json、没有 review 规则 DSL。所有的审查标准直接写在 Skill 的 instructions 里，通过 System Prompt 注入 LLM。这意味着你能用，但你不能定制审查规则。这是 tradeoff，不是 bug。

如果你需要特定规则，比如”禁止使用 any 类型”或”所有 API 调用必须有超时设置”，这个 Skill 做不到。你得自己 fork 一份改 SKILL.md，或者换一个支持规则配置的审查工具。Zapier 赌的是大部分团队不需要那么精细的控制，装上就能用比什么都能配置更值钱。

第二，它选择了”通用审查”而非”语言专项审查”。没有 Python 专项规则，没有 React 专项模式，全靠 LLM 的编码知识做泛化判断。这带来的结果是：对于常见语言效果不错，对于小众语言或框架内部约定，准确率会显著下降。

第三，触发机制设计得比较克制。触发词是”review”、“code review”、”check my code”等自然语言，不搞自动 hook 每次 commit 都跑。这个选择是对的，全自动审查会产生大量噪音，尤其是改动只有一行的时候 LLM 也会煞有介事地给你一段分析。

第四，它不存储任何审查历史。每次调用都是无状态的，不会学习你的项目偏好，也不会记住你上次 dismiss 了哪种类型的建议。短期看是简化，长期看是局限。

使用场景

我设想了两个典型的使用场景，覆盖这个 Skill 最擅长的事和它最不擅长的事。

场景一：个人项目的最后一层防线。 你一个人在维护一个 side project，没有队友帮你 review。每次提交前丢给这个 Skill 扫一遍，它至少能帮你揪出明显的低级错误：漏掉的空值检查、忘记关闭的文件句柄、硬编码的 API key。这些事人类 reviewer 也不一定能 100% 发现，但 LLM 对模式匹配天然敏感。

场景二：大团队 PR 的预审查。 在正式的 peer review 之前，先让 AI 跑一轮，把机械性的问题（命名、格式、基础安全检查）清掉。人类 reviewer 收到的是一个已经做过初步净化的 PR，可以专注于架构决策和业务逻辑。这个模式在 Zapier 自己的团队里跑得很稳。

边界在哪里？高复杂度架构决策、需要深度业务理解的设计评审、跨多个微服务的变更影响分析，这几个场景 LLM 审查帮不上忙。别在这些事上浪费 token。

洞察与反思

用了一段时间后，我对 AI 做 CR 这件事的核心认知发生了一些变化。

一开始我觉得 AI 审查最大的价值是”发现人类漏掉的问题”。但实际用下来，更重要的价值是它改变了 review 的心理门槛。很多开发者不愿意主动找人 review 是因为”不好意思麻烦别人”或者”觉得自己代码写得不好”。对着一个 Skill 喊 review 完全没有心理负担，这种低摩擦的入口比审查本身的质量更重要。

另一个意外发现是它对命名质量的审查比人类强。LLM 见过海量代码，对”这个函数名和它做的事不匹配”的敏感度远高于人类 reviewer。人类更容易被熟悉的命名习惯带偏，AI 没有习惯。

但局限也很明显。LLM 审查对上下文窗口有硬依赖：如果 diff 涉及的文件散落在项目各处，且没有足够的上下文拼接能力，审查质量会断崖式下降。Zapier 这个 Skill 没有做 RAG 或代码图谱索引，纯靠单次 diff 和 LLM 的编码知识，这也是零配置哲学的代价。

还有一个容易被忽视的问题：审查一致性。同一个 diff 跑两次，结果可能不完全一样。LLM 的非确定性输出在代码生成场景可以接受，但审查场景需要稳定的质量预期。追求”每次 PR 必须过同样的检查项”的团队，纯 LLM 审查不是合适的选择。

资源地址

总结

Zapier 的 Code Review Skill 是一个定位精准的小工具：它不试图替代人类 reviewer，不要求你改变开发流程，只在现有的 AI 编程助手里面嵌入一个审查节点。零配置、低摩擦、产出结构化，这三点让它成为个人开发和小团队的实用选择。

值得装的场景：一个人写代码需要第二双眼睛、团队 PR 流程里需要一个机械性的预审查环节、或者你单纯想看看 AI 能从你的代码里发现什么。

不值得的场景：你需要高度定制化的审查规则、你的项目用了冷门语言或框架、你的代码库大到需要跨文件上下文分析。

说到底，AI CR 改变的不是审查结果，是审查习惯本身。当一个”review”变成聊天的自然延伸，不需要排期、不需要等人、不需要心理建设，你才会真的开始频繁用它。