Prompt 基础结构

3.1 Prompt 为什么重要#

大模型是通用能力。它可以回答问题、写文案、总结文档、抽取字段、生成代码、做分类、改写语气。但通用能力要变成业务能力，必须有明确任务边界。

Prompt 的作用就是把业务任务翻译成模型可执行的指令。它决定模型如何理解输入、如何组织输出、如何处理不确定、如何遵守业务约束。

同一个输入，不同 Prompt 会得到完全不同的结果。

例如输入：

1
用户说：我买的耳机还没发货，今天不发我就退款。

如果 Prompt 是“帮我回复用户”，模型可能输出安抚话术。

如果 Prompt 是“识别客服意图并输出 JSON”，模型可能输出：

1
{
2
  "intent": ["催发货", "退款意向"],
3
  "risk_level": "medium",
4
  "need_order_query": true,
5
  "suggested_action": "查询订单和物流后回复"
6
}

如果 Prompt 是“生成客服回复，但不得承诺发货时间或退款”，模型会更稳地输出受控话术。

所以 Prompt 不是文字游戏，而是产品行为控制。

3.2 临时 Prompt 与产品化 Prompt 的区别#

临时 Prompt 面向个人效率，产品化 Prompt 面向稳定交付。

产品经理写 Prompt 时，不要只追求一次输出漂亮，而要追求稳定性。稳定性来自结构，不来自“多写几句拜托模型认真点”。

3.3 Prompt 的 8 个基础模块#

一个基础 Prompt 可以拆成 8 个模块：

1
角色
2
背景
3
任务
4
输入
5
输出格式
6
约束
7
示例
8
异常处理

不是每个 Prompt 都必须写满 8 个模块，但产品化场景至少要覆盖任务、输入、输出格式、约束和异常处理。

3.4 角色：让模型进入正确工作视角#

角色告诉模型应该用什么专业视角处理任务。

差的写法：

1
帮我写一段话。

更好的写法：

1
你是一名电商平台客服质检专家，熟悉售后政策、用户情绪处理和高风险承诺控制。

角色不是为了让模型“扮演”，而是为了激活任务相关的表达方式和判断标准。

常见角色：

• 客服回复专家。

• 商品运营文案专家。

• 合同摘要助手。

• 用户访谈分析师。

• 数据分析师。

• PRD 审查助手。

• 企业知识库问答助手。

角色要具体，但不要虚高。不要写“你是世界顶级专家”这类没有业务约束的描述。更好的角色定义应包含领域、任务和标准。

3.5 背景：说明业务上下文#

背景告诉模型这个任务发生在什么业务环境里。

例如客服回复：

1
背景：你正在为一个电商平台生成客服回复。用户咨询订单物流、退款、优惠券和售后问题。模型不得直接承诺退款、赔付、发货时间或优惠券补偿。

背景的作用是限制模型的默认假设。没有背景时，模型会按通用语境回答；有背景时，模型更容易贴合业务。

背景要包含：

• 业务类型。

• 用户对象。

• 使用场景。

• 风险边界。

• 输出对象。

不要把大量无关背景塞进 Prompt。背景越长，成本越高，模型也可能抓不到重点。稳定做法是：固定背景写入系统 Prompt，变化信息放入结构化输入。

3.6 任务：定义模型要完成什么#

任务要具体、可执行、可验收。

差的任务：

1
帮我优化一下。

好的任务：

1
请根据用户问题和订单状态，生成一段客服回复。回复需要先表达理解，再说明当前可确认的信息，最后引导用户下一步操作。不得承诺未由系统确认的发货时间、退款或赔付。

任务描述要回答：

• 模型要处理什么输入？

• 产出什么结果？

• 结果给谁使用？

• 完成后要支持什么业务动作？

如果任务复杂，建议拆成步骤：

1
请依次完成：
2
1. 判断用户意图。
3
2. 判断风险等级。
4
3. 判断是否需要查询业务系统。
5
4. 生成客服回复。
6
5. 标记是否需要人工接管。

分步骤不是为了让模型写推理过程，而是为了控制输出结构。

3.7 输入：让模型拿到必要信息#

输入是 Prompt 最容易被低估的部分。很多输出不稳定，不是 Prompt 写得不够华丽，而是输入字段不清楚。

例如客服回复至少需要：

