判断一个 Skill 有没有价值不是看它写得多完整而是看它有没有改变 Agent 的行为。可以看五个指标触发准确率用户自然描述任务时它是否会被正确选中误触发率不该用它的时候它是否乱入执行稳定性同类任务重复执行步骤是否一致验证闭环它是否要求 Agent 做必要检查维护成本新增边界时是补充几句规则还是要重写整份文档还可以准备一组测试提示词帮我从 Notion 生成这周周报把今天 GitLab 的 fix/feat/hotfix 提交同步到 Notion帮我 review 这个 GitLab MR为这个 Bug 生成禅道修复备注观察它们是否命中对应 Skill是否读取该读的 reference是否运行该运行的脚本是否给出符合团队习惯的输出。如果一个 Skill 只有在用户精确喊出名字时才工作它还只是一个手册。如果用户自然描述需求时它也能稳定接管流程它才真正进入了 Agent 的工作系统。一个延伸问题怎么测试 Skill 的稳定性 由于 LLM 行为有随机性同一个 Skill 多次执行可能得到不同结果。建议对输出不做逐字一致的断言而是做关键动作校验——比如是否读了 references/ 下的文件、是否运行了 scripts/ 中的脚本、最终输出是否包含预期结构。这样既允许 LLM 的自然表达又保证了流程的不变性。一个好 Skill 最值钱的是坑点清单很多人写 Skill 时会把精力放在背景介绍上。但真正值钱的部分往往是坑点清单。执行顺序哪些步骤必须先做不能颠倒哪些操作应该脚本化避免 Agent 每次临场重写判断与边界哪些工具看起来能用其实会产出错误结果哪些场景必须先问用户哪些可以直接合理假设哪些输出必须验证验证失败时怎么降级资源组织哪些信息应该放正文哪些应该放 references/哪些动作需要审批哪些文件不能动按维度分组后每个作者可以更快定位自己缺哪类坑点而不是面对一排问题无从下手。Skill 的价值不是把人类知道的全部东西铺满而是把任务中最容易翻车的地方提前标红。比如生成图片这个任务难点不只是写 prompt而是知道什么时候应该用图片生成工具什么时候该直接画 SVG透明背景什么时候可以色键抠图什么时候需要提醒用户走原生透明路径。这样的判断才是 Skill 的含金量。会写 Skill就是会把经验产品化我会用这个公式判断一个 Skill 是否值得存在好 Skill 清晰触发 精简正文 按需引用 确定性脚本 坑点前置 可验证输出单次提示词像口头交代AGENTS.md 像项目规矩MCP 像外部工具接口Hook 像生命周期拦截器而 Skill 像可复用的任务方法论。它把触发条件、执行步骤、参考材料、脚本工具和验证标准打包在一起让经验从这次对了变成下次也能对。所以走进 Skill 的内部机制真正要看的不是那一份 Markdown而是它背后的触发路由、渐进加载、资源组织、运行时渲染和团队分发路径。会写 Skill不只是会写文档而是会把经验做成系统。参考资料Claude Code Docs: Extend Claude with skillsAgent Skills Specification最后欢迎关注【袋鼠云数栈 UED 团队】~