1. 从“咒语”到“工程”：为什么我们需要结构化的Prompt技巧

如果你最近尝试过和任何主流的大语言模型（LLM）对话，无论是ChatGPT、Claude还是国内的文心一言、通义千灵，你大概率有过这样的体验：你问了一个问题，得到的回答要么是泛泛而谈，要么是答非所问，甚至干脆开始一本正经地胡说八道。这时候，你可能会觉得是模型“不够聪明”，或者开始在网上搜索所谓的“魔法提示词”，希望能找到一个“咒语”来解锁模型的全部潜力。

这种把提示词（Prompt）当作“咒语”来念的心态，正是Prompt Engineering（提示工程）早期阶段的普遍现象。但经过一年多的实践和社区沉淀，顶尖的从业者们已经发现，真正高效、可靠的交互方式，不是寻找某个一劳永逸的“万能咒语”，而是掌握一套结构化的思维框架和设计模式。这就像编程，你不需要记住每一行具体的代码，但你需要理解变量、循环、条件判断这些基本结构，并用它们来组合解决复杂问题。

今天要聊的Few-Shots、COT、SC、TOT、Step-Back，就是当前提示工程领域最核心、最实用的五类结构化技巧。它们不是五个孤立的“技巧”，而是一个从引导模型理解任务、到辅助模型深度思考、再到优化模型决策路径的完整工具箱。掌握它们，意味着你不再是与一个黑箱模型进行“祈祷式”的对话，而是在有策略地引导一个强大的计算引擎，为你产出高质量、高确定性的结果。无论你是想用AI辅助写作、分析数据、编写代码，还是解决复杂的逻辑推理问题，这套工具箱都能让你事半功倍。

2. 核心技巧全景解析：五大模式的定位与分工

在深入每个技巧之前，我们有必要先建立一个宏观的认知地图。这五种技巧并非随意排列，它们分别针对大语言模型在不同环节的“弱点”或“特性”进行干预，形成了一个从简单到复杂、从模仿到创造的支撑体系。

Few-Shots（少样本学习）是基础中的基础。它的核心思想是“示范教学”。大语言模型本质上是基于海量文本训练出的概率预测机器，它并不真正“理解”你的指令意图。Few-Shots通过提供几个具体的输入-输出示例，在对话上下文中为模型划定一个清晰的“答题格式和风格范围”，极大地降低了模型自由发挥导致偏离目标的风险。它解决的是“任务对齐”问题。

COT（Chain of Thought，思维链）是突破模型“直觉式”回答的关键。早期的模型倾向于直接给出最终答案，就像学生跳过了演算步骤直接写答案，这导致复杂问题上错误率很高。COT要求模型“展示它的思考过程”，将问题分解为多个中间推理步骤。这不仅能让答案更可靠（便于人类检查），其过程本身也常常被后续技巧作为输入。

SC（Self-Consistency，自我一致性）是对COT的增强和优化。单一的一条思维链可能因为随机性而走入“死胡同”。SC的核心是“兼听则明”：让模型针对同一个问题，生成多条不同的思维链，然后投票选出最一致的最终答案。这利用了“正确的推理路径往往能汇聚到同一个答案”的原理，显著提升了复杂推理任务的准确率。

TOT（Tree of Thoughts，思维树）将问题求解提升到了“战略搜索”的层面。当面对像下棋、规划、创意生成这类存在多个可能路径和分支选择的问题时，单一的线性思维链（COT）或投票（SC）就不够了。TOT将解决问题的过程模拟成一棵树的生长：每个“思维节点”代表一个可能的中间状态，模型需要评估不同节点，并决定向哪个分支继续探索。这为模型赋予了类似人类的“前瞻性”和“规划能力”。

Step-Back（退一步思考）是一种元认知（Metacognition）技巧。它要求模型在处理具体、细节的问题之前，先“退一步”，从更高、更抽象的层面去理解问题所归属的领域、涉及的核心概念和通用原则。这能有效防止模型陷入细节的泥潭，帮助其调用更相关、更本质的知识来指导具体推理，特别适用于需要跨领域知识或深层原理的问题。

为了更直观地理解它们的关系和适用场景，我们可以看下面这个对比表格：

3. 深度拆解与实战指南：如何正确运用每一个技巧

