链载Ai

标题: 撒娇、威胁对大模型都没用？顶级科研团队2000次实验，14种常用prompt技巧谁是强神谁是狼！撬动大模型能力杠杆，秘诀都在这了 [打印本页]

作者: 链载Ai 时间: 昨天 18:35
标题: 撒娇、威胁对大模型都没用？顶级科研团队2000次实验，14种常用prompt技巧谁是强神谁是狼！撬动大模型能力杠杆，秘诀都在这了

大型语言模型（LLMs）的飞速发展，在代码翻译、提交信息生成、程序修复等软件工程任务中展现出令人惊叹的能力。相信各位AI的同好们也有很强的体感，仅仅是提示词上的微小变化，就可能导致LLM的输出质量千差万别，这也是大家为什么总说和AI交互像是在“抽盲盒”。

所以，“提示工程”（Prompt Engineering）至关重要，这时候我们人类强大的大脑又会开始不自觉的追求最佳实践了（本质还是大脑懒得思考）：面对琳琅满目的提示工程技术，哪一种才是特定软件工程任务中的最佳选择？

面对这个还没有标准答案的挑战，来自巴西巴伊亚联邦大学、伯南布哥联邦乡村大学以及美国加州大学尔湾分校的研究团队，进行了一项开创性的系统性评估—《Which Prompting Technique Should I Use? An Empirical Investigation of Prompting Techniques for Software Engineering Tasks》。

研究团队通过花了大量时间和计算资源，调研了58种，整理了46种，最终筛选测试了14种主流提示技术在10个软件工程任务上的表现，用了4个主流LLM模型（DeepSeek-V3、Qwen2.5-Coder-32B-Instruct、Llama3.3-70B-Instruct和OpenAI o3-mini四个模型），总共跑了2000多次实验。告诉我们“用什么”，更揭示了“为什么”和“如何用”的深层奥秘。

反正本人是真的几度被《如何让大模型听懂我的人话》这个课题搞疯了，非常无比的需要这些行之有效的提示词玩法，如果各位AI的同好们也有需要，走，往下看。

参与pk的14种核心提示工程技术

研究团队精心挑选了14种提示工程技术，涵盖了六大核心维度：零样本（Zero-Shot）、少样本（Few-Shot）、思维生成（Thought Generation）、集成（Ensembling）、自我批评（Self-Criticism）和分解（Decomposition）。这些技术在代码生成、Bug修复、面向代码问答等广泛任务中接受了全面检验，参赛选手如下：

ES-KNN (Exemplar Selection KNN)：找好例子给模型看

核心思路：ES-KNN，即“示例选择K近邻”，其核心在于为当前任务样本找到最相似的“学霸作业”，然后一同提供给大模型。
具体实现：研究者将所有代码样本（非当前查询）转化为向量嵌入（采用专门训练过的多语言代码嵌入模型），然后通过计算余弦相似度，找出top-k个语义最相似的样本作为上下文示例（Few-shot）。
实践表现：ES-KNN在克隆检测、代码翻译和断言生成等任务中表现出卓越的性能，几乎在所有主流LLM模型中都位列前茅。这印证了为模型提供高质量、强相关的上下文示例，能够显著提高其理解与生成任务的准确性，就像程序员在编写代码时会参考类似功能的现有代码片段一样，为模型提供了可靠的参考系。

CCoT (Few Shot Contrastive CoT)：对的错的一起学

核心思路：“少样本对比思维链”是一种巧妙的方法。它不仅向模型展示正确的推理步骤和结果，还会提供错误的思路和相应的输出，引导模型学会区分对错，从而完善其推理过程。
实践表现：这种方法在代码调试任务中，CCoT会同时展示正确的调试思路和常见的错误分析，帮助模型避开“陷阱”。然而，CCoT在某些任务中，例如缺陷检测，其表现有时会不如人意。过度依赖对比学习可能会让模型在某些情境下陷入困惑。

ToT (Thread Of Thought)：线程思维思考，逐层分解

核心思路：“线程思维”技术会引导大模型逐步解决问题，专注于将大型或复杂任务分解成较小的可管理部分。
实践表现：在缺陷检测任务中，ToT表现出突出优势，它会引导模型逐个检查代码组件，而不是一次性分析整个代码块。数据表明，这种方法在需要复杂逻辑推理的任务中确实比直接提问效果好很多，准确率提升了10-15个百分点，体现了其在复杂问题分解和推理方面的独特价值。

