作者 姜饼

个人主页：https://modelscope.cn/profile/vcbbrdd

很多人第一次做 Skill，会把成功对话丢给 AI：

“请把对话总结成一个可复用的 Skill。”

AI 自动总结出来的 Skill，很多时候只是一个很长的 Prompt。

它看起来完整，有背景、有步骤、有格式。可下次复用时，很容易漏步骤、混规则、乱输出。

原因不是 AI 不会写文档，而是它不会自动完成 Skill 结构设计。

这篇文章只解决一个基础问题：重复流程怎么拆成真正好用的 Skill。

读完你能判断：哪些写进 SKILL.md，哪些放进 references/，哪些交给 scripts/ 或 AI。

 

先说结论：Skill 不是长 Prompt

长 Prompt 的思路是：

“我把所有要求都告诉你，你每次照着做。”

Skill 的思路不是这样。

Skill 更像一个可复用的工作目录。入口文件告诉 模型 什么时候使用它、先做什么、后做什么；支持文件保存资料、模板、配置和示例；脚本执行稳定、机械、容易出错的动作。

 

可以先用一张表理解区别：

对比项	长 Prompt	Skill
核心形态	一大段指令	有入口、有资料、有脚本的目录
主要依赖	模型每次重新理解	模型按设计好的路径执行
内容组织	背景、规则、模板混在一起	流程、材料、脚本分开放
稳定动作	交给模型临场发挥	交给脚本或明确工具
适合场景	一次性任务	重复流程、固定格式

所以，写 Skill 的重点不是“把上次成功经验写得更详细”，而是先拆 workflow。

为什么自动总结 Skill 容易出问题

一次成功对话里，通常混着流程、偏好、模板、配置、确定性动作和临时上下文。

如果让 AI 自动总结，它很可能把这些东西揉成一篇长说明，然后全部塞进 SKILL.md。

 

1. 它只是在复盘一次对话

自动总结会把“这次怎么成功的”写下来，但不一定能判断“下次怎样稳定复用”。临时文件名、偶然字段、随口偏好，都可能混进 Skill。

2. 它不会主动拆目录责任

一个好 Skill 不是只有 SKILL.md。它可以有支持文件、脚本、模板和配置。但自动总结通常会把所有内容都写到入口文件里，让 大模型 每次重新判断：哪些是步骤，哪些是材料，哪些是模板，哪些是偏好。

3. 它会把确定性动作交给模型

读取文件、解析 XML/JSON、排序、去重、检查字段、合并列表，这些动作不需要模型发挥创造力。交给模型临场做，结果就可能不稳定：这次漏一条，下次排序变了，再下次字段不一致。

4. 它很难维护

长 Prompt 一开始可能能跑。真正的问题出现在后续修改里：输出错了补一句，步骤漏了补一句，格式乱了再补一个例子。最后文件很长，结构却没有变清楚。

标准 Skill 的简单版结构

先不用记太多高级字段。

先记住这个最小结构：

my-skill/
├── SKILL.md
├── references/
└── scripts/

这三个位置各有自己的职责。

位置	应该放什么	不应该放什么
SKILL.md	触发条件、核心流程、边界规则、读取文件和运行脚本的时机	大量模板、长篇背景资料、可脚本化的细节
description	让 大模型 判断何时启用这个 Skill 的触发信号	宣传语、空泛形容词、过宽的能力描述
references/	配置、模板、示例、术语表、偏好、输出契约	每次都必须立即执行的步骤
scripts/	抓取、解析、转换、排序、去重、校验等稳定动作	需要语义判断、价值判断、风格判断的任务
AI	判断价值、归类、总结、改写、解释、处理模糊需求	重复做机械处理、假装执行确定性程序

最容易被忽略的是 description。它不是宣传语。

 

不要写成“这是一个强大的、多功能的、智能化的信息处理 Skill”。这种描述漂亮，但触发信号很弱。

 

更好的写法是明确场景：

“当用户需要读取 RSS 源、筛选值得关注的文章，并按固定格式输出摘要时使用。”

这句话没有夸自己，但 大模型 更容易判断什么时候该用。

 

Skill 案例：错在哪里

假设你有一个 Hermes-rss Skill。(推荐一下我自己的skill已发布到skill中心就叫Hermes-rss)

 

目标很简单：读取一批 RSS 源，筛选值得看的内容，再按固定格式输出。

如果让 AI 自动总结，很容易写成这样的 Prompt：

“请读取这些 RSS 源，解析 XML，去掉重复文章，按发布时间排序，筛选最有价值的内容，然后用我喜欢的格式输出。标题要简短，理由要清楚，最后按技术、产品、商业分类。”

这段话不算错，但它不是一个好 Skill。

 

因为里面混了不同类型的任务：

内容	类型	更适合放哪里
读取 RSS 源	稳定动作	scripts/
解析 XML	稳定动作	scripts/
去重、排序	稳定动作	scripts/
RSS 源列表	配置材料	references/
输出格式	模板材料	references/
分类规则	流程或参考材料	SKILL.md / references/
判断内容价值	语义判断	AI
改写推荐理由	表达任务	AI

RSS 抓取、XML 解析、去重、排序，都是确定性动作。

 

这些事情不需要 大模型 每次重新理解，也不应该让模型临场发挥。

