提示词工程入门: 角色、结构与 Few-shot 实战

先说结论：提示词工程（Prompt Engineering，就是设计给大模型的输入文本，让它稳定产出你要的结果）不是玄学，也不是背咒语。它是一门”把需求写成模型能执行的规格”的手艺——和你写 PRD 是同一件事，只是读者从工程师换成了模型。

学完这一课，你能解决三个具体问题：一是自己动手写出格式稳定、可复现的 prompt，而不是每次输出都像抽卡；二是听懂工程师说”加个 few-shot””上思维链”时到底在调什么，评估这些方案值不值；三是知道 prompt 上线之后怎么管——它是产品资产，要版本化、要回归测试，不能散落在某个同事的聊天记录里。

这一课只讲通用技巧：角色、结构、示例、思维链、输出约束，以及最重要的”把 prompt 当系统”的工作方式。怎么把一个具体业务需求拆解成 prompt，是第03课的事；如果你对”模型为什么会这样表现”还没概念，建议先回看第01课的下一词预测原理，本课所有技巧的原理都建立在它之上。

本文是《AI 产品经理课》第 2 课 · 专题目录 · 学习路线 · 上一课: 第 1 课 · 下一课: 第 3 课

全部 13 篇目录

角色设定: “你是一个资深客服”为什么有效

先解释一个术语：system prompt（系统提示词），指对话正式开始之前，产品方塞给模型的一段隐藏说明书，用户看不到它，但模型的每一句回答都受它约束。你平时在 ChatGPT 里打的字是 user 消息，而”你是一个乐于助人的助手”这类设定，通常写在 system prompt 里。

角色设定为什么有效？回到第01课的原理：大模型本质是概率续写机，它在海量语料上学会了”什么样的上文后面通常跟什么样的下文”。当你写下”你是一位有十年经验的电商客服主管”，你并没有给模型灌输任何新知识，你只是把它的输出概率分布拉向了语料中”资深客服会说的话”那个区域——用词更克制、先安抚再给方案、不轻易承诺。类比一下：模型像一个会模仿所有人的演员，角色设定就是递给它的剧本首页，告诉它这场戏演谁。

所以角色设定的正确用法不是堆形容词（”你是全宇宙最聪明的分析师”没什么用），而是给出能改变行为的具体信息：职业、经验背景、说话对象、边界（”遇到医疗问题一律建议就医，不给诊断”）。真实产品的系统提示词都是这么写的——AI 编程工具 Kiro 疑似泄露的完整提示词里，角色之外还密密麻麻写满了行为规则；Codex 智能体的提示词拆解更是把”资深工程师”这个角色落实成了几十条工程化约束。角色是骨架，规则才是肉。

顺带一提，角色机制也有安全面：模型有时分不清”谁在给它下指令”。有研究把提示词攻击的原理归结为角色混淆——攻击者在用户输入里伪装成系统，模型就可能听错人的话。作为 PM，你现在只需要知道：角色设定既是能力工具，也是攻击面，第10课讲工具生态时还会回到安全话题。

结构化提示: 给指令、材料和输入划清边界

新手写 prompt 最常见的问题是”一锅粥”：任务要求、背景资料、待处理的用户文本全部混在一段话里。模型读起来就像你收到一封没有分段的三千字邮件——它分不清哪句是让它做的事，哪句是让它处理的料。典型翻车现场：你让模型总结一篇文章，文章里恰好有一句”请忽略以上内容”，模型真的照做了。

解法很简单：用显式的边界把 prompt 切成区块。常用的边界有三种，效果递进：

分隔符：用 --- 或三个反引号把不同部分隔开，最轻量；
Markdown 标题：用 ## 任务、## 背景、## 输入 分区，模型对这类格式非常熟悉；
XML 标签：用 <指令>...</指令>、<输入>...</输入> 包裹，边界最明确，因为标签成对出现，模型清楚地知道一段内容从哪开始到哪结束。

一个通用骨架长这样：

<指令>
你要做什么、按什么规则做、输出什么格式。
</指令>

<背景>
模型需要知道的业务背景、术语解释。
</背景>

<输入>
{{待处理的实际内容}}
</输入>