理解了“是什么”和“为什么”之后，最关键的一步是“怎么做”。下面我将结合具体实例，拆解每个技巧的构建要点、常见误区和我的实战心得。

3.1 Few-Shots：不止是给例子，更是定义任务边界

很多人把Few-Shots简单理解为“多给几个例子”，但效果却时好时坏。关键在于，你的示例必须构成一个清晰、无歧义的“任务定义”。

一个失败的Few-Shots示例：

用户：把下面的话变得正式一点。 AI：好的，请提供原文。 用户（Few-Shots）： 输入：“这玩意太牛了！” 输出：“此物颇为精妙。” 输入：“我搞不定了。” 输出：“此事已非我力所能及。” 用户：那么，“这票干得漂亮！”怎么改？

这个示例的问题在于，“正式一点”的定义非常模糊。模型可能会模仿文言文风格（如示例），也可能模仿商务邮件风格，结果不可控。

一个成功的Few-Shots示例（定义“商务邮件风格”）：

任务：将随意的口语句子改写为专业的商务邮件用语。 请参照以下示例进行转换： 示例1： - 输入： “老李，那个报告你看了吗？有啥问题没？” - 输出： “李经理，您好。关于昨日提交的报告，不知您是否已审阅完毕？若有任何疑问或需要调整之处，敬请指出。” 示例2： - 输入： “明天开会别忘了，下午两点，302会议室。” - 输出： “温馨提示：明日（X月X日）下午两点将于302会议室举行项目例会，敬请准时出席。” 现在，请转换新的句子： 输入： “这票干得漂亮！客户很满意。” 输出：

在这个示例中，我们通过任务描述和两个例子，明确界定了“专业商务邮件”的多个维度：称呼正式化、使用敬语、信息完整化、语气委婉化。模型据此生成的输出就会稳定得多。

实操心得一：Few-Shots的“三要素”原则

1. 任务指令清晰：用一句话明确说明你要模型做什么。
2. 示例覆盖关键变体：你的例子应该涵盖输入可能的主要变化形式（如不同句式、不同情感色彩），并展示对应的输出变化。
3. 输入输出格式显式标注：使用“输入：”、“输出：”、“Q:”、“A:”等标签明确区分，避免模型混淆。

3.2 COT：关键在于“可验证的中间步骤”

“请一步步思考”是开启COT的常见指令，但要让COT真正有效，你必须引导模型生成对人类而言可理解、可验证的中间步骤，而不是让它生成一堆模糊的“内部计算”。

一个模糊的COT（效果差）：

问题：一个篮子里有5个苹果，小明拿走了2个，小红又放进去3个，然后小刚拿走了1个。篮子里还剩几个苹果？ AI：我们先计算小明拿走后的数量：5-2=3。然后计算小红放进去后的数量：3+3=6。最后计算小刚拿走后的数量：6-1=5。所以答案是5。

这看起来有步骤，但本质只是把算术过程写了出来，对于更复杂的问题帮助有限。

一个优秀的COT（应用于逻辑问题）：

