你或许已然听闻过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轮的时候, 你赫然发现它又在犯之前已经说过不许再犯的错误。
这一技能将这些问题予以一次性解决, 即运用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 - 可选）
（优化建议、最佳实践参考）
### 亮点
（代码中值得肯定的部分）
## 审查原则
1. 所有判断必须有具体依据，引用代码行号
2. 每个问题附带修复建议，给出示例代码
3. 宁缺毋滥，避免刷屏式输出低质量建议
4. 不确定的地方标注“需要人工确认”
2.3 如何使用
保存好文件后开云app官方入口网站世界杯直播观看，在Claude Code中输入：
@skill code-review 请审查 @src/services/userService.ts 这个文件
或者更简单——审查所有未提交的变更：
@skill code-review 请审查我当前的git diff
有团队甚至更甚一步, 在Claude Code里配置了六个专门的审查代理同时运行, 安全审查员检查注入风险和密钥泄露情况, Bug审查员排查空指针和竞态条件, 代码质量审查员检查SOLID原则违反情形, 测试覆盖率审查员识别哪些代码路径没有测试覆盖, 此为全部所为了。
输出的东西, 是那种具有结构化特点的报告, 每一个问题, 都附带有着置信度评分, 这个评分, 是处于0至1之间这样子的范围。那些置信度低于阈值的问题, 就会被自动地进行过滤处理, 从而避免你, 被那一堆毫无实质意义、无关紧要的建议给淹没掉, 就是这样的情况。
2.4 进阶玩法：接入CI/CD
技能并非仅仅用于本地, 你绝对能够将审查流程接入持续集成与持续交付流水线。
由官方所提供的GitHub Action, 需在.github/workflows/之下创建vet.yml文件, 于每次PR提交之际会自动触发审查, 审查的结果将会以行内评论的形式呈现在PR页面之上, 与你平常的人工review体验毫无二致。
与仅仅对格式问题予以检查的传统lint工具相比较而言, AI审查可以指出某些内容, 能指出边界条件, 能指出不安全的API模式, 能指出安全漏洞, 而这些都是静态分析工具常常会遗漏未检查出来的东西。
不须过分忧心审查质量, 依据某些实验数据, Claude 3.5于单元测试生成方面的准确率能够达到93.33%。固然代码审查与测试生成并非全然相同, 不过这个数据起码表明Claude在处理代码相关任务之际的能力是经受得住检验的。
三、技能生成单元测试, 将最枯燥的活, 扔给人工智能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: 质量自查
- 每个用例是否有明确的预期结果？
- 测试命名是否清晰描述场景？
- 是否有冗余的测试用例？
## 输出格式
```typescript
// 以实际框架为准，此处为示例
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先生成测试, 然后再去编写实现代码, 整个流程完全是自动化的。
四、更高级的玩法：多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像维护代码一样
技能可不是写一回就彻底完结的, 按照项目规范的变动来讲, 伴随团队最佳实践的逐步发展, 与之相关的技能文件是需要不断被更新的。
目前我采取的做法是, 将.claude/skills/这个目录添加到Git仓库当中, 以此实现团队共享一套Skill模板, 当有新成员加入时, 拉取下来便能够使用, 要是有改进之处, 提交PR, 这样所有人都可以实现同步。
另外, 建议定期去跑eval测试, 去验证Skill在典型场景之下, 是不是能够稳定输出符合预期的结果, 要不然, 改来改去, 等Skill退化了, 我们自己都不知道。
5.4 关于命名和组织
技艺增多以后, 易于记不住名称。我的体验是依照功能域予以命名: 代码审查, 测试生成, 重构, 安全审计, 文档生成。倘若项目较为复杂, 能够采用命名空间的形式, 比如特性部分/支付测试生成。
另外存在一种通常会有的困惑, 那就是: Skill与CLAUDE.md该如何进行配合呢? 简要来讲, CLAUDE.md属于项目层面的全局配置, Skill是依据需求加以加载的专项能力。这两者能够配合起来使用, 即: 在CLAUDE.md里对项目整体规范予以声明, 在Skill里对具体任务的执行流程作出定义。
结语
机能这一玩意儿, 从实质来讲是助力你使得“怎样开展工作”此一事项固定下来, 一回投入, 能够持续获取益处。
你曾经或许认为, 代码审查以及写单元测试, 是那种必须要去做的、令人苦恼的差事, 而如今, 你能够将它们转变为, 只是一条命令那般容易办到的事, 或者是一个Skill就能完成的事。省下来的那部分时间, 不管去做什么都行——比如说多翻阅几页书籍, 或者多喝上几口咖啡, 还能早点下班回家。
不用去竭力追求一下子就达成写出毫无瑕疵的Skill效果, 而是从一个微小的场景着手, 比如说先搭建起代码审查的Skill, 花费一周时间去体会感受这个方面的变化, 然后再循序渐进地进行完善。毕竟工具最终所要达成的目的, 是能够让你在编写代码的时候更加地舒适一些。
霍格沃兹测试开发学社整理的相关技术资料, 被本文部分内容有所参考到, 这些资料主要涉及软件测试, 自动化测试, 测试开发以及AI测试等方面内容, 并且侧重测试实践, 工具应用以及工程经验整理。
标签： ClaudeSkill React 代码审查 单元测试 自动化
还木有评论哦，快来抢沙发吧~