别再把经验存在脑子里了：手把手教你给自己造一个"专属专家"

先说个我自己的糗事。

去年我带团队做数据报表，每个月都要跟 AI 重复同一句话：字段怎么对应、异常值怎么标、图表按什么维度拆。改到第七遍的时候我突然想通了——我不是在跟 AI 沟通，我是在做一件人类最不擅长的事：把同一段话，说第八遍。

后来我做了件事：把这段"怎么说"固化成一个文件。从那以后，我只要说"帮我出上月月报"，它就知道该怎么干。

这个东西，就是 Skill。

一、Skill 到底是什么？一句话：它是你写给 AI 的"岗位说明书"

别被名字吓到。Skill 不是代码，不是插件，它本质上就是一个文件夹，里面放一份说明文档，告诉 AI：什么情况下用我、该怎么干、干完给你什么。

打个比方。

• 你每次跟 AI 说的那段话 = 现场教一个新员工干活；
• Skill = 你把这段话写成 SOP 贴在墙上，谁来了都能照着干。

一个运营能写，一个 HR 能写，一个天天做周报的产品经理更能写。它跟"会不会编程"真的没什么关系。

二、第一步：先别急着写文件，先写"什么时候用它"

新手最容易犯的错，是打开编辑器就开始码字。结果写了三千字，AI 该不调用还是不调用。

因为 Skill 能不能被"发现"，几乎全看开头那几行元信息：

markdown复制下载---
name: monthly-report
description: 根据用户提供的表格生成月报。当用户提到月报、月度汇报、本月数据总结时使用。
version: 1.0.0
---

三个要点，记住就行：

• name：小写加短横线，稳定、别乱改，比如 monthly-report；
• description：这是全场最重要的字段——写清楚"什么时候用"，而不是"我有多厉害"。把用户真实会说的话（月报、月度汇报、本月数据）塞进去，命中率会立刻不一样；
• version：第一次写 1.0.0，之后小改就涨最后一位。

我见过太多 Skill 死在 description 上：写成了产品介绍，AI 看完不知道啥时候该掏出来。

三、第二步：认识"最小可用结构"

别一上来就搞复杂。一个能跑起来的 Skill，长这样：

text复制下载monthly-report/
└── SKILL.md

对，就一个文件。不要为了显得专业而拆分目录。

等它真的长大，再按需长出这三样：

text复制下载monthly-report/
├── SKILL.md          # 主文档：关键流程、输入输出、失败怎么办
├── scripts/          # 能自动跑的脚本，优先跑，别让 AI 用嘴干活
├── references/       # 长示例、字段表、专项流程，用到再读
└── assets/           # 模板、素材

四、第三步：搞懂"渐进式披露"，你的 Skill 才算入门

这是整套机制里最聪明的一点：信息分层加载，不是一次性全塞给 AI。

mermaid复制下载命中需要不需要用户说了一句话匹配层: name + description
判断该不该用这个 Skill主文档层: SKILL.md
读取核心流程与资源入口任务需要更多细节?按需资源层: references / scripts / assets
只读当前用得到的那部分直接执行并返回结果命中需要不需要用户说了一句话匹配层: name + description
判断该不该用这个 Skill主文档层: SKILL.md
读取核心流程与资源入口任务需要更多细节?按需资源层: references / scripts / assets
只读当前用得到的那部分直接执行并返回结果

翻译成人话：

• 匹配层：description 决定"要不要用你"；
• 主文档层：SKILL.md 说清"主要怎么干"；
• 按需资源层：那些又长又细的字段表、示例、脚本，放在 references/ 和 scripts/ 里，任务真需要了再去读。

为什么这么设计？因为 AI 的注意力是有成本的。你把三千字的字段表塞进主文档，结果就是核心流程被淹没，AI 开始发挥想象力。

所以我的习惯是：主文档只写"主干"，细节全部外挂，并注明"什么时候去读"。

五、第四步：能写成脚本的，别写成文字

再说一个血泪教训。

我早期写的 Skill，是让 AI"帮我把表格里的 A 列和 B 列合并，然后去掉空行"。听起来没毛病，但每次结果都略有不同——因为每一次它都是"临场发挥"。

后来我把这段逻辑写成了一个脚本，放进 scripts/，主文档里只写一句"遇到合并去重，执行这个脚本"。结果是：每次输出完全一致，而且快了很多。

一句话原则：确定性的事交给脚本，需要判断和表达的事交给 AI。

顺手提两个规范上的坑：

• 脚本里别写死你自己电脑的路径。平台会注入目录变量，包内引用就用相对路径，换台机器照样能跑；
• 脚本写"错怎么办"和写"对怎么办"一样重要。数据缺列、字段为空时该怎么处理，写清楚，AI 才知道要不要来问你。

六、第五步：打包、检查、发给同事

写完别直接丢给别人。跑一遍检查，把结构和语法问题先筛掉：

sh复制下载python3 scripts/check_package.py ./monthly-report --output ./monthly-report-1.0.0.zip

打包出来的 ZIP 按 名字-版本号.zip 命名，里面保留一个稳定的顶层目录。注意：.git、.env、依赖目录、个人配置这些不要打进去。

想分享给同事？把它上传成云端技能，对方就能直接调用。这是我觉得整套机制最有价值的地方——经验第一次变成了可以被复制的东西，而不是跟着人走的东西。

七、三个新手一定会踩的坑

坑 1：一句话写进所有事。 一个 Skill 只解决一类问题。"帮我处理各种文档"这种描述，等于没有描述。

坑 2：description 写成宣传语。 不要写"本 Skill 功能强大、支持多种场景"，要写"当用户提到 XX 时使用"。

坑 3：追求一步到位。 我现在的习惯是先写 20 行，跑通一次，再往里面长东西。第一版就写 500 行的，基本都会弃坑。

八、什么时候不值得写 Skill？

也给个反向建议，省点力气：

• 一年就用一次的事，别写；
• 你自己都说不清标准流程的事，先别写，先把流程理清；
• 纯粹一句话能说清的事，直接说就行。

Skill 的真正价值，是把"重复 + 有标准 + 你已经很熟"的工作固化下来。

写在最后

我做这么多 Skill，最大的收获其实不是省了多少时间，而是被迫把自己的工作方法写清楚了。

写 Skill 的过程，就是逼你把"我大概是这么干的"变成"我具体是这么干的"。这件事本身，比自动化更值钱。

如果你手上正好有一件每周都要重复的活儿，今天就可以试一次：打开编辑器，写一份 20 行的 SKILL.md。

真的，比你想的简单。