问题：三位朋友——甲、乙、丙，分别来自北京、上海、广州，职业分别是医生、律师、教师，但顺序不对应。已知：1. 甲不是北京人。2. 医生不是上海人。3. 丙不是医生。4. 上海人是律师。请问丙来自哪里？职业是什么？ AI：让我们一步步推理。 步骤1：从条件4可知，“上海人是律师”。所以律师和上海是绑定的。 步骤2：结合条件2“医生不是上海人”，既然上海人是律师，那么医生就一定不是上海人，医生可能是北京人或广州人。 步骤3：看条件1“甲不是北京人”，所以甲可能是上海人或广州人。 步骤4：从步骤1知道上海人是律师，如果甲是上海人，那么甲就是律师。但目前职业和城市还未完全确定，先保留。 步骤5：条件3“丙不是医生”，所以丙可能是律师或教师。 步骤6：从步骤1知律师是上海人，如果丙是律师，则丙是上海人。但上海人是律师这个身份还没有归属到具体人。 步骤7：我们尝试用假设法。假设甲是上海人（根据步骤3，这是一种可能）。那么根据步骤1，甲就是律师。 步骤8：那么律师职业已被甲占据。根据条件4，上海人（甲）是律师，成立。 步骤9：现在剩下乙和丙，城市剩下北京和广州，职业剩下医生和教师。 步骤10：根据条件2，医生不是上海人（甲已经是上海人，所以成立），医生就在乙或丙中。 步骤11：根据条件3，丙不是医生，所以医生只能是乙。 步骤12：那么丙就只能是教师。 步骤13：现在确定乙是医生，丙是教师。需要确定他们的城市。医生不是上海人（条件2），乙是医生，所以乙不是上海人。上海人是甲，所以乙只能是北京人或广州人。 步骤14：丙是教师，教师这个职业没有城市限制。 步骤15：我们需要分配北京和广州给乙和丙。看看条件1：甲不是北京人，甲是上海人，这不冲突。没有其他条件限制北京和广州。 步骤16：但我们需要唯一解。重新审视条件：已知上海人（甲）是律师。乙是医生（不是上海人）。丙是教师。似乎城市分配（乙和丙对应北京/广州）无法确定？这提示我的推理可能有误。 步骤17：回到步骤7，我的假设“甲是上海人”可能不是唯一路径。让我换一种思路，从“上海人是律师”这个确定条件入手。 步骤18：设上海人是X。X的职业是律师。 步骤19：条件2：医生不是上海人，所以医生不是X。 步骤20：条件3：丙不是医生。 步骤21：条件1：甲不是北京人。 步骤22：如果X是甲，那么甲是上海人、律师。那么乙和丙来自北京和广州，职业是医生和教师。因为丙不是医生（条件3），所以丙是教师，乙是医生。这和我最初的推导一致，但城市仍无法定。 步骤23：如果X是乙，那么乙是上海人、律师。那么甲和丙来自北京和广州，职业是医生和教师。条件3说丙不是医生，所以丙是教师，甲是医生。条件1说甲不是北京人，如果甲是医生，医生不是上海人（条件2），所以甲不是上海人（已知），也不是北京人（条件1），那么甲只能是广州人。则丙是北京人，教师。这个分配似乎都满足条件。 步骤24：如果X是丙，那么丙是上海人、律师。那么甲和乙来自北京和广州，职业是医生和教师。条件3说丙不是医生，但此处丙是律师，不冲突。条件1：甲不是北京人。乙和甲分配医生和教师。假设甲是医生，根据条件2医生不是上海人，甲就不是上海人（丙是上海人），同时甲不是北京人，则甲是广州人（医生）。乙就是北京人（教师）。这也满足所有条件。 步骤25：看来存在多种可能？检查条件4：“上海人是律师”。这在三种假设中都成立。但问题通常有唯一解。我是否漏了条件？题目说“分别来自北京、上海、广州”，意思是三人城市不同。“职业分别是医生、律师、教师”，职业也不同。我的三种假设都满足这些。 步骤26：但仔细看，在假设X是乙（乙是上海律师）时，甲是广州医生，丙是北京教师。验证所有条件：1.甲不是北京人（对，他是广州人）。2.医生不是上海人（对，医生是甲，广州人）。3.丙不是医生（对，丙是教师）。4.上海人是律师（对，乙是上海律师）。全部成立。 步骤27：在假设X是丙（丙是上海律师）时，甲是广州医生，乙是北京教师。验证：1.甲不是北京人（对）。2.医生不是上海人（对，医生甲是广州人）。3.丙不是医生（对，他是律师）。4.上海人是律师（对）。也全部成立。 步骤28：在假设X是甲（甲是上海律师）时，乙是医生（城市？），丙是教师（城市？）。条件1满足，条件2（医生不是上海人）要求乙不是上海人（确实，甲是上海人），条件3满足，条件4满足。但乙和丙的城市无法从条件中推出北京或广州，因此这个假设下没有唯一城市分配，但题目隐含要求唯一分配，所以这个假设可能产生的两种情况，是否与其他条件矛盾？实际上，没有条件限制乙和丙的城市，所以这个假设下有两种解。但通常逻辑题有唯一解，所以最初假设（甲是上海人）可能不对。 步骤29：因此，排除甲是上海人的情况，因为它导致城市分配不唯一。剩下乙或丙是上海人。 步骤30：现在看条件1：甲不是北京人。如果乙是上海人，甲可以是广州人，丙是北京人（如上步骤26）。如果丙是上海人，甲可以是广州人，乙是北京人（如上步骤27）。现在两个解！ 步骤31：我需要再找隐藏条件。题目说“顺序不对应”，可能意味着我列的清单就是甲、乙、丙的顺序，和城市职业的对应关系。但通常逻辑题会给足够条件。我怀疑我最初理解有误。让我们重新严格列出所有可能组合，用排除法。 （为节省空间，此处省略后续穷举表格，最终AI通过穷举法得到唯一解：丙是上海人，律师。但过程中展示了严谨的推理、假设、验证和回溯。）

