Prompt工程进阶

3.1 为什么基础 Prompt 还不够#

基础 Prompt 可以解决简单任务，例如生成客服回复、写商品标题、做短摘要。但真实工作中，产品经理需要 AI 处理的任务往往更复杂。

例如用户访谈原始记录可能是这样的：

1
用户 A：我们现在每次做促销活动，都要去三个系统查库存、价格和优惠券规则。
2
有时候运营同学改了活动价，客服不知道，用户来问的时候还按旧价格解释。
3
还有一个问题是活动结束后复盘很慢，因为数据口径不统一，大家都在群里问到底看哪个表。

如果只写：

1
帮我总结一下这段访谈。

模型可能输出一段看似不错的总结：

1
用户主要反馈促销活动管理效率低，系统割裂，信息同步不及时，复盘数据口径不统一。

这对阅读有帮助，但还不能直接进入需求管理。产品经理真正需要的是：

• 用户是谁。

• 场景是什么。

• 痛点是什么。

• 痛点证据是什么。

• 可能的产品需求是什么。

• 影响哪个业务指标。

• 优先级如何判断。

• 是否需要继续调研。

• 哪些是用户原话，哪些是模型推断。

这就是进阶 Prompt 的价值：把隐含的业务分析标准显性化。

3.2 Few-shot：用例子定义标准#

Few-shot 指在 Prompt 中给模型几个输入和输出示例，让模型学习任务标准。

它适合以下场景：

• 输出格式复杂。

• 分类标准容易混淆。

• 业务语言有特定口径。

• 希望模型模仿某种结构或风格。

• 任务不是通用总结，而是特定组织的工作方式。

例如把用户反馈分成“问题、需求、解决方案、情绪、证据”时，模型可能混淆用户原话和产品推断。给一个示例能显著提高稳定性。

示例：

1
输入：
2
用户说：每次导出报表都要等十几分钟，有时候还失败，我只能截图给老板。
3

4
输出：
5
{
6
  "pain_point": "报表导出慢且不稳定",
7
  "user_need": "用户需要快速、稳定地导出经营报表",
8
  "evidence": "每次导出报表都要等十几分钟，有时候还失败",
9
  "workaround": "截图给老板",
10
  "priority_signal": "高频工作受阻，影响管理汇报",
11
  "inference_note": "需要进一步确认导出失败频率和报表大小"
12
}

这个示例告诉模型：

• 痛点要归纳。

• 需求要转成产品语言。

• 证据必须引用原话。

• 绕行方案要单独记录。

• 推断要标注不确定。

Few-shot 不是为了让模型照抄，而是为了定义“什么算合格输出”。

3.3 Few-shot 的风险：示例不是越多越好#

示例有成本，也有副作用。

示例太多会导致：

• 输入 Token 增加，成本上升。

• Prompt 维护困难。

• 模型过度模仿示例，忽略当前输入差异。

• 示例本身质量差，会污染输出。

• 示例覆盖不全时，模型可能误判边界。

产品化时建议采用“三类示例”：

1. 标准样例：展示正常输入如何输出。

2. 边界样例：展示资料不足或模糊时如何处理。

3. 反例样例：展示哪些内容不能输出或必须标记。

例如访谈抽取任务，可以给：

• 一个清晰痛点样例。

• 一个只有情绪没有具体需求的样例。

• 一个用户提出方案但没有明确痛点的样例。

这样模型更容易判断边界，而不是把所有话都硬转成需求。

3.4 分步任务：把复杂分析拆成可控过程#

分步任务不是要求模型展示冗长推理，而是把复杂输出拆成稳定的处理环节。

例如“客户访谈 -> 需求表”可以拆成：

1
1. 识别受访者角色和业务场景。
2
2. 提取用户原话中的事实和证据。
3
3. 归纳痛点。
4
4. 转译为产品需求。
5
5. 判断影响指标。
6
6. 标记优先级线索。
7
7. 标记不确定和需补充调研的问题。
8
8. 输出结构化表格。

这种拆解对产品经理有两个价值：

第一，能减少模型跳步。模型不会直接从一段访谈跳到一堆功能方案，而是先保留证据再推导需求。

第二，便于验收。你可以检查每一步是否合格：证据是否真实、痛点是否准确、需求是否过度推断、优先级是否有依据。

3.5 分步任务不要变成“让模型暴露思维链”#

实际产品中通常不需要模型输出完整推理过程。你需要的是可审计的中间结果，而不是模型内部推理。

更合理的写法是：

