1. 从“咒语”到“工程”为什么我们需要结构化的Prompt技巧如果你最近尝试过和任何主流的大语言模型LLM对话无论是ChatGPT、Claude还是国内的文心一言、通义千灵你大概率有过这样的体验你问了一个问题得到的回答要么是泛泛而谈要么是答非所问甚至干脆开始一本正经地胡说八道。这时候你可能会觉得是模型“不够聪明”或者开始在网上搜索所谓的“魔法提示词”希望能找到一个“咒语”来解锁模型的全部潜力。这种把提示词Prompt当作“咒语”来念的心态正是Prompt Engineering提示工程早期阶段的普遍现象。但经过一年多的实践和社区沉淀顶尖的从业者们已经发现真正高效、可靠的交互方式不是寻找某个一劳永逸的“万能咒语”而是掌握一套结构化的思维框架和设计模式。这就像编程你不需要记住每一行具体的代码但你需要理解变量、循环、条件判断这些基本结构并用它们来组合解决复杂问题。今天要聊的Few-Shots、COT、SC、TOT、Step-Back就是当前提示工程领域最核心、最实用的五类结构化技巧。它们不是五个孤立的“技巧”而是一个从引导模型理解任务、到辅助模型深度思考、再到优化模型决策路径的完整工具箱。掌握它们意味着你不再是与一个黑箱模型进行“祈祷式”的对话而是在有策略地引导一个强大的计算引擎为你产出高质量、高确定性的结果。无论你是想用AI辅助写作、分析数据、编写代码还是解决复杂的逻辑推理问题这套工具箱都能让你事半功倍。2. 核心技巧全景解析五大模式的定位与分工在深入每个技巧之前我们有必要先建立一个宏观的认知地图。这五种技巧并非随意排列它们分别针对大语言模型在不同环节的“弱点”或“特性”进行干预形成了一个从简单到复杂、从模仿到创造的支撑体系。Few-Shots少样本学习是基础中的基础。它的核心思想是“示范教学”。大语言模型本质上是基于海量文本训练出的概率预测机器它并不真正“理解”你的指令意图。Few-Shots通过提供几个具体的输入-输出示例在对话上下文中为模型划定一个清晰的“答题格式和风格范围”极大地降低了模型自由发挥导致偏离目标的风险。它解决的是“任务对齐”问题。COTChain of Thought思维链是突破模型“直觉式”回答的关键。早期的模型倾向于直接给出最终答案就像学生跳过了演算步骤直接写答案这导致复杂问题上错误率很高。COT要求模型“展示它的思考过程”将问题分解为多个中间推理步骤。这不仅能让答案更可靠便于人类检查其过程本身也常常被后续技巧作为输入。SCSelf-Consistency自我一致性是对COT的增强和优化。单一的一条思维链可能因为随机性而走入“死胡同”。SC的核心是“兼听则明”让模型针对同一个问题生成多条不同的思维链然后投票选出最一致的最终答案。这利用了“正确的推理路径往往能汇聚到同一个答案”的原理显著提升了复杂推理任务的准确率。TOTTree of Thoughts思维树将问题求解提升到了“战略搜索”的层面。当面对像下棋、规划、创意生成这类存在多个可能路径和分支选择的问题时单一的线性思维链COT或投票SC就不够了。TOT将解决问题的过程模拟成一棵树的生长每个“思维节点”代表一个可能的中间状态模型需要评估不同节点并决定向哪个分支继续探索。这为模型赋予了类似人类的“前瞻性”和“规划能力”。Step-Back退一步思考是一种元认知Metacognition技巧。它要求模型在处理具体、细节的问题之前先“退一步”从更高、更抽象的层面去理解问题所归属的领域、涉及的核心概念和通用原则。这能有效防止模型陷入细节的泥潭帮助其调用更相关、更本质的知识来指导具体推理特别适用于需要跨领域知识或深层原理的问题。为了更直观地理解它们的关系和适用场景我们可以看下面这个对比表格技巧名称核心思想解决的问题类比最佳适用场景Few-Shots示范教学任务格式不明确输出风格不可控给范文、给模板格式化输出JSON、表格、特定风格写作、简单分类COT分步推导复杂问题直接回答错误率高要求写出计算过程数学题、逻辑推理、多步骤问题解决SC多数决单次推理可能因随机性出错多个专家会诊取共识数学、常识推理、事实核查等有明确答案的问题TOT搜索规划问题存在多个可行路径和分支下棋时的棋路推演游戏策略、创意写作、复杂规划、算法设计Step-Back抽象提炼陷入细节缺乏高层指导先看地图再找路需要领域知识的问答、概念解释、原理性分析3. 深度拆解与实战指南如何正确运用每一个技巧理解了“是什么”和“为什么”之后最关键的一步是“怎么做”。下面我将结合具体实例拆解每个技巧的构建要点、常见误区和我的实战心得。3.1 Few-Shots不止是给例子更是定义任务边界很多人把Few-Shots简单理解为“多给几个例子”但效果却时好时坏。关键在于你的示例必须构成一个清晰、无歧义的“任务定义”。一个失败的Few-Shots示例用户把下面的话变得正式一点。 AI好的请提供原文。 用户Few-Shots 输入“这玩意太牛了” 输出“此物颇为精妙。” 输入“我搞不定了。” 输出“此事已非我力所能及。” 用户那么“这票干得漂亮”怎么改这个示例的问题在于“正式一点”的定义非常模糊。模型可能会模仿文言文风格如示例也可能模仿商务邮件风格结果不可控。一个成功的Few-Shots示例定义“商务邮件风格”任务将随意的口语句子改写为专业的商务邮件用语。 请参照以下示例进行转换 示例1 - 输入 “老李那个报告你看了吗有啥问题没” - 输出 “李经理您好。关于昨日提交的报告不知您是否已审阅完毕若有任何疑问或需要调整之处敬请指出。” 示例2 - 输入 “明天开会别忘了下午两点302会议室。” - 输出 “温馨提示明日X月X日下午两点将于302会议室举行项目例会敬请准时出席。” 现在请转换新的句子 输入 “这票干得漂亮客户很满意。” 输出在这个示例中我们通过任务描述和两个例子明确界定了“专业商务邮件”的多个维度称呼正式化、使用敬语、信息完整化、语气委婉化。模型据此生成的输出就会稳定得多。实操心得一Few-Shots的“三要素”原则任务指令清晰用一句话明确说明你要模型做什么。示例覆盖关键变体你的例子应该涵盖输入可能的主要变化形式如不同句式、不同情感色彩并展示对应的输出变化。输入输出格式显式标注使用“输入”、“输出”、“Q:”、“A:”等标签明确区分避免模型混淆。3.2 COT关键在于“可验证的中间步骤”“请一步步思考”是开启COT的常见指令但要让COT真正有效你必须引导模型生成对人类而言可理解、可验证的中间步骤而不是让它生成一堆模糊的“内部计算”。一个模糊的COT效果差问题一个篮子里有5个苹果小明拿走了2个小红又放进去3个然后小刚拿走了1个。篮子里还剩几个苹果 AI我们先计算小明拿走后的数量5-23。然后计算小红放进去后的数量336。最后计算小刚拿走后的数量6-15。所以答案是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阶段可能会回答核心领域心理学、行为统计学、实验方法学。关键概念变量操作化将“使用时长”、“睡眠质量”转化为可测量指标、控制变量、随机分组、相关性分析与因果推断。总体思路采用问卷调查法或实验法测量两个变量并控制其他可能影响睡眠的因素如年龄、学业压力然后进行统计分析。在此高层指导之下模型接下来设计的具体实验方案如采用纵向追踪设计、使用屏幕时间统计APP和睡眠手环收集数据、使用多元回归分析等就会更加严谨和合理避免了直接跳入“发个问卷问问”这种肤浅的方案。实操心得五何时使用Step-BackStep-Back特别适用于以下场景问题涉及陌生领域当你问一个模型知识边界附近的问题时Step-Back能帮它先定位知识领域提高回答的准确性。问题非常复杂或模糊将大问题分解为“高层策略”和“具体执行”两层能大幅降低一次性解决的难度。需要模型调用深层知识直接问“如何修复汽车异响”可能得到泛泛之谈但先让模型思考“汽车异响通常源于哪些系统发动机、悬挂、排气诊断的通用流程是什么”再具体到某个声音的描述效果会好得多。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澄清问题与目标请先逐步思考“客户满意度”在本公司上下文中通常通过哪些指标量化如NPS、CSAT、客户流失率、支持工单解决时长当前这些指标的数据表现如何假设你不知道具体数据请基于常见情况列出需要调查的数据点“提升”是一个模糊目标请将其转化为一个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从“艺术”变为可复制的“工程”。 从咒语到工程：掌握五大结构化Prompt技巧，高效驾驭大语言模型
1. 从“咒语”到“工程”为什么我们需要结构化的Prompt技巧如果你最近尝试过和任何主流的大语言模型LLM对话无论是ChatGPT、Claude还是国内的文心一言、通义千灵你大概率有过这样的体验你问了一个问题得到的回答要么是泛泛而谈要么是答非所问甚至干脆开始一本正经地胡说八道。这时候你可能会觉得是模型“不够聪明”或者开始在网上搜索所谓的“魔法提示词”希望能找到一个“咒语”来解锁模型的全部潜力。这种把提示词Prompt当作“咒语”来念的心态正是Prompt Engineering提示工程早期阶段的普遍现象。但经过一年多的实践和社区沉淀顶尖的从业者们已经发现真正高效、可靠的交互方式不是寻找某个一劳永逸的“万能咒语”而是掌握一套结构化的思维框架和设计模式。这就像编程你不需要记住每一行具体的代码但你需要理解变量、循环、条件判断这些基本结构并用它们来组合解决复杂问题。今天要聊的Few-Shots、COT、SC、TOT、Step-Back就是当前提示工程领域最核心、最实用的五类结构化技巧。它们不是五个孤立的“技巧”而是一个从引导模型理解任务、到辅助模型深度思考、再到优化模型决策路径的完整工具箱。掌握它们意味着你不再是与一个黑箱模型进行“祈祷式”的对话而是在有策略地引导一个强大的计算引擎为你产出高质量、高确定性的结果。无论你是想用AI辅助写作、分析数据、编写代码还是解决复杂的逻辑推理问题这套工具箱都能让你事半功倍。2. 核心技巧全景解析五大模式的定位与分工在深入每个技巧之前我们有必要先建立一个宏观的认知地图。这五种技巧并非随意排列它们分别针对大语言模型在不同环节的“弱点”或“特性”进行干预形成了一个从简单到复杂、从模仿到创造的支撑体系。Few-Shots少样本学习是基础中的基础。它的核心思想是“示范教学”。大语言模型本质上是基于海量文本训练出的概率预测机器它并不真正“理解”你的指令意图。Few-Shots通过提供几个具体的输入-输出示例在对话上下文中为模型划定一个清晰的“答题格式和风格范围”极大地降低了模型自由发挥导致偏离目标的风险。它解决的是“任务对齐”问题。COTChain of Thought思维链是突破模型“直觉式”回答的关键。早期的模型倾向于直接给出最终答案就像学生跳过了演算步骤直接写答案这导致复杂问题上错误率很高。COT要求模型“展示它的思考过程”将问题分解为多个中间推理步骤。这不仅能让答案更可靠便于人类检查其过程本身也常常被后续技巧作为输入。SCSelf-Consistency自我一致性是对COT的增强和优化。单一的一条思维链可能因为随机性而走入“死胡同”。SC的核心是“兼听则明”让模型针对同一个问题生成多条不同的思维链然后投票选出最一致的最终答案。这利用了“正确的推理路径往往能汇聚到同一个答案”的原理显著提升了复杂推理任务的准确率。TOTTree of Thoughts思维树将问题求解提升到了“战略搜索”的层面。当面对像下棋、规划、创意生成这类存在多个可能路径和分支选择的问题时单一的线性思维链COT或投票SC就不够了。TOT将解决问题的过程模拟成一棵树的生长每个“思维节点”代表一个可能的中间状态模型需要评估不同节点并决定向哪个分支继续探索。这为模型赋予了类似人类的“前瞻性”和“规划能力”。Step-Back退一步思考是一种元认知Metacognition技巧。它要求模型在处理具体、细节的问题之前先“退一步”从更高、更抽象的层面去理解问题所归属的领域、涉及的核心概念和通用原则。这能有效防止模型陷入细节的泥潭帮助其调用更相关、更本质的知识来指导具体推理特别适用于需要跨领域知识或深层原理的问题。为了更直观地理解它们的关系和适用场景我们可以看下面这个对比表格技巧名称核心思想解决的问题类比最佳适用场景Few-Shots示范教学任务格式不明确输出风格不可控给范文、给模板格式化输出JSON、表格、特定风格写作、简单分类COT分步推导复杂问题直接回答错误率高要求写出计算过程数学题、逻辑推理、多步骤问题解决SC多数决单次推理可能因随机性出错多个专家会诊取共识数学、常识推理、事实核查等有明确答案的问题TOT搜索规划问题存在多个可行路径和分支下棋时的棋路推演游戏策略、创意写作、复杂规划、算法设计Step-Back抽象提炼陷入细节缺乏高层指导先看地图再找路需要领域知识的问答、概念解释、原理性分析3. 深度拆解与实战指南如何正确运用每一个技巧理解了“是什么”和“为什么”之后最关键的一步是“怎么做”。下面我将结合具体实例拆解每个技巧的构建要点、常见误区和我的实战心得。3.1 Few-Shots不止是给例子更是定义任务边界很多人把Few-Shots简单理解为“多给几个例子”但效果却时好时坏。关键在于你的示例必须构成一个清晰、无歧义的“任务定义”。一个失败的Few-Shots示例用户把下面的话变得正式一点。 AI好的请提供原文。 用户Few-Shots 输入“这玩意太牛了” 输出“此物颇为精妙。” 输入“我搞不定了。” 输出“此事已非我力所能及。” 用户那么“这票干得漂亮”怎么改这个示例的问题在于“正式一点”的定义非常模糊。模型可能会模仿文言文风格如示例也可能模仿商务邮件风格结果不可控。一个成功的Few-Shots示例定义“商务邮件风格”任务将随意的口语句子改写为专业的商务邮件用语。 请参照以下示例进行转换 示例1 - 输入 “老李那个报告你看了吗有啥问题没” - 输出 “李经理您好。关于昨日提交的报告不知您是否已审阅完毕若有任何疑问或需要调整之处敬请指出。” 示例2 - 输入 “明天开会别忘了下午两点302会议室。” - 输出 “温馨提示明日X月X日下午两点将于302会议室举行项目例会敬请准时出席。” 现在请转换新的句子 输入 “这票干得漂亮客户很满意。” 输出在这个示例中我们通过任务描述和两个例子明确界定了“专业商务邮件”的多个维度称呼正式化、使用敬语、信息完整化、语气委婉化。模型据此生成的输出就会稳定得多。实操心得一Few-Shots的“三要素”原则任务指令清晰用一句话明确说明你要模型做什么。示例覆盖关键变体你的例子应该涵盖输入可能的主要变化形式如不同句式、不同情感色彩并展示对应的输出变化。输入输出格式显式标注使用“输入”、“输出”、“Q:”、“A:”等标签明确区分避免模型混淆。3.2 COT关键在于“可验证的中间步骤”“请一步步思考”是开启COT的常见指令但要让COT真正有效你必须引导模型生成对人类而言可理解、可验证的中间步骤而不是让它生成一堆模糊的“内部计算”。一个模糊的COT效果差问题一个篮子里有5个苹果小明拿走了2个小红又放进去3个然后小刚拿走了1个。篮子里还剩几个苹果 AI我们先计算小明拿走后的数量5-23。然后计算小红放进去后的数量336。最后计算小刚拿走后的数量6-15。所以答案是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阶段可能会回答核心领域心理学、行为统计学、实验方法学。关键概念变量操作化将“使用时长”、“睡眠质量”转化为可测量指标、控制变量、随机分组、相关性分析与因果推断。总体思路采用问卷调查法或实验法测量两个变量并控制其他可能影响睡眠的因素如年龄、学业压力然后进行统计分析。在此高层指导之下模型接下来设计的具体实验方案如采用纵向追踪设计、使用屏幕时间统计APP和睡眠手环收集数据、使用多元回归分析等就会更加严谨和合理避免了直接跳入“发个问卷问问”这种肤浅的方案。实操心得五何时使用Step-BackStep-Back特别适用于以下场景问题涉及陌生领域当你问一个模型知识边界附近的问题时Step-Back能帮它先定位知识领域提高回答的准确性。问题非常复杂或模糊将大问题分解为“高层策略”和“具体执行”两层能大幅降低一次性解决的难度。需要模型调用深层知识直接问“如何修复汽车异响”可能得到泛泛之谈但先让模型思考“汽车异响通常源于哪些系统发动机、悬挂、排气诊断的通用流程是什么”再具体到某个声音的描述效果会好得多。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澄清问题与目标请先逐步思考“客户满意度”在本公司上下文中通常通过哪些指标量化如NPS、CSAT、客户流失率、支持工单解决时长当前这些指标的数据表现如何假设你不知道具体数据请基于常见情况列出需要调查的数据点“提升”是一个模糊目标请将其转化为一个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从“艺术”变为可复制的“工程”。