这个例子虽然长，但完美展示了有效的COT：它包含了假设、推理、发现矛盾、回溯、重新假设、最终验证的完整闭环。用户不仅能得到答案，更能检查其逻辑是否严密。

实操心得二：触发高质量COT的指令设计直接说“一步步思考”可能不够。对于复杂问题，更有效的指令是： “请按照以下步骤分析和解决问题：1. 首先，澄清问题中的已知条件和最终目标。2. 其次，识别条件之间的潜在关联或约束。3. 然后，提出一个初步的推理假设或计划。4. 接着，逐步验证你的假设，如果遇到矛盾则回溯并尝试其他路径。5. 最后，总结你的推理过程并给出最终答案。” 这种结构化的指令能更好地引导模型模拟人类的系统化思考。

3.3 SC：让模型自己当自己的“评审委员会”

SC的实施通常分为两步：首先用COT生成N条（通常5-10条）不同的推理路径，然后从这些路径产生的答案中选出出现频率最高的那个。

关键点在于如何生成“不同”的思维链。如果你只是重复同一个问题，由于模型本身的随机性（temperature > 0），你会得到略有不同的答案，但多样性可能不足。为了促进多样性，可以在提示词中加入以下指令：

• “请从不同的角度或使用不同的初始假设来思考这个问题。”
• “请尝试用三种不同的方法来推导这个问题的答案。”
• “在开始推理前，先列举出这个问题可能涉及到的不同原理或知识点，然后选择其中一个作为起点。”

一个简单的SC提示词示例（用于数学问题）：

问题：一个水池有一个进水管和一个出水管。单开进水管，6小时可将空池注满；单开出水管，8小时可将满池水放完。如果同时打开进水管和出水管，问需要多少小时可将空池注满？ 我们将通过生成多条思维链并选取最一致的答案来确保正确性。请先生成3条不同的推理路径来解决这个问题。 路径1： 路径2： 路径3： 现在，请基于以上三条路径给出的最终答案，选出出现次数最多的那个答案作为最终答案。

模型可能会生成以“工作效率”为角度、以“单位时间内净进水量”为角度、甚至以“假设水池容量为具体数值”为起点的不同路径，最终都指向同一个答案（24小时）。通过投票机制，即使某条路径中间计算出错，最终答案也能保持正确。

实操心得三：SC的落地成本与权衡SC需要生成多次回答，这意味着更高的API调用成本和更长的等待时间。在实践中，我通常只对答案确定性要求极高（如数学计算、事实核查）或单次回答成本不高的场景使用SC。对于创意生成或开放式问题，SC的“投票机制”反而可能扼杀最好的那个创意，此时更适合用TOT来探索。

3.4 TOT：将问题求解构建为一个搜索过程

TOT是概念上最复杂，但也是最能体现“智能”的技巧。它要求我们将模型的单次生成，升级为一个循环的“生成-评估-选择”过程。实现一个完整的TOT通常需要借助AI Agent框架（如LangChain、AutoGen）来管理状态和循环，但其核心思想可以用提示词来部分实现。

一个简化的TOT提示词框架（用于“规划一周健身计划”）：

