在 AI Agent 和编程助手被越来越多人当“日常工具”用的今天最尴尬的其实不是工具不够强而是同一个问题你反复教它它每次都像第一次听。今天想聊的就是怎么用一套方法论把“临时教一次”变成“永久会”——也就是高效创建 skill 的完整流程以及我每次发版前都会过一遍的 Review 清单。这篇东西适合两类人一类是被各种 skill 模板搞晕的新手手里捏着一堆 Prompt 却不知道怎么提炼成技能包另一类是已经写了十几个 skill 但总觉得“能用但不好用”的进阶玩家想把自己的作坊式写法升级成一套可复用的流程。我见过太多人把 skill 当成“一个更长的 Prompt”来写这其实是最大的误解。skill 的核心价值不在于字数多、指令细而在于它能不能把一次性的、情境绑定的“做法”抽象成通用的“能力”。今天这篇我会从方法抽象的原理讲起给出一套可以直接照抄的六阶段流程再用一个日志分析 skill 的实例完整走一遍最后把 Review 清单直接列出来给你用。1. 先理解一件事skill 不是“写出来的”是“抽象出来的”1.1 skill 与 agent 的区别能力包与执行者的关系要理解 skill 的创建方法先得把“skill 和 agent 到底什么关系”这件事掰扯清楚。Skill 和 Agent 经常被并列提起但它们的定位完全不同。Agent 是一个能自主决策、调用工具、分步执行任务的执行者而 skill 是它“大脑里的一块预装知识包”让它在遇到特定场景时能直接调用成熟的处理方式而不是每次从零开始瞎试。做一个不太严谨但很好用的类比Agent 像一个刚入职的聪明新人学习能力强但经验少skill 则是你给他的“标准化作业手册”。新人有了手册不用每次都问“这事该走什么流程”直接照着手册执行就好。反过来如果只有 Agent 没有 skill就会出现最让人抓狂的情况——同一个问题你上周教会它了这周换了种问法它又不会了。所以 skill 存在的根本目的是把经验从“对话上下文”里抽出来变成“可沉淀、可复用、可分享”的独立资产。这个区别决定了你想问题的角度。写 skill 的时候你不是在“给机器人写一段话”你是在“把一类问题的解法固化成可执行的知识”。想通了这一点整个流程的重心就会从“怎么把 Prompt 写得更长更细”转向“怎么把经验抽象得更准更稳”。1.2 方法抽象把一次性的“做法”变成可复用的“能力”“方法抽象”这四个字是创建 skill 的核心动作。听起来玄乎其实你在生活里天天都在做。比如你第一次做红烧肉是照着菜谱一步步来的油温、糖色、火候都写得清清楚楚做多了之后你脑子里会自动浓缩成一句话——“炒糖色别过头冒小泡就下肉”。这就是一次成功的方法抽象把一堆具体的操作细节提炼成能迁移到下次做菜的经验判断。skill 里的方法抽象也是一样。它要做的是从大量的、具体的“解题过程”里抽出三个关键东西稳定的处理流程、关键判断标准、常见坑和应对方式。举个例子很多人第一次写“代码 Review Skill”时会把指令写成“请帮我 Review 这段代码”然后等 AI 自由发挥。结果它有时只检查格式有时只盯着命名质量极不稳定。但如果你做过几次 Review把过程中的共同动作抽出来——先看业务逻辑是否正确、再看异常处理是否覆盖、然后看是否有安全隐患、最后才是风格问题——把它固定成流程再把每个环节的检查要点写清楚这个 skill 就立住了。我自己判断一次抽象是否成功就一个标准换个完全不同的具体问题这个 skill 还能不能给出同等质量的处理结果。能说明你抽象到位了不能说明你只是在记录某一次对话而不是在做能力封装。1.3 抽象到什么程度才算够做抽象不是越通用越好这是很多人容易走极端的地方。你如果写一个“万能分析 skill”什么都能做最后的结果就是什么都做不精AI 的输出跟没有 skill 时没有任何区别。抽象的原则应该是足够覆盖一类场景但不足以模糊到失去判断力。我给你个非常实际的判断方法把 skill 的处理对象往前推一步。如果你的 skill 名叫“文案改写”那太宽了——新闻、营销、学术、口语这四类文案的改法天差地别AI 拿到你的 skill 后还是要猜。但如果你把 skill 定位成“产品卖点文案改写”那抽象程度就刚刚好。它有明确的输入产品资料、固定的处理逻辑卖点提炼-场景匹配-语言打磨、可预期的输出营销文案但又不局限于某一个具体产品。这里有个临界点要自己把握当你的 skill 里出现超过三处“如果场景是……则……否则……”的条件分支时说明你可能把两三个不同场景硬塞进了一个 skill。这时候应该拆开而不是继续往里加规则。我在实践中反复踩这个坑最开始的版本什么都想管结果 Review 清单越来越长改一条规则就要通读全文。拆开之后每个 skill 都轻了一倍准确率反而上去了。2. 高效创建 skill 的六个阶段2.1 需求挖掘别从“要什么”开始从“烦什么”开始很多人创建 skill 的第一步是“我要让 AI 帮我做 PPT”于是立刻去写 Prompt。这个起点就错了。高效流程的第一步是先搞清楚你到底在为什么事情烦。需求挖掘的要诀是从痛感出发而不是从功能出发。我给你一个我自己常用的提问模板最近一个月你在哪类事情上重复花过三次以上时间做完之后是不是觉得“这次跟上次没什么区别就是又走了一遍流程”如果有这就是 skill 的候选场景。常见的例子包括每次都要让 AI 按固定格式输出周报、每次都花半小时教它你们的命名规范、每次都要把日志贴进去让它分析但是格式老是乱。这个阶段的关键是“不设限地记录”。拿个本子手机都行把那些“AI 看起来会但做不好”“每次都差不多的重复劳动”全列出来哪怕只是模糊的感觉。记录之后不要急着选等攒够了十个左右再统一筛选。筛选标准很简单这件事是否高频、是否套路固定、痛感是否强烈。三项都满足的就是值得做成 skill 的高优先级项目。2.2 场景还原把“感觉”变成“素材”选中目标场景之后先别动手写。你需要做一次双人对话式的“场景还原”——你自己扮演使用者把最近一次真实操作的全过程一步一步写下来。这个步骤极其枯燥但无数人跳过它之后都回来补课了。怎么还原我给你一个框架。第一写清触发条件什么情况下你会需要这个 skill是收到一封邮件、一个报错、还是一堆原始数据第二写清操作对象你要处理的输入长什么样格式是什么有没有常见的脏数据或异常情况第三写清处理步骤你正常是怎么一步步解决的每一步的判断依据是什么第四写清完成标准做到什么程度你觉得可以收工了哪些东西是你绝对不能接受的比如你想做一个“会议纪要 skill”场景还原要细到这个程度输入是几段语音转文字里面可能有人名、语言混乱、多人插话你的处理步骤是先还原讨论主线、再提炼决策、最后单独列待办完成标准是每件事都能追到人不能出现“相关同事跟进”这种模糊表述。这些素材就是后面写 skill 规则时的原始矿料。2.3 抽象建模输入、输出、边界、判据素材备好之后开始真正的核心工作——抽象建模。这一步就是把 2.2 里那些血淋淋的实素材提炼成四个维度的定义输入定义、输出定义、边界定义、判据定义。输入定义考虑的是skill 能接受哪些输入不能接受哪些输入出现什么情况应该直接拒绝而不是硬着头皮处理。输出定义考虑的是产出物的结构、格式、风格、长度限制。边界定义回答的是哪些情况归这个 skill 管哪些情况应该提示用户换其他方式。判据定义考虑的是AI 在什么情况下可以做决策什么情况下必须停下来问用户。很多人不爱做这一步觉得太抽象、不如直接写 Prompt 爽。但这一步恰恰是决定 skill 质量的分水岭。我做过一个对比测试同一个任务用“直接把解决方法写成 Prompt”和“先建模再写 Prompt”两种方式实现在十几个测试用例上的平均准确率差了将近三成。因为建模会逼你把话说清楚而直接写 Prompt 通常只是想一句写一句逻辑漏洞特别多。2.4 结构化表达把模型变成 AI 能执行的指令模型建完之后终于到了大多数人以为的“写作”环节——结构化表达。Skill 文件该怎么组织现在主流做法已经相对成熟了核心是一份 SKILL.md里面按顺序写清楚技能描述、使用场景、工作流程、规则约束、示例参考。有些工具还支持拆多个文件比如把长规则放 details 文件把示例单独放 examples 目录主文件只放索引和核心逻辑。这个阶段我最重要的心得是用“流程”和“规则”两类内容组织整个 skill而不是用“描述”。流程是 AI 遇到问题之后按什么顺序干活规则是干活过程中必须遵守的底线。比如一个“SQL 优化 skill”流程是先拿到慢查询语句和表结构、分析执行计划、定位瓶颈、给出优化方案、最后提供验证脚本。规则是不能直接改生产库、不能只看一条语句就下结论、给出的每条优化建议必须带原理说明。另外写示例的时候别只写完美案例。刻意写一到两个“不完美输入”的处理示例对提升 skill 的鲁棒性帮助特别大。AI 在 few-shot 场景下特别容易模仿示例的模式你给它喂了“输入-处理-输出”齐全的正面例子之后它遇到类似输入时表现会稳定很多。2.5 最小验证用一条真实任务跑通不管模型建得多完美、指令写得多漂亮不跑通的 skill 都只是纸面功夫。最小验证的意思是拿到你要做的那个原始痛点里最典型的一条真实数据立刻让 skill 跑一遍看输出能不能达到“勉强可用”的水平。这里有个心态陷阱我必须提醒你第一版跑出来的结果一定不会太好这是正常的。最小验证的目标不是“一次成功”而是“暴露问题”。你就把自己当成一个挑剔的用户逐条检查它的输出流程走完了吗有没有漏环节输出格式符合定义吗有没有在判据不明确时瞎猜验证的结果通常会是三种通过可以直接迭代优化、部分通过有明确改进点、完全不通过说明抽象方向就错了。如果是第三种别急着改细节回头检查一下 2.3 的建模大概率是输入输出定义或者判据定义出了问题。2.6 迭代打磨让失败案例驱动更新Skill 完成初版并跑通之后真正的打磨才刚开始。我用过的所有 skill都是靠“失败案例驱动”迭代出来的。所谓失败案例就是用户包括你自己在实际使用中遇到的、skill 处理得不好的输入。我的迭代流程是固定的一套第一每发现一个失败案例先不急着改把它原样存档第二攒够三五个失败案例之后统一分析它们的共同模式——是两个案例都因为同一个模糊判断导致失误还是分别暴露了不同环节的漏洞第三针对共同模式修改规则或增加示例第四用同一个 skill 跑一遍全部历史案例既包括失败案例也包括以前跑通的正例确保修旧没破新。这个方法看着笨但实际操作下来非常稳。它其实就是在做回归测试而且用的是真实世界的数据比你自己脑补的测试数据可靠得多。长期迭代下来skill 会越来越像你亲自干活的风格而不是一个越来越长的规则堆。3. 实例拆解从“日志分析”到“日志分析 skill”3.1 初始需求与痛点为了把上面的流程串起来我用一个真实案例完整走一遍。场景是日志分析。做过线上问题排查的人都懂出了线上事故第一件事就是捞日志但日志一多就眼花十几个服务、几百行报错、时间线完全对不上人肉翻日志能翻到怀疑人生。我最初的痛感很明确每次都要把日志贴给 AI然后反复嘱咐“先按时间排序”“把 ERROR 和 WARN 分开”“看看异常的堆栈有没有共性”“最后给我一个排查建议”。操作一多AI 的回复就开始飘有时候分析方向跑偏有时候给的建议太宽泛。这种“每次都要重新教一遍”的挫败感正是最好的 skill 触发信号。3.2 抽象过程详解决定做这个 skill 之后我按流程走到抽象建模这一步。输入定义标准格式的日志片段最好带时间戳、日志级别、来源模块额外的系统信息可以追加在末尾如果输入完全不符合要求让 AI 先请用户整理。输出定义按“时间线还原-错误分类-根因推测-排查建议”四段结构输出每段控制长度结论优先证据随后。边界定义也遇到了值得说的事。一开始它什么日志都接后来我发现前端浏览器日志和后端服务日志的分析方法完全不同硬凑在一起只会互相干扰。于是拆成两个 skill。这种“拆”的判断就是在边界定义环节做出来的。判据定义是当错误类型超过五种或者日志量超过 200 行时不要逐条分析先让 AI 做聚类统计避免陷入细节出不来。3.3 落地实现与测试建模完成后SKILL.md 我是这样组织的开头一段技能描述说明这个 skill 给谁用什么场景用然后加上使用前提要求日志片段完整、格式尽量保留原始核心部分分两条线一条是按时间线还原的流程一条是错误分类与根因推测的规则最后给一个标准的输出模板作为示例。第一轮最小验证我选了一条真实事故日志包含大约 60 行 ERROR 和 30 行 WARN涉及三个微服务。跑出来的结果时间线还原不错错误分类也到位但根因推测明显过度发挥了——它根据一个超时错误就推测是数据库连接池耗尽实际上那次事故的根因是某个下游接口被限流。这就是我在 2.5 说的情况流程没问题但判据定义不够没有让 AI 先收集足够证据再下结论。3.4 迭代记录针对那次失败我调整了判据要求 AI 在根因推测前必须先列出至少三条支持证据证据不足时只能给“候选方向”不能给确定结论。同时加了一条反例规则禁止在没有全链路时间数据的情况下断言具体服务。这个改动之后同样一条日志再跑输出从“可能数据库连接池耗尽”变成了“观察到与 B 服务的交互超时候选方向包括限流与网络波动建议进一步查看 B 服务的入口日志”。这个收敛幅度非常大而且整个调节过程只花了半小时。这件事也给了我一个很深的感受skill 的每一次迭代本质上都是在把“AI 不该犯的蠢错”变成一条明确的规则每多一条规则它就离“像你”更近一步。4. Review 清单发布前逐项自查4.1 清单总览以下这份 Review 清单是我每次发布 skill 前都会逐项过的。它不针对某个具体工具适用于 Claude Code、Codex、Cursor以及各种支持自定义技能的框架。打印出来或者放个浏览器书签每次写完 skill 对着它过一遍能少踩很多坑。序号检查项通过标准1场景聚焦度skill 只负责一类场景没有包含多个互不相关的任务2输入边界清晰明确写了能接受什么输入、不能接受什么输入3输出格式固化输出结构、长度、风格有明确约束不是让 AI 自由发挥4流程有兜底遇到不符合输入边界的情况有明确的拒绝或提示逻辑5判据不模糊所有可能触发 AI 自行判断的地方都有明确的判断标准6示例覆盖充分至少有一个完整示例最好覆盖一个边界或不完美输入7规则去重没有两条规则在说同一件事没有互相冲突的指令8失败案例存档至少用三条历史真实输入跑过失败案例已记录并处理9不依赖特定上下文单独给一个陌生用户使用也能给出预期效果10回归验证通过修改后所有历史正例依然运行良好没有引入新问题4.2 每一项为什么重要清单里的每一项都不是凑数的我把几个最容易被忽视的展开说说。第 2 项输入边界很多人懒得写觉得 AI 自己会理解。实际上一旦你不写清楚AI 在收到垃圾输入时就会硬着头皮处理然后输出一份看似合理但完全错误的结果比你直接告诉它“数据不对重新给”危害更大。第 5 项判据不模糊是我认为整个清单里技术含量最高的一条。所谓判据就是 AI 做某个判断时需要满足的条件。你写“如果日志量太大就聚类分析”这就不够清晰——多大算大200 行还是 2000 行写“超过 200 行日志时先聚类再挑选代表条目深入分析”才算合格。第 6 项示例覆盖最常见的错误是只写漂亮的标准输入示例从来不写脏数据。但真实使用里输入哪有不脏的第 9 项不依赖特定上下文是最能验证 skill 是否真正可靠的一条。你自己写 skill 的时候潜意识里已经把背景信息填齐了AI 在你的对话里待久了也会被“喂饱”看起来特别聪明。但换个新对话、新用户背景信息一断它就原形毕露。所以每次写完之后我习惯开一个全新会话用最干巴巴的输入去测看看它能不能靠 skill 自己站稳。4.3 如何建立自己的 Review 习惯清单是死的关键是养成过清单的习惯。我的做法是把 Review 清单嵌进版本更新的每个节点而不是最后发布前才看。具体来说分三个节点初版完成后过一遍重点看 1 到 6迭代修补后过一遍重点看 7 到 10准备分享给团队或开源前再过一遍全部 10 项。还有一个小技巧每次发布新版本时顺手在 skill 文件末尾加一个“CHANGELOG”区记录这版改了什么、基于哪个失败案例。别小看这个习惯三个月之后再回头看你会惊异于自己当时的判断有多粗糙也会更清楚技能是怎么一步步长成今天这个模样的。这个 CHANGELOG 除了帮你追踪演进还能在未来训练新模型、迁移工具链时提供大量一手素材。5. 常见问题与踩坑实录5.1 五个高频问题速查表问题典型表现解决方法写了太多规则 AI 反而变笨指令越来越多输出越来越僵硬把互斥的场景拆成独立 skill精简规则保留判断标准换个问法 skill 就不起作用表现极其不稳定在 SKILL.md 里明确写“触发词”和“场景描述”不要依赖单一表达形式输出时好时坏方差很大同一条输入跑两次结果不一样检查输出模板示例是否足够完整把关键判断从“自由发挥”改成“按规则填写”跟 Agent 的默认能力冲突skill 偶尔生效偶尔不生效在 skill 开头用明确指令声明优先级或调整 Agent 的中枢路由配置改了一处规则全盘崩坏修好旧问题引入新问题建立历史用例集合每次修改后全量回归上面这些问题前三个是新手重灾区后两个是进阶玩家也容易栽跟头的。尤其最后一个“改一处崩全局”几乎每个人迭代 skill 到中后期都会遇到。根治办法就是我在 2.6 里说的回归测试没有别的捷径。5.2 三个独家心得心得一写 skill 的最高境界是“让 AI 少猜”。每一次你写下一条含糊规则AI 就会在生成时用它的语言模型帮你“猜”一下十次猜测里总有两三次是歪的。反过来每条规则写得像测试用例一样可验证整个输出质量就会指数级提高。所谓“好 skill”本质上是把不确定性尽可能排除掉。心得二SKILL.md 里的描述性文字要克制不要写“本技能旨在帮助用户提高效率”这种废话。AI 不会因为你的描述感人就输出得更好它只会根据流程、规则、示例来行动。文件开头留一两句场景说明就够了剩下全部是可直接执行的逻辑。心得三把自己当成历史上最挑剔的甲方去验收。每次跑完测试都要问自己“这个输出我敢不敢直接发给别人看说是我的水平”不敢就回去改。skill 是你能力的延伸你用它的每一次输出其实都在替你说话。这也是我为什么始终坚持用真实案例迭代、用严格清单把关的原因——它不只是一个工具它就是你处理问题方式的数字化固化。最后分享一个我觉得特别值得养成的习惯每次你发现自己正在重复教 AI 做同一件事时立刻停下来花半小时把它做成 skill。哪怕做得糙一点也没关系你后面会有无数机会通过失败案例打磨它。真正拉开差距的从来不是谁写的 Prompt 更华丽而是谁更早把零散的经验变成了可积累的资产。