1
请按以下步骤处理，但最终只输出表格：
2
1. 先识别用户原话中的事实证据。
3
2. 再基于证据归纳痛点。
4
3. 再把痛点转成产品需求。
5
4. 如果缺少证据，请在“需补充调研”列标记。

这样既控制过程，又避免输出冗长不可用。

3.6 结构化输出：让 AI 结果进入工作流#

结构化输出是 Prompt 产品化的关键。

如果 AI 只输出一段自然语言总结，产品经理还要手动拆成需求池、优先级、标签、责任人。结构化输出可以直接进入表格、看板、数据库或评审材料。

访谈抽取可用字段：

结构化输出的好处：

• 便于比较。

• 便于筛选。

• 便于进入需求池。

• 便于统计高频痛点。

• 便于评审。

• 便于后续 API 化。

3.7 结构化输出的常见问题#

结构化输出也会失败：

• 字段缺失。

• 格式不合法。

• 表格列数不一致。

• JSON 多了注释。

• 同一字段里混入多个概念。

• 模型把未知信息硬填。

• 置信度没有标准。

解决方式：

1. 输出字段要少而必要。

2. 每个字段要有定义。

3. 缺失信息要填固定值，例如“未提及”。

4. 枚举字段要给可选项。

5. 高风险字段要附证据。

6. 输出后做格式校验。

例如：

1
confidence 只能填写 high / medium / low。
2
如果原文没有明确证据，confidence 必须为 low。

这比让模型自由打分更稳定。

3.8 引用约束：结论必须绑定证据#

Day 4 讲过幻觉，Day 5 讲过检索。Prompt 进阶里必须引入引用约束。

对于访谈抽取，引用约束意味着每个痛点和需求都要对应用户原话。不能因为产品经理希望做某个功能，就让模型从用户一句模糊抱怨中推导出完整方案。

例如用户说：

1
每次活动复盘都很麻烦。

模型可以输出：

1
痛点：活动复盘流程效率低。
2
证据：每次活动复盘都很麻烦。
3
需补充调研：具体麻烦在数据收集、口径确认、报告生成还是跨部门协作？

但不能直接输出：

1
需求：建设一套自动化活动复盘 BI 系统，支持多渠道归因和预算优化。

这个需求可能有价值，但超出了证据。正确做法是把它标记为“产品机会假设”，而不是“已验证需求”。

3.9 自检：让模型检查自己的输出#

自检不是让模型保证绝对正确，而是让模型按明确标准检查输出。

常见自检项：

• 是否每条需求都有原话证据。

• 是否把用户方案误当成真实需求。

• 是否存在资料不足却强行判断。

• 是否输出了超出输入的信息。

• 是否格式符合要求。

• 是否标记了需补充调研项。

一个好的自检 Prompt 可以写成：

1
输出前请检查：
2
1. 每一行是否有 original_quote。
3
2. user_need 是否由 pain_point 推导，不得凭空添加。
4
3. confidence 为 high 的行必须有明确原话证据。
5
4. 无明确证据的内容必须放入 product_opportunity 或 follow_up_question，不得放入 confirmed_need。

自检最好和结构化字段结合，而不是让模型写“我已经检查过了”。

3.10 从 Prompt 到产品流程#

访谈抽取 Prompt 不应只是一个办公助手。它可以成为需求管理流程的一部分：

1
访谈记录
2
-> AI 初步抽取痛点和需求
3
-> 产品经理审核和合并
4
-> 标记优先级
5
-> 进入需求池
6
-> 关联业务指标和用户证据
7
-> 评审会讨论
8
-> 转 PRD 或进入待验证

这比“帮我总结访谈”更有产品价值，因为它改变了需求处理流程。

产品经理要关注两个指标：

• AI 是否减少了整理时间。

• AI 是否提高了需求证据质量。

如果 AI 只是生成一堆看似合理但无法追溯的需求，反而会增加评审成本。

3.11 进阶 Prompt 的边界#

Prompt 工程能提升稳定性，但不能解决所有问题。

它不能替代：

• 真实用户调研。

• 数据验证。

• 业务优先级判断。

• 规则系统。

• 权限控制。

• 人工评审。

• 持续评估。

Prompt 的合理定位是：把原始信息结构化，减少重复劳动，提高初步分析质量。最终决策仍然需要产品经理结合业务目标、资源、技术可行性和战略优先级。

业务背景#

一个 B 端 SaaS 团队正在调研“活动运营工作台”需求。产品经理访谈了运营、客服、财务和数据分析师，收集到大量口语化记录。