• 用户原话。

• 订单状态。

• 物流状态。

• 商品类目。

• 售后政策片段。

• 风险标签。

如果只给用户原话，模型只能猜。

产品化 Prompt 应尽量使用结构化输入：

1
{
2
  "user_message": "我买的耳机还没发货，今天不发我就退款",
3
  "order_status": "已付款，未发货",
4
  "logistics_status": "暂无物流单号",
5
  "policy_snippet": "未发货订单支持用户申请退款，具体到账时间以支付渠道为准",
6
  "risk_tags": ["退款意向"]
7
}

结构化输入有几个好处：

• 减少歧义。

• 便于系统拼接。

• 便于测试。

• 便于日志复盘。

• 便于后续 API 化。

3.8 输出格式：让结果可使用#

如果输出只给人看，可以是自然语言。如果输出要进入系统，就必须结构化。

例如：

1
{
2
  "intent": "退款咨询",
3
  "risk_level": "medium",
4
  "reply": "理解您的着急。目前订单仍处于未发货状态，您可以在订单页申请退款，到账时间以支付渠道为准。",
5
  "need_human": false,
6
  "forbidden_commitment_detected": false
7
}

输出格式决定结果能否进入产品流程。

常见输出形态：

• 文案：适合商品标题、客服话术、摘要。

• 表格：适合需求整理、竞品对比、风险清单。

• JSON：适合系统处理、自动化、API。

• Markdown：适合报告、PRD、会议纪要。

• 标签：适合分类、路由、质检。

产品经理要提前定义输出字段，而不是等模型自由发挥。

3.9 约束：写清楚不能做什么#

约束是 Prompt 中最重要的风控部分。

常见约束：

• 不得编造未提供的信息。

• 不得承诺退款、赔付、发货时间。

• 不得输出法律、医疗、金融的确定性建议。

• 必须基于引用资料回答。

• 不确定时必须标记为资料不足。

• 输出必须使用指定 JSON 字段。

• 每条建议必须对应依据。

• 不得使用夸大宣传词。

但约束不能替代系统能力。比如“不得承诺退款”有用，但最稳的做法是同时设置后处理校验和高风险词拦截。

Prompt 约束适合控制表达和判断，规则系统适合控制确定性业务结果。

3.10 示例：让模型理解标准#

示例能显著提升输出稳定性，尤其适合格式要求高、风格要求明确、分类标准复杂的任务。

例如客服回复可以给一个示例：

1
输入：
2
用户问题：我订单还没发，能退款吗？
3
订单状态：已付款，未发货
4
政策片段：未发货订单支持申请退款
5

6
输出：
7
{
8
  "intent": "退款咨询",
9
  "risk_level": "low",
10
  "reply": "您的订单目前仍未发货，可以在订单页提交退款申请。退款到账时间以支付渠道处理为准。",
11
  "need_human": false
12
}

示例要少而准。太多示例会增加 Token 成本，也可能让模型过拟合某种表达。

3.11 异常处理：资料不足时怎么做#

一个产品化 Prompt 必须定义异常处理。否则模型会在资料不足时继续编。

异常包括：

• 输入字段缺失。

• 资料不足。

• 用户问题超出范围。

• 用户要求高风险动作。

• 用户诱导模型编造。

• 输出无法确定。

• 检索资料互相冲突。

正确处理方式可以是：

1
如果资料不足，请输出：
2
{
3
  "status": "need_more_info",
4
  "missing_fields": [],
5
  "reply": "目前还需要补充信息，无法直接判断。"
6
}

这会把“不确定”变成可处理状态，而不是让模型硬答。

3.12 Prompt 版本管理#

Prompt 一旦进入产品，就应该版本化管理。

至少记录：

• Prompt 名称。

• 版本号。

• 适用场景。

• 输入字段。

• 输出字段。

• 变更原因。

• 测试集结果。

• 上线时间。

不要在生产环境里随手改 Prompt。Prompt 改动可能影响准确率、成本、输出格式和风险控制。后续 Day 10 会讲 Prompt 评估，今天先记住：Prompt 是产品配置，不是聊天草稿。

业务背景#

一个电商平台希望用 AI 辅助客服生成回复。客服场景高频、成本明显，但风险也高，因为模型可能错误承诺退款、赔付或发货时间。

