构建 Prompt 的场景拆解法: 把业务需求翻译成提示词

你大概遇到过这种场面：老板说”给客服系统加个 AI 总结功能”，你打开对话框写下”请总结这段对话”，跑了三次，三次结果长得都不一样——有时五百字，有时两行，有时结尾还带一句”希望这个总结对您有帮助”。问题不在模型，在于你把一句业务需求原封不动丢给了模型，中间少了一道工序：翻译。

这一课教的就是这道工序——构建 Prompt 的场景拆解法。学完你能做到：拿到任何一句模糊的业务需求，按”场景定义→输入输出→约束条件→评估标准”四步拆开，套进五段式模板，产出一份可测试、可复现、可交接的 prompt（提示词，就是你发给模型的那段指令文字）。课里用客服会话摘要、用户评论打标签、周报自动生成三个案例把全过程走一遍，prompt 全文和输入输出都给出来，照着改就能用。

上一课讲了角色设定、结构化提示、Few-shot 这些”手法”，这一课解决的是手法之前的问题：需求进来，从哪下笔。这也是《AI 产品经理课》整个系列里最”像产品经理本职工作”的一课——写 prompt 和写 PRD，用的是同一块脑子。

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

全部 13 篇目录

从需求到 Prompt: 四步翻译流程

把业务需求变成 prompt，本质上和把 PRD 变成代码是同一类工作：原始需求是自然语言，充满默认假设和省略；而执行方（不管是工程师还是模型）需要的是明确的输入、明确的输出、明确的边界。翻译，就是把省略的东西一条条补出来。

区别在于，工程师看不懂 PRD 会来问你，模型不会。它拿到多含糊的指令，就给你多含糊的结果，而且每次含糊得还不一样。所以这四步拆解，每一步都是在替模型把”它本来会瞎猜的地方”提前钉死。站内有一篇文章讲把”要做什么”和”怎么做”分开，prompt 就能自动优化，底层逻辑相通：需求描述和执行指令是两层东西，混在一起谁都优化不了。

第一步: 场景定义——给谁用、何时触发、输出给谁看

拿到需求先回答三个问题：这个功能给谁用？在什么时机触发？产出的东西给谁看？

以”给客服系统加个 AI 总结功能”为例。三个问题问下来，答案可能是：给质检员用；在会话关闭后自动触发；摘要写进工单系统，质检员每天扫几百条。这一问，需求立刻从”总结对话”变成了”把一段售后对话压缩成质检员三秒能扫完的结构化摘要”——质检员要扫几百条，五百字的总结再优美也是垃圾。

场景定义没做，后面三步全是空转。这一步不需要任何 AI 知识，是纯粹的产品基本功。

第二步: 输入输出——把模糊需求钉成数据

第二步回答：模型拿到的原料长什么样？吐出来的成品长什么样？

输入侧要问清楚：对话记录是带角色标记的（”用户: xxx / 客服: xxx”），还是一坨没分行的纯文本？最长多少轮？会不会有空会话？输出侧要定死：是三行固定格式的文本，还是一个 JSON（一种程序之间交换数据的通用文本格式，长得像 {"key": "value"}）？

一个实用的判断：输出是给人看的，优先可读性；输出是给系统用的，优先可解析性。两头都要的场景，让模型输出 JSON，展示层再渲染成人话。

第三步: 约束条件——把”不要什么”写出来

约束是需求里最常被省略的部分：长度上限、语气、禁用词、敏感内容怎么处理、遇到边界情况（空输入、纯表情、辱骂内容）输出什么。这些东西不写，模型就自由发挥。

写约束有个坑，第 02 课提过一嘴，这里展开说：负面指令效果常常不如正面指令。“不要太长”不如”不超过 30 字”；”不要口语化”不如”用书面语，参考银行客服公告的语气”。模型对”做什么”的执行力远好于”别做什么”，能改写成正面表述的约束尽量改写。