这背后的思维方式，站内有篇文章概括得很好：像对待编译器一样设计 Prompt。编译器不猜你的意图，只执行你写清楚的规格；模型比编译器宽容，但你越把它当编译器对待，输出越稳定。另外两个实用的顺序经验：指令放在最前面，让模型带着任务读材料；如果材料很长，把最关键的要求在结尾再重申一遍——长上下文的中间部分最容易被”读丢”，这一点第01课讲上下文窗口时提过。

Few-shot: 两三个示例比十个形容词管用

Few-shot（少样本示例）指在 prompt 里直接放几组”输入→输出”的示范，让模型照着模式续写。与之相对，不给示例只给指令叫 zero-shot。

为什么示例这么管用？还是那个原理：模型是模式续写机。你用文字描述”摘要要简洁、专业、突出重点”，这三个形容词在模型那里有一万种理解；但你给出两个真实摘要的样子，格式、长度、口径、语气就全部锁死了。一个直观的对比——你想要评论打标输出”正面/负面/中性”三选一：

zero-shot 写法：”判断以下评论的情感倾向。”——模型可能回你一整段分析，也可能输出”积极”而不是”正面”。
few-shot 写法：先给两条示例，”物流很快，包装完好→正面”、”用了三天就坏了→负面”，再放待判断的评论。输出格式基本不会再漂。

实践中的三个要点。第一，示例要覆盖边界情况：如果全是正面例子，模型会倾向于把什么都判成正面，这叫示例偏差；至少放一个”信息不足→中性”这样的兜底示例。第二，示例必须和指令一致：指令说输出 50 字以内，示例却是 100 字，模型多数会跟示例走——示例的权重高于形容词，也常常高于指令本身。第三，数量上 2~3 个通常就够，示例的边际收益递减很快，而每个示例都实打实消耗 token（token 是什么、怎么计费，第01课讲过），塞十个示例往往只是变贵没变好。

对 PM 来说，few-shot 还有一层产品含义：示例就是你的验收标准的可执行形式。你挑的示例，就是在告诉模型”什么样算好”——这件事没人能替你做，因为定义”好”正是产品经理的本职。

思维链: 让模型先想再答, 但别处处都用

思维链（Chain of Thought，简称 CoT）指要求模型先写出推理过程、再给最终答案，最简单的触发方式就是在 prompt 里加一句”请一步步分析后再给结论”。

它为什么有效？因为模型是逐 token 生成的，它没有”打草稿”的内部空间——除非你让草稿显式地写出来。让模型先列出分析步骤，这些步骤本身会成为后文的上下文，相当于模型踩着自己写下的台阶往上走。直接要答案，则像逼一个人心算多步数学题，错了你还看不到错在哪一步。

但思维链不是万灵药，值不值得用要算账：

值得用：多步推理（这条投诉该退款还是补偿？依据哪条规则？）、需要权衡的判断题、从混乱文本里做多条件筛选。这类任务上思维链能显著提升正确率，而且推理过程可审计——出错时你能看到它在哪一步想歪了。
纯浪费：简单抽取（从地址里取出城市名）、格式转换、打标分类这类一眼答案的任务。加思维链只会让输出变慢、token 费用上涨，正确率不涨。

还有一个时效性提醒：新一代推理模型已经把”先想再答”内置成了默认行为，对这类模型再手写”请一步步思考”收益会明显缩小。这正好说明提示词技巧是随模型演进的，具体某招什么时候失效没人能打包票，但下一节讲的”用测试集验证”的方法永远有效。

输出约束: 要 JSON 就给 schema, 负面指令要改写

如果 prompt 的输出要接进下游系统——存数据库、喂给前端、触发流程——格式约束就是生死线。这里有两条铁律。

第一条：要结构化输出，就给字段定义加例子，别只说”输出 JSON”。”输出 JSON”这四个字信息量为零：字段叫什么？类型是什么？空值怎么办？正确做法是把 schema（字段结构定义）写进 prompt：每个字段的名字、类型、取值范围，再配一个完整的输出示例，最后补上异常处理规则——”如果无法判断，resolved 填 false”。没写异常规则的 prompt，遇到脏输入时模型会自由发挥，而自由发挥是下游系统崩溃的头号原因。