TroT (Tree Of Thought)：树形思维探索，多维求解

核心思路：“树形思维”通过构建多个分支推理路径，鼓励模型探索不同的解决策略，尤其适用于复杂的设计问题，让模型同时考虑多种可能的解决方案。
实践表现：值得我们关注的是，尽管其设计理念听起来很有趣，但实验数据显示，TroT在软件工程任务中，尤其在代码生成、代码问答和断言生成等任务中，常常是表现最差的技术之一。这可能因为其多分支探索的开销较大，且并非所有软件工程类任务都需要如此发散的思考路径。

SA (Self Ask)：模型自问自答，拆解复杂问题

核心思路：“自我提问”技术让模型在回答问题前先生成自己的后续问题，从而帮助它将复杂问题分解成更小、更易于管理的小步骤。
实践表现：例如，在代码分析任务中，模型可能会先问自己“这个函数的主要功能是什么？”“可能存在什么边界情况？”然后再给出最终答案。这种方法有助于逻辑的清晰化，但研究数据显示，SA的总体表现中规中矩，并非在所有任务中都能带来显著优势。

USC (Universal Self Consistency)：模型从结果里投票选最好

核心思路：“通用自一致性”技术非常引人注目。它会让模型对同一个问题生成多次回答，然后利用一个“元提示”（meta-prompt）来选择最一致或最可靠的答案。
实践表现：例如，当您让模型生成代码翻译时，它可能给出5个不同版本，USC会分析这些答案的一致性，从而选出最可靠的那个。研究数据表明，这种方法在代码问答和代码生成任务中表现特别出色，错误率明显降低，这充分体现了“集思广益”在LLM领域的有效性。

SR (Self Refine)：自我优化评估

核心思路：“自我优化”技术听起来很高级，旨在让模型不断自我评估并改进其初始答案，以期达到更完美的输出。
实践表现：尽管其设计理念听起来很诱人，但实验结果显示，自我优化（SR）在多个任务中，尤其在代码理解任务中，常常位列表现最差的技术之一。研究者推测，这可能是因为模型在自我评估时容易陷入错误的反馈循环，导致越改越错，难以跳出局部最优解。

SG-ICL (Self-Generated In-Context Learning)：自动生成学习样例，少样本学习

核心思路：“自生成上下文学习”能够自动生成上下文示例，以模拟少样本学习，从而简化了编程任务的提示构建过程。
实践表现：这项技术在Bug修复任务中表现尚可，但在其他任务中，尤其在代码翻译、缺陷检测和代码问答中，SG-ICL却经常排在最差行列。这表明，自动生成的示例质量和相关性并非在所有情境下都足以支撑模型性能。

SBP (Step Back Prompting)：退步提示，全局审视问题

核心思路：“退步提示”会让模型首先整体审视问题，思考其关键思想或主要事实，然后再起草解决方案。这有助于大模型提前规划，避免直接跳入细节，从而获得更全面的视角。
实践表现：在一些需要全局理解的任务中（如代码问答的某些复杂场景）SBP有其价值，但从总体数据来看，其在软件工程任务中的表现平平，并未展现出显著的性能优势。

EP (Emotional Prompting)：情感牌，可惜还是输给逻辑

核心思路：“情感提示”试图通过在提示中加入情感语言（比如我旁边这位仁兄写提示词时会威胁模型“你不好好干公司就要倒闭了”）来塑造吸引人的回应，寄希望于情感能激发模型更好的表现。
实践表现：然而，研究数据却给出了一个清晰的答案：对于需要精确逻辑判断的编程任务，情感因素似乎并未带来积极影响，在大多数软件工程任务中都表现平平，甚至在缺陷检测任务中是最差的。看来，在硬核的SE任务中，专业、精准的指令远比情感色彩更重要。

SP (Style Prompting)：确保输出一致的格式控制