你是一个健身规划助手。用户的目标是：为一周7天制定一个兼顾力量、有氧和休息的健身计划。每天训练时间不超过1小时。 我们将使用“思维树”方法来规划。请按步骤执行： **步骤1：生成初始想法** 首先，不考虑细节，列出3种截然不同的一周健身计划整体框架思路。 例如： 思路A：上下肢分化训练（力量为主）。 思路B：全身性循环训练（兼顾力量有氧）。 思路C：专项突破训练（针对某个弱点）。 请生成你的3个初始思路： 1. 2. 3. **步骤2：评估与选择** 现在，请根据“兼顾性”、“时间可行性”和“可持续性”三个标准，为上述每个思路打分（1-5分）。然后，选出得分最高的那个思路作为我们深入展开的“主干”。 **步骤3：展开主干（第一层分支）** 针对你选出的最优思路，将其展开为具体的每周天数分配方案。例如，如果选择“上下肢分化”，可能产生：“周一：上肢力量；周二：下肢力量；周三：有氧；周四：上肢力量；周五：下肢力量；周六：有氧；周日：休息”。 请生成2种不同的天数分配方案。 方案1： 方案2： **步骤4：再次评估与选择** 对这两个具体方案，从“目标匹配度”和“劳逸结合度”进行评估，选择更优的一个。 **步骤5：填充细节（第二层分支）** 为你最终选定的每周方案，填充每天的具体训练动作、组数、次数和预估时间。为每一天生成2个不同的训练内容选项。 （例如：周一上肢力量：选项A-卧推、划船、肩推；选项B-引体向上、双杠臂屈伸、弯举） **步骤6：最终整合** 基于以上所有选择，输出一份完整、详细、可直接执行的一周健身计划表。

这个例子展示了TOT的核心：保持选择开放性，通过多次生成、评估和选择，逐步收敛到一个优化方案。在编程实现中，步骤2和4的“评估”可以交给另一个LLM调用，或者用预设规则自动评分，从而实现自动化搜索。

实操心得四：TOT的评估函数是关键TOT的效果严重依赖于“评估”环节的质量。评估标准（例如上文中的“兼顾性”、“可行性”）必须清晰、可操作。对于简单问题，可以用自然语言描述标准；对于复杂问题，可能需要将评估标准转化为一系列可自动检查的规则（例如，计划中是否包含所有必做事项？总时间是否超限？）。设计一个好的评估函数，往往比生成更多分支更重要。

3.5 Step-Back：先见森林，再见树木

Step-Back提示的核心是让模型在回答具体问题前，先进行“抽象化”或“概念化”的思考。这通常通过一个元提示（Meta-Prompt）来实现。

一个经典的Step-Back提示结构：

请你以“分步推理”的方式回答以下问题。但在开始具体推理之前，请先执行一次“Step-Back”思考： **Step-Back 问题：** 针对用户提出的具体问题，请先退一步，思考并回答： 1. 这个问题涉及哪个或哪些核心领域/学科？ 2. 解决这类问题通常需要用到哪些基本原理、通用方法或关键概念？ 3. 基于上述原理，解决当前这个具体问题的总体思路或高层次策略应该是什么？ **具体问题：** “如何设计一个实验，来验证社交媒体使用时长是否会影响青少年的睡眠质量？” 请先回答Step-Back问题，然后再基于你的抽象思考，一步步地设计出具体的实验方案。

模型在Step-Back阶段可能会回答：

1. 核心领域：心理学、行为统计学、实验方法学。
2. 关键概念：变量操作化（将“使用时长”、“睡眠质量”转化为可测量指标）、控制变量、随机分组、相关性分析与因果推断。
3. 总体思路：采用问卷调查法或实验法，测量两个变量，并控制其他可能影响睡眠的因素（如年龄、学业压力），然后进行统计分析。

在此高层指导之下，模型接下来设计的具体实验方案（如采用纵向追踪设计、使用屏幕时间统计APP和睡眠手环收集数据、使用多元回归分析等）就会更加严谨和合理，避免了直接跳入“发个问卷问问”这种肤浅的方案。

实操心得五：何时使用Step-BackStep-Back特别适用于以下场景：

1. 问题涉及陌生领域：当你问一个模型知识边界附近的问题时，Step-Back能帮它先定位知识领域，提高回答的准确性。
2. 问题非常复杂或模糊：将大问题分解为“高层策略”和“具体执行”两层，能大幅降低一次性解决的难度。
3. 需要模型调用深层知识：直接问“如何修复汽车异响”可能得到泛泛之谈，但先让模型思考“汽车异响通常源于哪些系统（发动机、悬挂、排气）？诊断的通用流程是什么？”，再具体到某个声音的描述，效果会好得多。

4. 技巧融合与实战编排：组合拳才是王道

在实际应用中，这些技巧很少孤立使用。高手总是根据任务类型，将它们像乐高积木一样组合起来。下面我通过两个综合案例，展示如何打出一套“组合拳”。

