作者分享搭建 AI Skill 的实践经验。总结出 3 个原则加单一职责核心；介绍四层标准目录架构，依靠渐进式披露按需加载资源降低开销，并提供自检清单与 Prompt 模板，优化结构比单纯更换模型更能节约 Token。

最近我在深度使用AI写Skill的过程中，踩了一个特别大的坑——我一开始就把”Skill”当成”高级提示词”来写，甚至连它和”Agent”的区别都还没搞清楚。结果呢？一个个很小的任务，Token花费就快赶上一杯星巴克了，而且对话响应还越来越慢。毕竟现实中的我，可不是天天奢侈喝星巴克的人，这就更让我肉疼了。

当时我还一口咬定是模型能力不够，于是一味追求”超高性能”的模型，死活不肯信任那些”经济型flash”版本。直到我到处查资料才发现，原来很多人跟我有过一样的经验，就是从一开始就把”力发歪了”。

其实，根本就不是模型变蠢了，是你的表达并不是AI的记忆和理解方式。

后来，我不断调优和借鉴尝试，总结出来了3个原则 + 1条核心原则，经过实践尝试如果严格按这个原则修改后，不仅能够提升Token的利用率，还能保障skill的高稳定性。并且，在后续的自我修改优化中，我们和大模型的思路都会变得异常清醒，所以在此分享给大家，并希望对大家也有帮助。

1. 写 Skill 前必须知道的三件事

1.1 Skill 不是提示词

提示词解决的是”一次性对话”的问题，Skill解决的是”这一类可复用的单元能力”的问题。就像我们设计师当年做的设计规范一样，它是可以进行反复使用的能力单元，每次调用独立运行，并且不依赖历史积累。

比如，你如果在AI对话框中输入“写一个周报”指令，AI回复你的是根据已有的上下文进行自由发挥的结果。如果你想它成为一个标准的格式输出，就像我们每周在公司写“周报”一样，你就必须在一开始就给它一个明确的格式要求。

记住：Skill.md不是一个Prompt的收纳箱，你塞进去的东西越多，它越找不到你要的东西。精简、准确、清晰、明了，才是最优解的形态。

1.2 Skill 是写给模型看的

SKILL.md写出来是给AI看的，而不是给用户看的。 所以，我们也需要写一个功能说明书，解释这些功能是做什么用的，而是下达一系列目的和步骤清晰的指令。

在文档的阅读过程中，AI的阅读特点是线性扫描式阅读，它是不会进行跳读的。所以，按照 Skill Creator 规范，SKILL.md 的大小建议控制在 300 行以内，并且最好在前 200 行就要让AI明确知道”它要做什么、什么时候做、怎么做、怎么控制、怎么输出…”。

而且，这个200行也是极大的提高对话速度和提高Token利用率的关键点，我在之前的坑中错误的写了1000行，后面发现AI真正阅读之后执行起来，变得又慢又浪费。

如果粗略算一下，1000行的智谱GLM5.2单次加载的一份SKILL.md相对成本约0.35元/次，降低为200行则是0.07元。如果换成Deepseek V4 flash则依次是0.07元/次和0.014元，所以，我们对比看下结论：

• 只换模型不改结构：成本能下降80%；
• 只改结构不换模型：成本也能下降80%；
• 结构+换模型双管齐下：成本可以降到96%；

记住这200行里面有很多根本不是“纲领”，让AI少读一些这些内容，这不是就发现省Token妙招了嘛。

1.3 Skill 不是越复杂越强大

我最开始也踩过这个坑，恨不得把逻辑和场景尽量的穷举，就像当年我们写测试报告一样，生怕有异常问题是我们想不到的。结果实践发现：写的过细，会导致AI反而变得困惑和不知所措了。并且，它还会在阅读完成后向我反馈：是skill和我的内容任务有歧义，这我也很无奈。

然后，我就突然明白了：做复杂的skill不代表它具备复杂解决问题的能力，“责任清晰+目标明确”才是。不要过于人为限制AI的执行，多给它空间，要相信它有足够的能力解决问题。

在反复的实践和尝试中，我知道了“最高效的办法”就是：一个 Skill 只做一件事，只应该有一个核心动作和一个单一职责。

1.4 一核心：Skill 的单一职责

好的skill要遵循“单一职责”的原则，就像是我们日常所在的企业内部一样，其部门结构包含HR、财务、市场、技术等不能职能部门。

所以，如果确实是在一个较复杂的任务中，需要多个不同技能点，那么我们就应该果断将一个skill拆成多个不同的Skill，或者采用“编排结构组织”，比如拆成“ agents/” 让AI按需调用不同的SKILL。

2. 标准架构解剖：四层结构与各自职责

在理解了上面的 3 个原则 + 1 条核心后，让我们一起来看：在我自己的真实案例中 wechat-articles Skill 长什么样，我想通过以下结构图示，你一看就能够非常清晰了：

你可以对照上图，逐个理解为：

• SKILL.md——大脑：只做决策，不干执行

职能：负责“识别意图 → 路由派发 → 释放上下文”，在技能命中即加载；一个最简单的 Skill 可以只有 SKILL.md 一个文件就可以跑起来了。