大模型 更适合做后半段：判断哪条值得看、为什么值得看、归到哪类、最后怎么写清楚。

 

所以 Hermes-rss 更合理的拆法是：

Hermes-rss/
├── SKILL.md
├── scripts/
│   └── rss_reader.py
├── references/
│   ├── config.yaml
│   ├── output-format.md
│   └── workflow-contract.md
└── preferences.example.yaml

 

这里的重点不是 RSS 技术，而是责任边界。

scripts/rss_reader.py 负责抓取、解析、去重、排序，并输出结构化结果。

references/config.yaml 放 RSS 源、抓取数量、过滤关键词等配置。

references/output-format.md 放最终输出模板。

references/workflow-contract.md 写脚本输出字段，以及 AI 接下来怎么使用这些字段。

SKILL.md 只描述触发条件、执行顺序、边界规则，以及什么时候读取文件、运行脚本。

这样拆完，Skill 才会从“长 Prompt”变成“可复用 workflow”。

 

把重复流程做成 Skill 的 5 步

如果你手里已经有一个重复流程，不要第一步就让 AI 总结。可以按下面 5 步拆。

 

第一步：写清楚触发场景

先回答一句话：“用户在什么情况下，需要这个 Skill？”这句话会影响 description。触发场景要具体，不要宽泛。

比如：

不要写“用于处理信息”。可以写：“当用户需要从多个 RSS 源中筛选文章并输出阅读摘要时使用。”

触发越清楚，Skill 越不容易乱用。

 

第二步：拆出固定流程

把流程写成顺序动作。例如 Hermes-rss 可以拆成：

1. 读取配置。
2. 运行 RSS 脚本。
3. 获取结构化文章列表。
4. 根据偏好筛选内容。
5. 按模板输出结果。

流程不是越细越好。SKILL.md 里只写 大模型 需要知道的路线。太底层的细节，如果可以脚本化，就不要塞在流程里。

第三步：把材料移到 references

凡是“需要参考，但不适合写在入口文件里”的内容，都可以先放到 references/。

常见材料包括输出模板、风格偏好、配置说明、示例输入和输出、字段说明、分类标准、术语表。

这样入口文件更短，材料也更容易单独维护。

第四步：把稳定动作脚本化

判断一个动作要不要放进 scripts/，可以问三个问题：它是不是有明确规则？是不是每次都应该得到稳定结果？让模型做是不是反而容易出错？

如果答案大多是“是”，就应该考虑脚本化。解析 XML、合并 JSON、排序、去重、生成固定字段，都是脚本的好候选。

不要让模型每次扮演解析器。

第五步：把 AI 留给真正需要判断的部分

AI 的价值不在于替你做机械活，而是处理那些规则没法完全写死的地方。

比如：这篇文章值不值得读，属于技术、产品还是商业，摘要怎么写才清楚，哪些内容对当前读者更重要，输出语气应该更正式还是更轻松。

把这些留给 AI，Skill 才会稳定又灵活。

写完 Skill 后的自查清单

写完以后，不要只问“能不能跑”。可以用这份清单快速检查：

• description 是否明确说明了触发场景？
• SKILL.md 是否只写入口、流程和边界，而不是塞满材料？
• 是否有可以移到 references/ 的模板、示例、配置？
• 是否有可以交给 scripts/ 的稳定动作？
• 是否把 AI 留在了判断、归纳、表达这些环节？
• 流程是否能按“先做什么，后做什么”讲清楚？
• 修改配置时，是否不需要改动主流程？
• 换一次输入后，Skill 是否还能按同样路径执行？

如果这 10 个问题里有一半答不上来，它可能还只是一个长 Prompt。

FAQ：新手最容易困惑的几个问题

1. 我可以只写一个 SKILL.md 吗？

可以。任务很简单时只写 SKILL.md 没问题；一旦出现大量模板、配置、示例、资料、固定处理逻辑，就应该拆出去。判断标准不是文件数量，而是责任是否清楚。

2. references/ 一定叫这个名字吗？

不一定。这里用 references/ 是为了表达“支持材料”的意思。重点不是名字，而是不要把所有材料都塞进入口文件。

3. 什么动作必须写脚本？

不一定“必须”，但稳定、机械、可验证的动作，强烈建议脚本化，比如抓取、解析、排序、去重、格式转换、字段校验。

4. AI 自动总结完全不能用吗？

不是。AI 自动总结可以作为草稿，但不要当成最终 Skill。更好的用法是：先让 AI 回顾流程，再要求它拆成 SKILL.md、支持文件和脚本职责。

5. 怎么判断一个 Skill 已经设计好了？

看它能不能回答四个问题：什么时候触发；先做什么，后做什么；哪些内容需要去支持文件里读；哪些动作必须交给脚本。能回答清楚，基本就不是纯长 Prompt。

最后：换一种提问方式

不要再只问：“请把这次对话总结成一个 Skill。”这句话太容易得到一篇长 Prompt。

更好的问法是：

“请把这个重复流程拆成 SKILL.md、references/ 和 scripts/，并说明每个文件负责什么。”

如果想再进一步，可以补一句：“请标出哪些步骤应该由 AI 判断，哪些步骤应该由脚本稳定执行。”

这才是创建 Skill 时最重要的变化：不是把提示词写长，而是先把 workflow 拆对。