核心思路：“风格提示”指导模型采用特定的语调或格式，确保生成的代码注释和文档符合所需的风格。
实践表现：这项技术在需要一致性输出格式的场景中非常有用，例如生成符合企业编码规范的代码注释。然而，其对核心任务性能（如代码正确性）的直接提升有限，更多体现在输出的规范性和一致性上。

RR (Rephrase and Respond)：模型重新描述问题再作答

核心思路：“重述回应”技术要求大模型首先用自己的话重述问题，如果需要还要添加额外细节，然后再给出答案。其假设是，通过让大模型向自己解释问题，模型更有可能完全理解所问的内容，并给出更准确详细的回应。
实践表现：尽管理论上这种方法有助于模型加深对问题的理解，但实验结果显示，RR在多个软件工程任务中都表现不佳。这可能意味着模型在“自问自答”时，其重述和补充能力尚未达到理想状态，或者未能有效引导其产生更优解决方案。

RP (Role Prompting)：角色扮演专家，点亮人物技能

核心思路：“角色提示”为模型分配一个特定的角色（例如代码审查员、资深开发者或初学者），以使其输出更适应特定软件工程任务的细节和语境。
实践表现：值得一提的是，尽管角色提示（RP）在性能上并非总能拔得头筹，但它在Token效率方面表现突出。在大多数任务中，RP都能提供不错的性能，同时保持相对较低的资源消耗。这使得RP在预算有限或对响应速度有较高要求的场景中，成为一个值得考虑的明智选择，展现了其“高性价比”的特点。

AP (Analogical Prompting)：类比提示，泛化理解

核心思路：“类比提示”让大模型使用类比来使代码解释或设计思想更容易理解。这有助于将复杂或抽象的数据结构或算法转化为相关的、现实世界的例子，从而降低理解门槛。
实践表现：AP在需要解释复杂概念的场景中具有一定价值。然而，从性能提升的综合数据来看，其在本次研究的软件工程任务中的表现有限，并未显著提高任务的准确率或效率。

究竟哪种提示工程技术效能最佳？

‼️重要观察结论：

【没有“银弹”！不存在一种提示工程技术能在所有SE任务中都表现最佳。】

没有一种提示工程技术能在所有SE任务中持续超越其他技术。甚至某些“高阶”提示技术甚至可能对性能产生负面影响。这意味着我们不能“一招鲜吃遍天”，而必须根据具体任务进行选择：

范例选择KNN (ES-KNN)
：在克隆检测、代码翻译和断言生成等任务上，ES-KNN表现尤为突出，几乎在所有LLM模型中都位列前茅。这表明，通过K近邻算法选择语义相似的上下文示例，能够有效引导LLM理解当前数据样本并完成任务。
通用自洽性 (USC)
：在代码问答和代码生成任务上，USC表现最佳。这说明，提供结构化的示例或鼓励模型探索多种解决方案路径，可以显著提高输出的可靠性。
思维链 (ToT)
：在缺陷检测任务中表现优异。ToT引导LLM将代码分解为组件，逐一检查潜在缺陷，有助于模型聚焦于特定组件，提高缺陷识别率。
OpenAI 03-mini 的特殊性：
有趣的是，03-mini模型的最优提示技术与其他模型有所不同，角色提示 (RP)在其上表现突出。这提示我们，轻量级模型可能需要独特的提示技术或额外的调优。

真正能打的“王炸”组合：ES-KNN、USC、ToT

图：不同Prompt技术在不同模型+不同任务上的最佳选型

实验中，有几种技术脱颖而出，被证明在软件工程任务中表现异常出色：

ES-KNN (示例选择K近邻)：大模型的“百科全书”

核心思路：想象一下，你写代码时遇到难题，是不是会去GitHub或Stack Overflow上找几个最相似的代码片段做参考？ES-KNN 就是这个道理。它会智能地找到与当前任务最相似的几个代码示例，把它们作为“上下文”一并交给大模型。
怎么做到？研究者先用专门训练过的代码嵌入模型，把所有代码样本都转换成数学向量，然后通过计算余弦相似度（一种衡量向量之间相似度的方法），筛选出Top-K个最相关的样本。
为什么强？它的成功秘诀在于提供了高质量、高度相关的学习示例，而不是随机塞给模型一堆不相干的信息。在代码翻译（比如Java转Python）和断言生成等任务中，ES-KNN 简直是“全能王”，所有测试模型都显示它是最佳选择。
小缺点：性能虽好，但由于需要包含多个示例，它的 Token 消耗也是最高的，资源成本相对较高。