• agents/——执行者：让专业的人干专业的事

我之前说到的：在真实的任务场景中，很多时候是不可避免的，面对需要处理的复杂的任务工作时，是需要依靠它来负责“拆分复杂子任务，每个文件独立完成一件事”的，这个文件也是按需调用即可；

• references/——知识库：只在需要时才翻开

它的角色是“知识库”，负责“存放评估体系、风格档案、流程规范等领域知识”，这个分类只在AI真实任务需要的时候，才会按需读取的。具体这个技能点我们会在下一篇文章中再做详细分析。

• data/——仓库：自己看的，AI 不主动读

data/的角色是“仓库”，负责“存放模板、图片、示例文件等静态资源”，这个是我们自己建立和维护的本地知识仓库，AI一般是不会主动读取的。

至于行标中出现的“scripts/”，它的功能就是：“ AI 在每次运行时都写同一段代码做同一件事，那这件事就该抽出来”。我这套技能用不到 “scripts/”，所以没加。

我介绍完文件分类后，对照上图，是不是你就已经觉得很简单了？

在理解了AI的阅读方式后，我们会发现AI大体是和我们人类自己做的分类是一样的——用标准的AI文件夹分类方式完成分类后，一个真实任务中的AI是不提前阅读和使用不需要的“信息”的，通过减少阅读量并提高文件夹的精准命中率，这就是我在实践中发现的最省Token的方式了。

3. 省 Token 自检清单：三个问题就够了

不提前加载、不重复加载、不混乱交叉阅读，这就是我们要做的文件目录优化工作。进而在AI调度中达到Token节约的方式，这个听起来很好理解，并且实践中也很简单。同时这种方式也被大家起了一个”牛哄哄“的专业名词，叫”渐进式披露”。

下面给大家一个小小真实有用的Token 利用率自检清单，这也是我自己使用的节省小妙招：

如果这 3 项全部通过，那么你的 Skill 在 Token 利用率上已经超过了 90% 的人。而且，如果你真的不会拆解skill，那么就让 AI 帮你检查这三个问题，反正花一次 TOKEN，会换来后续无数次省 TOKEN的好处。

Tips: 从 Skill Creator的官方规范看，Skill.md上限安全是 500 行，200行～300行都在安全区内。我的建议是：能200行说清楚的，就别写到300行！但若超过500行，就必须要考虑是否将其拆到”references/”或”agent/”中会更优。

🎁 彩蛋：让 AI 帮你生成第一个 Skill

下面直接分享给大家一个SKILL写之前的小prompt，使用方式是：直接复制这段话给 AI：

👇 版本一：经典版参考（3 行，适合小白体验）

请以 Skill-creator 架构师的身份，帮我设计 Skill 的目录结构。
Skill 名称：{你的 skill 名称}
触发场景：当用户说 {什么话} 时触发
核心价值：解决 {什么问题}

👇 版本二：详细版参考（含层级表+判断标准，适合第一次用）

请以 Skill-creator 架构师的身份，帮我设计一个 Skill 的完整目录结构。

## 基础信息
– **Skill 名称**：[待补充]
– **触发场景**：当用户说 [触发关键词/话术] 时触发
– **核心价值**：解决 [具体问题]

## 设计原则

### 1. SKILL.md 的职责边界
SKILL.md 是 Agent 的**唯一初始加载内容**，应保持精简。请据此判断：
– **应放 SKILL.md**：流程编排、路由决策、任务拆解逻辑、关键检查点
– **不应放 SKILL.md**（应放 references/）：详细的领域知识、API 文档、评估标准、示
库、历史数据、占位模板
– **判断标准**：流程逻辑（放正文） vs 被引用的知识（放 references/）

### 2. 子 Agent 的拆分标准
当满足以下任一条件时，应考虑拆分为独立子 Agent：
– **逻辑独立**：可脱离主流程单独执行并返回结果
– **状态隔离**：有自己的状态记忆或上下文管理需求
– **可复用**：可能被其他 Skill 调用
– **行数超标**：当前 SKILL.md 超过 200 行，且该功能块是独立逻辑单元

## 目录层级设计

请按以下层级设计，并给出每层的职责说明和加载策略：

| 层级 | 职责 | 加载策略 |
|——|——|———|
| **SKILL.md** | 任务编排、路由决策、调用子 Agent | 技能触发时加载，<300 行 |
| **agents/** | 可独立执行的子任务 | 仅主流程派发时加载 |
| **references/** | 参考资料、评估体系、外部知识 | 仅主流程显式引用时加载 |
| **scripts/** | 可复用的确定性脚本（Python/Bash） | 按需执行，不加载进上下文 |

## 输出要求
1. 完整的目录树结构
2. 每个目录/文件的职责说明
3. 关键文件的示例内容（特别是 SKILL.md 的框架）
4. 设计决策的依据（为什么这样拆分，为什么某些内容放某个位置）
5. 使用方式（Agent 如何调用这个 Skill 的各层资源）

如果你跟我一样，写了一千行 SKILL.md 并且还在追求”超高性能”的模型，倒不如先把这 100 行的结构目录调清楚。因为省 Token 是次要的，把我们的“脑子”想清楚才是主要的。