你有没有过这种经历同一个活儿翻来覆去跟AI交代每次开场都要先砸一长串背景、规则、输出格式说完还得补一句“这次务必记住”。结果换一个新会话一切归零你又得从头讲一遍。以前我也觉得这是AI不够聪明的锅后来我把思路换了一下——不再期待AI“记住”任何东西而是主动给它准备一本操作手册。这个玩法在圈里有个名字Skills技能包。Skills不是一句提示词也不是一个需要独立安装运行的插件它是一个自带说明、参考材料和脚本的文件夹。AI在对话里识别到匹配的任务后会把里面的说明文件当成操作手册来读需要的时候再执行脚本、查阅参考最后按约定格式输出。我最初做这件事目标特别朴素把团队里那些每次都要重新解释一遍的重复劳动变成可以复用、可以审查、可以迭代的资产。折腾了几个月踩了不少坑我沉淀出一套还算稳定的方法论。下面把从零搭建Skills的全过程捋一遍目录结构怎么设计、说明文件怎么写、脚本什么时候上场、最常见的翻车现场有哪些。刚接触这个概念的朋友可以直接照着做已经在用的话可以直接跳到第二章看规范和第四章的避坑清单。1. 为什么需要Skills先想清楚要解决什么问题1.1 从“临时对话”到“资产沉淀”先说我自己的真实场景。我负责对接大量重复度极高的文案和整理任务新产品介绍页、周报汇总、会议纪要结构化。之前团队所有人的做法都是现用现写提示词今天写“你是资深编辑注意语气活泼”明天写“你是运营输出要带数据”。每次看起来差不多实际上产出质量完全取决于当天手气而且没人能说清楚同一个任务为什么这次和上次结果不一样。后来我想明白问题不在提示词写得好不好而在AI干活没有稳定的工作台。员工干活有SOPAI干活凭什么只能靠一句口头交代Skills本质上就是把AI干活的方式标准化任务边界、执行步骤、质量要求、参考样例全部写进一个文件夹。AI一旦识别到对应任务就按本手册执行而不是凭上下文自由发挥。这个转变最大的价值不在于省下几分钟输入时间而在于可复现和可审查。以前生成一份文档谁也说不清它为什么长这样现在每一份输出都能追溯到Skill里的某一条规则。改规则等于改所有后续输出。对我们这种需要稳定交付的团队这两个词比什么都值钱。1.2 Skills与提示词、插件的边界很多人第一次听说Skills会问它跟提示词模板、跟插件到底什么关系。我有个不太严谨但很好懂的比方提示词是“你给临时工交代一句话”插件是“你给车间装了一台专用机床”Skills介于两者之间它更像是一本放在工位上的操作手册外加几个简单工具。提示词模板只有文字能约束AI的说话方式但没法让它精确计算、读文件、跑脚本。插件功能很强但要考虑接口、权限、依赖开发成本高。Skills选了中间点大部分逻辑用自然语言描述让AI自己理解执行少数需要精确的地方用脚本兜底。这样我不用写完整程序却能拿到接近定制工具的效果。拿表格看会更清楚三者的差异主要在这几个维度维度提示词模板Skills插件载体一段文字文件夹手册脚本参考独立程序或服务开发成本几乎为零低到中高能否执行动作否可调用脚本可稳定性依赖临场发挥中高高适用场景一次性的写作润色高频固定流程任务需要真实系统能力的场景我的建议是别一上来就追求插件。大部分你以为需要插件的场景先用Skill跑通真到瓶颈了再升级。原因很现实Skill的迭代周期以小时计插件以天甚至周计。团队初期快比全重要。1.3 什么时候不该用Skills做Skills做了几个月我想先泼盆冷水不是所有任务都适合做成技能包。判断标准我总结成三条至少满足两条再动手。第一任务必须高频。一个月才做一次的活写说明书和迭代的成本很可能大于收益。第二边界要清晰。什么叫完成、什么叫没完成要有客观判断标准。像“帮我写个文案”这种边界极宽的任务做成Skill容易做成四不像。第三输出有稳定格式。纪要要有章节、周报要有固定字段、报告要有固定结构这些都值得固化。反过来我自己坚决不碰三类头脑风暴类的开放性任务固化反而限制发散一次性的特殊需求写一遍就是浪费需要实时外部数据又不方便接脚本的任务强行做出来也是半残品。规则这东西宁缺毋滥。1.4 一个让我下定决心做Skills的真实案例举一个让我下定决心的具体事例。有段时间团队要求每场对外会议后24小时内输出纪要客户那边要求字段齐全、负责人明确。我们试过纯提示词方案运气好时十分钟搞定运气差时来回改四五轮最离谱的一次AI把两个不同会议的结论合并到了一起。后来我花一个下午做了个极简Skills版本一个说明文件加一个结构校验脚本。从第二周起每份纪要都是同一个模板字段缺失的会被脚本拦下来重写。最直观的变化是改AI输出从“看缘分”变成了“看手册”。这个案例后来成了我对外讲Skills时必提的样板——它足够小但把核心价值全展示出来了。2. Skill的标准结构与设计思路2.1 一个最小可用Skill长什么样我见过最精简的Skill整个项目只有一个SKILL.md文件。但大多数功能完整的技能包包含三类内容说明文件、参考材料、可执行脚本。我当前的标准目录长这样my-skill/ ├── SKILL.md # 技能说明与执行手册 ├── references/ # 参考文档、模板、历史优秀案例 │ └── template.md ├── scripts/ # 可执行脚本用于校验、格式化、转换 │ └── validate.py └── assets/ # 静态资源如样例数据 └── sample.json目录命名统一用短横线小写比如meeting-minutes、weekly-report。好处是跨平台安全在Git、压缩包、各种文件系统上都不会出岔子。根目录下的SKILL.md是入口文件名固定AI加载技能时首先读的就是它。这里有个关键认知这个文件夹本身不是程序AI也不会原样运行它。AI是把SKILL.md当作使用手册来读参考references里的材料需要精确处理时调用scripts。所以整个技能包的设计核心不是代码而是手册够不够明白。2.2 触发机制description才是真正的大门先说触发机制因为这是整个Skill最容易翻车的地方。AI在对话里不会主动翻阅你所有的技能包它每看到一个任务会先快速扫一遍各个技能包的description字段做语义匹配命中才加载完整正文。换个说法description是技能包的门面决定AI要不要进门正文是门里面的路决定进去之后走得好不好。所以description要写成一段自包含的话不能只写名称。“meeting-minutes”这种写法等于没写要让AI知道什么时候该用。我的标准写法是“当用户提供会议速记或讨论记录并希望整理成结构化会议纪要时使用本技能。不要用于安排会议日程、写会议邀请。”前半句是正向触发后半句是反向排除。这两部分缺一不可。还有一点description是会被AI频繁读的要短要准别把正文内容塞进去。我见过有人把整个手册抄进description结果AI触发是触发了但判断反而变慢变乱。门面上一句“什么时候用、什么时候别用”就够了。2.3 SKILL.md正文的写作逻辑正文我把它当成写给新同事的入职说明书来写先讲目标再讲步骤最后给检查和禁例。AI执行能力很强但脑补能力更强你少写一条它就能自己发挥一条所以“不要做什么”和“要做什么”同等重要。一个常见的误区是正文写得太抽象。“请认真整理会议纪要”这种话没有任何信息量。我会把它拆成具体步骤通读材料、识别主题日期与会人、按讨论逻辑合并同主题、提取结论、提取待办并标注负责人和截止时间。每一步都是AI能直接执行的动作。正文里最好放一段统一的输出模板并明确告知字段不能增删、顺序不能调整。AI对“格式自由”的理解和你不一定一样给它一个死模板比让它“自由发挥但保持专业”靠谱得多。2.4 references、scripts和assets怎么分工这三个目录的分工我给自己定了一条原则静态的放references动态的放scripts数据类放assets。references放的是每次任务都要参考但不用改动的材料风格指南、术语表、历史优秀输出案例。这里有个经验宁可放三份高质量样例别放十份参差不齐的样例负面样例反而会把模型带偏。另外context窗口是有限的references要是太长AI会抓不住重点所以我会控制在一两页以内具体细节按需让AI去查。scripts是给AI准备的精确工具。自然语言擅长表达意图不擅长精确计算。比如要求输出字数在800到1000之间让AI自己数它真可能数错让它写完调用字数统计脚本校验超了就截断、短了就提示补写结果稳定得多。脚本不追求复杂一个几百行的Python脚本能覆盖绝大多数场景。assets最灵活也最容易长成大杂烩。我的建议是凡是被脚本读取的数据统一放assets和references严格分开避免AI读到无关内容后产生误解。我在实际项目里就吃过亏参考资料里混了一份旧版术语表AI每次都会读到等于给自己埋雷。2.5 命名、版本与质量判断命名规范值得多说两句。除了目录名用短横线小写description里我会主动埋一些触发词。做会议纪要Skill时我写了“出现会议纪要、速记整理、讨论总结这些字眼时可触发”。这不是堆砌关键词而是给AI一个清晰的检索入口。反例是只写“整理会议记录”AI会在“帮我把这周会议排期整理一下”这种任务上误触发输出完全跑偏。版本管理我直接用Git每个Skill一个仓库或者一个大仓库下一个子目录看团队习惯。重点是每次改动都写清楚changelog。技能包是会持续进化的没有版本记录两周后你自己都说不清为什么输出格式变了。质量判断上我从三个维度打分触发准确率该用的时候用没用到、不该用的时候有没有瞎用输出通过率产出能不能直接进下游流程迭代成本改一次规则平均花多久。这三个数据攒几轮每个技能包值不值钱一目了然。3. 从零搭建一个可复用的Skill实操全流程3.1 选定场景找一个高频、稳定、可判别的任务理论讲完拿我做过的一个“会议纪要整理”技能当例子从头拆到尾。挑这个场景是因为它踩中了三个条件团队每周至少三场会高频产出物有明确的字段结构稳定输入是速记文本输出是结构化纪要边界清晰。我还额外加了一条错误能被客观发现。决策事项有没有进对应字段、负责人是不是缺失一眼就能看出来。选定场景后把任务拆成输入、处理、输出三段。输入是用户的速记或讨论记录格式混乱没关系处理是提取主题、与会人、结论、决策与待办输出是一份固定模板的纪要。这个拆解是后面写SKILL.md和脚本的基础拆得越清楚写起来越省事。3.2 编写SKILL.md从触发条件到执行手册写SKILL.md我的习惯是先写description再写正文正文写完再回来改description。因为写正文的过程会让你更清楚技能的边界这时候改description往往能改得更准。骨架大概是这样的--- name: meeting-minutes description: 根据会议速记或讨论记录生成结构化会议纪要。当用户提供会议内容并要求整理、总结、输出纪要时使用。不要用于安排会议日程、写会议邀请。 --- # 会议纪要整理 ## 目标 将原始速记整理为一份字段完整、逻辑清晰、可直接分发的会议纪要。 ## 执行步骤 1. 通读原始材料识别会议主题、日期、参与人。 2. 按讨论逻辑合并同主题内容删除重复与无关闲聊。 3. 提取明确的结论和决策事项。 4. 提取待办事项标出负责人和截止时间缺失时标记为“待确认”。 5. 按下方模板输出字段不能增删。 ## 输出模板 模板内容略 ## 不要做 - 不要编造未在材料中出现的结论。 - 不要省略待办事项。 - 不要改变原始结论的语气。注意description里的反向限定“不要用于安排会议日程、写会议邀请”。AI的触发机制是对描述做语义匹配不加这条它就很容易在用户聊到“下周会议排期”时强行触发输出一份不存在的纪要。这种反向限定每个Skill都应该有。3.3 让脚本上场处理AI不擅长的精确环节SKILL.md写完后我补了一个脚本负责两件事校验输出纪要的结构完整性统计待办数量。#!/usr/bin/env python3 import re import sys text sys.stdin.read() required [主题, 日期, 结论, 待办事项] missing [f for f in required if f not in text] if missing: print(STRUCT_ERROR: 缺少字段 , .join(missing)) sys.exit(1) todos re.findall(r- \{\{TODO\}\}, text) if len(todos) 0: print(STRUCT_WARN: 未发现待办事项) sys.exit(2) print(STRUCT_OK)这段代码本身没什么技术含量但它解决了一个很实际的问题AI写纪要偶尔漏字段还特别自信地告诉你写完了。脚本的判定是确定性的结构不对就是不对没有辩解的余地。执行链路是AI先写再调用脚本校验校验不通过就自己修正并重新校验。这比在提示词里写一百遍“务必检查字段”都管用。脚本的选择我总结过三个适用场景格式校验、字段抽取、文本统计。超过这三个场景比如涉及业务逻辑判断我会把标准写进SKILL.md而不是脚本因为业务逻辑频繁调整改文字比改代码成本低得多。另外脚本要遵守一个底线不做破坏性操作不依赖外部网络保证在任何环境跑一遍结果一致。3.4 测试与迭代技能包不是写完就结束技能包写完第一版只敢说能跑不敢说好用。我会用一个测试清单跑几轮每一轮都记录三件事AI是否正确触发、输出结构是否完整、内容有没有瞎编。用例类型输入示例预期结果正常一段完整会议速记触发技能输出完整模板边缘只有三行字的速记触发缺失字段标“待确认”干扰速记夹杂大量无关闲聊忽略闲聊只整理会议内容负例帮我安排下周评审会不触发走普通对话负例测试最容易被忽略但我第一版就在这翻过车。没写“不要用于安排日程”时负例直接挂掉——AI把“帮我约下周三的评审会”当成纪要任务硬生生输出了一份假纪要。加上反向限定后才通过。跑完测试把问题分三类描述问题改description执行问题改正文校验问题改脚本。然后重新跑全量清单。我习惯每改一次就全量回归别偷懒只测改的那条。技能包内部是联动的一个词的改动可能影响触发边界也可能影响执行表现回归测试是唯一靠谱的确认方式。4. 常见问题与排查技巧实录4.1 技能不触发或不该触发却触发了不触发多半是description写得太窄或太抽象。“处理会议相关内容”这种话AI理解不了什么叫处理、什么叫相关。解决办法是直接列出典型的用户说法像“速记”“会议记录”“把讨论整理一下”。这些词是你和AI之间的共同语言。误触发通常是反向约束没写。我后来养成了固定动作写完description后专门追问自己“哪些任务看起来像但其实是另一回事”然后把例外写进description。纪要技能排除“安排会议日程”周报技能排除“写个人总结”。一行字能消除一大半误触发。4.2 输出不稳定时好时坏输出忽好忽坏几乎都是因为手册只规定了方向、没规定检查点。解决方式是引入强制检查列表。在正文里加一段输出前自查主题是否与材料一致每个结论能否在原文找到依据待办人员是否标注AI在输出前会一条条过没过就自己改。如果自查还不够就让脚本做确定性校验。我见过一个做得极端的翻译技能要求术语统一人工抽查总有漏网。后来写了个脚本做术语表匹配发现不一致就改写并标注原因术语错误率几乎归零。这给我的启发是AI最怕的不是能力不够而是没人检查。4.3 多个技能包互相打架技能多了触发冲突是必然的。你有周报生成技能又有项目复盘技能用户说“把本周项目情况复盘一下”两个都觉得自己该上。这时候拼的是description的边界。我通常用两个办法。第一在各自description里写清排他条款比如“如果只是常规周报请使用weekly-report技能本技能仅用于重大节点复盘”。第二把重叠语义合并到一个技能里内部判断输出哪种结构而不是拆成两个互相抢。经验是宁可技能少而边界清不要技能多而边界糊。4.4 版本混乱改坏了想回滚技能迭代多了最怕昨天好好的、今天突然变傻。我第一次遇到排查了半天最后发现是前两天改了一版description把触发词改窄了该触发时不触发。现在的流程很固定每个Skill独立Git仓库提交信息写成“fix: 增加速记触发词”“change: 输出模板新增风险字段”。改坏了直接回滚。团队协作时我要求改Skill必须附带一个测试用例证明这次改动修的是什么。听起来重但对于要长期维护的技能包这是最低成本的保险。4.5 一个小型问题速查表最后给一张我工位上贴着的速查表排查顺序也按这个优先级来症状第一排查点第二排查点不触发description触发词太窄或太抽象与其他技能冲突被抢占误触发缺少反向排除说明description范围过宽输出不稳定正文步骤不具体缺少输出前自查结构错误模板未写明不可增删脚本校验缺失突然变差最近一次版本改动参考文件被替换这张表的价值在于它把玄学问题变成了工程问题。先检查最可能的点别一上来就怀疑模型不行。5. 进阶把Skills变成团队资产5.1 技能包的沉淀与淘汰机制单人的技能包再大也有限真正有杠杆的是团队层面的技能资产。我见过比较健康的做法新任务先人工跑跑顺了再固化成Skill固化后试用两周统计触发准确率和输出通过率连续两周不达标的重构或下架。这个机制解决的就是技能包越攒越多但没有淘汰的问题。定期技能审计像整理衣柜一样把不常用的合并、失效的下架、优秀的置顶。每半年做一次仓库会一直保持清爽。我自己的仓库就是这么活下来的否则早就变成一个无人认领的垃圾堆。5.2 怎样评估一个Skill到底划不划算投入产出比是可以算出来的。我的粗略算法维护成本等于开发工时加每月更新工时乘维护月数收益等于单次节省时间乘月度使用次数。三个月内收益覆盖不了成本这个技能包就属于“爱的供养”建议删掉。有人觉得这算法冷血但技能包是有机会成本的——维护鸡肋技能的时间完全可以用来沉淀真正高频的场景。我攒过十几个技能最后一半没人用维护还占时间不如一开始就少而精。5.3 工具与协作方式的选型心得工具和协作方式上我的选型很朴素。目录和SKILL.md用任何文本编辑器都行但需要配合Git所以团队里我统一用VSCode加Git插件没什么学习成本。参考资料里的模板我用Markdown保持纯净避免Word那套样式污染AI的阅读。协作流程上一个Skill至少两个人过目使用者提需求维护者写实现第三个人做验收测试。这套流程听起来像软件开发但它真的有必要。技能包本质上就是一个小型软件项目只是交付物从代码变成了“AI的行为准则”。按软件工程的规范对待它后面会省很多心。5.4 我在实操中的三点体会第一小步快跑比一次到位重要。先做只覆盖80%场景的最小版本用起来被真实需求打磨再完善剩下20%。一上来就想面面俱到大概率陷在设计文档的泥潭里出不来。第二Skill的质量上限取决于描述文字的清晰度而不是模型能力。同一个任务描述含糊和描述清楚输出质量就是及格和优秀的差距。别指望模型读懂你脑补出来的潜台词。第三也是我最有感触的一点技能包是团队规范不是个人私货。写的时候要想象未来接手的人能不能看懂、能不能维护。我每次写完都会问自己一句三个月后的我看到这个文件夹能不能三分钟内理解它要干什么如果不能它还没资格当一个技能包。最后再分享一个小技巧每次新建Skill先不让它追求完整而是故意留一个你已知的缺陷比如“输出格式先不强校验”。用起来之后你会发现真实需求比你的想象具体得多这时候再补上缺陷比一开始凭空猜需求高效好几倍。这是我的老办法也是我做得最顺手的一个习惯。