第四步: 评估标准——先想怎么打分

最后一步，也是最容易被跳过的一步：什么样的输出算好？如果你答不上来，说明场景还没想清楚，回到第一步重来。

评估标准不用复杂，先写三五条可判断的句子：”摘要必须覆盖用户核心诉求””状态字段只能是三个枚举值之一””不能出现原文里没有的信息”。这些句子之后会变成你的测试用例。这一步的产出在本课最后一节还会用到——验收先于实现，是整个场景拆解法的灵魂。

五段式模板: 任务、背景、输入、输出、示例

四步拆解产出的是”原材料”，五段式模板负责把它们组装成 prompt。五段依次是：

任务描述：一两句话说清模型的角色和要干的事。对应场景定义。
背景上下文：业务背景、读者是谁、结果用在哪。给模型判断分寸的依据。
输入数据：说明输入的格式和范围，实际数据在运行时填进来。
输出规范：格式、长度、字段、枚举值，越具体越好。对应输入输出加约束条件。
示例：一到三个输入输出对，也就是第 02 课讲的 Few-shot（在提示词里放几个完成好的例子，让模型照样学样）。示例是锁格式最有效的手段，比任何形容词都管用。

骨架长这样：

# 任务
你是<角色>，负责<一句话说清要做的事>。

# 背景
- <业务场景是什么>
- <输出给谁看/给什么系统用>

# 输入
<输入数据的格式说明>

# 输出
<格式、长度、字段的硬性规定>

# 示例
输入: <样例输入>
输出: <样例输出>

顺序不是随便排的：指令在前、数据在后，模型对开头和结尾的内容最敏感；示例放最后，紧挨着真正的输入，格式模仿效果最好。成熟做法可以参考揭秘 Codex 智能体提示词——本质就是把工程约束逐条写死，让模型行为可预期；GitHub 热门项目 Claude Design System Prompt 则把整套设计规范塞进 prompt 当背景上下文。好 prompt 的共性：规范多，形容词少。

五段不是每次都要齐全。任务简单到一句话说得清，背景和示例可以省；但输出规范几乎永远不能省——格式漂移的锅，八成是这段没写。

三个实战案例: 把翻译流程走通

下面三个案例覆盖 AI 产品经理最常碰到的三类文本任务：压缩（摘要）、分类（打标）、重组（周报）。每个案例都按”场景定义→验收标准→prompt 全文”的顺序给出，你可以直接拿去改。

案例一: 客服会话摘要

场景定义：售后客服会话关闭后，自动生成摘要写进工单系统，供质检员快速扫读。质检员只关心三件事：用户要什么、客服做了什么、问题解决没有。

验收标准：输出恰好三行；诉求和处理各不超过 30 字；状态只能是三个枚举值之一；不得出现对话里没有的信息。

# 任务
你是电商客服质检系统的会话摘要模块，负责把一段售后对话压缩成结构化摘要。

# 背景
- 对话来自售后场景，常见主题：退换货、物流、退款、商品质量。
- 摘要给质检员看，他们每天要扫几百条，只关心用户要什么、客服做了什么、问题是否解决。

# 输入
对话记录按行给出，每行格式为「角色: 内容」，角色只有"用户"和"客服"两种。

# 输出
输出恰好三行，每行以固定前缀开头，除这三行外不输出任何内容：
诉求: <用户的核心诉求，不超过30字>
处理: <客服给出的处理动作，不超过30字>
状态: <已解决/未解决/需跟进，三选一>
若对话为空或无实质内容，三行内容均写"无有效会话"。

# 示例
输入:
用户: 我上周买的杯子收到是碎的
客服: 抱歉给您带来不便，方便拍张照片给我吗
用户: 图片已发
客服: 已为您登记补发，48小时内发出
用户: 好的谢谢

输出:
诉求: 收到的杯子破损，要求处理
处理: 登记补发，承诺48小时内发出
状态: 已解决

