大多数 Skill 失败，不是写得不好，而是它从来没被触发过。
最近不少朋友开始给自己的 AI 配 Skill——把重复的活儿打包成一个可复用的能力。但装上之后常见两种结局：要么 AI 压根不调用它，要么调用了，产出还是一团乱。今天不聊概念，只讲一件事：日常使用里，一个好用的 Skill 到底该怎么做。
🎯 一句话总结
Skill 好不好用，七成在那段「描述」——它决定 AI 在什么时候想起你写的这套本事；剩下三成，看正文有没有把「怎么做」讲清楚。
🧭 先对齐：什么叫「好用」
一个 Skill 有没有用，不看它写得多全，只看两件事：该出手时它出手了吗（触发准）、出手后活儿干对了吗（产出稳）。下面整套方法，都是围着这两点转。
🔧 制作流程：六步，别跳步
顺序很关键。六步里最容易被省掉的，恰恰是第一步和最后一步。
•从真实重复任务出发：别为「假想需求」造 Skill，挑一件你这周真的重复做过三次以上的事。
•把触发描述写满：写清「什么时候用、处理什么文件、用户会怎么说」，再补一句「什么时候别用」。这是 AI 判断要不要调用的唯一依据。
•正文只讲「怎么做」：写步骤、写顺序、写那些踩过坑才知道的约束（路径、依赖、先做 A 再做 B），而不是科普「它是什么」。
•抽离脚本和模板：把会重复用到的代码和文件单独放好，让 AI 直接拿来用，而不是每次现写。
•拿小样本测触发：故意换几种说法去问，看它会不会调用——不调用，就回去改描述。
•按反馈迭代：触发不准就改描述，产出不稳就补步骤。Skill 是改出来的，不是一次写成的。
🧱 一个好 Skill 的结构
别把所有东西塞进一个文件。好结构是「分层」的，按需加载——AI 平时只读最上面那层，需要细节时才往下翻。这叫渐进式披露：既省上下文，也更稳定。SKILL.md 只放描述和核心步骤，尽量精简；展开的细节、可复用脚本、模板示例，分别放进下面三层，用到才加载。
📋 一套可直接套用的模板
说了这么多，直接给你一个能跑的骨架。它把上面讲的「触发描述 + 怎么做 + 注意事项 + 可复用资源」都占好了位——复制下来，把【】里的内容换成你自己的任务，就是一个 Skill 雏形。
name: 你的-skill-名字（让人一眼联想到任务）description: > 一句话说清做什么，再写清触发条件—— 当用户想做【某类任务】、出现【关键词 / 文件类型】时使用； 并补一句反例：不要用于【不适用的场景】。Skill 名称什么时候用触发场景：……不要用于：……操作步骤（按顺序）输入从哪来、放在哪关键约束：路径、依赖、先做 A 再做 B产出长什么样、放到哪里注意事项 / 踩过的坑……（容易出错的地方写在这）可复用资源scripts/ 可复用脚本assets/ 模板、示例文件
两个地方别糊弄：name 要让人一眼联想到任务，description 是重中之重，宁可写啰嗦也别写抽象——它直接决定 AI 会不会想起来用它。
🤖 偷懒法：让 AI 帮你「反向总结」出一个 Skill
其实你不用从零手写。更快的方式，是先让 Claude、ChatGPT 这类工具陪你把任务做一遍，再让它把过程总结成 Skill。具体五步：
•完整做一遍：在对话里把那件重复任务认真做完一次，过程中把你的要求、纠正、偏好都说清楚。
•让它复盘成清单：发一句——「把我们刚才完成这个任务的过程，总结成一份可复用的 SKILL.md，包含：触发描述、分步骤、注意事项、需要的模板」。
•单独打磨描述：再让它写出 3 种不同的触发说法和 1 条反例。描述越具体，以后越容易被自动调用。
•抽出可复用件：把过程里用到的提示词、表格、文件，让它整理成模板单独存好。
•换个说法验证：新开一个对话，用一句日常的话描述同类任务，看它会不会照这套流程走；不对，就把差异反馈回去让它改。
说白了，AI 最懂它自己刚才是怎么被指挥着把事做成的——让它把这段经验固化下来，比你凭空写一份说明书准得多。
⚠️ 最常踩的几个坑
•描述写得太笼统：AI 永远想不起来用它。宁可把触发场景写「啰嗦」，也别写抽象。
•把 SKILL.md 写成说明书：又长又全，关键步骤反而被淹没。
•只说「是什么」不说「怎么做」：AI 不缺知识，缺的是你这套具体打法。
•写完不测就用：上线前，至少换三种说法验证一次触发。
✍️ 写在最后
说白了，写 Skill 不是写文档，而是把你脑子里「这事我习惯这么干」的隐性经验，翻译成 AI 能照着执行的明确指令。真正值钱的从来不是那段 Markdown，而是你那套被验证过的做事方法——Skill 只是它的载体。
所以别急着追求「大而全」。先挑一件你每周都嫌烦的小事，把它做成一个能被稳定触发的 Skill，跑通一次，比规划十个都强。
