别再把 Skill 写成文档:拆解 Skill Creator 的底层逻辑

拆解 skill-creator 的底层逻辑、方法论与公开案例

很多人第一次接触 Skill，都会先犯一个错：

把 Skill 当成一份说明书。

写个 SKILL.md，塞点说明，补几个触发词，看起来像是“做了一个 Skill”。

但这理解从一开始就歪了。

Skill 不是说明书。不是更长的 Prompt。也不是“把自己会的东西写下来”。

Skill 的本质，是把一次性的聪明，压缩成另一个 Agent 可以稳定调用的能力。

如果再说得更硬一点：

Skill 是多智能体系统里的外置程序化记忆。

它解决的，不是“模型不知道”，而是“模型虽然懂，但每次都要从零推一遍，成本高、波动大、还容易反复踩坑”。

所以，真正的问题不是“怎么把 Skill 写长”，而是：

• • 什么东西值得做成 Skill？
• • 一个好 Skill 到底该怎么设计？
• • 为什么有些 Skill 一看很高级，一跑却很废？

这篇文章，我就把 skill-creator 的底层逻辑拆开讲清楚。

一、Skill 到底在解决什么问题？

先看一个很现实的现象。

很多 Agent 看起来什么都懂：

• • 会写日报
• • 会发文章
• • 会做表格
• • 会查资料
• • 会操作网页

但真到连续执行时，它就开始漂了：

• • 第一次做得不错
• • 第二次换个输入就变形
• • 第三次又忘了前一次踩过的坑
• • 第四次开始把“动作完成”误判成“任务完成”

这不是模型“笨”。而是因为很多任务，本来就不该每次都让模型从零推理。

比如：

• • 写日报有固定结构
• • 网页填报有固定步骤
• • 发公众号有固定排版标准
• • 做视频有固定生产链路
• • 审一个 Skill 有固定检查维度

这些事情如果每次都临场发挥，系统一定漂。

所以 Skill 的作用，就是把这些高价值经验，从一次性对话，变成可以反复调用的稳定能力。

你可以把它理解成三件事：

1. 1. 把流程固定下来
2. 2. 把坑提前写进去
3. 3. 把重复逻辑沉淀成资产

这才是 Skill 真正有价值的地方。

二、Skill Creator 的底层逻辑，不是“教你写文档”

很多人以为 skill-creator 是在教你怎么写一个 SKILL.md。

这只说对了最表面的一层。

它真正做的是三件事：

1. 1. 判断这个任务值不值得做成 Skill
2. 2. 判断什么内容该沉淀成资产
3. 3. 判断这个任务需要多强的护栏

说白了，它不是在教你排版，而是在教你做一件更硬核的事：

把能力工程化。

三、第一步：先判断，这个任务值不值得做成 Skill？

这一步特别重要。因为不是所有任务都值得 Skill 化。

最简单的判断方法，就是问 5 个问题。

1）它是高频任务吗？

高频，才值得沉淀；低频，很多时候现做更划算。

比如：

• • 写日报：如果你每天都写，甚至一天写一次以上，那就是高频
• • 写周报：一周一次，也可能值得做
• • 写一份离职证明：一年都用不上一次，那就没必要专门做 Skill

很多人会把“做过两次”误以为“高频”。这不对。

真正的高频，不是“偶尔重复”，而是：

你已经能预判，未来还会持续重复。

比如“写日报”就是典型高频。你今天写，明天写，下周还写。这种任务一旦不 Skill 化，模型就会在同样的结构上反复浪费算力。

2）它有固定流程吗？

如果一个任务每次都要经历相似步骤，那就值得做 Skill。

比如：

• • 把会议录音整理成纪要：转文字 → 提炼议题 → 提炼结论 → 提炼待办 → 整理格式
• • 发公众号文章：写稿 → 排版 → 配图 → 转 HTML → 进草稿箱
• • 做短视频：主题 → 脚本 → 分镜 → 素材 → 合成

这类任务一眼就能看出来：它不是一次性灵感创作，而是有明确生产链路。

3）它有非通用知识吗？

如果任务里包含模型默认不知道的知识，它更值得做成 Skill。

比如：

• • 公司内部日报格式
• • 某个平台的发文规范
• • 某套 API 字段规则
• • 某个团队自己的命名方式
• • 某个业务系统的特殊流程