典型访谈片段：

1
运营：我们做一次大促，要先找商品负责人确认库存，再找价格同学确认活动价，
2
还要找客服同步优惠券规则。每次都在群里对，没人知道最后版本是哪一个。
3
活动结束后复盘也很痛苦，数据同学给一版，运营自己拉一版，口径经常对不上。

产品经理希望 AI 帮助把访谈转成结构化需求表，用于后续需求池管理。

相关角色#

• 产品经理：负责访谈、分析、需求归纳。

• 运营：提供业务流程和痛点。

• 客服：提供用户咨询和异常问题。

• 数据分析师：提供指标和口径问题。

• 研发：评估系统改造成本。

• 管理者：判断优先级和资源投入。

原始流程#

1
访谈录音/笔记
2
-> 产品经理手动整理
3
-> 归纳痛点
4
-> 写需求池
5
-> 合并相似需求
6
-> 评审优先级

痛点：

• 访谈记录长，整理耗时。

• 容易把用户原话和产品推断混在一起。

• 不同访谈对象表达方式不同，难比较。

• 需求缺少证据，评审时争议大。

• 高层只看到结论，看不到证据链。

进阶 Prompt 方案#

1
角色：
2
你是 B 端 SaaS 产品经理助理，擅长从用户访谈中抽取痛点、需求和证据。
3

4
任务：
5
请把访谈记录转成结构化需求表。你必须区分用户原话、痛点归纳、产品需求和产品机会假设。
6

7
处理步骤：
8
1. 识别受访者角色和业务场景。
9
2. 提取能作为证据的用户原话。
10
3. 基于原话归纳痛点。
11
4. 将痛点转译为用户需求。
12
5. 标记可能影响的业务指标。
13
6. 判断置信度。
14
7. 标记需补充调研的问题。
15

16
输入：
17
访谈记录：{{interview_text}}
18

19
输出格式：
20
| 用户角色 | 场景 | 用户原话证据 | 痛点 | 用户需求 | 产品机会假设 | 影响指标 | 置信度 | 需补充调研 |
21

22
约束：
23
1. 每条痛点必须有用户原话证据。
24
2. 不得把没有证据的产品方案写成已确认需求。
25
3. 原文未提到的信息填写“未提及”。
26
4. 置信度只能为 high / medium / low。
27
5. 如果只是用户抱怨但缺少具体场景，置信度必须为 low。

数据与系统依赖#

• 访谈记录。

• 受访者角色标签。

• 业务流程背景。

• 需求池字段。

• 指标字典。

• 后续人工审核机制。

方案架构#

1
访谈材料
2
  -> 清洗
3
      -> 说话人标记
4
      -> 去除无关寒暄
5
  -> Prompt 抽取
6
      -> 场景
7
      -> 证据
8
      -> 痛点
9
      -> 需求
10
      -> 指标
11
      -> 置信度
12
  -> 产品经理审核
13
  -> 合并相似需求
14
  -> 进入需求池
15
  -> 评审与验证

关键指标#

• 访谈整理耗时。

• 抽取字段完整率。

• 用户原话引用率。

• 产品经理修改率。

• 需求重复率下降。

• 评审中证据不足问题占比。

• 后续需求验证通过率。

主要风险#

• 模型过度推断，把想法包装成需求。

• 把用户方案当成真实痛点。

• 缺少业务背景时误判场景。

• 输出字段不稳定，难进入需求池。

• 置信度标准不一致。

• 产品经理未经审核直接采纳。

复盘结论#

访谈抽取 Prompt 的价值不在于“总结得像不像”，而在于能否保留证据链、区分事实和推断，并把结果稳定进入需求管理流程。

业务背景#

同样是处理文本，客服对话质检和需求抽取的 Prompt 目标不同。

客服质检关注：

• 是否准确识别用户意图。

• 是否有违规承诺。

• 是否按流程转人工。

• 是否安抚用户情绪。

• 是否解决问题。

需求抽取关注：

• 用户真实场景。

• 痛点证据。

• 需求归纳。

• 产品机会。

• 优先级线索。

如果把同一个 Prompt 用在两个任务上，输出会不稳定。

客服质检 Prompt#

1
角色：
2
你是电商客服质检专家。
3

4
任务：
5
请检查客服对话是否存在流程违规、高风险承诺和服务体验问题。
6

7
输出字段：
8
用户意图、客服处理动作、是否违规、违规类型、证据、风险等级、改进建议。
9

