先聊点实际的。最近这一轮AI Agent的玩法逐渐变深圈子里冒出来一个高频词skill。不管是codex skill、Claude Code skill还是Trae、OpenClaw这类工具里的skill插件本质都是同一件事——把某个领域里可复用的经验、流程、判断标准打包成一个AI能直接调用的“能力模块”。很多人第一次接触skill时的反应是这不就是写提示词吗一开始我也这么想直到自己动手做了十几个skill、又帮团队梳理过一整批之后才反应过来提示词只是skill的表皮真正决定一个skill好不好用的是背后那套“方法抽象”的功夫。这篇文章想把我在实际创建skill过程中沉淀下来的完整流程摊开来讲从选题、拆解、结构化、用例设计一直到末尾那份Review清单。它适合正在做Agent开发的人也适合产品经理、运维、测试这些想把重复劳动固化下来的角色。只要你手里有一类高频、有规律、做过不止一次的任务就可以照着这套方法产出一个像样的skill。而且这篇流程不挑工具不管你是给Copilot写prompt还是给Claude Code写SKILL.md或者在一个通用Agent平台里配技能逻辑都通用。1. 内容整体设计与思路拆解先把“skill到底是什么”这件事说透。在和团队配合的时候经常有人问skill和普通提示词模板、和Agent本身到底有什么边界我习惯用一个做饭的类比来解释Agent是厨师本人LLM是灶台和锅skill则是一本菜谱——它不负责决定今晚要不要做饭那是用户的目标也不负责实际颠勺那是模型推理干的事它提供的是做一道菜时所需要的原料清单、火候曲线、翻车预案。没有菜谱厨师凭经验也能烧但出品不稳有了菜谱哪怕换个帮厨做出来的味道也在可控范围。所以一个真正合格的skill应该包含几个固定的层次触发条件/适用范围什么场景下应该调用这个skill什么场景下不该用。执行流程完成这类任务的标准步骤顺序本身就能体现经验。决策规则分支判断、质量阈值、取舍标准。输入输出约定接收什么格式的信息产出什么结构的交付物。边界与兜底遇到未知情况怎么办失败之后如何回退。这个分层模型跟我做项目管理方法论时的那套“流程模板检查单”的思路几乎是同构的。你会发现凡是想清楚过方法论的人再看skill设计会非常轻松因为两者本质上都是在做知识的结构化封装。1.1 为什么“方法抽象”决定了skill的上限说句可能得罪人的话市面上八成以上的skill其实是“伪skill”。它们不过是把一两条提示词包装了一下起了个唬人的名称本质上仍然是一个“识别意图→套模板输出”的薄壳。这类skill在demo里看着很惊艳一旦放到真实工作流里就露馅——因为真实任务永远有各种细节偏斜薄壳skill一遇到偏斜就断。真正能扛住实战的skill必须做“方法抽象”。这句话的意思是你要从过去做过的N次同类任务里把那些真正可迁移的模式提炼出来而不是把某一次具体的操作过程录下来。再打个比方——如果让你做一个“写周报”的skill低级的做法是把某个人上周的周报当成模板高级的做法是抽象出周报的“要素结构”本周重点、数据变化、风险与求助、下周计划、所需资源。前者换个人、换个项目就废掉后者放到哪个团队都能用这就是抽象的作用。方法抽象在实践里分三步第一反刍过去的案例把任务从头到尾拆成步骤第二每个步骤问一句“这一步能不能换一种做法换了之后目标变不变”能换的就是可变项不能换的就是不变项第三步把不变项固化成主流程把可变项变成配置项或分支选项。这套思路做完你的skill才谈得上“可复用”而不是“可演示”。1.2 不是所有任务都适合做成skill必须泼一盆冷水不是所有任务都值得做成skill。做这件事之前先做一道判断题能省下后面大量维护成本。用三个标准来筛。第一个是频率这个任务是不是你或者你的团队每周都会做至少一次低频任务做skill基本是负收益因为写skill要花时间维护要花时间用的时候还要花时间校验输出对不对低频任务的成本根本摊不回来。第二个是确定性任务的执行路径是不是有相对固定的章法比如“分析一份日志并定位报错原因”就比“构思一个营销创意”更适合做skill因为前者有明确的分析路径后者本质上吃灵感和语境。第三个是容错率任务做砸了是否需要付出很高代价如果这个任务是“生成季度财报分录”那我不建议新手一上来就拿它练手而是建议先在低风险任务上跑通流程。如果你手上正好有一个任务三条都满足冷静一下别急着动手写。先做下一件事——把Review清单找出来对照着看自己有没有想清楚。2. 核心细节解析与实操要点到了真正动手的阶段很多人的第一反应是打开编辑器直接写。我建议你忍一忍。直接写的坏处是你会顺着“线性思维”把skill写成一个长长的步骤序列但真实的专家经验往往是树状的、带分支判断的直接写会丢失那些“如果……就……否则……”的暗知识。所以我的实操顺序是先画清楚任务的“决策树”再落成“文档结构”最后才动笔写正文。这一步不用画得很复杂就用缩进列表或者思维导图工具把分支列出来就行。以“日志分析skill”为例它的决策树大概长这样拿到日志文件第一步确认日志类型应用日志/系统日志/网络日志应用日志 → 检查框架版本与依赖系统日志 → 检查资源水位网络日志 → 检查连接与超时第二步提取异常特征关键词、频率、时间点第三步匹配已知错误库匹配成功 → 输出根因与修复建议匹配失败 → 进入通用排查流程第四步输出报告画完这棵树再落成文档逻辑就顺了。下面我把每一步的实操要点拆开讲。2.1 定义触发条件让该用的地方想起来用skill用不起来的第一大原因该触发的时候想不起来。很多Agent平台本身有自动触发机制但更多场景是半自动的——用户需要一个入口或一段描述让模型在合适的时机主动提出“这个任务我可以调用XX skill来高效完成”。定义触发条件时至少要写清楚三件事。第一任务的典型句式比如用户说“帮我看看这批日志”“分析一下报错”“检查一下昨天的运行情况”这些都是触发信号第二任务的目标物比如“日志文件”“导出表”“API返回结果”让模型知道对什么类型的数据生效第三非触发场景这块特别重要比如“用户只是想闲聊某个技术话题”就不要触发“日志分析skill”避免模型自作聪明。我用过一个笨办法把这份skill曾经适配过的真实场景写成三五条“使用样例”直接贴在skill文档开头。模型在推理时会把这个当成few-shot示例触发准确率会明显提高。这比单纯写一句“适用于日志分析场景”有效得多。2.2 设计执行流程按“输入→处理→输出”三段组织执行流程是skill的心脏也是最容易写得稀烂的部分。我见过大量skill在这里犯同一个毛病流程写成了一本流水账不分主次也没有漏斗模型读完之后还是不知道每一步要做到什么标准。我的建议是把流程拆成三段输入段、处理段、输出段每一段里只保留“判断”和“动作”两类节点。输入段要定义清楚这个skill需要哪些前置信息如果没有完整信息怎么办是向用户追问还是基于默认值运行我强烈建议在输入段做一个“信息缺口检查”——把必填项和选填项列出来缺了必填项就停下来问不要带着残缺信息硬跑。这一步能极大提升输出质量因为很多模型翻车是从一开始就理解错了输入。处理段是核心要写清楚每一步的目标、输入、产出以及质量标线。比如“识别日志中的时间窗口”这一步质量标线是“必须精确到秒级并标注时区”“匹配错误库”这一步质量标线是“匹配置信度低于60%时不要强行给结论改为列出可能性列表”。把质量标线写进每一步模型在执行时的“自我要求”会明确非常多。输出段要约定交付物结构。例如日志分析skill的输出应该包含异常总览、根因推断、影响范围、修复建议、参考证据。结构越明确后续跨团队协作越顺畅因为每个读报告的人都知道去哪一段找什么信息。输出段还要写“坏输出长什么样”比如“不要只给一句话结论”“不要在没有证据的情况下给修复建议”负面样例和正面样例一样重要。2.3 建立决策规则把暗藏的判断经验显性化老手和新手最大的差距在于面对不确定情况时的判断力。在做skill的时候这一步的价值就体现出来了。我平时会把自己做任务时的“内心独白”录下来——当然不是真的录音而是边做边记这个地方我为什么这么判断是什么信号让我倾向方案A而不是方案B这招很实用因为人的判断很多时候是瞬发的不刻意记录根本想不起自己有过哪些判断。把这些判断用“如果……那么……”的句式整理出来就是skill的决策规则集。比如如果日志中同时出现OOM和CPU飙升优先排查内存配置而非扩容。如果错误码只在特定时段出现考虑定时任务或批处理叠加造成的资源竞争。如果同一个错误反复出现在不同服务里先查公共依赖层。每一条决策规则都是你个人或团队经验的一次固化。规则数量不求多但求有区分度——写出那些“大多数新手不知道、知道了就少走弯路”的判断才是有价值的。2.4 配置兜底与恢复接受会失败这件事模型执行任务一定会有偏差这是命躲不开。所以skill设计里要给“失败预案”留位置。兜底策略通常包含两层。第一层是执行中的校验每一步执行完做一个“自检动作”比如日志分析skill可以要求模型输出前检查“根因推断是否引用了日志中的原句”如果没引用就回头补充。这个校验逻辑相当于给模型加了一道保险丝。第二层是执行后的回退机制如果最终产出被用户判定为不合格skill要定义好“降级方案”——从哪里开始重新执行哪些步骤可以有替代路径有没有备用工具另外我特别建议在skill里加一个“信息不足时的动作”当模型发现自己拿到的信息不足以高质量完成任务时模板化的做法是列出一个“待补充信息清单”让用户逐项确认后再继续。这比硬着头皮编一个答案要专业得多。用户不会因为你追问而不耐烦但一定会因为你瞎编而失去信任。3. 实操过程与核心环节实现前面讲了不少理念这一节我们进入实操。我用一个来自身边的真实场景串联全流程为软件项目管理团队创建一个“项目周报生成skill”。这个例子足够典型——周报任务频率高、结构性强、模板稳定非常适合用来演示方法抽象。3.1 从零到一一个真实skill的完整诞生过程这个skill的目标是输入一个项目的原始信息本周完成事项、待办变化、风险登记、下周计划等输出一份格式统一、重点突出、可直接发到群里的项目周报。第一步收集原始素材。我先把团队最近两个月的历史周报全部翻出来一共40多份然后做了一件事——把每份周报拆成“段落级别”的碎片统计哪些段落是每次必出现的哪些是偶尔才出现的。统计结果非常有意思必出现的段落是“本周进展”“下周计划”“风险与求助”偶尔出现的是“数据变更”“版本发布记录”“成员动态”。这说明周报的“不变项”是前三个段落“可变项”是后几个。第二步识别步骤链。我观察团队成员写周报时的实际动作顺序先汇总本周提测/发布/上线的功能再对照项目计划找有没有延期项然后筛风险和求助最后整理下周排期。这个顺序本身就包含了经验——先给结果、再讲偏差、最后说需求符合管理者的阅读习惯。第三步找决策点。写周报的过程中什么环节最考验判断力当团队里同时发生五六件事时怎么判断哪三件写进“本周进展”我追问了一圈老同事总结出两条隐性规则一是“跟里程碑强相关的事件优先写”二是“对外有可见影响的变更必须写”。这两个判断直接被我固化成了决策规则。第四步设计输出模板。基于前面的抽象输出模板被定义为本周整体评估一段话总结定调关键进展最多三条每条包含“做了什么结果是什么”风险与求助按P0/P1/P2分级下周计划按优先级排序到这一步skill的骨架已经清晰了。剩下的工作就是把它写成文档并配上一个输入模板让用户按照“项目名、里程碑、本周事件列表、风险列表”的格式提供原始信息。3.2 skill文档的Markdown模板框架下面给出一份可直接套用的skill主体结构我在写不同领域的skill时基本都用这套框架。注意不同平台对skill文件格式的要求略有差异比如Claude Code会强调SKILL.md的规范性codex则更看重描述和运行方式这里给出的是通用骨架--- name: 技能名称 description: 用一句话描述该技能的能力和适用场景包含触发关键词 --- # 技能名称 ## 适用场景 - 场景A、场景B、场景C - 不适用场景场景D ## 输入要求 - 必填项…… - 选填项…… - 信息缺口处理方式缺少必填信息时先询问再执行 ## 执行流程 1. 步骤一目标质量标准 2. 步骤二目标质量标准 3. 步骤三目标质量标准 ## 决策规则 - 如果……那么…… - 如果……那么…… ## 输出格式 - 交付物结构 - 正面样例 - 负面样例 ## 兜底方案 - 执行中自检动作 - 失败时降级路径这个模板的精髓不在于框架本身而在于每一节都有“质量标准”和“样例”把抽象要求全部具体化了。如果你在写某个新skill时觉得某些节点写不出样例通常说明你对这类任务的理解还不够深需要再补功课。3.3 用真实数据做一轮完整测试写完初稿必须做真实数据测试而且要用“你没见过的新数据”不要拿当初用来提炼skill的那批历史数据测试——那样测出来的都是假阳性。我接手过的教训太多了有个同事写了一个“会议纪要skill”用自己以前开的六场会做测试效果惊艳一放到新会议上就翻车原因就是那个skill死记了他旧会议的发言顺序和废话率抽象程度根本不够。真实测试时我会这样操作找三个历史上完全没有被用于提炼的样本逐个测试测试时要求模型输出中间过程而不仅仅给最终结果每测完一个样本认真记下哪里偏离了预期。测完一轮后我会对着偏差清单回到文档里改决策规则或补充约束条件。这个过程一般要跑两三轮skill才敢说达到了“可发布”状态。就我这个周报skill的实测情况来说第一轮跑出了两个典型问题。第一个问题是模型把“下周计划”写得太泛比如“推进项目进度”这种正确的废话我在决策规则里补了一条——下周计划必须有动词、有对象、有预期结果比如“完成支付模块联调输出测试报告”。第二个问题是模型对风险的判断偏轻经常把P1写成P2我加了一个分级判定标准定义了什么才算“影响上线”什么才算“需要求助”。这就是为什么一定要拿真实数据跑测试靠想象根本发现不了这些问题。4. 常见问题与排查技巧实录做skill这件事说难也难说不难也不难但有几个问题我几乎在每次评审别人的skill时都能遇到。整理成一份问题实录按出现频率排个序。4.1 “这个skill到底该写多长”这是被问得最多的问题。太长模型加载后占用大量上下文窗口反而干扰主任务的推理太短指导力不足跟没有skill没什么区别。我个人的经验法则分支少的任务300到600字足够分支多的任务控制在1500字以内。超过1500字建议拆成多个skill而不是堆成一个巨型skill。还有个细节skill文档的首页前100字极其重要。很多平台的模型会先读这一段来判断要不要使用这个skill所以开头要写清楚这个skill是干什么的、擅长什么、不擅长什么帮助模型快速决策。不要把关键定义埋在文档深处那等于没有。4.2 写好的skill经常“用不出来”或“被错误触发”这个问题一半跟触发描述有关一半跟决策规则有关。触发描述写得太窄模型遇到类似任务但换了表达方式就认不出来写得太宽什么任务都往这个skill上靠错误触发频发。处理办法是给触发描述建立“正例负例”两层。正例写三到五种典型说法负例写一两种表面相似但实际不是该技能任务的说法。举个例子日志分析skill的正例是“帮我看下这个log文件”“这个报错怎么回事”负例是“帮我写一段产生这个报错的代码”——后者是在生成代码不是在分析日志。4.3 输出效果不稳定时好时坏大多数情况下不稳定不是模型的问题而是skill文档里“质量标线”不够明确。举个例子如果你只写“输出一份周报”模型每次输出的宽松度会漂移但如果你写下“关键进展必须包含数字、风险必须标明等级、每条不超过50字”输出的方差就会急剧下降。模型需要的是边界清晰的“好”和“不够好”之间的分界不是模糊的“努力写”。如果加了标线还是漂移就要检查是不是某些决策规则相互冲突。我曾在一个“客户投诉回复skill”里同时写了“语气诚恳”和“不承认我方责任”模型在这种隐性冲突下输出就会左右摇摆。解决办法是增加优先级说明当两条规则冲突时以哪条为准。4.4 快速Review清单发布前逐项核对最后把这份我做skill时必用的Review清单完整放出来你能直接复制到自己的流程里。每一条都是我踩过坑之后沉淀下来的检查点需求定义这个skill解决的具体问题是否一句话能说清是否有明确的目标用户和典型使用场景是否与已有技能存在边界重叠是否需要合并或区分流程设计执行流程是否按输入→处理→输出来组织每一步是否有明确目标和质量标线是否包含分支条件与对应处理方案是否包含信息不完整时的询问机制方法抽象步骤是否是从多个案例中提炼的通用路径而非某一次任务的复刻决策规则是否是大多数人不知道的隐性经验输出模板是否具有跨场景复用性文档质量描述区是否清晰说明适用范围与限制是否包含正面样例和负面样例正文长度是否控制在合理范围没有大量冗余测试与维护是否用未参与提炼的新数据进行过至少一轮测试是否记录了测试中发现的偏差并迭代修正是否明确标注了技能当前适用的版本范围比如适用于哪类Agent平台、哪个模型版本这份清单不复杂但能拦住绝大部分“半成品skill”。我每次写完一个skill都会让清单“过”一遍再发布。刚开始做这件事的时候每次都至少能挑出一两个问题做到后来真正需要改的地方越来越少因为很多检查点已经内化成了写作习惯。这个内容后续还可以这样扩展等skill积累到十几个之后可以开始给同类skill做“家族化设计”把公共的输入清洗规则、错误分级标准、输出样式抽出来做共享模块再往后还可以把skill的撰写流程本身再抽象一层做成一个“meta-skill”专门用来批量孵化新skill。我自己就在往这个方向走毕竟干这行的都知道能把自己“做东西的方法”再做成一个东西才是真正的复利。