很多人聊起 AI 助手的 Skills态度经常走向两个极端要么把它吹成“神兵利器”好像装上某个技能整个助手立刻脱胎换骨要么觉得它就是“换个名字的提示词”包装得再花哨该笨还是笨。两个说法我都不太认同。Skills 既不是魔法也不是智商税它是把“你和模型之间反复发生的协作动作”沉淀成固定套路的一种办法。要是理解了这个底层逻辑你花两分钟就能写出第一个能用的技能真正的难点从来不在“怎么写”而在“什么值得写”——那些你觉得特别顺手、特别能打的技能几乎都是从真实痛点里一点一点“痛”出来的。我前前后后折腾了不少技能有的一版就废有的改了七八版还是不行踩坑踩得多了慢慢摸出一套自己的判断标准。这篇文章就打算把这套东西摊开讲先拆掉“神化”和“贬低”两座大山再看一次技能在底层到底怎么运转然后带你现场做一个能立刻用的例子最后聊聊怎么找出那些真正值得固化成技能的“痛处”。结尾会附上我自己的几个翻车现场给你当反面教材。1. Skills的“神”与“废”一个容易吵翻天的伪问题先说我观察到的现象。每次有人分享技能评论区总会有类似的争论有人拿着一个几十行的“技能配置”说效果惊人也有人试了之后觉得完全不行直接甩一句“还不如我自己写提示词”。两边都没说假话但都在用自己的个例覆盖全局。这背后的根本原因很简单技能不改变模型本身的能力上限。它改变的只是一个常量——每一次调用时模型会额外获得什么信息、遵循什么约束、按什么顺序执行动作。换句话说模型该聪明的还是聪明该糊涂的还是糊涂技能只是把“聪明的发挥方式”固定下来让输出更稳、更可控而不是把模型变强。我常用一个类比模型本身像一个刚入职的聪明新人知识面广、反应快但缺乏工作惯例。你每次给他布置任务都要重新交代背景、格式、步骤、注意事项状态好时他做得漂亮状态不好、你交代得含糊时他就自由发挥。Skills 相当于给这个新人一份《岗位操作手册》明确告诉他“接到这类任务时按这个顺序处理、用这种格式输出、碰到这些情况要特别留意”。这样一看“神”和“废”的争论就容易理解了。觉得“神”的人是第一次把背后的操作手册固定下来发现输出稳定性大幅提升觉得“废”的人要么是早就把手册内容写进自己的系统提示词里要么是做那种一次性、极个性化、不依赖固定流程的任务——对他们来说技能确实多此一举。所以我不太谈“技能有没有用”更愿意谈“技能在你的工作流里扮演了什么角色”。它本质上是一种工程手段把经验、规则和步骤打包让复杂协作变得标准化、可复用。它不是模型能力放大器而是“协作流程稳定器”。想明白这一层你就不会再纠结“我是不是该把所有事都写成技能”也不会因为某个技能效果不好就全盘否定。还有个容易忽略的点技能的质量参差不齐多数时候问题出在“设计者没想清楚边界”。越是想让一个技能包罗万象、覆盖所有情况它就越容易在各种边缘场景里翻车。反倒是那些目标窄、规则细、划分清楚的技能长期用下来更可靠。这就是为什么同样在玩技能有人手里一堆“一次就废”的配置文件有人能攒出一套稳定好用的个人工具库。2. 看穿运行逻辑一次调用里的三件小事技能看起来是黑盒其实运行逻辑并不复杂拆开看就是三件事识别、注入、执行。这三件事发生在一次普通对话的底层只是平时你感知不到。2.1 识别什么时候触发这个技能技能不是一直开着的。它需要一套“识别条件”告诉助手什么情况下该启用。条件的写法通常分两种一种是靠定义里的描述让模型自己判断是否匹配另一种是靠显式标记比如用户手动选中某个技能。前者更像“语义触发”灵活但偶尔误判后者更像“按钮触发”准确但有操作成本。我自己实践下来比较稳妥的做法是在技能描述里把“适用场景”和“不适用场景”都写清楚。比如写周报技能我就明确写“仅当用户提供本周工作记录或以周报为主题时使用”这样可以有效减少模型在闲聊时把技能拉出来用的情况。别小看这个限制很多技能显得“笨”就是因为触发得太随意什么场合都想插一脚。2.2 注入模型在动手前看到的“额外指令”触发之后技能内容会被注入到模型的上下文里相当于在对话开始前先塞给它一份说明书。这份说明书可以包含背景信息、输出格式、分步操作、禁用事项等。模型之后的推理和回复都会参照这份说明执行。这里有一个关键细节也是很多人误解的地方技能注入的优先级并不一定高于用户当前说的话。系统提示词、用户输入、技能内容三者混合在一块儿模型会综合判断。所以在实际使用里如果用户明确说“不要按周报格式写直接问答”,模型大概率会听用户的。技能不是不可违抗的铁律它更像一份默认偏好。理解这一点很重要能避免你把技能当成“一套必须严格执行的程序”导致在边界情况里对模型输出产生不切实际的预期。2.3 执行输出和动作的边界识别和注入之后剩下的就是执行。执行分两类一类是“只输出内容”模型按规则生成文本或结构化数据另一类是“调用工具”模型在技能指引下发起搜索、读写、计算等外部动作。很多强大的技能属于后者但这也意味着你要额外关注工具的权限和安全性。每次调用还会消耗上下文窗口。技能写得太长会挤占正常对话能用的上下文空间导致模型“忘记”对话前文的内容。我见过有人把一个技能写了四千字结果用起来反而比短技能差很多就是因为模型把上下文资源都拿去“读说明书”了留给用户信息的空间变小。所以技能不是越详细越好而是要“刚好够用”。这个平衡点需要根据你用的平台和模型情况自己试。我通常会控制技能正文在八百到一千五百字之间。超过这个范围我就会开始怀疑是不是规则太冗余或者是不是该拆成多个技能了。这不是硬性标准只是一个提醒上下文是稀缺资源每个字都要有存在的理由。3. 两分钟创建初版我会用周报技能做例子技术原理讲太多容易飘上手做一遍最实在。下面我用一个“周报整理”技能作为例子带你走一遍完整创建流程。按我的经验如果不纠结措辞真能做到两分钟内写出一个能用的初版。3.1 准备工作先回答五个问题动手之前我会先要求自己回答五个问题回答完了技能的大致框架也就出来了这个技能处理什么类型的任务输入是什么用户会提供哪些原始材料输出是什么最终的格式长什么样有哪些必须遵守的规则或禁忌什么时候不该用这个技能对周报技能来说答案大概是这样任务是把零散的工作记录整理成结构清晰的周报输入是用户随手记的日志、聊天记录、待办列表输出是包含“本周进展”“风险与问题”“下周计划”三块的 Markdown 文档规则是“只整理用户提供的信息不要虚构”以及“默认不改变事实只在表述上做优化”不适用场景是“用户不是在写周报而是在写日报或项目总结”。别小看这五个问题。它们相当于技能的“需求说明书”能帮你避免一大半后续返工。很多技能之所以改来改去就是因为一开始没想清楚边界和输出格式。3.2 创建一个可直接套用的技能模板下面是我常用的技能描述模板你可以直接复制改技能名称周报整理助手 适用场景 - 用户提供零散的工作记录、日程、聊天摘要希望整理成周报 - 用户明确要求“按周报格式整理”或类似表述 处理步骤 1. 通读用户提供的信息提炼出关键工作事项 2. 将事项分类到“本周进展”“风险与问题”“下周计划”三个板块 3. 每条事项用一句话概括保持客观不夸大成果 4. 按时间倒序排列“本周进展”里的条目 输出格式 - 使用 Markdown 标题三个板块分别为二级标题 - 每个板块下用无序列表列出条目 - 条目尽量控制在 30 字以内 必须遵守 - 只处理用户明确提供的信息不得编造进度或结果 - 如果用户提供的信息过少主动询问补充 - 不改变事实细节比如日期、负责人、完成状态 不适用场景 - 用户需要的是日报、月报或项目复盘 - 用户想讨论周报写法的建议而不是真正生成一份周报你可能会觉得这套描述太啰嗦。但正是这些“边界”和“步骤”让技能稳定。触发条件写得清楚模型就不容易误用步骤写得具体输出质量就会一致不适用场景写得明确模型在模糊的情况下就知道该退让。有人喜欢用 YAML 或者 JSON 格式来写这种描述我也觉得没问题。但一开始我更推荐用自然语言因为改起来更顺手可读性也更高。等以后技能复杂了再考虑结构化格式也不迟。3.3 快速验证用三条“测试用例”确认效果创建完成之后不要急着直接投入使用先用几个虚构的样本测一下。我会模拟三个输入一段典型的零散工作记录、一条只有一句话的极简输入、一条跟周报完全无关的内容。看模型在三种情况下分别怎么反应。拿上面这个技能来说第一个输入应该能产出一份格式完整的周报第二个输入我希望模型主动说“信息不足需要补充”而不是硬写第三个输入也就是无关内容我希望模型不要强行套用周报格式而是自然转入普通对话。如果三种情况都符合预期这个技能初版就算能用了。整个过程如果你已经熟悉这个技能模板确实两分钟就能搞定。难的部分不是写出来而是接下来长期使用里的调整和打磨这就涉及到第四部分要谈的“痛点驱动”。4. “痛”出真正好用的技能从一句抱怨到一套流程我最想重点聊的就是这一部分。因为观察了一圈很多人做技能是“先写了再说”灵感来了就创建用两次就扔。真正耐用的技能几乎都不是这样来的它们更像是被同一件事反复折磨之后忍无可忍才被逼出来的。4.1 痛点清单哪些“疼”值得变技能先做个区分。不是所有抱怨都值得做成技能只有那些满足以下特征的痛点才值得高频发生、流程固定、每次都要花时间重新讲述要求、输出标准比较统一。我给自己定过一个“三次原则”同一类任务如果我在一周内手动做了三次并且每次都要重复打一大段说明那它就值得做成技能如果只是偶尔一次或者每一次的处理逻辑差异很大那就老老实实手动写别硬做技能。举几个我身边的真实例子。有个朋友经常需要把会议录音转成文字纪要但每次都要花好几分钟写明格式要求和重点提取规则后来他做了一个“会议纪要整理”技能效果立刻不一样。再比如我自己经常要给不同项目写简短的项目状态同步每次都要重复“按进展、风险、下一步三个部分各写两到三句话”写了第四次之后我就受不了做了一个模板技能。这些都不算什么惊天动地的需求但它们高频、固定、痛感明显天然适合被技能化。4.2 从“一句抱怨”到“一条技能规则”痛点变技能的路径我总结出来其实是四步记录痛点、提炼规律、落到描述、实测迭代。第一步记录痛点就是在你被某件事烦到的当下顺手把“我为什么烦”记下来别等到过后再回忆。第二步提炼规律是把“我这次希望它怎么做”抽象成普适规则。第三步落到描述是把规则写进技能的步骤和约束里。第四步实测迭代是带着真实样本反复测试看它哪里还疼再针对性地改。举个例子。“我烦每次整理周报都要手写一遍格式要求”是一句抱怨。“以后用户提供零散记录时自动按周报三段式整理并且每件事只提炼一句话”是规律。“在每个板块下用无序列表每条不超过三十字”是描述里的具体写法。最后你拿五份真实记录去测发现其中两份的“风险与问题”被模型写成了套话你就会再补一条规则“风险与问题必须来自用户原话不得凭空猜测”。这一步一步“痛”出来的修正才是技能真正变好用的原因。4.3 迭代节奏技能不是写完就结束很多技能做出来是“一次性生效”之后就再也不更新了。这其实浪费了技能最大的优势——它可以被持续打磨。模型在变、工具在变、你自己的表达习惯也在变技能如果静止不动很快就会退化。我的习惯是每个月抽一点时间把技能列表过一遍删掉一次都没用过的把频繁使用的技能打开看看近期的输出有没有跑偏如果发现模型经常忽略某条规则那就把它提到描述更靠前的位置或者给出一个正例。这种维护听着不起眼但长期下来差别很大。好的技能像手边的工具越用越顺手。而让它们变顺手的不是最初那一版写得多完美而是后面被真实使用里的痛点折腾过多少轮、改了多狠。这也是我想强调的核心观点技能是从痛苦里生长出来的。5. 把我劝退的翻车现场技能失效的五种死法光讲成功经验不够反面案例的参考价值往往更大。我自己的教学经历里有不少技能是动不动就废了的这里挑五种典型的“死法”说说。5.1 死法一技能过载规则多到模型记不住第一个翻车现场是我早期特别贪心把一个技能写成了“一站式全家桶”。规则里有背景信息、处理流程、格式规范、数据清洗、风险提示、输出校验……洋洋洒洒快两千字。结果用起来发现模型经常执行到一半就“忘了”后面的步骤输出偶尔对偶尔错极不稳定。后来我把它拆成三个分工明确的技能每个只负责一段流程稳定性马上就上来了。教训就是技能描述不是写论文长度是敌人。宁可分成多个小技能也别在一个技能里塞太多动作。5.2 死法二触发条件太严该用的时候没触发另一个常见问题是把触发条件写得太死板。比如我在一个技能描述里写了“仅当用户输入包含‘请生成周报’时才触发”结果后来我自己换了说法说“帮我整理一下这周的进展”技能就没触发了等于白做。改进办法是放宽语义条件同时用否定项来约束。把触发条件写成“当用户提供近期工作记录、且要求进行整理或汇总时使用”并且加上“用户只要求问答、不要求整理时不要使用”。这样既不会太迟钝也不会过于灵敏。5.3 死法三工具调用配置错误技能执行到一半中断有一个技能需要调用外部工具读取文件结果我配置权限的时候没注意助手读完开头一小段就停下来问东问西反而比不用技能还慢。排查了一圈发现是工具权限里设了“每次读取前必须确认”执行时每一步都在等确认流程就碎了。这类问题不完全在技能描述本身更多在于技能依赖的外部工具设置。如果你发现一个技能经常中断、卡住、反复确认先去看看它调用的工具是不是需要更细致的权限设置别一股脑往描述里加“继续执行”四个字。5.4 死法四版本更新后失效旧技能没人管平台和模型版本更新会导致技能的某些假设失效。比如我之前给某个技能写的“禁止使用某格式”在新版本模型出来之后这条规则就莫名其妙被忽视了。不是模型变笨了而是新版本在指令理解上跟旧版本有差异旧技能没跟上自然就失效。这个问题的解法其实就一句话定期回归测试。每次平台有大版本更新我都要花几分钟把常用技能跑一遍样本谁坏了修谁。这套习惯比任何高级技巧都管用。5.5 死法五把一次性任务包装成技能最后一个特别典型某次处理一个特殊的、不会再重复的任务顺手就做成了技能。结果技能躺在列表里吃灰几个月占着位置还可能在模型自动识别时误触发。我自己就吃过亏有一次清理技能列表才发现一堆这种东西。我现在的原则是如果我不能确定这个任务在未来一个月会重复出现就不做技能直接用一次性提示词解决。技能库宁可小而精不要大而杂。6. 什么情况下先别急着写技能把前面的逻辑梳理完之后我想给出一个更冷静的判断标准不是所有东西都该技能化有些情况反而应该忍着。一个是我前面说的“一次性任务”不用我说你也知道了。另一个是“高度依赖个人当时灵感”的任务比如写诗、构思创意标题这种任务每次的创作逻辑都不一样固化技能反而会限制想象力。还有一种是“涉及外部行为且权限不明确”的任务如果你不确定工具的权限边界最好别贸然把整套动作写进技能避免出问题之后不好定位。反过来什么情况下应该积极考虑写技能呢高频、固定、规则化、你已经在重复忍受的任务。只要你开始觉得“又要我做同样的事了”那个瞬间就是技能诞生的最佳时机。不用等平台更新也不用等别人的炫酷模板从你自己的痛处里挖出来的技能往往比任何“全网爆款”都要适合你。我自己的技能库里算下来真正长期在用的也就七八个每一个都对应着我反复经历过的痛周报整理、会议纪要、项目状态同步、格式统一、代码审查反馈、文章校对提纲……没有一个是“为了做技能而做技能”的产物。它们的每一次改动几乎都有具体事故驱动某次输出格式乱了某次丢掉了一条重要信息某次该触发时没触发。说句夸张点的话我的技能不是“设计”出来的是“疼”出来的。所以如果你现在正在犹豫要不要做个技能、或者刚试了几个技能觉得效果一般我建议你先别去到处收藏别人的“神级技能”。拿一张纸或者打开一个备忘录随手记下未来几天里所有让你不耐烦、想重复交代事情的情景。攒一个星期再回头看看哪类事情出现了三次以上哪件事让你一提就烦那才是你真正应该写进技能的素材。我最后再分享一个小技巧给技能起名和写描述时别用什么特别抽象的概念就用你自己能听懂的大白话。技能库是你的个人工具架不是给谁参观的展览品。你越清楚它“在什么场景下、解决什么麻烦”这个技能越好用。至于那些看起来很炫的全局规划、复杂编排等你想清楚痛点在哪儿之后再去折腾也不迟。