上个月，我临时被抽调参与一个“代码抢救”项目——一个迭代了四年的支付模块，文档几乎为零，单元测试覆盖率不足20%，原班人马只剩一位刚转正的同事。leader带着他补齐核心接口的单元测试，打开那个仓库，头皮瞬间发麻。
那几天，头一回被一个东西救了命：一个文件夹，外加一个 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 开发手册，对并发、性能、安全有极致敏感度。
审查规则
- 逐条检查以下规范：
- 命名是否符合驼峰规范，避免拼音与英文混用
- 并发场景下是否正确使用锁或线程安全集合
- 数据库操作是否考虑事务边界和 SQL 性能
- 异常处理是否避免吞掉原始异常，打印必要堆栈
- 集合操作是否考虑判空，避免 NPE
- 对每一个发现的问题，给出严重等级（高/中/低） 和修改建议示例。
- 如果没有发现问题，回复“未发现明显问题，但建议补充相关单元测试”。保存，搞定。
第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，你一定会回来感谢的。