
先说结论那些能被反复复用、换个场景依然好用的提示词才是真正值得沉淀的东西。6000 多次会话攒下来的百条 golden prompts不是靠运气碰出来的而是靠大量的失败、对比、修正一点点筛出来的。把这些提示词做成 skill本质上是把碎片化的经验变成一套可调用的方法论让 AI 不再需要你每次重新费口舌讲背景、讲约束、讲输出格式。这篇文章就聊清楚三件事什么样的提示词够格叫 golden、skill 到底怎么把提示词包装成可复用的能力、以及我在沉淀这百条 skill 过程中踩过的坑和总结出的排查方法。如果你也在大量使用 Claude Code、Codex、OpenClaw 这类支持 skill 机制的 AI 编程工具这篇文章会给你一套直接从零落地的思路。1. 为什么非要把提示词做成 skill先说一个很多人没意识到的点提示词本身是一次性的。你在对话框里写一段高质量的 prompt得到一次完美回答这事儿就结束了。下次遇到类似问题你还是得重新组织语言、重新把上下文背景贴一遍、重新让对方理解你要什么格式的输出。这种重复劳动攒多了以后会非常烦躁。而 skill 解决的是另一件事它把提示词、示例、约束、甚至脚本和模板打包成一个可被 AI 自动调用的组件。只要你触发了 skill 的关键词或描述AI 就会读取你预先写好的整套指令按里面定义的流程和要求来执行。我最初拿到 Claude Code 的 skill 功能时也没太当回事。真正让我决定把提示词全部改造成 skill 的是一次对比实验同一个需求——分析这段代码的性能瓶颈并给出优化建议——直接用对话我要解释项目背景、语言版本、期望输出格式光铺垫就花了几百字。而封装成 skill 之后一行触发词AI 自动按 skill 里的流程走从代码走查、性能分析、瓶颈定位到优化建议全套流程稳定复现且输出质量一致。这里有个简单的类比提示词是每次见面重新自我介绍skill 是递上一份完整简历。行业内还有个提法——agent 的肌肉记忆我很喜欢这个说法因为 skill 本质上就是在给 AI 建立可重复调用的行为模式让它在面对特定任务时不需要你从零训练直接按预设的路径走。1.1 skill 和 agent 到底啥关系结合当前热词里大量关于skill 和 agent 的区别的搜索我多说两句。很多人会把 skill 和 agent 概念搞混实际理解起来其实不复杂agent 是决策者它负责理解任务、拆解步骤、选择工具像是一个管理者。skill 是执行能力它给 agent 提供一套标准化的操作流程和知识储备像是员工手册或操作 SOP。所以更准确地说agent 负责编排skill 负责执行。一个 agent 可以挂载多个 skill根据任务类型动态加载不同的 skill。比如我常用的一个 code review agent 就挂了三套 skill——性能分析、安全审计、代码风格检查每个 skill 对应一套专门打磨过的工作流这样 agent 的通用编排能力和 skill 的专业深度就能互补。1.2 6000 次会话沉淀出来的真实路径再说回我这 6000 多次会话。这个数字不是虚的是我在过去大半年里实际积累的。你可以理解为平均每天 30-50 次与 AI 的深度交互覆盖了代码调试、架构设计、文档撰写、数据处理、SQL 分析、技术方案评审甚至帮朋友做的数学建模题目练习。沉淀路径大致是这样的每次对话结束后把聊出来的高质量 prompt 存到一个总文档里记下使用场景和效果。大约每攒 50 条左右做一次去重和归类淘汰那些只有一次性价值的 prompt。最终筛选出约 100 条 golden prompts再按照类型拆分成三类框架逐条封装成 skill。封装的过程中不断回炉测试发现效果不稳定的继续修改直到输出质量可控。这个过程没有任何捷径核心就是高频使用有意识地记录筛选。6000 次对话听起来吓人其实拆到每天也就那么点量关键是养成觉得这句 prompt 好用就立刻存下来的习惯。2. 6000 次会话里什么样的提示词才配叫 golden先说个残酷的事实你觉得自己写得不错的提示词大概有七成不够格进入 skill 库。golden prompts 的定义不是这次回答得好而是换一个场景、换一个项目、换一个数据源它依然能稳定输出高质量结果。我筛选 golden prompts 时用四个硬性标准缺一不可筛选标准具体要求淘汰比例可复用性必须能在至少三种不同场景下使用不是一次性的45% 被淘汰稳定性同一组输入多次执行结果质量波动小20% 被淘汰结构化对输出格式有明确定义可预期、可解析15% 被淘汰逻辑自洽指令本身不矛盾、不含歧义、不依赖运气10% 被淘汰你会发现判定一个 prompt 是否 golden核心不是看它写得好不好看而是看它稳不稳。我见过很多花里胡哨的提示词角色设定一长串各种专业术语堆砌但实际用起来输出飘忽不定这种完全没有沉淀价值。2.1 从普通 prompt 到 golden prompt 的三次改造我拿一条最典型的例子来说明一开始我用的是这种 prompt——帮我看看这段代码有什么问题。这属于典型的模糊提问AI 会给你一个万金油式回答什么可读性有待提升、建议添加注释之类没有任何实质价值。第二次改造加上了约束条件——你是资深 Python 工程师请审查这段代码关注性能瓶颈、潜在 bug、安全漏洞按优先级输出修改建议。这次效果好了不少但输出格式不统一有时候给我编号列表有时候给我大段文字。第三次改造加入了结构化输出要求——请按此格式输出问题描述、影响范围、复现步骤、修改建议、修复代码示例按严重程度从高到低排列并给出置信度评分。到这里这条 prompt 才算有了 golden 的雏形。这就是一个典型的沉淀过程从模糊到清晰从无约束到有约束从自由输出到结构化输出。6000 多次会话里积累出来的经验本质上就是这么一轮一轮迭代出来的。2.2 几条被验证过的高频 golden 类型先说共识你自己在实践中最常重复使用的那一类提示词往往最值得做进 skill。我这边沉淀出来最有价值的几条类型如下你可以对照自己的使用习惯看看有没有相似的代码审查类要求 AI 按安全、性能、可维护性三个维度做交叉审查输出分级问题和可运行的修改建议。通用设计类要求 AI 从问题定义、约束条件、候选方案、方案对比、最终推荐这五步来输出技术方案。文档写作类要求 AI 指定受众、指定语气、指定结构并要求在正式输出前给出一版大纲供确认。数据分析类要求 AI 先说结论和数据来源再展示分析推理过程最后给出决策建议。这几类提示词在我的实际使用中几乎每天都会用到一两次所以它们被我最先抢着装进了 skill 里。2.3 不配叫 golden 的三种典型提示词有正向标准也得有负向清单。我淘汰掉最多的提示词主要有三类你也可以自查一下自己手里是不是有类似的东西角色堆砌型请你扮演一个拥有 20 年经验、精通所有编程语言、对性能优化有独到见解的资深架构师同时兼具……这种开头我见一次删一次。角色设定的作用是提供约束不是用来堆砌权威感的。一条靠谱的提示词角色设定不会超过一句话。万能许愿型请帮我做一个高质量的用户管理系统完了没有业务约束、没有技术栈要求、没有交互逻辑说明。这种 prompt 不管 AI 多强都只能给你一个花架子。没有约束就没有个性没有个性就不是 golden。格式失控型对输出格式没有任何要求想到哪聊到哪。这种提示词得到的回答通常你需要再花两三轮去整理、归拢、让他重写。与其这样不如一开始就定义好输出格式省下的时间成本非常可观。3. skill 到底长什么样——一条 prompt 到一套组件的完整改造聊清楚了哪类提示词值得沉淀接下来进入核心实操环节。我把一条普通的 golden prompt 改造成一个标准 skill大致要经历六个环节。下面按我自己常用的落地方式展开你可以直接参考这套流程去改造你自己的提示词库。当前主流 AI 编程工具比如 Claude Code、Codex对 skill 的加载方式基本都遵循同一套逻辑在项目或全局目录下创建.claude/skills或类似结构每个 skill 是一个子目录目录里有SKILL.md作为主文件有的还支持挂载参考资料、模板文件、脚本等。SKILL.md 里通过 YAML frontmatter 声明 name、descriptionmarkdown 正文写具体的执行流程和指令。3.1 先把 SKILL.md 的核心结构吃透一个标准的 SKILL.md 我建议包含以下区块这套结构来自我大量拆解社区热门 skill包括那几个搜索量很高的 superpowers、taste 类项目后的总结--- name: 技术方案设计 description: 产出结构化的技术方案文档。触发条件包括设计系统架构、评估技术选型、输出方案对比、编写设计文档。 --- 1. 需求澄清阶段先向用户确认三个问题——目标场景、约束条件、可接受的复杂度 2. 信息收集阶段识别用户已提供的信息与缺失信息缺失部分明确追问 3. 方案生成阶段按 3 个候选方案横向对比包括各自的优势、代价、适用边界 4. 推荐与输出阶段给出推荐方案说明理由并输出标准格式的设计文档这套模板的核心思想是把 AI 的行为路径固定下来。技能的核心价值不是让它更聪明而是让它更可控。skill 正文章节的目的就是定义遇到这类任务时你要按什么顺序做什么把不可控的发挥压缩到最小。注意description 字段是 AI 能否正确触发 skill 的关键。我踩过的坑是 description 写得太泛导致无关任务也触发写得太窄又导致相关任务不触发。最佳实践是触发条件 具体行为双描述比如技术方案设计……触发条件包括设计系统架构、评估技术选型、输出方案对比。3.2 将百条 golden prompts 拆成三类 skill 框架6000 多会话沉淀下来的百条 golden prompts如果一条一个 skill目录会非常混乱我建议一定要做归类将相近逻辑的提示词合并成一个 skill然后用工作流把它们串起来。我自己的做法是分成三大类代码工程类 skill包括代码审查、性能分析、架构设计、单元测试生成、重构建议等每一条原来的 golden prompt 化简为 skill 里的一个具体 section。写作表达类 skill包括技术文档撰写、PRD 生成、会议纪要整理、周报优化等核心特征是流程固定要求强格式输出。思考推理类 skill包括问题拆解、方案对比、风险分析、复盘总结等这类 skill 的重点不在格式而在思考步骤的严谨性。归类后的好处很明显触发词可以合并AI 的上下文占用更小——因为一个 skill 只需要读一份总文档而不需要检索一百份零散提示词。3.3 触发词和元信息设计skill 的元信息是 skill 与 AI 之间的接口。为了让 AI 能在关键时刻想起这个 skillname 和描述是最关键的信息——名字要直白描述要把触发场景写充分。以我的code-reviewskill 为例--- name: code-review description: 以资深工程师视角审查代码质量。当用户请求审查代码、检查 bug、分析代码隐患、评估代码可维护性时使用。输入为代码地址或代码片段。 ---这个描述覆盖了三种最常见的触发场景查 bug、查隐患、评估质量比单纯的代码审查覆盖面宽很多。但如果写得太泛比如代码相关的内容都可以触发就会导致 AI 在正常写代码时也莫名其妙地触发整套审查流程既消耗 token 又拖慢响应。3.4 示例输入输出是 skill 的灵魂很多人写 skill 只写了指令没写示例。这是很大的一个遗漏。我自己的验证结果是带 1-2 组示例的 skill输出稳定性和格式符合度能提升一半以上。还是说代码审查 skill我在里面挂了一个 example 区块贴了一段有性能问题的代码片段以及期望的输出结构。AI 看到示例后即使前面指令写得不够细它也能通过模仿示例来对齐输出风格。这就像你教新人做事的时候光讲规则不如直接给他一人做过的成果参考效果完全不是一个量级的。3.5 挂载模板、脚本和数据文件SKILL.md 只是入口skill 的真正威力在于能挂载额外的资源文件。我的百条 golden prompts 里有相当一部分属于强模板场景比如 SQL 分析、测试报告、周报总结这些我全部把模板抽出来单独存成一个参考文件在 SKILL.md 里用说明文字引用。一个实际的目录结构大概是这样的my-skills/ └──>