10
约束：
11
每个违规判断必须引用客服原话。不能根据猜测判定违规。

需求抽取 Prompt#

1
角色：
2
你是产品需求分析助手。
3

4
任务：
5
请从用户反馈中抽取场景、痛点、需求、证据和需补充调研问题。
6

7
输出字段：
8
用户角色、场景、原话证据、痛点、需求、指标影响、置信度、后续问题。
9

10
约束：
11
不要把客服处理问题误判为产品需求；只有可复用、可产品化的问题才进入需求列。

关键差异#

复盘结论#

Prompt 必须服务具体业务目标。同一段文本可以被用于质检，也可以用于需求分析，但字段、标准、风险和后续流程完全不同。产品经理要先定义任务意图，再设计 Prompt。

任务：设计一个“客户访谈 -> 需求表”的 Prompt#

请选取一段真实或模拟访谈记录，设计一个进阶 Prompt，把它转成需求表。

Prompt 必须包含：

1. 角色。

2. 任务步骤。

3. 输入字段。

4. 输出表格字段。

5. 引用约束。

6. 置信度规则。

7. 异常处理。

8. 自检要求。

建议输出字段：

验收标准#

合格：

1. Prompt 能输出结构化表格。

2. 每条需求必须有原话证据。

3. 能区分已确认需求和产品机会假设。

4. 对资料不足的内容能标记需补充调研。

优秀：

1. Prompt 包含 Few-shot 示例。

2. 置信度规则明确。

3. 输出能直接进入需求池。

4. 能设计至少 5 条测试输入验证稳定性。

理解题#

1. Few-shot 解决什么问题？ 参考答案：Few-shot 通过给模型高质量输入输出示例，帮助模型理解任务标准、输出格式和边界，适合分类标准复杂或输出结构特殊的场景。

2. 为什么示例不是越多越好？ 参考答案：示例会增加 Token 成本，增加维护成本，也可能让模型过度模仿示例而忽略当前输入。示例应该少而准，覆盖标准样例、边界样例和反例。

3. 分步任务的价值是什么？ 参考答案：分步任务能把复杂任务拆成可控处理环节，减少模型跳步，便于验收中间结果，如先提证据，再归纳痛点，再转需求。

4. 结构化输出为什么重要？ 参考答案：结构化输出能让 AI 结果进入表格、系统、需求池或 API，便于筛选、统计、评审和复用。

5. 引用约束如何降低幻觉？ 参考答案：引用约束要求结论绑定原文或资料证据，避免模型凭空生成结论。没有证据的内容应标为假设或需补充调研。

应用题#

6. 用户说“复盘很麻烦”，模型能否直接输出“建设自动化 BI 系统”的需求？ 参考答案：不能直接作为已确认需求。可以把“复盘效率低”作为痛点，把“自动化 BI 系统”标为产品机会假设，并补充调研具体麻烦点、数据源、口径和频率。

7. 如何判断“客户访谈 -> 需求表”Prompt 是否稳定？ 参考答案：用多条访谈样本测试格式合规率、证据引用率、痛点准确率、过度推断率、置信度一致性和产品经理修改率。

8.1 需求抽取 Prompt#

1
Prompt 名称：客户访谈到需求表抽取
2
版本：v1
3

4
角色：
5
你是产品需求分析助手，擅长从客户访谈中抽取场景、痛点、需求和证据。
6

7
任务：
8
请把输入的访谈记录转成结构化需求表。
9

10
处理步骤：
11
1. 识别用户角色和业务场景。
12
2. 提取用户原话证据。
13
3. 基于证据归纳痛点。
14
4. 将痛点转成用户需求。
15
5. 标记产品机会假设。
16
6. 判断影响指标和置信度。
17
7. 标记需补充调研问题。
18

19
输入：
20
{{interview_text}}
21

22
输出格式：
23
| 用户角色 | 场景 | 原话证据 | 痛点 | 用户需求 | 产品机会假设 | 影响指标 | 置信度 | 需补充调研 |
24

25
约束：
26
1. 每条痛点必须有原话证据。
27
2. 不得把无证据推断写成已确认需求。
28
3. 原文未提到的信息填写“未提及”。
29
4. 置信度只能为 high / medium / low。
30
5. 缺少具体场景时，置信度必须为 low。
31

32
自检：
33
输出前检查每一行是否有原话证据、是否存在过度推断、是否有需补充调研项。

8.2 访谈抽取结果表#

8.3 Prompt 进阶评估表#