★ FEATURED ARTICLE 1. 项目概述为什么我会把一个叫 skills 的东西当成正经项目来做先说个背景。我做 AI 应用落地已经有段时间了早期跟大多数同行一样核心工作是写 prompt、调 prompt、再写更长的 prompt。但很快发现一个尴尬的问题同样的任务比如写一封得体的催款邮件做一份竞品分析摘要把会议录音整理成待办清单每次都要从头组织指令一次一次试效果还飘忽不定。有时候同一句话换个说法输出质量就明显下降。这种随机性让人非常疲惫。后来我接触到一个思路把高频、重复、有固定流程的能力封装成一个独立的、可被调用的技能单元也就是我给这个项目起的名字skills。你可以把它理解成给 AI 配备的一套标准作业程序。每个技能里除了基础指令还包含一套完整的上下文信息任务目标、约束条件、执行步骤、参考示例、输出校验标准甚至关联的工具接口。主程序平时不加载这些细节只有当触发条件满足时才把对应的技能包整体唤醒并投入执行。这套机制解决了我之前的痛点第一技能是一次性沉淀、反复使用的不用每次重写第二技能把怎么说和做什么分开了效果稳定得多第三多个技能可以组合像搭积木一样完成更复杂的任务。这个文章想分享的就是我在构建技能化封装过程中的完整思路和实操细节包括技能单元应该怎么设计、主指令怎么写才扛得住真实场景、怎么用资源文件避免上下文被无关内容冲淡、以及我踩过的那些坑。如果你是做 AI 应用、智能体开发或者有大量重复性文本生成需求的内容从业者这篇内容应该能帮你少走不少弯路。2. 设计思路拆解技能单元为什么比长长长 prompt 更靠谱2.1 从一次性指令到可复用技能的转变逻辑传统 prompt 工程的核心是把话说清楚。但问题在于越长的 prompt越难维护也越容易在模型推理时出现注意力分散。像我之前维护的一份战略分析报告生成指令足足有三千多字每次微调都战战兢兢怕改一处坏全局。更麻烦的是不同任务之间的指令互相没有隔离A 任务的要求偶尔会污染 B 任务的输出。技能化封装的核心变化是把指令升级为模块。对比维度传统长 prompt技能化封装skills组织方式全部塞在一次对话里按技能拆分成独立单元按需加载上下文开销每次都要携带全部指令token 消耗大只有触发时才加载相关技能节省上下文可维护性改一处可能影响所有任务每个技能独立迭代互不干扰复用性换个场景基本要重写复制、微调、组合都方便效果稳定性容易受对话历史干扰技能内约束更聚焦输出更可控这个表格不是理论推演是我实际对比使用后的真实差异。尤其是上下文开销这一条在长对话场景里特别明显。没有技能化封装时对话历史一旦变长模型经常会把早期指令中的边角料当成新的要求来执行结果越聊越偏。而技能是按需注入的平时不占地方关键时刻才作为权威上下文出现。2.2 技能单元的四层结构触发层、指令层、资源层、校验层在实践里我把一个标准技能单元拆成四个层面。这个分层不是什么官方标准是我根据自己的使用习惯和失败经验总结出来的但后来发现它跟不少成熟方案里的技能包结构不谋而合。第一层触发层。定义这个技能什么时候被激活。典型的触发方式有两种一种是显式调用像函数调用一样由主程序决定什么时候调用这个技能另一种是隐式匹配通过用户输入的关键词、意图或语义相似度来判断是否激活。实际项目中我大部分技能用的是显式调用隐式匹配只用在少量高频通用技能上比如摘要提取翻译这类意图明确的场景。隐式匹配有个隐患就是容易误触发这个后面在常见问题里专门讲。第二层指令层。这是技能的核心文件通常叫 SKILL.md里面包含了角色设定、任务目标、执行步骤、输出格式、边界约束等。这一层的质量直接决定技能效果的上限。我的经验是指令层的篇幅控制要克制能说清楚就行冗余描述反而会稀释关键约束的权重。第三层资源层。这是技能化封装比普通 prompt 强的一个关键。资源层可以挂载多种形式的辅助文件参考示例few-shot 样本、常用模板、数据字典、术语表、历史最佳实践等等。指令层负责告知任务资源层负责提供弹药。比如我在做商务邮件撰写这个技能时资源层就放了中文、英文各三封高质量范文以及一份包含 20 个行业场景的常用话术清单。这些资源平时不加载只有在技能被激活时才作为上下文注入既保证了输出的专业度又不会拖慢无关对话。第四层校验层。技能输出后用来判断结果是否合格的标准。这个层面最容易忽略也最有用。我在早期做技能时AI 生成的产出经常出现看着内容完整实际没法用的情况。后来我开始给技能配校验清单有些校验项我自己写好后要求模型输出时先自查一遍比如邮件必须包含明确的行动指令摘要必须包含三个核心数据指标效果一下子稳了不少。2.3 命名与触发条件决定技能能否被正确唤醒技能命名看着是个小事其实非常影响使用体验。我见过有人把技能直接命名为帮我处理一些事情这种模糊说法结果触发的时候全靠猜能猜中也是运气好。我自己总结了几个命名原则技能名称必须是动宾短语一眼能看出功能边界。比如撰写周报生成会议纪要分析用户评论情感而不是周报纪要这种名词。触发条件要写清楚用户可能使用的自然语言变体。比如撰写周报这个技能我除了匹配写周报之外还会匹配总结本周工作整理周度汇报这类近义表达。这个变体清单通常放在技能配置的触发规则里而不是塞在指令正文中。避免多个技能共用一个动词。比如你同时有生成周报和生成日报两个技能触发时就容易打架。解法是要么在触发条件中增加必要的实体如时间范围描述、明确场景标志词要么把两个技能合并成一个生成工作汇报的技能再通过参数区分周报/日报。这个过程特别像给电台节目设定呼号喊错了人频道就乱了。触发条件设计得越清晰整个技能体系的调度效率就越高。3. 实操步骤从零构建一个技能单元的完整流程3.1 技能目录与项目结构规划先说你拿到一个需求之后应该怎么组织技能。我建议每个技能独立成目录不管后续是放在本地文件里调用还是发布到团队共享的仓库里目录化的管理方式都最清晰。一个典型技能目录是这样的skills/ ├── write-business-email/ │ ├── SKILL.md # 主指令文件 │ ├── templates/ # 资源层常用模板 │ │ ├── zh_cn/ │ │ │ ├── cold_email.md │ │ │ ├── follow_up.md │ │ │ └── apology.md │ │ └── en/ │ │ ├── cold_email.md │ │ └── follow_up.md │ ├── examples/ # 资源层参考示例 │ │ ├── sample_01.md │ │ └── sample_02.md │ ├── references/ # 资源层术语与话术 │ │ └── phrases.md │ └── config.json # 触发规则、参数定义等元数据这里的核心文件是SKILL.md它承担了传统 prompt 的所有职责但又比 prompt 多了结构化的约束。config.json是技能的身份证它定义了这个技能的触发规则、参数、版本号和适用场景。这两个文件之间要明确分工配置文件管调度主指令文件管执行。我在一开始犯过的错误是把触发条件写在 SKILL.md 里结果技能加载时需要额外解析文本来判断是否触发效率低且容易错。后来统一把判断逻辑放进config.jsonSKILL.md 只负责已经决定要执行时应该怎么做边界清晰后整套体系稳定多了。3.2 编写主指令文件的五个关键段落SKILL.md 不要求固定模板但我觉得内容上必须覆盖五个关键段落缺一不可。角色与目标。一段话说明这个技能要让模型扮演什么角色、完成什么目标。比如写作技能里我会写你是一名有十年外企工作经验的商务沟通专家擅长根据场景撰写专业、得体、目标明确的电子邮件。这里要注意角色描述不要夸张到影响模型判断重点是专业领域和输出目的。执行步骤。按顺序列出完成任务的流程。这一步的核心价值是让模型的推理路径可控。在我做的客户访谈要点提取技能里执行步骤写的是先通读全文划分主题再按主题提炼关键观点最后对照问题列表补全缺失信息。三步走下来输出质量比直接提取要点稳定得多。输出格式。明确告诉模型以什么格式返回结果。格式化输出不仅方便下游程序处理也倒逼模型思考更严谨。比如要求邮件技能的输出必须包含主题建议、称呼、正文、落款、邮件要点自检列表五个部分这样出来的东西人稍加修改就能直接发出去。约束与边界。说清楚什么不可以做。比如不要在邮件中虚构数据不要使用口语化表达不要使用客户未提供的真实姓名。这一段的写法非常讲究用否定句式比肯定句式更有效因为模型在生成时的负向约束往往比正向鼓励更不容易被穿破。技能参数。列出调用这个技能时可能需要输入的变量。比如收件人背景沟通目的希望传达的核心信息期望的语气。参数化设计是我把技能从特种兵变成常规部队的关键一步它让同一个技能可以适配多种细分的具体场景。3.3 资源文件与引用机制让技能自带弹药库这一步是我认为技能化封装里最值得花时间的地方。很多人写技能所有的东西都堆在主指令里导致指令越来越长token 消耗越来越大而且真正关键的中间结论容易被淹没。资源层的设计就是为了解决这种大而全的诱惑。资源文件分两种使用方式。第一种是全量加载即技能激活时默认把相关资源注入上下文适合那些每个技能执行都需要的材料比如术语表、格式规范。第二种是按需加载由技能在执行中根据具体任务决定是否读取某个参考文件。比如邮件技能里如果用户的目标是写一封催款邮件那么技能可以先判断这是催款场景再去读取templates/follow_up.md而不是把十个场景的模板全部一次性注入。在我的实现里按需加载是通过在 SKILL.md 中写明当遇到 XX 场景时参考 references/xx.md 中的模板进行修改来实现的。实际执行时模型会自行决定是否读取这个文件。这个方法的风险在于模型有时候会忽略指令中参考文件的要求所以最好配合校验层做兜底。后来我改成在主指令里用强制语句比如输出前必须核对 references/phrases.md 中的场景术语表触发率就高多了。3.4 技能测试与版本迭代像维护软件一样维护技能技能写出来不是结束而是开始。我见过太多人写了一个技能用一次就弃置了本质上是因为没有闭环反馈。我习惯的迭代方法是四轮测试法。第一轮单例测试。用最典型的输入跑一遍看输出是否满足校验层的判断标准。大概率会发现格式不对、步骤遗漏等问题直接修。第二轮边界测试。把参数推到极端。比如写邮件技能试试收件人是完全不认识的陌生人、主题是道歉、长度要求是极短。边界情况最容易暴露技能设计的盲区。第三轮回归测试。把之前跑通过的用例批量重跑。这一步非常劝退但是值得因为技能文件改动后经常影响之前已经正常的部分。第四轮组合测试。把两个或多个技能串联使用检查它们在切换时的衔接是否顺畅。我在做会议纪要素材整理和周报生成这两个技能联动时就是靠这一轮发现信息传递丢失的问题的。至于版本管理我建议直接用语义化版本号v1.0.0 这种格式每次修改时在 config.json 里更新版本并写一行 changelog。不要用最终版绝对最终版这种命名方式后面你会感谢自己当初用了版本号。4. 实战解析一个商务邮件技能的完整拆解4.1 需求拆解与参数设计下面用一个实际例子来走一遍完整流程。假设我现在要构建一个商务邮件撰写技能。需求背景是工作中平均每天要写 5 到 10 封邮件涉及催款、跟进、感谢、道歉、约时间、介绍产品等多种场景。不同收件人的关系亲疏差异很大语气也随之变化。过去靠临时写费时且经常词不达意。我先拆解这个技能需要的参数最终定了四个recipient_relation收件人关系陌生客户 / 合作中客户 / 上级领导 / 跨部门同事 / 长期伙伴不同关系对应不同语气区间。email_purpose邮件目的催款、跟进、告知、致歉、邀约、致谢不同的目的有完全不同的结构和信息优先级。core_message核心信息点用户需要传递的关键事实这个必须留空给用户输入绝不能写死在技能里。tone语气风格正式 / 商务专业 / 温和亲近三档选择。这四个参数极大地减小了技能对用户的认知负担。用户不用自己组织语言只需要给参数赋值剩下的交给技能。4.2 主指令与资源文件的落地写法SKILL.md 的正文我控制在六百字左右。角色设定是你是一名资深商务沟通顾问熟悉中英文商务邮件写作惯例。执行步骤我列了五步确认参数含义、判断场景并调用对应模板、构建邮件结构与关键内容、对照校验清单检查、输出最终结果。资源层放了两个目录templates目录按照场景拆分了十二个模板文件examples目录放了六个完整范文中英文各三篇。还放了一个checklist.md里面是转发邮件前的最终校验项比如正文包含明确的行动指令落款信息完整数字和日期核对无误等。这些校验项在指令里被引用做输出前自检。让我用催款邮件场景来展示一下这个模板的核心思路下面是一个简化的示意# 催款邮件模板 ## 适用对象 合作中但付款逾期的客户且合作整体良好 ## 语气基准 既表达理解又明确传递紧迫感不指责但要求明确时间 ## 结构 1. 开头温和回顾合作背景与付款事项 2. 中间客气但明确提及账单逾期情况并给出期待解决时间 3. 结尾请求对方在指定日期前回复或完成付款表达对后续合作的期待 ## 必含要素 - 合同或发票编号 - 逾期金额 - 期望付款日期 - 一个替代方案如分期或确认新时间表模板是给技能参考的骨架不是让技能直接照抄。在 SKILL.md 中我会强调模型必须基于用户提供的实际信息填充细节不允许虚构数字如果用户没有提供关键信息则必须先提问澄清。4.3 实测效果对比有技能和没技能的差距我用了同一个真实case来对比测试。内容大致是客户执行了项目但尾款 15 万逾期 20 天未付之前催过一次没下文需要写一封再次催款邮件但语气不能崩掉。没有技能直接让模型写出来的邮件结构还行但细节问题很多。比如没有给出具体的付款期限没有提合同编号结尾软绵绵地写着期待您的回复没有明确的推进动作。整体感觉像工作人员不像一个专业的商务人。引入技能之后模型自动判断场景是合作中客户催款选定了模板结构然后根据用户输入的参数填充内容。最终输出的邮件里第一段先表达了理解第二段清晰提到了合同编号 JG-2024-071 和逾期金额 15 万元第三段提出希望在 3 个工作日内收到款项如遇困难可随时沟通分期方案结尾是期待继续保持合作。整体语气既坚持立场又留有余地。这组对比让我确认了一个判断技能化封装的本质价值不是生成能力变强了而是把模型在多个维度上的发挥空间收敛到合理范围内让输出的确定性和可用性大幅提升。5. 常见问题与排查技巧实录5.1 技能不触发的排查思路技能叫不醒是我用过一段时间后最崩溃的问题。明明配置了触发规则结果用户输入帮我催一下客户的款邮件技能却没有被调用。排查步骤我后来固定成一条线先查 config.json 的触发关键词看是否覆盖了用户可能说法中的实体词。催一下客户的款里触发关键词如果只写了催款那确实匹配不到。需要把催一下追一下进度款项逾期等变体都收进去。再检查有没有其他技能的触发条件跟它重叠导致调度时被更先匹配的其他技能抢走。我遇到过的情况是一个叫生成待办事项的技能配置了催字开头结果把催款邮件的请求截胡了。然后查技能目录路径是否在系统的加载列表中。新的技能目录容易忘记注册这属于低级但高发的问题。最后看主指令里是否有如果用户没有明确要求不要主动执行本技能这类自我否定的描述。我早期写的技能里有一句除非用户要求否则不要主动发邮件结果每次调用都被模型自己给拦住了。这种潜意识层面的指令约束比显式的触发规则更有杀伤力。5.2 上下文污染如何防止技能之间互相串味做技能库的时间久了一定会出现多个技能同时出现在上下文里的情况。我的做法是引入最小上下文原则也就是每个技能只注入执行任务真正需要的内容。这个原则听起来简单实操起来需要克制不要为了省事把其他技能的好用模板也挂到当前技能里。有一次我把周报生成技能里积累的几条优秀表达放进了会议纪要整理技能的参考文件中结果会议纪要生成时会时不时冒出周报的叙述腔调改了好久才意识到是资源文件的串味。另外还要非常警惕对话历史对技能输出的干扰。技能激活后模型会看整个对话历史如果你的历史里包含了其他场景的大量对话非常影响技能的专注度。我现在会在关键技能调用前在框架层面做历史摘要替换用一段极简的上下文摘要替代冗长的对话记录效果提升非常明显。5.3 技能与临时指令冲突时的处理原则用户在对话中可能会说这次不要按你的模板来直接写一封狠一点的催款邮件。此时临时指令和技能内约束会产生冲突。怎么处理我的原则是临时指令优先但技能提供的约束仍然对输出质量负责。也就是说尊重用户改语气的要求但技能中必含要素一类的底线约束比如不能虚构金额、必须有明确的付款期限仍然执行。这需要在 SKILL.md 里写清楚哪些是可变参数哪些是不可突破的底线。如果不做这个区分模型往往会在临时指令面前把底线也丢弃邮件里开始出现没有出处的数字那是绝对不能接受的。5.4 版本回滚与多环境适配技能迭代过程中总会有改坏的时候。回归测试能挡掉一部分问题但挡不住所有。关键的防呆设计是每个技能目录里保留最近两个版本的备份或者使用代码仓库管理。改坏了就回滚不要有心理负担。另外一个容易忽略的问题是同一个技能在不同模型上的表现差异很大。我在一个模型上调好的技能换到另一个模型后发现输出格式散架了部分原因是不同模型的指令遵循能力存在差距。现在我的做法是在技能 config.json 里记录适配模型列表只承诺在验证过的模型上稳定工作。这个习惯能在多人共享技能库时避免很多无谓的为什么我跑出来效果不一样的争论。6. 个人经验与后续扩展思路6.1 从技能库到团队共享组织方式的演进做了一堆技能之后我开始觉得这个玩法可以复制到团队。于是把技能库从个人目录移到了团队的公共仓库里每个人都可以往里面提交新的技能。这个过程中暴露出来的问题比技术问题更值得说。团队共享技能库最核心的是技能的验收标准。有人写的技能只有一段角色设定没有任何校验层输出质量看运气。后来我们规范化了技能入库的检查清单只有通过审查的技能才允许合入主分支。这种类开源的协作模式跑起来之后技能的沉淀速度的确比个人维护快很多因为每个人都有自己擅长的场景写出来的技能往往比我一个人想得更接地气。6.2 技能质量评估别只看用没用得上技能积累多了自然要面对一个问题怎么判断一个技能是真好还是假好我现在自己会关注三个指标使用频率、修正率、Token 消耗。使用频率好理解修正率是说模型输出结果需要人为修改的比例如果每次都要大改这个技能就该重构了Token 消耗太高的技能我会想办法精简资源文件用按需加载替代全量注入。这三个指标不一定能全面衡量技能质量但能看出一个技能是不是在正确轨道上。6.3 踩坑总结四个让我印象深刻的教训踩过的坑太多挑四个有代表性的聊聊。第一个教训是不要追求一次性的全能技能。我最早做过一个万能写作助手技能试图覆盖所有写作场景结果什么都写不好。后来拆成商务邮件公众号推文活动策划案竞品分析四个独立技能效果立刻上来了。每个技能的职责越单一执行效果越可靠。第二个教训是不要在技能里堆砌太多否定式约束。我之前在一个技能里连续写了十多个不要做 XX结果模型反而变得束手束脚输出变得非常保守。后来我把大部分否定项改成了肯定式的行为描述比如把不要写空话套话改成每个段落都应包含具体信息、数字或可执行建议输出的质感明显提升。第三个教训是技能主指令尽量让新人能看懂。写技能的时候你是在跟未来的自己对话三个月后的你大概率已经忘了当初为什么要这么写。我现在要求 SKILL.md 里必须有设计动机小节一句话说明这个技能为什么这么设计优先解决什么问题。这个习惯救了我很多次。第四个教训是技能再厉害也不要替代人的最终判断。技能的价值是提升下限但上限还是要靠人来把关。我的邮箱里发出去的每封邮件依然会经过自己的人工过目和修改。技能收敛了模型的发散空间但最终的责任还是在自己身上。这个项目做到现在我的核心体会已经不只是把 prompt 写成文件放在目录里这么简单了。它本质上是一种把经验制度化、把能力模块化的思维方式。技能库对我来说就像一本不断增厚的操作手册沉淀的都是我真实工作里反复验证过的东西。如果你也在被重复性任务消耗时间不妨试着从你做得最多的那个任务开始把它变成你的第一个技能。
阅读完成 · 觉得有帮助？
