产品经理写 AI Prompt，要先写任务边界
我在三次翻车后学会的事
2024 年底，我负责一个客服 AI 功能。上线第一天，用户反馈就涌上来了——AI 把退货政策说成了「您可以随时退款」，但实际规则是 7 天内且需未拆封。产品经理同事第一反应是去改 Prompt 的语气，把「可以」换成「需要确认是否符合条件」。改完上线，又出问题了：AI 遇到不符合条件的情况，直接回复「您不符合退款条件」，语气冷硬，引发二次投诉。
问题不在语气，在于任务边界从来没写清楚。
这件事让我意识到一个反复出现的模式：产品经理写 Prompt 时，第一反应是打磨表达——「语气更专业一点」「回复简短一些」——但 AI 功能能否落地，取决于任务边界是否清楚。Prompt 不是文案，它是产品规格的一部分。
后来我看了 Productboard 总结的 PM prompt 六大模板，也翻了 OpenAI 和 DAIR.AI 的 prompt engineering 指南，逐渐整理出一套可复用的工作流。这篇文章就是这套方法的完整梳理。
为什么「先写边界」比「先写句子」更重要
Prompt 的本质是任务规格
Lakera 在 2026 年的 prompt engineering 指南里提到一句话：「大多数 prompt 失败源于模糊性，而非模型局限性。」这对产品经理来说是个重要信号——我们习惯性地以为 AI 不够聪明，但实际上是我们没有说清楚要它做什么。
DAIR.AI 的 Prompt Engineering Guide 把 prompt 拆解成四个核心要素：
| 要素 | 说明 | 产品经理的对应物 |
|---|---|---|
| Instruction（指令） | 模型要执行的具体任务 | 功能目标 |
| Context（上下文） | 帮助模型理解背景的额外信息 | 业务规则、约束条件 |
| Input Data（输入数据） | 需要处理的内容 | 用户输入或系统数据 |
| Output Indicator（输出指示） | 期望的输出格式或类型 | 交付标准 |
这四个要素和 PRD 的结构几乎一一对应。区别在于 PRD 面向工程师，Prompt 面向模型——但两者都需要先定义边界，再填充细节。
Productboard 的「Make Implicit Context Explicit」原则
Productboard 在总结 PM prompt 模板时提出的第一条原则就是「让隐含的上下文显式化」。模型不知道你的产品背景、用户画像和业务约束，除非你明确告诉它。
我见过太多这样的 prompt：
请帮我总结用户反馈。
这句话缺少什么？总结给谁看？总结成什么格式？哪些反馈需要重点标注？「重要」的定义是什么？这些隐含上下文，产品经理脑子里有，但 prompt 里没有。
HelloPM 的 RCFCE 框架
HelloPM 的 prompt engineering 指南提出了「RCFCE 五要素架构」——Role（角色）、Context（上下文）、Format（输出格式）、Constraints（边界限制）、Examples（参考样例）。这个框架比 DAIR.AI 的四要素多了角色和约束，更适合产品场景。
为什么？因为 AI 功能通常面向特定用户群，需要遵循特定业务规则，输出也有特定的格式要求。少了角色和约束，prompt 就容易变成「万能模板」——什么场景都能用，但哪个场景都用不好。
四个前置问题：写 Prompt 之前先回答
在动手写提示词之前，我会先回答四个问题。这四个问题不回答，后面的打磨都是空中楼阁。
1. 用户场景：谁在什么情况下需要这个 AI 输出？
这个问题看起来简单，但很多团队在功能评审时才第一次认真讨论。
| 维度 | 模糊定义 | 清晰定义 |
|---|---|---|
| 用户角色 | 「用户」 | 「新注册 7 天内的电商卖家」 |
| 触发时机 | 「用户提问时」 | 「用户在订单详情页点击「退货」按钮后」 |
| 用户目标 | 「获取帮助」 | 「判断自己的情况是否符合退货条件」 |
| 使用场景 | 「客服场景」 | 「移动端，用户正在查看物流信息，发现包裹损坏」 |
2. 输入来源：哪些信息来自用户，哪些来自系统？
这一步决定了 prompt 的数据结构。
| 输入类型 | 来源 | 示例 |
|---|---|---|
| 用户主动输入 | 前端表单、对话框 | 「我的包裹到了但箱子破了」 |
| 系统上下文 | API 注入 | 订单号、商品类型、物流状态、退货政策版本 |
| 用户画像 | 数据库查询 | 注册时间、历史退货次数、信用等级 |
| 环境信息 | 请求头 | 设备类型、语言偏好、所在地区 |
把输入来源列清楚之后，prompt 里就可以用变量占位符来组织结构，而不是把所有信息揉成一段自然语言。
3. 输出标准：结果给谁看，怎么消费？
这个问题直接影响 prompt 的输出格式设计。
| 消费方式 | 输出要求 | 示例 |
|---|---|---|
| 用户直接阅读 | 自然语言，语气友好，结构清晰 | 「您的包裹符合退货条件，请在 7 天内…」 |
| 前端渲染 | 结构化 JSON，包含状态码和消息 | {"eligible": true, "reason": "damage", "deadline": "2026-07-02"} |
| 下游系统消费 | 严格 schema，字段可枚举 | {"action": "initiate_return", "policy_version": "v3"} |
| 人工审核 | 包含推理过程和置信度 | 「判断：符合条件（置信度 0.92），依据：…」 |
4. 失败处理：缺信息、低置信度或高风险时怎么办？
这一步最容易被跳过，但它往往是用户体验的分水岭。
| 失败类型 | 处理策略 | 示例 |
|---|---|---|
| 信息不足 | 追问用户，列出需要补充的字段 | 「请提供订单号和损坏照片」 |
| 低置信度 | 标记为需人工审核，不直接输出结果 | 「该情况需要客服确认，已为您转接」 |
| 高风险操作 | 二次确认，列出可能的后果 | 「退货后退款将在 3-5 个工作日到账，确认继续？」 |
| 超出能力范围 | 诚实告知限制，给出替代方案 | 「这个问题超出了我的处理范围，建议联系…」 |
Prompt 工作流：从场景到上线的完整链路
把上面四个问题串起来，就是产品经理设计 AI Prompt 的完整工作流：
这条链路的核心思路是：先把边界写清楚，再去打磨表达。如果评审或灰度阶段发现边界有问题，回到对应步骤修正，而不是在表达层面打补丁。
和工程协作的交付物
产品侧不需要写完所有实现细节，但应该提供以下材料：
| 交付物 | 内容 | 用途 |
|---|---|---|
| 场景说明 | 用户角色、触发时机、使用场景 | 工程理解功能背景 |
| 输入 schema | 字段名、类型、来源、是否必填 | 设计 API 和数据管道 |
| 输出 schema | 字段名、类型、枚举值、格式要求 | 设计 schema 和校验逻辑 |
| 理想输出样例 | 3-5 个正常场景的完整输入输出 | 评测基准和 few-shot 示例 |
| 不可接受输出 | 明确列出不能出现的内容或行为 | 安全护栏和评测负例 |
| 边界案例 | 信息不足、模糊输入、极端情况的处理 | 异常处理和兜底策略 |
工程侧基于这些材料设计 schema、评测样例和日志字段。产品侧的输入越结构化，工程实现和后续迭代越稳定。
三个实战案例
案例一：电商退货客服 AI
这是开头的翻车案例。修正后的 prompt 结构如下：
# 角色
你是电商平台「XX商城」的退货客服助手。
# 业务规则
- 退货条件：商品未拆封、7 天内、非特殊品类
- 特殊品类（生鲜、定制品）不支持无理由退货
- 物流损坏一律支持退货，需用户上传照片
# 输入信息
- 用户描述：{user_message}
- 订单信息：{order_json}
- 退货政策版本：{policy_version}
# 输出要求
- 先判断是否符合退货条件，给出结论和依据
- 如果符合，告知退货流程和时限
- 如果不符合，解释原因并提供替代方案（如换货）
- 语气友好但专业，不要生硬拒绝
# 失败处理
- 信息不足：明确告知需要补充什么，不要猜测
- 无法判断：标记为需人工审核，不要硬给结论
- 用户情绪激动：先安抚，再处理问题修正后的 prompt 把业务规则、输入结构、输出标准和失败处理全部显式化。模型不再需要「猜」什么情况下该拒绝，什么情况下该追问。
案例二：用户反馈分析 Prompt
一个 PM 同事需要每周分析上百条用户反馈。最初的 prompt 是这样的：
请帮我分析这些用户反馈，总结一下主要问题和改进建议。输出结果每次都不同——有时按功能分类，有时按情绪分类，有时直接给一段总结。无法稳定消费，也没法做趋势追踪。
改进后的版本：
# 任务
对用户反馈进行分类和摘要分析。
# 分类标准
- 问题类型：bug、功能缺失、体验优化、价格相关、其他
- 严重程度：P0（影响核心流程）、P1（影响体验）、P2（小问题）
- 情绪倾向：正面、中性、负面
# 输入格式
每条反馈包含：content（文本）、source（渠道）、created_at（时间）
# 输出格式
JSON 数组，每个元素包含：
- category：问题类型
- severity：严重程度
- sentiment：情绪倾向
- summary：一句话摘要（不超过 30 字）
- action_suggestion：建议的处理方式
# 约束
- 如果一条反馈包含多个问题，拆分为多条记录
- 如果无法判断严重程度，标记为 P2 并在 summary 中标注「待确认」
- 不要添加反馈中没有的信息改进后的输出可以直接被下游系统消费，做趋势图表、生成周报、自动建工单都可以。
案例三：产品文档多版本生成
一个 SaaS 团队需要把 release notes 同步给三类读者：技术团队、客户成功经理和终端用户。最初的方案是写三版文档，后来尝试用 AI 一稿多输出。
第一次尝试的 prompt：
请把这份 release notes 改写成适合不同读者的版本。结果：输出了一版混合格式的文档，有些段落像技术文档，有些段落像营销文案，边界不清。
改进后拆成三个独立 prompt，每个有明确的角色和格式约束：
# 技术团队版本
角色：你是技术文档工程师
读者：后端开发工程师
格式：Markdown，按模块分类，包含 API 变更、数据库 schema 变更、已知问题
约束：不要省略技术细节，可以包含代码片段# 客户成功经理版本
角色：你是产品运营
读者：客户成功经理，需要向客户解释变更
格式：分「新功能」「改进」「修复」三类，每类用一句话说明影响
约束：不包含技术实现细节，重点说明对客户的影响# 终端用户版本
角色：你是产品文案
读者：非技术用户
格式：简短公告，最多 3 个要点，每个要点一句话
约束：使用日常语言，避免技术术语，语气友好三个 prompt 独立运行，输出格式和深度完全不同，但输入源是同一份 release notes。这就是「任务边界」的威力——边界清晰了，同一个输入可以产出完全不同的输出。
Prompt 设计的常见对比
下面这组对比总结了产品经理写 prompt 时最常见的错误和改进方向：
| 维度 | 常见错误 | 正确做法 |
|---|---|---|
| 起点 | 先写 prompt 句子 | 先回答四个前置问题 |
| 角色定义 | 不写角色或写「你是一个助手」 | 明确角色身份、专业领域和行为边界 |
| 上下文 | 假设模型知道业务背景 | 把业务规则、约束条件显式写入 |
| 输入定义 | 自然语言描述输入 | 用变量占位符结构化输入 |
| 输出标准 | 「请给我一个好的结果」 | 指定格式、字段、长度、枚举值 |
| 失败处理 | 不考虑异常情况 | 显式定义信息不足、低置信度、高风险的处理策略 |
| 评测 | 试几次觉得 OK 就上线 | 准备覆盖正常、边界、异常的评测样例集 |
| 迭代 | 出问题就改句子 | 先判断是边界问题还是表达问题，再决定改哪里 |
再看一组 prompt 代码层面的对比：
反面示例：模糊的 prompt
你是客服助手，请回答用户的问题。语气友好一点。这段 prompt 的问题：没有业务规则，没有输入结构，没有输出标准，没有失败处理。「语气友好一点」是表达层面的要求，但边界层面的缺失让模型无从判断什么该说什么不该说。
正面示例：有边界的 prompt
# 身份
你是「XX」平台的售后客服 AI，专门处理物流问题。
# 能力范围
- 可以：查询物流状态、解释配送延迟、发起补发
- 不可以：处理退款、修改地址、承诺赔偿
# 输入
- 用户问题：{user_message}
- 订单状态：{order_status}
- 物流信息：{tracking_json}
# 输出格式
1. 先判断问题是否在能力范围内
2. 如果在范围内：直接回答，包含具体信息（单号、预计时间等）
3. 如果超出范围：告知用户该问题需要人工处理，并提供转接入口
# 约束
- 不要编造物流信息，只使用提供的 tracking_json 中的数据
- 不要承诺具体赔偿金额
- 如果用户情绪激动，先安抚再处理两段 prompt 的长度差了三倍，但第二段的可预测性和安全性高了一个量级。
Prompt 上线前的检查清单
经过几次翻车和修正，我整理了一份检查清单。每次上线新的 AI 功能前，我会逐项核对：
场景与边界
- 用户角色是否明确定义（不是泛泛的「用户」）
- 触发时机和使用场景是否写清楚
- AI 的能力范围是否显式标注（可以做什么、不可以做什么）
- 是否和工程、设计、客服团队对齐了功能边界
输入与数据
- 输入字段是否用变量占位符结构化
- 每个字段的来源（用户输入 / 系统注入 / 数据库查询）是否明确
- 是否处理了输入缺失、格式异常的情况
- 是否考虑了输入中可能包含的恶意内容（prompt injection）
输出与格式
- 输出格式是否明确（自然语言 / JSON / 结构化数据）
- 输出的消费方（用户直接阅读 / 前端渲染 / 下游系统）是否清楚
- 输出长度、语气、风格是否有约束
- 是否准备了 3-5 个理想输出样例
失败与兜底
- 信息不足时的追问策略是否定义
- 低置信度时是否标记为需人工审核
- 高风险操作是否有二次确认
- 超出能力范围时是否有诚实告知和替代方案
评测与监控
- 是否准备了覆盖正常、边界、异常的评测样例集
- 是否定义了不可接受的输出（负例）
- 是否有灰度发布计划
- 上线后是否监控了 AI 输出的质量指标（准确率、用户满意度、人工介入率）
把 Prompt 当成产品规格
回到开头的退货客服案例。最终解决问题的不是「语气更专业一点」，而是我们终于坐下来，把退货政策、判断逻辑、异常处理、输出格式一条一条写了下来——这个过程本质上就是在写产品规格。
当 Prompt 影响用户体验，它就不只是文案。它定义了 AI 功能的行为边界、质量标准和风险处理方式。
产品经理越早把边界写清，后续工程实现和评测越稳定。反过来，如果边界模糊，无论后续怎么打磨表达，都只是在沙子上盖楼。
我现在的习惯是：开功能评审会时，先花 15 分钟和团队一起回答那四个前置问题，再让产品同学写初版 prompt，最后和工程一起评审。这个流程看起来多了一步，但实际上把后面返工、改 prompt、紧急 hotfix 的时间省掉了大半。
Prompt engineering 不是产品经理的新技能，而是产品思维在 AI 时代的自然延伸。定义场景、明确边界、考虑失败、准备评测——这些本来就是我们该做的事，只不过现在多了一个「读者」：大语言模型。
它比人类同事更「字面」，比人类同事更需要你把隐含的东西写出来。但它也因此更诚实——你写清楚的边界，它会严格遵守；你没写清楚的，它也不会假装知道。
把 Prompt 当产品规格写，是产品经理在 AI 时代最划算的投资。
参考资料
- OpenAI. Prompt Engineering Guide. OpenAI API Documentation.
- DAIR.AI. Elements of a Prompt. Prompt Engineering Guide.
- Lakera. The Ultimate Guide to Prompt Engineering in 2026. Lakera AI Blog.
- Productboard. 6 AI Prompt Templates for Product Managers. Productboard Blog.
- HelloPM. Prompt Engineering Mastery for Product Managers. HelloPM.
- Alloy. AI for Product Managers: Workflows, Outcomes, and Tools. Alloy Library, 2026.
- prodmgmt.world. Best AI Tools for Product Managers (2026 Guide). Product Management World.
- Bagel AI. 50+ AI Prompts Product Managers Use Weekly (2026 Edition). Bagel AI Blog.