写 skill 这件事已经成了我用 AI 工作流里最上头的环节之一。但我见过太多人花一下午写了一个自我感觉良好的 skill然后……就没有然后了。问题不在于你不会写而在于你缺一套流程。你靠灵感和一次成功经验堆出来的东西本质上是一段带运气的 prompt 加强版。这篇想做的是把“高效创建 skill”这件事拆成一套可复制的流程核心落在我认为最关键的词上方法抽象。怎么从“我上次这么干成了”变成“这个领域以后都能这么干”最后附一份我自己会逐条打勾的 Review 清单。适合正在给 AI 定制能力、又总觉得 skill 不够聪明的朋友。1. 先想清楚skill 为什么容易吃灰以及“方法抽象”到底在抽什么1.1 大多数人写 skill 的方式错在哪先说个我自己的反面教材。早期我给代码仓库写过一个代码审查用的 skill特别得意把我当时认为重要的检查项全塞进去了——包括某个项目特有的模块命名规范、固定的依赖版本清单、还有我们组自己的 git 分支命名规则。写的时候觉得“真全面”结果换到另一个项目试用第一轮就崩了。模型把新项目里不存在的模块名当成潜在错误标了出来给出的依赖升级建议也完全对不上。这不是模型蠢是我蠢。我把“具体案例”当成了“通用方法论”塞进了指令。这是大多数人写 skill 的第一个坑以为写的越细越好。但细节有两种一种是“方法本身需要的步骤和判断标准”一种是“某个特定场景下的实例数据”。前者是可迁移的方法论后者是写死的一次性参数。skill 吃灰的根因基本都出在后者太多、前者太少。1.2 抽象不是“把话写模糊”而是“把路径画清楚”很多人听到“抽象”两个字就以为要把指令写得更泛、更模糊结果 skill 的输出变成一堆正确的废话。比如你写“请仔细分析这份日志找出问题并给出建议”模型确实会“仔细分析”但产出质量完全看运气。真正的方法抽象是在更高层级描述步骤、判断、顺序和终止条件让模型到一个新场景里还能重新执行。我常用一个类比菜谱和烹饪方法论的区别。菜谱告诉你“放入 5 克盐”换个菜它就失效烹饪方法论告诉你“少量多次加盐每次加完尝一下直到咸淡合适”这东西能迁移到所有菜。所以抽象抽走的是那些“换个场景就变的参数”留下来的是“无论什么场景都成立的动作序列”。判断一条指令该不该抽象你就问一句如果用户换一个项目、换一套数据、换一种框架这句话还成立吗成立就留着不成立就做成变量或者删掉。1.3 三个信号这个需求值得做成 skill 吗不是所有事情都值得做成 skill。我见过有人给“写周报”做 skill给“整理桌面文件”做 skill结果用两次就废了。不是这些事不重要而是它们太个人化、太依赖临时状态抽象不出稳定路径。我一般用三个信号来判断这件事你反复做且每次都靠脑内经验。比如日志排查、代码 review、竞品调研、数据清洗这些事你做了十遍二十遍每次都在脑子里过同一套判断写成 skill 等于把经验外置。做得好的人寥寥无几而你已经有一两次成功的案例。注意这里是“一两次成功案例”不是“我觉得我懂”。你需要有具体的、做成功的样本作为抽象素材凭空想象出来的步骤往往经不起推敲。输出可以被结构化拆解成明确的步骤和判断规则。如果这个东西完全靠灵感比如写诗、起名抽象出来的 skill 只能给你打辅助给不了确定性。那不是 skill 该干的事。2. 五步流程从一条聊天记录到一个可复用 skill2.1 流程全景五个阶段的链路和产出物我现在的 skill 开发流程基本固定成五步每一步都有明确的产出物。这套流程的核心思路是先收集样本、再做抽象、最后才写代码——这个顺序不能反。阶段核心任务产出物参考耗时需求捕捉判断要不要做、边界在哪需求卡10-20 分钟样本收集找回 1-3 个高质量案例案例记录20-40 分钟方法抽象提炼步骤、参数、边界抽象草稿30-60 分钟编写 skill写成 SKILL.md 与脚本skill 包1-2 小时测试与 Review跑测试任务 逐条自查Review 记录30-60 分钟很多人跳过样本收集直接从需求跳到编写这是效率最低的做法。你没有样本就只能凭空编规则写出来的 skill 大概率是“你以为的流程”不是“你实际做过的流程”。这两者差很远。2.2 需求卡格式化定义的威力我写任何 skill 之前都会先花十分钟填一张需求卡格式固定就五个字段目标用一句话说清楚这个 skill 要解决什么问题。写不清楚说明你自己还没想明白。触发场景在什么情况下用户会调用它。比如“当用户给出多行日志时”“当用户要求审查 PR 时”。输入模型能拿到什么信息。是原始文本是文件路径还是需要用户补充问题输出最终产出的格式。是结构化报告、代码片段、还是表格不做明确这个 skill 不应该干什么。这一条最容易被忽略但它是后续防跑偏的关键。举个我实际做过的例子一个日志分析 skill 的需求卡是这样填的目标快速定位线上报错日志的根因并给出可执行的修复建议。 触发场景用户粘贴一段报错日志或给出日志文件路径并要求分析。 输入原始日志文本可能包含堆栈、时间戳、业务错误码。 输出根因判断、证据链、修复建议按固定 Markdown 模板输出。 不做不负责修复代码不生成补丁不做性能优化建议。当日志来自非技术场景时明确拒绝分析。这张卡的最大作用是后面每一步都拿它来对齐。写指令写偏了回来看看“不做”那一栏Review 的时候也拿“目标”那一栏检验 skill 到底有没有完成核心任务。2.3 最小可用版本的“三件套”一个标准的 skill 包我建议第一版就准备三样东西说明档SKILL.md核心指令告诉模型怎么思考、按什么顺序做、什么情况下停。这是整个 skill 的灵魂大部分精力都应该花在这。可选脚本scripts/用来做模型不擅长的事比如精确解析 JSON、计算时间差、批量处理数据。注意脚本永远是辅助不是主体。示例输出examples/一两份“标准答案”样本。模型在做任务时可以参考它对齐格式和风格也能用于后续回归测试。最小可用原则就是第一版只覆盖一条最主线的路径不需要把所有分支都写上。先把一条路跑通再扩分支。很多 skill 写得太大一次想解决所有问题结果每条分支都没测试过全是雷。2.4 先别急着写代码用纯指令跑通第一版这是我最想强调的一个习惯第一版不要写任何脚本纯用指令。先只写一版 SKILL.md描述方法和流程不写任何代码然后拿真实案例去跑。你会发现很多你以为需要脚本的地方模型直接用指令就能处理好而真正需要脚本的地方会在测试中自己暴露出来。我见过太多 skill 作者一上来就写一个三百行的 Python 脚本解析日志费了老鼻子劲结果模型在纯指令模式下用正则思路就解决了。等确认了“这里确实需要精确计算”再加脚本你的脚本才是经过验证的而不是拍脑袋的。另外每多一个脚本就多一份维护成本和失败概率。脚本可能报错、可能路径不对、可能依赖缺失而指令永远不会由于环境问题 crash。3. 方法抽象最关键的三个动作提炼、变量化、边界化3.1 提炼从一次优质输出倒推“决策树”这是整个方法抽象里最花功夫、也最值钱的一步。具体做法是把你过去做成功的一个案例完整翻出来逐句还原当时的思考过程。不是复述你做了什么而是追问你每得出一个结论依据是什么你看到了哪些信息你排除了哪些可能性是什么让你决定停止分析拿日志分析举例子。我手工排查报错时脑子里其实有一套隐形的决策树先看时间戳找到密集报错的时间区间再看 ERROR 和 WARN 的比例判断是雪崩还是局部异常然后看堆栈里出现最多的调用链锁定疑似模块最后查这些模块最近有没有发布记录。但你要是不逼自己写出来你永远不会意识到这套决策树存在——你只会觉得“我就是看一眼就知道了”。把这段过程翻出来然后用“如果……那么……”的句式翻译成规则“如果 ERROR 集中在 3 秒内爆发那么优先怀疑依赖服务超时或重启而不是代码逻辑错误。”这些规则才是方法论。你能从一次成功案例里倒推出十条以上的决策规则这个 skill 就成功了一半。3.2 变量化识别哪里是固定方法论、哪里是每次变的参数提炼出来的规则要分成两类固定方法论和可变参数。固定方法论是任何场景下都成立的判断原则——比如“先定位时间窗口再分析堆栈最后关联发布记录”这个顺序本身就是方法论。可变参数是每个项目都不一样的东西——比如具体服务名、日志路径、团队命名规范、错误码字典。处理方式很简单把固定方法论写成指令正文把可变参数抽成 {变量}在 skill 运行前由用户填写或者由模型从上下文中提取。用变量命名的方式设计 skill 的“接口”就像给一个函数定义参数。你的 skill 参数越清晰它复用起来就越顺手。我经常看到新手在这里犯一个相反的错误把固定方法论也参数化。比如“按 {某种方式} 分析”这个“某种方式”就是该写死方法论的地方结果你把它做成变量等于把决策权交还给了模型skill 的确定性就没了。3.3 边界化告诉模型“什么时候该停手”边界化可能是方法抽象里最被人低估的一环。模型遇到信息不足的情况本能反应是编造。你如果不告诉它“找不到根因时该怎么办”它就会给你一个有模有样的假结论而且证据链都是编的。我写 skill 时一定会写进三样边界一是信息不足时的处理策略是继续追问用户、还是基于现有信息给出带置信度的推断二是停止条件什么时候分析可以收工比如日志里只有三条 ERROR 且彼此孤立没构成任何模式就应该明确告诉用户“信息不足无法定位根因”而不是硬凑一个结论。三是明确禁止直接在指令里写“不确定时明确说不确定不要编造证据链”。很多 skill 质量翻车不是方法错了而是模型在无法得出结论的边界处编了一个结论。边界写清楚等于给 skill 装了一个刹车。3.4 一个具体案例的全过程从聊天记录到抽象草稿我把上面的过程串起来用日志分析 skill 演示一下。最初样本是一次“查线上报错”的对话用户贴了一份完整日志我手工给出了分析和修复建议。第一版我把这次对话里的内容平铺直叙写成规则按错误频率排序、看堆栈、查依赖服务、给出建议。测试后发现两个问题。第一我把当时那家公司的服务名和版本号写进了示例模型在新场景里会试图找这些不存在的模块产生幻觉。于是把所有具体服务名删掉替换成“疑似模块”这种占位描述。第二用户场景不同需要的建议格式也不同。有人要一句话结论有人要完整的根因报告。我把它拆成“结论模式”和“完整模式”由 skill 根据日志复杂程度自动选择。这轮折腾下来最终 SKILL.md 里的核心指令变成了先读时间戳确定窗口、再统计错误类型分布、然后定位堆栈中的公共调用链、最后结合已知变更信息判断根因。整个分析过程中只依赖日志文本本身和用户补充信息不依赖任何具体项目特征。这就是方法抽象完成后的样子。4. 附上我的 Review 清单25 项逐条自查4.1 清单结构说明很多人写完 skill 就直接投入生产这是我最不建议的做法。skill 不同于普通 prompt它会反复被调用一次错误会被放大很多倍。所以我在发布任何 skill 前都会花二十分钟逐条过一份 Review 清单。这份清单分四组目标与边界、抽象与迁移、指令可执行性、失败与测试。每组都是发现问题用的不是走过场。4.2 Review 清单 v1.0 全文这里是我手上在用的版本你可以直接拿去用。每一项都是二选一过不去就回去改改完再测。编号检查项通过标准A1一句话能力范围SKILL.md 前三行能说清楚解决什么问题A2不适合场景有明确“不做”清单防止被乱调用A3触发条件description 字段写清什么时候触发A4输入字段明确模型需要读取的信息和格式A5输出格式明确最终产出的结构标题、模板、示例B1无硬编码找不到写死的项目名、路径、版本号B2规则优先于示例关键判断以“如果那么”规则呈现B3阈值可配置数值型参数可以用变量或模糊基准B4环境无关换一个 agent 环境仍可执行B5抽象层级一致不出现一半宏观一半抠细节的断层C1无空话指令不出现“认真分析”“深入思考”这种话C2顺序明确步骤有先后依赖关系写清楚C3信息源明确每一步知道从哪里取数据C4分支条件不同情况有对应的处理路径C5输出模板至少给一个可参考的输出格式C6确认机制首次运行时要求复述任务理解D1信息不足处理有“信息不足怎么办”的明确指令D2停止条件知道什么时候收工不会无限发散D3反幻觉明确禁止编造证据链D4外部工具失败脚本报错时知道如何降级处理D5正向测试至少两个真实场景跑通D6负向测试输入不完整、格式错误时能正确拒绝D7回归样例保留一份测试日志改后重跑不后退D8变更记录有过一次迭代记下了修改原因看着项目多其实大部分都是快速判断。真正花时间的永远是下面这四个最容易挂的检查项。4.3 最容易挂的四个检查项详解B1 无硬编码。这个最容易挂因为你写的时候根本不觉得那是硬编码。项目名、模块名、目录结构你写得很自然但换一个项目就全废。我自己的诀窍是写完 SKILL.md 后把所有专有名词圈出来逐个问一句“换个场景它还成立吗”。C1 无空话指令。我检查时会把所有形容词和副词圈出来然后问自己这句话删掉对模型的输出有没有影响“全面考虑”“仔细分析”“充分理解”删掉对输出一点影响没有这就是空话。真正的指令动词应该是列出、排序、对比、回溯、归类。D2 停止条件。模型默认会一直分析下去直到它觉得差不多了。但“觉得差不多了”这件事本身就是玄学。你必须写清楚什么情况下算完成什么情况下算信息不足什么情况下直接给结论。A2 不适合场景。这个挂的人更多。我见过一个日志分析 skill 被用户拿去分析财务表格模型居然也照跑不误。就因为你没在 SKILL.md 里写明“那这不是我该干的”。边界写清楚模型才敢拒绝。4.4 Review 完不要急着交付先做“灾难测试”清单过完我会做一轮灾难测试用三个故意刁难的输入去跑第一输入不完整比如只有半行错误码看模型会不会直接放飞。第二输入信息互相矛盾比如时间戳比当前时间还晚看模型有没有防御性地指出问题。第三超长输入塞一大坨无关内容看模型会不会抓不住重点。灾难测试的本质是检验 skill 的防御机制。一个只会处理“理想输入”的 skill到了真实场景基本头一两次就会翻车。真实世界的数据永远是脏的、乱的、带歧义的skill 的可靠性恰恰体现在这些脏数据面前的表现。5. 维护阶段把 skill 当成产品而不是脚本5.1 版本管理与变更日志很多人的 skill 写完就再也不动了。但 skill 有一个特点模型在变、使用场景在变、你对方法论的理解也在变。一个三个月前的 skill很可能已经跟不上现在的模型能力了。我现在给每个 skill 都做简单版本记录格式不用复杂一个 CHANGELOG 文件就够这个版本改了什么为什么改。更新节奏上新 skill 前两周我基本每周迭代一次因为刚投入使用时最容易暴露问题。等稳定之后一个月 review 一次就行。核心思路是让 skill 保有生命力它不是一个一次性交付物而是你日常工作方法论的活体文档。5.2 组合使用时的命名与冲突处理skill 多了之后最大的麻烦是多个 skill 可能被同时触发。比如你有一个通用的“代码审查” skill又有一个专门的“安全审查” skill用户发一段代码时两个都被唤起了输出可能会互相打架。我的处理办法是命名要带明确前缀描述字段里写清边界和优先级。SKILL.md 里的 description 字段是 skill 的“门面”。它不只是一个功能介绍还是模型判断“该不该用我这个 skill”的依据。写 description 的时候要比你想象中更具体——要写“当用户给出超过 10 行报错日志并要求定位根因时”而不是“分析日志”。描述写不具体触发就会混乱再好的方法论也用不上。5.3 把写 skill 的方法本身变成一个 skill最后分享一个我觉得很有趣的递归应用我把我这套五步流程和 Review 清单做成了一名叫“skill creator”的 skill。是的我自己在用一个帮我写 skill 的 skill。它做的事情很简单当我给它一个原始需求它会先让我填需求卡然后引导我找样本再按提炼、变量化、边界化的顺序帮我生成抽象草稿最后写完 SKILL.md 跑一遍 Review 清单。这个 skill 本身有没有多智能没有。它只是把我这套方法论完整地硬化成了指令让我在状态不好或者想偷懒的时候也能保证产出质量不滑坡。这其实就是 skill 最本质的价值不靠状态、不靠灵感、不靠运气把你已经验证过的方法论变成每次都能复现的确定性输出。方法抽象这事我越做越觉得它的边界很大。不只是写 skill你日常做的任何重复性工作都可以先问自己一句这里面哪些步骤是方法论、哪些参数是变量、哪些情况该停手把这三件事想清楚你距离一个靠谱的 skill 就只差动手写了。