USC (通用自一致性)：让AI自己“投票”选答案

核心思路：这个技术特别有意思，它不相信大模型一次的回答，而是会让模型对同一个问题回答多次，然后用一个“元提示”（可以理解为更高层次的指令）来选择最一致或最可靠的那个答案。
怎么做到？比如，你让模型生成5个版本的代码，USC 会分析这5个版本之间的一致性，选出那个最靠谱、最有信心的答案。
为什么强？就像人类做决策时会从多个角度思考，然后综合判断一样，USC 通过这种“多答案投票”机制，大大降低了错误率。在代码问答和代码生成任务中，USC 表现特别出色，错误率明显降低。
小缺点：需要生成多个响应，时间成本会略高，但对于对准确性要求极高的场景，这点额外开销绝对值得。

ToT (线程思维)：复杂推理的“剥洋葱”高手

核心思路：它会引导大模型像剥洋葱一样，把一个复杂的大任务分解成若干个小的、可管理的步骤，然后一步步地解决。
怎么做到？在缺陷检测（找代码Bug）任务中，ToT 会引导模型逐个检查代码组件，而不是一次性分析整个代码块。这种系统性的“分支思考”模式，能有效避免遗漏潜在问题。
为什么强？数据表明，这种方法在需要复杂逻辑推理的任务中，确实比直接提问效果好很多，准确率甚至能提升10-15个百分点，如果我们在开发静态分析工具或代码审查系统，ToT 应该是首选。

值得注意的是，在实验中，OpenAI的o3-mini模型显示出了与其他三个模型（DeepSeek-V3、Qwen2.5-Coder-32B-Instruct、Llama3.3-70B-Instruct）不同的偏好模式，这提醒我们，在不同模型间切换时，需要重新验证提示策略。

避坑指南：哪些Prompt技术是“花架子”？

图：不同Prompt技术在不同模型+不同任务上的最差选型

有表现出色的，自然也有不尽如人意的。这项研究也无情地揭露了一些看似高大上，实则“拉胯”的 Prompt 技术，大家千万要避雷：

SR (自我优化)：看上去很美，实际很坑

核心思路：让模型不断自我评估和改进答案。听起来是不是很完美？
缺点：实验结果显示，SR 经常是最差的那一批。特别是在代码理解任务中，它几乎总是垫底。研究者推测，可能是模型在自我评估时容易陷入错误的反馈循环，越改越错，把自己绕进去了。

TroT (树形思维)：别被名字唬住，它不是ToT

核心思路：通过构建多个分支推理路径来探索不同的解决策略。请注意，这个TroT (Tree of Thought)和前面提到的ToT (Thread of Thought)虽然名字很像，但效果天差地别
缺点：实验数据显示，TroT 在代码翻译、变异生成等任务中都是最差的选择，可能是因为它的多分支结构对软件工程任务来说过于复杂化了，反而拖了后腿。

EP (情感提示)：对AI撒娇/恐吓，都没用

核心思路：在提示中加入情感语言，比如“这很重要，请仔细思考！”或者“请务必给出最精确的答案！”很多人以为这样能让AI更“上心”。
缺点：数据直接“打脸”了，EP 在大部分软件工程任务中都表现平平，甚至在缺陷检测任务中是最差的。看来对于需要精确逻辑判断的编程任务，情感因素真的没什么用

SG-ICL (自生成上下文学习) 和 RR (重述回应)：自动化不等于优化

这两个技术虽然听起来很智能，一个能自动生成学习示例，一个要求模型先重述问题再回答。但在实际测试中，它们经常排在最差行列。原因可能是自动生成的内容质量不够高，反而干扰了模型的正常判断，或者“重述”并没有真正带来更深的理解。

揭秘实验设计：这项重磅研究是如何进行的？

要得出哪些 Prompt 技术真正“能打”的结论，离不开严谨科学的实验设计。这项开创性的研究，其背后凝聚了研究者们大量的心血和精密的考量，确保了其结论的权威性和说服力。

任务范围与数据基础

