如何使用不同Prompt技巧，让大模型更听话？
本篇内容并不都只是写提示词的技巧，而是涵盖了从提示词设计技巧，到用Prompt搭流程（Workflow），再到以Prompt为接口的完整 LLM 应用与系统设计模式的整体演进的相关技术。
一、Prompt 表达层（Prompting as Text）
- Zero-Shot Prompting（零样本提示）
- 定义：不给任何示例，只用一句明确指令，直接让模型完成任务。比如：分类、翻译、摘要、简单问答等。
Classify the text into neutral, negative or positive.
Text: I think the vacation is okay.
Sentiment:
- Few-Shot Prompting（少样本提示）
- 在 Prompt 中先给模型少量示例（demonstrations / exemplars），再让它完成新任务。本质是In-Context Learning（上下文学习）。当你对回答的语气 / 风格 / 格式有要求，需要临时对齐了你这一次的规则。适合使用。
Text: That movie was great!
Sentiment: Positive
Text: The food was terrible.
Sentiment: Negative
Text: I think the vacation is okay.
Sentiment:
- Chain-of-Thought Prompting（思维链提示）
- 思维链提示则进一步把“中间推理过程”显式化，强制模型按步骤分解问题、逐步计算，从而避免跳步猜答案，比如数学问题，计算等。
Solve the problem step by step, then give the final answer:
If you have 3 apples and you buy 2 more, how many apples do you have?
- Self-Consistency（自一致性）
什么是 Self-Consistency？ Self-Consistency 是一种用于推理类任务的提示技术，目的是替代链式思考（Chain-of-Thought）中依赖单一路径、单次生成所带来的不稳定性。 它的核心做法是：对同一个问题生成多条相互独立的推理路径，再从这些结果中选择出现频率最高、彼此最一致的最终答案作为输出。 它并不是为了让推理过程更复杂，而是通过“多次独立思考 + 结果一致性选择”，提升推理结果在工程实践中的稳定性与可靠性。
直观理解 可以把 Self-Consistency 理解为：让多个人分别解同一道题，最后不看谁写得最漂亮，而是看哪个答案被最多人算出来。 这里的“多个人”对应模型生成的不同推理路径，“投票”对应对最终答案的一致性筛选。
为什么要用？ 当一个 Prompt 在一次生成中同时要求模型“完成推理过程”和“给出最终结论”时，很容易因为中途某一步判断失误而整体跑偏。 Self-Consistency 通过引入多条推理路径，将这种偶然性显式暴露出来，并用一致性规则进行约束，从而减少单次推理失败对最终结果的影响。 它尤其适用于算术推理、常识推断以及对结果稳定性要求较高的解释型任务。
错误的一句话问法（示例）
When I was 6 my sister was half my age. Now I’m 70, how old is my sister?
这种问法把“推理”和“定论”压缩在一次生成中，模型一旦选错推理路径，就会自洽地输出错误答案。
最小化的 Self-Consistency 用法，做法并不复杂，可以拆成三步：
- 第一步，让模型按链式思考方式完成推理；
- 第二步，对同一问题进行多次独立生成；
- 第三步，对最终答案进行统计，选择出现次数最多的结果。
最小通用模板（可复用）
你将对同一个问题进行多次独立推理。
每次推理都需要完整给出思考过程，并在最后给出一个明确答案。
在完成所有推理后，只输出出现次数最多的最终答案。
问题：
{在这里放入你的问题}
- Meta Prompting（元提示）
Meta Prompting 是一种“先定结构、再填内容”的提示方法。它不是通过给模型示例来教它怎么答，而是先告诉模型答案应该按什么结构来写，再让模型在这个结构里完成具体内容。
直观理解： 你不是给模型“参考答案”，而是给它一张答题模板。模板只规定顺序和栏目，不规定具体写什么。
- 模板 → Prompt 中的结构规则
- 填写内容 → 模型的推理与生成
在工程实践中，Meta Prompting 常用于需要统一输出结构的场景。模型不再模仿某个具体例子，而是始终按照同一套结构规则来思考和表达。
一个更直观的判断方法是： 如果你一句 Prompt 里，同时让模型学例子的样子、真正去解题、还要顺便解释它是怎么想的，那输出大概率会变乱。 Meta Prompting 的做法，就是把“怎么想、怎么写”这件事提前规定好，让模型只专心填内容，而不是在生成时临时做取舍。
错误的一句话问法示例：
请参考下面的示例，解答这个问题，并说明你的思考过程。
这个问法把示例模仿、问题求解、过程解释混在一起，输出结构很容易随着示例变化而变乱。
使用 Meta Prompting 的最小改进方式：
请按照以下结构完成任务：
- 第一步：列出已知条件
- 第二步：给出推理步骤
- 第三步：得出最终结论
要求：每一步只完成对应内容。
这里不提供任何具体示例，只定义答案应该如何被组织。
- Directional Stimulus Prompting（定向刺激提示）
Directional Stimulus Prompting（定向刺激提示） 是一种 “先划重点、再生成” 的提示方法。 它不是让模型自己判断什么重要，而是你先明确告诉模型 你希望关注的重点在哪，再让模型围绕这些重点完成回答，从而减少遗漏和跑偏。
直观理解： 你不是让模型“自由发挥地总结”，而是先给它一张 划重点清单。 这张清单只规定 必须覆盖哪些点，不规定具体怎么写。
- 划重点清单 → Prompt 中的 stimulus / hint
- 围绕重点输出 → 模型的生成与组织表达
在工程实践中，Directional Stimulus Prompting 常用于需要 稳定覆盖关键信息 的场景，比如摘要、信息抽取、报告生成等。 模型的目标不再是“写得像不像”，而是 “该提到的点一个不漏”。
一个更直观的判断方法是：
- 如果模型的回答 看起来没问题 但 总是漏掉你最在意的几件事 那就说明重点没有被提前约束，适合使用定向刺激提示。
错误的一句话问法示例：
请用 2-3 句话总结下面这段内容。
这个问法把 “判断重点” 和 “生成总结” 混在一起， 重点完全交给模型自己决定，结果容易 遗漏关键信息或方向跑偏。
使用 Directional Stimulus Prompting 的最小改进方式：
参考以下重点总结内容：
重点：
- {必须提到的点1}
- {必须提到的点2}
- {必须提到的点3}
- Generated Knowledge Prompting（生成式知识提示）
**Generated Knowledge Prompting（生成式知识提示）**是一种提示方法：先让模型显式生成与问题相关的背景知识，再基于这些知识完成最终判断或回答。
这就像让一个人先把相关资料写在草稿纸上，再正式答题。 草稿纸上的内容不是答案，而是解题所需的背景信息。
- 草稿纸 → 生成的 Knowledge
- 正式答题 → 基于 Knowledge 的最终回答
经验判断规则： 当一个问题表面看起来很简单，但实际依赖隐含常识或真实世界规则时，就很容易出错。在一次性回答中，模型往往直接对结论进行优化，而不是先确保支撑结论的知识是否完整、是否正确。当输出目标越短、越确定（例如 Yes / No），模型越容易跳过必要的知识校验。
三种典型适用情况
情况一：常识判断类问题
问题特征： 判断依赖真实世界规则，但规则未在问题中显性出现。
错误的问法：
Part of golf is trying to get a higher point total than others. Yes or No?
使用 Generated Knowledge Prompting：
Question: Part of golf is trying to get a higher point total than others. Yes or No?
Knowledge: {生成的高尔夫计分规则}
Answer:
情况二：事实与定义容易混淆的问题
问题特征：概念相近，模型容易模糊处理定义边界。
错误的问法：
A rock is the same size as a pebble. Yes or No?
使用 Generated Knowledge Prompting：
Question: A rock is the same size as a pebble. Yes or No?
Knowledge: {生成的 pebble 尺寸定义}
Answer:
情况三：是 / 否、对 / 错等二值判断
问题特征：输出空间极小，模型容易直接给结论而不校验依据。
错误的问法：
Smoking increases the chance of lung cancer. Yes or No?
使用 Generated Knowledge Prompting：
Question: Smoking increases the chance of lung cancer. Yes or No?
Knowledge: {生成的因果或统计事实}
Answer:
提问模版
输入：{问题}
第一步：请先写出回答该问题所必需的背景知识或事实，不要给结论。
知识：
第二步：仅基于上述知识回答问题。
答案：
- Multimodal CoT Prompting （多模态链式思维提示）
Multimodal CoT Prompting（多模态链式思维提示），就是在有图片和文字一起输入时，先让模型把“看懂的过程”写出来，再让它给答案，避免它没看清就乱猜。
它解决的问题很简单： 模型在看图 + 回答时，经常只用文字经验直接下结论。
就像老师让你做看图题：。
- 图和题目 → 输入
- 先写“我是怎么看出来的” → 推理过程
- 再写答案 → 最终结论
重点不是写得多漂亮，而是真的看过图再说话
在实际系统中，这种做法等于强制模型按顺序来：先理解图片，再给结果，减少跳步和瞎猜。
为什么要用？
模型一旦知道“目标是给答案”，就可能先编答案，再补理由。
最常见的三种情况
情况一：图像问答
错误情况：
看这张图，这是什么？为什么？
模型可能直接用常识猜答案，理由也是事后编的，图看没看不重要。
改进方式：
请先描述你在图片中看到的关键内容，
说明这些内容分别代表什么。
在分析完成后，再回答这是什么。
先逼它“看图说话”，再允许它下结论。
情况二：找共同点 / 做对比
错误情况：
这两个东西有什么共同点？
可能直接给一个“听起来对”的共同点，但没逐一检查。
改进方式：
请分别列出这两个物体在图片中能看到的属性，
然后基于这些属性判断它们的共同点。
最后给出结论。
情况三：找共同点 / 做对比
错误情况：
根据图片选择正确答案。
只看结果，完全不知道模型有没有认真分析。
改进方式：
请先说明你是如何根据图片一步步排除错误选项的，
再给出你选择的最终答案。
让过程暴露出来，答案才有意义。
- GraphPrompts（图提示）
- 把问题里的信息组织成图结构（Graph）用**节点（nodes）和边（edges）**明确表示实体和关系，再把这个结构作为提示输入给大模型，目的是让模型在关系理解、推理、结构化任务上表现更好。
二、Prompt 流程层（Prompting as Workflow）
- Prompt Chaining（提示链）
什么是提示链？
Prompt Chaining 指的是将一个复杂任务拆分为多个小问题，按照固定顺序依次向模型提问，并将前一步的输出作为后一步的输入。它的目的不是让流程变复杂，而是把原本容易出错的判断和思考过程提前拆开并显式控制，从而实现风险分离。在简单任务中这种优势不一定明显，但在大上下文、需要可解释、可审计并尽量减少幻觉的工程场景中，往往能显著提升结果的稳定性与可控性。
如果用一个直观的比喻来理解，它就像制作一份复杂的便当：与其一句话要求“全部做好”，不如按照“先煮饭、再做菜、最后摆盘”的顺序逐步完成。Prompt Chaining 正是把这种分步完成的思路，引入到与大语言模型的交互中，让模型在每一步只做一件事，从而避免在一次生成中同时承担多种不同性质的思考任务。
为什么要用
LLM 在一次生成中通常只能沿着一个思路往前走。当你在一个 Prompt 里要求它完成两种不同性质的思考任务时，后面的输出目标会反过来污染前面的思考过程。换句话说，模型往往不是先想清楚再回答，而是在生成答案的同时顺便编思考过程。因此，当下面这些事情被放在同一个 Prompt 里时，就特别容易出错。
第一类是把判断与回答混在一起。判断一件事是否可行，本应先确定判断标准，但在同一个 Prompt 里，模型往往会先给结论，再为结论拼理由，导致判断依据不稳定。错误范例:
这个 Prompt Chaining 方案是否合理？请直接给出结论，并说明理由。
第二类是把事实获取与解释混在一起。当模型一边找原因、一边解释原因时，如果它并不知道真实事实，就会自然地补充听起来合理但未经验证的内容。
根据这篇文档，解释 Prompt Chaining 为什么可以显著减少幻觉问题。
第三类是把结构规划与内容生成混在一起。结构规划需要全局视角，而内容生成是线性输出；两者同时进行时，模型容易边写边改结构，导致逻辑跳跃或重复。
请系统、完整、有逻辑地写一篇文章，介绍 Prompt Chaining 的定义、原理、优势和应用示例。
怎么用？
真实例子：想要判断一个方案是否可行
如果用一句话提问，例如：
这个方案是否可行？请说明理由。
缺点分析：这种问法的主要问题在于，它把“先建立判断标准”和“直接下结论并解释”这两件不同性质的任务混在了一起。模型在一次生成中往往会先给出一个看起来合理的结论，然后再为这个结论补充理由；由于判断标准没有被提前明确，理由更像是为结论服务的“事后解释”。结果就是：判断依据不稳定、解释可能偏主观，且你很难看清它到底是基于哪些因素做出的判断。
更稳妥的做法是采用最小的 Prompt Chaining，把“确定判断依据”和“依据评估并下结论”拆成两步完成。
Step 1：先定判断依据
请列出判断一个方案是否可行时，需要考虑的关键因素。
只列因素，不下结论。
Step 2：再用依据给结论
请根据上面列出的关键因素，
逐条评估下面这个方案，并给出最终结论。
方案是：{方案内容}
最简单的Prompt Chaining模板
这个模板只做一件事：把“思考”从“回答”里剥离出来。 Step 1：先想清楚，不回答
在回答问题之前，
请先列出你需要考虑的关键点 / 判断依据。
只列点，不要给最终答案。
Step 2：基于上一步再回答
请根据上面列出的关键点，
一步步思考，并给出最终答案。
- Tree of Thoughts (ToT)（思维树）
Tree of Thoughts（ToT，思维树） 是一种用于复杂推理任务的提示与推理框架。 它解决的核心问题是：当问题存在多种可能路径、需要试探、回退或比较中间方案时，模型一次线性生成很容易走偏且无法自纠。 它的基本工作方式是：让模型在多个“中间思路（thought）”之间进行分支生成、评估与筛选，并通过搜索策略逐步逼近可行解。
可以把 ToT 理解为下棋时的“多步预演”。 你不是只走一步棋就定胜负，而是同时设想几种走法，分别推演几步，再淘汰明显会输的路线。
为什么要用？
当一个问题存在多种可能解法，且中途走错一步就难以修正时，线性 Prompt 往往不稳定，适合使用 ToT
三种典型适用情况
第一种：需要探索解空间的问题 例如数学推理、谜题、规划类任务。 这些问题不存在显然的第一步，ToT 允许模型同时尝试多条路径，再逐步淘汰不可能的分支。
第二种：中间步骤可判断对错的问题 当部分思路可以被标记为“可行 / 不可行 / 未确定”时，ToT 能提前剪枝，避免无效推理继续扩散。
第三种：需要回退或比较方案的问题 例如策略制定、复杂决策分析。 ToT 让模型显式保留多个候选方案，而不是在生成后期才发现方向错误却无法回头。
怎么用？
错误的一句话问法：
请一步步思考，算出这四个数如何通过加减乘除得到 24。
这个问法把路径选择、推理展开和结果确认混在一次生成中。模型一旦早期选错组合方式，后续推理就会被错误方向牵着走，难以修正。
最小可行的改进方案：
步骤一：生成多个候选思路
给定数字 3, 3, 8, 8。
请列出 5 种不同的中间计算思路，每种只写第一步，不要继续计算。
步骤二：评估每个思路的可行性
对于上面的每个思路，判断它是否“可能 / 不太可能 / 不可能”得到 24，并给出一句理由。
步骤三：只保留可行思路继续展开
从被标为“可能”的思路中选择一个，继续下一步计算。
最小通用模板
【任务说明】
这里描述最终要解决的问题：{最终目标}
【步骤一：生成候选思路】
请给出 {N} 个不同的中间思路。
每个思路只写当前一步，不要给出完整答案。
【步骤二：评估思路】
请分别评估每个思路是否可行（如：可行 / 不确定 / 不可行），并给出简短理由。
【步骤三：继续推进】
仅从被判定为可行的思路中选择一个，继续下一步。
- ReAct Prompting（Reason + Act）
ReAct Prompting 是一种把**想问题（Reasoning）和动手查信息（Action）**交替进行的提示方法。 它要解决的核心问题很简单：模型训练用的是过去的数据，并不了解最新或具体的现实情况，如果只让它靠“脑补”去想，很容易在信息不够的时候给出不准甚至编出来的答案。 ReAct 的做法是，让模型在一次任务中不断循环 “先想清楚要查什么 → 再去查 → 看查到的结果 → 再继续想”。
这就像你要去一家从没去过的餐厅。 你先想大概在哪个区域（推理），然后打开地图搜索（行动），看到评分和路线（观察），再决定走哪条路（再推理）。这里的地图和搜索结果，就是 ReAct 里的“外部信息”。
在真实系统里，ReAct 的价值在于：它不要求模型一开始就给答案，而是允许它边查边想。这样可以避免模型在不知道事实时硬编理由，让每一步判断都有依据，也方便人类回头检查中间过程。
为什么要用？
模型一次输出是线性的。如果它一开始就奔着“最终答案”去，很容易为了凑结论而扭曲前面的思路。ReAct 通过强制插入“去查一下再说”的步骤，把想和查分开，降低瞎猜的概率
三种最常见、最适合用 ReAct 的情况：
第一，查资料型问题（跨多个事实来源）。 例子：你问“ReAct 是哪篇论文提出的？作者是谁？论文是哪一年发的？” 如果不查，模型可能把作者、年份记错，或者把类似方法搞混。 用 ReAct 的做法是：先分别去查“ReAct 论文”“作者列表”“发布日期/年份”，拿到结果后再拼成最终答案。
第二，需要一步步决策的任务（每一步都依赖反馈）。 例子：你要模型帮你“用 LangChain 配一个 ReAct Agent 跑起来，并且能调用搜索 + 计算工具”。 如果模型一次性给完整方案，很容易漏掉关键步骤（比如环境变量没配、工具名不对、版本差异导致代码跑不起来）。用 ReAct 的做法是：先检查安装与版本 → 再跑最小样例 → 观察报错 → 针对报错修正 → 再运行下一步，直到成功。
第三，要用工具的问题（必须调用外部能力才有答案）。 例子：你问“今天东京的天气怎么样？适合不适合去户外？”或者“把 29 的 0.23 次方算出来”。前者如果不查实时天气，模型只能猜；后者如果不算，模型容易算错。
怎么用？
错误的一句话问法：
帮我判断这个方案是否可行，并给出结论和理由。
这个问法让模型一边下结论，一边编理由。如果它其实不知道关键事实，就很可能先拍脑袋给结果，再反过来找“看起来合理”的解释。
更稳的改法（ReAct 思路）： 第一步，只让模型说清楚需要哪些信息。 第二步，让它去查这些信息。 第三步，再基于查到的结果下结论。
你将按下面步骤完成任务：
Thought：列出判断这个方案是否可行需要哪些关键信息。
Action：逐条查询或计算这些信息。
Observation：记录每次查询或计算得到的结果。
Thought：基于这些结果重新判断。
Final：给出最终结论和依据。
最小通用模板
你将通过“想 → 查 → 看结果”的方式完成任务：
Thought：说明现在还缺哪些信息。
Action：执行一次明确的查询、搜索或计算。
Observation：写出这一步得到的结果。
Thought：根据新信息更新判断。
当信息足够时：
Final：输出最终答案。
- Reflexion（自我反思式强化）
Reflexion 就是让模型在每次做完事之后，用一句话总结哪里做错了、下次该怎么改，再带着这句话继续下一次。它不改模型参数（不训练模型），而是把 失败经验 → 写成文字 → 存进记忆 → 下次当上下文用。
像人做题后写一句复盘笔记：这题为什么错，下次注意什么；模型也是把这句“提醒”当作记忆继续用。它的作用不是让模型更聪明，而是让模型少重复犯同一个错，让多次尝试能真正往正确方向收敛。
最常见的三种情况
例子：写代码通过测试 你让模型写函数，通过一个测试集。第一次失败后，如果只是“再试一次”，模型通常会整体重写，错误点不固定。 用 Reflexion 时，模型会先说清楚：是边界条件没处理，还是逻辑顺序错了，再针对这个点改。
错误提问
写一个 JavaScript 函数，判断一个字符串是不是回文，不对就再改，直到正确。
正确提问（使用 Reflexion）
任务：
写一个 JavaScript 函数，判断一个字符串是不是回文。
第一步：执行
直接给出函数代码。
第二步：检查
这个实现在哪些情况下会判断错误？用 1–2 句话说明。
第三步：提醒
总结一句“下次实现时必须注意的点”。
第四步：重来
在遵守这句提醒的前提下，重新写函数。
- PAL (Program-Aided Language Models) （程序辅助语言模型）
什么是PAL PAL 是一种做法：让模型先写一段能跑的代码，再用代码算出答案，而不是让模型直接“想”答案。它解决的是：模型在算数、日期、规则这类问题上，光靠嘴说很容易算错。目标很简单——把容易出错的计算交给程序来做。
这就像做数学题时，不在脑子里心算，而是先把公式写进计算器。
- 题目 → 模型看懂
- 算法 → 模型写代码
- 结果 → 计算器给
在系统里，PAL 让关键步骤变成可运行的代码，结果能复查、能复现，不靠“感觉对不对”。
为什么要用 大模型生成的是下一个最像人话的词，不是真正在做加减、日期推进或规则执行。结果看起来对，只是“像对”，不是“算对”。凡是必须算准、必须能检查的问题，就不该让模型靠“写文字”完成最后一步。
三种常见场景
场景一：算数 / 日期类问题
错误方式：
今天是 2023-02-27，我 25 年前出生，生日是哪天？
模型一边理解时间，一边自己算日期，容易算偏，你也看不到它怎么算的。
改进方式（PAL）：
不要直接给答案。
请用 Python 代码计算：
今天是 2023-02-27，往前推 25 年，输出日期，格式 MM/DD/YYYY。
场景二：规则多、条件多的判断
错误方式：
根据下面的规则，判断这个用户能不能退款，并说明原因。
规则多的时候，模型容易漏条件，理由听着对，但不一定真符合规则。
改进方式（PAL）：
不要直接判断。
请用代码实现退款规则判断逻辑，
输入为用户信息，最后输出 true 或 false。
场景三：需要结果可核对的问题
错误方式：
统计下面日志中，每个用户的访问次数。
模型可能“看着像统计过”，但你无法确认它有没有真算全。
改进方式（PAL）：
不要直接给统计结果。
请写一段代码：
读取下面的日志数据，统计每个用户的访问次数，并输出结果。
三、LLM 系统模式层（Prompting as Interface）
- Retrieval Augmented Generation (RAG)
RAG 是一种做法：先查资料，再让模型根据查到的资料回答问题，而不是让它靠记忆乱答。就像做开卷考试：题目是你的问题，查书是检索，看着书写答案是生成
在系统里，RAG 的本质是：答案来源由你给的资料决定，而不是模型自己发挥。
为什么要用？ 模型不知道事实时，也会硬编一个听起来像真的答案。
三种最常见的情况
场景一：规则经常变、以最新为准
错误方式：
现在会员升级需要满足什么条件？
模型可能按旧规则回答，语气很肯定，但信息已经过期。
改进方式（RAG）：
以下是当前生效的会员规则内容：
{{latest_rules}}
请根据这些规则，说明会员升级条件。
- RAG和GKP的工作方式本质差异：
- RAG：Question → 检索真实文档 → 拼接上下文 → 生成答案→ 关键在 external grounding（外部事实锚定）
- GKP：Question → 让模型先生成“相关知识列表/解释” → 再回答→ 关键在 cognitive scaffolding（思维支架）GKP 不是“学新知识”，而是“把模型已经学过的知识先显式生成出来”。
- Automatic Reasoning and Tool-use (ART)
ART 是一种让模型一边想、一边在需要的地方用工具的方法，而不是一次性凭感觉给答案。
像做作业时可以随时用计算器或查资料。把“想”和“做”分开，哪一步要算、要查都说清楚，结果更稳，也更好改。
为什么要用？ 模型遇到复杂问题时，常常不查、不算，直接编结论，ART 用流程把它拦住。模型一旦被要求“直接给结论”，就容易先编答案，再补理由。
三种最常见的情况
场景一：必须算准的问题（时间 / 数量 / 金额）
错误方式：
现在是东京时间 9:40，纽约现在几点？
模型可能直接凭印象给时间，时区、夏令时容易错，但看起来“像真的”。
改进方式（ART）：
请一步步完成：
1. 确认东京和纽约的时区
2. 判断是否有夏令时
3. 计算时间差
4. 给出最终时间
不让模型直接猜结果，而是强制先查、再算、最后说答案。
场景二：多步骤决策 / 规划问题
错误方式：
帮我规划一个三天东京自由行，直接给最终行程。
行程看着合理，但可能出现：路线绕、时间冲突、景点关门等问题。
改进方式（ART）：
请按步骤来：
1. 列出每天可用时间
2. 查每个景点的开放时间和区域
3. 按区域分组安排
4. 最后生成三天行程
先把限制条件和步骤想清楚，再生成结果，不容易走偏。
场景三：需要外部信息才能判断的问题
错误方式：
这个 API 方案是否可行？直接给结论。
模型会在不知道真实接口限制的情况下，直接给“看起来专业”的判断。
改进方式（ART）：
请按步骤判断：
1. 明确这个方案依赖哪些外部条件
2. 分别查清这些条件是否满足
3. 基于查到的信息再判断是否可行
先拆步骤 → 该查就查 → 再给结论
- Active-Prompt（主动提示）
Active-Prompt 就是一种做法：先看模型在哪些问题上最拿不准，再只给这些问题补示例，让结果慢慢变稳。
同一个问题问模型好几次，如果答案差很多，说明它其实不懂；那就只挑这些题来补讲解，而不是每题都讲。它不是一开始就把示例写死，而是根据模型哪里容易出错，动态补示例，让系统不靠运气。
场景一：同一个问题，多问几次结果都不一样
错误方式：
请给出下面问题的最终结论，并说明理由。
模型会先给一个结论，再顺着结论编理由，每次编法都不一样。
改进方式（Active-Prompt）
请对下面的问题分别给出 3 个独立答案，不要解释。
问题：
{question}
请指出这些答案哪里不一致。
先看答案分不分叉，再决定要不要补示例，而不是一上来就信结果。
Active-Prompt 不是教你“怎么问模型”，而是教你“怎么把一个会乱答的系统慢慢调稳”。它更接近系统训练流程的一部分，而不是用户层的提示技巧。
- Automatic Prompt Engineer (APE)
APE 就是：不靠人瞎改 Prompt，而是让模型自己多写几种 Prompt，跑一遍，看哪种效果最好。
如果你发现：只改一句 Prompt，结果就忽好忽坏，而且说不清原因，就该用 APE。可以用于自己测出最佳prompt。不改模型参数，只是怎么跟模型说话。
最小通用模板（一步步问）
第一步：只让它生成 Prompt
为下面这个任务生成 5 条不同说法的 Prompt，不要执行任务。
任务：
【在这里写你的任务】
第二步：逐条或批量执行 Prompt
使用下面这条 Prompt，完成同一个输入。
Prompt：
【第 1 条 Prompt】
输入：
【同一个输入】
第三步：只做对比和选择
下面是同一输入在不同 Prompt 下的结果。
请根据【评价标准】选出效果最好的一条，并说明原因。
评价标准：
- 是否覆盖关键信息
- 是否跑题
- 是否稳定