很多人写不好 Prompt，不是因为不够努力，而是因为把它当成”灵感文案”来写。

但 OpenAI 官方文档的底层逻辑其实很朴素：Prompt 是一套约束系统，和玄学没什么关系。先把目标、边界、输出格式写清楚，再谈技巧。否则今天跑通了，明天又跑偏。

一句话总结：先让它稳定可用，再让它漂亮好看。

TL;DR：zero-shot 拿基线，few-shot 定口径，CoT 保过程，self-consistency 降波动，role-play 统一长期风格。

精读之后，我记住的 4 个关键点

1. 分清角色，否则你会”自己打自己”

developer 写规则，user 给输入，assistant 出答案。这不只是语法细节，本身就是一套权限系统。

很多输出跑偏的根因，是把硬约束塞进了 user 文本里。用户一追问，约束就被冲掉了。这种情况很常见。

2. 先做基线，不要上来就叠技巧

先用 zero-shot 跑一版。能跑通，就说明任务可解。

然后再看失败模式是什么：格式乱了，上 few-shot；推理断了，上 CoT；结果抖动大，再上 self-consistency。

3. 结构化写 Prompt，重点在可维护

把 Identity、Instructions、Examples、Context 分开写。后面改版时才知道该改哪一段，不然每次都”整条重写”，又慢又玄。

4. 真要落地，必须有评估闭环

固定样本，固定指标，每次只改一个变量。别凭感觉说”这版更好”，要拿通过率说话。

5 种模式，我是怎么用的

建议顺序：zero-shot -> few-shot -> CoT -> self-consistency。role-play 作为横向增强，不建议单独替代。

1. Zero-shot：先拿到可用基线

什么时候用

任务目标清楚，结构也不复杂，你只想先验证”这题能不能做”。

比如让模型提取一段文本里的所有日期，或者把一段口语化的描述转成标准格式。这种时候不需要给例子，先把规则说清楚，看它能做到什么程度。

常见坑

  • 目标写得太虚，模型不知道优先优化什么
  • 格式没定死，回答每次长得不一样
  • 约束没写全，看起来对，落地就崩

模板

[System]
你是{领域}助手。
目标：{目标}
硬约束：
1) {约束1}
2) {约束2}
输出格式：
1) {字段A}
2) {字段B}

[User]
任务：{任务描述}
输入：{输入内容}

Zero-shot 用来先拿到可用起点。它是低成本摸底，先拿到一版能跑的，再决定要不要升级。

2. Few-shot：把隐含标准变成显性标准

什么时候用

模型大方向没错，但你总觉得它”懂是懂，就是不按你要的方式输出”。

比如做情感分析，模型知道要判断正面或负面，但对你的细分标准不清楚——”略带讽刺的表扬”到底算正面还是负面？这时候给几个例子，比写一百字规则都管用。

常见坑

  • 只给标准样例，不给边界样例
  • 示例之间标准打架
  • 只堆样例，不写规则，后续没法维护

模板

[System]
你是{角色}。
严格复用示例中的判断口径和输出结构，不新增字段。

[User]
请按示例完成任务。

示例1
输入: {x1}
输出: {y1}

示例2
输入: {x2}
输出: {y2}

现在处理：
输入: {x_new}
输出:

Few-shot 的作用不在”喂更多字”。它是在做一组最小可用标注，让模型知道你到底怎么算”对”。

3. CoT：把复杂任务拆开，让过程可检查

什么时候用

多约束、多步骤，而且你需要它给出”为什么”。

比如做一道数学应用题，或者分析一个业务决策的利弊。这种任务如果直接要答案，模型容易跳步或者漏掉某个约束。让它先把推理过程写出来，你能检查哪里出了问题。

常见坑

  • 让模型无限展开，结果又长又空
  • 只有结论，没有可核查路径
  • 讲了过程，但没有风险点

模板

[System]
你是{角色}。请先做步骤化分析，再给结论。
仅输出：
1) 关键假设
2) 推理步骤摘要
3) 最终答案
4) 风险与校验点

[User]
问题：{复杂问题}
约束：{约束列表}

CoT 的重点不在拉长文本。重点是让你的判断可审计、可复盘。

4. Self-consistency：用多候选收敛，换稳定性

什么时候用