本次研究的覆盖面可谓极广，精心挑选了从代码理解到代码生成等十大类核心软件工程任务。为了保证评估结果的统计学可靠性，每个任务都经过了科学的随机抽样，确保有稳定且充足的测试实例，数量均在378到391之间。这为后续深入分析奠定了坚实的数据基础。

Prompt 技术精挑细选：

面对市面上琳琅满目的 Prompt 工程技术（最初多达46种），研究团队采取了极为严格的筛选标准，最终精简出14种最具代表性和主流的 Prompt 技术进行深度测试。他们的筛选原则非常明确：

去重存优：功能相似的技术只保留一个，例如，K-Nearest Neighbor 和 Vote-K 这类都属于少样本技术，只选择其中一个进行代表。
杜绝组合：避免多种技术复杂组合（如 DENSE 这类集成方法），确保每种被测技术是独立的。
不依赖外部工具：剔除那些需要额外工具或接口辅助（如 ReAct）的技术，以保证测试的纯粹性。
整个筛选过程由两名拥有两年以上 Prompt 工程经验的资深研究生独立完成，若出现意见分歧，则由第三方专家进行仲裁，最终通过严谨的协商达成一致，确保了技术选择的公平与严谨。

提示语的“千锤百炼”：

研究者们深知，即便是同一项 Prompt 技术，不同的措辞也可能带来不同的效果。为了避免这种“提示语陷阱”，他们为每种选定的技术构建了10个不同的变体模板。这些变体首先由强大的语言模型（如 ChatGPT）生成，确保语法正确性和表达多样性。随后，由6名研究人员分成3个小组，对这些模板进行严苛的人工审核，每组负责4-5种技术。只有当两位审核者都确认某个模板完美符合其文献描述时，该模板才会被最终采纳。这种双重验证机制，最终使得人工审核的一致性系数（Cohen's kappa）达到0.45，这在人工标注领域已属相当高的可靠性。

模型的多元选择：

为了让研究结果更具普适性，研究团队选择了四款来自不同组织、拥有独特架构和训练目标的大模型参与实验：包括DeepSeek-V3、Qwen2.5-Coder-32B-Instruct、Llama3.3-70B-Instruct，以及OpenAI的o3-mini。这些模型在EvalPlus等权威代码生成基准测试中均表现出色。值得注意的是，o3-mini在许多任务中展现出与其他模型不同的行为模式，这也提醒我们，在实际应用中切换大模型时，原有的 Prompt 策略很可能需要重新验证和调整。

2000多次实验的严谨执行

这项研究总计进行了超过2000次独立的测试运行。具体操作流程细致入微：每一种精选的 Prompt 技术都被完整地应用于所有10个软件工程任务。为确保数据分配的公平性，数据集被平均切分，保证每个 Prompt 变体都处理38到40个独立的实例。研究者们通过together.ai API调用开源模型，并通过OpenAI API调用o3-mini。模型返回的响应则由专门编写的解析脚本进行提取和评估：如果模型按约定使用了指定的分隔符，解析器会精准提取分隔符内的内容；如果模型未按约定使用分隔符，则对整个响应进行评估。

论文数据集：面向开发者的“宝藏”

这项研究的价值，不仅在于其权威的结论，更在于论文作者慷慨地公开了其所使用的实验数据集。对于广大代码工具类产品的开发者而言，这份数据集无疑是一份极具价值的“宝藏”，它提供了：

1. 业界领先的标准化测试基准：

每个任务都配备了经过科学严谨抽样、数量介于378至391个的测试实例，为开发者提供了可靠的评估依据。
采用95%置信水平、5%误差边际的统计学方法，确保了所有测试结果都具有高度的可信度。
任务类型丰富多样，涵盖了从简单的代码分类到复杂的代码生成等全方位的软件工程场景，能够全面检验AI工具的性能。

2. 源自真实世界的代码场景：

缺陷检测的数据直接来源于实际开源项目的Bug报告，而非人造案例，确保了其真实性和实用性。
代码生成任务严格依据真实的编程需求和功能规范来设计，使得生成的代码更具实际应用价值。
错误修复的案例则取材于真实的软件开发调试过程，高度贴近日常开发中遇到的实际问题。

3. 全面支持多语言编程：