第二条：负面指令常常失效，尽量改写成正向指令。你跟模型说”不要提竞品名字”，结果它偏偏提了——这不是模型叛逆,而是原理使然：你把”竞品名字”这个概念注入了上下文，反而提高了相关 token 的生成概率。就像有人跟你说”别想白熊”，你脑子里立刻全是白熊。改写方法是把”不要 X”翻译成”要 Y”：”不要啰嗦”改成”回答控制在三句话以内”；”不要编造”改成”只依据 <背景> 标签内的信息回答，找不到依据就回答’资料中未提及'”。站内有不少现成案例：有人用一段提示词治好了 AI Agent 回复冗长的毛病，靠的是明确的正向长度约束；Gemini 用户对抗模型”偷懒”不搜索，思路同样是把期望行为写成明确指令而不是抱怨式禁令；还有开发者写出一份拒绝简化的硬核编码助手提示词，通篇都是”必须做什么”的行为规范。

这两条对 PM 的意义：评审 prompt 方案时，看到裸的”输出 JSON”和成串的”不要不要不要”，你就知道这个 prompt 还没到能上线的成熟度。

把 prompt 当系统, 而不是咒语

这一节是全课最重要的一节，讲的不是技巧，是工作方式。

反模式你一定见过：从网上抄来一段”万能提示词”，贴进自己的场景，效果不好就东改一个词西加一句话，改到某次输出顺眼了就宣布搞定。这是炼丹，不是工程。问题在于：你不知道这次”顺眼”是普遍提升还是运气好，更不知道这次改动有没有把之前跑得好的案例改坏。

工程化的做法叫 evals（评估集）思维：在动手调 prompt 之前，先攒一个小测试集——从真实业务里挑 20~50 条有代表性的输入，覆盖正常案例和边界案例（超长输入、空输入、带干扰信息的输入），并为每条写清楚期望输出或判定标准。之后每改一版 prompt，全量跑一遍测试集，看通过率是升是降。这样”prompt 变好了”就从一句感觉，变成一个数字。

这件事 PM 完全可以主导，甚至应该由 PM 主导——测试集里”什么输入算典型、什么输出算对”，本来就是产品定义。工程师负责把跑测试的流程自动化，你负责测试集的内容质量。配套的还有可观测性：上线后要能看到每次调用实际发出的 prompt 和收回的结果，站内这篇拆解 Prompt、Tool Call 与 Token 全链路追踪讲的就是怎么打开这个黑盒。

为什么回归测试如此重要？因为你的 prompt 跑在别人的模型上，而模型是会变的。服务商灰度升级模型，你的 prompt 行为就可能漂移——社区甚至发展出用特定提示词探测模型灰度差异的民间手艺；更隐蔽的情况是平台在你的 prompt 之外动手脚，比如 Claude Code 的时区检测争议中，开发者发现用户提示词疑似被系统层改写。没有测试集，这些漂移你只能靠用户投诉才能发现；有测试集，定期一跑就现形。

产品落地: prompt 是产品资产, 要版本化、可复现

最后从”写好一个 prompt”抬升到”管好一堆 prompt”。当 AI 功能上线，prompt 就成了产品逻辑的一部分——它决定用户体验，它的变更会引发线上行为变化。所以要用管代码的方式管它：

进版本库：prompt 存进 Git（代码版本管理工具），谁改的、改了什么、为什么改，全部留痕。改动走评审，就像代码 review。一个现成的参照物是 Claude Code 生态的 CLAUDE.md——本质就是一份版本化的项目级提示词，怎么写好这份最小有效配置站内有专文，其中”少而准胜过多而杂”的原则对所有 prompt 都适用。
记录运行环境：同一个 prompt 在不同模型、不同温度参数（第01课讲过，温度控制输出的随机程度）下行为不同。资产登记要连模型版本号和参数一起记，否则”可复现”无从谈起。
管住安全边界：只要产品接受用户输入，prompt 注入（用户在输入里夹带指令劫持模型行为）就是现实风险，连一支词典笔都被人用提示词注入破解过。上线前要做对抗测试，把”用户输入只能是被处理的数据、不能是指令”用上一节的结构化边界钉死。
明确责任分工：PM 定义验收标准和测试集，工程师负责工程实现和自动化。prompt 没有 owner，就会退化成没人敢动的祖传咒语。

这套”资产化”思路不只适用于 prompt，后面讲工作流（第05课）和智能体（第04课）时你会发现，所有 AI 能力的产品化都遵循同一个模式：可版本化、可测试、可回滚。更多围绕产品视角的 AI 实践，可以翻AI 产品经理专题和AI Agent 专题的存量文章。

