Skill Engineering
定义
Skill Engineering，是指把开发、数据处理、研究分析等工作中的专业经验、工程规范和操作流程，写成 Agent 可以读取和执行的技能文档的实践方法。它不是单纯把一句 Prompt 写长，而是把“什么时候该用这套方法、具体分几步做、不能越过哪些边界、做完如何检查”明确编码出来，让 Agent 在真实任务中按方法论行事。
在本文语境中，Skill Engineering 的典型载体是 SKILL.md。这类文件通常先用 YAML 声明名称和用途，再用 Markdown 写出触发场景、执行步骤、约束和示例，因此它既是说明书，也是 Agent 的操作手册。
在本文档中的语境
本文把 Skill Engineering 放在 Agent 从“会对话”走向“会协作”的范式转移中理解：2024 至 2025 年很多人关注的是 Prompt Engineering，重点是“怎么跟模型说”；而 Skill Engineering 更接近 Context Engineering，重点转向“该给 Agent 什么工作流、在什么时候给、给多少、按什么流程执行”。
原文明确给出一个区分：Prompt Engineering 管的是“怎么说”，Context Engineering 管的是“说什么、什么时候说、说多少”。Skill Engineering 则把这种上下文与流程设计进一步产品化、文档化，让经验不再停留在人脑或临时对话里，而是沉淀成可安装、可复用、可跨 Agent 运行的技能。
这也是为什么文中把 Skills 视为 Agent 的“操作系统”式能力：裸 Agent 并非没有智能，而是“智商高但没经验”，经常出现一上来就写代码、不先设计、不写测试，或者修了 A 又破坏 B 的情况。Skill Engineering 的作用，就是把工程方法论注入 Agent，让它不再瞎忙活。
核心机制
1. 把经验写成技能文档
Skill Engineering 的第一步，是把原本由资深人员口头传授、靠个人习惯执行的经验，改写成结构化技能文档。文中给出的基本模板包括以下部分：
- YAML 头部：声明
name、description等元信息； - 标题：说明这是哪一类技能；
- 触发条件：写明用户说了什么、处于什么场景时应该激活；
- 执行步骤：按顺序列出任务流程；
- 约束：写清楚不要做什么、边界条件是什么；
- 示例：给出具体输入输出或调用方式。
原文强调，这件事“不用懂复杂编程”，本质上是把专业知识写成 Agent 能看懂的操作手册。这使得个人经验第一次可以被直接执行、放大、复用和传承。
2. 强调触发条件设计
Skill Engineering 不是把所有规则永久塞进系统提示词里，而是强调“何时触发”。触发条件设计是技能是否好用的关键，因为 Agent 只有在合适的任务场景中，才应加载对应技能。
文中的技能模板专门要求写“触发条件”，包括：
- 用户提到哪些关键词时激活；
- 哪类任务场景应该使用；
- 哪些请求虽然相似，但不应触发该技能。
以 Hugging Face 的模型训练技能为例，其 When to use 明确列出三种触发场景：
- 用户想微调模型；
- 用户需要硬件推荐；
- 用户想估算训练成本。
这说明 Skill Engineering 关心的不是抽象地声明“我会训练模型”，而是把适用边界前置到入口处，减少错误调用和上下文浪费。
3. 定义步骤与约束
一个技能能否稳定复现，取决于步骤是否足够明确。原文给出的 Hugging Face 模型训练技能示例，把执行过程拆成了 5 个具体步骤：
- 确认基础模型和训练方法，训练方法包括 SFT、DPO、GRPO；
- 估算硬件需求；
- 生成训练脚本；
- 提交到 HF Jobs；
- 用 Trackio 监控训练。
这种写法体现了 Skill Engineering 的一个核心特征：把复杂任务拆成 Agent 能遵循的顺序流程，而不是只给一句笼统目标。
与此同时，原文模板还要求显式写出“约束”，例如：
- 不要做什么；
- 哪些边界不能越过；
- 哪些条件下需要停下并让人确认；
- 验证和收尾如何完成。
这说明 Skill Engineering 不只负责正向步骤，也负责失败预防、范围控制和结果校验。它要减少 Agent 擅自扩展任务、越权决策或跳过检查的情况。
4. 按需加载，优化上下文利用率
原文指出，虽然模型上下文窗口越来越大，例如 Claude 达到 200K、Gemini 达到 2M，但“够用”不等于“会用”。模型依然会出现 lost-in-the-middle，即中间信息记不住、利用率低的问题。
Skill Engineering 的应对方式是按需加载：
- Agent 启动时只加载技能名称，消耗几十个 token；
- 真正需要时再加载完整指令，消耗几百个 token；
- 相比把所有规则都塞进一次提示中，效率可高约 10 倍。
因此，Skill Engineering 与 Context Engineering 密切相关。它不是单纯整理文档，而是在控制上下文注入的时机和粒度，让 Agent 在有限注意力下仍能使用正确的方法论。
5. 提升稳定性与复用性
原文反复强调，Skills 的价值不在“看起来很聪明”，而在稳定与复用。把方法论固化后，Agent 不会每次都从零猜测做法，而会重复执行一套已知流程。
这种稳定性体现在多个层面：
- 避免一上来就编码，先做需求澄清和方案设计；
- 避免只修当前问题而破坏其它部分；
- 避免不同项目、不同会话中风格和流程完全漂移；
- 避免每次都手工复制提示词和说明文件。
复用性则体现在：
- 同一份技能可跨项目使用；
- 可通过插件系统安装、更新和复用；
- 可被不同 Agent 工具采用；
- 可由团队共享同一套标准流程。
文中给出的强信号是“跨平台”和“标准化”：Claude Code、OpenAI Codex、Gemini CLI、Cursor 都能直接使用统一开放标准下的技能文档，形成“一次编写，多 Agent 运行”的效果。
关键组成
技能文档结构
原文给出的通用结构可以概括为：
---
name: my-custom-skill
description: 一句话描述这个 Skill 做什么，以及什么时候触发
---
# Skill 标题
## 触发条件
- 用户说了什么关键词时激活
- 什么场景下应该使用
## 执行步骤
1. 第一步做什么
2. 第二步做什么
3. 验证和收尾
## 约束
- 不要做什么
- 边界条件
## 示例
具体的输入输出示例
这个结构说明，Skill Engineering 并不神秘，它依赖的是可读、可审、可维护的文档约定。技能不是黑盒权重，而是可被工程团队编辑和评审的显式规范。