数据集包含了Java、Python、C++等主流编程语言的代码样本，满足了不同开发团队的需求。
涵盖了从简单函数到复杂系统等不同复杂度级别的代码片段，为评估AI工具在不同难度任务下的表现提供了依据。
这份详尽且真实的测试用例库，能够直接为工程师提供可应用于产品开发、测试和优化的宝贵资源。

意想不到的“黑马”：“小而美”的 Prompt 技巧

RP (角色提示)：性价比之王

通过给大模型分配一个特定角色，比如“你现在是一名经验丰富的代码审查员”，或者“你是一名资深开发者”。

虽然性能不是最顶尖，但 RP 在 Token 效率（也就是花钱）方面表现突出，在大多数任务中都能提供不错的性能，同时保持相对较低的资源消耗。对于预算有限或对响应速度有要求的场景，RP 可能是更明智的选择。这也是我们日常目前用的最多的一个方式了。

Exemplar Selection (示例选择)：基础但有效

其实这个跟 ES-KNN 的核心思想是类似的，就是给模型看一些例子。研究发现，这种看似简单的“当复读机”的方法，只要例子选得对，效果就不会很差。

深度揭秘：Prompt成功的真正底层逻辑

符合人类找规律的习惯，这项研究还从更深层次剖析了 Prompt 成功的底层逻辑，对我们优化 Prompt 策略极具指导意义。先看下试验结果：

图中展示了每个任务中最佳和最差技术的具体表现，以及通过对比解释分析得出的成功关键因素，怎么看：

Task (任务):这个很直观，就是具体的软件工程任务，比如“克隆检测 (Clone detection)”。
Std (标准差):这个指标告诉我们，在这个任务上，不同Prompt技术的表现差异有多大。

数值高（比如Mutant generation的19.59）：说明在这个任务上，选对Prompt和选错Prompt，效果是天差地别
数值低（比如Code summarization的1.51）：说明大部分Prompt技术在这个任务上表现得差不多，选哪个影响相对较小。

Best (最佳技术) & Worst (最差技术):这两部分分别列出了在该任务中，性能得分最高和最低的技术。
z-score (Z分数):你可以简单地把它理解为性能得分，分数越高，代表表现越好。通过对比Best和Worst的z-score，你能直观地感受到它们之间的性能鸿沟。
Best vs Worst Contrastive Explanation (最佳与最差的对比性解释):几个关键词，指出了“最佳技术”比“最差技术”到底强在哪里。

实验结果说明了什么？

洞察一：Structured Guidance (结构化指导) - 灵魂中的灵魂

给大模型提供清晰的、有条理的、一步步的指引。而不是给一个模糊、开放的任务。这包括明确的步骤、输出格式的规定、需要遵循的规则等。
为什么它最重要？你看这张表，Structured Guidance这个词在最后一列几乎无处不在/这说明，无论做什么任务，给AI一个清晰的“路线图”是提升性能最核心、最普适的方法。好的Prompt会引导AI思考，而差的Prompt只会让AI迷路。

洞察二：In-Context Example (上下文示例) - “身教”远胜“言传”

给大模型提供高质量、高相关的学习范例。
为什么它重要？这个秘籍在代码生成类任务（Generation Tasks）中出现的频率极高。这再次印证了ES-KNN等少样本技术为什么如此强大。对于需要创造性输出的任务，给AI看几个“优秀作业”，远比用长篇大论去描述要求更有效。

洞察三：Ambiguity Reduction (减少歧义) - 别让AI“猜谜”

确保你的指令精准、无歧义，让AI不需要猜测你的真实意图。
为什么它重要？在Code QA（代码问答）这类需要精确理解的场景下，这个因素至关重要。一个模棱两可的问题，自然很难得到一个准确的答案。

洞察四：Efficiency (效率) & Robustness (鲁棒性)

这Efficiency指的是技术能高效地引导模型找到正确答案。Robustness指的是技术能更好地处理各种输入，不容易被干扰。
为什么它们也重要？它们是“锦上添花”的因素，能让一个好的Prompt变得更稳定、更可靠。

从表中提炼出的实战结论：

语言学特征：Prompt的“内在美”