举个简单例子，“写日报”这件事本身很常见，模型都会。但如果你的团队要求日报必须包含：

• • 今日完成
• • 遇到问题
• • 明日计划
• • 智识点评
• • 本质 / 因果 / 原则 / 反馈闭环

那这就不是通用知识了。这部分，就值得沉淀成 Skill。

4）它容易翻车吗？

有些任务虽然不复杂，但一旦出错，后果很差。这种任务更应该做 Skill。

比如：

• • 自动发帖
• • 后台填表
• • 批量改文件
• • 发布文章
• • 生成视频并导出

这些任务的共同点是：

• • 顺序不能错
• • 状态很多
• • 假成功概率高
• • 失败有副作用

举个例子，“发布公众号文章”这件事，模型不是不会。但如果你不把流程写清楚，它可能：

• • 文案没问题，但排版没处理
• • 排版没问题，但封面不对
• • 草稿箱没报错，但文章实际没进去
• • 发了，但不是你想要的版本

这种任务的难点，从来不是“懂不懂”，而是稳不稳。

5）它每次重写都很浪费吗？

如果一个任务里，总有一段逻辑被你反复重写，那它就该下沉成 Skill，甚至下沉成脚本。

比如：

• • 每次都要写同一种日报结构
• • 每次都要整理同一种文章排版
• • 每次都要生成同一种分镜 JSON
• • 每次都要走同一种 ffmpeg 合成流程

这些重复动作如果不沉淀，Agent 每次都像在现场重新发明轮子。

四、判断完“值不值得”，下一步是：该沉淀什么？

不是所有东西都该堆在 SKILL.md 里。一个好的 Skill，必须知道什么该放哪里。

1）SKILL.md：放核心流程，不放百科全书

SKILL.md 最适合放的，是：

• • 核心原则
• • 执行步骤
• • 成功标准
• • 失败处理
• • 资源导航

如果你要做一个“写日报”的 Skill，SKILL.md 里应该写的是：

• • 什么时候触发
• • 日报结构是什么
• • 哪些内容必须有
• • 哪些内容不能省
• • 写完后如何自检

而不是在里面写一堆“日报的重要性”。

2）scripts/：放重复执行的硬逻辑

如果某段逻辑重复出现，而且最好别让模型每次现编，那它就该进 scripts/。

比如：

• • 批量重命名文件
• • 生成固定 JSON 结构
• • ffmpeg 合成视频
• • 批量格式转换
• • 结构化输出处理

“AI 漫剧”这个任务里，“把 storyboard 和图片合成为 mp4” 这件事，就很适合放脚本。

3）references/：放知识，不放主流程

有些信息很重要，但不是每次都要读。这种内容最适合放到 references/。

比如：

• • 分镜 schema
• • 平台规则
• • 错误码说明
• • 风格指南
• • 业务字段解释

4）assets/：放拿来用的东西

如果某个文件不是拿来读的，而是拿来直接用的，那它就该进 assets/。

比如：

• • 模板
• • logo
• • 字体
• • 样板 HTML
• • 字幕模板
• • 示例工程

五、真正拉开 Skill 水平差距的，是“自由度控制”

很多人写 Skill，最大的问题是：该写死的地方没写死，不该写死的地方反而写死了。

所以真正要判断的是：

这个任务，应该给 Agent 多大行动空间？

1）高自由度：适合创意型任务

比如：

• • 想选题
• • 做脑暴
• • 提炼洞察

这类任务没有唯一解。Skill 只要给方向，不用把每一步写死。

2）中自由度：适合分析型任务

比如：

• • 写方案
• • 做报告
• • 结构化拆解
• • 翻译文章
• • 写公众号正文

这类任务有套路，但不是强流程。适合写成：

• • 框架
• • 结构
• • 输出格式
• • 关键检查项

3）低自由度：适合高风险执行型任务

比如：

• • 自动发布
• • 视频合成
• • 批量改文件
• • 多步骤网页操作

这类任务必须加硬护栏。

举个例子，“写日报”这个任务，哪怕结构偏一点，也不会出大事故，所以它可以是中自由度。

但“把一组图片按时长合成为视频”这个任务，你如果顺序错了、命名乱了、路径没对上，最后出来的就不是“差一点”，而是直接没片子。

所以这类任务必须低自由度，甚至直接脚本化。

不是所有 Skill 都要更聪明，很多 Skill 的价值只是别乱来。

