如何写好一个Skill：从原理到实践的专业博客写作指南

不是你写不好，是没掌握“教AI做事”的正确方法。

引言

你有没有过这样的经历：每次让AI帮你写周报、审代码、或者把一篇技术文章转化成社交媒体文案，都要花上十几分钟重新解释一遍规则——语气要什么样、格式怎么定、哪些坑要避开？一次两次还能忍，但当你每周都要重复三遍的时候，这笔时间账就算不过来了。

2025年12月，Anthropic宣布将Agent Skills作为开放标准发布，随后迅速被Microsoft、GitHub、Cursor、VS Code等主流平台采用，GitHub上的Skills仓库已突破6万Star。有人甚至说，Skills可能比MCP更具影响力。

那Skills到底解决了什么问题？

一、Skills是什么：不是工具调用，是“做事方法”

要理解Skills，先要和MCP做一个区分。

MCP（Model Context Protocol）解决的是 “能用什么工具” 的问题——它是一套统一的协议，让Agent可以调用外部服务和数据。但MCP不告诉Agent “怎么一步步把事情做好” 。

而Skills提供的，是完整的“能力包”：

一个Skill = 任务指导指令 + 执行流程 + 最佳实践 + 可选脚本 + 参考文档 + 素材资源

简单说，MCP给Agent工具，Skills给Agent “操作手册” 。当你把写LinkedIn帖子、做代码审查、生成周报的全套规则封装成一个Skill后，下次只需要说一句“帮我发一篇关于XX的LinkedIn帖子”，Agent就会自动按照你预设的标准执行。

实际案例也验证了这套机制的价值。乐天（Rakuten）团队用Skills将管理会计和财务工作流自动化，原本一天的工作缩短到一小时；SEO内容优化师把完整的优化流程封装成Skill后，原本初级写手2小时的工作量，几分钟就能完成。

二、Skill的底层逻辑：渐进式披露

在动手写之前，你需要理解一个核心机制：渐进式披露（Progressive Disclosure） 。

这个机制解决了AI系统最头疼的问题——上下文窗口有限。如果每个Skill都把全部指令、脚本、文档塞进上下文，装10个Skill上下文就炸了。

所以Skills采用三级加载策略：

• Level 1（始终加载） ：只有name和description这两个元数据。Agent启动时就放进系统提示，用于判断“这个任务需不需要用我”。
• Level 2（触发加载） ：当用户消息与元数据匹配时，Agent才读取SKILL.md的完整正文。
• Level 3（按需加载） ：scripts/、references/、assets/等辅助文件，只有执行过程中真正需要时才加载。脚本本身不占上下文，只有执行结果才进入上下文。

这套机制让Agent可以同时安装几十个Skill而不卡顿，同时保证关键时刻有足够的详细指导。

三、如何写一个好Skill：从零到一

1. 选择一个你已经在重复的任务

最容易踩的坑是：想一次性把所有任务都做成Skill。

正确的做法是：找一个你经常做、而且每次都要重新解释相同上下文的任务。

比如：

• 把技术文章转成LinkedIn帖子（每次解释语气、钩子、CTA规则）
• 每周五写周报（每次解释格式、结构、风格）
• 代码审查（每次解释检查哪些点）

黄金法则：如果你解释同一件事超过两次，就该做成Skill了。

2. 文件结构：严格遵守命名契约

一个Skill就是一个文件夹，最核心的是SKILL.md文件。

my-skill/
├── SKILL.md          # 必需：指令+元数据
├── scripts/          # 可选：可执行脚本
├── references/       # 可选：参考资料
└── assets/           # 可选：模板、资源

命名契约（这几点容易踩坑，而且出错是静默的） ：

• 文件名必须是全大写SKILL.md——写成skill.md或Skill.md会导致Skill不加载，而且不报错
• 目录名必须是kebab-case（如weekly-report），不能有空格、下划线或大写
• frontmatter的name必须和目录名完全一致
• frontmatter里禁止出现XML尖括号（<和>），哪怕写在注释里也不行——Claude Code解析frontmatter时对尖括号很敏感

