1. 为什么提示词学会就废？先搞懂 Skill 到底解决什么问题
这两年我见了太多人，提示词收藏了上百条，真正能稳定复用的没几条。今天问 ChatGPT 要一个方案觉得不错，明天换个需求重新写一段提示词，效果又飘了。问题不在于你写的提示词不够好，而在于你从来没把它当成一个正经的工程产物来对待。
提示词工程的核心早就不是“怎么把话说得更像人话”，而是怎么把一次性的灵感碎片，沉淀成一套可以反复调用、稳定输出、能跨场景迁移的能力单元。这个概念现在有一个更准确的名字：Skill，也就是 AI 技能。
先说清楚，Skill 不是什么玄学。你可以把它理解成给 AI 制定的一份“岗位职责说明书 + 标准作业流程”。普通人写提示词，是告诉 AI 今天你要干什么；而建立 Skill，是告诉 AI 你的角色是什么、你按什么步骤思考、你输出什么格式、你卡在什么标准上、遇到边界情况怎么处理。区别就在于，前者是一次性对话，后者是可复用的能力档案。
我最早开始重视 Skill 这个概念，是在用各类 AI 编程工具时发现，每换一个项目就要把同样的架构设计原则、代码规范、测试要求重新说一遍，效率极低。后来看到宝玉老师分享的那套 5 步工程化流程，一下子把“提示词”从手工作坊拉到了流水线生产的层面。你不需要懂编程，也能把一段提示词做成可以反复调用的资产。
这篇文章我会拆开讲清楚这套流程的每一步，用一个真实案例完整走一遍，再把实操中踩过的坑和排查思路全部摆出来。适合谁看？适合所有正在跟大模型打交道、又不满足于“聊一次算一次”的人。不管你是产品经理、运营、程序员还是内容创作者，只要你日常需要反复让 AI 做同类事情，这套方法都能帮你省下大量返工时间。
2. 拆解核心概念：Skill、Prompt、Agent 到底什么关系
在进入 5 步流程之前，有一个基础问题必须盘清楚，不然你后面做 Skill 的时候，很容易跟 Agent 混在一起，概念一乱，工程结构就跟着乱。
2.1 提示词是“一句话”，Skill 是“一套流程”
普通提示词是即兴的，你输入一句“帮我写一篇产品文案”，AI 给你一个回应，对话结束，上下文跟着作废。Skill 则是一个有边界、有输入输出协议、有质量标准的独立模块。它通常包含：
- 角色的定义：AI 以什么身份来处理任务
- 任务的拆解：把目标分解成可执行的步骤
- 输入变量的占位：允许每次调用时传入不同的业务参数
- 输出的格式约束：结构化输出，方便后续处理
- 质量的校验规则：输出前 AI 需要自检是否满足哪些标准
- 异常情况的兜底策略：遇到没有足够信息时该怎么处理
形象一点说，提示词是给外卖员打的一个电话，告诉他你家的地址、你想吃什么；Skill 则是这家餐厅自己后厨的 SOP 手册，规定每道菜放多少盐、炒几分钟、出锅什么颜色。
2.2 Skill 和 Agent 的区别，关键看“谁来决策”
很多人问，Skill 做出来的东西，跟 Agent 有什么区别？我的理解是这样的：Agent 是一个具备自主规划、自主调用工具、自主决定下一步动作的执行主体，它像一个项目经理；Skill 则是被调用的一项专业能力，像某个岗位的操作流程。
Agent 可以调用 Skill，一个 Agent 可能由多个 Skill 组合而成。反过来，Skill 不负责做决策，它只负责在特定任务上稳定输出。这就好比一个熟练的技术工人手里有一套专用工具，工具不替他决定要做哪个零件，但工具能保证他做出来的每个零件尺寸一致。
这个区分在实操中很重要。如果任务本身是开放式、探索式的，比如“帮我们策划下个月的内容选题”，适合用 Agent 去跑；如果任务是固定流程、重复出现的，比如“根据这篇论文生成结构化摘要”，那把它做成 Skill 的效率远高于每次重新对话。
2.3 为什么工程化流程比“灵光一现”更可靠
我们常用的网页版 AI 工具，本质上都是靠临时对话驱动的。问题是，同一个需求今天写一段提示词能用，明天加了一个小变化，又得从头调试。这个“调试”成本是隐性的——你以为你只是在打字，其实你在反复做提示词工程。
把提示词工程化之后，最大的变化是“稳定”。你不需要每次都写完整的一套指令，只需要传入变量，Skill 会自动用固定的高质量逻辑来生成结果。长远来看，你会慢慢积累起一批属于自己的 Skill 库，这些技能就像你的数字资产，跨项目、跨工具都能用。
3. 宝玉老师 5 步工程化流程详解：从灵感碎片到稳定技能
接下来进入正题。宝玉老师的 5 步流程，我拆开揉碎讲，并且每一步都会结合一个我在实际项目中验证过的细节。
3.1 第一步：锁定单一目标，把模糊需求变成可验收的问题
做 Skill 最常见的失误，是一上来就贪大。“帮我写一个万能的文案助手”这种目标，注定做不出高质量的 Skill。正确的做法是先锁死一个非常具体的任务边界。
我当时做第一个 Skill 时，目标定的是“把简历中的工作经历描述，改写成符合 STAR 法则的高质量条目”。目标里包含了几个关键信息：处理对象是简历里的工作经历，处理方式是改写，处理标准是 STAR 法则。这样 AI 就不是漫无目的地写，而是有一个清晰的验收清单。
在锁定目标时，你可以问自己三个问题：这个任务哪些部分是每次都不变的？哪些部分是每次会变的？什么结果才算是“做得好”？把这三个问题的答案写下来，你就已经完成了 80% 的目标定义。
3.2 第二步：搭提示词骨架，用固定结构约束模型的发挥空间
目标锁定了，接下来就是写提示词的主体。我强烈建议你不要写成一整段自然语言，而是拆成几个固定的区块，这样后面调度和迭代都会舒服很多。
我常用的结构是五个区块：
第一个是角色区，明确告诉模型“你是一名资深 HR 总监，有 10 年互联网行业招聘经验”。角色不是摆设，它决定了模型调用的知识侧重和语气风格。
第二个是任务区，用一两句话描述本次要完成的事情。这里的关键是动作要具体，不要出现“帮助”“支持”这类空洞词汇，直接写“把以下工作经历改写成 3 条符合 STAR 法则的条目”。
第三个是输入区，用变量占位。比如“{{工作经历}}”和“{{目标岗位}}”。这里不写死内容，每次调用时传入。
第四个是步骤区，列出模型需要按顺序执行的推理过程。比如先分析原经历中的情境、任务、行动、结果分别是什么，再判断哪些细节值得保留，最后按时间顺序重组。
第五个是输出区，定义格式和约束。例如“输出 Markdown 格式，每条包含不超过 50 字的改写说明”。
这五个区块不是随意的，它实际上是在给大模型的注意力画轨道。模型在你给它铺好的轨道上跑，稳定性比自由发挥高得多。我见过很多人写提示词喜欢说“请你自由发挥”，结果就是模型发挥得时好时坏，根本没法用到生产里。
3.3 第三步：建立反馈闭环，用测试驱动提示词迭代
这一步是大多数人会跳过的，也是 Skill 质量好坏的分水岭。写完提示词骨架只是开始，真正要花精力的地方是测试和打磨。
我的做法是，准备 5 个以上不同难度的输入样例，每一次调整提示词之后，都用同一批样例去跑，看输出的稳定性。这跟写单元测试是同一个逻辑——你不能只测一次觉得还行就算完，你要反复确认在边界情况下的表现。
举个例子，我测试简历改写 Skill 时，其中一个测试用例是“原经历本身写得很差，只有一句话且没有数据”。第一次跑出来的结果，模型只是把原句换了个说法，根本没有提炼出亮点。我针对这个问题在步骤区增加了一条：“如果原经历缺乏信息，不要强行编造，在改写说明中明确指出缺少量化数据，并给出补充数据的建议方向。”
这种基于反馈的调整，大概迭代了四五轮，Skill 的稳定输出率才达到我满意的水平。你要有耐心，Skill 工程本身就是一个不断让模型更懂你的过程。
3.4 第四步：参数化与抽象，把业务细节抽出去，把通用能力留下来
Skill 之所以能“复用”，核心在参数化。那些每次会变的业务内容，比如具体的简历文字、目标岗位名称、产品卖点，都抽成变量；那些每次不变的规则和判断逻辑，固化成提示词里的固定文字。
这一步常见的误区是过度抽象。有人做一个文案 Skill，想把所有文案类型都包含进去，结果指令上下文塞了一堆互相矛盾的规则，模型在执行时无所适从。我更推荐“一个 Skill 解决一类任务”的思路：简历优化就是一个 Skill，商品详情页改写是另一个 Skill，两者不合并。虽然看起来 Skill 数量多了，但每个 Skill 的提示词更短、内部逻辑更一致，实际效果反而最好。
参数化的另一好处是，你可以在不同场景下复用同一个 Skill。简历优化 Skill 把“目标岗位”做成变量之后，同一个 Skill 既可以用在投技术岗的场景，也可以用在转行运营的场景，只要传入参数即可。
3.5 第五步：文档化与版本管理，让 Skill 成为可迭代的长期资产
最后一步最容易被忽略，却是长期收益最大的一步。所谓文档化，不只是把提示词存到一个文件里，而是要给每个 Skill 写一个说明，包括：这个 Skill 解决什么问题、适用什么场景、不适用什么场景、输入变量有哪些、输出格式是什么、已知的局限有哪些。
版本管理也很重要。Skill 的迭代不是一次性的，过了一段时间你可能想调整某些规则。如果你没有版本记录，改来改去很容易改坏。我的习惯是每次调整后，在文件头部更新版本号和变更说明，例如“v1.2，增加对无信息经历的兜底处理”。
如果你用的是支持 Skill 结构的工具，比如 Claude 的 Agent Skills 或者 Codex 的 skills 机制，那更好，可以直接做成目录文件，里面包含 SKILL.md、参考文档、脚本等。就算你只在普通网页版里用，也可以把 Skill 存成 Markdown 文件放在自己的笔记库里，需要的时候复制到对话框里。
4. 实操案例：从 0 到 1 打造一个“简历优化 Skill”
理论讲完，必须做一遍才有体感。下面我完整展示一个简历优化 Skill 的搭建过程，包含提示词的完整结构、调试中遇到的典型问题和最终的稳定版本。
4.1 需求拆解与输入输出设计
任务目标：把一段平铺直叙的工作经历描述，改写成有亮点、可量化、符合 STAR 法则的高质量简历条目。
输入变量两个：一是原始工作经历文本，二是目标岗位方向。
输出要求：改写后的简历条目 + 每条配一行简短的改写说明。整体控制在合理篇幅内，不夸大不编造。
这个任务的难点在哪里？难点在于模型很容易把“改写”变成“重写”，加入原文没有的信息。所以我在提示词里专门加了一条约束：只基于原文提供的信息进行结构化重组和表达优化，不做事实扩充。
4.2 完整提示词骨架示例
以下是我调试完成后的一个精简版本，你可以直接复制参考：
角色： 你是一名资深的人力资源专家，擅长简历优化，尤其熟悉互联网行业的岗位要求和技术语言。 任务： 将用户提供的原始工作经历文本，改写成若干条符合 STAR 法则（情境-任务-行动-结果）的高质量简历条目，让每条条目更有说服力和可读性。 输入变量： 原始工作经历：{{工作经历}} 目标岗位：{{目标岗位}} 执行步骤： 1. 阅读原始工作经历，提取其中涉及任务和动作的关键信息。 2. 判断原文中哪些部分对应 STAR 法则中的 S、T、A、R 元素；如果缺失，不要自行编造。 3. 将提取内容按行动和结果优先的原则重组语言，使用动词开头，突出个人贡献。 4. 如果有量化数据，尽量放在结果部分；如果没有数据，保留事实描述，并在改写说明中提示补充方向。 5. 输出多条简历条目，覆盖原文的主要工作内容。 输出格式： 1. 改写后的简历条目（每条 1 行，使用 - 开头） 2. 每条条目下方缩进附一行改写说明，格式为：改写说明：... 3. 在最后附一个“补充建议”，列出原文中缺失但可向沟通对象确认的信息。 约束： - 只能使用原文中出现过的信息，禁止虚构数据或业绩。 - 不要添加“负责”“参与”这种模糊词，换成“主导”“推动”“搭建”等有行动指向的动词。 - 语言要简洁，每条不超过 80 字。你可以看到，这个提示词把“角色”“任务”“输入变量”“执行步骤”“输出格式”“约束”全部拆开，模型在执行时就是在按这套流程走。它不是灵光一现的产物，而是一份可以重复执行的 SOP。
4.3 调试中踩过的坑：角色冲突、输出漂移、变量污染
做这个 Skill 的过程中，我踩过三个典型的坑，值得单独拿出来说。
第一个坑是角色冲突。一开始我在角色区写的是“你是一位经验丰富的简历编辑”，同时又在任务区加入了“你是一位招聘经理，知道公司想看什么”。这两个角色的立场不完全一致，导致输出风格一会偏求职者视角，一会偏招聘方视角。后来统一成“资深人力资源专家”，立场就稳了。
第二个坑是输出漂移。模型在多轮迭代之后，偶尔会突然改变输出格式，把原本要求的“先条目后说明”顺序打乱，或者出现编号。后来我用两招解决：一是在输出格式区强调“严格按照以下格式”，二是在测试用例回归中加了一条“格式合规检查”，每次调整后先确认格式没飘。
第三个坑是变量污染。我在测试时发现，当输入的目标岗位是“产品经理”时，模型可能会从知识库里带出一些简历优化的通识内容，甚至把上一轮测试的其他岗位信息混进来。这个问题不太好根治，目前的缓解方案是在任务开始前加一句“忽略所有与本次输入无关的背景知识，只基于当前提供的原始经历文本进行处理”。变量污染在复杂 Skill 里出现的概率更高，建议在提示词里始终保持“只基于输入”的约束。
4.4 复用验证：从简历场景迁移到文档优化
Skill 建好之后，最大的成就感来自于场景迁移。
我用同一个提示词骨架，把输入变量从“工作经历”换成“产品功能描述”，输出从“简历条目”换成“功能亮点清单”，中间的核心逻辑——动作动词开头、结果导向、量化补充——几乎不用改动，就得到了一个新的“产品功能优化 Skill”。
这说明参数化做得好的话，Skill 的核心价值确实可以沉淀下来。你不用每次从零开始设计提示词，只需要调整输入变量和输出格式，就能在相邻任务间快速复用。
5. 常见问题与排查技巧实录
最后一部分，我把实操中经常被问到的问题统一整理一下。这些经验大多是从踩坑中得来的，比你搜教程来得实在。
5.1 高频问题速查表
| 问题现象 | 可能原因 | 排查动作 | 预期结果 |
|---|---|---|---|
| Skill 一次能用，换个输入就表现很差 | 过度拟合了测试样例 | 增加更多边界测试输入，检查提示词中是否有隐含的假设 | 不同输入下输出质量趋于稳定 |
| 模型输出格式经常变化，不按模板走 | 输出格式约束不够明确，或被淹没在长文中 | 把输出格式区放到提示词最后，并用“必须”“严格”等强约束词 | 格式漂移率明显下降 |
| 模型开始编造原文没有的信息 | 没有显式禁止虚构，或步骤区给了太多自由 | 增加“禁止虚构事实”约束，并在步骤中要求先提取原文信息 | 输出严格基于输入 |
| 同一段输入，多次运行结果差异大 | 温度参数偏高，或提示词缺少确定性引导 | 降低温度，增加步骤区和自检环节 | 输出趋于一致 |
| Skill 用着用着效果变差 | 上下文被无关对话干扰 | 每次使用前清空上下文，或把 Skill 做成独立模块 | 效果恢复稳定 |
| 不知道该把哪些内容做成 Skill | 目标设置过宽 | 优先选择每周重复三次以上的固定任务 | 高频率任务先固化 |
5.2 Skill 和 Agent 怎么选，我给一条判断标准
很多人在接触 AI 工程化之后都会被 Agent 吸引，觉得 Skill 不够“智能”。我个人的判断标准是这样：固定流程、需要稳定输出的任务，优先做 Skill；需要探索信息、规划路径、动态决策的任务，适合用 Agent。
比如“从 30 篇论文里提取出 OLED 材料的关键性能参数并生成对比表格”，这就是一个流程明确的任务，做成 Skill 非常合适。而“帮我调研一下这个行业的竞品情况，并给出建议”，这是一个开放式任务，更需要 Agent 来拆解步骤和调动各种工具。
说白了，Skill 适合“把事做对”，Agent 适合“决定做什么”。两者不是竞争关系，是配合关系——Agent 做决策，Skill 做执行，这是我目前最推荐的组合。
5.3 个人经验：Skill 不在于多，而在于精
最后分享一个我自己的习惯。我见过有些人一下午做了一百个 Skill，实际用起来没几个好用的。我的建议是反着来，一个月只精心打磨三五个 Skill，但每一个都要做到稳定可靠。
怎么判断一个 Skill 已经“稳”了？我会用同一个 Skill 在至少 5 个不同场景、不同类型输入下测试，只有所有输出都达到“可以不用修改直接使用”的程度，才算合格。达不到这个标准，就反复迭代，不要急着上线。
另外别忘了，Skill 的维护不是一次性的。模型在升级，你的业务在变化，Skill 也需要定期回到测试集上重新跑一遍，看看有没有因为模型底层更新而出现质量退化。养成这个习惯之后，你的 Skill 库会越来越值钱，它不再是一堆提示词的堆砌，而是真正属于你的可复用能力资产。