词汇多样性是关键：研究发现，用词丰富、表达多样的 Prompt 确实能显著提升模型表现。如果你总是用单调重复的措辞，反而会限制模型的理解能力。所以，多用同义词，多角度描述，让你的 Prompt 更多样。
更长不等于更好：让人意外的是，Prompt 的长度（Token 数量）与性能呈负相关。这彻底颠覆了“Prompt 越详细越好”的传统观念，它告诉我们，精炼准确比冗长描述更重要。
可读性因任务而异：更有趣的是，Prompt 的可读性在不同类型任务中表现完全相反。在代码理解任务中，简单易懂的 Prompt 更有效；但在代码生成任务中，复杂一些、更具信息密度的 Prompt 可能更有帮助。这说明我们需要根据任务的特点来调整 Prompt 的“易读程度”。

对比解释分析：结构化指导是“灵魂”

研究者们深入分析了为什么有些技术效果好，有些效果差，发现：

结构化指导占主导地位（32.05%）：这是最重要的成功因素——意味着好的 Prompt 技术会提供清晰的步骤指导和约定规范，而不是模糊的任务描述。比如 ES-KNN 不仅提供示例，还会明确说明如何使用这些示例。AI 也喜欢有条理、有规则的指引。（结构化表达金字塔，含金量还在提升啊）
上下文示例排第二（21.80%）：再次证明了示例学习的重要性。但关键不是随便给几个例子，而是要提供与当前任务高度相关的、高质量的示例。（临摹上手，干中学）
效率和歧义减少也很重要：排名中效率（17.95%）和歧义减少（15.38%）顺位3、4，说明好的提示技术既要能引导模型找到最优解，又要能消除任务需求的不确定性。
直接要求“推理”或“正确性”效果有限：推理（2.56%）和正确性精确性（2.56%）占比较低，表明简单粗暴地让模型“仔细推理”或“确保正确”，效果往往并不理想。

成本考量：性能与效率如何平衡？

性能固然重要，但资源消耗（特别是Tokens和时间）在实际应用中也是关键考量，饰演的关键结论如下：

性能与成本的权衡：
开发者在选择提示技术时，需要仔细权衡性能提升与资源成本。
模型感知优化：
提示词优化策略需要“模型感知”，说白了就是不同模型也要多尝试（比如o3-mini在很多结果上展现了与其他模型不一样的偏好）因为对一个LLM有效的技术，可能无法推广到另一个模型上。

我们来看看试验结果：

图：在每个任务中，性能得分排在第一位的技术，它的资源成本是怎样的。

行 (Row) - 看任务：表格的每一行代表一个具体的软件工程任务，比如“缺陷检测 (Defect detection)”或“代码翻译 (Code translation)”。
列 (Column) - 看模型：表格的每一列代表一个大模型，比如Qwen、DeepSeek、Llama等。其中Aggregate这一列是所有模型的综合平均结果，最具参考价值。
核心解读：每个单元格里的内容都遵循Default/ Token/Time的格式。这三个位置分别代表：

Default/Performance:在这个任务上，性能表现最好/最差的技术是哪个。
Token:在这个任务上，Token消耗最少/最多的技术是哪个。（可以理解为最省钱/最费钱）
Time:在这个任务上，响应时间最短/最长的技术是哪个。（可以理解为最快/最慢）

图说明了什么？

洞察1：ES-KNN - 性能王者，但也是“吞金兽”

证据：在“Default”位置（性能最佳），ES-KNN 出现了非常多次，尤其是在 Aggregate 综合列中，堪称霸榜。这印证了它是当之无愧的性能王者。
但是，你会发现，在“Token”位置（Token最省），ES-KNN 很少出现。反而，Control(基线，即最简单的提示) 经常是Token效率最高的。这说明 ES-KNN 的高性能是用高昂的Token成本换来的。

洞察2：RP (角色扮演) - 当之无愧的“性价比之选”

证据：仔细看“Token”位置（Token最省），RP 出现的频率相当高。这意味着，虽然它性能不总是第一，但它非常“省钱”。对于预算敏感或追求高效率的场景，RP 是一个非常明智的选择。

洞察3：“最好”不等于“全能”，需要按需选择

证据：几乎没有任何一个单元格是X / X / X的形式。这说明，不存在一个既性能最好、又最省钱、还最快的“完美”技术。你需要根据自己的首要目标来做选择：

