最近这一个月我没干别的就专心折腾一件事把散落在各种对话里的临时任务变成一套可以被AI助手按需调用的技能包。所谓技能包你可以理解成给大模型外挂的一组说明书、脚本和参考数据用户发起对应需求时Agent自动加载那一套能力而不是每次都在上下文里重新教一遍。今天想把整个过程从设计到排错从头讲一遍尤其适合那些想把日常重复工作沉淀成可复用资产的开发者或重度使用者。做了三四个技能之后我最深的体会是一个合格的技能包解决三个问题——触发稳定、执行可预期、失败可回退。触发说的是模型能不能在恰当的时机把技能拿出来用执行说的是加载之后能不能按照你设计的路径把活干完回退说的是遇到边界场景时Agent能不能体面地收场而不是直接胡编。下面按这个主线展开全程不讲花架子只讲能落地的做法。1. 技能包的定位先想清楚它到底是什么再动手写1.1 一次能力封装而不是一个万能提示词先说清楚我理解的“开发各种skills”到底是做什么。这里说的技能不是模型本身的通用能力而是建立在某个AI助手平台之上的一层自定义能力封装通常由一个描述文件、若干指令文本、少量辅助脚本和参考素材组成。它的表现很像给Agent装了一个“可插拔的外挂”平时不占用资源用户一提出相关需求它就被自动识别并加载。很多人会把这个东西跟“长提示词”画等号觉得技能包不过就是把提示词整理得更规范而已。实践下来区别很大。长提示词是塞进会话里的一份固定说明书无论什么任务都在场内容稍长就会挤压对话空间还会干扰模型对当前任务的注意力。技能包则是按需加载的加载时才进入上下文任务结束后又可以卸载会话主干始终保持干净。打个比方去饭店吃饭。提示词像是你身后一直站着一个服务员不管点什么菜他都把整本菜谱背给你听技能包则是后厨的几套固定流程你说要红烧肉后厨只有那一刻才翻出红烧肉的做法平时那些流程都在柜子里放着不影响你做别的事。这个区别决定了技能包在复杂工作流里的价值它是可独立设计、独立测试、独立替换的组件。那什么样的情况不需要做技能包我自己的判断标准是这个任务在未来一个月内会不会出现三次以上如果答案是不会就不要做。技能包本质是给“频繁发生且结构稳定”的任务建立标准动作一次性任务直接写提示词就够了强行封装反而浪费时间制造一堆没人再用的僵尸资产。所以动手之前先花十分钟回答一个元问题这项任务有没有值得沉淀的共性1.2 三个设计支柱意图识别、执行路径、验证回退一个技能包能在实战中站稳靠的是三个支柱。第一个是意图识别也就是Agent得明白“什么时候该用这个技能、什么时候不该用”。这主要靠技能包里的描述文件解决描述写得好触发就精准描述写得太泛模型就会到处乱用。第二个是执行路径也就是技能内部的指令和脚本它决定任务被加载后能不能按预设流程走完。第三个是验证回退也就是技能输出结果的检查方式以及遇到异常时的处理策略。这三个支柱之间有明显的优先级意图识别错了执行路径再完美也白搭因为技能根本没被正确加载执行路径不完整活干到一半模型容易自己改规则输出就不可控验证回退缺失模型会在拿不准时仍然硬着头皮给结果错误就悄无声息地溜过去。所以我开发技能的顺序永远是先逼自己想清楚触发条件再设计执行步骤最后才写脚本和处理分支。一个优秀的技能包还应该具备“体面失败”的能力。所谓体面失败就是模型在执行过程中发现自己不适合处理当前输入时能够输出一个明确的提示而不是给出一个看似正确实则离谱的结果。这句话很多人不当回事但在真实业务里极其重要——我见过很多次Agent把一个不合规的输入硬生生处理成完整的产品生成结论时还说的头头是道后续排查成本远高于直接承认处理不了。2. 动手前的规范化统一结构、命名与核心字段2.1 一套固定目录而不是一地散文件如果你只打算给自己的助手配一两个技能规范似乎可有可无可一旦要同时维护十几个技能没有统一的目录结构技能很快会失控。我一开始就犯过这个错误每个技能的文件组织方式完全随心情有的把脚本放在根目录有的塞在子文件夹里结果想找某个文件时翻半天最后只能重新建一个。后面吃了亏才总结出一套比较顺手的目录模板my-skills/ ├─ document-splitter/ │ ├─ SKILL.md │ ├─ scripts/ │ │ ├─ split_markdown.py │ │ └─ requirements.txt │ ├─ references/ │ │ └─ format_guide.md │ └─ examples/ │ ├─ input.md │ └─ output.json ├─>--- name: document-splitter description: 当用户需要对长文档进行章节拆分、重组、定位或提取时使用。 典型触发词包括拆分、章节、一级标题、目录、提取第N章、重排。 如果输入文本少于800字或者用户只是想了解文章大意不要使用本技能。 instructions: | 1. 识别输入文本的一级标题记录每个标题的位置和序号。 2. 如果标题数量少于2个改用二级标题作为切分依据。 3. 按照标题位置切割内容并将代码块视为不可拆分单元。 4. 对每个章节生成10到30字的中文摘要。 5. 最终输出JSON数组字段为level、title、content、summary。 examples: | 输入# 第一章 概述... 输出[{level:1,title:第一章 概述,content:...,summary:...}] error_policy: | 如果无法识别任何标题不要强行拆分直接输出错误信息。description里我特意加了反例强调低于800字不要使用这能显著减少误触发。instructions则保持了强顺序逻辑从识别标题到切分、摘要、输出一条线走下来模型不太会中途走错路。error_policy看起来很不起眼但它避免了一个致命问题——当模型面对一篇没有完整标题的文本时会强行编造章节结构输出一份看似漂亮的“假目录”这比输出错误信息更糟糕因为后续环节会把这份假目录当真实文档用。3.3 第三步写辅助脚本把机械操作彻底定下来既然切分工作是纯规则的我就写了一个Python脚本负责切分模型只需要负责语义摘要和JSON组装。脚本的核心逻辑是扫描Markdown里的标题行记录它们的位置和层级再按位置把内容切块。下面是这个脚本的关键部分我精简了注释但保留了完整逻辑import re def split_markdown(text): lines text.splitlines() sections [] current None for index, line in enumerate(lines): m re.match(r^(#{1,3})\s(.)$, line) if m: if current: sections.append(current) level len(m.group(1)) title m.group(2).strip() current { start: index, level: level, title: title, content_lines: [line], } else: if current is not None: current[content_lines].append(line) if current: sections.append(current) result [] for section in sections: content \n.join(section[content_lines]).strip() result.append({ level: section[level], title: section[title], content: content, }) return result这个脚本本身并不复杂但它解决的是模型在做切分时的一个通病模型会把“代码块里的#注释”错误识别成标题也会在切分时漏掉某些空行。脚本一旦接管这一步模型只需要拿到切好的块然后逐块做摘要和判断既快了也更不容易出错。脚本通过标准输入读取文本输出标准JSON模型只需把摘要字段补上就可以直接输出最终结果。脚本写完后一定要为它造一批测试文本。不要只测那些规规矩矩的文章还要测那些没有一级标题、只有三级标题、包含代码块、标题和正文挤在同一行的用例。我测试时发现正则表达式在处理带有特殊标题符号时偶尔会误判后来加上了更严格的行首锚定才通过。这些边界测试看似增加工作量但真实场景里最常规的文本往往特别少非常规文本才是大多数。3.4 第四步在真实对话环境里联调与回退验证脚本写完不等于技能开发完还要把整个技能包放进Agent环境里做联调。我习惯用一个固定测试用例清单来跑比如“请拆分这篇文章”和“提取第五章”这两类说法要能触发技能而“帮我看看这篇文章的中心思想”这种说法则必须不触发。每调整一次description就重新跑一遍测试观察Agent的选择路径和输出结果。联调阶段我最关注回退行为。有一次我故意输入一篇纯表格文本没有任何标题Agent当时做出的选择让我十分意外——它给我返回了一份完整的拆分计划从“第一章”到“第十章”全都拟好了。这就是典型的不体面失败模型没有标题也要造出标题因为它在迎合用户。后来我在error_policy里写了明确指引并在instructions里加了条件判断标题数量小于2直接终止。这样一改模型遇到无标题文档时就会老老实实说明失败原因而不是继续硬编。4. 多技能并行开发三种典型技能的设计差异4.1 第二类技能数据清洗技能核心在“少让模型做计算”在我的技能库清单里除了文档拆分还有一类高频使用的技能是数据清洗。它的典型场景是用户拿着一份混乱的CSV或者Excel内容希望去重、修正日期格式、补齐缺失值、统一单位。这类任务如果只用提示词让模型去做模型会涮一遍但它对表格里具体数值的处理时对时错尤其是日期和浮点数。数据清洗技能的设计思路和文档拆分完全相反——能用代码完成的环节尽量用代码完成。我会写一个Python脚本处理所有确定性操作去除重复行、把五花八门的日期格式统一成ISO格式、将带单位的文本拆成数值和单位两个字段。模型只负责一个任务根据用户描述判断哪些列是日期、哪些列是数值然后把判断结果传给脚本。模型判断好语义脚本落地执行这是数据类技能最稳妥的分工方式。设计这种技能时有一个坑特别值得提代码算出来的结果和模型读到的结果出现冲突。比如脚本对某个价格字段做了去重但模型在处理下一张表时又把这个价格字段视作原始数据。为了解决这个问题我在技能里强制要求脚本输出一份“变更说明”模型必须把这份变更说明一并呈现给用户让用户知道哪些行被去掉、哪些值被修正。数据类任务最忌讳的是“悄悄处理”可见性就是可信度。4.2 第三类技能代码审查技能核心在“引用规范而非复述规范”第三种技能是代码审查。代码审查技能的目标是让Agent读一段源码之后按团队的编码规范给出批注列表。这类任务最常犯的错误是把几十页的编码规范整个塞进提示词里因为说明书太长模型在实际审查时只能记住开头的几页后面的规则全被忽略。我在设计代码审查技能时采取了一种更节省的做法不把规范全文写进指令而是保存一份单独的局面规范文件放在references目录下instructions里只写“审查时依次对照references/encoding_rules.md中的规则并给出违反规则的位置和修改建议”。模型在处理具体代码时按需读取规范章节等于把一份大部头字典放在了手边而不是强迫它把整本字典背下来。这个技能还有一个特殊处理它不直接修改代码只输出评审意见。我发现如果指令让技能“直接修改代码”模型很容易在不懂项目整体架构的情况下把代码改错或在多个技术栈之间迷失方向。评审意见模式则限制了风险范围——Agent只负责挑毛病和给建议是否修改、怎么修改由开发者决定。一个技能能做的越少反而越可靠这是我在多技能开发中反复印证的一点。4.3 第四类技能内容排版技能核心在“用示例代替道理”还有一类技能适合用少样本示例来驱动我可以拿内容排版举例。某个团队要维护一系列公众号风格的推送要求标题不超过24个字、段落之间必须空行、引用部分不能连续超过5行、结尾需要一段统一风格的主编短评。这些规则用文字列出来模型总能漏掉一两条但改成给它两三个“输入原文、输出排版结果”的完整示例它就能通过类比学会整套规范。内容排版技能的结构因此很特殊SKILL.md里的instructions特别短只有“参考examples目录中的排版示例将输入文本按相同风格输出”这样一句话真正的规则全部藏在示例中。这背后的道理很朴素模型对具体例子的模仿能力远强于对抽象规则的遵循能力。你在指令里写“保持风格一致”模型不知道风格是什么但你给它三组排完版的对照样本它自己就能归纳出风格的内涵。需要注意的是示例要覆盖“极端情况”不能全选好样本。比如一个示例专门展示“引用内容超过5行时如何合并”另一个示例专门展示“标题字太多时如何删减”。只给好样本会让技能在新的复杂输入前不知所措给几个坏样本并附上“这是错误做法”的标注模型反而能学到边界在哪里。5. 开发过程中最常踩的坑与排查方法5.1 技能总是触发不了问题往往在描述文件多技能开发一段时间后你会发现大量问题都出在“触发链路”上而不是技能内部的指令逻辑。最典型的现象是你明明设计了一个技能用户说的话跟触发词也沾边Agent就是不加载它。排查第一步是看该技能的description里是否把触发场景写清楚了。我见过很多设计者只写“用于处理XX任务”没有给出关键词、没有给出反例Agent每次都得猜测猜错率自然高。我自己的排查方法是做触发实验准备一组经过标记的有效输入和无效输入逐一让Agent判断是否应该加载该技能然后把判断结果统计成表格。实验中如果发现技能总是有些该触发时不触发的情况我会在description里增加场景化描述比如“当用户提到某关键词或表达出某类诉求时使用”如果发现大量不该触发时反而触发我会重点补充反例。这个实验每次改完description都要重跑一遍是保证触发稳定性的基本功。5.2 技能与技能之间串台边界没有划干净当技能数量多到十个以上新的问题就出现了两个技能的边界互相重叠Agent经常加载错。比如我的“文档拆分技能”和另一个“长文摘要技能”都是在处理同一个长文档表面看确实很像。如果描述文件里没有写清楚分工Agent可能把拆分任务交给摘要技能输出一堆段落大意而不是拆分结果。划清边界靠两件事一处是描述里的“明确分工”一处是技能内的“使用条件”。我会在document-splitter的描述里写“重点在于按照标题切分”在长文摘要技能的描述里写“重点在于概括整体内容不对章节做切分”。当两个技能边界实在无法完全分开时我会选择把其中一个技能做成另一个的操作选项比如让摘要技能在判断需要拆解时调用拆分技能而不是各自为政。5.3 上下文被技能说明撑爆加载即卡死另一个隐蔽问题是上下文膨胀。有些技能为了把指令写全把几十年行业经验都塞进了instructions一份SKILL.md就动辄两三千字。这会导致一个结果技能一加载模型的可用上下文就被吃掉一大块后面处理任务时反而缩手缩脚。这也是我前面强调references目录的原因——长资料应该放到引用文件而不是全部堆在入口卡片里。如果技能确实需要大量背景知识建议把知识拆成多个小文件并让instructions明确“遇到哪类问题才读取哪个文件”。这样做的好处是多数任务只需要模型读取其中一两个文件上下文消耗被控制在合理范围而且模型不会因为一次性读太多材料而欺骗注意力。上下文就像工具箱技能应该是一把精装的螺丝刀而不是一整辆工具车。5.4 脚本执行失败与路径错误脚本类技能还有一个高频故障来源路径问题。技能包从一个环境搬迁到另一个环境时脚本里的绝对路径很容易失效。我吃过一次亏把整个技能库从笔记本迁到服务器后数据清洗脚本找不到了引用文件的位置Agent连着报错。后来我定了一个规矩所有技能包内部引用必须用相对路径并且脚本入口统一通过一个总入口文件比如run.py启动运行时基于脚本所在目录解析所有路径。另外脚本的参数传递方式要简单且标准。我通常让脚本通过标准输入读取原始数据通过标准输出返回结果避免依赖临时文件。临时文件在并发任务里很容易互相覆盖一次两个Agent同时在跑同一技能脚本就乱了。把输入输出都约束在进程内部基本能绕开这类偶发故障排查成本也最低。6. 技能库的维护与持续演进做有用的资产而不是摆设6.1 建立技能清单与回归测试集当技能数量上来之后维护成本会直线上升。单纯靠在对话里测试变得不可行所以我建了一张技能清单表格记录每个技能的边界、触发词、最近改动时间和依赖脚本。这张表格最简单但作用巨大每当我修改一个技能我可以快速看到哪些其他技能可能与它共享脚本或重叠边界从而提前评估改动影响。更重要的是回归测试集。我把每个技能对应的有效输入和无效输入样本整理成固定文件每次修改后运行一遍完整测试。花的时间不长但能拦住绝大多数低级回归。有一次我自以为只改了一个技能的一处说明结果运行回归测试后发现另一个技能被连带影响了因为它们的描述文件里用了同一条触发词。没有回归测试这种问题就会在线上悄无声息地爆发。6.2 效果的回收与迭代更新技能不是写完就结束它是一个需要持续喂养的资产。我通常留一个专门的动作每跑完一个真实任务把用户反馈记下来判断是“描述问题”还是“流程问题”还是“脚本问题”然后回到对应环节修改。这个闭环做完几轮之后技能会越来越贴合实际需求而不是停留在最初的设计假想里。有一点要特别提醒不要一发现问题就急着改。先攒一批问题分类后再统一修改每次改完重跑回归测试。频繁地小修小改容易让技能进入一种“按下葫芦浮起瓢”的状态改一次惹出一堆新故障。我一直以来的心态是技能库是为未来服务的今天的克制会减少明天的大面积返工。6.3 把可用技能当成标准操作程序来运营实战到后期你手里的技能包已经不只是一堆技术文件它更像一组标准操作程序。当你把某项工作的执行顺序、判断标准和失败处理都固定成技能后团队里任何人面对同一类任务都能得到一致的AI辅助结果。这比一段纯口头约定要可复制得多因为它把老员工的经验沉淀成了可执行文件。我个人在实际操作中还有个习惯每个技能都会配一段简短的使用说明放在仓库的README里说明这个技能面向什么任务、什么时候不要用、如果出错要找谁。很多技术能力做出来了没人用不是因为它不好而是因为别人不知道它好在哪里。把技能当成一个内部产品来运营写清楚使用场景和边界它才会真正活起来。这些技能开发下来我最大的收获倒不是效率提升了多少而是被迫把很多模糊的、靠感觉的日常任务重新梳理了一遍。你能把一个任务变成技能说明你真的理解了它你理解得越深技能就越稳定越能省下你脑子里的带宽去处理更复杂的判断。这就是我为什么坚持把各种技能一个个开发出来省下的是重复劳动换来的是更多可以自由支配的注意力。
最近这一个月我没干别的就专心折腾一件事把散落在各种对话里的临时任务变成一套可以被AI助手按需调用的技能包。所谓技能包你可以理解成给大模型外挂的一组说明书、脚本和参考数据用户发起对应需求时Agent自动加载那一套能力而不是每次都在上下文里重新教一遍。今天想把整个过程从设计到排错从头讲一遍尤其适合那些想把日常重复工作沉淀成可复用资产的开发者或重度使用者。做了三四个技能之后我最深的体会是一个合格的技能包解决三个问题——触发稳定、执行可预期、失败可回退。触发说的是模型能不能在恰当的时机把技能拿出来用执行说的是加载之后能不能按照你设计的路径把活干完回退说的是遇到边界场景时Agent能不能体面地收场而不是直接胡编。下面按这个主线展开全程不讲花架子只讲能落地的做法。1. 技能包的定位先想清楚它到底是什么再动手写1.1 一次能力封装而不是一个万能提示词先说清楚我理解的“开发各种skills”到底是做什么。这里说的技能不是模型本身的通用能力而是建立在某个AI助手平台之上的一层自定义能力封装通常由一个描述文件、若干指令文本、少量辅助脚本和参考素材组成。它的表现很像给Agent装了一个“可插拔的外挂”平时不占用资源用户一提出相关需求它就被自动识别并加载。很多人会把这个东西跟“长提示词”画等号觉得技能包不过就是把提示词整理得更规范而已。实践下来区别很大。长提示词是塞进会话里的一份固定说明书无论什么任务都在场内容稍长就会挤压对话空间还会干扰模型对当前任务的注意力。技能包则是按需加载的加载时才进入上下文任务结束后又可以卸载会话主干始终保持干净。打个比方去饭店吃饭。提示词像是你身后一直站着一个服务员不管点什么菜他都把整本菜谱背给你听技能包则是后厨的几套固定流程你说要红烧肉后厨只有那一刻才翻出红烧肉的做法平时那些流程都在柜子里放着不影响你做别的事。这个区别决定了技能包在复杂工作流里的价值它是可独立设计、独立测试、独立替换的组件。那什么样的情况不需要做技能包我自己的判断标准是这个任务在未来一个月内会不会出现三次以上如果答案是不会就不要做。技能包本质是给“频繁发生且结构稳定”的任务建立标准动作一次性任务直接写提示词就够了强行封装反而浪费时间制造一堆没人再用的僵尸资产。所以动手之前先花十分钟回答一个元问题这项任务有没有值得沉淀的共性1.2 三个设计支柱意图识别、执行路径、验证回退一个技能包能在实战中站稳靠的是三个支柱。第一个是意图识别也就是Agent得明白“什么时候该用这个技能、什么时候不该用”。这主要靠技能包里的描述文件解决描述写得好触发就精准描述写得太泛模型就会到处乱用。第二个是执行路径也就是技能内部的指令和脚本它决定任务被加载后能不能按预设流程走完。第三个是验证回退也就是技能输出结果的检查方式以及遇到异常时的处理策略。这三个支柱之间有明显的优先级意图识别错了执行路径再完美也白搭因为技能根本没被正确加载执行路径不完整活干到一半模型容易自己改规则输出就不可控验证回退缺失模型会在拿不准时仍然硬着头皮给结果错误就悄无声息地溜过去。所以我开发技能的顺序永远是先逼自己想清楚触发条件再设计执行步骤最后才写脚本和处理分支。一个优秀的技能包还应该具备“体面失败”的能力。所谓体面失败就是模型在执行过程中发现自己不适合处理当前输入时能够输出一个明确的提示而不是给出一个看似正确实则离谱的结果。这句话很多人不当回事但在真实业务里极其重要——我见过很多次Agent把一个不合规的输入硬生生处理成完整的产品生成结论时还说的头头是道后续排查成本远高于直接承认处理不了。2. 动手前的规范化统一结构、命名与核心字段2.1 一套固定目录而不是一地散文件如果你只打算给自己的助手配一两个技能规范似乎可有可无可一旦要同时维护十几个技能没有统一的目录结构技能很快会失控。我一开始就犯过这个错误每个技能的文件组织方式完全随心情有的把脚本放在根目录有的塞在子文件夹里结果想找某个文件时翻半天最后只能重新建一个。后面吃了亏才总结出一套比较顺手的目录模板my-skills/ ├─ document-splitter/ │ ├─ SKILL.md │ ├─ scripts/ │ │ ├─ split_markdown.py │ │ └─ requirements.txt │ ├─ references/ │ │ └─ format_guide.md │ └─ examples/ │ ├─ input.md │ └─ output.json ├─>--- name: document-splitter description: 当用户需要对长文档进行章节拆分、重组、定位或提取时使用。 典型触发词包括拆分、章节、一级标题、目录、提取第N章、重排。 如果输入文本少于800字或者用户只是想了解文章大意不要使用本技能。 instructions: | 1. 识别输入文本的一级标题记录每个标题的位置和序号。 2. 如果标题数量少于2个改用二级标题作为切分依据。 3. 按照标题位置切割内容并将代码块视为不可拆分单元。 4. 对每个章节生成10到30字的中文摘要。 5. 最终输出JSON数组字段为level、title、content、summary。 examples: | 输入# 第一章 概述... 输出[{level:1,title:第一章 概述,content:...,summary:...}] error_policy: | 如果无法识别任何标题不要强行拆分直接输出错误信息。description里我特意加了反例强调低于800字不要使用这能显著减少误触发。instructions则保持了强顺序逻辑从识别标题到切分、摘要、输出一条线走下来模型不太会中途走错路。error_policy看起来很不起眼但它避免了一个致命问题——当模型面对一篇没有完整标题的文本时会强行编造章节结构输出一份看似漂亮的“假目录”这比输出错误信息更糟糕因为后续环节会把这份假目录当真实文档用。3.3 第三步写辅助脚本把机械操作彻底定下来既然切分工作是纯规则的我就写了一个Python脚本负责切分模型只需要负责语义摘要和JSON组装。脚本的核心逻辑是扫描Markdown里的标题行记录它们的位置和层级再按位置把内容切块。下面是这个脚本的关键部分我精简了注释但保留了完整逻辑import re def split_markdown(text): lines text.splitlines() sections [] current None for index, line in enumerate(lines): m re.match(r^(#{1,3})\s(.)$, line) if m: if current: sections.append(current) level len(m.group(1)) title m.group(2).strip() current { start: index, level: level, title: title, content_lines: [line], } else: if current is not None: current[content_lines].append(line) if current: sections.append(current) result [] for section in sections: content \n.join(section[content_lines]).strip() result.append({ level: section[level], title: section[title], content: content, }) return result这个脚本本身并不复杂但它解决的是模型在做切分时的一个通病模型会把“代码块里的#注释”错误识别成标题也会在切分时漏掉某些空行。脚本一旦接管这一步模型只需要拿到切好的块然后逐块做摘要和判断既快了也更不容易出错。脚本通过标准输入读取文本输出标准JSON模型只需把摘要字段补上就可以直接输出最终结果。脚本写完后一定要为它造一批测试文本。不要只测那些规规矩矩的文章还要测那些没有一级标题、只有三级标题、包含代码块、标题和正文挤在同一行的用例。我测试时发现正则表达式在处理带有特殊标题符号时偶尔会误判后来加上了更严格的行首锚定才通过。这些边界测试看似增加工作量但真实场景里最常规的文本往往特别少非常规文本才是大多数。3.4 第四步在真实对话环境里联调与回退验证脚本写完不等于技能开发完还要把整个技能包放进Agent环境里做联调。我习惯用一个固定测试用例清单来跑比如“请拆分这篇文章”和“提取第五章”这两类说法要能触发技能而“帮我看看这篇文章的中心思想”这种说法则必须不触发。每调整一次description就重新跑一遍测试观察Agent的选择路径和输出结果。联调阶段我最关注回退行为。有一次我故意输入一篇纯表格文本没有任何标题Agent当时做出的选择让我十分意外——它给我返回了一份完整的拆分计划从“第一章”到“第十章”全都拟好了。这就是典型的不体面失败模型没有标题也要造出标题因为它在迎合用户。后来我在error_policy里写了明确指引并在instructions里加了条件判断标题数量小于2直接终止。这样一改模型遇到无标题文档时就会老老实实说明失败原因而不是继续硬编。4. 多技能并行开发三种典型技能的设计差异4.1 第二类技能数据清洗技能核心在“少让模型做计算”在我的技能库清单里除了文档拆分还有一类高频使用的技能是数据清洗。它的典型场景是用户拿着一份混乱的CSV或者Excel内容希望去重、修正日期格式、补齐缺失值、统一单位。这类任务如果只用提示词让模型去做模型会涮一遍但它对表格里具体数值的处理时对时错尤其是日期和浮点数。数据清洗技能的设计思路和文档拆分完全相反——能用代码完成的环节尽量用代码完成。我会写一个Python脚本处理所有确定性操作去除重复行、把五花八门的日期格式统一成ISO格式、将带单位的文本拆成数值和单位两个字段。模型只负责一个任务根据用户描述判断哪些列是日期、哪些列是数值然后把判断结果传给脚本。模型判断好语义脚本落地执行这是数据类技能最稳妥的分工方式。设计这种技能时有一个坑特别值得提代码算出来的结果和模型读到的结果出现冲突。比如脚本对某个价格字段做了去重但模型在处理下一张表时又把这个价格字段视作原始数据。为了解决这个问题我在技能里强制要求脚本输出一份“变更说明”模型必须把这份变更说明一并呈现给用户让用户知道哪些行被去掉、哪些值被修正。数据类任务最忌讳的是“悄悄处理”可见性就是可信度。4.2 第三类技能代码审查技能核心在“引用规范而非复述规范”第三种技能是代码审查。代码审查技能的目标是让Agent读一段源码之后按团队的编码规范给出批注列表。这类任务最常犯的错误是把几十页的编码规范整个塞进提示词里因为说明书太长模型在实际审查时只能记住开头的几页后面的规则全被忽略。我在设计代码审查技能时采取了一种更节省的做法不把规范全文写进指令而是保存一份单独的局面规范文件放在references目录下instructions里只写“审查时依次对照references/encoding_rules.md中的规则并给出违反规则的位置和修改建议”。模型在处理具体代码时按需读取规范章节等于把一份大部头字典放在了手边而不是强迫它把整本字典背下来。这个技能还有一个特殊处理它不直接修改代码只输出评审意见。我发现如果指令让技能“直接修改代码”模型很容易在不懂项目整体架构的情况下把代码改错或在多个技术栈之间迷失方向。评审意见模式则限制了风险范围——Agent只负责挑毛病和给建议是否修改、怎么修改由开发者决定。一个技能能做的越少反而越可靠这是我在多技能开发中反复印证的一点。4.3 第四类技能内容排版技能核心在“用示例代替道理”还有一类技能适合用少样本示例来驱动我可以拿内容排版举例。某个团队要维护一系列公众号风格的推送要求标题不超过24个字、段落之间必须空行、引用部分不能连续超过5行、结尾需要一段统一风格的主编短评。这些规则用文字列出来模型总能漏掉一两条但改成给它两三个“输入原文、输出排版结果”的完整示例它就能通过类比学会整套规范。内容排版技能的结构因此很特殊SKILL.md里的instructions特别短只有“参考examples目录中的排版示例将输入文本按相同风格输出”这样一句话真正的规则全部藏在示例中。这背后的道理很朴素模型对具体例子的模仿能力远强于对抽象规则的遵循能力。你在指令里写“保持风格一致”模型不知道风格是什么但你给它三组排完版的对照样本它自己就能归纳出风格的内涵。需要注意的是示例要覆盖“极端情况”不能全选好样本。比如一个示例专门展示“引用内容超过5行时如何合并”另一个示例专门展示“标题字太多时如何删减”。只给好样本会让技能在新的复杂输入前不知所措给几个坏样本并附上“这是错误做法”的标注模型反而能学到边界在哪里。5. 开发过程中最常踩的坑与排查方法5.1 技能总是触发不了问题往往在描述文件多技能开发一段时间后你会发现大量问题都出在“触发链路”上而不是技能内部的指令逻辑。最典型的现象是你明明设计了一个技能用户说的话跟触发词也沾边Agent就是不加载它。排查第一步是看该技能的description里是否把触发场景写清楚了。我见过很多设计者只写“用于处理XX任务”没有给出关键词、没有给出反例Agent每次都得猜测猜错率自然高。我自己的排查方法是做触发实验准备一组经过标记的有效输入和无效输入逐一让Agent判断是否应该加载该技能然后把判断结果统计成表格。实验中如果发现技能总是有些该触发时不触发的情况我会在description里增加场景化描述比如“当用户提到某关键词或表达出某类诉求时使用”如果发现大量不该触发时反而触发我会重点补充反例。这个实验每次改完description都要重跑一遍是保证触发稳定性的基本功。5.2 技能与技能之间串台边界没有划干净当技能数量多到十个以上新的问题就出现了两个技能的边界互相重叠Agent经常加载错。比如我的“文档拆分技能”和另一个“长文摘要技能”都是在处理同一个长文档表面看确实很像。如果描述文件里没有写清楚分工Agent可能把拆分任务交给摘要技能输出一堆段落大意而不是拆分结果。划清边界靠两件事一处是描述里的“明确分工”一处是技能内的“使用条件”。我会在document-splitter的描述里写“重点在于按照标题切分”在长文摘要技能的描述里写“重点在于概括整体内容不对章节做切分”。当两个技能边界实在无法完全分开时我会选择把其中一个技能做成另一个的操作选项比如让摘要技能在判断需要拆解时调用拆分技能而不是各自为政。5.3 上下文被技能说明撑爆加载即卡死另一个隐蔽问题是上下文膨胀。有些技能为了把指令写全把几十年行业经验都塞进了instructions一份SKILL.md就动辄两三千字。这会导致一个结果技能一加载模型的可用上下文就被吃掉一大块后面处理任务时反而缩手缩脚。这也是我前面强调references目录的原因——长资料应该放到引用文件而不是全部堆在入口卡片里。如果技能确实需要大量背景知识建议把知识拆成多个小文件并让instructions明确“遇到哪类问题才读取哪个文件”。这样做的好处是多数任务只需要模型读取其中一两个文件上下文消耗被控制在合理范围而且模型不会因为一次性读太多材料而欺骗注意力。上下文就像工具箱技能应该是一把精装的螺丝刀而不是一整辆工具车。5.4 脚本执行失败与路径错误脚本类技能还有一个高频故障来源路径问题。技能包从一个环境搬迁到另一个环境时脚本里的绝对路径很容易失效。我吃过一次亏把整个技能库从笔记本迁到服务器后数据清洗脚本找不到了引用文件的位置Agent连着报错。后来我定了一个规矩所有技能包内部引用必须用相对路径并且脚本入口统一通过一个总入口文件比如run.py启动运行时基于脚本所在目录解析所有路径。另外脚本的参数传递方式要简单且标准。我通常让脚本通过标准输入读取原始数据通过标准输出返回结果避免依赖临时文件。临时文件在并发任务里很容易互相覆盖一次两个Agent同时在跑同一技能脚本就乱了。把输入输出都约束在进程内部基本能绕开这类偶发故障排查成本也最低。6. 技能库的维护与持续演进做有用的资产而不是摆设6.1 建立技能清单与回归测试集当技能数量上来之后维护成本会直线上升。单纯靠在对话里测试变得不可行所以我建了一张技能清单表格记录每个技能的边界、触发词、最近改动时间和依赖脚本。这张表格最简单但作用巨大每当我修改一个技能我可以快速看到哪些其他技能可能与它共享脚本或重叠边界从而提前评估改动影响。更重要的是回归测试集。我把每个技能对应的有效输入和无效输入样本整理成固定文件每次修改后运行一遍完整测试。花的时间不长但能拦住绝大多数低级回归。有一次我自以为只改了一个技能的一处说明结果运行回归测试后发现另一个技能被连带影响了因为它们的描述文件里用了同一条触发词。没有回归测试这种问题就会在线上悄无声息地爆发。6.2 效果的回收与迭代更新技能不是写完就结束它是一个需要持续喂养的资产。我通常留一个专门的动作每跑完一个真实任务把用户反馈记下来判断是“描述问题”还是“流程问题”还是“脚本问题”然后回到对应环节修改。这个闭环做完几轮之后技能会越来越贴合实际需求而不是停留在最初的设计假想里。有一点要特别提醒不要一发现问题就急着改。先攒一批问题分类后再统一修改每次改完重跑回归测试。频繁地小修小改容易让技能进入一种“按下葫芦浮起瓢”的状态改一次惹出一堆新故障。我一直以来的心态是技能库是为未来服务的今天的克制会减少明天的大面积返工。6.3 把可用技能当成标准操作程序来运营实战到后期你手里的技能包已经不只是一堆技术文件它更像一组标准操作程序。当你把某项工作的执行顺序、判断标准和失败处理都固定成技能后团队里任何人面对同一类任务都能得到一致的AI辅助结果。这比一段纯口头约定要可复制得多因为它把老员工的经验沉淀成了可执行文件。我个人在实际操作中还有个习惯每个技能都会配一段简短的使用说明放在仓库的README里说明这个技能面向什么任务、什么时候不要用、如果出错要找谁。很多技术能力做出来了没人用不是因为它不好而是因为别人不知道它好在哪里。把技能当成一个内部产品来运营写清楚使用场景和边界它才会真正活起来。这些技能开发下来我最大的收获倒不是效率提升了多少而是被迫把很多模糊的、靠感觉的日常任务重新梳理了一遍。你能把一个任务变成技能说明你真的理解了它你理解得越深技能就越稳定越能省下你脑子里的带宽去处理更复杂的判断。这就是我为什么坚持把各种技能一个个开发出来省下的是重复劳动换来的是更多可以自由支配的注意力。
