目录
- Agent Skill 的基本定义与抽象模型
- Skill 与提示词的工程边界
- 最小可用 Skill 的结构设计
- 按需加载机制与 Token 控制策略
- 复杂 Skill 的模块化拆分方式
- Scripts 与 Assets：从“生成”到“执行”
- Skill 的三层加载结构总结
- Skill 创建流程的工程化抽象
- 高频独家 Skill 的长期价值
1. Agent Skills 的基本定义与抽象模型
从工程视角看，Agent Skills 并不是一个“新概念”，而是对稳定能力单元的一次明确建模。
一个成熟的人类技能，通常由四部分组成：
- 明确的流程
- 可复用的方法或配方
- 可调用的工具
- 固定或半固定的材料
Agent Skills 对应的工程抽象非常直接：
- skill.md：定义流程与决策规则
- references/：外部规范与参考资料
- scripts/：可执行工具
- assets/：不可变资源
当这些内容以固定结构组织在一个目录中时，就构成了一个完整的 Skill。
从本质上讲，Skill 是一种能力封装方式，而不是一次性指令。
2. Skill 与提示词的工程边界
从效果层面看，Skill 依然依赖提示词； 但从工程层面看，两者并不在同一个层级。
提示词的典型问题包括：
- 无法复用
- 难以维护
- 信息相互干扰
- Token 成本不可控
Skill 的引入，本质上是把提示词提升为工程对象：
- 具备名称与触发条件
- 具备固定结构
- 具备演进空间
- 可被系统按需加载
这一步，是从“会用模型”迈向“构建能力体系”的分水岭。
3. 最小可用 Skill 的结构设计
一个 Skill 并不需要一开始就很复杂。
从实践经验来看，一个最小可用 Skill（MVP）只需要一个文件。
3.1 基本目录结构
example-skill/ └─ skill.md
3.2 skill.md 的职责划分
skill.md 通常包含两类信息：
元信息（Meta）
- Skill 名称
- 使用场景
- 触发条件
该部分始终加载，作用类似能力目录。
指令定义（Instructions）
- 操作流程
- 输入输出约束
- 风格与规则
只有在系统判断需要使用该 Skill 时，才会加载这一部分。
4. 按需加载机制与 Token 控制策略
Skill 相比普通提示词的核心优势，在于加载策略。
4.1 元信息的常驻加载
系统始终可见 Skill 的元信息，但不暴露细节。这使模型能够在多个 Skill 之间做选择，而不会被具体指令干扰。
4.2 指令的条件加载
只有当任务匹配某个 Skill 时，完整指令才会进入上下文。
这种设计带来的直接收益包括：
- Token 使用可控
- 多 Skill 并存不互相污染
- 回答路径更聚焦
5. 复杂 Skill 的模块化拆分方式
当 Skill 涉及多种复杂规则时，将所有内容堆叠在一个文件中并不可行。
典型问题包括：
- 文件过长
- 规则互相干扰
- 无法精确匹配场景
5.1 references 的设计目的
references 目录用于存放按场景拆分的规范文件：
references/ ├─ poster.md ├─ banner.md ├─ menu.md
skill.md 中只保留索引逻辑，例如：
当任务涉及具体物料类型时，读取对应 reference 文件。
这样可以确保：
- 只加载必要信息
- 复杂度与任务强度匹配
- 输出更稳定、更精准
6. Scripts 与 Assets：从“生成”到“执行”
6.1 Scripts：让 Skill 具备执行能力
scripts 目录中存放的是可执行脚本，例如：
- 生图 API 调用
- 数据转换
- 外部系统交互
关键工程特性在于：
脚本不会被模型读取，仅在满足条件时执行，不占用上下文 Token。
在 skill.md 中，只需要定义触发条件与参数映射规则。
6.2 Assets：保证结果稳定性的关键
对于 Logo、固定图片等不可变资源，最佳做法是放入 assets 目录：
assets/ └─ logo.png
并在 Skill 指令中明确其使用方式。
这一步的工程意义在于：用确定性资源替代概率性生成。
7. Skill 的三层加载结构总结
从系统角度看，一个完整 Skill 由三层组成：
- 元信息层
- 始终加载
- 用于能力发现
- 指令层
- 条件加载
- 定义执行逻辑
- 资源层
- references / scripts / assets
- 按需读取或执行
- 脚本仅执行，不进上下文
这是一种典型的渐进式披露（Progressive Disclosure）设计模式。
8. Skill 创建流程的工程化抽象
随着 Skill 数量增加，手动维护其结构与规范会迅速成为负担。
一种更合理的工程做法是：将 Skill 的定义过程本身工具化。
8.1 Skill Authoring 工具的职责
该类工具并不执行任务，而是：
- 通过交互式方式收集需求
- 强制补齐结构约束
- 自动生成合规的 Skill 文件
用户只需描述需求，其余结构化工作由工具完成。
8.2 工程价值
从工程角度看，这是把经验约束前置到工具层，而不是分散到每个使用者身上。
9. 高频独家 Skill 的长期价值
Skill 的价值不在数量，而在使用频率与稳定性。
最值得长期维护的 Skill，通常具备以下特征：
- 高频使用
- 有明确质量标准
- 方法已被反复验证
例如：
- 周报生成
- 备课流程
- 合同审查
- 固定风格写作
- 内容配图流程
当这些能力被封装为 Skill 后，AI 才真正成为一个稳定执行者，而不是一次性助手。
Skill 是能力的“工程边界”
当能力可以被文件化、结构化、加载控制时，它就不再依赖个人记忆或即时灵感。
Skill 的本质，不是“让 AI 更聪明”， 而是让经验具备工程形态。
