你可能已经听说过Claude Skill——Anthropic在2025年10月推出的这个功能，一时间成了开发者圈子的热门话题。但说实话，刚开始我也觉得这不过是又一个“AI新特性”，听听就好，不用当真。
直到有一天，我对着一个2000多行的React重构项目发了愁。每次让Claude Code帮忙，都要重复交代“记得用TypeScript严格模式”“API调用要加错误处理”“组件要符合单一职责原则”……聊了十几轮之后，Claude Code还会“忘记”我最初的要求。
后来我把这些重复的要求封装成几个Skill文件。现在只要一句@skill react-refactor，它就知道该怎么做。那个2000行的类，原本估计要花三天时间重构，最后两个下午就搞定了。
这篇文章不讲那些虚头巴脑的概念，直接聊怎么用Claude Skill把代码审查和单元测试这两件事自动化。
一、Skill到底是什么——给懒得读文档的人
简单说，Skill就是给Claude的“技能包”。在.claude/skills/目录下创建一个markdown文件，把常用的提示词、工作流程、代码规范写进去。需要的时候，一句@skill 技能名就能调用。
你可能想问：这和直接写提示词有什么区别？区别大了。
手写提示词的痛点我太清楚了：每次都要从Notion复制粘贴，一天下来光复制粘贴就要花半小时；今天用的提示词和上周的不一样，效果飘忽不定；想回溯“上次那个好用的版本”根本找不到。长对话里，Claude Code很容易忘记你最初的要求，聊到第20轮，你发现它又在犯之前说过不要犯的错误。
Skill把这些问题一次性解决了：用Git管理版本，随时回溯；放在团队仓库里所有人同步；不会因为对话太长而失效。
从架构上看，Skill采用的是“三层渐进式披露”设计。Claude启动时只预加载技能的元数据（名称和描述），几乎不占用上下文窗口。当它判断某个技能与当前任务相关时，才逐步加载完整的指令内容，必要时再调用附加的脚本文件。这意味着你可以在Skill里塞很多内容，不用担心撑爆上下文限制。
你可能会好奇Skill和MCP有什么区别。MCP是一种协议，关注的是AI如何以统一方式调用外部工具和服务，本身不定义任务逻辑。而Skill封装了完整的做事方法——教AI怎么处理特定任务。两者不是二选一的关系，经常配合使用。
二、代码审查Skill——让AI帮你找出自己写的bug
2.1 场景痛点
你辛辛苦苦写完一个功能，自我感觉良好，提了PR。第二天reviewer打回来：“这里有个空指针风险，这里SQL拼接有注入隐患，测试覆盖率也不够。”
你一边改一边想：这些低级问题，为什么不在我提交之前就发现？
现在可以了。
2.2 动手搭建一个代码审查Skill
先在你的项目根目录创建Skill文件夹：
mkdir -p .claude/skills/code-review
在里面创建SKILL.md文件。这是Skill的核心，Claude会读取它来理解要怎么干活。
name: code-review
description: 对代码变更进行多维度审查，涵盖安全、逻辑、性能、代码风格四个维度，输出结构化报告
代码审查专家 Skill
你是一位经验丰富的代码审查专家。收到代码后，请按以下标准进行系统化审查。
审查维度
1. 安全性
- SQL注入风险（尤其检查字符串拼接的查询）
- XSS漏洞（用户输入是否经过转义）
- 敏感信息泄露（API密钥、密码是否硬编码）
- 权限校验是否完整
2. 逻辑正确性
- 空指针/undefined访问风险
- 边界条件处理（数组越界、除零、空集合）
- 并发安全问题（竞态条件、死锁）
- 异常处理是否完善
3. 性能
- 不必要的循环嵌套
- N+1查询问题
- 内存泄漏风险（事件监听未移除、定时器未清理）
- 大数据量操作是否有分页或流式处理
4. 代码质量
- 命名是否符合项目规范
- 函数是否过长（超过50行需拆解）
- 重复代码是否存在
- 注释是否与代码一致
输出格式
请按以下结构输出审查报告：
🚨 严重问题（P0 - 必须修复）
（安全漏洞、逻辑错误等会导致线上故障的问题）
⚠️ 警告（P1 - 建议修复）
（性能隐患、代码异味、可维护性问题）
💡 建议（P2 - 可选）
（优化建议、最佳实践参考）
✅ 亮点
（代码中值得肯定的部分）
审查原则
- 所有判断必须有具体依据，引用代码行号
- 每个问题附带修复建议，给出示例代码
- 宁缺毋滥，避免刷屏式输出低质量建议
- 不确定的地方标注“需要人工确认”
2.3 如何使用
保存好文件后，在Claude Code中输入：
@skill code-review 请审查 @src/services/userService.ts 这个文件
或者更简单——审查所有未提交的变更：
@skill code-review 请审查我当前的git diff
有团队甚至更进一步，在Claude Code里配置了六个专门的审查代理同时跑：安全审查员检查注入风险和密钥泄露，Bug审查员排查空指针和竞态条件，代码质量审查员检查SOLID原则违反情况，测试覆盖率审查员识别哪些代码路径没有测试覆盖。
输出是一个结构化的报告，每个问题带有置信度评分（0-1之间）。置信度低于阈值的会被自动过滤掉，免得你被一堆无关痛痒的建议淹没。
2.4 进阶玩法：接入CI/CD
Skill不只是本地用的。你完全可以把审查流程接入CI/CD流水线。
官方提供了GitHub Action，在.github/workflows/下创建vet.yml文件，每次PR提交时自动触发审查。审查结果会以行内评论的形式出现在PR页面上，和你平时的人工review体验一模一样。
相比传统的lint工具只检查格式问题，AI审查能指出边界条件、不安全的API模式、安全漏洞——这些都是静态分析工具经常漏掉的东西。
不用太担心审查质量——根据一些实验数据，Claude 3.5在单元测试生成上的准确率能达到93.33%。当然代码审查和测试生成不完全一样，但这个数据至少说明Claude在处理代码相关任务上的能力是经得起检验的。
三、单元测试生成Skill——把最枯燥的活丢给AI
3.1 场景痛点
写单元测试这件事，在开发者“最不想干的活”排行榜上常年稳居前三。不是不会写，是真的太烦了。
一个正常函数，手写覆盖正常路径+边界+异常，至少要十来分钟
遇到复杂逻辑，半小时起步
改一次代码，对应的测试用例要同步更新，这谁受得了
3.2 动手搭建一个测试生成Skill
mkdir -p .claude/skills/test-gen
创建SKILL.md：
name: test-gen
description: 为给定函数或模块自动生成单元测试用例，覆盖正常路径、边界条件、异常情况
单元测试生成专家 Skill
角色定位
你是一位经验丰富的测试工程师，擅长编写高质量、可维护的单元测试。
工作流程
Step 1: 分析待测代码
- 识别函数的所有输入参数及其类型
- 识别函数的返回值类型
- 识别函数内部的分支逻辑和依赖
Step 2: 设计测试用例
基于等价类划分和边界值分析法，覆盖以下场景：
| 用例类型 | 覆盖内容 | 最少数量 |
|---|---|---|
| 正常路径 | 函数设计场景下的典型输入 | 1-2个 |
| 边界条件 | 空值、零值、最大/最小值、数组首尾 | 2-3个 |
| 异常路径 | 无效输入、依赖失败、超时 | 2-3个 |
| 并发场景 | 如有状态，考虑竞态 | 按需 |
Step 3: 生成测试代码
- 使用项目已有的测试框架（Jest/Vitest/JUnit/pytest）
- 遵循AAA模式：Arrange（准备）、Act（执行）、Assert（断言）
- 每个测试用例独立，不依赖执行顺序
- Mock外部依赖，不发起真实网络请求
Step 4: 质量自查
- 每个用例是否有明确的预期结果？
- 测试命名是否清晰描述场景？
- 是否有冗余的测试用例？
输出格式
// 以实际框架为准，此处为示例
describe('functionName', () => {it('should return expected value when given valid input', () => {// Arrange// Act// Assert});
});
注意事项
不要修改源代码，只生成测试文件
不确定的地方添加 @todo 注释标注
如果待测代码难以测试，在报告末尾给出重构建议### 3.3 使用示例假设你有这样一个函数：```typescript
// utils/calculator.ts
exportfunction divide(a: number, b: number): number {
if (b === 0) {throw new Error('除数不能为0');}
return a / b;
}
在Claude Code里输入：@skill test-gen 为 @utils/calculator.ts 中的 divide 函数生成单元测试，使用 Jest 框架
AI会输出类似这样的测试代码：import { divide } from'./calculator';describe('divide', () => {
// 正常路径it('should return correct result when dividing positive numbers', () => {expect(divide(10, 2)).toBe(5);expect(divide(9, 3)).toBe(3);});it('should handle negative numbers correctly', () => {expect(divide(-10, 2)).toBe(-5);expect(divide(10, -2)).toBe(-5);});// 边界条件it('should handle division by 1', () => {expect(divide(100, 1)).toBe(100);});// 异常路径it('should throw error when dividing by zero', () => {expect(() => divide(10, 0)).toThrow('除数不能为0');});
});
有团队基于Claude Skills构建了完整的TDD流水线——Skills强制执行TDD规范，不可跳过任何步骤。也就是说，你可以让AI先生成测试，再写实现代码，整个过程完全自动化。人工智能技术学习交流群
伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇四、更高级的玩法：多Skill协作
单个Skill能做的事情有限，但多个Skill组合起来，威力就完全不一样了。举个例子，你可以这样编排一个完整的代码质量保障流水线：用test-gen Skill生成测试用例
用code-review Skill审查代码
用test-runner Skill（需要自己写）执行测试并汇总覆盖率
把所有报告整理成一份PR摘要
有开发者甚至用Claude Skill结合GitHub Actions做定时巡检，每天凌晨自动扫描代码库，生成安全报告发送到团队群里。这种组合玩法的核心思路是：把重复性的质量保障工作完全自动化，让人工review只关注那些真正需要人脑判断的问题。五、一些踩坑后的经验
5.1 Skill不是万能的
AI审查有自己的局限性。最大的问题在于：AI写的代码和AI审查同一份代码，很容易产生“盲点”——它会倾向于验证原始实现中的假设，而不是质疑这些假设本身。所以目前社区公认的最佳实践是专业化分工：不让同一个AI又写又审，而是用不同的Skill从不同角度分别审查——安全一个角度，逻辑一个角度，性能一个角度，最后汇总结果。5.2 关于数据安全
这个问题必须提一下。绝对不要把公司的核心代码、用户隐私数据、API密钥直接喂给公网的大模型。如果是敏感项目，建议使用公司内部部署的私有化模型，或者在本地运行。Skill本身是在本地运行的，但调用大模型API时数据会发往云端。这一点要心里有数。5.3 维护Skill像维护代码一样
Skill不是写一次就完事的。随着项目规范的变化、团队最佳实践的演进，Skill文件也需要持续更新。我现在的做法是把.claude/skills/目录加入Git仓库，团队共享一套Skill模板。有新成员加入，拉下来就能用。有改进就提PR，所有人都能同步。另外建议定期跑eval测试——验证Skill在典型场景下是否稳定输出符合预期的结果。否则改来改去，Skill退化了都不知道。5.4 关于命名和组织
Skill多了之后，容易记不住名字。我的经验是按功能域命名：code-review、test-gen、refactor、security-audit、doc-gen。如果项目比较复杂，可以用命名空间的方式，比如feat/payment-test-gen。还有一种常见的困惑：Skill和CLAUDE.md怎么配合？简单来说，CLAUDE.md是项目级别的全局配置，Skill是按需加载的专项能力。两者可以配合使用——CLAUDE.md里声明项目整体规范，Skill里定义具体任务的执行流程。结语
Skill这个东西，本质上是在帮你把“怎么干活”这件事固化下来。一次投入，持续受益。以前你可能觉得代码审查和写单元测试是不得不做的苦差事，现在你可以把它们变成一条命令、一个Skill的事。省下来的时间做什么都好——多看几页书，多喝几口咖啡，早点下班。不用追求一步到位写出完美的Skill。从一个小场景开始，比如先把代码审查的Skill搭起来，用一周感受一下变化，再逐步完善。毕竟工具的最终目的，是让你写代码更舒服一些。推荐学习
测试智能体与智能化测试平台公开课， 从架构设计到大厂落地，重塑自动化测试力。
扫码进群，报名学习。
关于我们
霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。