Agent Skills 实战：把 Code Review 规范写成 Skill
从0到1！想入门大模型(LLM)却不知道从哪开始?我根据最新的技术栈和我自己的经历&理解，帮大家整理了一份LLM学习路线图，涵盖从理论基础到落地应用的全流程!拒绝焦虑，按图索骥~~因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取2025最新版CSDN大礼包：《AGI大模型学习资源包》免费分享因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取2025最新版CSDN大礼包：《AGI大模型
团队做 Code Review 时，若每人标准不一，反馈格式混乱，很难沉淀成习惯。把评审清单写进一条 Agent Skill，助手在你说「review 这段代码」「帮我审一下 PR」时就按同一套标准输出，必改/建议/可选分清楚，格式统一。本篇从评审清单到 SKILL.md 结构、可选 reference.md、触发与输出和团队协作，走完一整套实战。
一、从团队评审清单到技能范围
先明确「审什么、怎么报」。常见维度可包括：
-
安全：敏感信息、依赖漏洞、权限与输入校验等。
-
可读性：命名、注释、复杂度、重复代码等。
-
测试：有无单测、边界是否覆盖、是否易测等。
-
输出格式：每条问题标为 必改 / 建议 / 可选，并注明位置（文件:行或片段）、理由与修改建议。
示例（可据团队裁剪）：
|
类别 |
必改项 |
建议项 |
可选项 |
|---|---|---|---|
|
安全 |
硬编码密钥、未校验输入 |
依赖版本、日志脱敏 |
加固建议 |
|
可读性 |
无注释的复杂逻辑、魔法数字 |
命名、文件过长 |
注释风格 |
|
测试 |
核心路径无单测 |
边界与异常用例 |
覆盖率目标 |
技能的目标：助手在用户给出「这段代码」或「这个 PR」时，按上述维度检查并输出结构化的评审结果（必改/建议/可选 + 位置 + 理由 + 建议）。
二、SKILL.md 结构示例
在 .cursor/skills/code-review/ 下建 SKILL.md。推荐目录结构：
code-review/
├── SKILL.md
└── reference.md # 可选，完整检查清单
示例 SKILL.md 如下：
---
name: code-review
description: 对用户提供的代码或 PR 进行 Code Review，按团队规范输出评审结果；适用于用户说「review 这段代码」「审一下这段」「code review」「评审代码」或提及 PR 评审时。
---
# Code Review 技能
当用户要求对代码进行评审时，按以下规范执行并输出结构化结果。
## 执行前
- **评审范围**：用户 @ 的文件、选中的代码块或粘贴的片段。若用户只说「review」「审一下」等未指明范围，先询问要评审的文件或代码，再执行。
- 确认有可读的代码内容后，再按下方维度与格式输出。
## 评审维度
1. **安全**：敏感信息暴露、依赖漏洞、输入校验与权限。
2. **可读性**：命名、注释、复杂度、重复与魔法数字。
3. **测试**：核心逻辑是否有单测、边界与异常是否覆盖。
## 输出格式
对每个问题注明：
- **级别**：必改 / 建议 / 可选
- **位置**：文件路径与行号（或代码片段）；整体性建议可写「（整体）」代替具体位置
- **理由**：为何算问题
- **建议**：如何修改（简短可操作）
先列必改，再列建议，最后可选。若某维度无问题，可写「无」。
## 检查要点（必改）
- 硬编码密钥、token 或敏感配置
- 用户输入未校验即参与计算或持久化
- 核心业务逻辑无任何单测
## 检查要点（建议）
- 函数过长、圈复杂度过高、重复代码
- 魔法数字、含糊命名、缺少必要注释
- 依赖版本过旧或已知漏洞
## 示例输出格式
**必改**
- `src/auth.ts:12` — 密钥写死在代码中。建议：移至环境变量或配置服务。
**建议**
- `src/utils.ts:45` — 函数超过 80 行，建议拆成小函数并按职责命名。
**可选**
- `（整体）` — 可增加错误码与日志级别约定，便于排查。
可根据团队实际增删「检查要点」和「输出格式」；复杂清单可放到 reference.md，主文件只写「见 reference.md 第 x 节」。
三、可选 reference.md
若评审项很多，可在同目录下增加 reference.md（与 SKILL.md 同级），例如：
-
按模块（如 API、前端、脚本）拆不同检查项。
-
列出「禁止/推荐」模式与示例代码。
-
链接到内部文档或规范。
SKILL.md 里写一句：「完整检查清单见 reference.md。」助手会在需要时读取。
以下为 reference.md 示例，可按团队实际裁剪：
# Code Review 完整检查清单
本文件供 code-review 技能在需要时查阅，与 SKILL.md 中的「检查要点」一致并展开细节。
---
## 一、按模块的检查项
### API / 后端
| 类别 | 必改 | 建议 | 可选 |
|--------|------|------|------|
| 安全 | 输入校验、无硬编码密钥 | 依赖版本、日志脱敏 | 限流与熔断 |
| 可读性 | 复杂逻辑有注释 | 命名、单文件行数 | 注释风格 |
| 测试 | 核心路径有单测 | 边界与异常用例 | 覆盖率阈值 |
### 前端
| 类别 | 必改 | 建议 | 可选 |
|--------|------|------|------|
| 安全 | 无敏感信息进 localStorage、XSS 防护 | 依赖版本 | CSP 配置 |
| 可读性 | 组件职责单一、无魔法数字 | 命名、文件拆分 | 注释风格 |
| 测试 | 关键交互有单测/快照 | 边界与可访问性 | 覆盖率阈值 |
### 脚本 / CLI
| 类别 | 必改 | 建议 | 可选 |
|--------|------|------|------|
| 安全 | 无硬编码密钥、对输入做校验 | 日志不打印敏感信息 | - |
| 可读性 | 用法说明或 --help | 命名、错误信息清晰 | - |
| 测试 | 主流程可测 | 边界与退出码 | - |
---
## 二、禁止 / 推荐模式与示例
### 禁止：硬编码密钥
```text
❌ const API_KEY = "sk-xxxx";
❌ password = "admin123";
```
改为环境变量或配置服务（如 `process.env.API_KEY`、密钥管理服务）。
### 推荐：用户输入先校验再使用
```text
✅ 对入参做类型、长度、范围校验后再参与计算或写库。
✅ 对来自外部的 ID、路径做白名单或规范化，避免注入。
```
### 建议：过长函数拆分
```text
✅ 单函数建议 80 行内；圈复杂度过高时拆成小函数并保留清晰命名。
✅ 重复逻辑提取为共用函数或工具模块。
```
---
## 三、内部规范链接（占位）
- API 设计规范：\[团队内部链接]
- 前端组件规范：\[团队内部链接]
- 安全 checklist：\[团队内部链接]
将上述链接替换为团队实际文档地址即可。
四、在 Cursor 里的触发与输出
-
隐式：用户说「review 这段代码」「帮我审一下下面这段」「做一次 code review」，助手根据 description 匹配到 code-review 技能，按上述维度与格式输出。
-
显式：用户说「用 code-review 技能审一下这段代码」或输入
/code-review（若产品支持）。
输出应包含：必改 / 建议 / 可选 分段，每条带位置、理由与修改建议，便于作者逐项处理。
五、与 Rules、MCP 的衔接
-
若团队还有全局约定（如「所有接口必须校验输入」），可放在 Rules 里，Code Review 技能只负责「按清单输出评审结果」；两者配合使用。
-
若需要「查依赖漏洞」「读 CI 结果」等，可配合 MCP 提供数据，Skill 规定「怎么查、怎么报」；详见Rules、Skills、Command、Workflow、MCP、Subagent、Hooks、Memories 怎么选？对比与搭配指南。
六、团队协作：统一技能与 Review 他人写的 Skill
-
统一技能目录：建议把 code-review 等团队技能放在项目内
.cursor/skills/，随仓库提交，所有人拉代码即有一致环境。 -
Review 他人写的 Skill：新技能或改动可走 PR，重点看：description 是否覆盖常见说法、检查项是否与团队共识一致、输出格式是否清晰；必要时在对话里实际触发一次做验收。
小结：从评审清单到 SKILL.md（维度 + 输出格式 + 检查要点）、可选 reference、触发方式与团队协作，就完成了一条可复用的 Code Review 技能。下一篇将继续介绍 常用 Skills 例子。
最后
从0到1！大模型(LLM)最全学习路线图，建议收藏！
想入门大模型(LLM)却不知道从哪开始? 我根据最新的技术栈和我自己的经历&理解，帮大家整理了一份LLM学习路线图，涵盖从理论基础到落地应用的全流程!拒绝焦虑，按图索骥~~
因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取