单次结果波动大，而且你不能接受”偶然答对，偶然答错”。

比如医疗诊断辅助、财务数据核对这种高风险场景。问一次和问十次结果不一样，这时候需要一种机制来降噪。

常见坑

  • 机械重复问三遍
  • 候选之间根本不独立
  • 没有收敛规则，只是拼接意见

两阶段模板

阶段1：候选生成
给出 3 个相互独立的候选解法，每个包含：
1) 核心结论
2) 关键依据
3) 可能错误点

阶段2：一致性收敛
比较 3 个候选，输出：
1) 最终答案
2) 选择理由
3) 放弃其他候选的原因
4) 仍不确定点

Self-consistency 不会”凭空变聪明”。它做的是降噪，让答案更稳。

5. Role-play：统一风格，更重要的是统一决策口径

什么时候用

你希望输出长期稳定，尤其是多人协作、多人共用 Prompt 的场景。

比如一个团队里有三个人都在写客服回复的 Prompt，结果出来的语气、结构、处理方式各不相同。这时候不是让模型”扮演一个专家”，而是给它定一套职业纪律。

常见坑

  • 只写”你是专家”，不写行为规则
  • 只写语气，不写禁区
  • 角色设定和业务目标冲突

模板

[System]
你是{角色名}，背景是{背景}。
工作原则：
1) 先澄清再结论
2) 明确假设与证据
3) 结论必须包含可执行下一步
禁止：
1) {禁止行为1}
2) {禁止行为2}
输出结构：
1) 结论
2) 依据
3) 下一步

[User]
场景：{场景}
目标：{目标}
输入：{输入}

Role-play 不等于”演角色”。它更像在给模型定职业纪律。

怎么选模式

你遇到的问题 优先动作
先要验证任务可解 zero-shot
格式和口径总漂 few-shot
多步骤推理经常断 CoT
同题多次结果差异大 self-consistency
团队里风格不一致 role-play

记住这张表，基本够应对 80% 的场景。

一个我常用的迭代流程

第 1 步：定义”可用”

先写验收标准。没标准，后面都在吵感觉。

第 2 步：跑 zero-shot 基线

拿到第一版，然后只看失败样本，不急着炫技巧。

第 3 步：按失败类型升级

  • 格式乱：few-shot
  • 推理断：CoT
  • 波动大：self-consistency
  • 口径飘：role-play

一次只加一层。别全加，全加通常会更乱。

第 4 步：最小评估闭环

固定样本集，每次只改一个变量，记录通过率变化。能复现才算进步，不能复现只是运气。

实战示例：从客服对话中提取意图并生成工单

下面用一个真实场景串一遍五种模式。假设你在做一个客服助手，需要从用户对话中提取意图、情绪和关键信息，输出结构化工单。

输入样本

用户：我昨天在你们平台下单了一台显示器，订单号是 20250421001，
今天物流显示已经到站点了，但我等了一整天没人联系配送。
我现在在家办公急用，能不能帮我催一下？

Zero-shot 基线

先不写例子，只给规则和格式。

[System]
你是客服工单助手。
目标：从用户对话中提取关键信息并生成结构化工单。
硬约束：
1) 意图必须是以下之一：催单、退换货、投诉、咨询、其他
2) 情绪必须是以下之一：平静、焦虑、愤怒、满意
3) 不得编造输入中不存在的信息
输出格式：
1) 意图: {意图}
2) 情绪: {情绪}
3) 订单号: {订单号或"无"}
4) 摘要: {20字以内的问题摘要}
5) 建议处理: {给客服的下一步建议}

[User]
用户对话：我昨天在你们平台下单了一台显示器，订单号是 20250421001，
今天物流显示已经到站点了，但我等了一整天没人联系配送。
我现在在家办公急用，能不能帮我帮我催一下？

典型输出

1) 意图: 催单
2) 情绪: 焦虑
3) 订单号: 20250421001
4) 摘要: 物流到站点未配送
5) 建议处理: 联系物流站点催促尽快配送

Zero-shot 能跑通，说明任务可解。但问题也来了：

  • “焦虑”和”愤怒”的边界模糊，有些模型会判成”愤怒”
  • 摘要长度有时超 20 字
  • “建议处理”的口径不稳定，有时给具体操作，有时给泛泛建议

