企业官网建设流程全解析

判断一个 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 skills

Agent Skills Specification

最后
欢迎关注【袋鼠云数栈 UED 团队】~