系统化 Prompt 设计：从角色设定到输出结构控制

从“调 Prompt”到“设计 Prompt”

上一节我们理解了 Prompt 是 AI 产品的语言接口。但在真实项目中，Prompt 往往是团队里某个人某个深夜随手写的，然后被反复打补丁，最后变成没人敢动的“祖传代码”。系统化 Prompt 设计的目的，就是让 Prompt 变成可维护、可协作、可测试的产品资产。

推荐一个五段式结构作为起点：

[角色] 你是谁，专业背景如何
[任务] 要完成什么，成功标准是什么
[上下文] 相关背景、输入数据、边界信息
[约束] 不许做什么、优先级冲突时如何取舍
[输出格式] 结构、长度、风格、示例

角色设定：不是玄学，是分布的偏移

“你是一位资深律师”这类角色设定，本质上是在把模型的输出分布拉向某个专业语料的空间。产品视角的要点：

• 角色要与任务的专业领域对齐，而不是与用户对齐。给用户做法律咨询助手，设定“耐心的小学老师”就文不对题。
• 角色设定应包含行为倾向，不只是身份。例如“你倾向于给出简洁、可执行的回答，避免罗列不相关的背景知识”。
• 警惕角色带来的立场固化：如果设定“你总是支持用户的方案”，会显著削弱回答的批判性。

任务拆解：一个 Prompt 只做一件事

复杂需求要拆成多步，就像复杂功能要拆成多个接口。两种拆法：

1. 串行流水线：先抽取 → 再分类 → 再生成。每步一个 Prompt，中间结果可检查、可干预。客服工单处理通常这样拆：意图识别 → 信息抽取 → 回复生成。
2. 单 Prompt 内的分步指令：要求模型“先分析，再给结论”。适合中等复杂度，成本低但可控性弱。

产品决策提示：判断拆不拆的标准是错误成本。分步流水线的中间结果可以被规则引擎校验、被人工抽检；单 Prompt 出错只能整体重来。凡是涉及资金、合规、对外发送的场景，优先拆步。

约束条件：把“不许”写清楚

模型的默认行为往往与你期望的产品行为有出入。常见的必要约束：

• 范围约束：“仅基于提供的资料回答，资料中没有的信息要明确说不知道”——这是 RAG 场景的标配。
• 风格约束：“不要使用感叹号”“避免营销话术”。
• 冲突取舍：“当准确性与简洁性冲突时，优先准确性。”
• 拒答规则：什么情况引导转人工，什么情况直接拒绝。

输出结构控制

这是对产品经理最有价值的一节。三个层次：

层次	手段	适用场景
强结构	要求输出 JSON/XML，配合 schema 描述	程序消费：分类、抽取、打标
半结构	Markdown 标题 + 列表 + 固定小节	界面直接渲染：报告、摘要
弱结构	只控长度和风格	开放对话、创意生成

两个实用技巧：

• 给一个输出示例（锚定）：在 Prompt 末尾放一个符合预期的完整输出样例，模型会强烈模仿它的结构。
• 用分隔符隔离用户输入：用 <user_input>...</user_input> 包住用户内容，防止用户输入被当成指令执行（即 Prompt 注入）。

版本管理与协作流程

把 Prompt 当代码管理：

1. 入库：Prompt 与代码同库，禁止只存在于某人的对话框里。
2. 版本号与变更记录：每次修改记录动机和预期影响，方便回滚。
3. 固定变量：把模型版本、温度参数与 Prompt 版本一起记录——换模型导致的退化经常被误判为 Prompt 问题。
4. 评审：Prompt 变更走类似 code review 的流程，至少两人过目长尾场景。

产品决策提示：Prompt 的“好”没有客观标准，只有相对基线的好。建立一套固定的测试问题集（哪怕只有 30 条），每次改动跑一遍对比，是成本最低的质量保险。

本节要点

• 用“角色 / 任务 / 上下文 / 约束 / 输出格式”五段式结构编写 Prompt，让团队协作有共同框架。
• 复杂任务按错误成本决定是否拆成多步流水线；高错误成本场景优先拆步，保留中间检查点。
• 输出结构按消费方分为强结构（JSON）、半结构（Markdown）、弱结构三类，程序消费必须约定格式并做解析兜底。
• 用分隔符隔离用户输入、写清拒答规则，是防范 Prompt 注入和越界输出的第一道防线。
• Prompt 需要版本管理、变更记录与固定测试集，把“凭感觉”变成“对基线”。