外观
第 16 章 从经验试错到系统化调优
先来看一个很多工程师都经历过，或者未来大概率会经历的场景。
假设一位工程师负责维护一个用 LLM 做内容审核的系统，这个系统每天要处理上百万篇用户发布的文章，是公司内容生态的审核入口。某天下午，产品经理急匆匆地找过来，满脸焦虑，开口就说：“线上出 P0 级事故了！我们的系统，把一篇用户写的关于‘日本动漫文化’的、非常正常的深度分析文章，给错误地打上了‘色情低俗’的标签！这篇文章的作者是个行业大 V，粉丝几百万，现在他把截图发到社交媒体上了，说我们平台‘没文化’、‘搞一刀切’。我们的品牌公关部门电话已经被打爆了，用户投诉的邮件已经塞满了 CEO 的邮箱！”
工程师心里一惊，赶紧去查日志，找到了那篇系统“误杀”的文章，也调出了当时系统的审核记录。用户文章里有这么一句话：“...《新世纪福音战士》（EVA）这部伟大的作品，深刻地探讨了青春期的迷茫、存在的孤独，以及少年少女们对于自我‘身体’和‘心灵’的觉醒，这种对存在主义的思考，是它封神的原因...”
而审核 Prompt 里，有一条工程师亲手写下、看似天经地义、不容置疑的规则：“规则 3.7：严格检测文本中是否包含关于‘身体’部位的露骨描写，以防止软色情内容的传播。”
问题就出在这里。模型只按字面含义执行指令，看到“身体”这个关键词就触发了规则。没有人教会它，此“身体”非彼“身体”。它把一个哲学层面的、关于“存在”的“身体”，直接等同于生理层面的“身体”。
现在问题摆在面前。作为这个系统的负责人，面对工作群里不断@过来的老板和同事，这个 Prompt 该怎么改？
一个急于止血的工程师，可能会立刻动手。第一反应是“打补丁”，直接把那条规则改成：“规则 3.7：严格检测文本中是否包含关于‘身体’部位的、非医学或艺术语境下的露骨描写”。改完，用出问题的那篇动漫评论一测，通过了。于是提交代码，走紧急上线流程，在事故群里@所有人：“问题已修复上线。”到这里就结束了，没有做任何其他验证。
结果，第二天一早，咖啡还没喝上一口，产品经理又找上门来，脸色比前一天更难看：“又出大事了！昨天你改完之后，系统是能识别动漫了，但现在，一篇正常的、讨论‘瑜伽如何塑造身体曲线’的健身教学文章，被它放过去了！而这篇文章，被我们的竞争对手扒出来，里面有一些明显打软色情擦边球的、带有强烈性暗示的描写！现在我们被监管部门约谈了！”
问题变得更严重了。为了修复一个“误杀”（False Positive）的 case，结果制造了一个更严重的“漏杀”（False Negative）的 case，陷入修一处、坏一处的循环。每一次修改都在不同的目标之间顾此失彼，而且判定规则本身还随着每次修补不断变化。
为什么会这样？
因为缺少一套系统性的调优方法论，工程师是在用“打补丁”的战术层面的思维，去解决一个复杂的、战略层面的系统平衡问题。
一个 Prompt，尤其是企业级的、承载着复杂业务逻辑的 Prompt，不是一条孤立的指令，而是一个包含大量隐性权重和相互依赖关系的、极其敏感的系统。对其中任何一个词、一句话、一个示例的修改，都可能在完全意想不到的位置改变输出结果。
所以，绝不能再沿用“头痛医头，脚痛医脚”的修修补补。需要一套标准化的、可重复的、能够保证“稳步前进，而不是左右横跳”的调优 SOP（标准作业流程）。
这一章要讲的，就是一套从大量失败经验中总结出来的五步优化循环法。掌握了它，才能从被动地打补丁，成长为能系统化地设计和优化 Prompt 的工程师。
16.1 五步优化循环
先忘掉那些随心所欲、靠灵感驱动的修改方式。从现在开始，每次准备动手优化一个 Prompt 之前，先在心里或任务管理工具里，为这五个步骤建一份检查清单，把整个循环变成肌肉记忆。这五个步骤，构成一个完整的、科学的、闭环的优化流程。
这个循环，就是诊断 -> 假设 -> 修改 -> 验证 -> 回归。
这套流程借鉴了科学实验的严谨态度，用来对待 Prompt 调优这个看似“感性”的工作，把“艺术创作”变成“工程实践”，把“我感觉”变成“数据显示”。
循环的第一步是诊断（Diagnose）。在动手之前，先强迫自己停下来，不要急着去改那句出问题的指令，而是系统地、全面地分析问题到底出在哪。是模型的能力真的不行，还是指令写得有歧义？是给的例子有误导性，还是输入的数据本身就有问题？一个准确的诊断，是所有正确行动的前提。错误的诊断，比不诊断更可怕。
诊断清楚了，第二步是假设（Hypothesize），基于诊断，提出一个或多个清晰的、可验证的“改进假设”。好的假设，不是一句模糊的“我试试加个例子”，而应该是一个完整的、符合科学规范的句子，比如：“我假设，通过在 Prompt 中增加一个关于‘艺术评论’的负面示例（Negative Example），可以让模型更好地区分正常的文化讨论和真正的色情描写，从而在不影响瑜伽文章判断的前提下，修复动漫文章的误杀问题。”这个假设，明确了要做什么（增加负面示例）、期望达到什么效果（修复动漫误杀，不影响瑜伽判断），以及判断效果的依据。
第三步才是修改（Modify），到这一步才可以动手，而且修改必须是最小化的、原子化的、可控的。严格根据假设，一次只改一个变量。如果同时有好几个假设，比如“增加示例”和“修改规则描述”，那就创建几个不同的 Prompt 版本（V1.1, V1.2），分开进行实验。千万不要把好几个改动揉在一个版本里，那样的话，就算最后效果变好了，也说不清楚到底是哪个改动起了决定性作用，知识就无法沉淀和复用。
改完之后是第四步，验证（Validate），用修改后的新版 Prompt，去运行评估集。这里不光要看最初那个让人头疼的 BAD Case 修复了没有，更要检查其他的、原本表现正确的 case，这次修改有没有“误伤”到它们，同时关注“修复率”和“劣化率”。很多时候，一个看似成功的修改，实际上是用“修复 1 个 bug，引入 2 个新 bug”的代价换来的。
第五步是回归（Regression），这也是最关键、最容易忽略的一步。验证完新版 Prompt 的效果后，必须立刻把最初的 BAD Case，连同它的正确答案，一起加入一个专门的“回归测试集”。这个测试集记录了系统历史上犯过的所有典型错误。要确保未来的每一次修改，都完全通过这个回归测试集，保证那些已经解决掉的老问题，不会再次出现。
这套流程强迫人慢下来，先思考，再动手，用严格的纪律，约束“先干了再说”的冲动，把一次性的紧急修复，变成可积累、可传承的资产沉淀。
下面就把这五个步骤逐一拆开，看看每个环节里，都有哪些具体的方法和工具。
16.2 定位 Prompt 问题的根因
这是整个优化流程中最重要，也是最考验功力的一步。一个错误的诊断，会让后续所有的修改都作用在错误的位置，改得越多，偏离越远。
面对一个效果不佳的 Prompt 输出，可以沿着一棵“问题诊断树”层层排查，最终定位到最根本的原因。
一个常见的错误输出，其背后的原因，通常可以归结为以下几种主要类型。要能区分它们之间的细微差别。
原因一：能力不足（Competency Gap）
这是最需要优先排除的一种可能性。因为如果真的是这个问题，那后续在 Prompt 上做的任何挣扎，都将是徒劳。
表现很有辨识度。无论怎么修改 Prompt，怎么循循善诱，怎么给示例，模型对于某一类特定的任务，始终做不到，做对的概率接近随机。它的错误，不是那种“可以理解的”逻辑错误，而是一种“匪夷所思的”随机错误，说明输出接近随机猜测。
诊断这个病因，要放下对“大力出奇迹”的幻想，放下工程师那种“一切问题都能通过努力解决”的执念，冷静地问一个关键的问题：“我让它做的这个事，是不是已经超出了当前这个模型的能力边界？”
举个具体的例子。让 GPT-3.5-Turbo 去解决一个需要复杂的多步逻辑推理和精确计算的数学应用题，比如：“一个水池有两个进水管 A 和 B，一个出水管 C。单开 A 管 3 小时注满，单开 B 管 4 小时注满，单开 C 管 6 小时放完。现在三管齐开，多久能注满？”
可能会发现，无论思维链（CoT）Prompt 写得多么循循善诱，教它“第一步，计算 A 的效率是 1/3；第二步，计算 B 的效率是 1/4；第三步，计算 C 的效率是 1/6；第四步，计算总效率是 1/3 + 1/4 - 1/6...”，它在最后一步 1 / (1/3 + 1/4 - 1/6) 的计算上，还是会频繁地、随机地出错。有时候算出 2.4 的正确答案，有时候算成 3，有时候甚至给出一个负数。
或者，给模型的上下文里，放两个高度相似、但在一个不起眼的角落里有一个关键数字不同的段落（比如一份合同的两个版本，只有一个条款的违约金从“10%”改成了“15%”），然后要求它找出这个差异。可能会发现，即便是当前最强的闭源旗舰，在处理这种需要“像素级”的、极其精细的文本比对任务时，也常常会“视而不见”，然后自信满满地宣称“这两段文本没有差异”。
那么，如何确诊这种“先天不足”？一个办法，是简化问题到极致，进行“单元测试”，把复杂任务，拆解成它所需要的最基础的、原子化的能力单元。比如，对于那个水池问题，别让它解应用题了，就单独给它一道分数的加减法 1/3 + 1/4 - 1/6，看它会不会。如果连最简单的单元它都做不好，那组合起来的复杂任务，就更做不好了。这和调试一个复杂函数的思路一样，先保证它调用的那些基础库函数是没问题的。
另一个办法是横向对比，寻找“能力天花板”。把同一个任务，同一个 Prompt，扔给市面上最强大的模型去试试，比如 GPT-5、Claude Opus 4.5 这类旗舰，或者 DeepSeek、通义千问 Qwen 的最新版本。如果连最强的模型都做得磕磕绊绊，那手里这个更轻量的模型，就更别指望了。这能帮助快速确认当前 LLM 技术栈的“能力天花板”在哪，避免在超出能力范围的任务上继续投入。（注：旗舰模型的排名迭代很快，本章以方法论为主，以动手时能调用的最强模型为准。）
还可以查阅最新的研究文献，参考已有的结论。去 Google Scholar、arXiv 这些地方，看看相关的研究论文或者技术博客，看看学术界和工业界，对于正在处理的这类任务（比如，长文本精确信息抽取、复杂算术推理、代码生成中的算法正确性），目前的技术水平（State-of-the-art, SOTA）到底到了一个什么程度。很多时候会发现，遇到的问题，其实是一个全世界都还没解决好的开放性难题。知道了这一点，就能坦然地放弃，而不是陷入无尽的自我怀疑。
到了处理这一步，如果最终确认是“能力不足”，那么请立刻停止在 Prompt 上继续浪费时间，把精力转到方案调整上。可能的处理方式有这么几条。
最直接的一条是升级模型，换一个更强大的、更大参数量的模型。从小档位升级到旗舰档位，很多问题就迎刃而解了。当然，代价是更高的成本和延迟。
也可以改变实现路径，用代码补上模型的能力短板。比如，对于计算问题，在 Prompt 链里加入一个“代码解释器”的步骤，让模型生成一段 Python 代码去执行计算，然后把结果返回给它，而不是让它自己去“心算”。对于精确的文本比对，先用传统的、基于字符串 diff 的算法，筛出有差异的段落，再让 LLM 去理解和总结这些差异。
如果前两者都做不到，那就只能降低期望，调整产品设计，和产品经理坐下来，开诚布公地沟通，讲清技术的边界在哪，然后一起商量，是降低对这个功能的预期（比如，从“100% 准确”降低到“提供参考，需人工核对”），还是干脆就砍掉这个功能，避免给用户带来错误的引导。
承认模型的能力边界，并且知道在什么时候应该放弃，是 Prompt 工程里重要的一课。
原因二：指令不清（Instruction Ambiguity）
这是最常见，也是提示工程师最应该花力气去解决的一类问题。因为这个锅，99% 的情况下，都在写 Prompt 的人自己身上。
症状也好识别。模型的输出，时好时坏，非常不稳定，充满了“薛定谔”式的随机性。对于同一个任务，它有时候能完美地理解意图，有时候又会以一种完全意想不到的、清奇的角度，把事情搞砸。它的输出质量不稳定，取决于指令能否覆盖当前输入的各种情况。
诊断时，要换一个审查标准：不再默认指令的含义不言自明，而是逐字逐句地审视 Prompt，假设模型是一个绝对理性、但没有任何“常识”和“默契”的机器，它只会按字面含义执行，并且会利用指令里的任何一点模糊、歧义和未定义之处，给出不符合预期的输出。
回到开篇那个让人焦头烂额的“内容审核”的例子。原始的指令是：“检测文本中是否包含关于‘身体’部位的露骨描写”。
按字面执行的标准来分析，这个指令哪里“不清”了？ 先看“身体”这个词，它的定义太宽泛了。作为一个没有人类价值观的机器，它会想：“哲学讨论里的‘肉身’算不算身体？医学解剖图谱算不算身体？艺术作品里的人体雕塑算不算身体？色情描写里的躯体算不算身体？你没说清楚，那我就只能一视同仁了。为了安全起见，我还是都给你标出来吧。”
再看“露骨描写”。这是一个非常主观的、充满了人类文化色彩的词。“露骨”的程度，每个人都有不同的标准。模型会想：“‘她穿着清凉的比基尼’算不算露骨？‘他展示了健硕的肱二头肌’算不算露骨？你没有给我一个可以量化的、可操作的判断标准或示例，那我只能根据我在训练数据里学到的、最‘平均’的理解来判断了。我的训练数据里，可能有很多把‘身体’和负面内容关联起来的文本，所以我的判断，自然会偏向于更严格。”
那怎么确诊这种“指令不清”？可以先按字面标准自查，拿着指令，逐句去读那篇系统误杀的动漫评论文章。会发现，根据字面指令，文章里确实提到了“身体”，模型把它判定为违规，是完全“忠于”指令的。错的不是模型，错的是发号施令的人。
更有效的诊断方法，是主动寻找并测试“边界反例”。主动去知识库或者网上，找一些处于“模糊地带”的、极具挑战性的例子。比如，一篇关于“乳腺癌自我检测方法”的医学科普文章，一篇探讨“人体艺术摄影”审美价值的评论文章，一篇讲述“分娩过程”的母婴纪实文章。用这些例子去测试原始 Prompt，看看它会如何判断。这些测试会把指令里的漏洞和想当然之处，直接暴露出来。
解决指令不清的方法，前面的章节里其实已经反复提过了，核心思想就是八个字，即增加清晰度（Clarity）和明确性（Specificity）。写 Prompt 时，要把每条规则的适用范围和判定标准写明确，不留模糊空间。
具体落笔时，先要精确用词，消除歧义，把所有模糊的、有多重含义的词，都换成精确的、单一含义的词。比如，把“身体部位的露骨描写”，改成“以引发性联想为主要目的的、对人类生殖器官或性行为的直接、详细的文字描述”。
光有精确的词还不够，还要提供明确的边界和豁免条款，明确地告诉模型，什么是，什么不是。比如，增加一条规则：“豁免条款：在医学、科学、艺术评论或教育语境下，对人体部位的客观、非性化的描述，不属于本规则定义的违规范围。”
规则的尽头，还应该给出高质量的正反两方面的示例（Few-shot）。规则描述往往不如示例直接。提供正反两方面的例子，特别是那些最容易混淆的“边界”例子。比如，给一个动漫评论的片段，告诉它这是“合规”的；再给一个色情小说的片段，告诉它这是“违规”的。一个好的示例，胜过千言万语的规则描述。
指令的清晰度，是 Prompt 性能的基石。在这上面花再多的时间，都不过分。打磨指令花的时间，能在后续的迭代和维护中数倍地省回来。
原因三：格式错误（Format Error）
这类问题，通常出现在那些需要模型输出结构化数据（比如 JSON、XML、YAML）的场景里。这也是一类常见的低级错误。
表现很典型。模型已经正确理解了意图，也从文本中提取了所有信息，但输出的格式与要求不一致。它可能会在 JSON 的最后一个键值对后面，多一个画蛇添足的逗号，导致下游的 JSON 解析器直接崩溃；也可能会把一个明确要求是 number 类型的字段，输出成一个带引号的 string 类型。
还有一种常见情况，模型会在要求的 JSON 结构之外，加上自己的“注释”，比如 // Here is the JSON you requested:，或者在 JSON 的代码块前后，加上 ```json 的 Markdown 标记。
这类问题的诊断，相对简单。不需要去理解模型的“内心世界”，只需要像一个代码 Linter 一样，把模型的输出字符串，和 Prompt 里要求的输出格式，进行严格的、字符级别的对比。
先检查格式定义是否严谨，Prompt 里对输出格式的定义，是不是足够清晰、无歧义？有没有提供一个完整的、可以直接复制粘贴来验证的格式示例？很多时候，示例本身可能就存在语法错误。
再检查输入数据本身有没有问题。有时候，问题出在输入数据里。比如，输入文本里，本身就包含了一些会和 JSON 语法冲突的特殊字符（比如未转义的引号、换行符），导致模型在生成时，为了保持内容的完整性，而破坏了 JSON 的结构。
治疗这类问题，第 12 章“输出工程”里，详细地讲过这些技巧，这里再从“调优”的角度，把它们串成一套组合做法。
最基础的一层是强类型约束。不要只是模糊地说“请输出 JSON”。要在 Prompt 里，用一种类似 TypeScript 或 Pydantic 的语法，来定义输出 Schema。明确地告诉模型，每个字段的名称、类型（string、number、boolean、array）以及是否是必需的。这种“代码化”的描述，模型理解起来，比自然语言描述要好得多。
再往上一层是标准示例。给出一个完整的、语法绝对正确的、和要求一模一样的 Few-shot 输出示例。模型会模仿示例的格式。给它的示例越标准，它输出的结果就越标准。
更进一步是预填充（Prefilling）。这是一个非常有效的小技巧。在 API 调用中，利用 Assistant 角色，预先填好输出的第一个字符。比如，如果想要 JSON，就在 Assistant 的第一句话里，直接填一个 {。这个小技巧能提高模型直接以合法 JSON 开头的概率，减少附加的前后缀注释。
不过它有明确的适用边界。截至 2026 年 8 月，Anthropic 官方文档已声明 Claude 4.6 及之后的模型不再支持预填充，这类请求会直接返回 400 错误，官方建议改用结构化输出或系统提示约束来达到同样目的。动手之前，先确认所用模型是否仍支持这一操作。
如果这几层约束都用了还不放心，最后一道保障是使用工具（Function Calling）。如果模型和 API 支持（截至 2026 年中，OpenAI 的 Chat Completions 与 Responses API、Anthropic 的 Messages API、Google 的 Gemini API，以及几乎所有主流开源模型框架都原生支持），请毫不犹豫地使用 Function Calling 或 Tool Use 功能。这是目前解决结构化输出问题最稳健、最可靠的方式。它从根本上改变了输出的生成方式。
它让模型不再需要去“生成”一个充满了语法陷阱的 JSON 字符串，而是去“填充”一个已经在代码中用 Pydantic 或类似工具定义好的、强类型的函数参数结构。模型只需要输出它想调用的函数名和对应的参数值，剩下的序列化和校验工作，都由代码和 API 服务商来保证。这从根本上杜绝了格式错误的可能性。
通过这样一套系统化的诊断流程，绝大多数情况下都能准确定位到问题的根源。一个清晰的诊断，就是成功优化的一半。
16.3 单一 Prompt 还是拆成链
在诊断出问题，准备动手修改之前，还得做一个重要的、架构层面的决策。这个决策，可能会比具体修改哪个词、哪句话，对项目产生更深远的影响。它决定了 Prompt 系统未来的可维护性和扩展性。
这时需要退后一步，审视当前的 Prompt，回答一个架构问题：是不是应该把更多的逻辑、更多的规则，都塞进现有的这个单个的、巨大的 Prompt 里，让它变得越来越“万能”，成为一个“巨石（Monolith）”？还是应该把这个复杂的任务，拆分成多个更简单的、职责单一的小 Prompt，然后用代码把它们串联成一个链（Chain），对应“微服务（Microservices）”的拆分方式？
这，其实是在开发效率（Development Efficiency）和系统鲁棒性（Robustness）之间，做一个艰难但必要的权衡。
单一“巨石”Prompt（Monolithic Prompt）的优缺点
这种思路非常符合初期的直觉。在一个 Prompt 里，把角色定义、任务指令、几十条细分的规则、各种需要考虑的边界条件、一堆正反两方面的 Few-shot 示例，还有复杂的、带有嵌套的输出格式要求，全都塞进去。
它的优点很实际。开发速度快，上手简单，在项目的初期，当逻辑还比较简单时，这种方式非常直接。所有的逻辑都在一个 .txt 或 .md 文件里，修改起来很方便，甚至不需要动后端代码，只需要在 Prompt 管理后台改改就行。而且它端到端，延迟低，一次 API 调用，就能完成从输入到输出的全过程。相比于需要多次调用的 Prompt 链，它的网络开销更小，整体延迟相对较低。
缺点则是全方位的。这种“巨石”Prompt 极其脆弱，牵一发而动全身，内部规则的依赖关系错综复杂，存在大量写的时候没有意识到的隐式关联。为了修复一个问题，修改了其中一条规则，很可能会莫名其妙地影响到另一条看似完全无关的规则。它的行为，会变得越来越混沌，越来越难以预测，最后变成一门“玄学”。
可维护性也会急剧恶化。当这个 Prompt 超过 2000 个 token，包含了超过 10 条复杂的、相互关联的规则时，连作者本人都很难再看懂。几个月后再回来看它，可能需要花一整天的时间，才能理清里面的逻辑。新人接手更是无从下手，只能把它当成一个“黑箱”来用。
调试也很困难。一旦出了问题，很难定位到底是哪一部分的指令出了问题。是因为角色定义有冲突？还是某条规则有歧义？或者是某个示例有误导性？只能用“注释掉一半代码”这种最原始的方式，反复地去试。
它还会带来性能和成本问题。巨大的 Prompt，意味着更高的 token 消耗和更长的处理时间。很多时候，对于一个简单的输入，也需要把那个包含了无数用不上的规则的、庞大的 Prompt，完整地发给模型，造成了巨大的浪费。
那么，什么时候可以考虑使用单一 Prompt？对于那些逻辑相对简单、规则少于 5 条、未来也不太可能频繁变更的简单、独立的任务，比如写一封邮件、翻译一段话、总结一篇文章，用单一 Prompt 是完全可以的，而且效率很高。
拆分成 Prompt 链（Chain of Prompts）的优缺点
这种思路，更像是现代软件工程里的“微服务”思想，或者说 Unix 哲学，即“做一件事，并把它做好”。把一个复杂的、端到端的任务，分解成一系列更小的、独立的、职责单一的步骤，每一个步骤，都由一个专门的、小而美的 Prompt 来负责，再用代码把这些步骤串联起来。
再以那个让人头疼的“内容审核”系统为例。一个“微服务化”的 Prompt 链，通常分三步。
最前面是意图分类 Prompt（路由器）。这个 Prompt 的任务极其简单，就是判断用户输入的文本，大概属于哪个领域。它不关心内容是否违规，只关心“这是什么”。比如，输入一篇动漫评论，它输出 {"category": "anime_review"}；输入一篇医学文章，它输出 {"category": "medical_content"}。
中间是路由逻辑（代码层）。Python 或 Java 代码拿到分类结果后，根据 category 的值，来决定接下来调用哪个领域专用的审核 Prompt。
链路末端是领域审核 Prompt（执行器），为每一个领域，都准备一个专门的、经过了精细优化的审核 Prompt。动漫审核 Prompt 里面可能会有更多关于“艺术表现”“虚拟角色”“剧情需要”的豁免规则；医学审核 Prompt 会极大地放宽对“人体器官”“疾病”等词汇的限制，但会严格审查内容是否包含“伪科学”“贩卖焦虑”或“无证行医”的倾向；健身审核 Prompt 则会用一套专门的规则和示例，来精准地识别那些在健身教学的幌子下，打“软色情”擦边球的内容。
这种拆法的优点，正好对应“巨石”的缺点。它鲁棒性极强，逻辑隔离，每个 Prompt 都很小，逻辑简单，职责单一，它们之间是完全解耦的。修改“动漫审核”的规则，绝对不会影响到“医学审核”的逻辑。系统的行为，变得非常稳定和可预测。
它的可维护性很高，整个复杂的审核流程，在代码里表达得清晰而结构化，代码即文档。每个 Prompt 文件，可能都只有短短的几百个 token，一目了然，修改起来负担很小。调试也容易定位，一旦出了问题，可以很容易地从日志中，定位到是哪一个环节、哪一个 Prompt 出了错，还能对每一个步骤，进行独立的、单元化的测试和评估。
可扩展性同样很好，未来如果新增了一个“美食评论”的审核场景，只需要增加一个新的“美食审核 Prompt”，然后在路由逻辑里加一个 case 分支就行了，完全不会影响到任何现有功能。
当然，代价也真实存在。它的初期开发成本更高，需要设计整个链条的逻辑，编写更多的“胶水代码”来串联这些 Prompt。延迟必然增加，多次 API 调用，必然会带来额外的网络开销和模型处理时间的累加，导致整体的端到端延迟变高。还有错误累积的风险，链条中的任何一个环节出错，都可能导致整个流程的失败，或者把错误传递给下一个环节。
至于什么时候必须考虑拆分，凡是那些业务逻辑复杂、规则超过 10 条、需要处理多种不同场景、并且需要长期维护和迭代的企业级、生产级应用，强烈建议从项目设计的第一天开始，就采用拆分的思路。
给一条个人建议。这是一个没有标准答案的权衡。但经验之谈是，永远不要低估业务未来可能发生的复杂度变化。今天看起来简单的一个任务，三个月后，产品经理可能就会给它加上各种各样意想不到的“补丁”。
具体的经验法则是，当 Prompt 长度超过 4000 个 token，或者在 Prompt 里写了超过 10 个 if-else 式的、用自然语言描述的逻辑分支时，就应该立刻、毫不犹豫地进行重构和拆分。
一开始在架构上多花一点时间，把任务拆分清楚，远比未来去维护一个几千行、没人敢动的“巨石”Prompt，代价小得多。
16.4 BAD Case 库的建立与使用
到这里已经有了科学的诊断方法，也做出了合理的架构决策。接下来进入具体的“修改”和“验证”环节。
在这个环节，有一个极其重要、却常常得不到重视的资产，那就是失败案例库（BAD Case Repository）。
每一个让系统出错的例子，每一个用户投诉的例子，都是定位问题、改进系统、提升鲁棒性的直接材料。把这些案例沉淀下来，就能把同类问题永久地挡在回归测试之外。
要把这些失败案例系统地保存起来，建立一个专门的 BAD Case 分析和管理流程。
如何建立 BAD Case 库：要记录哪些信息
这个库，可以是一个简单的 Git 仓库里的一个 yaml 或 json 文件，一个共享的飞书文档，或者一个专业的测试用例管理工具（比如 TestRail）。关键不在于工具，而在于记录了什么信息，以及如何使用这些信息。
对于每一个 BAD Case，都要把该记的信息记全。每一个 case，都要有一个唯一 ID，方便追踪和引用，比如 CASE-2024-001；再配上一句话描述（Title），用人话概括这个 case 的问题，比如“将动漫评论误判为色情内容”。
案卷的主体，是完整输入（Input），即导致错误的完整用户输入、上下文，以及当时使用的 Prompt 版本号；连同错误输出（Erroneous Output），即模型给出的完整的错误答案；再加上期望输出（Expected Output），即理想中正确的答案应该是什么样的。最后这一条非常重要，它定义了优化的目标。
根因分析（Root Cause Analysis）也要落在记录里，按上一节的诊断流程，分析出导致这个错误的根本原因。比如打上 #Instruction_Ambiguity、#Competency_Gap 这样的标签。
收尾时，还要记下修复状态（Status），比如“待处理”“修复中”“已修复-待验证”“已加入回归集”，以及修复方案链接（Solution Link），指向为了修复这个问题而提交的那段代码或 Prompt 的 Pull Request。
如何使用 BAD Case 库：驱动修改、快速验证、防止回归
这个库不能只记录、不使用。它应该深度地、自动化地融入到日常的调优循环中。
它可以直接驱动修改。开始一次新的优化任务时，第一步不应该是去修改 Prompt，而应该是先从这个库里，挑选一个或几个最具有代表性的、状态为“待处理”的 BAD Case，然后为它们编写一个自动化测试用例。这个测试用例会断言，当输入是 BAD Case 的输入时，输出不应该是那个错误的输出，而应该是（或者接近）那个期望的输出。现在，运行这个测试，它应该是失败的（红色）。任务就从一个模糊的“优化 Prompt”，变成了一个极其明确的工程任务：“让这个红色的测试用例，变绿。”
它也用来快速验证效果。修改完 Prompt 后，第一步不是去跑那个完整的、可能需要半个小时的、包含几百个问题的评估集，而是先运行为那几个 BAD Case 编写的单元测试。如果连这几个目标问题都解决不了，那说明修改是无效的，根本不用浪费时间去跑完整的评估。这个快速的反馈循环，能极大地提高调优效率。
更重要的是，它还能防止回归。当修改成功地让那几个新的测试用例“变绿”了之后，必须立刻用所有其他的、已经标记为“已加入回归集”的 BAD Case 的测试用例，去完整地跑一遍。这是为了检查，这次修改有没有在修复一个问题的同时，让另一个已经解决的老问题重新出现。
这个过程，其实就是软件工程中测试驱动开发（TDD）和回归测试的核心思想，在 Prompt 工程领域的落地应用。
BAD Case 库随着时间的推移，会变得越来越丰富，越来越有价值。它完整记录了 Prompt 系统从问题频出到稳定可靠的全过程。
每一次准备上线一个新的 Prompt 版本时，都让它先通过这个包含了所有历史教训的回归检验。全部通过，才有依据按下“发布”按钮。
这种基于 BAD Case 分析的、小步快跑的迭代方式，能让调优过程从不确定的反复尝试，变成有步骤、可验证的工程流程。
16.5 在真实流量上做 A/B 测试
经过了前面所有的内部诊断、修改和验证，新版 Prompt 在“黄金评估集”和“BAD Case 库”上，都表现完美，所有的离线指标都显示，新版本比老版本，有了显著的提升。
先别急着全量上线，还需要最后一步验证。
因为那些离线的评估集，无论做得多么逼真、多么全面，都只是对真实世界的一种“模拟”。真实的用户，他们的提问方式、他们的关注点、他们的行为模式，永远比预想的复杂，没有人能预测，他们会输入什么样的极端问题。
在把新版 Prompt 推给全部用户之前，必须先在一小部分真实流量上验证效果。在 LLM 应用领域，这个方法就叫A/B 测试（A/B Testing）。
A/B 测试的思想很简单，但操作起来，需要极其严谨。真实的用户流量，通过一个流量分配系统，随机地分成两部分（或者多部分）。一部分用户（比如 90%），继续使用线上稳定运行的老版本 Prompt，也就是对照组 A。另一小部分用户（比如 10%），在他们完全不知情的情况下，开始使用那个经过了充分验证的、寄予厚望的新版 Prompt，也就是实验组 B。
接下来让系统并行地跑上一段时间（比如一周或两周，具体时间取决于流量大小），同时持续收集这两组用户的各种行为数据和反馈。最后，用统计学的方法，客观地比较，新版 Prompt 到底是不是真的比老版本“更好”。
A/B 测试到底在“测”什么？别只盯着准确率
在 A/B 测试中，需要关注两类指标，一类是业务指标，一类是系统性能指标。
第一类是业务核心指标（Business Metrics），这是产品经理和老板最关心的，它直接反映了 Prompt 优化，有没有带来真金白银的业务价值。如果这个 AI 是一个电商导购机器人，就看转化率（Conversion Rate），用了新 Prompt 的那一组，用户的点击购买转化率，有没有显著提升？如果面对的是聊天场景，就看用户满意度（Satisfaction Rate）。聊天界面通常会有“顶”和“踩”两个按钮。用了新 Prompt 的那一组，收到“顶”的比例，有没有更高？收到“踩”的比例，有没有更低？这是最直接的用户反馈。
业务指标还包括任务完成率（Task Completion Rate）和对话轮数（Session Length）。如果这个 AI 是一个多轮对话的任务机器人（比如订票、报修），那么用了新 Prompt 的那一组，用户能够成功走完整个任务流程的比例，有没有提升？中途放弃的比例，有没有下降？对话轮数这个指标则比较微妙。有时候，对话轮数变长，是好事，说明用户更愿意和 AI 聊天了。有时候，又是坏事，说明 AI 总是听不懂话，需要用户反复澄清。要结合具体场景来分析。
第二类是系统性能指标（System Metrics），这是工程师必须持续盯住的，它关乎系统的稳定和成本。先看平均延迟（Average Latency），新 Prompt 是不是因为变得更长、逻辑更复杂，导致 AI 的平均响应时间，从 2 秒变成了 5 秒？如果是这样，那就算准确率再高，用户可能也已经因为等得不耐烦而流失了。
再看 API 成本（API Cost），新 Prompt 平均每个请求消耗的输入和输出 token 数量，是不是急剧增加了？要计算一下，业务指标提升带来的收益，能不能覆盖掉这部分新增的成本。还有错误率（Error Rate），新 Prompt 有没有更容易触发模型的“内容安全策略”（比如误判成了有害内容），导致返回错误的概率增加了？或者，有没有更容易导致下游的解析器（比如 JSON 解析器）出错？
一个成功的实验，必须两类指标都达标。一个 Prompt，虽然让用户满意度提升了 2%，但却让系统延迟增加了 50%，成本增加了 80%，那它很可能依然是一个失败的、不可上线的改动。
统计显著性：区分真实提升与随机波动
在分析 A/B 测试结果时，有一个非常重要的概念，必须理解，否则数据的随机波动很容易骗过你，让你得出错误的结论。这个概念，叫统计显著性（Statistical Significance）。
假设 A/B 测试跑了一周，收集了足够多的样本。数据显示，实验组 B 的转化率是 5.5%，而对照组 A 的转化率是 5.0%，B 比 A 高了 0.5%。是不是就可以打开 PPT，写上“实验大获成功，新版 Prompt 带来 10% 的相对提升！”了？
不一定。
这个 0.5% 的提升，有可能是因为新 Prompt 确实厉害，但也有可能，它纯粹就是因为运气。可能在那一周里，随机分到实验组 B 的那批用户，恰好就是购买意愿更强的一批人，这个结果，可能只是一个随机的、毫无意义的波动。如果基于这个“幸运”的结果，就贸然全量上线，很可能下周就会发现，整体转化率并没有任何变化，甚至还下降了。
统计显著性，就是一套数学工具，用来排除“运气”这个干扰因素。它通过一系列的数学计算（比如 T 检验、卡方检验），来判断观察到的这个差异，到底有多大的可能性，是真实有效的，而不是随机产生的。
通常的做法，是计算一个叫做p-value的值。不需要深入理解它背后的复杂公式，但要记住它的含义，p-value 代表了，如果 A 和 B 两个版本实际上没有任何差异，有多大的概率，会因为随机性，而观察到当前看到的这个（甚至更大的）差异。
所以，p-value 越小，就说明观察到的差异，越不可能是随机因素导致的，实验结果就越“显著”，越可信。在互联网行业，惯例是，当 p-value < 0.05 时，就认为这个实验结果是统计显著的。这意味着，有 95% 以上的信心，认为这个差异是真实的，而不是运气。
具体的统计学公式这里不展开，市面上有很多成熟的 A/B 测试平台（比如 Optimizely、VWO）和开源的计算工具，可以自动完成这些计算。但有一个意识必须建立起来，任何没有经过统计显著性检验的 A/B 测试结论，都是在耍流氓。
只有当 A/B 测试在跑了足够长的时间、积累了足够多的样本量之后，明确显示新版 Prompt 在核心业务指标上，带来了统计显著的正向提升，同时又没有让系统性能指标变得无法接受，才有依据把实验组的流量，从 10% 逐步放大到 50%，再到 100%，完成这次上线。
16.6 从用户反馈中持续改进
新版 Prompt 经过了内部评估和线上 A/B 测试的双重验证，全量上线了，各项指标都达到了预期。
但上线不是这项工作的结束，而是持续优化的开始。
一个在生产环境长期运行的系统，优化是持续的。因为外部的世界在不断地变化，用户的需求在变，新的业务场景在出现，甚至底层依赖的大模型，每个月都在发布新的版本，其行为可能会发生意想不到的“漂移（Drift）”。
这就必须建立一个持续的、自动化的反馈和学习机制，让 Prompt 系统能够持续地从真实的用户交互中获取改进依据，不断迭代。
这个机制，就叫人类反馈闭环。
它的核心思想，是把每一次线上失败，都变成一次改进的机会，而这些改进的线索，来自真实用户的反馈。
顺带把一个容易混淆的近亲概念辨析清楚。人类在环（Human-in-the-Loop, HITL）说的是另一件事。它指的是，在系统运行的敏感、高风险节点上，主动让流程暂停下来，把最终的决策权交给人。落到实处，就是 AI 客服拿不准时转接人工坐席，就是 Agent 在执行转账、删数据这类关键动作之前，必须等一个人点下“批准”。两者都相信人的判断，但介入的时机完全不同。反馈闭环是事后收集、离线反哺；人类在环是事中把关、在线放行。这套事中把关的机制，第 22 章讲 Agent 编排时会正面展开。
反馈闭环的构成
这个闭环，通常由以下几个部分构成，它需要产品、研发和运营的紧密配合。
起点是无处不在的反馈收集。必须在产品界面上，为用户提供最简单、最直接、最无痛的反馈渠道。最基础的是“顶/踩”按钮（Thumbs Up/Down），它也是用户最愿意使用的。用户对每一个回答，都可以给出一个简单的二元反馈，也是衡量线上效果的最重要的“北极星”指标之一。在用户点击了“踩”之后，不要就这么算了，可以在旁边弹出一个小输入框，用友好的文案引导用户：“非常抱歉没能帮到您，可以简单告诉我们，您觉得哪里不好吗？”这是一句话文本反馈。
更进一步，还可以允许用户“再编辑”，直接在 AI 的回答上，进行修改，然后提交一个他们认为“更好”的版本。这种数据非常宝贵，因为它直接说明了，用户期望的答案是什么样的。
收集之上，是智能化的数据标注与分析。通过各种渠道，收集到了海量的、原始的用户反馈数据。这些数据，是混杂着情绪和噪音的，需要一个半自动化的流程，来对它们进行清洗、聚类和标注。可以定期地（比如每天），把所有用户“踩”过的，或者用户提交了修改建议的问答对，都导出到一个内部的标注平台。然后，先用一个 LLM，对这些 BAD Case 进行一次预标注和聚类，比如让 LLM 自动地把这些失败案例，归因到“答案事实错误”“答案不完整”“引用来源错误”“回答风格不佳”等预设的类别中。最后，运营同事，或者工程师本人，对这些经过了预处理的数据，进行快速的人工审核和修正。
闭环的关键，是多路径的反哺与优化。这些经过了分析和标注的、高质量的 BAD Case，可以用在系统的不同环节。最直接的是反哺 Prompt 优化，可以把它们加入到回归测试集中，扩充 BAD Case 库，让回归覆盖更完整，防止老问题复发。
如果发现某一类问题，模型总是出同样的错误（比如，总是把“年假”和“病假”搞混），可以从这些用户反馈中，提炼出一个经典的“错误-正确”示例对，把它作为一个新的 Few-shot 示例，加入到 Prompt 里，去“教会”模型，以后不要再犯这种错了；有时候，用户的反馈，会暴露一些设计时完全没有想到过的“边界情况”，还可以根据这些反馈，在 Prompt 里，增加一条新的规则或约束。
反哺的路径不止 Prompt 一条。有时候，模型回答错误，不是 Prompt 的问题，而是 RAG 知识库本身就错了，或者过时了。用户的反馈相当于一套分布式的勘误机制，能帮助发现并修正数据源里的问题。如果有对模型进行微调（Fine-tuning）的计划，那么这些经过了人工审核和修正的、高质量的“问题-期望答案”对，就是最宝贵的、可以直接用来进行指令微调的训练数据。
通过这样一套“收集 -> 分析 -> 反哺”的持续循环，Prompt 系统就不再是一个静态的、发布后就一成不变的“软件”，它会变成一个能够持续学习、持续改进的系统。
每一次打开标注平台，看到的那些来自真实用户的负面反馈，不再是只用来解释线上事故的材料，而是让系统改进的输入。
16.7 自动化提示词优化方法概览
前面讲的“诊断→假设→修改→验证→回归”五步循环，靠工程师手动驱动。当 Prompt 数量上规模、每条 Prompt 都要在几十个任务上反复迭代，单纯靠人手写修改、跑评估集、对比效果，效率会迅速见顶。近几年学术界和工业界陆续推出了几种把这条循环部分自动化的方法。目标一致。让模型自己，或在外部评分函数的指引下，去搜索更好的 Prompt。下面把最具代表性的四种串起来看一遍，厘清原理、适用场景，以及与人工五步循环的衔接关系。
四种主流方法的原理
APE（Automatic Prompt Engineer）是最早引起关注的工作之一，论文 2022 年 11 月在 arXiv 发布（Zhou et al., arXiv:2211.01910，ICLR 2023）。核心思路很直接，把“指令”当作待搜索的“程序”，先让一个 LLM 针对任务描述批量生成候选指令（一次性产出几十到上百条），再用预先准备好的“输入-期望输出”小样本集作为评分函数，从这些候选里挑出得分最高的那条。
后续工作把它扩展到对候选指令做“改写-打分-再改写”的迭代搜索。优点是原理透明、实现简单，几行 Python 就能搭起来；局限在于搜索空间天然受限于“初始 LLM 能想到的措辞”，容易卡在局部最优。
OPRO（Optimization by PROmpting，Google DeepMind，arXiv:2309.03409，ICLR 2024）走得更远一步，把“优化器”这个角色也交给 LLM。做法是构造一段特定的元 Prompt，把当前最优的几条候选指令、它们各自的得分，以及任务描述一起塞进去，让 LLM 推理出“应该往哪个方向改”的下一批新指令，再把这些新指令加进候选池继续评估。
论文报告在 GSM8K（小学数学应用题）上比人工 Prompt 高出最多 8%，在 Big-Bench Hard 上高出最多 50%。优势是搜索过程对“指令措辞”和“推理策略”同时敏感，更容易跳出措辞层面的局部最优；代价是每轮都要调用两次 LLM（一次生成新指令，一次评估），成本要算清楚。
DSPy（Stanford NLP，2023 年起持续迭代）换了一个完全不同的角度。它不让人手写 Prompt，而是把任务抽象成“Signature（输入字段→输出字段的类型签名）+ Module（如何执行的策略：直接预测、CoT、ReAct 等）+ Optimizer（用训练样本和指标去搜索最优的指令和示例）”。调优器（BootstrapFewShot、MIPROv2、GEPA 等）会根据一组带标注的样本，自动去“编译”出最适合当前任务的 Prompt 与少样本示例。
真正贡献是把 Prompt 工程从“写字符串”变成“编程序”，让 Prompt 和代码一起被版本管理、被测试。局限是学习曲线较陡，需要先理解“声明式签名”这套抽象，对纯自然语言型的临时性需求反而显得过重。
其中的 GEPA 值得单独点一句。它把候选 Prompt 当成一个种群来进化，采样完整的执行轨迹（推理、工具调用与工具输出），用自然语言反思来诊断败在哪里、提议怎么改，再把帕累托前沿上各有胜出的候选交叉组合。论文报告它在六项任务上比强化学习基线 GRPO 平均高 6%、最高高 20%，采样轮次最多只有后者的三十五分之一；比上一代优化器 MIPROv2 高出 10% 以上，AIME-2025 上高出 12%，这项工作被 ICLR 2026 接收为口头报告。对工程团队的直接含义是，任务只要有稳定的评分函数，自动调优器搜出的指令加示例组合，已经经常好过人工反复手调的版本。
PromptWizard（Microsoft，arXiv:2405.18369，2024）走的是“反馈驱动自我进化”路线。在每一轮迭代中让 LLM 先对当前 Prompt 做“突变”，产生若干变体；再用一个“批评器”对变体打分、生成改进意见；接着用这些意见去反向合成新的、针对性的少样本示例，与指令一起再优化。亮点是把“指令优化”和“示例优化”放在同一个反馈循环里交替推进，比单独优化某一项更彻底。
适用场景是有一定规模的训练集、且对少样本示例质量敏感的复杂任务。局限是反馈链路较长，迭代一次成本可观，需要在生产环境里评估“省下的人工调优时间”和“多花的 API 费用”哪边占优。
与人工五步循环的关系
把这四种方法与 16.1 节的人工五步循环放在一起对照，能看清各自的定位。APE 与 OPRO 主要是把“假设→修改”这两步半自动化：候选 Prompt 由模型生成或改写得来，人工要做的只剩“准备评估集”和“选定评分函数”。DSPy 与 PromptWizard 进一步把“验证→回归”也吸收进来，只要训练集与指标稳定，就能持续跑出新版本。但这并不意味着人工循环可以被替代。评估集要由领域专家构造，评分函数要由人来定义，最后的发布决策也必须有人来拍板。自动化方法省下来的是“在既定评分下反复试措辞”那部分枯燥劳动，让人能集中精力去做“评分函数本身是否合理”“业务目标是否对齐”这种更上层的工作。
收束点睛
自动化提示词优化是一条值得长期跟踪的技术线，落地时建议从小处起步。先在某个反复手调、成本可接受的 Prompt 上跑一遍 APE 或 OPRO，验证自动化版本确实优于人工基线，再决定是否接入正式流程。在这个过程中，评估集的质量永远比优化器的花哨程度更重要。一套精心设计的评估集和指标，是任何自动化方法真正发挥价值的前置条件。
本章总结 调优是持续的系统工程
这一章，从一个线上事故开始，讲了一套完整的系统化调优流程。
用系统化的方法诊断问题的根源，而不是盲目地修改；在“巨石”和“微服务”这两种架构方案之间，做出权衡；把失败案例沉淀成BAD Case 库；用A/B 测试的统计方法，替代“我感觉”的主观判断；最后，还建立了一个持续运转的人类反馈闭环，让系统能够不断改进。
Prompt 调优，远远不是修改几个词、几句话那么简单，它本质上是一项跨学科的系统工程。它要求对指令里的每一个细微歧义都保持敏感，一句不起眼的话，可能在某个意想不到的 case 上明显改变输出；它要求按软件架构的标准去设计 Prompt 的结构，让它可维护、可扩展、可测试，而不是内部耦合成一团的“巨石”；它要求建立起量化的评估体系，把每一次决策都建立在数据和统计学之上，而不是“感觉”；它还要求能从用户看似琐碎的反馈里，找到改进系统的线索。这四种能力，本来分属不同的工种，但在这里，必须都掌握。
这很难，真的很难。它不像写一段算法，有明确的对错，而是充满了灰度、权衡和不确定性，需要付出大量的、枯燥的、反复的努力。
但这也正是这份工作的价值所在。每一次通过系统性的分析，定位到一个隐藏得很深的、导致系统行为异常的 bug，然后用一个可能只改变了几个词顺序的 Prompt 修改，让系统的核心指标得到提升，这种成就感是实实在在的。
所以，调优不是一件不得不做的杂活，而是一项需要持续投入的系统性工作。
在这个过程中积累下来的，不仅仅是 Prompt 本身，更是一名工程师追求准确、尊重数据、系统思考的工作习惯。
参考资料
- OpenAI (2025). Introducing GPT-5. https://openai.com/index/introducing-gpt-5/
- Anthropic (2025). Introducing Claude Opus 4.5. https://www.anthropic.com/news/claude-opus-4-5
- Anthropic. Using the Messages API（含 Prefilling Claude's response 一节，说明 Claude 4.6 及之后的模型不再支持预填充）. https://platform.claude.com/docs/en/build-with-claude/working-with-messages
- OpenAI. Function calling（API 文档指南，示例同时覆盖 Responses API）. https://platform.openai.com/docs/guides/function-calling
- OpenAI. Function calling in the OpenAI API（帮助中心，说明 Responses API 统一了此前分布在 Chat Completions API 与 Assistants API 中的能力）. https://help.openai.com/en/articles/8555517-function-calling-in-the-openai-api
- Anthropic. Tool use overview（Claude Platform Docs）. https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview
- Google. Gemini API: Function calling. https://ai.google.dev/gemini-api/docs/function-calling
- TestRail（测试用例管理工具官网）. https://www.testrail.com/
- Optimizely（实验与 A/B 测试平台官网）. https://www.optimizely.com/
- VWO. What is A/B Testing? https://vwo.com/ab-testing/
- Zhou, Y., Muresanu, A. I., Han, Z., Paster, K., Pitis, S., Chan, H., & Ba, J. (2022/2023). Large Language Models Are Human-Level Prompt Engineers (Automatic Prompt Engineer, APE). ICLR 2023. arXiv:2211.01910. https://arxiv.org/abs/2211.01910
- Yang, C., Wang, X., Lu, L., Liu, H., Le, Q. V., Zhou, D., & Chen, X. (2023/2024). Large Language Models as Optimizers (Optimization by PROmpting, OPRO). ICLR 2024. arXiv:2309.03409. https://arxiv.org/abs/2309.03409 （Google DeepMind）
- Khattab, O., Singhvi, A., Maheshwari, N., Zhang, Z., Santhanam, K., Vardhamanan, S., et al. (2023). DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines. Stanford NLP. 项目文档 https://dspy.ai/ ；GitHub 仓库 https://github.com/stanfordnlp/dspy
- Agarwal, E., Singh, J., Dani, V., Magazine, R., Ganu, T., & Nambi, A. (2024). PromptWizard: Task-Aware Prompt Optimization Framework. Microsoft. arXiv:2405.18369. https://arxiv.org/abs/2405.18369 ；开源代码 https://github.com/microsoft/PromptWizard
- Agrawal, L. A., Tan, S., Soylu, D., et al. (2025). GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning. ICLR 2026 Oral. arXiv:2507.19457. https://arxiv.org/abs/2507.19457 ；开源代码 https://github.com/gepa-ai/gepa