第一次接触“skills”这个词是在整理团队SOP的时候。文档写了一堆目录建了十几个但真到用的时候才发现知道要做什么和知道怎么做完全是两回事。后来开始碰AI Agent相关的东西又撞见“skills”——只是这一次它的含义完全变了变成了给模型用的技能包把做事的流程、判断依据、避坑经验封装成一个可复用的单元。我花了一段时间才把这些概念理顺也踩了不少坑。如果你也在关注个人能力沉淀、团队知识管理或者正在折腾AI Agent这篇应该对你有用。我想聊的是一个更实际的问题怎么把零散的经验真正变成资产从设计、编写、验证到迭代完整搭出一套可复用的Skill技能库。1. 先想清楚Skill到底是什么1.1 一个词两个语境“skills”这个词现在存在两个语境很多人混着用结果讨论半天对不上。第一个语境是个人能力层面指专业技能、软技能、管理能力。这个层面讨论的是“人如何成长”比如沟通技巧、编程能力、谈判能力。它很重要但不是这篇文章的主角。第二个语境是AI Agent层面指给智能体准备的可执行能力包。你可以把它理解成一张“操作说明书”加“经验手册”的组合让AI在遇到特定任务时能按一个成熟流程去执行而不是每次从头开始瞎猜。这两个语境之间的关系也很有意思。个人技能是抽象的、隐性的存在脑子里的Skill技能包是具体的、显性的存在文件夹里的。把脑子里的经验外化成一份结构化的技能包这个过程本身就是在做知识显性化。我们团队后来沉淀了几十个这样的技能包才发现这比写一百页文档有用得多。1.2 为什么技能包比文档更值钱传统做知识管理大家习惯写文档操作手册、流程规范、FAQ。文档当然有用但它有几个硬伤。第一文档是给人看的不是给机器执行的。写的时候觉得“这么清楚肯定没人看不懂”但真用起来还是处处要人判断。第二文档是静态的一旦更新不及时反而变成误导。第三文档之间没有结构关联查A要翻B翻B又要看C效率极低。技能包解决的是另一个维度的问题它不只是“告诉你怎么做”而是“按这个方案就能跑通”。技能包内部有明确的触发条件、执行步骤、输出格式、避坑要点甚至可以直接作为AI Agent的一个能力单元被调用。我打个比方。文档相当于一本菜谱告诉你食材、步骤、火候但每一步都得你自己看着办。技能包相当于一位师傅站在旁边不仅告诉你步骤还会在关键节点提醒你“这个时候油温已经太高了”“这个调料千万别放多”“这个步骤如果出现XX情况就说明你前面做错了”。菜谱解决“知不知道”的问题师傅解决“做得成不成”的问题。所以如果你想做知识沉淀不要只停留在写文档。要把高价值的经验做成技能包让它们真正可复用、可执行、可验证。2. 从经验到技能包设计一个Skill的基本结构2.1 最小可用结构一个文件夹加一个描述文件一个技能包听起来很玄其实最小可用结构就两部分一个目录以及一个描述核心逻辑的文件。我习惯的目录结构是这样的skills/ └── meeting-minutes/ ├── SKILL.md ├── examples/ │ └── demo-input.txt └── references/ └── templates/SKILL.md 是整个技能包的大脑负责描述这个技能是干嘛的、什么时候该用、具体怎么执行。examples 目录放输入样例用来演示这个技能适用的任务长什么样。references 目录放模板和参考资料给执行过程提供素材。这个结构看起来简单但它背后有三个设计原则单一入口、渐进明细、边界清晰。单一入口指所有核心信息都从SKILL.md进去你不需要东翻西找一个技能包的核心逻辑在哪。渐进明细指主文件只写主干流程细节放在子文件里保证主文件不会变成一本500页的字典。边界清晰指这个技能包只管自己该管的不越界涉及其他任务。很多人在第一步就翻车把SKILL.md写成了一个超大文档什么都要收录结果AI读起来上下文爆炸人也看不下去。技能包没有规定一定要多大但一个健康的SKILL.md最好控制在几十行到一两百行之间。超过这个量级就要思考是不是该拆分了。2.2 元数据写清楚“何时用”比“怎么写”更重要设计技能包时大家通常会花很多精力写执行步骤但容易忽略最前面的元数据部分。我踩过这个坑之后才明白元数据才是整个技能包最值钱的部分。可以借助一个拟定的结构来看比较通用的几个字段是name、description、when_to_use、version、tags。--- name: meeting-minutes description: 生成结构化会议纪要支持中英文混合输入整理 when_to_use: 当用户提供会议录音转写文本、会议笔记草稿或要求生成会议纪要时 version: 1.0.0 tags: [会议, 纪要, 办公自动化] ---看起来很简单但每个字段背后都有讲究。description 不能只是“生成会议纪要”而要说明这个技能能处理什么输入、产生什么输出。因为AI在决定调用哪个技能时靠的就是这个描述。写得太泛AI会把不相干的任务也丢进来写得太窄该触发的时候不触发。when_to_use 是大多数新手会忽略的。它相当于触发条件告诉AI“什么场景下你应该选我”。这一条写得准技能被正确调用的概率会大幅提升。我见过一个反例有人写“当用户需要帮助时使用”这就是废话等于没说。when_to_use 一定要具体到任务特征比如“当输入包含RWKV格式的原始文本且用户要求整理为结构化条目时”。version 也很重要。技能包会持续迭代没有版本号你没法追溯某次行为变化是从哪个版本开始的。后面讲迭代管理时还会细说。2.3 把模糊经验翻译成可执行步骤这是技能包装写过程中最考验功力的一步。很多人在这一步会犯同一个毛病写得太抽象。比如写“分析用户情绪”“给出专业建议”这种话没有任何执行性。什么叫“分析情绪”看关键词看语气词看感叹号AI不知道人看完也不知道。把模糊经验翻译成可执行步骤核心是用“条件动作”的结构去表达遇到什么情况就做什么动作。拿“会议纪要”技能来举例。关于“纪要格式”的模糊经验是“要重点记录决策和行动项”。翻译成可执行内容就变成了1. 从转写文本中提取所有决策事项 - 判断标准出现“决定了”“就这么定”“一致同意”等表述 2. 从转写文本中提取行动项 - 每条记录包含负责人、截止时间、具体动作、关联背景 - 如果文本中没有明确说出负责人标注“待确认”不要自行编造 3. 区分事实陈述和个人观点 - 事实陈述保留原意个人观点用“讨论”后缀标注你会发现可执行的步骤有几个特点有判断标准、有边界条件、有不可做的事项。判断标准让AI知道“什么时候算命中”边界条件让它知道“什么是特殊情况”不可做的事项直接规避了AI常见的“编造信息”问题。我后来给团队定了一个“步骤四要素”原则动作要单一、条件要可判断、输出要明确、边界要清晰。满足这四个要素的步骤才叫可执行。3. 实操从0到1搭一个可用的技能库3.1 命名、目录与版本规范动手写之前先定好规范。没有规范的技能库几个月之后就变成一片混乱。命名建议用短横线分隔的小写英文比如meeting-minutes、># 会议纪要技能 把会议内容整理成纪要。就这么两句没了。我立刻发现根本不能用整理成什么格式按什么结构判断标准是什么全部缺失。第二版我加了步骤但还不够。第三版我才慢慢补齐。后来一个可用的版本大概长这样--- name: meeting-minutes description: 将会议录音转写文本或会议笔记草稿整理为结构化的会议纪要输出决策、行动项和待讨论事项 when_to_use: 当输入包含会议转写文本、会议笔记或明确要求生成会议纪要时 version: 1.2.0 tags: [会议, 纪要, 办公自动化] --- # 产出格式 纪要包含四个部分按顺序输出 1. 会议概况会议主题、时间、参会人从文本中提取缺失则标注“未提及” 2. 关键讨论按话题分组每个话题列出核心论点 3. 决策事项列出所有已确定结论标注决策背景 4. 行动项每条包含负责人、截止时间、动作描述缺失信息标注“待确认” # 执行步骤 1. 通读全文按话题给文本分段 2. 提取决策事项判断标准出现“决定”“就这么定”“一致同意”等表述 3. 提取行动项判断标准出现“需要”“负责”“跟进”等动词结合上下文确认责任主体 4. 过滤寒暄和无关闲聊不写入纪要 5. 使用简洁书面语输出保留原始结论的关键措辞 6. 如果文本存在明显信息缺失在对应位置标注“待确认”不自行补全 # 边界 - 只处理与会议内容相关的信息 - 不添加原文没有的结论 - 不改变原文表述中的关键意思这个版本比第一版好用得多。为什么因为每个环节都有了可判断的标准AI知道怎么提取、怎么过滤、怎么做取舍。后来我又在references里加了模板文件让AI可以套用统一的格式输出。3.3 验证与测试技能能跑通吗写完技能包之后最重要的一步是验证。这一步我强烈建议你准备至少5个不同的测试输入。测试输入要覆盖正常场景、边界场景和异常场景。正常场景是标准输入边界场景是输入特别长、特别短、混杂其他内容异常场景是输入和目标任务完全不匹配。每跑一个测试输入都记录两个东西输出结果是否符合预期以及AI是否在正确的时机调用了这个技能。这一套跑下来你通常会发现几类问题第一是触发不灵敏。你精心写的when_to_useAI根本不理。这时候不要急着改描述先看看你是不是把技能说得太大路货了。比如一个“整理会议纪要”的技能和一个“生成待办事项”的技能在很多情况下触发条件有重叠AI就会分不清。你要做的不是堆更多形容词而是把两个技能的边界划清楚。第二是步骤顺序不清。AI在执行时有时候会跳步或者反复执行某一步。这个大概率是你在步骤描述里缺少前置条件和终止条件。比如“提取行动项”之前要说清楚“只由最终确认过的文本中提取不包括讨论过程中的假设”。第三是发挥不稳定。同一个输入跑两次结果差别很大。这种情况多半是步骤里夹带了模糊要求比如“合理整理”“适当补充”解决办法是给AI更明确的规则把“合理”替换成具体判断标准。验证环节没有捷径就是反复跑、反复改。但跑过几轮之后技能包的稳定性会有质的提升。4. 迭代与分享技能库的生命力4.1 版本管理改技能比写技能更容易翻车很多人在技能包刚跑通之后就停止了迭代觉得“能用就行了”。但真实情况是技能包的生命力在于持续迭代。不过改技能比写技能更容易翻车这一点我教训很深。有一次我为了让一个“周报生成”技能支持英文输入顺手调整了输出模板。结果中文周报的输出格式也变了测试时全乱套还影响到了其他技能在引用这个模板时的表现。那次之后我养成了两个习惯。第一个习惯是任何修改都先看影响范围。技能包不是孤岛它可能被其他技能包引用也可能被自动化流程调用。改一个步骤之前先查一下谁在引用它。第二个习惯是改动要可回滚。没有版本管理改崩了就是改崩了。我把每个技能包做成一个独立的git仓库或者至少在一个大的仓库里保持独立的提交记录。这样每次修改都能追踪改崩了随时回滚。迭代方向上优先级最高的是补齐边缘场景。一个技能包8成的使用场景是稳定的2成是特殊情况。这2成恰恰是用户最容易遇到、也最容易出问题的地方。每跑出一个不好用的案例就把它补进测试集然后针对性地优化步骤。测试集越厚技能包越稳。4.2 多场景复用一次沉淀多处调用技能包做多了之后你会开始发现一些通用的底层能力。比如“以中文输出简洁总结”就是一种能力很多技能都需要它。这类能力值得抽出来做成一个基础技能包供其他技能调用。做一个类比技能包和函数很像。函数解决的是“把一段逻辑封装起来供多处调用”的问题技能包解决的是“把一套经验封装起来供AI在多场景下复用”的问题。复用带来一个额外的好处你修复一个基础技能包里的bug所有依赖它的技能都跟着受益。这比在100个文档里分别改同一处错误效率高太多了。但复用也有风险。依赖关系一多改一个底层技能可能引起连锁反应。所以复用的原则是“宽进严出”基础技能包的描述要清晰稳定输出格式要有协议保障而上层技能包尽量只依赖稳定的那一层别把基础技能包的实现细节写死在上层逻辑里。4.3 组织级技能库从个人资产到团队基建当技能包从个人扩展到团队事情的性质就变了。个人技能库的核心是“帮自己省事”团队技能库的核心是“让团队更稳定地交付”。这两者的评价标准完全不同。个人技能库跑通一次就算成团队技能库要求的是不管谁操作、不管什么输入输出都保持稳定。团队技能库落地时比较有效的做法是“三个一”一个库、一个owner、一份评审流程。一个库指所有团队成员共用同一个技能库不要各建各的否则很快就碎片化。一个owner指每个核心技能包至少有一个明确的负责人谁写的谁维护其他人要修改先跟owner沟通。一份评审流程指新增或修改技能包时要走“提变更、跑测试用例、评审通过、合入”的流程跟代码合入的思路一样。这三件事看起来简单但真正落地时很多团队会栽在第二件上。没有owner技能包就成了孤儿出了问题没人改慢慢就没人用了。所以在线下建技能库时我总会先问一句谁负责这个包的长期维护如果没人接那就先不建。5. 常见问题与避坑记录5.1 把Skill写成字典有步骤但没有判断这是一个非常高发的坑。把Skill写成了“字典式”的说明比如“会议纪要会议信息讨论行动项”然后给一堆字段定义以为就完成了。但这只定义了“物理结构”没有定义“行为逻辑”。一个技能要真正好用核心是判断逻辑。什么时候提取行动项、怎么判断谁是负责人、如何处理会议中的跑题内容这些判断逻辑才是经验的核心。没有判断逻辑AI拿到字典也不知道怎么用。这就像你给一个人一份零件清单却不告诉他怎么组装。清单再详细也没用。5.2 技能包和SOP文档的区别在哪儿有朋友问过我这个Skill不就是SOP标准作业程序吗还真不是一回事。SOP文档的核心是流程标准化它假设执行者具备基础判断力能处理异常情况。技能包的核心是让AI或新人在缺少隐性经验的情况下也能完成高质量输出。它要求把隐性经验显性化、把判断标准明确化、把异常处理预案化。换个角度说SOP是写给懂行的人看的操作指引技能包是写给“不太懂但能力很强的执行体”看的完整方案。这两者的读者不同写法和颗粒度完全不同。5.3 过度抽象陷阱为通用而牺牲可用还有一种倾向也要警惕为了追求通用性把技能包做得过于抽象。比如做一个“通用内容生成技能”想着什么都能干结果哪个场景都干不好。合理的做法是宁可多建几个针对性强的技能包也别强行搞一个“万能包”。判断标准很简单如果一份描述里塞满了“各种情况下”“根据用户需求”“视情况而定”这类字样它大概率是个过度抽象的半成品。真正可用的技能包边界是清楚的描述是具体的触发条件是明确可判定的。5.4 常见问题速查表下面是几个高频问题的速查都是我踩过的坑问题现象根因解决思路AI在该触发技能时不触发when_to_use过泛或与其他技能重叠精确定义触发条件明确排除场景输出格式每次都不一样缺少输出模板或模板不够具体在references里放模板文件步骤中指定套用模板执行时遗漏关键步骤步骤描述缺少顺序约束使用“先…再…最后…”明确每步的输入输出改一处技能其他技能跟着坏依赖关系混乱没有版本管理建立依赖清单技能包独立版本控制技能包内容太多AI读不完单文件过大没有分层拆分为SKILL.md加references子文件技能包写好了但没人用无owner无维护计划指定负责人建立评审和更新机制这几条问题如果能提前规避你的技能库至少能少踩一半的坑。最后再分享一个我个人的体会技能库的建设本质上不是技术问题而是习惯问题。它真正的门槛不在怎么写SKILL.md而在于你有没有把一次偶然的成功经验当成一个值得沉淀的资产。很多次我接到一个棘手的任务跑通了觉得庆幸但没记录下来。下一次遇到类似任务又从零开始摸索。直到我习惯性地把每次“跑通”都变成“技能包”这种重复劳动才算真正结束。从今天开始挑一个你反复做过三次以上的任务把它写成第一个技能包。不用追求完整先写最小的可用版本然后在实践中慢慢补。你大概率会发现这件事比想象中简单也比想象中值钱。 从经验到资产：构建AI Agent可复用Skill技能库实战指南
第一次接触“skills”这个词是在整理团队SOP的时候。文档写了一堆目录建了十几个但真到用的时候才发现知道要做什么和知道怎么做完全是两回事。后来开始碰AI Agent相关的东西又撞见“skills”——只是这一次它的含义完全变了变成了给模型用的技能包把做事的流程、判断依据、避坑经验封装成一个可复用的单元。我花了一段时间才把这些概念理顺也踩了不少坑。如果你也在关注个人能力沉淀、团队知识管理或者正在折腾AI Agent这篇应该对你有用。我想聊的是一个更实际的问题怎么把零散的经验真正变成资产从设计、编写、验证到迭代完整搭出一套可复用的Skill技能库。1. 先想清楚Skill到底是什么1.1 一个词两个语境“skills”这个词现在存在两个语境很多人混着用结果讨论半天对不上。第一个语境是个人能力层面指专业技能、软技能、管理能力。这个层面讨论的是“人如何成长”比如沟通技巧、编程能力、谈判能力。它很重要但不是这篇文章的主角。第二个语境是AI Agent层面指给智能体准备的可执行能力包。你可以把它理解成一张“操作说明书”加“经验手册”的组合让AI在遇到特定任务时能按一个成熟流程去执行而不是每次从头开始瞎猜。这两个语境之间的关系也很有意思。个人技能是抽象的、隐性的存在脑子里的Skill技能包是具体的、显性的存在文件夹里的。把脑子里的经验外化成一份结构化的技能包这个过程本身就是在做知识显性化。我们团队后来沉淀了几十个这样的技能包才发现这比写一百页文档有用得多。1.2 为什么技能包比文档更值钱传统做知识管理大家习惯写文档操作手册、流程规范、FAQ。文档当然有用但它有几个硬伤。第一文档是给人看的不是给机器执行的。写的时候觉得“这么清楚肯定没人看不懂”但真用起来还是处处要人判断。第二文档是静态的一旦更新不及时反而变成误导。第三文档之间没有结构关联查A要翻B翻B又要看C效率极低。技能包解决的是另一个维度的问题它不只是“告诉你怎么做”而是“按这个方案就能跑通”。技能包内部有明确的触发条件、执行步骤、输出格式、避坑要点甚至可以直接作为AI Agent的一个能力单元被调用。我打个比方。文档相当于一本菜谱告诉你食材、步骤、火候但每一步都得你自己看着办。技能包相当于一位师傅站在旁边不仅告诉你步骤还会在关键节点提醒你“这个时候油温已经太高了”“这个调料千万别放多”“这个步骤如果出现XX情况就说明你前面做错了”。菜谱解决“知不知道”的问题师傅解决“做得成不成”的问题。所以如果你想做知识沉淀不要只停留在写文档。要把高价值的经验做成技能包让它们真正可复用、可执行、可验证。2. 从经验到技能包设计一个Skill的基本结构2.1 最小可用结构一个文件夹加一个描述文件一个技能包听起来很玄其实最小可用结构就两部分一个目录以及一个描述核心逻辑的文件。我习惯的目录结构是这样的skills/ └── meeting-minutes/ ├── SKILL.md ├── examples/ │ └── demo-input.txt └── references/ └── templates/SKILL.md 是整个技能包的大脑负责描述这个技能是干嘛的、什么时候该用、具体怎么执行。examples 目录放输入样例用来演示这个技能适用的任务长什么样。references 目录放模板和参考资料给执行过程提供素材。这个结构看起来简单但它背后有三个设计原则单一入口、渐进明细、边界清晰。单一入口指所有核心信息都从SKILL.md进去你不需要东翻西找一个技能包的核心逻辑在哪。渐进明细指主文件只写主干流程细节放在子文件里保证主文件不会变成一本500页的字典。边界清晰指这个技能包只管自己该管的不越界涉及其他任务。很多人在第一步就翻车把SKILL.md写成了一个超大文档什么都要收录结果AI读起来上下文爆炸人也看不下去。技能包没有规定一定要多大但一个健康的SKILL.md最好控制在几十行到一两百行之间。超过这个量级就要思考是不是该拆分了。2.2 元数据写清楚“何时用”比“怎么写”更重要设计技能包时大家通常会花很多精力写执行步骤但容易忽略最前面的元数据部分。我踩过这个坑之后才明白元数据才是整个技能包最值钱的部分。可以借助一个拟定的结构来看比较通用的几个字段是name、description、when_to_use、version、tags。--- name: meeting-minutes description: 生成结构化会议纪要支持中英文混合输入整理 when_to_use: 当用户提供会议录音转写文本、会议笔记草稿或要求生成会议纪要时 version: 1.0.0 tags: [会议, 纪要, 办公自动化] ---看起来很简单但每个字段背后都有讲究。description 不能只是“生成会议纪要”而要说明这个技能能处理什么输入、产生什么输出。因为AI在决定调用哪个技能时靠的就是这个描述。写得太泛AI会把不相干的任务也丢进来写得太窄该触发的时候不触发。when_to_use 是大多数新手会忽略的。它相当于触发条件告诉AI“什么场景下你应该选我”。这一条写得准技能被正确调用的概率会大幅提升。我见过一个反例有人写“当用户需要帮助时使用”这就是废话等于没说。when_to_use 一定要具体到任务特征比如“当输入包含RWKV格式的原始文本且用户要求整理为结构化条目时”。version 也很重要。技能包会持续迭代没有版本号你没法追溯某次行为变化是从哪个版本开始的。后面讲迭代管理时还会细说。2.3 把模糊经验翻译成可执行步骤这是技能包装写过程中最考验功力的一步。很多人在这一步会犯同一个毛病写得太抽象。比如写“分析用户情绪”“给出专业建议”这种话没有任何执行性。什么叫“分析情绪”看关键词看语气词看感叹号AI不知道人看完也不知道。把模糊经验翻译成可执行步骤核心是用“条件动作”的结构去表达遇到什么情况就做什么动作。拿“会议纪要”技能来举例。关于“纪要格式”的模糊经验是“要重点记录决策和行动项”。翻译成可执行内容就变成了1. 从转写文本中提取所有决策事项 - 判断标准出现“决定了”“就这么定”“一致同意”等表述 2. 从转写文本中提取行动项 - 每条记录包含负责人、截止时间、具体动作、关联背景 - 如果文本中没有明确说出负责人标注“待确认”不要自行编造 3. 区分事实陈述和个人观点 - 事实陈述保留原意个人观点用“讨论”后缀标注你会发现可执行的步骤有几个特点有判断标准、有边界条件、有不可做的事项。判断标准让AI知道“什么时候算命中”边界条件让它知道“什么是特殊情况”不可做的事项直接规避了AI常见的“编造信息”问题。我后来给团队定了一个“步骤四要素”原则动作要单一、条件要可判断、输出要明确、边界要清晰。满足这四个要素的步骤才叫可执行。3. 实操从0到1搭一个可用的技能库3.1 命名、目录与版本规范动手写之前先定好规范。没有规范的技能库几个月之后就变成一片混乱。命名建议用短横线分隔的小写英文比如meeting-minutes、># 会议纪要技能 把会议内容整理成纪要。就这么两句没了。我立刻发现根本不能用整理成什么格式按什么结构判断标准是什么全部缺失。第二版我加了步骤但还不够。第三版我才慢慢补齐。后来一个可用的版本大概长这样--- name: meeting-minutes description: 将会议录音转写文本或会议笔记草稿整理为结构化的会议纪要输出决策、行动项和待讨论事项 when_to_use: 当输入包含会议转写文本、会议笔记或明确要求生成会议纪要时 version: 1.2.0 tags: [会议, 纪要, 办公自动化] --- # 产出格式 纪要包含四个部分按顺序输出 1. 会议概况会议主题、时间、参会人从文本中提取缺失则标注“未提及” 2. 关键讨论按话题分组每个话题列出核心论点 3. 决策事项列出所有已确定结论标注决策背景 4. 行动项每条包含负责人、截止时间、动作描述缺失信息标注“待确认” # 执行步骤 1. 通读全文按话题给文本分段 2. 提取决策事项判断标准出现“决定”“就这么定”“一致同意”等表述 3. 提取行动项判断标准出现“需要”“负责”“跟进”等动词结合上下文确认责任主体 4. 过滤寒暄和无关闲聊不写入纪要 5. 使用简洁书面语输出保留原始结论的关键措辞 6. 如果文本存在明显信息缺失在对应位置标注“待确认”不自行补全 # 边界 - 只处理与会议内容相关的信息 - 不添加原文没有的结论 - 不改变原文表述中的关键意思这个版本比第一版好用得多。为什么因为每个环节都有了可判断的标准AI知道怎么提取、怎么过滤、怎么做取舍。后来我又在references里加了模板文件让AI可以套用统一的格式输出。3.3 验证与测试技能能跑通吗写完技能包之后最重要的一步是验证。这一步我强烈建议你准备至少5个不同的测试输入。测试输入要覆盖正常场景、边界场景和异常场景。正常场景是标准输入边界场景是输入特别长、特别短、混杂其他内容异常场景是输入和目标任务完全不匹配。每跑一个测试输入都记录两个东西输出结果是否符合预期以及AI是否在正确的时机调用了这个技能。这一套跑下来你通常会发现几类问题第一是触发不灵敏。你精心写的when_to_useAI根本不理。这时候不要急着改描述先看看你是不是把技能说得太大路货了。比如一个“整理会议纪要”的技能和一个“生成待办事项”的技能在很多情况下触发条件有重叠AI就会分不清。你要做的不是堆更多形容词而是把两个技能的边界划清楚。第二是步骤顺序不清。AI在执行时有时候会跳步或者反复执行某一步。这个大概率是你在步骤描述里缺少前置条件和终止条件。比如“提取行动项”之前要说清楚“只由最终确认过的文本中提取不包括讨论过程中的假设”。第三是发挥不稳定。同一个输入跑两次结果差别很大。这种情况多半是步骤里夹带了模糊要求比如“合理整理”“适当补充”解决办法是给AI更明确的规则把“合理”替换成具体判断标准。验证环节没有捷径就是反复跑、反复改。但跑过几轮之后技能包的稳定性会有质的提升。4. 迭代与分享技能库的生命力4.1 版本管理改技能比写技能更容易翻车很多人在技能包刚跑通之后就停止了迭代觉得“能用就行了”。但真实情况是技能包的生命力在于持续迭代。不过改技能比写技能更容易翻车这一点我教训很深。有一次我为了让一个“周报生成”技能支持英文输入顺手调整了输出模板。结果中文周报的输出格式也变了测试时全乱套还影响到了其他技能在引用这个模板时的表现。那次之后我养成了两个习惯。第一个习惯是任何修改都先看影响范围。技能包不是孤岛它可能被其他技能包引用也可能被自动化流程调用。改一个步骤之前先查一下谁在引用它。第二个习惯是改动要可回滚。没有版本管理改崩了就是改崩了。我把每个技能包做成一个独立的git仓库或者至少在一个大的仓库里保持独立的提交记录。这样每次修改都能追踪改崩了随时回滚。迭代方向上优先级最高的是补齐边缘场景。一个技能包8成的使用场景是稳定的2成是特殊情况。这2成恰恰是用户最容易遇到、也最容易出问题的地方。每跑出一个不好用的案例就把它补进测试集然后针对性地优化步骤。测试集越厚技能包越稳。4.2 多场景复用一次沉淀多处调用技能包做多了之后你会开始发现一些通用的底层能力。比如“以中文输出简洁总结”就是一种能力很多技能都需要它。这类能力值得抽出来做成一个基础技能包供其他技能调用。做一个类比技能包和函数很像。函数解决的是“把一段逻辑封装起来供多处调用”的问题技能包解决的是“把一套经验封装起来供AI在多场景下复用”的问题。复用带来一个额外的好处你修复一个基础技能包里的bug所有依赖它的技能都跟着受益。这比在100个文档里分别改同一处错误效率高太多了。但复用也有风险。依赖关系一多改一个底层技能可能引起连锁反应。所以复用的原则是“宽进严出”基础技能包的描述要清晰稳定输出格式要有协议保障而上层技能包尽量只依赖稳定的那一层别把基础技能包的实现细节写死在上层逻辑里。4.3 组织级技能库从个人资产到团队基建当技能包从个人扩展到团队事情的性质就变了。个人技能库的核心是“帮自己省事”团队技能库的核心是“让团队更稳定地交付”。这两者的评价标准完全不同。个人技能库跑通一次就算成团队技能库要求的是不管谁操作、不管什么输入输出都保持稳定。团队技能库落地时比较有效的做法是“三个一”一个库、一个owner、一份评审流程。一个库指所有团队成员共用同一个技能库不要各建各的否则很快就碎片化。一个owner指每个核心技能包至少有一个明确的负责人谁写的谁维护其他人要修改先跟owner沟通。一份评审流程指新增或修改技能包时要走“提变更、跑测试用例、评审通过、合入”的流程跟代码合入的思路一样。这三件事看起来简单但真正落地时很多团队会栽在第二件上。没有owner技能包就成了孤儿出了问题没人改慢慢就没人用了。所以在线下建技能库时我总会先问一句谁负责这个包的长期维护如果没人接那就先不建。5. 常见问题与避坑记录5.1 把Skill写成字典有步骤但没有判断这是一个非常高发的坑。把Skill写成了“字典式”的说明比如“会议纪要会议信息讨论行动项”然后给一堆字段定义以为就完成了。但这只定义了“物理结构”没有定义“行为逻辑”。一个技能要真正好用核心是判断逻辑。什么时候提取行动项、怎么判断谁是负责人、如何处理会议中的跑题内容这些判断逻辑才是经验的核心。没有判断逻辑AI拿到字典也不知道怎么用。这就像你给一个人一份零件清单却不告诉他怎么组装。清单再详细也没用。5.2 技能包和SOP文档的区别在哪儿有朋友问过我这个Skill不就是SOP标准作业程序吗还真不是一回事。SOP文档的核心是流程标准化它假设执行者具备基础判断力能处理异常情况。技能包的核心是让AI或新人在缺少隐性经验的情况下也能完成高质量输出。它要求把隐性经验显性化、把判断标准明确化、把异常处理预案化。换个角度说SOP是写给懂行的人看的操作指引技能包是写给“不太懂但能力很强的执行体”看的完整方案。这两者的读者不同写法和颗粒度完全不同。5.3 过度抽象陷阱为通用而牺牲可用还有一种倾向也要警惕为了追求通用性把技能包做得过于抽象。比如做一个“通用内容生成技能”想着什么都能干结果哪个场景都干不好。合理的做法是宁可多建几个针对性强的技能包也别强行搞一个“万能包”。判断标准很简单如果一份描述里塞满了“各种情况下”“根据用户需求”“视情况而定”这类字样它大概率是个过度抽象的半成品。真正可用的技能包边界是清楚的描述是具体的触发条件是明确可判定的。5.4 常见问题速查表下面是几个高频问题的速查都是我踩过的坑问题现象根因解决思路AI在该触发技能时不触发when_to_use过泛或与其他技能重叠精确定义触发条件明确排除场景输出格式每次都不一样缺少输出模板或模板不够具体在references里放模板文件步骤中指定套用模板执行时遗漏关键步骤步骤描述缺少顺序约束使用“先…再…最后…”明确每步的输入输出改一处技能其他技能跟着坏依赖关系混乱没有版本管理建立依赖清单技能包独立版本控制技能包内容太多AI读不完单文件过大没有分层拆分为SKILL.md加references子文件技能包写好了但没人用无owner无维护计划指定负责人建立评审和更新机制这几条问题如果能提前规避你的技能库至少能少踩一半的坑。最后再分享一个我个人的体会技能库的建设本质上不是技术问题而是习惯问题。它真正的门槛不在怎么写SKILL.md而在于你有没有把一次偶然的成功经验当成一个值得沉淀的资产。很多次我接到一个棘手的任务跑通了觉得庆幸但没记录下来。下一次遇到类似任务又从零开始摸索。直到我习惯性地把每次“跑通”都变成“技能包”这种重复劳动才算真正结束。从今天开始挑一个你反复做过三次以上的任务把它写成第一个技能包。不用追求完整先写最小的可用版本然后在实践中慢慢补。你大概率会发现这件事比想象中简单也比想象中值钱。