注意几个细节：空会话的兜底写进了输出规范，这是第三步约束条件的产出；”除这三行外不输出任何内容”专治模型爱加的客套话。同类任务的更多变体，可以参考让 ChatGPT 高效整理长对话里的会话整理技巧。

案例二: 用户评论打标签

场景定义：每周产品评审会前，把本周新增的用户评论批量打上类别和情感标签，统计各类问题占比。输出给统计脚本消费，必须是可解析的 JSON。

验收标准：输出是合法 JSON 且只有 JSON；类别只能从固定清单里选；一条评论可以有多个类别；情感是三选一。

# 任务
你是用户评论分析系统的打标模块，给每条评论打上类别标签和情感标签。

# 背景
标签用于每周产品评审会的问题占比统计，由脚本自动解析入库，格式错误会导致统计中断。

# 类别清单
物流、质量、价格、客服态度、功能、其他

# 输入
一条用户评论的纯文本。

# 输出
只输出一个 JSON 对象，不加代码块标记，不加任何解释文字。字段：
{"categories": [从类别清单中选1到3个], "sentiment": "正面/负面/中性三选一", "summary": "不超过20字的评论要点"}
类别必须来自类别清单，清单外的一律归入"其他"。

# 示例
输入: 快递挺快的，但是杯盖拧不紧，倒过来就漏水
输出: {"categories": ["物流", "质量"], "sentiment": "负面", "summary": "物流快但杯盖漏水"}

输入: 还没用，先好评
输出: {"categories": ["其他"], "sentiment": "中性", "summary": "未使用，默认好评"}

这个案例的关键是”类别清单”独立成段。分类任务里，枚举值就是产品口径，混在正文里模型容易漏看，单独列出来命中率明显更高。第二个示例专门放了一条”没有信息量的评论”，教模型处理边界情况——示例不只锁格式，也锁行为。

案例三: 周报自动生成

场景定义：团队成员每天写流水账日报，周五自动汇总成周报发给部门负责人。负责人不了解执行细节，只关心产出、风险、下周计划。

验收标准：只使用日报里出现的信息，禁止编造；同一事项多天出现要合并；总长不超过 300 字；语气平实。

# 任务
把团队成员一周的流水账日报，整理成一份给部门负责人看的周报。

# 背景
- 负责人不了解执行细节，只关心三件事：本周产出了什么、有什么风险、下周做什么。
- 周报直接贴进邮件正文，语气平实，禁止出现"赋能""抓手""闭环"这类词。

# 输入
5 条日报，按天给出，每条是自由格式的中文文本。

# 输出
按以下 Markdown 结构输出，总长不超过300字：
## 本周进展
- <按事项合并，不按天罗列>
## 风险与阻塞
- <没有则写"无">
## 下周计划
- <只从日报中提取，日报没提就写"待定">

# 约束
- 只使用日报中出现的信息，禁止推测、禁止补充数据。
- 同一事项在多天出现时合并为一条，体现进度变化（如"周二启动、周四完成联调"）。

周报场景最大的风险是编造——模型看到”风险与阻塞”这个标题，哪怕日报里没提风险，也倾向于”补”一条出来撑场面。所以约束段用了两个”禁止”加一个兜底值（”待定”），把编造的路堵死。类似思路可以看看那份拒绝简化的硬核编码助手提示词——约束严苛到近乎偏执，换来的是稳定。

Prompt 模板化: 变量占位与动态拼装

上面三个案例写的都是”一份完整的 prompt”，但在真实产品里，prompt 不是一次性写完的文章，而是一个带空槽的模板，运行时才把数据填进去。

变量占位是第一步。把 prompt 里会变的部分挖成槽位，比如用 {{conversation}} 表示对话记录、{{category_list}} 表示类别清单。这样做的直接好处：prompt 本体（指令、规范、示例）和数据（每次不同的输入）分离了。指令层可以版本化管理、review、回归测试；数据层随请求变化。不少产品把这层能力直接开放给用户，比如开源翻译工具 WinTranslator 支持自定义 Prompt，用户填模板，工具负责把待翻译文本拼进去——这就是模板化最直白的产品形态。

