两个月前我想从本地仓库里揪出所有临时拼凑的代码段做一次可维护性体检当时我清楚地记得上个月某次对话里写的一条提示词效果出奇地好——它让模型先列检查清单、再逐项打分、最后输出一份带优先级的整改列表比我手动用的任何审查模板都靠谱。问题是那条提示词被我随手贴在某个会话窗口里翻了一个多小时愣是没找到。类似的事情发生过好几次之后我决定认真对待一个老问题我一直在和模型聊出好结果但这些好结果没有沉淀每次都靠运气重新碰出来。于是我做了一个整理计划拉出过去一年多6000多次会话的记录把其中反复验证有效、值得二次复用的提示词一条条筛出来整理成上百条 golden prompts再按任务类型封装成一套 skill——让它们不只是躺在归档文档里的文本而是能被模型主动识别、按统一流程执行的技能包。这篇文章就聊聊整套过程怎么从海量会话里筛出真金怎么把一条 prompt 改造成一个 skillskill 和 agent 到底什么关系以及我在实际使用中踩过哪些坑。适合平时重度使用 AI、手里攒了一大堆零散好提示词但一直不知道怎么体系化的朋友。1. 6000多次会话不是数量炫技而是筛选样本量的基础先回答一个很可能被问的问题为什么非要强调6000多次会话这个数字难道会话少就不配整理提示词吗倒不是这个意思。强调这个数字是因为筛选 golden prompts 本质上是个统计问题——只有样本池足够大、场景足够杂你才能分清楚某条提示词效果好到底是运气还是规律。如果你总共就聊过80次而且全是写SQL那攒下来的所谓 golden prompts 大概率只对 SQL 场景有效换到别的任务上马上失灵。样本太少的时候你很容易把偶然的灵光一现当成可复用的方法论。我当时把过去一年多所有会话粗略按任务类型归了个类日常问答、代码生成、bug 调试、代码重构、文档写作、数据分析、prompt 迭代、agent 任务编排、格式转换、学习答疑大概十个大类。6000多次会话里真正产出过让我眼前一亮内容的对话占比不到5%。这个比例本身就说明一个很现实的问题大多数对话是即时性的用完就没了少数对话里藏着高价值的 prompt但它们混在普通对话里不专门去找根本发现不了。整理的第一步是导出和归档。不同工具的会话记录导出方式差异很大有些客户端能直接倒出全部历史有些只能手动复制。我坦白说我没做到一步到位而是选了个最笨但可靠的办法把关键对话按日期任务类型命名落成本地 markdown 文件。这样做有个附加好处——我可以在归档时顺手做两层清洗。第一层是去隐私信息。对话里经常出现内部路径、人名、项目代号、数据库表名这类东西如果不清理后面封装成 skill 根本没法给别人用哪怕是给自己用换台电脑也会因为路径失效而踩坑。我的做法是全部替换成通用占位符比如project_name、user_id、/path/to/repo。第二层是去掉重度依赖上下文的内容。凡是那句 prompt 离开当时的对话背景就完全没有意义的比如继续再来一遍就按这个思路但改一下第三点这种直接淘汰。golden prompts 的前提是它自己就能独立工作不依附于前面的聊天记录。这一步做完6000多次会话大概剩下一两百条候选但还远不够格称为 golden。有人可能会问为什么不直接靠工具把全量记录结构化处理省去手动归档的功夫我在尝试过之后发现原始记录里充斥着试探性的、失败的、文不对题的 prompt全量结构化只会得到一堆噪音。真正的筛选动作必须由人来判断这段对话里到底哪句话是关键、可复用的这个判断恰恰是机器一时半会儿替代不了的——因为效果好这个标准本身就包含了大量个人偏好和场景信息。多说一句归档阶段还有个容易被忽视的好处你会慢慢看清自己到底在哪些任务上重度使用 AI。我整理完才发现自己花在格式转换和代码审查上的会话比想象中多得多而这两个领域恰好成了我后来第一批做 skill 的对象。整理记录这件事本质上也是在复盘自己的工作流。2. 从聊天记录里捞 golden prompts筛选标准与操作流程有了归档文件接下来就是筛选。这一步如果全靠感觉来最后大概率会留下几十条看起来都挺好但实际用途不明的提示词。我最后总结出四条硬标准缺一条都进不了 golden 名单。2.1 四条筛选标准第一稳定可复现。这条 prompt 必须在不同日期、不同会话、不同上下文里重复使用过而且产出质量波动不大。我见过很多一条 prompt 第一次用效果惊艳、第二次用完全跑偏的情况多半是因为它吃到了当时上下文的红利比如前面刚好贴过一份格式规范的文档模型顺着那个格式输出了漂亮的结果。这种不是 stable 的不能要。我实际操作时会用固定的一组测试任务跑三轮每轮结果都达到我愿意直接使用的水平才敢标记为稳定。第二跨场景可迁移。它不能绑死单个项目、语言或工具。帮我看一下 orders 表的 SQL 为什么慢这种是典型的一次性 prompt换了库就失效。但先输出你推测的瓶颈点再按影响程度从大到小列出验证方案最后只给出需要改动的 diff这种约束类表述放在任何 SQL 调优场景都成立。我总结的经验是真正值得沉淀的往往不是任务内容本身而是你期望模型采用的行为方式。第三行为有明确边界。一条好的 golden prompt 必须能回答两个问题它适合什么任务它不适合什么任务很多 prompt 效果好的原因恰恰是约束了模型的自由发挥空间但如果你说不清边界就可能在错误场景里误用。比如我有一条结构化日志分析的 prompt它明确要求只处理文本日志不处理二进制不处理实时流。这个边界一开始是踩坑踩出来的——有次我拿它处理 pcap 抓包文件产出完全不可用后来才在 prompt 里补上了适用范围。第四产出有可校验的格式。这条尤其重要。如果一条 prompt 的输出是看起来差不多的散文你很难判断它好坏也就没法迭代优化。反之如果它强制模型输出结构化内容——比如先列清单、再打分、最后给结论——那好坏一眼可辨你也能在失败时精准指出是哪个环节出了问题。golden prompts 的价值不在于让模型发挥而在于让模型的发挥可以被观察、被评估、被修正。2.2 从原始会话到候选 prompt 的操作流程我的具体操作流程分四步你可以照着搭一套。第一步粗扫会话列表标记出产出质量肉眼可见高的对话。这里的判断标准很朴素看到那次输出的时候我有没有哇一下的冲动或者有没有直接复制使用、连改都没改。凡是有这种体验的对话先加标记。第二步从标记的对话里把关键 prompt 提取出来做去上下文化。就是把对话里的具体名词、具体路径、具体项目名称替换成抽象占位符。比如原始 prompt 是帮我看看用户中心服务启动为什么会报 OOM去上下文化之后变成帮我看看[service_name]启动为什么会出现[error_type]要求按照[步骤]排查。这一步是让一条 prompt 从特定任务的临时指令变成可复用的行为模板的关键。第三步用一组固定的测试任务做横向验证。我自己维护了一个三到五个任务的测试集覆盖了最常使用的场景。每条候选 prompt 都在这个测试集上跑一遍不达标的直接淘汰。这里有个坑要提醒测试任务不要太难选中等偏简单的最好——因为你要测的是 prompt 的稳定性而不是测试模型的能力上限。任务越难随机性越大越难判断是 prompt 的功劳还是运气。第四步对通过的候选 prompt标注适用场景和失效边界。我会顺手写一句在什么情况下不要用这条。比如我有一条写 English commit message 的 prompt边界就是只适用于代码仓库的 commit不适用于 PR 描述、不适用于技术文档。这个边界不是拍脑袋定的都是实际用错过才补上的。最后再给一个经验初筛阶段宁可多留也不要太早删。我会把犹豫的先丢进待验证文件夹等某次真实任务适合它时拿出来再试一次试过再定去留。这个方式比一次性大批量筛选靠谱得多因为你很容易被当时的兴奋感误导高估一条 prompt 的价值。放进真实任务里跑一次它到底行不行就很清楚了。3. skill 到底是什么——以及它和 agent 最容易被混淆的边界做完了 golden prompts 的筛选下一个问题是为什么要把它们做成 skill而不是继续以普通文档形式保存这就要先把 skill 的概念讲清楚。3.1 一句话理解 skill 和 agent 的区别skill 本质上是某类任务应该以什么方式完成的可复用操作模板落地形式就是一套写好的指令和流程。agent 则是有决策循环、有记忆、能自主选择工具并执行目标的执行主体。一个 agent 可以像人一样在任务开始时判断应该调用哪些 skill把 skill 里的步骤当作自己行动的约束同一个 skill 也完全可以被多个 agent 复用。用生活化类比理解agent 是厨师skill 是菜谱agent 是员工skill 是 SOP 手册。厨师有自己的经验、有灶台、有判断力但接到一道不熟悉的菜时他翻开菜谱按步骤做菜谱本身不会自己下厨房它就是一份操作方法。这个区别看起来很清楚但实际使用中特别容易混淆——因为不少工具里自定义 agent和自定义 skill长得很像都是写一段 Markdown 或者 YAML 配置单看文件内容很难一眼分辨。我见过有人把 agent 定义得跟 skill 一样只有一段提示词而没有决策和工具调用的设计也有人把 skill 写得像 agent试图让它自主决定下一步做什么结果触发又不稳定、执行又僵硬。一个很实用的判断技巧问自己这个东西有没有独立的决策循环和执行上下文。如果它只是规定了遇到某类任务应该按什么步骤做、输出什么格式那它就是 skill如果它能主动判断什么时候用什么工具、分几步完成目标、中途出错了怎么调整那才是 agent。模型读到一个 skill是把它当作这个任务的执行规范模型作为一个 agent 运行才是把它当作由我自主推进的一套行为方式。3.2 不同工具里 skill 的落地形态因为搜索引擎里天天有人问skill 怎么使用skill 插件怎么安装这里把主流做法汇总一下。不同 AI 编程工具和 Agent 框架虽然命名不同但底层的 skill 概念是共通的工具/框架skill 的落地形式我注意到的特点Claude Code项目里建.claude/skills目录每个 skill 一个子目录里面放SKILL.md描述指令描述文件决定了模型什么时候自动选择这个 skill所以 description 的写法直接影响触发准确率Codex通过自定义指令和插件机制加载技能包可以复用社区现成技能包安装后按名字触发OpenClaw / 各类 agent 框架skill 通常是独立的 Markdown 或 YAML 文件按目录组织agent 启动时动态加载和工具调用、记忆模块解耦skil 自身不含状态不管在哪个工具里skill 的核心构成都是那几样描述、指令正文、示例、边界条件。你完全可以先把一个 skill 写成本地一个目录验证有效后再迁移到具体工具里不用一开始就绑定平台。3.3 skill 和 agent 的配合节奏实际工作中 skill 和 agent 的配合我总结成一句话skill 约束路径agent 负责决策。比如我有个代码审查类的 agent它收到审查这个 PR的任务后会先判断当前任务属于哪种类型然后加载对应的审查 skill约束自己必须按步骤来先重述任务、再列检查项、逐项审查、按严重级别输出结果。skill 保证了 agent 的行为不跑偏agent 保证了任务推进过程中的灵活性——它可以在 skill 的框架里自主选择先审查哪个文件、要用哪些工具做辅助。很多人误以为 skill 是 agent 的替代品或者反过来。实际上它们是互补的两层。如果你只是偶尔手动给模型粘贴提示词那你用的就是裸 prompt当你把这条提示词结构化成一份带元信息、带步骤、带示例的文档并让模型能够主动识别和调用它时它就变成了 skill而当你在 skill 外面套上自主决策和工具调用时你才是在构建 agent。想清楚这层关系之后再看把 golden prompts 做成 skill这件事意义就很明确了prompt 是一次性的话语skill 是可持续维护的能力资产。6000多次会话沉淀下来的上百条 golden prompts如果不做这个转换它们就只是几个归档文件里躺着的历史不能主动参与后续每一次任务。4. 从一条 prompt 到一个 skill我的设计方法与代码模板这一节回答热搜里被问得最多的skill 怎么写。我拿最经典的代码审查场景做例子从改造前的裸 prompt 讲起展示完整的设计过程。4.1 改造前的裸 prompt很多人的代码审查 prompt 长这样帮我审查这段代码重点是性能和安全性 [粘贴代码]这条 prompt 不是不能用但问题很明显模型可能给你长篇大论讲原理也可能只给你三行结论可能抓住一个边角问题大做文章也可能漏掉真正严重的 bug。而且你没法复现——同样的代码贴两遍模型输出的结构和侧重都可能不一样。我的 golden 版本是经过实战沉淀的长这样请审查以下代码。先输出你对代码功能的理解再按严重级别从高到低列出发现的问题。 每个问题必须包含问题描述、影响范围、严重级别P0-P2、修复建议、参考的代码行号。 最后输出一个一句话总结。如果没有P0级问题请明确说明。 [粘贴代码]这条比裸 prompt 好一些因为它规定了输出结构但skill不仅仅是这段指令还要包含模型在什么情况下该调用它、它要遵守哪些约束、有没有参考示例。4.2 一个 skill 目录的标准结构不管用什么工具我都建议一个 skill 占一个独立目录目录结构大致如下skills/ └── code-review/ ├── SKILL.md # 核心指令元信息 触发条件 执行流程 输出格式 ├── examples/ │ └── sample-review.md # 一个完整的示例输出作为 few-shot └── references/ └── severity-guide.md # 参考文档P0/P1/P2 严重级别的定义这种组织方式的好处是核心逻辑集中在 SKILL.md示例和参考文档按需加载不会让模型一次性读入过多内容导致注意力分散。实际运行时大多数工具会优先读 SKILL.md只有当它看到需要更多参考时才会去翻 references 下的文档。下面是我目前用下来最顺手的 SKILL.md 模板你可以直接照着改--- name: code-review description: 当用户要求审查代码、检查合并请求、评估代码质量或者提供了代码片段并要求给出问题清单时使用本技能。 输入用户提供的代码片段或仓库路径。 输出结构化问题清单按严重级别排序包含影响范围和修复建议。 --- # 代码审查技能 ## 触发条件 - 用户要求审查代码看看这段代码有什么问题评估这个PR - 用户粘贴了代码并请求代码质量分析 ## 执行流程 1. 首先重述你对代码功能的理解不超过100字 2. 按严重级别从高到低列出问题 - P0可能导致数据丢失、服务崩溃、严重安全漏洞的问题 - P1影响性能、可维护性或潜在逻辑错误但不至于立即崩溃 - P2风格、命名、注释、代码组织等改进建议 3. 每个问题都必须给出修复建议和代码行号引用 ## 输出格式 markdown ### 功能理解 一句话 ### 问题清单 | 严重级别 | 问题描述 | 影响范围 | 修复建议 | 行号 | | --- | --- | --- | --- | --- | ### 总结 一句话如果没有P0问题请明确说明注意事项不审查测试代码的 style 问题只关注实质逻辑如果代码超过500行优先审查核心逻辑不要逐行细读不确定的地方明确标注需要更多上下文不要猜降级策略如果用户提供的代码不完整或缺少运行时环境信息无法判断性能影响时 明确告知基于静态分析的局限性不要强行编造性能结论。这个模板里最关键的是 description 字段。很多人写 skill 时把大量精力花在执行流程上description 却只写一句话代码审查技能。这会导致一个很尴尬的局面模型在任务开始前的匹配阶段根本不确定这段任务要不要调用这个 skill最后要么错过触发要么在不相干任务里误触发。 我总结的 description 写法是三个层次 - **第一句写什么时候用**要具体到动词当用户要求审查代码、检查合并请求、评估代码质量…… - **第二句写输入是什么**输入用户提供的代码片段或仓库路径 - **第三句写输出是什么**输出结构化问题清单按严重级别排序 不要堆形容词不要写这是一个强大的技能这种废话。description 不是给人看的是给模型看的检索索引它决定了模型的匹配准确率。 ### 4.3 从原始 prompt 抽象变量槽位 做 skill 的另一个关键动作是抽象出变量槽位。原始 prompt 里最具体的那些部分恰恰是最难复用的部分。拿代码审查为例 - 原始说法帮我看一下订单模块的这段逻辑有没有并发问题 → 抽象为被审查代码输入槽位 - 原始说法重点是性能和安全性 → 抽象为审查维度可选项默认全维度 - 原始说法给我个报告 → 抽象为输出格式固定为结构化表格 这样一来同一个 skill 可以处理不同维度、不同语言的代码审查任务。遇到需要特定维度的审查时用户只需在任务描述里补充一句skill 的核心流程不用改。 最后聊一下一个 skill 做多大合适。我被问过是不是 skill 越细越好答案是看维护成本。我一开始把代码审查拆成Python代码审查性能审查安全审查三个 skill实际使用后发现触发经常互相打架——一段 Python 代码同时命中两三个 skill模型不知道该听谁的。后来合并成一个code-review把维度变成参数反而稳定多了。 我的经验是**skill 的粒度应该对齐任务目标而不是工具类型或语言**。用户任务是做一次代码审查那就做一个 code-review skill用户任务是写一段 Python 正则那才是做一个 Python 正则 skill。你是在让模型完成一个任务不是让模型记住一个函数。 ## 5. 实测一轮后暴露的三个问题——触发不准、旧假设失灵、粒度失衡 skill 做出来不是终点真正的问题是用起来以后暴露的。我拿第一批封装好的 skill 在真实任务里跑了一轮踩了三个有代表性的坑每个都值得单独说。 ### 5.1 description 写太长触发反而越来越不准 第一个问题出现的场景很典型我精心写了一个结构化日志分析的 skilldescription 洋洋洒洒写了几百字把日志格式、处理流程、输出要求全部塞了进去心想描述得越详细模型越容易判断。结果实际使用里它在该触发的时候没触发反而有一次用户让我把这份通知按模板格式化时它跳出来干扰了另一个 skill。 排查过程让我明白了原因模型做 skill 匹配时看的核心依据就是 description 的前几句话。当 description 里塞满了各种任务场景名词和术语时前几句话很容易和不相干的任务产生字面重叠导致误触发同时详细的描述会稀释关键触发词的权重让真正相关的任务在匹配阶段得分不够高。解决方法是把技术细节全部移到 SKILL.md 正文description 只保留三层结构什么时候用、输入是什么、输出是什么。压缩到三句话之后触发准确率显著提升。 ### 5.2 早期 prompt 里的重复强调成了新模型的负担 我在整理 golden prompts 时发现不少早期的优秀 prompt 里充满了请务必非常重要仔细思考一步一步来这类强调词。这些词在旧模型上是有效的——当时的模型注意力机制容易跑偏需要靠这些敲黑板式的词汇把重点圈出来。 但当我用新版模型重新测试这些 skill 时问题来了模型已经把逐步思考和聚焦重点变成了内建能力那些重复强调反而让输出变得啰嗦、拖沓回答速度也变慢质量却没提升。我做了一次减压处理把所有重复的情绪化强调词删掉只保留行为指令和输出约束。测试下来的结果让我意外——质量和原来持平输出更简洁了。 这件事给我一个很重要的教训golden prompts 不是金科玉律。模型能力在迭代你的 skill 也要跟着重新验证。我现在每次模型大版本更新后会挑出使用频率最高的10个 skill 跑一遍回归测试像刷新自己的知识库一样刷新 skill 库。过时的 skill 不删除而是标注已归档放到旧版本目录里——说不定以后回退模型版本时还能用上。 ### 5.3 粒度失衡拆太细不如合并成任务级 skill 第三个问题虽然排在最后但带来的维护负担最大。第一批做 skill 时我遵循单一职责原则把脚本类任务拆成了写 Python 正则的 skill写 Shell 命令的 skill写 SQL 查询的 skill三个独立模块。 表面上很合理实际用起来全是问题。一次任务里我让模型写一个解析日志的 Python 脚本结果同时命中了Python正则和Shell命令两个 skill——模型试图同时按照两份流程执行输出来回摇摆最后我不得不手动关闭一个 skill 重新跑。而且三个 skill 的维护成本也很高改一个脚本生成逻辑要同步三处。 后来我把它们合并成一个脚本和命令编写skill统一约束如果目标是生成可执行脚本先确认输入输出再选择语言最后输出可运行的完整代码。合并之后触发准确率和回答质量都明显提升。这件事让我把粒度控制原则总结成一句话**粒度对齐任务目标而不是对齐工具类型**。用户要的是完成一件事不是调用一个函数。 除了这三个大坑还有一个维护技巧值得分享当 skill 的输出不如预期时先别急着改。把 skill 降级成普通提示词贴进空白会话和模型纯聊一次对比效果。如果纯提示词效果差说明模型能力不够或者上下文缺信息问题不在 skill 本身如果纯提示词效果好那说明 skill 的结构设计有问题可能是步骤太多分散了注意力也可能是输出格式描述产生了误导。这个对比法能帮你快速定位是 skill 的问题还是外部因素省去大量盲目调整的时间。 最后再分享一个我现在一直在用的小习惯当某次会话的产出明显超出预期时我不再等会话结束再去翻记录整理而是立刻在对话里让模型基于这次产出帮我写一版 skill 初稿——相当于把沉淀这件事从离线整理变成了即时动作。模型先出草稿我再人工打磨十分钟积累成本一下子就降下来了。6000多次会话看着多真正能沉淀成 skill 的反而都是当时顺手记下来的那几条。这个习惯比任何整理技巧都管用你要是也想把手里那一堆零散提示词变成自己的技能库不妨从明天开始试试。