你有没有遇到过这样的情况你刚给AI助手讲清楚了一套方法论比如“分析用户访谈记录要先剔除无效样本、再按主题编码、最后聚合出洞察”它当时点头称是做出来的结果也像模像样。可隔几天换一个新会话同样的需求再来一次它又把这套流程忘得一干二净像是第一次听说。我一开始也以为是上下文长度不够后来才发现问题根本不是“记忆”而是知识没有被打包。这就是我现在想聊的东西——Skills。它可以理解成一种给AI配套的“专家操作手册”把某个领域的知识、流程、模板、甚至校验规则写进一个独立的目录结构里AI在遇到对应场景时会自动加载这套手册照着里面的方法论执行任务。这篇文章我打算把构建这类技能包的核心设计思路、完整实例、调试方法和踩坑经验全部拆开讲一遍适合正在做AI Agent、智能体工作流或者希望让AI稳定处理固定任务的朋友。1. 先搞清楚Skills是什么别再和插件搞混了1.1 一句话定义Skills是可装载的专家工作手册很多人一听到“Skills”就以为是工具调用能力的扩展其实不太一样。我更喜欢用一个比喻**Plugins是车上的工具Skills是司机手里的路线图。**工具告诉你“我能做这件事”路线图告诉你“遇到这种情况应该按什么顺序、用什么标准、产出什么结果”。具体到文件形态上一个技能通常就是一个目录里面有主文件、脚本、参考文档。AI在运行时会根据用户请求的描述决定要不要把这个目录里的内容加载进上下文然后按照里面写好的步骤来干活。整个机制有点像一个“按需加载的知识模块”——你平时不占内存用到的时候才把整本手册翻出来。我自己第一次动手做这类技能包就是因为被AI反复无常的“失忆”搞烦了。明明上一版对话里已经把某类报告的结构、语气、字段都调得差不多了下个新会话又要从头教一遍。而一旦把这一整套要求固化成一个技能后续只需说一句“帮我生成一份XX报告”AI就会自动去取技能里的规范效果稳定非常多。这个模式的本质是把你和AI之间的一次性“对话调教”沉淀成可持续复用的“项目资产”。1.2 为什么需要Skills把隐性知识变成显性资产这里有个核心问题值得深挖大模型本身不携带领域知识的“肌肉记忆”。你在对话里告诉它的信息只存在于当前上下文窗口里对话一结束就归零。所以每次想让AI产出特定质量的结果你就得重新把背景、规则、案例、格式要求全部灌输一遍这既浪费时间也容易前后标准不一致。Skills恰恰解决了这个“每次从零开始”的痛点。你可以把这套能力想象成给AI配了一个“长期职业培训手册”它不需要记得你所有的偏好它只需要在恰当的时候读到正确的文档。更重要的是手工写的这套技能包是可以跨会话、跨项目甚至跨团队复用的。你把方法论沉淀成文件后同事拿到就能直接用不需要你亲自去“人肉复述”一遍。另外这种形式也对调试友好。以前AI产出不对你只能反复改提示词改完也没有记录一个月后回溯根本不知道改了什么。现在技能包是一个目录里面的每个文件都能进Git做版本管理哪一版的方法文案让输出质量明显提升一查历史记录就清清楚楚。知识变成代码一样可diff、可回滚、可评审的东西这才是它最大的价值。1.3 Skills、Plugins、Agents三者的边界在实际做AI应用的时候这三者经常被混在一起说我建议在认知上把它们切开。Plugins解决的是“AI够不到外部世界”的问题典型形态是搜索、读写数据库、发送邮件、调用第三方API。它提供的是原子能力本身不包含“什么时候用、怎么用才能得到好结果”的判断逻辑。Agents解决的是“AI怎么规划一连串动作”的问题它负责感知当前状态、拆解目标、决策下一步调用哪个工具、观察结果再继续。这是一个偏动态的决策循环。Skills则站在另一个维度它提供的是“某一类任务应该怎么做”的领域方法论。它可能包含几十条步骤、若干质量标准、若干输出模板但它不负责调用外部工具。换句话说Skill给Agent提供了“行为准则”Agent结合当前用户请求决定是否使用这套准则Plugins则作为准则中被调用的具体执行手段。举个最直白的例子如果我要AI做一份行业研究报告Agent负责判断“先搜集资料、再整理框架、最后撰写”Plugins负责真正从网上获取资料而Skills负责规定“报告必须包含行业现状、竞争格局、未来趋势三个章节每个论点必须附数据来源”。三者各司其职少了SkillsAgent和Plugins都能跑但产出的报告质量会非常不稳定。2. 项目设计目录结构、命名约定与格式核心2.1 一个标准技能包目录长什么样想动手做一个技能第一步不是急着写内容而是先把目录结构定清楚。这里我直接给出一个我在实践中验证过、个人比较推荐的标准布局my-skill/ ├── SKILL.md ├── scripts/ │ └── preprocess.py ├── references/ │ ├── 行业术语表.md │ └── 内部命名规范.md └── templates/ ├── report_template.md └── email_template.md这个结构看起来简单但每一层都有它的必要性。SKILL.md是技能包的核心入口相当于整个仓库的“README操作手册”AI加载技能时最先读取的就是它。scripts目录放可执行的脚本用于处理那些文本模型不擅长但代码很擅长的机械任务比如批量去重、正则清洗、统计词频。references目录放参考资料AI会在正文中按需引用其中的信息比如术语解释、指标口径、规范要求。templates目录放输出模板能极大降低AI自由发挥带来的格式漂移问题。有一种特殊情况当技能内容本身很短、只有几条规则时不需要建这么多子目录单独一个SKILL.md文件就能跑通。但一旦技能涉及复杂任务、需要多份支撑材料你就要尽早按上面这个结构拆开不然等SKILL.md膨胀到一万多字时AI反而抓不住重点。2.2 SKILL.md该写什么、不该写什么SKILL.md是整个技能包的灵魂它的写法直接决定AI会不会执行、能不能执行好。先说必须有的部分头部要包含一个YAML格式的元信息块至少要写name和description两个字段。name就是这个技能包的唯一标识你可以把它理解成技能在系统中的“镜像名”它需要全局唯一、简短直接不宜频繁变动。description的作用更关键AI引擎通常靠它来判断“当前用户请求和这个技能匹配不匹配”所以description里一定要写清楚触发场景、输入是什么、预期输出是什么。举一个我实际用过的description写法name: meeting-notes description: | 当用户提供原始会议录音转写文本或会议记录草稿时使用此技能。 它会将杂乱的会议内容整理为结构化会议纪要包含结论、决策项、待办事项、风险与阻塞。 输出格式遵循 templates/meeting_template.md。 只有明确涉及会议记录整理的任务才使用不要用于一般性问答。最后一句“只有……才……”这种排除性描述其实是我踩过坑之后才加上的。因为如果你不写清楚适用边界AI经常会把技能误加载到一些毫不相关但表面有点像的任务上比如用户问“怎么组织一场会议”模型可能也会先加载会议纪要技能导致回答跑偏。正文部分才是真正的“方法论”。你不需要在这里写长篇大论的理论而是要写可执行的流程步骤、判断规则、输出要求和质量标准。比如处理会议纪要时正文可以这样写“第一从转写文本中找出所有被明确讨论过并有结论的议题第二为每个议题标注对应的决策项第三提取所有带责任人的待办并标出截止时间第四如果没有责任人默认标注待确认。”这种逐步规则AI执行起来就很有抓手。同时SKILL.md里不该出现的东西也要注意不要写绝对化但无操作性的口号比如“请以专业的方式进行总结”不要放未经整理的大量背景资料这类内容应该丢进references不要写互相矛盾的规则。你要记住这个文件不是给人看的培训PPT是给模型看的操作手册越像一份SOP标准作业程序效果越好。2.3 配套文件不是配角它们决定了产出上限很多新手做技能时只写SKILL.md忽视了templates和references导致的效果是AI确实按流程走了但输出格式五花八门。我用过的最有效的一个增强手段就是在templates里放一个几乎完成度达到70%的填充模板AI只需要往里“填槽”而不是凭空生成结构。模板文件里我会这样设计# 会议纪要{会议名称} - 会议时间{YYYY-MM-DD} - 参会人{逗号分隔} - 记录人{可选} ## 1. 核心结论 {分点列出本次会议达成的明确共识} ## 2. 决策项 | 议题 | 决议内容 | 决策人 | |------|---------|--------| | {议题} | {决议} | {姓名} | ## 3. 待办事项 - [ ] {负责人}{任务描述}截止 {日期}这种模板的价值在于它把“格式”这个变量直接移除了。AI不需要去猜测“决策项写在段落里还是表格里”它只需要按模板把内容填进去。你实际评测时会发现填得越准输出越稳定。同时references里放术语表也很有帮助比如公司内部有“大促”“核心SKU”“履约率”等特定词汇AI如果不知道这些词的含义产出质量必然受限有了参考文档它就能按统一口径来写。3. 手把手创建第一个技能给AI配一个“会议纪要专家”3.1 定义技能目标与触发场景光讲理论不够我决定用一个最典型、效果最容易验证的场景——会议纪要整理把整个流程走一遍。第一步先明确这个技能的目标输入是一段杂乱的会议录音转写文本输出是结构化、可直接同步到项目群里的会议纪要。触发场景要写得非常具体用户在什么情况下会说哪些话才应该触发这个技能。比如“帮我把刚才的会整理一下”“这是会议记录草稿帮我梳理重点”“把这段转写变成纪要”这些都属于清晰触发信号。而“今天开了个会你觉得会议效率怎么提高”这种问题就属于话题相关但任务无关不应该触发。把这个边界写清楚后面能省掉大量误触发排查时间。接着还要定义清楚输入的限制条件如果用户提供的是语音文件而不是文本技能无法直接处理只能在SKILL.md里写“请使用语音转文字工具先行转写再使用本技能”。这一点新手常常忽略——技能不是万能的它处理的是文本不能想当然地以为AI能搞定一切。3.2 编写SKILL.md的过程明确了目标之后我开始编写SKILL.md。这一步要边写边问自己如果是一个新入职的助理拿到这本手册能不能把会议纪要做好我会先写YAML元信息把名称、描述、触发条件整理好然后正文按顺序列出处理流程--- name: meeting-notes description: 处理会议记录整理任务的技能见上文详细触发描述 --- # 会议纪要整理技能 ## 输入要求 - 仅接受纯文本输入。如果是语音文件先转成文字再处理。 ## 处理步骤 1. **通读全文**去除寒暄、口头禅、与主题无关的闲聊。 2. **识别议题**找出所有讨论过且产生了结论或待办的话题按重要性排序。 3. **提炼结论**每个议题下用一句话写明最终结论若存在分歧则分别记录并标注未决。 4. **提取待办**从发言中找出所有“需要有人去做的事”记录负责人、内容、时间点。 5. **标注风险**识别可能影响计划推进的阻塞点或隐患。 6. **按模板输出**使用 templates/meeting_notes_template.md 渲染最终结果。 ## 质量标准 - 结论必须能从原文中找到依据不能凭空推测。 - 待办事项必须有负责人否则标注“待确认”。 - 输出中不能保留口语化的语气词。写这种步骤时有一个非常关键的技巧每个步骤都要做到可验证。比如“识别议题”之后你还要再给一个判断标准——“什么是议题一个话题被至少两人讨论并且有明确结论或后续动作才算一个议题。”有了这个标准AI才不会被“看起来像是议题”的内容带偏。这就是常见的“边界条件缺失”问题补上之后稳定性会明显上升。3.3 用清单把AI的输出稳定在及格线以上完成SKILL.md后我还会在文件夹里放一个检查清单文件。这个清单不一定要给AI读它更重要的作用是给我自己做回归测试。每次改完技能包我会拿同一份原始会议转写跑一遍逐项核对清单上的指标是否将会议中的所有决策项都提取出来待办事项是否都标注了责任人和截止时间输出是否严格遵循模板结构是否遗漏掉了开场确认、风险提示等固定环节为什么要做这一步因为大模型生成的随机性摆在那里哪怕同样的提示词两次输出也可能不一样。检查清单能做得像“物化指标”一样量化评估比如上一版提取出12个决策项改完变成8个那你就要回头查是不是某个步骤写得太收敛了。没有这种回归测试你就永远不知道自己的更改是变好还是变差。顺带说一句如果发现某个步骤总是执行不好与其反复修改文字描述不如直接把“反例”写进步骤里。比如“待办事项中不要出现‘我们之后要考虑一下’这种没有责任人的模糊表述”这种带反例的说明通常比抽象规则有效得多因为模型对具体例子的敏感度远高于对抽象要求的敏感度。3.4 测试与迭代一次没有捷径的苦功夫技能写完后真正的打磨工作才刚刚开始。我会建议至少准备三到五组不同的测试输入覆盖典型场景、边界场景和疑难场景。典型场景是完整但拖沓的会议转写边界场景是特别短的会议记录只有两三句话疑难场景是包含大量行业黑话、多人争论、话题来回跳的转写。每组输入跑完都要用上面的检查清单评估输出。我自己实测下来通常第一个版本只能达到七十分的水平常见问题是提取待办时漏了细节、把没有结论的话题也当成了议题。这时候不用急着推翻重写而是回到SKILL.md里针对性地补充规则。比如连续两次漏掉待办时间点我就会在步骤里加一句“所有带明确日期表述的内容必须原样保留在待办中”。每一次修改后重新跑全部用例看整体收益是否提升。迭代到一定阶段可能会发现有些问题怎么改都无解比如AI在判断“哪些话算结论”上反复横跳。这时候我建议你换个思路不是继续改提示词而是在templates里把该字段设计成“备选项”或者在后处理脚本里做规则兜底。提示词不是万能的学会用结构去兜底是一个成熟做法的标志。4. 让AI真正按技能工作触发、上下文与稳定性调优4.1 触发机制描述写得越像“路口指示牌”AI越不容易走错技能能不能被正确调用第一步就取决于元信息里的description。我见过很多技能包内容写得很好结果没人用得上原因就是description写得像产品说明而不是“路口指示牌”。什么叫路口指示牌就是你站在用户的角度念一句用户会说的话description要能告诉系统“这句话该往哪拐”。所以我在写description时一定会包含三类信息触发词或场景用户提到了什么、输入形态文本、文件、短句、任务类型整理、生成、分析、翻译。同时必须用排除性语言把不匹配的场景切干净。下面这个是我调整后的一个写法示例你可以对比感受一下description: | 当用户提供会议录音转写文本、会议草稿或聊天记录并要求整理为结构化纪要及时使用。 如果用户只是询问“会议怎么开更高效”或要求分析某段文字的情感倾向不要使用本技能。加了最后一句话之后误触发率能下降一大半。这个细节不是我一开始就会的是跑了十几个测试用例之后总结出来的大模型在做技能匹配时对“是”的判断通常比对“否”的判断敏感你不主动告诉它哪里不能走它就很容易自作主张。4.2 模型不按技能走先查描述再查正文最后查模板技能被加载了但AI完全不按流程执行这种情况排在所有排查问题里的第一名。我的排查顺序基本固定先怀疑触发描述再怀疑正文规则最后怀疑模板结构。触发描述的问题在于“加载了但没完全加载”AI可能只读取了一部分技能内容就停止扩展导致后续规则没生效。这种情况通常发生在技能包文件太多、SKILL.md太长的时候。我建议控制SKILL.md的体量原则就是一个技能只解决一件事情正文原则控制在两千字以内其余内容全部拆到references里按需引用。正文规则的问题在于“约束力不够强”。AI对“应该”“建议”“最好”这类词的执行力度远低于“必须”“禁止”“如果……就……”。如果你发现某个步骤总是被跳过试着把措辞改成强约束比如“所有待办必须标注负责人未标注的一律标记为待确认”而不是“尽量标注负责人”。这一字之差效果可能天差地别。模板的问题在于“结构性压制”。如果模板里给出了字段AI通常会优先保证结构完整而非内容准确所以模板字段的设计要和你希望AI关注的重点对齐。比如我特别重视待办事项那么模板里待办部分就不应该只是个普通列表而应该使用表格并明确列出负责人、任务、截止时间三列。结构上的“强调”比任何提示词都管用。4.3 提高技能稳定性的几个关键点少让AI做判断题做了一个月左右的技能包后我最大的心得可以浓缩成一句话**少让AI做判断题多让AI做填空题。**所谓的判断题就是“这段内容里哪些是议题”“这里算不算结论”这种模糊决策模型每次都得出于自己的理解来做选择结果自然不稳定。填空题的意思是你的规则要尽量把“判断”换成“提取”和“映射”。举个例子与其让AI判断“这是不是决策项”不如直接告诉它“在原稿中查找包含‘决定了’‘大家一致认为’‘就按这个来’这些短语的句子标记为决策候选。”这种基于关键词映射的指令虽然看起来有点“笨”稳定性却非常高。另外一个关键点是上下文污染。技能包加载的内容越多AI的输出就越容易偏离。所以references里的文件不要一股脑全放进去可以在SKILL.md中直接指定“仅在处理涉及XX术语时才查询术语表”。如果你用的是支持按需读取的工具型技能框架那更是要主动设计好参考文档的读取时机避免所有内容一起涌进上下文。5. 使用场景与组合玩法从单兵作战到技能库协同5.1 适合被技能化的三类任务不是所有任务都值得做成技能做之前先评估一下值不值。我总结出三类最适合技能化的任务。第一类是高频重复的流程化任务比如每周项目周报、每日舆情摘要、周期性数据通报。因为它们反复出现投入产出比最高。第二类是需要领域知识门槛的任务典型如医疗报告解读、法律文书初审、财务指标分析。这类任务普通人做不好AI没有知识也做不好但如果你把行业知识写进references再配上判断规则AI就能达到相当于一个“有培训经历的新手”的水平。当然专业责任一定还是在人身上技能只是辅助判断。第三类是输出格式要求高度统一的任务比如客户通知邮件、招投标文件初稿、活动复盘报告。这类任务的难点从来不是内容创作而是格式和口径的一致而这也正是Skills最擅长解决的问题。对企业来说把这类任务技能化本质上就是“把优秀员工的输出标准复制给每一个AI辅助的新人”。5.2 多技能协同把大任务拆成“技能链”当任务比较复杂时一个技能往往不够用这时就需要组合多个技能。我举个例子做一份项目月度复盘我先用“会议纪要技能”处理项目例会的转写记录再用“指标分析技能”分析项目核心数据最后用“复盘报告技能”将前面产出的素材汇总成正式文档。在这个组合过程里最重要的机制是技能之间的接口约定。前一个技能的输出格式要能够直接成为下一个技能的输入。所以我在设计“会议纪要技能”时就故意让它输出的每个议题都附带编号和标题而在“复盘报告技能”的规则里我会写“引用议题时使用输入的编号不要重新描述话题”。这样上下游技能就能无缝衔接而不是每个技能各说各话。对Agent架构来说这种多技能协同的设计还能带来额外的可观测性。你可以看到每一步用的是哪个技能消耗了多少上下文产出了什么中间结果比起一个巨大无比的单体技能排查问题要方便太多。我建议从一开始就把技能做成“小粒度、高内聚”而不是等出了问题再拆分。5.3 团队的技能库沉淀像维护代码库一样维护技能技能包在个人手里是效率工具在团队手里就变成了知识资产。我见过一些团队会把技能包集中放在Git仓库里目录结构按业务线划分每个技能包都有明确的负责人和更新记录。新同学入职后不需要反复问“我们写周报有什么格式要求”直接把相关技能交给AI它就能产出符合规范的初稿。这里要提醒一个协作上的坑技能包的改动一定要走评审机制不能一个人觉得“这样写更顺”就随意改。因为你面对的是AI一个规则措辞的调整可能影响所有下游产出。我建议重要技能包至少要有两套测试用例任何修改都必须跑通全部用例才能合并。这听起来很重但对于真正核心的技能来说这是防止“某次更新后整体质量滑坡”的必要保障。技能库的长期维护还需要定期复盘。我自己的习惯是每个月挑几个常用技能做一次“输出质量回看”拿最新的十次真实产出和最初的标准版本对比看有没有出现偏差。如果发现某些新场景没有被现有规则覆盖就补充测试用例再决定是否更新技能内容。这本质上就是给知识做“补丁管理”越早形成习惯技能库越健康。6. 常见问题与排查技巧实录6.1 高频问题速查表实测版为了便于你对照排查我把实际使用中遇到的高频问题整理成了一个速查表。每条都来自真实案例不是纸上谈兵。高频问题常见原因推荐解法技能完全没被触发description里缺少明确触发场景和排除条件重写description加入“当用户……时使用”“如果只是……不要使用”技能加载了但输出完全没按步骤来SKILL.md正文规则太泛形容词多、操作词少把“应该、尽量”改成“必须、禁止”每个步骤加可验证标准输出结构每次都不一样模板缺失或模板字段太笼统提供填充式模板用表格固定字段并给出示例值待办、结论等关键信息频繁遗漏步骤中没给出明确的“识别标准”补充关键词映射规则比如“包含‘决定了’的句子视为决策候选”技能内容太长导致执行走样一个技能里塞了太多子任务拆分成最小粒度技能用多个技能组合完成复杂任务脚本执行报错如果有scripts依赖环境不一致将脚本做成无状态的命令行工具固定Python版本用requirements锁定依赖这张表可以贴在项目文档第一页作为日常排障入口。你会发现绝大多数问题都出在“描述不清”和“规则过泛”这两个源头和模型本身的能力没太大关系。6.2 关于“技能臃肿”的一点心得我最早做技能时有个坏习惯总希望一个技能包能覆盖一个岗位的绝大部分工作结果SKILL.md越写越长references里塞了几十个文档。实际跑下来效果反而很差因为模型一次处理的信息量有限规则一多它就分不清主次经常该执行的没执行不该做的事情反而做了。后来我从软件工程里的“单一职责原则”中借鉴了思路一个技能只解决一个核心问题如果某个任务需要多种能力那就拆成多个技能由Agent在流程中依次调用。到目前为止我维护的最稳定的技能包正文都不超过一千五百字。短小精悍的技能让人感觉“不够全面”但实际上执行可靠性提高了维护成本也直线下降。同时技能包里的每条规则也要定期“断舍离”。我在迭代中经常发现某些当初为了修复一个偶发问题加进去的规则后来模型版本升级后已经没必要存在了或者反而不利于输出。所以每隔一段时间我会刻意删掉部分规则跑一遍回归测试看看是否真的会变差。不试试你永远不会知道自己是不是在“负重前行”。6.3 版本管理给技能包做一条清晰的生命线最后想聊聊version管理这件事。很多刚开始做技能的朋友会觉得这不就是几个文档嘛改起来这么费劲干嘛。但一旦技能开始被团队复用你就会发现“没有版本管理的技能”是一场灾难。今天有人把模板里的一个字段改了明天全组生成的报告都变了形状还没人知道是谁改的。我的做法很简单粗暴所有技能包都进Git仓库每次改动都要通过一次“提交”行为完成提交信息里写清楚改动原因和预期影响。如果一次改动涉及流程步骤的调整我会在CHANGELOG里记一条摘要并同步更新测试用例。这样每个版本都有迹可循出问题可以直接回滚到上一版。整个过程不需要什么复杂工具一个Git仓库加一套测试用例就够了但对长期维护的帮助极大。在我个人的体会里做Skills这件事最有趣的地方不是写技能本身而是你被迫重新梳理自己的工作流程。为了教会AI做一件事你必须把过去凭感觉完成的工作拆解成可复述、可验证、可量化的一二三四步。这个过程本身就足以让你对自己手上的业务重新做出更清醒的判断。如果你现在正被某类频繁重复的任务折磨不妨从把它打包成一个技能开始——先定触发边界、再写步骤、最后配个模板跑完十次真实用例再谈优化。你可能会发现那些最让你头疼的琐碎工作反倒是最值得被“手册化”的东西。