六、一个好 Skill，到底该怎么判断？

我后来把它压缩成一个很实用的公式：

好 Skill = 触发精准 × 指导有效 × 护栏匹配 × 资源分层 × 结果可验 × 可迭代

1）触发精准

很多人写 Skill，第一步就错在 description。

它以为 description 是简介，其实不是。description 本质上是路由规则。

2）指导有效

正文不是拿来讲概念的，是拿来指导执行的。

3）护栏匹配

任务越脆，护栏越要硬。

4）资源分层

把所有内容都堆进一个 SKILL.md，是最常见的低级错误。

5）结果可验

很多 Skill 最大的问题，不是不会执行，而是不会定义成功。

• • “写了一篇文章”不代表“文章可以发布”
• • “生成了图片”不代表“视频做出来了”
• • “返回了结果”不代表“结果是对的”

6）可迭代

好 Skill 不是一开始设计得多完美，而是它在真实任务中：

• • 暴露问题
• • 记录失败
• • 修正流程
• • 加固护栏
• • 继续复用

七、公开案例：“AI 漫剧 Skill”的 MVP 拆解

假设你要做一个 Skill：用户输入一个主题，或者一段文本，最后输出一个视频。

很多人第一反应会把它理解成：

• • 生图 Skill
• • 写脚本 Skill
• • 做视频 Skill

但这些理解都不够完整。

它真正的本质是：

把文本意图，转译成可播放视频资产的多阶段生产链路。

所以它不能只是某一个点的生成器，而必须像一个“导演”。

它要统一调度这些阶段：

1. 1. 故事规划
2. 2. 分镜生成
3. 3. 视觉素材
4. 4. 音频与字幕
5. 5. 视频合成

如果你只会生图，最后得到的是一堆图，不是视频；如果你只会写脚本，最后得到的是一段文案，不是视频；如果你只会 ffmpeg，最后没有前面的结构化输入，你也拼不出片子。

这就是为什么这个 Skill 最适合设计成“导演型 Skill”。

它负责的不是某一个局部，而是统一调度中间产物。

而且它特别适合说明一个核心原则：中间产物必须落盘。

因为视频链路长，任何一步都可能失败。如果你不把：

• • story plan
• • storyboard
• • 图片
• • concat 文件
• • 最终视频

这些东西逐步落盘，流程一断，你就只能从零再来。

八、如果你也要写 Skill，可以直接按这个顺序来

如果前面讲得太多，你记不住，那就记住这 7 个问题。

以后你写任何 Skill，都先问：

1）它什么时候触发？

2）它要吃什么输入？

3）它要先判断什么状态？

4）它具体怎么执行？

5）它怎么证明成功？

6）它失败后怎么办？

7）哪些内容该下沉？

把重复逻辑下沉到 scripts/，把知识下沉到 references/，把模板和素材下沉到 assets/。

九、最后一句：Skill 的终局，不是文档，而是能力资产

很多人做 AI，喜欢囤 Prompt。但 Prompt 的问题是，它太依赖当次对话。

Skill 不一样。

它一旦写对了，沉淀的是：

• • 你的流程
• • 你的判断
• • 你的踩坑经验
• • 你的成功标准
• • 你的执行护栏

也就是说，你不是在“写一段提示词”。你是在给系统新增一个可被长期调用的能力模块。

所以真正有价值的 Skill，不是那种“看起来懂很多”的 Skill，而是那种：

换另一个 Agent 接手，它也能把活稳定干完。

这才是 Skill Creator 真正在教你的东西。

不是写文档，而是把能力工程化。

结尾给你一个最实用的判断标准

以后你看任何一个 Skill，都别先问它“写得长不长”，先问它 6 件事：

1. 1. 它什么时候触发？
2. 2. 它到底指导了什么？
3. 3. 它的自由度和任务风险匹不匹配？
4. 4. 该下沉的脚本、知识、素材有没有分层？
5. 5. 它怎么证明自己真的成功了？
6. 6. 失败以后，它还能不能继续迭代？

如果这 6 个问题答不清，一个 Skill 再长，也大概率只是“看起来很专业”。

真正有价值的 Skill，不是那种“写得像文档”的 Skill。而是那种：

换另一个 Agent 接手，它也能把活稳定干完。

这才是 skill-creator 真正在教你的东西。

不是写文档，而是把能力工程化。