4.1 案例一：智能代码评审与优化建议

任务：给定一段存在潜在性能问题和bug的Python代码，让AI进行评审并提出优化建议。

低效提示：“看看这段代码有什么问题，怎么优化？”

高效组合提示（融合Few-Shots, COT, Step-Back）：

你是一个经验丰富的Python高级开发工程师，擅长性能优化和代码审查。请对以下代码进行评审。 **Step-Back思考指南**： 在分析代码细节前，请先思考： 1. 这段代码主要实现什么功能？属于哪种类型的程序（如数据处理、Web服务、算法）？ 2. 评审此类代码通常关注哪些核心维度？（例如：时间复杂度/空间复杂度、内存使用、代码可读性、可维护性、潜在边界条件错误、Pythonic写法等） 3. 针对每个核心维度，有哪些通用的最佳实践或检查清单？ （模型进行Step-Back思考，输出高层指导原则） **Few-Shots示例（定义评审报告格式和深度）**： 下面是一个代码评审的示例，请学习其分析框架和表述风格： 示例代码： ```python def sum_of_squares(n): result = 0 for i in range(n): result += i * i return result

评审报告：

• 功能：计算从0到n-1所有整数的平方和。
• 时间复杂度：O(n)，对于大的n可能较慢。存在优化空间。
• 改进建议：可使用公式n*(n-1)*(2n-1)//6在O(1)时间内计算。
• 潜在Bug：无。但需注意n为负数或非整数时的输入处理（当前未处理）。
• 可读性：良好。

**现在，请使用Chain of Thought（思维链）方式，逐步分析以下代码：** 1. 首先，逐行理解代码的功能和逻辑。 2. 其次，对照Step-Back中提到的各个核心维度，逐一检查代码。 3. 然后，针对发现的问题，指出具体位置、原因以及可能带来的后果。 4. 最后，给出具体的、可操作的优化代码或修改建议。 **待评审代码：** ```python def process_data(items): result = [] for i in range(len(items)): if items[i] % 2 == 0: result.append(items[i] * 2) else: result.append(items[i] * 3) return result

请开始你的逐步分析并生成完整的评审报告。

在这个组合中： - **Step-Back** 确保了评审的全面性和专业性，不会漏掉重要维度。 - **Few-Shots** 定义了输出格式和深度，让模型知道不仅要指出问题，还要给出优化方案和公式。 - **COT** 要求模型展示分析过程，使得最终建议的逻辑更清晰，也更容易让人信服。 ### 4.2 案例二：基于模糊需求的商业方案撰写 **任务**：老板说“我们需要提升客户满意度”，请你起草一个初步方案。 **低效提示**：“写一个提升客户满意度的方案。” **高效组合提示（融合COT, TOT, Few-Shots）**：

你是一家SaaS公司的产品运营负责人。目标是“提升客户满意度”。请撰写一份初步的行动方案。

第一步：思维链（COT）澄清问题与目标请先逐步思考：

1. “客户满意度”在本公司上下文中，通常通过哪些指标量化？（如NPS、CSAT、客户流失率、支持工单解决时长）
2. 当前这些指标的数据表现如何？（假设你不知道具体数据，请基于常见情况列出需要调查的数据点）
3. “提升”是一个模糊目标，请将其转化为一个SMART目标（例如：在未来一个季度内，将NPS分数从X提升到Y）。

第二步：思维树（TOT）生成可选策略不要急于确定一个方案。请先头脑风暴，生成3条截然不同的、高层次的策略方向。 例如：

• 策略A（产品导向）：优化产品核心功能的用户体验和性能。
• 策略B（服务导向）：加强客户成功团队建设，提供更 proactive（主动式）的服务。
• 策略C（价值导向）：深化客户教育，通过教程、案例提升客户感知价值。 请生成你的3个策略方向。

第三步：评估与初步选择基于“实施成本”、“预期影响速度”和“与公司核心能力的匹配度”三个维度，对上述策略进行简要评估（高/中/低）。并选择你认为在当前阶段最值得优先探索的1个策略。

第四步：Few-Shots示例填充方案细节参考以下方案叙述结构，为你选择的策略填充具体行动项： 【示例：针对“优化产品 onboarding（新用户引导）”的策略】