目标不是让 AI 替代客服，而是让 AI 根据用户问题、订单状态和政策片段生成可审核回复。

相关角色#

• 用户：提出物流、退款、售后问题。

• 一线客服：使用 AI 草稿，提高回复效率。

• 客服主管：维护话术和质检标准。

• 运营：维护活动规则和售后政策。

• 产品经理：定义输入字段、输出格式、风险边界。

• 研发：接入订单、物流、知识库和模型 API。

原始流程#

1
用户咨询
2
-> 客服查看订单
3
-> 搜索政策
4
-> 手写回复
5
-> 高风险问题升级

痛点：

• 重复问题多。

• 新客服回复质量不稳定。

• 高峰期响应慢。

• 政策解释容易漏条件。

Prompt 设计#

1
角色：
2
你是电商平台客服回复助手，目标是帮助一线客服生成合规、清晰、可审核的回复草稿。
3

4
背景：
5
平台涉及订单物流、退款、优惠券、发票和售后问题。你只能基于输入中的订单状态和政策片段生成回复。
6

7
任务：
8
请根据用户问题、订单状态、物流状态和政策片段，生成客服回复草稿，并判断是否需要人工接管。
9

10
输入：
11
用户问题：{{user_message}}
12
订单状态：{{order_status}}
13
物流状态：{{logistics_status}}
14
政策片段：{{policy_snippet}}
15
风险标签：{{risk_tags}}
16

17
输出格式：
18
{
19
  "intent": "",
20
  "risk_level": "low|medium|high",
21
  "reply": "",
22
  "need_human": true|false,
23
  "reason": ""
24
}
25

26
约束：
27
1. 不得承诺未由系统确认的发货时间、退款、赔付或优惠券补偿。
28
2. 如果政策片段不足以回答，请标记 need_human=true。
29
3. 回复要简洁、礼貌、可直接发给用户。
30
4. 不得编造订单状态或政策。

数据与系统依赖#

• 用户消息。

• 订单系统。

• 物流系统。

• 售后政策知识库。

• 风险标签规则。

• 人工客服工作台。

关键指标#

• 回复草稿采用率。

• 人工修改率。

• 错误承诺率。

• 高风险接管率。

• 首次响应时间。

• 用户满意度。

• 单会话成本。

主要风险#

• 输入政策片段不完整。

• 模型为了安抚用户做出承诺。

• 输出 JSON 格式不稳定。

• 高风险标签漏识别。

• 客服直接发送未经检查的草稿。

复盘结论#

客服 Prompt 的重点不是语气优美，而是边界清晰。它必须明确禁止承诺、资料不足转人工、输出结构可解析，并结合业务系统，而不是只靠模型回答。

业务背景#

同样是“生成文本”，商品文案和合同摘要的 Prompt 设计完全不同。

商品文案偏创意和转化，可以允许多个版本，但要控制夸大宣传和描述不符。合同摘要偏准确和忠实，不能自由发挥，必须保留风险点和原文依据。

商品文案 Prompt#

1
角色：
2
你是电商商品运营文案助手，擅长根据商品结构化资料生成平台合规的标题和卖点。
3

4
任务：
5
根据商品资料生成 3 个商品标题和 5 条核心卖点。
6

7
输入：
8
商品类目：{{category}}
9
品牌：{{brand}}
10
材质：{{material}}
11
规格：{{specs}}
12
目标人群：{{target_users}}
13
核心优势：{{selling_points}}
14
平台禁用词：{{forbidden_words}}
15

16
输出格式：
17
1. 标题候选：
18
- 标题 1：
19
- 标题 2：
20
- 标题 3：
21
2. 核心卖点：
22
- 卖点 1：
23
- 卖点 2：
24
- 卖点 3：
25
- 卖点 4：
26
- 卖点 5：
27
3. 风险提示：
28

29
约束：
30
不得使用平台禁用词，不得编造材质、功效、品牌授权和认证信息。

合同摘要 Prompt#

1
角色：
2
你是合同摘要助手，目标是帮助业务和法务快速理解合同要点，但不替代法律审核。
3

4
任务：
5
请基于合同原文，提取合同主体、金额、期限、付款、交付、违约责任、自动续约、排他、数据和保密条款，并标记需法务关注的风险。
6