Few-shot：定口径

针对 zero-shot 的漂移问题，给两个例子确定标准。

[System]
你是客服工单助手。严格复用示例中的判断口径和输出结构，不新增字段。

[User]
请按示例完成任务。

示例1（焦虑催单）
输入: 我前天买的键盘怎么还没到？订单 20250420003，我明天要出差了。
输出:
1) 意图: 催单
2) 情绪: 焦虑
3) 订单号: 20250420003
4) 摘要: 键盘物流延迟影响出差
5) 建议处理: 查询物流轨迹，告知预计送达时间，必要时协调加急

示例2（平静咨询）
输入: 想问下你们显示器支持 Type-C 一线连吗？
输出:
1) 意图: 咨询
2) 情绪: 平静
3) 订单号: 无
4) 摘要: 咨询显示器接口功能
5) 建议处理: 回复产品规格，确认型号兼容性

现在处理：
输入: 我昨天在你们平台下单了一台显示器，订单号是 20250421001，
今天物流显示已经到站点了，但我等了一整天没人联系配送。
我现在在家办公急用，能不能帮我催一下？
输出:

典型输出

1) 意图: 催单
2) 情绪: 焦虑
3) 订单号: 20250421001
4) 摘要: 显示器到站点未配送
5) 建议处理: 查询站点配送安排，协调优先派送，同步预计时间

加了 few-shot 后，”焦虑”的判定更准确了，摘要也收敛到 10 字左右，建议处理的粒度对齐了示例风格。

CoT：让推理可检查

假设业务变复杂：用户同时抱怨多个问题，需要拆分优先级。这时候不能只要答案，要看模型怎么拆的。

[System]
你是客服工单助手。请先做步骤化分析，再给结论。
仅输出：
1) 关键假设
2) 推理步骤摘要
3) 最终答案（严格复用示例格式）
4) 风险与校验点

[User]
用户对话：我昨天在你们平台下单了一台显示器，订单号是 20250421001，
今天物流显示已经到站点了，但我等了一整天没人联系配送。
我现在在家办公急用，能不能帮我催一下？
另外我发现你们商品页写的刷新率是 144Hz，但包装盒上印的是 120Hz，
这是不是虚假宣传？

约束：
- 用户同时提了物流和商品描述两个问题
- 商品描述问题涉及合规风险，优先级高于普通催单

典型输出

1) 关键假设
   - 用户陈述的订单号和包装信息为真
   - "商品页"指本平台商品详情页

2) 推理步骤摘要
   Step 1: 识别问题数量 → 物流未配送 + 商品描述不符
   Step 2: 评估优先级 → 商品描述涉及虚假宣传，合规风险高，优先处理
   Step 3: 提取订单号 → 20250421001
   Step 4: 判定情绪 → 焦虑中带质疑

3) 最终答案
   1) 意图: 投诉
   2) 情绪: 焦虑
   3) 订单号: 20250421001
   4) 摘要: 物流延迟且质疑商品描述不符
   5) 建议处理: 先核实商品页与包装参数差异，同步安抚用户并协调物流优先配送

4) 风险与校验点
   - 风险：用户情绪可能升级，需 2 小时内首次响应
   - 校验：必须人工核实商品页历史快照，确认是否曾标注 144Hz

CoT 的价值在这里体现得很清楚：如果没有步骤 2 的优先级评估，模型可能会把两个问题平行处理，甚至只输出催单。现在你能检查它为什么把”投诉”排在”催单”前面。

Self-consistency：降噪收敛

把上面的 CoT 场景跑三遍，让模型独立生成多个候选，再收敛。

[System]
你是客服工单助手。请按以下两阶段处理。

阶段1：候选生成
给出 3 个相互独立的候选解法，每个包含：
1) 核心结论（意图、情绪、优先级判断）
2) 关键依据
3) 可能错误点

阶段2：一致性收敛
比较 3 个候选，输出：
1) 最终答案（严格复用示例格式）
2) 选择理由
3) 放弃其他候选的原因
4) 仍不确定点

[User]
用户对话：我昨天在你们平台下单了一台显示器，订单号是 20250421001，
今天物流显示已经到站点了，但我等了一整天没人联系配送。
我现在在家办公急用，能不能帮我催一下？
另外我发现你们商品页写的刷新率是 144Hz，但包装盒上印的是 120Hz。