追求极致性能？选ES-KNN或ToT。
追求最低成本？考虑RP或Control。
追求最快响应？这需要具体看任务，没有统一的赢家。

这张差生表同样精彩，解读方式同上，我们这里直接看结论：

洞察1：SR (自我优化) - 全方位的“差生”

证据：SR这个缩写在整张表里无处不在...它不仅频繁出现在“DEFAULT”位置（性能最差），也经常出现在“TOKEN”（Token消耗最多）和“TIME”（时间最长）的位置。
结论：这给了我们一个极其有力的警告：SR技术不仅效果差，而且又贵又慢，是绝对需要避开的“天坑”...

洞察2：TroT, SG-ICL, RR - 难兄难弟

证据：除了SR，TroT（树形思维）、SG-ICL（自生成上下文）和RR（重述回应）也是榜上的常客，证明它们在软件工程任务中普遍表现不佳。

洞察3：最差性能 ≠ 最差效率

证据：即使是表现最差的技术，消耗资源最多的也未必是它自己。例如，在Defect detection的DeepSeek模型下，性能最差的是EP（情感提示），但最耗Token的是SR，最慢的是SBP（退步提示）。这说明“差”也分很多种，有些是单纯效果不好，有些则是资源黑洞。

研究也对比了不同提示工程技术在Token消耗上的表现：

Token消耗：

代码生成和Bug修复
任务的Token节省量最高（平均超过8000个Token），这表明这些Token密集型任务从提示词压缩策略中受益最大。
03-mini模型
在大多数任务中Token节省量最低，可能其提示词本身已足够简洁，或压缩能力有限。

在响应时间上的表现：

代码生成和Bug修复
等任务，在时间节省上同样表现出色。
识别或分类型任务
（如异常类型预测、克隆检测、代码问答）在时间节省方面效率提升较小，可能因为这些任务的输入提示词本身就比较紧凑。

速记：根据具体任务匹配Prompt队友辅助

看到这里我悟了，下次再做 AI 应用时，别再盲目尝试各种 Prompt 技巧了，根据你的具体任务，直接选择被数据验证过的“王炸”组合：

如果你在做代码翻译（比如Java转Python）、代码重构、或者需要检测代码相似性（克隆检测）：

首选 ES-KNN。它的语义相似性示例选择机制，能完美指导模型理解转换规律或相似性模式。

如果你在做代码问答、或者需要根据需求生成新代码：

USC 最靠谱。它的多答案一致性检查机制能有效减少错误，保证输出的准确性。虽然多花点时间，但绝对值得。

如果你做缺陷检测，需要发现代码Bug的场景中，或者开发静态分析工具或代码审查系统：

ToT 无可替代。它的分支思考模式特别适合系统性地检查代码各个组件，避免遗漏问题。

如果你预算有限，或者对响应速度有较高要求，但又想获得不错的效果：

RP (角色提示) ，百搭。

AI同好们的后续行为指导方针

没有万能钥匙：
提示工程没有一劳永逸的解决方案。最佳实践是根据具体任务和所选LLM模型进行自适应设计和实证验证。
结构和示例是核心：
有效的提示词不仅仅是文字的堆砌，更是结构化指导与高质量、相关性强的上下文示例的有机结合。
语言特征的深远影响：
提示词的词汇丰富度、长度和可读性等语言特征，对模型性能有着复杂而直接的影响。我们需要深入研究这些“语言基因”，才能更好地“定制”提示词。
成本与效益的平衡：
在需要考虑性能的时候，需要关注Token消耗和响应时间。对于资源密集型任务，提示词优化甚至能带来显著的经济效益。

或许未来的发展将走向自动化和自适应的提示词生成工具，这些工具能够根据任务需求、LLM特性以及语言特征，动态生成最优的提示词结构和内容，也或许LLM慢慢的也会进化到，可以根据我们的任务自动匹配到点亮的神经元执行任务，而不需要我们去筛选和甄别什么样的语言和逻辑让他们更好更快的理解我们。

但在AI长大到具备这样的能力之前，就让我们来记住这些，和AI实现一场双向奔赴吧。

欢迎光临链载Ai (https://www.lianzai.com/)