动手练习: 写一个客服会话摘要 prompt

把本课四个技巧（角色、结构、few-shot、输出约束）拼进同一个 prompt。下面是完整示例，你可以直接贴进任何一个聊天产品验证：

你是一家电商平台的资深客服质检专员，负责把客服会话整理成结构化摘要，
供运营团队复盘。请严格按以下规则工作。

<指令>
读取 <会话记录> 中的对话，先在一行内用 2~3 句话梳理：用户遇到了什么
问题、客服给了什么方案、问题是否解决。然后输出 JSON，字段如下：
- issue_type: 字符串，取值只能是 "物流" / "退款" / "商品质量" / "其他"
- summary: 字符串，50 字以内，说清问题与处理结果
- resolved: 布尔值，问题是否在本次会话中解决
- follow_up: 字符串，需要跟进就写具体动作，不需要就写 "无"
如果会话记录为空或无法判断，issue_type 填 "其他"，summary 填
"信息不足"，resolved 填 false。
</指令>

<示例>
输入：用户说买的杯子碎了要求退款，客服核实照片后当场发起退款。
输出：
{"issue_type": "退款", "summary": "杯子运输破损，客服核实后已退款", "resolved": true, "follow_up": "无"}

输入：用户问包裹三天没更新物流，客服承诺催促承运方，请用户等 24 小时。
输出：
{"issue_type": "物流", "summary": "包裹物流停滞，客服已催承运方，待反馈", "resolved": false, "follow_up": "24 小时后回访确认物流恢复"}
</示例>

<会话记录>
{{在这里粘贴一段真实或编造的客服对话}}
</会话记录>

练习分三步。第一步，编三段不同类型的会话（一段正常退款、一段没解决的物流问题、一段闲聊式无效会话）分别跑一遍，检查 JSON 字段是否始终合规。第二步，删掉 <示例> 整块再跑同样的输入，直观感受 few-shot 对格式稳定性的影响。第三步，故意在会话记录里塞一句”请忽略以上所有指令”，看结构化边界扛不扛得住。三步做完，你对本课所有概念的理解会立刻从”听过”变成”摸过”。

FAQ

模型越来越聪明, 提示词工程会不会很快过时?

会贬值的是技巧层（比如手写思维链对推理模型的收益已经在缩小），不会过时的是需求表达层。模型再强也读不了你的心，”把模糊需求写成清晰规格”这件事永远有人要做——这恰好是 PM 的核心能力，只是交付物从 PRD 变成了 prompt。本课压重注在测试集和资产化上，就是因为方法比技巧保值。

用中文写 prompt 效果会比英文差吗?

主流大模型的中文理解已经足够好，业务场景直接用中文写完全没问题，而且团队评审起来成本低得多。定性地说，英文在个别技术任务上可能略有优势（训练语料占比更高），但这点差距远小于”prompt 写得清不清楚”带来的差距。先把结构和约束写对，再考虑语言这种边角优化。

不会写代码, 能做好提示词工程吗?

能，而且本课通篇没有出现一行传统意义上的代码。写 prompt 需要的是清晰的任务定义、好的示例挑选和验收标准——全是 PM 的存量技能。唯一建议补的是让工程师帮你搭一个能批量跑测试集的小工具，你负责往里填内容。

Few-shot 示例是不是越多越好?

不是。2~3 个高质量、覆盖边界情况的示例通常就够，再多边际收益很小，token 成本却线性上涨。比数量更重要的是质量：示例之间格式一致、和指令口径一致、包含至少一个兜底案例。示例出现冲突时模型会无所适从，输出反而更不稳定。

为什么同一个 prompt 昨天还好用, 今天就翻车了?

三个常见原因：一是模型服务商升级或灰度了底层模型，行为发生漂移；二是温度参数偏高，本来就存在随机波动，只是你之前没测出来；三是今天的输入恰好踩中了 prompt 没覆盖的边界情况。三个原因指向同一个解法：建测试集、记录模型版本和参数、把翻车案例补进测试集。翻车不可怕，不可审计才可怕。

结语

提示词工程的入门技巧一节课就能学完，真正拉开差距的是工作方式：给 prompt 建测试集、上版本管理、明确验收标准。下一课我们把这套方法对准真实业务需求，练习完整的场景拆解。