别再让 AI 自动总结 Skill 了！

作者 姜饼

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

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

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

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

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

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

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

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

先说结论：Skill 不是长 Prompt

长 Prompt 的思路是：

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

Skill 的思路不是这样。

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/

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

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

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

更好的写法是明确场景：

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

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

Skill 案例：错在哪里

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

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

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

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

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

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

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 拆对。