6000 多次会话说不清是从哪一天开始动这个念头的。当时我手头一堆零散的 prompt分布在十几个文档里有些是在 Claude、Codex、OpenCode 这类 Agent 环境里反复调出来的有些是跟大模型对话聊到一半灵感来了临时存的。等到某天想找一个之前用过的模板发现搜索比重新写还费劲那一刻我意识到6000 多次会话沉淀下来的百条 golden prompts如果不重新组织那它们就只是聊天记录里的废料。于是我把它们做成了 skill一套能在 Claude Code、Codex、OpenCode 等 Agent 环境里被自动加载、自动执行的技能包。这篇文章不聊抽象概念直接讲我从这百条 prompts 里提炼、结构化和工程化的全过程。适合那些已经跟大模型打了大量交道、手头有不少好 prompt 但不知道怎么复用的人也适合准备入局 skill 生态但卡在怎么写、怎么拆、怎么测这一步的人。我会把每个关键选择的理由、踩过的坑、实测下来的效果都写清楚尽量做到你可以照着复现。1. 从一个朴素的习惯说起6000 次会话里到底沉淀了什么1.1 为什么我会攒下这么多 golden prompts先交代背景。过去一年多我的工作流高度依赖大模型无论是日常写代码、搭脚本、写文档、做数据分析还是跑一些重复性很高的信息整理任务都会先把问题丢给 Agent 去执行。用得多之后一个很自然的习惯就养成了每次对话里只要出现效果特别好的回答我就把当时的问题、上下文和模型回答一并复制到一个备忘记事本里顺手标一下这个好用下次改参数就能用。这个动作坚持了很长时间积少成多下来大概积累了 6000 多次有记录的会话。注意不是 6000 个 prompt是 6000 次会话每次会话里可能包含多轮对话其中有价值的片段被我摘出来慢慢沉淀出大约百来条经过验证的 golden prompts。这批 prompts 的范围很杂。有用于代码生成和重构的有用于写周报和整理会议纪要的有用于做竞品分析的有用于把口语化需求转成结构化任务清单的还有不少是给文档做摘要、翻译、格式转换这种相对轻量的任务。它们的共同点是在真实场景里被验证过至少一次输出质量稳定不是那种只在理想输入下才有效的花架子。1.2 从零散提示词到 skill一个被反复摩擦出来的转折点零散 prompts 的问题用一句话概括就是找得到的时候是资产找不到的时候就等于不存在。我试过给文档建目录、加标签、按日期排序甚至想过做一套本地检索系统但每次在大模型对话窗口里需要使用某个 prompt 时还是要先打开文档、找到内容、复制粘贴、再根据当前任务手动改细节。这个流程慢且笨。更麻烦的是不同 Agent 环境对上下文长度的处理方式不一样粘贴进去的提示词如果太长会影响模型对后续内容的注意力分配。后来我开始留意到 skill 这个概念——它不是简单的提示词文件而是把提示词、参数定义、示例和触发规则打包成一个可以被 Agent 自动识别的单元。当你把某个任务交给 Agent 时它能在合适的时机自行加载对应的技能而不需要你手动把一大段提示词塞进对话框。从零散提示词到 skill 的转折点其实是被一个具体场景逼出来的。某次我要处理一批格式不统一的销售周报里面有中文有英文有表格有长文需要逐个转换成统一格式。我手头明明有已经调好的转换模板但因为是分散保存的每次都得人工去匹配。那一刻我很确定我需要一个能自动感知任务类型并主动调用模板的机制而不是继续靠复制粘贴。2. skill 到底是什么它和普通提示词的区别在哪里2.1 skill 不是冰箱贴它是一个可被调用的工作单元如果非要用一句话说清楚 skill 和普通提示词的区别我倾向于这么类比普通提示词就像一张写着做菜步骤的便利贴你每次做饭都得拿出便利贴看一遍然后自己动手起锅烧油skill 则像是一个装在厨房里的智能料理机你只要告诉它今天想吃红烧肉它会自动加载食材清单、步骤、火候参数甚至把调味顺序都安排好了。技术上一个 skill 通常包含三样东西。第一是描述文件用来说明这个技能是干什么的、适合在什么场景下触发、需要哪些输入参数。第二是本体指令也就是一段或多段结构化的提示词内容这部分决定了模型在技能被调用时以什么身份、什么逻辑去处理任务。第三是示例可能是一到两组输入输出对帮助模型稳定理解预期的输出格式和风格。描述文件的重要性往往被新手低估。很多人以为 skill 就是把提示词改个名字存进文件夹就行了实际上描述文件写得不好Agent 永远不会主动找到它。你可以把描述文件理解成一张技能名片它不仅告诉 Agent这个技能存在还要告诉它在什么情境下应该递出这张名片。2.2 从使用逻辑看skill 改变的是谁在主导流程普通提示词的使用逻辑是人主导。你输入一段指令模型给出结果你再根据结果调整提示词再输入……整个过程需要人持续在循环里。而 skill 的使用逻辑是任务主导。你只告诉 Agent 最终目标比如把这 20 份简历按这个标准整理成表格Agent 会先理解任务类型判断出这属于信息提取与结构化整理这一类可复用任务然后自动加载对应的 skill 来执行。这个转变表面上只是少了复制粘贴的步骤实际影响远不止效率。当提示词被封装成 skill 之后它会强制你思考几个以前懒得思考的问题这个任务的核心输入是什么输出格式有没有可能标准化模型的输出风格要不要固定这些思考本身就会反过来帮你把提示词打磨得更严谨。另一个区别是版本管理。普通提示词散落在各个对话里改了一版旧版就找不回来了而 skill 有明确的文件结构和命名规则你可以在文件夹里同时保留 v1、v2、v3哪一版出了问题随时可以回退。对于我这种经历了 6000 多次会话、验证过百条 prompts 的人来说版本管理基本属于刚性需求否则根本不敢动手改任何一版。3. 把 golden prompts 沉淀成 skill 的完整流程3.1 第一步从会话记录里提炼可复用的逻辑主线面对百来条 prompts我做的第一件事不是写代码而是清洗和归类。我把 6000 多次会话的记录按任务类型粗分了一遍发现很多 prompt 表面看起来不同内核逻辑却是同构的。比如把这段技术文档翻译成中文要求术语准确、语调专业和把这段用户反馈翻译成英文要求简洁、适合发社群——翻译对象不同但本质都是语言风格迁移。我把这种同构的 prompt 归为一类再从中提取共同的结构而不是一条一条单独封装。这个提炼过程有点像做 ORM 建模。你面对的是各种形态的原始数据但要抽出的是共有的字段和方法。比如信息提取类prompt它们的共同结构不外乎三块明确要提取的字段清单、说明原始内容的来源格式、规定输出结果的展示方式。一旦抽取出这个结构原来 20 条分散的信息提取 prompt 就能统一成一个带参数的 skill。分类维度我建议按输出目标来切而不是按输入内容来切。按输入内容分类容易分出一堆互相重叠的类比如代码文档摘要会议纪要摘要论文摘要其实都是摘要按输出目标分类则会自然形成生成类转换类分析类提取类这几个相对独立的大类然后再在每个大类下细分子类后续写描述文件会轻松得多。3.2 第二步模板化与参数化的改造把 prompts 做成 skill 的核心步骤是参数化。原来一条写死的提示词比如请用专业、客观的语气分析这三家公司的竞品优劣势如果要复用在不同行业、不同公司数量、不同分析粒度上就不能让三家公司竞品优劣势这种具体的词固化在里面。我采用的策略是给每条 prompt 设计一个输入参数区。以我做的竞品分析 skill 为例它需要接收的参数有五个行业领域、竞品名称列表、分析维度列表、字数要求、输出风格。在 skill 本体里我会把这五个参数用占位符标出来并在描述文件里写清楚每个参数的类型和可接受范围。这样无论用户输入是分析小米、华为、苹果在手机影像上的策略差异500 字以内还是帮我看看瑞幸、库迪、Manner 的扩张模式要详细对比同一套 skill 都能接得住。要注意的是参数不是越多越好。我最初把一个行业研究报告 skill 设计成了十二个参数结果每次调用都要填一堆东西Agent 反而容易犯迷糊最后输出效果还不如直接随手写一段 prompt。实操下来单个 skill 的参数控制在三到五个比较合适超过五个就该考虑拆分成多个 skill。参数的意义是提供灵活性但过多参数会稀释 prompt 的聚焦力这跟你和真人沟通是一样的问题问得越集中答案越靠谱。3.3 第三步写描述文件决定 Agent 何时能找到它skill 能不能被 Agent 恰当使用80% 取决于描述文件有些场景里叫 SKILL.md 或者技能说明文件写得怎么样。我以前以为描述文件就是简单写几句话概括功能后来才发现描述文件实际上是技能与 Agent 之间的唯一桥梁。写得好不好直接决定 Agent 是把你精心打磨的技能拿起来用还是宁愿自己现编一套提示词。我的写作套路是这样的先写这个技能解决什么问题这是用来让 Agent 做初次匹配的再写在哪些任务类型下应该考虑使用本技能这是给 Agent 一个触发判断依据然后写使用本技能时需要提供哪些输入参数这是引导 Agent 从用户需求中提取关键词最后写输出格式遵循什么规范包括一些硬性约束比如生成表格时不允许出现合并单元格结论部分前必须有一句话直接回答问题。这里有个反直觉的经验描述文件不要写太多哲学层面的东西。高质量输出深度思考这种词没有任何信息量Agent 读了也不知道你想让它干什么。描述文件的核心任务是精确、具体、可操作最好是像一份工作说明书而不是一段自我表扬的简介。3.4 第四步测试、观察、迭代的闭环skill 写完不是终点测试才是真正让 skill 从能跑到好用的分水岭。我给每个 skill 建立了一套最小测试集大约三到五个典型的输入样例覆盖该技能最可能遇到的场景。测试的时候不光看输出好不好还要注意 Agent 是刚好它自己想用还是确实按你的描述匹配到的——后者才是 skill 设计成功的标志。第一次测试往往都会暴露问题这很正常。我记得测试一个会议纪要素材整理 skill 时Agent 确实触发了技能但输出格式跟描述文件里规定的完全不一样后来排查发现是描述文件里以要点列表形式呈现这句话和 skill 本体里以 Markdown 列表呈现的表达不完全一致模型在执行时选择了更模糊的指令。从那以后我养成了一个习惯描述文件中的关键要求必须在本体指令中原样保留一遍。迭代的时候不要试图一次解决所有问题。每次只改一个变量要么改描述文件里的触发条件要么改本体里的输出格式约束要么改示例的内容。混在一起改的话出了问题你根本不知道是哪一处改动导致的排查成本反而更高。4. 设计和工程化过程中的关键决策4.1 颗粒度多大才合适一条指令还是拆成一组这是我在设计 skill 时想得最多的问题。如果颗粒度太粗一个 skill 里塞了太多任务逻辑Agent 执行时容易选择性忽略部分要求如果颗粒度太细每个 skill 只管一小步那任务稍微复杂一点就需要连续调用多个技能不仅响应变慢中间还容易出错。我采用的拆分策略是看语义断层。如果任务 A 的输出是任务 B 的输入而且 A 和 B 的领域差异明显那就值得拆成两个 skill。比如从竞品官网扒取定价信息和对比多款竞品的价格策略前者是提取任务后者是分析任务它们的处理逻辑完全不同分开做效果更好。相反如果一个任务的子步骤只是同一个逻辑在不同数据上的重复那就没必要拆一个 skill 加个循环就行。优先级上我倾向于把提取类和格式转换类的技能做得更细因为这类任务输出结构稳定最容易被参数化把分析类和创作类的技能做得稍粗一些给模型留一点自由度否则模型内容会显得僵硬。4.2 冲突与依赖两个 skill 之间会不会打架当 skill 数量多到一定程度冲突就不可避免。最常见的是两种触发条件重叠同一段用户输入可能匹配到两三个不同技能能力边界重叠某个技能能做另一个技能的活但做得没那么好。这个问题我一开始没重视直到测试时发现一个任务被反复触发同一个不合适的 skill才意识到需要做冲突管理。我的解决办法是建立技能索引表给每个技能标注明确的优先级和排他条件。比如会议纪要生成和行动项提取这两个技能在同一个任务里是有顺序依赖的纪要生成应在前面行动项提取在后面。我会在纪要生成技能的描述文件里专门加一句本技能仅负责完整纪要的结构化整理不单独提取行动项若用户明确要求提取行动项请先完成纪要生成后再调用行动项提取技能。依赖关系的管理还要注意一种情况技能 A 的输出格式变了可能导致技能 B 的输入解析失败。所以我在设计时尽量让技能之间的交互通过标准格式完成比如统一输出 JSON 结构或者在输出末尾附带本技能已完成输出结构版本为 v2之类的标记。这样即使后续要改结构排查链路也会清晰很多。4.3 和 Agent 协作时skill 应该多主动还是多被动这是个很微妙的问题。skill 设计得太主动Agent 会在用户没有明确需求时也自动触发反而干扰用户设计得太被动Agent 又把 skill 当成一个摆设永远不去匹配用户需求。我在多轮实测中总结出来的原则是能明确识别就主动识别不确定就询问。举个例子。我有一条告别信/请假邮件生成的 skill它的触发条件很明确用户提到请假、离职、告别邮件、写邮件给团队等关键词。这种情况描述文件里可以直接写当用户请求生成任何形式的告别信或请假说明时必须调用本技能。而另一条数据分析报告生成的 skill因为数据分析任务形态差异太大用户可能只是说看看最近的数据这时候就不适合自动触发描述文件里应该写成当任务涉及数据分析且用户明确要求生成报告时优先考虑本技能。这种主动/被动的边界只有通过真实对话场景的反复测试才能摸准。我给自己的要求是每新增一个 skill至少要在三种不同表达方式的用户请求下测试触发行为如果两次以上触发不准确就回炉调整描述文件。5. 实际使用效果评估5.1 影响最大的三个场景这套 skill 体系我实际用了一个多月目前总共有 100 多条技能在正式工作流中运行。影响最大的场景有三个。第一个是重复性信息整理。以前每周处理销售周报、用户反馈汇总、项目周报这类任务大概需要一两个小时现在基本就是丢给 Agent 一句话所有格式化、摘要、重点提取都由对应 skill 完成十分钟内拿到初稿我再花几分钟微调。这个效率提升是最直观的也让整理信息这类原本不太喜欢干的活变得不那么痛苦。第二个是跨语言文档转化。我经常需要把中文技术方案翻译成英文文档或者反过来以前每次都要在提示词里反复强调术语表、语气风格、格式细节现在一个翻译 skill 把这些全部固化了只要输入把这份方案翻译成英文术语表见附件输出质量非常稳定。第三个是竞品研究。这个因为涉及的分析框架比较多原来靠人肉写提示词很容易漏掉某个维度现在用竞技分析 skill只要提供竞品名单和分析方向它会自动按设定维度拆解最后生成对比表格和结论摘要。我不需要每次重新考虑要分析哪些角度技能本身就替我做了决策。5.2 从输出质量、调用准确率、维护成本三个维度看效果如果量化评估这套体系我更关注三个指标。输出质量稳定性调用准确率以及维护成本。输出质量稳定性方面同一技能在相同参数下反复运行输出结构的一致性比以前手写提示词高了很多。以前同样一个任务上午和下午各跑一次格式可能差很多现在因为 skill 里预设了明确的输出模板10 次运行有 8 次以上结构基本一致剩下的一两次差异也能很快定位到是参数问题还是模型波动。调用准确率是我初期最头疼的指标。前两周测试时技能总体的自动调用准确率大概只有 60% 到 70%不少任务 Agent 根本没想到调用现有技能而是自己重新生成了一套相近逻辑的提示词。经过反复优化描述文件和触发规则后调用准确率提升到了 80% 到 90%虽然还没做到百分百但日常使用中手动指定技能的概率已经很低了。维护成本方面必须说实话skill 体系的初期维护开销不低特别是描述文件的调整。但进入稳定期后成本显著下降。现在新增一个技能从 idea 到可用的完整周期大约需要一到两个小时其中大部分时间花在测试和调整描述文件上。考虑到大量重复任务从此不再需要每次写提示词这个前期投入是划算的。5.3 关于技能通胀的反思手里有 100 多条技能之后我开始意识到一个新问题技能太多本身就是一种负担。每次新增技能都会增加 Agent 对技能列表的检索复杂度描述文件写得模棱两可时Agent 可能选中一个功能相近但不够合适的技能输出效果反而劣于不调用技能。这情形让我想到一个词技能通胀。当技能的供给远超真实需求时技能的边际价值会迅速下降。我现在对自己的约束是新增一个技能前必须回答三个问题第一这个任务是否至少每周会执行一次第二现有技能是否真的无法覆盖第三这个技能的输入输出是否能被清晰定义。三个问题有任何一个答不上来我就只保存 prompt 不进 skill 库。事实上我在整理那 100 多条 golden prompts 时最终真正转化成 skill 的只有 70% 左右。剩下的 30% 要么触发条件太模糊要么任务场景太小众做成 skill 反而会让整个体系变臃肿。保留精而不贪多是这套体系能长期稳定运行的前提。6. 常见问题与排查技巧实录6.1 技能一直不触发怎么办这是使用 skill 时最容易遇到的问题。排查时我先看描述文件描述文件里如果写的是本技能用于帮助用户处理文本Agent 大概率不会主动用因为这句话根本没法建立触发条件。触发条件要具体到能对应真实用户输入比如当用户要求对会议记录进行结构化整理时。如果描述文件没问题再看技能目录结构。有些 Agent 环境要求技能放在特定目录、文件命名有固定规范放错位置或者命名不规范Agent 就扫描不到。这部分虽然简单但极其容易踩坑我排过好几次刚才还一切正常过了两天技能突然失效的案例最后发现是目录同步工具把文件名改掉了。另外也别忽略一个很踏实的可能Agent 默认不会在每次请求时都读取全部技能的详细内容它更依赖于描述文件先做粗匹配。描述文件开头几句话就要把核心触发场景点出来千万别把关键信息埋在文本末尾。6.2 触发了但输出结果太泛怎么办技能被正确调用但输出泛泛多数问题出在输入参数不明确和输出约束缺失。举一个例子我早期写的一个工作总结生成技能输出结果全是本周完成了多项工作取得了一定进展这种车轱辘话完全没法用。后来我加入了输出硬约束必须列出具体完成事项清单每一事项必须包含动作、产出物和数据反馈没有数据反馈的事项必须注明暂无量化数据。输出约束的细化程度可以直接决定输出质量。我建议在 skill 本体指令里加入正面要求和反面禁止两种表述。反面禁止大家普遍会忽略但它其实很有效比如禁止输出笼统评价禁止使用 不错良好 等无量化词语。模型对明确禁止的内容会有更强的遵循意愿这点在我翻看多次会话记录后体会特别明显。6.3 技能版本升级后旧任务突然执行异常技能升级是踩坑高发区。我遇到过一次格式化问题一个信息提取技能升级后加了新的输出字段但同一工作流中下游的另一个技能还在按旧字段解析结果提取出来的数据全乱了。排查思路先缩小范围先用旧版本技能跑同一个任务如果旧版本正常那就是升级引入的兼容性问题。处理方式我推荐做缓冲版升级技能时保持旧版文件仍可访问描述文件里注明v2 版本尚不支持 xx 功能若用户任务涉及该功能请回退到 v1给下游技能一个适配的窗口期。另外尽量让技能之间通过稳定 ID 或版本号字段通信而不是靠对字段名的隐式依赖这套做法能让整个技能体系在持续迭代时不至于一改就崩。写在最后的几句实在话把 6000 多次会话里沉淀的 golden prompts 做成 skill回头去看本质上是做了一次系统性的经验工程化。很坦白地说这个过程不是一蹴而就的我也一直没有追求一次到位的完美方案。迭代了这么多轮最大的心得反而是先跑起来再慢慢改。任何一个技能只要具备最基础的触发条件和参数设计哪怕输出效果一般也比躺在文档里的死 prompt 强。效果不好说明它已经被用了被用了才有机会优化成好用的工具。复盘这次经历我最大的体会是不要为了做 skill 而做 skill每一组值得沉淀的提示词背后一定有一个你反复要做、做起来又很费劲的真实任务。只要抓住那个真实任务skill 的价值是自然涌现的。至于那些只是为了炫技而设计得花里胡哨的技能让它们安安静静躺在草稿箱里就好市场会替你淘汰。最后再分享一个我保留至今的小习惯每当模型在某次对话里给出了让我眼前一亮的效果我不会只感叹真聪明而是会下意识追问一句我是怎么问出来的——这句话其实就是在为下一个好 skill 打草稿。