最近几个月，我私信里最常出现的一句话是：“我想做一个自己的AI Skill，但完全不知道从哪下手。”说这话的人，有做知识付费的、有想搞副业的设计师、有几乎不会写代码的文科生，还有几个正在走“超级个体”路线的自由职业者。他们有个共同点：看了一堆厂商文档，越看越懵——Claude叫它Agent Skills，Codex叫它Custom skills，豆包把它叫技能插件，DeepSeek那边说能在Harness里装Skill。同一个词，四套说法，新手直接被绕晕。
这种混乱其实很正常，Skill这个概念正处在“人人都在喊、但江湖规矩还没定”的阶段。但落到具体做事上，它并没有那么玄。我自己从零做过备课类、专利辅助类、内容创作类的Skill，也帮朋友拆过不少失败案例，跑通整套流程之后发现，一个超级个体想把Skill做出来、用起来、迭代起来，路径其实是固定的，大体就五步。多数人卡在第一步——没想清楚Skill到底是什么，就直接去写提示词。我先把概念关过了，再往下拆，因为这是我见过最多人翻车的地方。
1. “Skill”这个概念，先别急着动手写
“Skill”这个词最近几乎被玩坏了。厂商各说各话，社区教程也各写各的：有人说是高级提示词，有人说是插件，有人说是Agent，还有人觉得只要写个Markdown文件就算Skill。这种定义混乱不是小事，它会直接导致你做错方向——花大量时间写出来的东西，放进真实对话里根本发挥不了作用。
1.1 为什么市面上的定义这么乱
原因很简单：每家平台都在用自己的生态理解做Skill。Anthropic把Agent Skills设计成“项目内的一个文件夹，包含说明文档和可选脚本”，强调模型自主调用；OpenAI的Codex把Custom Skills更像“定制化指令包”，偏重编码场景的规范约束；豆包这类国内平台则习惯做“技能广场”，把Skill包装成可下载安装的插件形态；DeepSeek最近公开的智能体训练思路里，也提到通过Harness安装Skill来增强行为控制。术语体系不同，底层逻辑却高度相似。
但恰恰是这层“外壳”差异，把新手带偏了。很多人以为Skill就是一段写得比较好的提示词，于是花两个晚上憋出三千字角色设定，然后发现模型根本不按设定的流程走；也有一些人以为Skill必须写成复杂插件，一上来就研究接口协议，结果被工程细节劝退。
1.2 我给Skill划的边界：不是插件，也不是普通提示词
做了一段时间之后，我自己比较认可的理解是：Skill是“一套能被AI模型按需调用的完整工作流”，它通常包含身份设定、工作流程、动作工具、输入输出规范这几个部分。普通提示词只告诉模型“你要怎么做”，Skill则更进一步——告诉模型“你判断什么情况该做、按什么顺序做、用什么工具做、做完要输出成什么样”。它是把一个人脑里的“经验剧本”固化成机器能读懂的文件夹结构。
我举个例子。你写一个提示词“你是资深专利代理师，帮我检索对比文件”，模型确实能写出像模像样的分析。但如果做成专利辅助Skill，它会先判断用户属于“交底书评估”还是“权利要求提取”还是“审查意见答复”场景，然后自动调用检索脚本去比对外部数据源，再按特定格式输出带置信度的对比表。这里的差别不在“谁更聪明”，而在“谁有流程、有工具、有标准”。Skill真正的价值，是把一次性的聪明回答，变成可复用、可校准、可迭代的标准化产能。
所以做Skill之前，先问自己一句：我要做的事情，是单纯靠“嘴皮子”就能说清楚，还是必须依托一个稳定流程和外部工具来保证质量？如果是后者，才值得做成Skill。想通这一点，后面每一步才不走回头路。
2. 第一步：选准场景，比写代码重要十倍
我见过太多人做Skill的启动方式是这样的：先决定“我要做一个AI Skill”，再琢磨“做什么方向”，最后拍脑袋选了一个自己觉得酷的功能。这种顺序从一开始就错了。正确的做法是先找到真实且高频的痛点，再看这个痛点能否被模型、脚本、数据三件套有效解决。
2.1 从“高频琐碎”和“强逻辑”的交叉点找需求
最适合做成Skill的需求，通常有两个特征。一是高频琐碎，比如备课、专利初步检索、旅游行程规划、短视频脚本文案，这些事情单独看不大，但反复出现，且每次都消耗大量人力；二是强逻辑，即事情本身有固定的步骤和方法论，不是纯天马行空的创意活。你去看最近搜索量暴涨的那些词——“AI备课Skill”“AI旅游”“狗头军师Skill”“专利相关辅助链接 AI辅助”，背后全是这两个特征的组合。
拿专利辅助来说，很多独立发明人其实不懂怎么写交底书，也分不清权利要求里的“独权”和“从权”的区别。这类需求非常具体，而且天然带一套可固化的流程：先读技术方案，再提炼创新点，再按专利语言组织权利要求层次。做成Skill之后，模型可以引导用户一步步输入技术细节，而不是甩一个空白聊天框让人家自由发挥。这就是高频琐碎和强逻辑交叉产生的机会。
2.2 反推需求：看看人们正在搜什么
如果你一时找不到方向，我建议你别坐在屋里想，而是去翻搜索词和社区讨论。那些被反复搜索的“XX Skill”，每一个都代表一个未被满足的痛点。比如“book to skill”这个说法，说明很多人希望把一本书变成可交互的知识技能；再比如“Codex Skill 科研”，说明科研人员想在论文写作、文献梳理这些场景里获得可复用的AI工作流；还有“豆包安装Skill”被频繁搜到，意味着大量普通用户已经意识到默认对话不够用，想要更专业的功能模块。
看到这些信号之后，你可以再往下拆一层：这类Skill上线之后，用户到底会怎么用？比如“狗头军师Skill”这种偏创意和决策辅助的方向，本质上是帮用户“多角度抬杠式”地审视一个决策，它需要的是模型具备强批判性思维框架，而不是调用什么复杂外部工具。这类Skill做起来轻，但很吃提示词设计功力。
2.3 需求收敛：一个Skill只做好一件小事
选场景时，我强烈建议把口子收窄。不少新手把Skill做成了“瑞士军刀全集”——既能写文案，又能做PPT大纲，还能生成配图提示词，最后每个功能都浅尝辄止。模型在推理时拿到的描述模糊，调用成功率就会暴跌。
正确做法是：一个Skill只负责一件小事，哪怕这件小事听起来很窄——“给程序员写周报”“给小学数学课设计随堂练习”“把公司财报翻译成人话”。定义好了之后，把自己关在一个小房间里，把“输入什么信息、经历什么处理步骤、最终输出什么格式”这三件事写死。我自己的习惯是连“不做的事”也要写进说明里，比如“本技能不负责生成答案，只负责辅助理解”，越清晰，后续调试越省力。
3. 第二步：技术底座选型，你的Skill跑在谁的生态里
场景定下来之后，紧接着要回答一个非常现实的问题：这个Skill挂在哪里跑？不同平台的Skill机制差异不小，选择直接决定了你后面怎么写文件、怎么传参数、怎么让模型“看到”并且“调用”你的技能。
3.1 主流平台的Skill机制差异
先说Claude生态。Claude的Agent Skills目前采用的是项目内置文件夹的方式，通常结构是这样的：
my-skill/ ├── SKILL.md ├── scripts/ │ └── run_analysis.py └── assets/ └── template.md核心在于SKILL.md，这个文件必须带YAML格式的头信息，包括name、description、how to use这些字段。其中description字段我花了很多功夫调试，因为它直接决定模型在什么时候会“想”起这个技能。官方建议在description里写“何时使用本技能”而不是“本技能是什么”，这是有道理的——模型是靠语义匹配来决定是否调用，描述越贴近用户的真实问题表述，命中率越高。
再说Codex方面。Codex的Custom skills用YAML和Markdown组合，允许在配置里声明名称、描述和指令集，尤其适合给AI编程助手设定项目特定的代码规范或验证流程。我在帮朋友做Codex科研类Skill时，就把文献调研流程拆成了“检索论文→提取关键结论→生成对比表→输出综述草稿”四个步骤，每一步写清楚判断标准，模型在代码环境里配合工具执行起来非常顺。
至于国产平台，豆包目前的技能广场走的是安装即用的插件路子，适合分发但自定义程度相对受限。DeepSeek的Harness方案则是从智能体训练角度切入，把Skill作为行为约束的一部分注入到执行流程里，更学术、更工程化。还有很多人问“API MCP Server Skill”是什么，我统一解释一下：Skill是技能的组织方式，MCP是模型调用外部工具的统一协议，两者不是同一个层次的东西。复杂Skill内部可以封装一个MCP Server来对接外部数据源，但如果你只是想让模型按流程做分析、生成结构化结果，完全不需要上MCP，本地脚本就够轻。
3.2 跨平台兼容的通用做法
如果你不想被某个平台拴死，我有一个通用套路：把Skill设计成三层结构。第一层是“标准Markdown说明层”，也就是SKILL.md或等价文档，保证任何平台都能读懂；第二层是“脚本层”，用Python或JavaScript写纯函数式的动作脚本，不依赖平台SDK，输入输出都用标准JSON；第三层是“适配层”，针对不同平台写很薄的映射文件，比如把Claude的目录结构转成Codex的配置格式。实测下来，核心逻辑一次写好，换平台只需要改适配层，成本能压到很低。
这个方案唯一的代价是需要一点工程能力，但即便你不会写代码，也可以让模型帮你生成脚本，你负责描述逻辑就好。我见过一个完全不会编程的朋友，用对话方式把一套专利检索流程拆给Claude，让它逐段生成Python脚本，最后集成出来也能跑得通。模型写代码的能力早就够用了，卡人的从来不是代码，而是“你能不能把自己脑子里的流程讲清楚”。
4. 第三步：把模糊想法变成机器可读的SKILL.md骨架
选好底座之后，就进入最核心的写作环节。很多人把这个环节理解为“写提示词”，但它比写提示词要求更高。你要做的，是把一个模糊的想法翻译成一份模型能稳定照做的操作手册，同时配上可执行的动作。
4.1 YAML头信息：name、description、how to use的写法细节
以Claude Agent Skills为例，SKILL.md开头有一段YAML头信息。我写多了之后，对每个字段都有自己的心得：
--- name: lesson-planner description: 当用户需要快速设计某一学科、某一课时的完整教学方案时使用，覆盖教学目标、重难点、教学流程、随堂练习与板书建议。不适用于课程论文写作或教育理论探讨。 how to use: 先让用户提供学科、教材版本、课时时长和班级基础，再调用 scripts/lession_builder.py 按标准模板生成教案，最后把可调整的开放项逐条列出供老师确认。 ---name字段要短，且能看出功能方向；description不要堆形容词，直接写“什么情况下使用”和“什么情况下不要用”，这两句话是模型做路由的依据。how to use则要写清楚触发动作的顺序，让模型知道第一步干什么、第二步干什么。很多人会忽略“不适用于”这个信息，但我发现它比正向描述更管用，能显著减少模型在无关话题上误调用Skill的概率。
4.2 正文部分：角色、目标、工作流程、输入输出格式、边界
YAML下面就是正文，我的习惯包含五块：角色定义、工作目标、工作流程、输入输出格式、边界与禁忌。角色定义写得别太玄乎，“你是资深专利代理师”这种我会改成更具体的行为约束，比如“你按专利审查指南的逻辑分析技术方案，输出时使用专利领域的标准术语”，模型对这种行为描述比对身份标签的理解更精准。
工作流程部分，我把步骤尽量拆细，并且对每个步骤给出完成标准。比如“分析交底书”不能光写这五个字，要写“先提取技术特征，标记出与现有技术不同的关键点，再判断该关键点是否属于技术方案而非商业规则”。输出格式要直接给模板，最好是一段示例，告诉模型“长什么样算合格”。边界与禁忌里明确写“不做侵权判断”“不做商业模式建议”，这既控制幻觉，也帮你规避后续风险。
4.3 动作脚本：一个脚本只干一件事
如果你的Skill需要执行外部动作，把脚本放进scripts目录，命名要语义化。比如备课Skill里，我放了一个lesson_builder.py，输入是学科、知识点、课时长度，输出是一个结构化的教案JSON；专利辅助Skill里，我放extract_claims.py和prior_art_search.py，分别负责权利要求提取和对比文件检索。脚本越小越好，一个脚本只干一件事，方便单独测试和替换。
写脚本的时候，我给模型留的“自由裁量权”很小。凡是能用参数控制的，绝不靠模型临场发挥。比如教案的课时结构、随堂练习的题量，全由脚本按参数模板生成，模型只负责填具体内容。这样做的好处是，输出质量的下限被托住了，即使模型某个环节发挥失常，整体框架也不会散架。
5. 第四步：开发、联调、自测的完整闭环
Skill写完初稿，距离“能用”还差得很远。我见过太多人写完SKILL.md就兴冲冲拿去发布，结果放进真实对话里被用户两句话问懵。开发和调试是一个需要反复攻击自己的过程，我一般把它分成三个阶段：用AI辅助开发、设计对抗性测试、做“人味”校准。
5.1 用AI写AI：让模型帮你开发和挑刺
我写Skill有一个习惯，叫“双AI协作”。第一步，用一个大模型根据我的场景描述生成SKILL.md初稿；第二步，把初稿喂给另一个模型，告诉它“你是这个技能的第一个用户，请用最刁钻的方式测试它”。这一步能发现大量逻辑漏洞，比如指令前后矛盾、步骤缺少兜底方案、输出格式没有示例等等。
拿备课Skill来说，初稿里的工作流程是“分析教学目标→设计课堂环节→生成练习题”。另一个模型测试后直接指出：如果用户只给了一个章节名，没有任何教材细节，流程根本走不动。这个问题非常真实，教师用的时候确实经常只甩过来一句话。于是我在SKILL.md里加了一条兜底逻辑：信息不足时，先输出信息收集清单，并给出三个可选的默认教材版本。这个补丁让Skill的鲁棒性提升了一大截。
5.2 设计测试用例：正常路径、边界输入、错误输入、长对话
自测不能只跑一条“看起来会顺利”的路径。我给Skill建了一个测试用例表，至少覆盖四类输入。正常路径，比如“初中物理《浮力》一节课，45分钟，学生基础一般”；边界输入，比如“只有10分钟的微课”“学生已经熟练掌握阿基米德原理”“班上三分之一学生是物理竞赛选手”；错误输入，比如“讲一节不存在的课程”“用户要求生成一篇论文”；长对话测试，也就是连续追问多轮，看Skill会不会在后半段忘了自己的角色和流程。
长对话测试是我最关注的一项。模型在短对话里约束力很强，但聊着聊着就会自由发挥。我的对策是在SKILL.md里加一个“对话中要随时自查”的机制，让模型在每次输出前快速核对当前用户意图是否仍属于本技能的范围。不要小看这一句话，它能在长对话场景里把受众拉回正轨。
5.3 对抗性测试工具与“去AI味”检查
我看到社区里有人分享过grill-me这类工具，功能是自动生成各种刁钻问题来“拷问”你的Skill，快速暴露提示词里的安全漏洞和逻辑死角。这类工具的价值在于把测试自动化，适合那些需要频繁更新的成熟Skill。我这里说一下自定义测试的补充建议：不要只测“用户正确提问”的情况，还要测“用户提问本身就很模糊”的情况，模糊提问才是真实世界的大概率事件。
联调阶段最后一步，我会做一遍“去AI味”检查。做法很简单：把Skill生成的结果拿给身边一个不明内情的人看，问他“你觉得这些话像是真人写的吗？”如果答案是不像，就回去调整提示词。具体调整手法我摸索出几个：删掉“首先、其次、此外、总而言之”这类连接词，把“旨在、助力、赋能、确保”换成“用来、帮你、省得”，把排比堆砌的形容词改成具体可感的数据或案例。AI味不是玄学，它是由一组高频套话构成的，去味也就是把这组套话从输出模板里挖掉。
6. 第五步：发布、反馈、迭代的日常
Skill上了线，真正的工作才开始。很多人把发布当成终点，其实它是起点。一个Skill只有在被真实用户反复揉搓之后，才能从“能跑”进化到“好用”。这一步的核心是建立反馈闭环，并且用迭代节奏去持续优化。
6.1 发布时把README写清楚
发布Skill时，我见过太多人只丢一个下载包，连说明都不写。然后用户装上去用起来不对，也不提issue，直接跑到社区骂。老实说，这怨不了用户，是你没把“预期边界”讲清楚。我的习惯是README里必须写清楚四件事：这个Skill适合什么人、需要什么样的输入、哪些场景它明确不处理、已知的限制是什么。比如“备课Skill”我会写：适合K12学科教师快速生成初稿，不适合课程体系设计；输入最好包含教材版本，没包含时会先向你追问；输出教案需人工复核后使用，尤其是实验安全类环节。
把这些写在明面上，不是给产品减分，而是帮你筛选出真正匹配的用户。那些被劝退的人，大概率本来就会给你打低分。
6.2 建立反馈机制：日志比夸奖重要
Skill跑起来之后，最重要的物料是用户真实提问记录。平台一般不直接给你看完整日志，但你可以设计一个动作：让Skill在运行过程中把用户的关键输入和最终输出结构化地存进一个文本文件，或者通过一个简单的接口回调到你自己的表里。别纠结隐私问题，你在README里声明“仅用于匿名优化”就好。
我每次迭代都会翻这三样东西：用户最常输入的句式是什么、什么类型的输入触发了最多失败、用户拿到输出之后还会追加什么问题。比如做知识型Skill的时候，我发现用户提问的方向经常会落到某一个具体知识点的延伸，而不是预设的整体概括，这说明用户的真实需求是“知识探索”而非“内容总结”。这个反馈直接让我把书籍转化Skill的知识检索权重从“按章节顺序”调成“按问题相关性重排”。
6.3 迭代节奏：提示词天天调，脚本周更，接口不轻易动
迭代也要有节奏，不能想到哪改到哪。我自己定的规矩是：提示词层面的修改随时可以，这属于微调；脚本层面的修改至少要攒够几个明确需求再动，最好一周一个小版本；对外接口和数据结构不要轻易变，一旦变了就是重新发布，需要全量回归。每次改动之后，哪怕只是改了一句描述，也要把旧测试用例整体跑一遍，防止“修好一个问题崩掉三个场景”这种事发生。
在这里分享一个真实教训。我做过一个内容创作方向的Skill，某次因为用户反馈“输出太啰嗦”，我把提示词里的“详细”改成了“简洁”。结果正确路径倒是变爽利了，但碰到复杂场景时模型开始漏掉关键步骤，整个输出从“冗长但完整”退化成了“简洁但残缺”。做回归测试时这个问题立刻暴露出来，我花了一晚上重新设计“简洁”的定义，改成“输出必须包含四个固定模块，模块内部删冗余表达”，而不是笼统地要求少写。后来我意识到一个道理：给模型的指令，一定得是“可检查的”，而不是“可感觉的”。
Skill的迭代就是这样一点点磨出来的。很多真正受欢迎的Skill，最初的版本都非常简陋，它们的竞争力也不是来自一次成型的设计，而是来自持续不断的小步快跑。超级个体和团队pk不到人力和预算，只能拼一件事——迭代速度。谁能更快地收集反馈、定位问题、修正行为，谁的Skill就能在社区里活得更久。
就我自己而言，做了这么多轮的Skill之后，最大的体会是：做Skill最稀缺的技术不是写代码，不是调参数，而是“精确描述一个流程”的能力。你得能把那些平时熟练到不需要思考的工作方法——备课、检索、策划、分析——拆成一二三四五步，每一步都说清楚触发条件、行动内容和完成标准。这个能力只能靠一次次的“写—测—被锤—重写”练出来。今天我把整条路径摊开来讲，也只是帮你把这条练习之路上的弯路提前画出来而已。