7
输入：
8
合同原文：{{contract_text}}
9

10
输出格式：
11
| 模块 | 摘要 | 原文依据 | 风险等级 |
12
|---|---|---|---|
13

14
约束：
15
1. 必须基于原文，不得补充合同未出现的内容。
16
2. 找不到的信息填写“原文未明确”。
17
3. 不输出法律结论，只输出风险提示。
18
4. 每个风险点必须附原文依据。

对比分析#

复盘结论#

Prompt 不存在通用最优。不同业务目标决定不同结构。商品文案要兼顾创意和合规，合同摘要要优先忠实和可追溯。产品经理要先定义任务类型，再写 Prompt。

任务：为同一任务写 3 个 Prompt，比较输出稳定性#

选择一个你熟悉的任务，例如：

• 客服回复。

• 商品标题生成。

• 合同摘要。

• 用户访谈总结。

• 会议纪要。

• 需求提炼。

为同一个任务写 3 个版本：

1. 简单版 Prompt：一句话描述任务。

2. 结构化版 Prompt：包含角色、任务、输入、输出格式。

3. 产品化版 Prompt：增加约束、异常处理和验收标准。

然后用同一条输入测试 3 次，比较：

• 输出是否稳定。

• 是否符合格式。

• 是否有编造。

• 是否能处理资料不足。

• 是否能直接进入业务流程。

验收标准#

合格：

1. 至少写出 3 个 Prompt 版本。

2. 使用同一条输入测试。

3. 记录输出差异。

4. 总结哪个版本更适合产品化。

优秀：

1. 能定义结构化输出字段。

2. 能写出禁止项和异常处理。

3. 能提出后续评估指标，例如格式合规率、采用率、错误率、人工修改率。

理解题#

1. Prompt 为什么不只是自然语言提问？ 参考答案：产品化 Prompt 要定义角色、背景、任务、输入、输出格式、约束和异常处理，本质上是在定义 AI 功能接口，而不是临时聊天。

2. Prompt 中为什么要写输出格式？ 参考答案：输出格式决定结果能否被人稳定使用或被系统解析。没有格式约束，模型可能每次输出不同结构，难以进入产品流程。

3. 为什么结构化输入比随手粘贴更适合产品化？ 参考答案：结构化输入字段清晰、歧义少、便于系统拼接、测试、日志复盘和 API 化。

4. Prompt 约束能否替代规则系统？ 参考答案：不能。Prompt 可以约束表达和生成，但退款、赔付、库存、价格、审批等确定性判断应由规则系统或业务系统处理。

5. 为什么 Prompt 要版本管理？ 参考答案：Prompt 改动会影响输出质量、格式、成本和风险。版本管理便于测试、回滚、复盘和持续迭代。

应用题#

6. 客服回复 Prompt 最重要的约束是什么？ 参考答案：不得编造订单状态、不得承诺未确认的发货时间、退款、赔付或优惠券补偿；资料不足或高风险问题必须转人工。

7. 商品文案 Prompt 和合同摘要 Prompt 的关键差异是什么？ 参考答案：商品文案允许适度创意和多版本，但必须避免夸大和描述不符；合同摘要必须忠实原文，缺失信息写原文未明确，并附依据，不得自由发挥。

8.1 Prompt 模板 v1#

1
Prompt 名称：
2
适用场景：
3
版本号：
4

5
角色：
6
你是 ______。
7

8
背景：
9
当前业务场景是 ______，用户是 ______，需要注意 ______。
10

11
任务：
12
请完成 ______。
13

14
输入：
15
{{input_field_1}}
16
{{input_field_2}}
17
{{input_field_3}}
18

19
输出格式：
20
请按以下格式输出：
21
______
22

23
约束：
24
1. ______
25
2. ______
26
3. ______
27

28
异常处理：
29
如果 ______，请输出 ______。
30

31
验收标准：
32
1. ______
33
2. ______
34
3. ______

8.2 三类业务 Prompt 对比表#

8.3 Prompt 评审清单#

1
是否有明确角色：
2
是否说明业务背景：
3
任务是否可执行：
4
输入字段是否清晰：
5
输出格式是否可解析：
6
禁止项是否明确：
7
资料不足时是否会拒答/追问：
8
是否区分模型生成和系统判断：
9
是否有测试样本：
10
是否有版本号：