从今年开始AI 圈子里聊提示词的人明显少了聊Skill的人多了。我自己也是这时候把手里几个高频提示词陆续重写成 Skill宝玉老师那套5 步工程化流程前后看了两遍又在自己项目里实测了一轮。这篇不打算复述课件就说清楚一件事把提示词从一段话变成一个可复用的能力中间到底差了什么以及那 5 步每一步具体怎么做。适合正在做 AI 应用、写 Agent、或者只是想让 Prompt 不那么用完就废的人。1. 在动手写之前先想明白 Skill 跟 Prompt 到底差在哪很多同学一上来就问Skill 怎么写但我建议先花十分钟搞清楚Skill 和 Prompt 的本质区别。否则你很容易把 Skill 做成一个长一点的提示词然后发现它并没有比以前好用。1.1 Prompt 是说一次Skill 是一直能用Prompt 是你每次跟模型对话时输入的那段话它是瞬时的。今天你让它帮你写周报明天再写的时候同样的措辞又得重新组织一遍。而 Skill 是一个能力单元它把提示词、规则、示例、约束、输入输出协议全部打包进去像一个被封装好的函数。你调用它时只需要给参数不需要每次重写逻辑。打个比方Prompt 就像你每次进餐厅都跟服务员说一句少放盐而 Skill 是把你的忌口直接录进餐厅系统下次你一落座后厨已经按你的口味出餐了。前者每次都要沟通后者一次配置、反复生效。1.2 Skill、Prompt、Agent、Plugin 的关系别搞混这几个词经常被混着提但它们的分工完全不一样概念本质举例Prompt一次对话指令帮我把这份会议纪要整理成三条行动项Skill可复用的能力包会议纪要与行动项提取技能封装了处理流程和输出模板Agent自主决策的执行者一个能自己决定先用哪个工具、怎么拆任务的 AI 助手Plugin / Tool模型可调用的外部工具搜索、访问数据库、调用内部 APISkill 和 Agent 的关系简单说就是Agent 是厨师长Skill 是厨师长手下一个个专项能力包——会切菜、会配菜、会摆盘而 Plugin 是烤箱、料理机这类外部设备。Agent 可以调度多个 SkillSkill 内部也可以绑几个 Plugin。现在各大模型平台和 Agent 框架都在推自己的技能体系名字五花八门但本质都是同一件事让大模型在特定场景里稳定地执行一类任务。1.3 真正的分水岭可复用性、可测试性、可维护性如果你把 Prompt 和 Skill 都当成文本去看它们的差别并不大但一旦从工程视角看差别就出来了可复用性Prompt 换个场景基本要重写Skill 换个人、换个项目拷过去照样用。可测试性Prompt 改了个词效果是变好还是变坏全靠感觉Skill 可以挂一套测试用例每次改完跑一遍就知道有没有退化。可维护性一个月后回看 Prompt你大概率想不起来当时为什么强调这一点Skill 有结构、有版本号、有更新记录别人接手也看得懂。这个差别说白了就是打字作品和工程产物的区别。你写一条 Prompt输出的是内容你做一个 Skill输出的是一条可以被反复调用的能力线。2. 为什么散装提示词会越写越累三个被忽视的坑在中级玩家手里提示词早就不是请帮我写个东西这种水平了。他们会用角色设定、给示例、写步骤但为什么还是会越写越累我自己踩下来核心是三个结构性的坑跟你水平高低没太大关系。2.1 坑一每个任务都从零开始经验沉淀不下来最常见的状态是每周写周报每周都现写一段帮我写周报的提示词每周开会每周都现写一段整理会议纪要的提示词。看起来每次都能用但你的经验完全没有沉淀。你会发现经过一个月的调整你心里其实已经积累了很多隐性经验比如周报要按目标-进展-风险来写纪要要区分决策和待办。但这些经验全在脑子里而不是在工具里。某天你手头忙随手写了一条粗糙的提示词模型给你的结果又退化回新手水平。只要经验不沉淀你就在反复支付同一笔及时生效成本。2.2 坑二改动没有基准好与坏全凭感觉提示词优化最难受的一点是你改了一个词模型这次回答变好了但下次换一个输入效果又变差了。你不确定是这次运气好还是真的改对了。没有基准就没有迭代。做机器学习的人都知道评估集的重要性可一旦回到提示词大家全变成了凭感觉调参。我见过有人在一条 800 字的提示词里反复调整顺序调了两个小时问他哪里变好了他说不上来。2.3 坑三一条长提示词里真正生效的可能只有一小段这可能是最隐蔽的坑。提示词越长模型的注意力越容易被稀释。你辛辛苦苦写了大几百字模型真正遵守的可能只剩开头部分和最后强调的部分中间那一段很容易被忽略。这不是玄学是很多模型实际表现出的特点。你可以做一个简单实验把你手头一条 500 字以上的提示词只保留前 20% 和后 20%做一次对比你可能会惊讶地发现结果差别没那么大。这说明你中段写的很多东西模型并没有读进去。这些坑的共同根源是把提示词当成一次性的输入而不是当成需要维护和治理的资产。工程化思维要做的就是把软件工程里那套版本管理、测试、模块化的朴素思想搬到提示词世界里来。3. 5 步工程化流程拆解从一段提示词到一个可复用能力宝玉老师这套 5 步流程核心不是怎么写提示词而是怎么组织提示词周围的东西。我按自己的实践场景重新命名了每一步原意不变但操作的抓手感更强。整个过程看下来你会发现它更像做一个小产品而不是写一段话。3.1 第 1 步先用一句话定义它做什么、它不做什么大部分提示词失败死在第一步你以为你说了要做什么但你没说清楚不做什么。做 Skill 第一步不是写指令而是写一段能力描述至少包含三句话它做什么输入是什么输出是什么。再加一句它不做什么。比如一个技术选型评审技能描述可以写成当用户需要在多个技术方案中做选择且提供了候选方案名称或背景信息时生成结构化对比和推荐意见。输入包括技术背景、候选方案、决策约束。输出包括对比表、推荐、风险清单、待确认问题。不负责做最终拍板不编造性能数据。这四句话为什么重要因为模型在判断当前场景要不要启用这个 Skill时靠的就是描述里的语义匹配。你写得太宽该用的时候不触发或者不该用的时候瞎触发写得太窄能用的场景全部漏掉。实操上可以拿一张卡片写下来写不顺嘴说明你自己还没想清楚它该不该存在。3.2 第 2 步搭一个固定的 Skill 骨架而不是自由发挥Skill 文件不需要很多花哨格式但一定要有一套固定的骨架。我常用的结构包括这些字段字段作用说明name技能名用动词开头如生成会议行动项description触发描述决定模型是否在合适的时候调用它role角色设定给模型一个稳定的行为基线workflow执行步骤明确执行顺序防止模型跳步output_format输出格式让输出可解析避免每次长得都不一样constraints约束条款明确边界、禁止行为few_shots示例教会模型好长什么样fallback兜底策略遇到没见过的场景怎么办为什么要骨架因为固定结构既是给模型看的也是给你自己看的。模型看到工作流程就知道要按顺序执行看到约束条款就知道有些话不该说你维护的时候也知道输出格式乱了该改哪不用从头读一遍全文。这里有个非常实用的小技巧技能名尽量用动词开头description 里一定要写清楚什么时候用、什么时候不用。很多人忽略 description 的重要性结果 Skill 做完了但模型根本不知道在什么场景下调用它。3.3 第 3 步把好例子喂进去重点在对比纠错写再多你要专业、你要客观不如给它一个具体的好回答。模型对抽象形容词的理解是很弱的但对具体文本的模仿能力很强。例子准备两到四个足够不需要多但要覆盖三种类型典型例子最常规的输入输出告诉模型标准活长什么样。边界例子稍微特殊的情况告诉模型这种情况也归你管要学会处理。纠错例子一个看起来像、但实际不应该这么处理的输入配合纠正说明。很多人在这一步只给好例子不给反例。但实际测试中纠正类型的效果往往比正向例子更明显因为模型从之前这样不行要那样做里学到的边界比从要这样做里学到的更具体。例子来源很简单翻你过往和模型对话的记录挑几个你觉得回答得最好的稍微润色塞进去。不要凭空编造也不要硬凑。3.4 第 4 步用约束和护栏让它在边界外也能体面收场约束和护栏说的是两件事。约束是你可以做什么、不可以做什么护栏是当你做不好的时候你怎么坦白。很多人的 Skill 只写了约束没写护栏导致模型一遇到没见过的情况就开始生编硬造。比如你让它做选型对比数据不够它给你编一个不存在的性能指标你让它整理会议纪要录音没转出来它给你捏造一条张总说了。护栏的做法很简单强制要求模型在信息不足时明确说待核实或信息不足而不是硬补。我在约束里通常放这么几条不得编造数据。数据缺失时在对应位置标注待核实。当用户提供的信息严重不足时允许先提问澄清而不是强行给出结论。这条护栏能省掉你大量事后发现它在胡说的痛苦。3.5 第 5 步建一个最小测试集用回归代替感觉Skill 做完第一版不要急着投入使用先建一个最小测试集。这个测试集不需要多复杂10 到 15 条输入就够关键是要覆盖各种类型正常输入、缺信息输入、冲突输入、完全不相关的输入。你拿着这个测试集跑一遍给每条输出打三个分任务完成度、格式合规率、约束遵守率。然后记录结果。以后每次改 Skill都拿同一套测试集重跑一遍对比分数有没有变差。这就是最朴素的回归测试。这一步最大的价值是让你从我感觉这次改得不错进化到我知道这次改得不错。前者靠运气后者靠证据。改动的时候建议一次只改一个变量。今天只改描述明天只加例子后天只调约束。如果一次性改三处再过两周你想回溯到底哪次修改导致效果变好根本查不出来。这个亏我吃过很多次。4. 实操演示把一个技术选型评审Skill 从 0 做到 1光讲方法论容易飘下面用一个我实际在用的例子完整过一遍这 5 步。这个任务大家应该很熟遇到技术选型的时候让 AI 帮忙分析几个候选方案。直接问模型我应该用 PostgreSQL 还是 MongoDB的时候它给的答案通常又长又空像一篇没有冒号的百度百科。我们的目标是让这条产出变成一个稳定的、结构化的、可参考的方案对比。4.1 第 1 步落成文件先把边界卡死我在做这个 Skill 之前先写下了它的能力边界卡做什么多方案技术选型时输出结构化对比、推荐意见、风险清单。输入技术背景、候选方案列表、约束条件成本、团队能力、时间。输出候选方案概览、对比表格、推荐及理由、风险清单、待确认问题。不做什么不编造性能数据、不替用户做最终决定、不输出模板化的空话。边界卡里最关键的是最后一条不做什么。很多 Skill 翻车就是因为什么都想管结果变成一个大而全的咨询机器人失去专用性。4.2 Skill 文件初稿长什么样我把上面这张边界卡落成一份 Markdown 文件这就是 Skill 的主体。不同平台的 Skill 存储格式略有差异但核心逻辑通用。--- name: 技术选型评审 description: 当用户需要在多个技术方案中做选择且提供了候选方案名称或背景信息时调用本技能生成结构化对比和推荐。如果用户只是闲聊或询问一般性技术问题不要调用。 version: 1.0 --- # 角色 你是一名有十年经验的资深架构师擅长技术选型决策。 # 工作流程 1. 列出用户提供的全部候选方案如果少于 2 个先向用户补充确认。 2. 根据背景确定对比维度默认包含性能、成本、生态成熟度、团队熟悉度、扩展性。 3. 逐项对比区分客观事实与主观推测。 4. 给出明确推荐意见列出最大风险。 5. 输出待确认问题清单。 # 输出格式 - 候选方案概览一句话背景 - 对比表格 - 推荐意见1-2 段 - 风险清单3-5 条 - 待确认问题2-4 条 # 约束 - 不得编造性能数据数据缺失时标注待核实。 - 不替用户做最终决定只给推荐理由。 - 对比必须覆盖全部候选方案不允许偏袒。 - 用户信息严重不足时先提问澄清不要硬输出。这个初稿已经把第 1、2、4 步都装进去了边界、骨架、约束护栏都齐了。但只有这些还不够模型大概率还是不知道好长什么样接下来要喂例子。4.3 第 2、3 步合并加入范例模型才真的懂输出标准我给这个 Skill 配了一个很典型的 few-shot 例子场景是数据库选型输入信息大概是这样我想在 PostgreSQL 和 MongoDB 之间选一个。现有业务是订单交易团队对 SQL 非常熟悉部署环境是私有云。预期的标准输出是这个风格候选方案概览订单交易场景候选方案分别是关系型数据库 PostgreSQL 和文档型数据库 MongoDB。对比表格节选维度PostgreSQLMongoDB事务能力原生 ACID强一致成熟4.0 后支持多文档事务但场景相对年轻团队熟悉度高团队有多年 SQL 经验低需要学习文档模型生态成熟度金融、交易场景案例丰富内容管理、日志场景案例多推荐意见优先选 PostgreSQL。理由订单交易强一致需求匹配关系型模型团队 SQL 熟悉度高是硬约束。风险清单如果未来模型频繁变化且强事务依赖弱化PostgreSQL 的迁移成本较高。订单量极速增长时需要提前规划分表方案。待确认问题日均写入量级是多少是否已有选定的 ORM数据库是否必须支持跨区域灾备这个例子告诉模型三件事对比表怎么组织、推荐理由怎么落到约束条件上、末尾必须给出待确认问题。看过一次这样的输出它后面再遇到类似请求就大概率会照这个格式来。4.4 第 4、5 步合并跑测试集用失败案例驱动迭代初稿加例子第一版能跑了但别急着用。我给它准备了一个 10 条的测试集其中特意放了两个容易翻车的输入一个信息严重不足的输入一个候选方案超过 3 个的输入。第一轮测试果然发现两个问题案例一用户只说了帮我比较一下这几个消息队列没提业务背景。模型没有先追问直接输出了一篇泛泛而谈的对比基本没有参考价值。案例二用户给的候选方案里有自己写一个这种非标准选项模型直接忽略了它只对比了其他两个开源方案违反了对比必须覆盖全部候选方案的约束。针对这两个失败案例我改了两个地方。首先在约束里加了一句当用户未提供业务背景、规模、约束条件时必须先在开头用 3 个以内的问题补齐关键信息再开始对比。然后调整工作流第 1 步列出全部候选方案包括自研等非标准选项。如果某个方案你完全不熟悉明确说明该方案缺少公开对比数据不得跳过。改完再跑一遍测试集这两个案例通过了同时其他 8 条也没退化。这就是一次标准的回归迭代有测试集有失败有针对性修改有复测验证。5. Skill 落地后的测试、迭代与一些没人明说的经验流程走通之后Skill 就进入日常使用和维护阶段了。这个阶段最容易翻车因为很多问题是在真实场景里才暴露出来的你准备再周全也预料不到。5.1 最容易翻车的五个瞬间我整理了五个高频翻车场景给各位做个排查清单翻车场景表现形式典型原因该调用时不调用用户都说了帮我选型模型还在闲聊description 触发条件写得不够具体不该调用时乱调用用户只是随口提一句技术名词模型就进入选型模式description 里没写不要调用的场景输出格式飘忽不定这次是表格下次是列表再下次是段落output_format 没给定死或者约束被后文稀释信息不足硬编数据缺失模型给你凑了一个看起来合理的数字没写 fallback没写待核实改了之后变笨模型开始机械套模板丧失灵活性约束写太多太死指令之间互相矛盾这里我想特别说一下第二条。很多人以为描述写得越详细越好但实际上什么时候不要调用和什么时候调用同样重要。description 里写清楚如果用户只是闲聊或泛泛提问不要调用本技能能帮你挡掉特别多误触发的情况。5.2 保持 Skill 长期可维护的几个小习惯Skill 不是写完就一劳永逸它跟代码一样需要维护。几个小习惯能让你省下很多时间把版本号写进文件头部。哪怕只是内部自用也草稿纸上标个 v1.0、v1.1。你一定会遇到上个月那个版本好像更好用的时刻没版本号只能干瞪眼。每次只改一个变量。想改输出格式就只改输出格式想加例子就只加例子。混着改出了问题你根本没法定位。留一个黑历史文件。把那些失败的案例单独放在一个文件夹里。它们是性价比最高的测试样本下次改 Skill 时先拿这些历史失败案例做回归。半年不用的 Skill 直接归档。你已经不用的东西留着也是带噪音的垃圾。归档不是删除需要的时候还能翻出来。最后再分享一个这轮实践中最大的体会这套 5 步流程真正值钱的地方不是那 5 个步骤本身而是它逼着你像产品经理一样去定义问题。我以前写提示词脑子里想的是这句话怎么措辞模型才听话现在做 Skill脑子里想的是这个能力的边界是什么、输入输出怎么约定、失败时怎么处理。这两种思维方式产出的结果完全不是一个层级的东西。如果你也想把手头提示词升级成 Skill我建议从那个每周都会让你重复头疼的任务开始先走一遍这 5 步跑通了再扩展。不用贪多做一个就够你体会到差异了。