3. 写description：这是激活开关，不是说明书

这是最关键也最容易被忽视的一步。

Agent判断“要不要调用这个Skill”的唯一依据，就是常驻上下文里那行description。description没写对，Skill写得再好也等于白写。

错误的写法（说明书式）：

“本Skill用于生成博客文章大纲”

正确的写法（搜索引擎式）：

“Generate an article outline in my preferred structure. Use whenever the user asks for an outline, a structure, or section headings for an article or blog post.”

公式：做什么 + 何时用 + 关键触发词

更进阶的做法是：写20条触发测试query——8-10条应该触发、8-10条不该触发（尤其是“近miss”场景——共享关键词但实际不匹配的）。然后跑自动化优化，选择测试分数最高的描述。

4. 写正文：步骤化、可操作、有护栏

正文是Skill触发后加载的内容，需要包含完整的执行指导。

核心原则：

• 步骤化：把任务拆成带编号的步骤，每个步骤清晰可执行
• 显式调用：如果涉及多个子任务，在步骤里显式说明调用哪个子Skill或脚本
• 加护栏：对于有副作用的操作（如删除、写入生产环境），加上“STOP and wait for user approval”这类安全门控

举个例子，一个博客写作Skill套件可以拆成5个协作的Skill：

~/.claude/skills/
├── blog-outline/       # 生成大纲
├── blog-writer/        # 写初稿（可调用 blog-outline）
├── blog-editor/        # 编辑润色
├── blog-seo/           # SEO检查（用脚本算客观数据）
└── blog-meta/          # 生成元信息

主Skill在步骤里显式调用其他Skill：

## 步骤

1. 如果用户没提供大纲，先调用 blog-outline skill 生成
2. 按 reference/style-guide.md 的风格规范写作
3. 使用 templates/article.md.tpl 作为基础模板

5. 让脚本承担“计算”类工作

一个容易被忽略的设计原则：凡是需要客观数据、精确计算的部分，用脚本来做，不要让AI估算。

比如SEO检查中的字符数统计、链接数量统计、关键词密度计算——这些让AI“目测”一定会出错，但写成Python脚本就能保证精确。

四、迭代：第一版必然不完美，但不必追求完美

一个真实的迭代案例：某作者的/daily Skill改到v6才稳定：

• v1：步骤不清楚、路径写错、有些情况没处理
• v2：加了内容发现系统整合
• v3：发现周进度计算常出错，加了明确的计算规则
• v4：加了自动触发——周二提醒跑周会、月初提醒归档
• v5：加了iPhone轻量模式（检测环境，手机上跳过需要Python的步骤）

这不代表失败了。相反，每次迭代都在解决真实使用中发现的问题。

Anthropic官方提供了skill-creator这个元技能——一个专门用来造Skill的Skill。你只需要给它一句描述，它就能引导你走完用例定义、frontmatter生成、验证整个流程，15到30分钟就能做出一个能用的Skill。

更专业一点，还可以建立Eval体系：在evals/evals.json里写测试prompts，同时跑with_skill和baseline（无skill），双盲对比，用aggregate_benchmark出pass_rate / time / tokens报告。

结语

Skill不是一次性的提示词，它是可复用的知识资产。你写的每一个Skill，本质上都是在把“你怎么做一件事”的经验，编码成AI可以稳定复用的指令集。

写一个好的Skill，关键不在技术有多复杂，而在于：想清楚你要解决什么重复问题，把description写到能让Agent准确识别，把步骤写清楚到别人也能照着执行。

第一版不完美没关系。Skill本来就是在使用中迭代的——每一次你发现“这个步骤AI又搞错了”，就是在为下一版积累改进点。

Skill的价值不在于单次输出的效果有多好，而在于可重复的标准化工作流程所带来的复合效率提升。