Claude Code 代码审查别再”感觉有问题”了，这个开源项目让AI的结论都有证据

拾遗·Skill精选官 内容创作者 2026-10-01 16 阅读

用 Claude Code 写代码，你可能只用了它 5% 的能力。

大多数人的用法是：丢一段代码，让 AI 点评一下。结果呢？泛泛而谈，言之无物，该踩的坑一个没说出来。

今天介绍一个开源项目——serendip-ml/claude-code-skills，它让 Claude Code 变成了一个有原则的代码审计员，每一条结论都要求有命令执行的证据支撑，不是”感觉有问题”，而是”这个问题我跑出来了，实锤在这里”。

两个核心命令，干两件具体的事

/review-code — 提交前的最后一道关卡

你在一个分支上写完了代码，commit 之前运行它。它会拿你的 diff 去和目标分支（main / develop 随便指定）做对比，用全新的上下文跑一遍审查，不带实现时的偏见。

输出按严重程度分层：

  • Critical：Bug、安全漏洞、数据丢失风险——这类必须先修
  • Important：破坏性变更、资源泄漏——建议改
  • Minor：代码风格改进——可改可不改
  • Nitpick：个人偏好，纯观察

最后给一个结论：「Ready to PR」还是「Fix issues first」。不是那种列表式的废话，是真的在替你把关。

/grade-python-project — 给你的整个项目打一次分

不是那种给个总分的敷衍评分。它把 Python 项目拆成 7 个维度，每个维度 0-10 分，每一项扣分都必须有实际命令输出作为证据。

7 个维度：架构与设计（15%）、代码质量（20%）、安全（15%）、测试（15%）、文档（10%）、生产就绪（15%）、依赖与兼容性（10%）。

举个例子：作者用它给 pydantic 库打过一次分，得分 9.30/10，每一个扣分点都写了具体命令和输出。这种评分是有重量的，因为你能看到推理过程。

它的审查哲学：证据大于直觉

项目 README 里明确写了三条原则：

  1. 证据驱动 — 每个结论必须有对应的命令输出。没有跑过验证的”可能有问题”不算。
  2. 验证优先 — “看起来有问题” ≠ “确实有问题”。Claude 必须先执行、看到结果，再下结论。
  3. 可操作的输出 — 每个问题都附上具体位置和修复建议，不是那种”建议提高代码质量”的废话。

这套原则让它和普通 AI 代码审查拉开了本质差距。普通审查是”给个印象分”，它是”法庭呈堂证供”。

安装方式

# 克隆到本地
git clone https://github.com/serendip-ml/claude-code-skills.git

# 整体复制到 Claude Code 命令目录
cp -r claude-code-skills ~/.claude/commands/

# 或者只装其中一个技能
cp -r claude-code-skills/skills/review-code ~/.claude/commands/
cp -r claude-code-skills/skills/grade-python-project ~/.claude/commands/

适合谁用

  • 有代码审查流程的团队：把 /review-code 接入 CI 或 pre-PR hook，让每次合并都有 AI 帮你在前道把关
  • 独立开发者：发开源项目之前用 /grade-python-project 自查一遍，有个量化的质量参照
  • 代码质量有洁癖的人：它不会给你那种”感觉还不错”的情绪价值，只给实打实的审计报告

GitHub: https://github.com/serendip-ml/claude-code-skills

GitHub: https://github.com/serendip-ml/claude-code-skills

评论区

0 条评论

登录后可评论。

拾遗·Skill精选官 16 阅读