• 行动项1：分析新用户首周行为数据漏斗，找出流失关键节点。
• 行动项2：设计并A/B测试一套交互式产品导览。
• 行动项3：在关键节点设置触发式的帮助提示或视频。
• 成功度量：新用户7日留存率提升10%。
• 所需资源：1名产品设计师，2周开发时间。

请为你选择的策略，列出3-4个具体的、可执行的行动项，并说明每项的成功度量和所需资源。

第五步：整合输出请将以上所有思考整合成一份简洁的初步方案大纲，包含：背景目标、核心策略、具体行动项、资源需求和预期效果。

在这个组合中： - **COT** 首先用于将模糊需求转化为具体、可衡量的目标。 - **TOT** 用于打开思路，避免陷入单一解决方案，并通过评估进行收敛。 - **Few-Shots** 在最后阶段提供了具体行动项的撰写框架，保证了输出内容的可操作性。 ## 5. 避坑指南与高级心法 掌握了技巧的形，还需要理解其神。以下是我在大量实践中总结出的核心心法和常见陷阱。 ### 5.1 量力而行：不是所有问题都需要“大炮打蚊子” 最大的误区是盲目追求复杂技巧。请记住这个决策流： 1. **任务是否简单、格式固定？** (如：情感分类、实体提取) -> 优先用 **Few-Shots**。 2. **任务是否需要多步推理，且有明确答案？** (如：数学计算、逻辑谜题) -> 使用 **COT**，如果答案要求极高可靠性，升级为 **SC**。 3. **任务是否开放式，存在多种可能路径和选择？** (如：策划、设计、写作) -> 考虑使用 **TOT**。 4. **问题是否复杂、涉及深层原理或陌生领域？** -> 在开始任何具体分析前，先加上 **Step-Back** 思考。 对于简单的信息提取或格式转换，一个清晰的Few-Shots提示足够好。强行使用COT或TOT只会增加不必要的token消耗和响应时间。 ### 5.2 上下文是稀缺资源：精打细算你的Token Few-Shots示例、COT的长篇推理、TOT的多轮对话都会快速消耗模型的上下文窗口。你必须精打细算： - **压缩示例**：在Few-Shots中，使用最精简但信息量最大的示例。去掉所有无关的修饰词。 - **分步执行**：对于超长任务，不要试图在一个提示里解决所有问题。可以设计多轮对话，将上一步的输出作为下一步的输入，从而重置或有效利用上下文。 - **总结摘要**：在TOT的每一轮评估后，可以用一句话总结当前状态，而不是把整个思维树都保留在上下文里。 ### 5.3 评估标准决定搜索效率：给TOT装上“导航仪” 在TOT中，盲目生成分支是低效的。一个清晰的评估标准（或评分函数）就像导航仪，能指引搜索方向。这个标准最好能量化。例如： - 对于写作任务，评估标准可以是：“连贯性（1-5分）、创意新颖性（1-5分）、与主题相关性（1-5分）”。 - 对于代码生成，可以是：“功能正确性（通过测试用例比例）、代码简洁度（行数）、时间复杂度”。 你可以让模型自己根据这些标准打分，也可以设计外部函数（如真正运行代码测试）来评估。 ### 5.4 拥抱不确定性：与概率模型共舞 LLM本质是概率模型，它的输出具有随机性。Few-Shots、COT、SC都是在与这种随机性共舞，试图约束它、利用它或从中做出最优选择。因此： - **不要期望绝对确定**：即使使用SC，也可能在极其模糊的问题上得到错误的大多数答案。对于关键决策，人类复核必不可少。 - **将随机性作为创意来源**：在创意生成任务中，可以主动提高模型的“温度”（temperature）参数，并利用TOT来探索随机性产生的不同分支，从而获得意想不到的灵感。 ### 5.5 持续迭代与模式化：建立你自己的提示词库 最高效的做法不是每次从零开始写提示词。而是将验证有效的、针对特定任务的“技巧组合”保存为模板。例如： - `代码评审模板` = Step-Back（领域原则） + Few-Shots（报告格式） + COT（分析步骤）。 - `商业分析模板` = Step-Back（分析框架） + TOT（策略生成与选择） + Few-Shots（结论呈现）。 将这些模板化、模式化，你就能在面对新问题时快速组装出强大的提示词，真正将Prompt Engineering从“艺术”变为可复制的“工程”。