上个月，我被临时抽调去支援一个“代码抢救”项目——一个迭代了四年的支付模块，文档约等于零，单元测试覆盖率不到 20%，原班人马跑得就剩一个刚转正的哥们儿。leader 让我带着他把核心接口的单元测试补齐，我一打开那个 repo，头皮就麻了。

就在那几天，我头一回被一个东西救了命：一个文件夹，加一个 Markdown 文件。我把项目的代码规范、历史踩坑记录、需要重点测试的边界条件全塞进去，然后丢给 AI 助手，它突然就“懂了”这个项目，生成出来的测试用例质量吊打我手写了三天的版本。

那个东西，就叫 Skill。今天这篇，我手把手带你从零写出你自己的第一个 Skill，不需要写一行代码，5分钟搞定。

一、Skill 到底是什么？你先别想复杂了
在很多 AI 工具里，Skill 本质上就是一个“能力封装包”。你平时跟 AI 对话，每次都得交代背景：“我是后端开发”“用 Java 17”“项目遵循阿里巴巴规范”“这个模块是支付回调，表结构长这样”……一套话重复无数遍。

Skill 干的事特别朴素：把这堆上下文、规范、知识、提示词，打包成一个文件夹，以后要用的时候，一键加载。 它就像你给一个聪明绝顶但失忆的实习生，配了一本随身携带的《项目生存手册》。

你只需要做到两点：新建一个文件夹，里面放一个 SKILL.md 文件。完事儿。

二、动手：5分钟，做出你人生第一个 Skill
别急着怀疑，先跟我走一遍流程。我用的是 Claude 的 Skills 功能（如果你用其他平台，思路完全通用，核心就是这个文件结构）。

第1步：新建文件夹
在你的电脑上随便找个地方，建一个文件夹，名字就叫 my-first-skill。名字无所谓，别带中文空格就行。

第2步：创建 SKILL.md
在文件夹里新建一个 Markdown 文件，文件名必须叫 SKILL.md，大小写也别错。

打开 SKILL.md，粘贴下面这段内容：

name: code-review-assistant
description: 根据团队 Java 编码规范，对提交的代码片段进行深度审查，输出改进建议和风险点。

角色定义

你是一名资深 Java 后端工程师，精通代码审查，熟悉阿里巴巴 Java 开发手册，对并发、性能、安全有极致敏感度。

审查规则

1. 逐条检查以下规范：
   • 命名是否符合驼峰规范，避免拼音与英文混用
   • 并发场景下是否正确使用锁或线程安全集合
   • 数据库操作是否考虑事务边界和 SQL 性能
   • 异常处理是否避免吞掉原始异常，打印必要堆栈
   • 集合操作是否考虑判空，避免 NPE
2. 对每一个发现的问题，给出严重等级（高/中/低）和修改建议示例。
3. 如果没有发现问题，回复“未发现明显问题，但建议补充相关单元测试”。
   保存，搞定。

第3步：丢进 Claude 试试
在 Claude 的聊天界面里，点输入框左侧那个小回形针或者加号，选择 “添加技能” 或者直接把这个文件夹拖进去。不同版本的入口可能叫“Upload Skill”或“Load folder as skill”，你找到就行。

加载成功后，直接发一段你最近写的代码过去，然后看它怎么审。我上周随手喂了一段自己写的 Redis 分布式锁释放逻辑，它立刻指出 finally 块里没有判断锁是否属于当前线程就直接释放，还给了带 Redisson 的对比写法——比我同事 review 还狠。

三、光有指令还不够？把资料扔进去
上面那个只是开胃菜。Skill 真正厉害的地方在于：它不仅能装提示词，还能把整个知识库带在身上。

回到我开头说的那个支付项目，我是这么操作的：

在 my-first-skill 文件夹里，除了 SKILL.md，我额外建了一个子文件夹叫 docs，里面塞了三样东西：

payment_flow.md —— 我从代码里扒出来的支付状态流转图
db_schema.sql —— 核心表结构
known_issues.md —— 近半年线上故障复盘记录
然后修改 SKILL.md，在里面加上一句：

项目背景参考

请在分析本项目的任何代码前，务必阅读 docs/ 目录下的所有文件，作为上下文基础。
再次加载这个 Skill，我让它“根据退款接口代码和已知问题，生成 P0 级的回归测试用例”。它把半年前因为状态机并发导致重复退款的那个坑都覆盖进去了，那一刻我真觉得这哥们儿比我还懂这烂摊子。

本质就是：你喂给它的私有资料越多，它在这个狭窄领域里的表现就越接近一个贴着工牌的内部专家。

四、一线老兵的几个私藏心法
这东西上手实在太简单，但想用好，有几个点我跟周围同事反复踩坑后才琢磨明白：

① 提示词别写“正确的废话”
见过很多人把 Skill 提示词写成高考议论文，通篇“你是一个专业的、细心的、负责任的工程师”。这些形容词对 AI 来说约等于噪音。直接下命令、给规则、举反例。 比如“禁止吞掉原始异常，必须用 log.error 打印完整堆栈”，比“请你注意异常处理”有效一百倍。

② SKILL.md 的 YAML 头一定要写对
name 和 description 不是给自己看的，是给 AI 调度器看的。描述写得越精准，AI 才知道什么时候该自动调用你这个技能。比如 description 写“审查代码”，那它只会在代码审查场景被激活。别写个“帮我干活”这种泛词，否则你的 Skill 会被 AI 拿去在写诗的时候也尝试加载，闹笑话。

③ 把 Skill 当成代码来管理
我现在所有项目都有一个 .skills 目录，里面放几个不同的 Skill 文件夹，然后用 Git 管起来。团队新人入职，拉一份仓库，把技能文件夹一加载，直接具备老员工的八成功力。跨项目复用也简单，把文件夹复制粘贴过去就行，接口统一就是 SKILL.md。

④ 调试 Skill 的唯一真理：迭代
没有一个 Skill 是一次写对的。我的做法是，先跑 10 个真实场景的输出，把不符合预期的地方截图记下来，回到 SKILL.md 里补规则、加禁止项。一般改过三四轮之后，这个 Skill 才会进入“有点靠谱”的阶段。

五、别让你的知识烂在脑子里
写完第一个 Skill 那天晚上，我发了个朋友圈，配图就是那个文件夹截图，文案是：“从业十年，头一回能把脑子里的经验，用一个文件夹完整地甩给 AI。”

后台好几个老同事私信问我怎么搞，我把文件夹直接打包发过去，他们加载完就能用。这种传递方式，比写 Wiki、做培训痛快得多——毕竟写 SKILL.md 只需要你会用 Markdown，而分享一个可执行的“能力单元”，只需要复制一个文件夹。

你不需要什么工程化平台，不需要学 LangChain，不需要申请服务器资源。你面前这台电脑，建个文件夹，写个 Markdown，就拥有了你的第一个 AI 技能。

别光看，现在就试试。从你最常跟 AI 抱怨的那句话开始——把那句“你每次都记不住我们用 Java 8 和 MyBatis”写进 SKILL.md，你会回来谢我的。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。