手把手教你编写第一个 Code Review Skill

最新推荐文章于 2026-06-06 14:58:03 发布

原创最新推荐文章于 2026-06-06 14:58:03 发布 · 679 阅读

5 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#代码复审 #AI编程

代码编写同时被 2 个专栏收录

35 篇文章

订阅专栏

编码IDE

10 篇文章

订阅专栏

为什么需要 Skill？

想象一下，每次让同事做 Code Review，你都要重复说：“注意看有没有硬编码密钥、函数不要太长、关键逻辑要加测试……” 时间久了，大家记不住，标准也不统一。

Skill 就是把你团队的“最佳实践”写成一份“智能菜谱”，AI 看到“做 Code Review 这道菜”时，自动按你的配方一步步执行，保证每次味道都一样。

三步写出你的第一个 Skill

第 1 步：准备“菜谱”文件

在你的项目根目录，创建这个结构：

你的项目/
├── .cursor/
│   └── skills/
│       └── code-review/       ← Skill 文件夹，名字随意但建议用短横线
│           ├── SKILL.md       ← 核心“菜谱”（必须这个文件名）
│           └── reference.md   ← 可选的详细配料表

第 2 步：编写核心“菜谱”（SKILL.md）

用文本编辑器打开 SKILL.md，按这个模板写：

---
name: code-review                    # Skill 的名字（建议英文小写+短横线）
description: 对代码进行结构化评审，检查安全、可读性、测试问题，输出必改/建议/可选项
---

# Code Review 技能

## 什么时候用？
当用户说“review 一下这段代码”、“帮我审审”、“做 code review”时自动触发。

## 评审维度
1. **安全**：敏感信息、输入校验、依赖漏洞
2. **可读性**：命名、注释、复杂度、重复代码
3. **测试**：是否有单测、边界是否覆盖

## 输出格式（严格按这个来）

**必改**（不改不能合入）
- `文件名:行号` — 问题描述。建议：具体修改方案。

**建议**（推荐改进）
- `文件名:行号` — 问题描述。建议：优化方向。

**可选**（有更好）
- `（整体）` — 建议说明。

*先列必改，再列建议，最后可选。如果某个维度没问题，写“无”。*

## 具体检查项

### 必改项（发现必须指出）
- 代码里直接写死的密码、密钥、Token
- 用户输入没校验就直接使用
- 核心业务逻辑完全没有单元测试

### 建议项（推荐优化）
- 函数超过 80 行或逻辑太复杂
- 有“魔法数字”（如 `if (status == 3)` 的 3 没解释）
- 命名让人看不懂做什么（如 `func a()`）

### 可选项（锦上添花）
- 增加错误码规范
- 补充架构图或设计说明

关键说明：

--- 之间的部分是“元数据”，AI 靠 description 来判断什么时候用这个 Skill
下面内容是具体指令，AI 触发技能后会仔细读并执行
检查项按你团队实际情况增减

第 3 步（可选）：补充详细资料

如果检查项很多，可以写在同目录的 reference.md 里，然后在 SKILL.md 里写“完整清单见 reference.md”，AI 会按需读取。

# reference.md 示例

## 安全类详细检查

### 前端安全
- ❌ 避免：`localStorage.setItem("token", "硬编码token")`
- ✅ 推荐：从环境变量或配置服务获取

### 后端安全
- 所有 API 入参必须校验类型、长度、范围
- 数据库查询必须参数化，防止 SQL 注入

## 可读性类详细检查
- 函数名用动词开头：`getUser()` 而不是 `user()`
- 复杂算法必须加注释说明思路
- 单个文件建议不超过 500 行

怎么用你写的 Skill？

自动触发

在 Cursor 里，当你对 AI 说：

“review 一下这段代码”
“帮我审审这个函数”
“做一次 code review”

AI 会自动识别到你在请求 Code Review，然后加载你的 Skill，按你写的标准输出结构化结果。

手动触发

直接说：“用 code-review 技能审一下这段代码”。

看到的效果

假设你给 AI 一段代码：

def process_user_data(user_input):
    api_key = "sk-live-123456789"  # 硬编码密钥
    # 直接使用用户输入
    result = expensive_calculation(user_input)
    return result

AI 会按你的 Skill 输出：

必改

demo.py:2 — 密钥直接硬编码在代码中，泄露风险高。建议：移至环境变量（如 os.getenv("API_KEY")）或密钥管理服务。

建议

demo.py:4 — 用户输入 user_input 未经验证直接参与计算，可能引发性能或安全问题。建议：增加长度、类型校验后再使用。

可选

（整体） — 可考虑为 expensive_calculation 函数添加单元测试，确保核心逻辑正确性。

团队如何共享？

项目内共享：把 .cursor/skills/ 目录加入 Git，队友拉取代码后自动就有这个 Skill
全局共享：把 Skill 文件夹放在 ~/.cursor/skills/（macOS/Linux）或 C:\Users\你的用户名\.cursor\skills\（Windows），所有项目都能用
PR 评审：队友新增或修改 Skill 时，可以走 Code Review 流程，确保质量

进阶技巧

1. 渐进式加载

如果 Skill 很复杂，可以把不同部分拆开：

code-review/
├── SKILL.md           # 主指令
├── security.md        # 安全检查细则
├── readability.md     # 可读性细则
├── examples/
│   ├── good.py       # 好代码示例
│   └── bad.py        # 坏代码示例
└── templates/
    └── output.md     # 输出模板

在 SKILL.md 里写：“安全检查细则见 security.md”，AI 会在需要时去读，不一次性全加载。

2. 精准触发

在元数据里加 trigger_keywords，让 AI 更容易识别：

---
name: code-review
description: 对代码进行结构化评审...
trigger_keywords:
  - review
  - 审一下
  - code review
  - 代码评审
  - 帮我看看代码
---

从今天开始

在你的项目里创建 .cursor/skills/code-review/SKILL.md
把上面模板复制过去，按你们团队标准修改检查项
下次让 AI 评审代码时，看它是否按你的标准输出
根据实际使用反馈，不断完善你的 Skill

Skill 就像给 AI 的“岗前培训”——一次编写，每次执行都一致。从 Code Review 开始，逐步把团队的各种规范都变成 Skills，让 AI 成为你的标准化助手。