Aakash Gupta 从 2023 年 10 月开始研究 Skills，最近对 25 个核心 Skill 跑了 75 次测试，总结出了 7 条编写高质量 Skill 的定律。
为什么 Skill 是 2026 年的 Meta
2023-2026 的 meta 是 Prompt Library。2026 的 meta 是 Skill Library。
Prompt 的问题：你得记住它存在、找到对的、粘贴、下次会话重新粘贴、改进后旧版本散落在三个文件夹、队友用的可能是六个编辑之前的漂移版本。
Skill 是一次安装的可复用工作流。上下文匹配时自动加载，不需要你主动调用。它知道先读哪些文件、输出该长什么样、什么不该碰。标准编码一次，跨会话、跨队友生效。
Skill 对 Prompt 的三局完胜
vs 一句话用户 — 用户打 "create tickets from this PRD"，Claude 每次现场发明模板、格式、细节级别，输出每轮不同。Skill 用户打同样的话，Skill 强制执行格式、验收标准结构、工作量估算、依赖关系图。
vs 巨型 Prompt 用户 — 每次会话顶部粘贴 800 字。确实编码了真实标准，但工作开始前先烧 token、每次重贴都有微小漂移、无法作为工作流交给队友。Skill 用户只在相关时加载标准、从不重贴、可作为文件夹分享。
vs 结构化 Prompt 库用户 — 按用例整理的优秀 Prompt 文件夹。仍然在三件事上输给 Skill：Prompt 用户得记得调用哪个，Skill 用户靠描述匹配自动加载；Prompt 用户跨工具手动版本管理，Skill 用户单一事实来源；Prompt 库从 Claude 切到 Cursor 就断裂，Skill 库可移植。
Skill 用户全胜，因为 Skill 把工作从人转移到系统。你不再是路由器、版本控制器、标准执行者。
什么时候用 Skill，什么时候留作 Prompt
用 Skill：会粘贴两次以上的指令、有不可协商的标准（输出格式、审批门、事实来源文件）、Claude 需要先读上下文再生成、想让队友无差别运行而不需要录 Loom 视频解释。
留作 Prompt：一次性问题、Prompt 本身就是工作的探索性对话、Claude 能直接回答的简单查询、每次形状都不同的任务。
测试标准：如果你会粘贴同样的指令两次，它就该是个 Skill。
跨工具部署
Skill 架构正在 Claude、Cursor、Copilot、Codex 之间收敛。每个 Skill 都应该部署到所有你使用的工具上。
Claude Code — Settings → Customize → Skills，上传 ZIP，toggle 开启。自然语言输入或 /skill-name 强制加载。
Claude Desktop — Personal Skill 放在 ~/.claude/skills/skill-name/，每个项目生效。Project Skill 放在仓库的 .claude/skills/skill-name/，提交后克隆仓库的人自动获得。这是唯一 Skill 随代码库一起交付的表面。
Claude Web — 文档密集型工作的最高杠杆点。Skill 读的是你的真实文件，不是粘贴片段。打两个字，输出引用真实上下文。一篇太长无法粘贴的文档，变成两个字的命令。
七定律
Law 1：Description 就是路由器
Claude 在会话开始时扫描每个已安装 Skill 的描述。完整指令、输出格式，在 Claude 判定 Skill 相关之前一概不加载。这个判定完全基于描述。
Gupta 测试了一个食谱规划 Skill，描述只有 37 个字符："Suggest recipes from what's in fridge." 10 个应该触发它的 Prompt，大多数没命中。
好的描述：第三人称、首句说明 Skill 做什么以及何时使用、包含真实用户会打的触发短语、至少命名一条清晰边界。
Law 2：排除要带指针
大多数 Skill 作者写什么时候用，几乎没人写什么时候不用。当你排除某事却不给替代方案，Claude 仍然必须选一个。它加载最接近的匹配项，输出格式错误、Skill 错误、但自信满满地交付。
修复在描述里，不在正文中。正文中排除时，错误的 Skill 已经加载了。描述中排除时，它在路由阶段就生效。
"Do NOT use for X" 只是建议。"Do NOT use for X, use /Y instead" 才能正确路由。
Law 3：正文用祈使句
正文每行都应该是祈使语气。"Read the target file. Check for X. Output as Y." 而不是 "Could you take a look and maybe check for any issues?"
Gupta 测试的 Code Reviewer Skill 开头是："Hey! When the user asks for a code review, it would be great if you could go through their diff carefully..." Claude 精确匹配了这种能量——输出友好、模糊、结构像体贴同事的留言，没有严重级别评分，没有文件和行号引用。
改成命令："Check the diff. Flag every issue with severity (Critical/High/Medium/Low). Reference file path and line number for each. Do not soften." 同一个 Claude，同一个 diff，完全不同的输出。
Law 4：Read-First 表格
25 个 Skill 中最大的单项改进，不是新规则，是把一句模糊的话替换成一张具体的表。
Debugger Skill 没有 read-first 步骤，交给它一个错误，得到听起来很专业的通用分析：可能根因、建议修复。全部来自训练数据，没有一个字触碰实际代码库、错误日志或最近提交。
修复是三列表格：Source、Path、What to extract。这张表告诉 Claude 哪个目录、哪些搜索词、提取什么。"Check the relevant files" 是标签；表格是指令。
Law 5：输出模板 + 完整示例
Daily-plan Skill 连续三天早上用同样的 Prompt 运行。周一：按时间块的项目符号列表。周二：叙事段落。周三：带标题的编号列表。
同一个 Skill，同一个 Prompt，三种不同结构。指令很清楚，但没有模板和示例。Claude 每轮都发明新格式，因为从未被展示过「完成」长什么样。
修复：指定精确结构的输出模板，加上展示完整输出的 worked example。规则描述目标，示例展示击中目标的样子。
Law 6：示例打败规则
Commit Message Skill 有 12 条规则。全面、清晰。但连续三轮同样输入，输出不一致。
"Concise" 每轮意思不同。没有具体的东西可供模式匹配。加了两个 worked input/output 示例后，三轮输出结构完全一致。Claude 是优秀的模式匹配器。给它目标，而不是描述目标长什么样的文字。
如果你写的规则比示例多，翻转这个比例。
Law 7：关键规则置顶
Skill 加载后，每一行都在和对话历史争夺 Claude 的注意力。Skill 越长，底部的指令被忽略的概率越高。
724 行的 Fitness Coaching Skill，训练哲学、伤病史、减量协议，内容确实好。但第 700 行 buried 着安全规则——它们从未触发。
把关键规则移到最顶部，在一切内容之前。把背景内容移到 references 文件夹。Claude 需要时才会去读。
审计清单
Description：
- 超过 100 个字符？
- 包含 3 个以上真实用户会打的短语？
- 第三人称？
- 首句 250 字符内说明做什么和何时使用？
- 至少一条 "Do not use for X, use /Y" 边界？
Body：
- 指令使用祈使动词？
- 输出格式用模板或完整示例指定？
- 有 Source / Path / What to extract 的 read-first 表格？
- 关键规则在前 100 行？
- 少于 500 行？
升级现有 Skill
把这个 Prompt 发给加载了 Skill 的聊天：
Use the advice in this article: [粘贴本文] to improve the skill [名称].
更硬的版本：释放 10 个子 Agent 攻击你的 Skill，以 hard grader 评分输出，基于失败点在三轮中重写 Skill。Gupta 用这个方法跑遍了库里每个 Skill， surfaced 出手动永远抓不到的失败模式。