动态拼装上下文是进阶动作。背景上下文那一段不必是死的：客服摘要场景里，可以按会话所属的业务线，动态拼入该业务线的术语表；评论打标场景里，可以只拼入当前商品类目相关的类别清单。原则是只拼当前任务用得上的上下文，而不是把所有可能有用的东西一股脑塞进去——塞多了不但费 token（模型计费和限长的基本单位），还会稀释关键指令的权重，这个坑下一节展开。工具层面，Prompt Picker 这类插件做的就是从网页里精准提取需要的元素再拼进指令，而不是整页塞给模型。

模板化还有一个容易被忽略的收益：它逼你想清楚哪些东西属于”系统能力”，哪些属于”单次输入”。站内本体层比堆 Prompt 更能让 Agent 变薄这篇说得透——当 prompt 越写越长、什么都往里塞时，往往说明有些东西该沉淀到 prompt 之外的系统层去。

失败案例复盘: 三类高频翻车与修法

prompt 上线后翻车，九成能归进下面三类。每类给一个真实感十足的现场和对应修法。

指令冲突: prompt 里的自相矛盾

现场：客服摘要的 prompt 里，背景段写着”摘要要让质检员快速扫读，越简洁越好”，输出段又要求”覆盖用户诉求、客服动作、情绪变化、升级风险四个维度”。模型每次在”简洁”和”四维度”之间随机站队，输出忽长忽短。

修法：约束只留一个信源。所有对输出的硬性要求集中到输出规范段，背景段只描述场景、不下指令。写完通读一遍，检查有没有两段话在管同一件事——prompt 迭代几轮后特别容易新旧指令打架，因为改的人往往只加不删。

上下文淹没: 塞得越多, 听得越少

现场：为了让评论打标更准，有人把 50 条打标规则、整份客服手册全贴进了 prompt。结果准确率不升反降，模型开始忽略中间部分的规则，甚至把手册里的示例当成了待打标的评论。

修法：回到动态拼装的原则，只放当前任务用得上的内容；关键指令放开头和结尾，模型对这两个位置最敏感；超长的参考资料换成”按需检索再拼入”（第 07 课讲 RAG 时会展开这个思路）。还要警惕一个安全变体：拼入 prompt 的内容来自外部（用户输入、网页、第三方数据）时，可能混入伪装成指令的文本，即 prompt 注入。Claude 客户端”幽灵推广”事件就是典型讨论——外部内容必须当不可信数据处理，用分隔符明确圈出来。

格式漂移: 一百次里总有三次不听话

现场：评论打标跑了一周都好好的，某天统计脚本报错——模型在 JSON 外面套了一层 Markdown 代码块标记，还加了句”以下是分析结果”。抽查发现约 3% 的请求会这样。

修法：三层防御。第一层，输出规范写死”只输出 JSON 对象，不加代码块标记，不加解释文字”（正面+负面双保险）；第二层，示例里的输出严格保持目标格式，一个字符都不多；第三层，代码侧永远做校验和兜底——解析失败就重试或降级，别指望模型 100% 听话。概率生成的系统没有绝对稳定，prompt 负责把失败率压到 1% 以下，工程负责兜住那 1%。排查这类问题时，把每次请求的 prompt 和响应记录下来非常关键，可以参考Prompt、Tool Call 与 Token 的全链路追踪的做法——没有日志，你连”3% 的失败长什么样”都不知道。

验收先于实现: 先写”什么样算好”

最后回到四步流程的第四步。它值得单独一节，因为这是产品经理在 prompt 工作里最大的价值点，也是最反直觉的工作顺序：先写验收，再写 prompt。