典型输出

阶段1：候选生成

候选 A
1) 核心结论：意图=投诉，情绪=愤怒，优先级=商品描述问题优先
2) 关键依据：用户明确质疑"虚假宣传"，属于合规敏感词
3) 可能错误点：情绪可能过度推断为"愤怒"，原文更偏向"焦虑"

候选 B
1) 核心结论：意图=催单，情绪=焦虑，优先级=物流问题优先
2) 关键依据：用户开篇和结尾都在强调"急用""催一下"，物流是主诉
3) 可能错误点：可能忽略了商品描述问题的合规风险

候选 C
1) 核心结论：意图=投诉，情绪=焦虑，优先级=商品描述问题优先
2) 关键依据：两个问题上，"虚假宣传"的升级路径更危险；"急用"是情绪背景，不是核心矛盾
3) 可能错误点：需要人工确认商品页是否确实标注过 144Hz

阶段2：一致性收敛

1) 最终答案
   1) 意图: 投诉
   2) 情绪: 焦虑
   3) 订单号: 20250421001
   4) 摘要: 物流延迟且质疑商品描述不符
   5) 建议处理: 优先核实商品页参数，同步协调物流优先配送，2 小时内响应

2) 选择理由
   - 候选 A 和 C 都识别到商品描述的合规风险，这一点上比 B 更完整
   - C 的情绪判定"焦虑"比 A 的"愤怒"更准确，避免过度反应

3) 放弃其他候选的原因
   - 放弃 B：低估了商品描述问题的风险，主诉判断有偏
   - 放弃 A：情绪推断偏激进，可能导致客服过度安抚

4) 仍不确定点
   - 商品页是否确实标注 144Hz，需人工核实
   - "急用"是否涉及商业场景，影响补偿策略

Self-consistency 没有让模型”更聪明”，但它逼模型把不确定性显式摆出来。最终答案比单次 CoT 更稳，而且”仍不确定点”给人工介入提供了明确抓手。

Role-play：统一长期风格

假设团队有三个人都在写客服 Prompt，输出风格各异。这时候不是让模型”扮演客服专家”，而是给它定一套职业纪律。

[System]
你是客服工单助手，背景是电商平台售后中台。
工作原则：
1) 先澄清再结论：遇到信息缺失或矛盾，先标注待核实项，不猜测
2) 明确假设与证据：每个判断必须指向原文具体位置
3) 结论必须包含可执行下一步：禁止输出"请尽快处理"这类空话
禁止：
1) 使用"非常抱歉给您带来不好的体验"等模板化安抚语
2) 在证据不足时推断用户情绪为"愤怒"
3) 合并多个独立问题时只保留一个
输出结构：
1) 意图
2) 情绪
3) 订单号
4) 摘要
5) 建议处理

[User]
场景：用户同时反馈物流延迟和商品描述疑问
目标：生成结构化工单并标注风险等级
输入：我昨天在你们平台下单了一台显示器，订单号是 20250421001，
今天物流显示已经到站点了，但我等了一整天没人联系配送。
我现在在家办公急用，能不能帮我催一下？
另外我发现你们商品页写的刷新率是 144Hz，但包装盒上印的是 120Hz。

典型输出

1) 意图: 投诉
2) 情绪: 焦虑
3) 订单号: 20250421001
4) 摘要: 物流到站点未配送，质疑商品页刷新率标注（144Hz vs 120Hz）
5) 建议处理:
   - 物流：查询站点配送安排，协调当日优先派送，同步预计时间
   - 商品描述：调取商品页历史快照核实 144Hz 标注记录，若属实则启动合规核查流程
   - 风险标注：商品描述问题涉及虚假宣传敏感词，建议 2 小时内首次响应

Role-play 在这里的作用不是”演得更像客服”，而是统一了三件事：

  • 情绪判定口径：禁止轻易判”愤怒”，避免客服过度反应
  • 摘要风格：不合并问题，独立列出
  • 建议粒度：必须拆成可执行动作，禁止空话

示例总结

