Appearance
大部分提示词优化技巧的目的：对抗 token 生成的随机性
Q：如何超过模型能力极限？
0-shot 零样本提示
解释
不需要示例，依靠模型原生能力得出结果，适用于通用任务。
User Prompt
文本摘要："总结以下文章的主要内容..."
简单翻译："将这句话翻译成英文..."
基础问答："Python 中如何创建列表？"
缺点
无法胜任有明确规则、要求的任务
few-shot 少样本提示
解释
提供少量样本，对抗生成结果的随机性
适合场景
0-shot User Prompt
实现一个函数，将日期格式化为中国人习惯的方式，支持年月日、星期、时辰等信息
few-shot User Prompt
实现一个函数，将日期格式化为中国人习惯的方式，支持年月日、星期、时辰等信息。
js
// 示例 1
formatChineseDate(new Date("2024-01-15 09:30:00"));
// 输出: 2024 年 1 月 15 日 星期一 上午 巳时js
// 示例 2
formatChineseDate(new Date("2024-01-15 13:45:00"));
// 输出: 2024 年 1 月 15 日 星期一 下午 未时适用场景：
- 需要特定格式或结构的输出
- 特定格式的文档生成（简历、报告等）
- 特定格式的代码实现
- 特定风格的文章写作
- 任务规则复杂或含糊
- 当规则用文字难以准确描述
- 规则包含多个特殊情况
- 最好通过例子来展示规则
- 需要保持一致性的任务
- 批量数据处理
- 标准化命名
- 统一的文本风格
- 涉及主观判断的任务
- 情感分析
- 文本分类
- 风格转换
与 LangGPT 结合
作为 examples 模块：
xml
<global>
$language = "JavaScript/TypeScript"
</global>
<role>
你是一位专门负责日期格式化的函数开发专家，擅长将日期转换为中国传统格式
</role>
<task>
实现一个将日期格式化为中国人习惯方式的函数
</task>
<constraints>
- 输入: Date对象
- 代码语言: {$language}
- 函数名称: formatChineseDate
</constraints>
<output_format>
年月日 星期 上下午 时辰
</output_format>
<examples>
示例1:
Input: new Date('2024-01-15 09:30:00')
Output: "2024年1月15日 星期一 上午 巳时"
示例2:
Input: new Date('2024-01-15 13:45:00')
Output: "2024年1月15日 星期一 下午 未时"
</examples>缺点
没有推理过程，不适合 需要多步骤执行 的任务，适合作为单次输入、输出流程。
CoT Chain-Of-Thought 思维链
解释
要求模型展示推理步骤，随着步骤的明确，生成随机性降低
适合场景
对于 需要多步骤推理过程才能得出答案 的任务
Q：谁来拆解推理步骤？
0-shot CoT
解释：使用类似"让我们一步步思考"的提示词，强制模型分步骤思考
User Prompt
小明有 15 个气球,送给小红 3 个,小李 5 个,现在还有几个?
让我们一步步思考
优缺点：简单直接，一些模型已经内置了该能力，但效果可能不好（模型不一定按我们的意愿思考）。
扩展阅读：Thinking Claude
few-shot CoT
解释：0-shot CoT 需要模型拆分步骤，拆分步骤这一步可以通过 few-shot 引导
优缺点：效果更好，但需要准备示例
few-shot CoT 例子
问题 1: 小李有 8 个苹果,吃掉 3 个,又买来 2 个,现在有几个?
解答:
先看小李开始有多少个
- 开始有 8 个
吃掉后还剩多少
- 吃掉 3 个: 8 - 3 = 5 个
买来新的后有多少
- 买来 2 个: 5 + 2 = 7 个
所以现在有 7 个苹果
问题 2: 小明有 15 个气球,送给小红 3 个,小李 5 个,现在还有几个?
解答:
与 LangGPT 结合
LangGPT 中模块的定义顺序，在设计时就考虑了 CoT：
LangGPT 中的 CoT
- Role (角色)
- Profile（角色简介）
- Profile 下的 skill (角色技能)
- Rules (角色要遵守的规则)
- Workflow (满足上述条件的角色的工作流程)
- Initialization (进行正式开始工作的初始化准备)
- 开始实际使用
LangGPT 中任何模块都能使用 CoT，最主要的是 Workflow
工作原理
可以从两个角度解释：
- 推理能力角度：CoT 让模型能更好利用预训练时学到的推理能力，通过推理步骤激活了模型内部更多相关知识的展示，减少了模型在单步大跨度推理时的信息损失
- token 预测角度：模型的本质是预测下一个 token，使用 CoT 时，如果输出的当前执行步骤正确，那输出新步骤时之前正确的步骤将作为上下文，以此降低生成 token 的随机性
缺点
只有单一视角的推理过程
Self-Consistency CoT 自我一致性
解释
并行执行多条不同的 CoT 推理路径，对比不同推理路径的结果，投票评估最终结果
案例
未经过 SC 优化：
xml
<role>
一位拥有丰富前端开发和架构经验的技术专家
</role>
<workflow>
对于输入的问题，执行如下步骤：
1. 说明这个视角的独特观点
2. 列出关键的分析论据
3. 给出基于该视角的结论
</workflow>
<constraints>
- 分析必须独立且深入
- 分析必须基于该技术专家的专业知识和关注点
- 避免个人偏见,保持客观中立
</constraints>
<input_format>
[待分析的具体问题]
</input_format>
<output_format>
## 前端技术专家视角
[前端专家的分析内容]
</output_format>
前端是否应该负责部分后端工作（作为BFF层）？经过 SC 优化后：
xml
<role>
一位有丰富软件开发、架构设计、需求分析经验的软件公司CTO
</role>
<workflow>
1. 分别以下面四种不同身份/视角来思考问题：
- 前端技术专家
- 后端技术专家
- 测试工程师
- 产品经理
2. 对于每个视角执行如下步骤：
- 说明这个视角的独特观点
- 列出关键的分析论据
- 给出基于该视角的结论
3.
- 比较这所有视角的异同点
- 整合各个视角的见解
- 提出一个综合的、平衡的最终结论
</workflow>
<constraints>
- 每个视角的分析必须独立且深入
- 分析必须基于该角色的专业知识和关注点
- 避免个人偏见,保持客观中立
- 最终结论必须平衡考虑所有视角
</constraints>
<input_format>
[待分析的具体问题]
</input_format>
<output_format>
## 前端技术专家视角
[前端专家的分析内容]
## 后端技术专家视角
[后端专家的分析内容]
## 测试工程师视角
[测试工程师的分析内容]
## 产品经理视角
[产品经理的分析内容]
## 综合分析
[各视角对比和最终结论]
</output_format>
前端是否应该负责部分后端工作（作为BFF层）？适合场景
- 复杂推理问题
- 数学题、逻辑题等需要多步骤推导的问题
- 问题求解有多种可能的思路和路径
- 需要确保推理过程的可靠性
- 有歧义的开放性问题
- 存在多个合理答案
- 需要从不同角度分析问题
- 答案具有不确定性
- 需要验证结果的场景
- 通过多次独立推理交叉验证
- 检查答案的一致性
- 提高结果的可信度
缺点
- 只有线性推理过程，不能前瞻、回溯、全局探索不同想法
- 只有推理没有评估和改进
无法胜任的工作：
24 点游戏
请用我给你的 4 个数字，通过加、减、乘、除、括号，组成一个运算，使得结果为 24。
注意：数字需要全部使用
我提供的数字：4 4 6 8
人类推理的过程：
- 提出想法：解决这个问题有哪些好想法？
- 评估想法：如何衡量想法的好坏？
- 做出改进：基于上述评估，下一步该怎么做？
小作业：使用上述介绍过的所有技巧尝试解决该问题
ToT Tree-of-Thought 思维树
解释
与传统 CoT 的区别：
- 不仅有思考，还能评估，并基于评估改进行动
- 不仅能顺序执行，还能前瞻、回溯、全局探索
脱离单纯 提示词技巧 的范畴，根据实现逻辑，应该被划分为 workflow 或 agent
24 点游戏求解器
工作原理：以 BFS（广度优先搜索）的方式求解