具体做法很朴素。为每个场景准备一个小评估集（业内叫 evals，就是一组固定的测试用例）：挑 10 到 20 条真实输入——普通样本、边界样本（空输入、超长输入、纯表情）、易错样本（讽刺语气的好评、一条评论骂三个类别）——给每条写上期望输出或判断规则。然后每次改 prompt，就把评估集整个跑一遍，看通过率。

没有评估集时，改 prompt 靠手感：”看起来好像好了”——其实只是你试的那两条恰好通过。有评估集后，每次修改都有分数，你能明确回答”这版比上一版好在哪、有没有把原来对的改错了”。这和工程团队跑回归测试是同一件事，在 Claude Code 这类 AI 编程工具的重度用户社区里，”给 prompt 建测试集”早已是共识做法。

评估集还有一个隐藏价值：它是你和技术团队对话的通用语言。方案评审时，”我觉得效果不好”没有说服力，”评估集 20 条里挂了 6 条，全是讽刺语气的样本”立刻能推进讨论。等你后面接触智能体（第 04 课会讲怎么用一段提示词构建最简 Agent），任务链路更长、失败模式更多，没有评估集基本等于裸奔。

动手练习

把这一课的方法用一遍，比再读三遍都有用。练习题：会议纪要生成。

假设需求是”帮我们把会议录音转的文字稿变成纪要”。请你：

做场景定义：给谁看？（建议设定：给没参会的同事看）什么时机生成？读者最关心什么？
定输入输出：输入是带发言人姓名的转写文本；输出你来定——建议包含”结论、待办（谁、做什么、截止时间）、遗留问题”三块。
写三条约束：至少覆盖”禁止编造”和一个边界情况（比如文字稿里有大量闲聊）。
写三条验收标准，再按五段式模板写出 prompt 全文。
找两段真实的会议记录跑一跑，对照验收标准打分，改到全过为止。

做完你会发现，四步里最花时间的是第一步和第四步——恰好是和模型无关、和产品最相关的两步。这就是本课想传递的核心判断：prompt 写得好不好，三分靠技巧，七分靠需求想得清不清楚。

FAQ

五段式模板每次都要写满五段吗?

不用。简单任务（比如”把这段话翻译成英文”）一句话就够。判断标准是任务的”自由度”：模型可能理解歧义的地方越多，需要的段落越多。但只要输出会被下游系统消费，输出规范和示例这两段就不能省——它们是格式稳定性的主要来源。

Prompt 是不是写得越长越好?

不是。长度本身没有价值，覆盖到位才有价值。一份好 prompt 的每句话都应该在钉死某个模型会瞎猜的点；钉完就停。上下文淹没那一节讲过，无关内容塞多了反而稀释关键指令。

不会写代码, 能做 prompt 模板化吗?

能。变量占位本质是”填空题设计”，不需要编程。你负责设计模板、定槽位、写验收标准，工程同学负责运行时把数据填进槽位。事实上模板设计的关键决策——哪些内容固定、哪些内容动态、口径怎么定——全是产品决策，代码只是执行层。

同一份 prompt, 换个模型效果差很多, 正常吗?

正常。不同模型的训练数据和对齐方式不同，对指令的敏感点也不同：有的对示例学得快，有的对负面指令执行差。所以 prompt 迁移到新模型时，必须把评估集重新跑一遍，别默认结论可以平移。选型阶段可以参考大模型对比评测类的横评思路：用你自己的评估集测，比看任何榜单都准。

评估集要做多大才够用?

起步 10 到 20 条就够，重点不是数量是覆盖：普通样本、边界样本、易错样本各占一部分。之后每次线上翻车，就把翻车的输入补进评估集，让它随产品一起长大。

结语

场景拆解法的核心只有一句话：模型会瞎猜的地方，你提前钉死；钉不钉得准，用评估集说话。下一课我们把这套 prompt 功夫升级——用一段提示词，构建你的第一个 AI 智能体。