模式 解决的问题 本示例中的具体改进
Zero-shot 验证任务可解 确认能从对话中提取意图、情绪、订单号
Few-shot 格式和口径漂移 钉死”焦虑”判定标准、摘要长度、建议粒度
CoT 多步骤推理断裂 显式展示优先级评估过程，避免漏掉商品描述问题
Self-consistency 结果波动大 三候选收敛，显式标注不确定点，降低误判风险
Role-play 团队风格不一致 统一情绪判定禁区、建议输出粒度、禁止模板化安抚语

这个示例的核心想说明一点：Prompt 的升级不是堆技巧，而是按失败模式对症下药。 你的 zero-shot 如果本来就很稳，没必要为了用 CoT 而 CoT。

模式组合：按需拼装

上面的示例为了讲清楚每种模式，把它们拆开了。但真实落地时，很少单独用某一种，更多是组合使用。 关键是理解每种模式的职责边界，知道什么时候该加、什么时候不该加。

常见组合方式

组合 1：Few-shot + Role-play（最常用）

这是团队协作出 Prompt 时的基线配置。Role-play 定纪律，Few-shot 定口径，两者互补。

  • Role-play 解决”风格统一”问题：禁止什么、必须什么
  • Few-shot 解决”标准模糊”问题：焦虑长什么样、摘要多长算合适

组合 2：CoT + Self-consistency（高风险场景）

医疗诊断、财务核对、合规审查这类不能出错的场景，需要过程可检查 + 结果可收敛。

  • CoT 保证每一步推理都有迹可循
  • Self-consistency 通过多候选投票降低偶然错误

组合 3：全套组合（复杂业务系统）

把五种模式全部串起来，形成一套完整的生产级 Prompt。

[System]
你是{角色名}，背景是{背景}。
工作原则：
1) 先澄清再结论
2) 明确假设与证据
3) 结论必须包含可执行下一步
禁止：
1) {禁止行为1}
2) {禁止行为2}

[User]
请按以下步骤处理：

步骤1：候选生成（Self-consistency）
基于输入，独立生成 3 个候选分析，每个包含：
- 核心结论
- 关键依据
- 可能错误点

步骤2：一致性收敛
比较 3 个候选，输出最终结论和选择理由。

步骤3：结构化输出（Few-shot 格式）
严格按以下格式输出：
1) 意图: {意图}
2) 情绪: {情绪}
3) 订单号: {订单号}
4) 摘要: {20字以内}
5) 建议处理: {可执行下一步}

参考示例：
示例1（焦虑催单）
输入: ...
输出: ...

示例2（平静咨询）
输入: ...
输出: ...

现在处理：
输入: {用户对话}

这个组合里：

  • Role-play 在 System 层定纪律
  • Self-consistency 在步骤 1-2 做降噪
  • Few-shot 在步骤 3 定输出格式
  • CoT 的推理过程被内化到”候选生成”和”一致性收敛”中

组合时的注意事项

不要全堆

全加通常会更乱。每种模式都有成本：

  • Few-shot 消耗 token，示例太多会挤占上下文
  • Self-consistency 需要多次调用，延迟和成本翻倍
  • CoT 拉长输出，如果业务不需要过程可检查，就是噪音

一次只加一个

基线跑通后，按失败类型逐个加：

  1. 格式乱 → 加 Few-shot
  2. 推理断 → 加 CoT
  3. 波动大 → 加 Self-consistency
  4. 口径飘 → 加 Role-play

每加一层，跑一遍评估集，确认有提升再往下走。

Role-play 是横向增强，不是纵向升级

Zero-shot → Few-shot → CoT → Self-consistency 是纵向的复杂度升级，解决的是”能不能做对”。

Role-play 是横向的风格增强，解决的是”长期稳定输出”。它可以和任何一种纵向模式组合，但不建议单独替代其他模式。

一个判断口诀

你的现状 加什么 不加什么
基线能跑，但格式总漂 Few-shot Self-consistency（还没波动问题）
多步骤任务，模型跳步 CoT Role-play（不是风格问题）
同输入多次结果不一致 Self-consistency 更多 Few-shot（样本不是波动根因）
团队多人写 Prompt，输出风格各异 Role-play CoT（不是推理问题）
高风险 + 多步骤 + 团队协作 全上 —

组合的本质是精准投放：先定位你的失败模式，再选对应的模式组合，而不是把五种技巧全塞进去求个心安。