以下内容摘录自：用Skill将能力固化为可复用流程

知道 Skill 的结构是一回事，写出真正好用的 Skill 是另一回事。一个结构完整但指令含糊的 Skill，和一个精心打磨的 Skill，效果差距巨大——前者可能让 Agent 反复犯同样的错，后者能让 Agent 稳定地交付高质量结果。

写好一个 Skill，本质上要走完五步：判断值不值得做 → 提取该写什么 → 写好指令 → 配好工具 → 验证和迭代。每一步解决一个不同的问题，跳过任何一步都会在后面埋雷。

第一步：判断值不值得做

封装 Skill 有成本——设计结构、编写指令、测试迭代。如果任务本身很简单或只执行一次，这些成本就是浪费。在动手之前，先问自己三个问题：

这个任务有”专家直觉”吗？

“寻找那些’专家依靠直觉能做对，但新手经常漏掉边界条件’的环节。”

课程审核就是一个典型例子。资深课程设计师一眼就能看出”这个代码示例对初学者太复杂了”，但新手往往意识不到。这种”隐性知识”正是 Skill 最应该捕获的内容。

这个任务足够复杂吗？

“能够在 3 步以内通过 GUI 完成的操作，严禁封装为 Skill。”

如果一个任务足够简单（比如”把这段文字翻译成英文”），直接用自然语言描述就够了，没必要大费周章地创建 Skill。为了用 AI 而用 AI，是工程实践中最常见的误区之一。

这个任务会反复执行吗？

Skill 的价值在于复用。如果一个任务只会执行一次，封装它的投入产出比就很低。但如果你的团队每周都要审核 20 门课程，那么花一天时间打磨一个?CourseReviewSkill?就非常值得。

三个问题都回答”是”，才值得封装。这个判断能帮你避免最常见的浪费——不是 Skill 写得不好，而是根本不该写。

第二步：提取该写什么

确定要写之后，很多人会直接列操作步骤——“第一步做X，第二步做Y”。但这样的 Skill 和一段普通 Prompt 没什么区别。

真正有价值的内容是那些专家知道但很难说清楚的隐性知识。你需要做的核心工作是将它们显性化：

• 提取专家的决策树而非单纯的步骤——“在什么条件下选择方案A，什么条件下选择方案B”
• 注入反模式检查——“哪些坑绝对不能踩”

一个只告诉 Agent “做什么”的 Skill 是不完整的。一个优秀的 Skill 还会告诉 Agent “不要做什么”以及”为什么”。

提取出知识后，怎么呈现给模型？有两种高效的方式：

Template 模式：标准化输出格式

如果你的任务需要标准化的输出（审核报告、变更日志、测试总结等），直接在 Skill 中提供输出模板。模板比文字描述更精确，模型不需要”猜”你想要什么格式。

第三步：写好指令

有了内容，接下来是怎么写。上下文窗口是有限的公共资源——你的 Skill 要和 System Prompt、对话历史、其他 Skill 的元数据共享这个空间。写得太多，模型反而抓不住重点；写得太死，灵活的任务会被束缚；写得太长，单个文件装不下。这三个问题分别对应三条原则。

简洁：每句话都要值得它的 token 成本

在写下每一段文字之前，问自己：模型真的需要这个解释吗？我能假设模型已经知道这个吗？

自由度匹配：约束程度要匹配任务风险

不同的任务需要不同程度的指令精确度。一个数据库迁移脚本必须严格遵循每一步，一个代码审查则可以让 Agent 自由发挥。如果你在所有地方都用同样的约束程度，要么该严格的地方太松（出事故），要么该灵活的地方太死（限制了模型的能力）。

把模型想象成一个探索路径的机器人。窄桥 + 悬崖（数据库迁移）：只有一条安全的路，你需要提供精确的护栏（低自由度）。开阔田野（代码审查）：多条路径都能到达目的地，你只需给出大致方向（高自由度）。

渐进式披露：主文件保持精简，详情按需加载

当 Skill 包含大量参考资料时，不要把所有内容都塞进 SKILL.md——在 1.3.1 中我们已经看到了这个原则。这里补充一个重要的实践细节：保持扁平结构，避免深层嵌套。

为什么？当引用层级过深时，模型可能只用 head -100 预览中间文件而非完整读取，导致关键信息在传递链中丢失。扁平结构确保模型只需”一步”就能访问任何所需资源。

第四步：配好工具

1.3.2 介绍了为什么需要脚本——让模型不用”猜”。但脚本的输出质量直接决定了 Agent 能否用好它。一个输出?"Error: exit code 1"?的脚本和一个输出结构化诊断信息的脚本，对 Agent 来说是天壤之别。

先来看工作流设计，再看工具本身怎么写。

设计可追踪的工作流

复杂任务需要清晰的工作流。为 Agent 提供一个可追踪的 Checklist，能显著提高执行的可靠性。

第五步：验证和迭代

Skill 写完了，怎么知道它好不好？靠自己读一遍是不够的——你觉得写得清楚，模型可能理解完全不同。最有效的方式是与 AI 协作开发。

“双 Agent”模式

• Agent A（设计者）：帮你设计和精炼 Skill 的指令
• Agent B（使用者）：在真实任务中测试 Skill

开发流程分三个阶段：

阶段一：建立评测基线。?先用 Agent A 完成一次真实任务（不用任何 Skill）。记录它在哪些地方犯了错、哪些地方需要你反复纠正，挑出 3 个最典型的失败场景作为评测用例。先有评测，再写 Skill——否则后续优化全靠“感觉”。

阶段二：提取 Skill。?任务完成后，让 Agent A 帮你总结：“哪些信息是你反复提供的？” 将这些信息整理成 Skill 的初稿。

阶段三：测试迭代。?让 Agent B（一个全新的会话）加载这个 Skill，执行阶段一中的评测用例。对比输出：改进了哪些？还有哪些没解决？把观察带回 Agent A 改进 Skill，重复测试，直到 Agent B 能稳定通过所有评测用例。

这种“评测-改进-验证”循环是打磨 Skill 最有效的方式。评测用例贯穿整个开发过程，为每一轮迭代提供客观的衡量标准。

参考资料

以上内容摘录自：用Skill将能力固化为可复用流程

如本文对您有用，捐赠和留言 将是对我最好的支持~
如愿意，请向朋友推荐本站，谢谢。

尊重他人劳动成果。转载请务必附上原文链接，我将感激不尽。

与《如何写出高质量的 Skill》相关的博文：