大多数工程师将提示词（prompts）视为咒语——稍微修改一下措辞，寄希望于它能奏效，然后就此作罢。这在演示阶段（demos）没问题。但在生产环境中，这会导致系统表现不稳定：没人知道为什么模型在周二的表现与周一不同，一次常规的模型更新可能会悄无声息地破坏掉三个功能。正确的提示工程是一门学科，而不是一种仪式。本文涵盖了全栈内容：何时使用每种技术、基准测试（benchmarks）实际显示了什么，以及陷阱在哪里。
零样本与少样本：选择并非显而易见
零样本提示（Zero-shot prompting）——只需描述任务并让模型开始工作——的效果往往比大多数工程师预期的要好，而且其运作方式并不总是直观的。对于理解良好的任务（总结、翻译、事实性问答），零样本通常是正确的选择。通过示例增加复杂性并不总是有帮助。
经典的“零样本思维链”（zero-shot chain-of-thought）技巧——在末尾添加“让我们一步步思考”——在逻辑推理任务上经常优于少样本提示。这一简单的短语能将模型从模式匹配转向程序性推理。
当你需要一致的输出格式、特定领域的语气，或者仅靠描述过于模糊的细微分类时，少样本提示（Few-shot prompting）就大放异彩了。系统研究中一个令人惊讶的发现是：示例的正确性并没有你想象的那么重要。推动少样本性能的关键是标签空间（有哪些可能的类别）、输入分布（看起来像真实数据的现实示例）以及输出格式。一个包含稍微错误示例但格式正确的少样本提示，往往优于一组完美准确但格式不一致的示例。
决策树大致如下：
- 简单、通用的任务 → 首先尝试零样本
- 复杂的输出格式或 Schema → 少样本
- 推理或数学问题 → 零样本 CoT（“一步步思考”）
- 需要一致的语气/语调 → 带有 3–5 个锚点的少样本
- 推理模型（o3, o4-mini, Claude 3.5+）→ 两者都测试，不要假设少样本必胜
高级推理模型的一个注意事项：少样本示例可能会产生负面影响。这些模型具有强大的内部推理能力，少样本示例有时会使它们偏向于表面层面的模式匹配，而不是深层推理。务必进行基准测试，不要凭空假设。
思维链：基准测试实际显示了什么
在 Wei 等人（2022 年）展示了数学基准测试中的巨大收益后，思维链提示（Chain-of-thought prompting）成为了标配。但 2025 年的研究描绘了一个更微妙的图景，从业者应当对此有所了解。
沃顿商学院 GAIL 的一项研究在 25 次重复实验中，使用 8 个模型测试了 198 个博士级问题。结果如下：
- 非推理模型（如 Gemini Flash 2.0）：+13.5% 的准确率提升 —— 这很有意义，但伴随着 35–600% 的额外 Token 消耗
- 非推理模型（GPT-4o-mini）：+4.4% 的收益，在统计学上不显著
- 推理模型（o3-mini, o4-mini）：+3% 的收益，微乎其微
- 推理模型（Gemini Flash 2.5）：−3.3% —— 使用 CoT 比不使用效果更差
规律是：CoT 对非推理模型有显著帮助。对于推理模型，模型已经在进行内部思维链——要求它显式地执行通常只会增加 Token 浪费，有时甚至会因为强迫采用不同的思考路径而降低性能。
成本影响加剧了这一点。CoT 会增加 Token。在大规模应用中，处处使用 CoT 的提示词可能比有选择性使用的提示词贵 3–5 倍。在每日 100,000 次调用的情况下，差价可能达到每天 2,000–3,000 美元。
何时使用 CoT：多步骤数学、逻辑演绎、代码调试，以及任何需要中间推理过程可审计的地方。对于分类、查询、提取以及任何答案直接的任务，请跳过它。对于推理模型，在投入使用前进行基准测试——它可能会在没有帮助的情况下增加成本。
结构化输出：生产环境的可靠性问题
结构化输出提示是大多数生产环境 AI 漏洞（bugs）的所在地。各供应商提供的 JSON 模式（JSON Mode）保证了语法有效的 JSON —— 它不保证字段匹配你的 Schema、类型正确或值符合你的预期。在测试中运行良好的提示词可能会在模型更新后悄然失效。
三类故障始终存在：
字段不一致：字段名称在不同响应中的大小写、下划线或命名约定各不相同。userId vs user_id vs UserID —— 全是有效的 JSON，但在你的解析器中都会导致程序崩溃。
类型不匹配：数字被写成字符串，应为默认值处返回 null，布尔值被写成 "true"/"false" 字符串而不是实际的布尔类型。这些会导致强类型语言中的下游故障，调试起来令人抓狂。
格式泄漏：模型尽管被告知不要这样做，却还是将 JSON 包裹在 Markdown 代码块中。在起始符号 { 前有前导文本，在结束符号 } 后有结尾说明。这在基础模型和系统提示词更改后很常见。
行之有效的生产可靠性模式：
- 使用紧凑的 JSON 骨架进行提示，显示字段名称、类型和预期值 —— 而不是描述要生成什么
- 包含一个完整、正确的示例，演示包括边缘情况在内的每条规则
- 对于结构化任务，将 Temperature 设置为 0.0–0.1 —— 这是 LLM 行为中最明确的相关性之一。较高的温度会直接导致格式偏差
- 在消费输出前，根据你的 Schema 进行程序化验证
- 利用模型进行修复 —— 将验证失败的信息作为针对性的修复请求传回模型，而不是重新运行整个流水线
实现基于 Schema 的结构化提示的从业者报告称，JSON 提取 success rates 从约 60% 跃升至 95% 以上。Schema 强制的结构化输出（可通过 OpenAI 的 Structured Outputs API 获取）可以达到 >99% 的 Schema 依从性，并减少高达 60% 的解析/集成代码。
使用正确的工具：对于 OpenAI，优先选择原生 Structured Outputs（Schema 强制）而非 JSON Mode（仅语法）。对于 Claude，在提示词中使用明确的 Schema 和格式指令即可可靠工作，无需单独的模式切换。像 Instructor 和 Pydantic AI 这样的库可以处理超过 15 个供应商的重试/验证循环。
提示词敏感性问题（以及为什么它在生产环境中至关重要）
关于提示词敏感性的研究表明，在少样本（few-shot）场景下，仅格式变化就可能导致高达 76 个百分点的准确率差异。这不是因为模型改变了，也不是因为任务不同，仅仅是相同内容的不同格式化方式导致的。
这有两个实际意义：
首先，看似模型的能力限制，往往其实是提示词设计的问题。在断定 LLM 无法完成某项任务之前，请尝试系统化的调整：不同的指令措辞、显式 vs 隐式的格式要求、添加或删除示例、改变上下文区块的顺序。答案空间非常大。
其次，今天有效的提示词可能会在模型更新后失效。随着微调更新，模型的行为会发生细微变化。针对 GPT-4-0613 编写的系统提示词在处理特定输入时，可能会在 GPT-4-1106 上出现退化。这使得提示词回归测试成为了生产环境的必需品，而非可有可无的选项。
实际的缓解措施：
- 在版本控制系统中管理你的提示词版本 —— 将它们视为代码，而非配置
- 维护一套用于回归测试的输入/输出对“黄金数据集”（golden set）
- 每当你更新提示词或模型端点发生变化时，运行该数据集进行测试
- 在发布变更之前，将提示词测试覆盖集成到你的 CI 流水线中
值得了解的高级技术
**Self-consistency（自我一致性）**通过生成多条独立的推理路径并通过多数投票选择答案，来提高 CoT（思维链）的准确率。在困难的推理任务中，它能带来 5%–10% 的准确率提升，代价是 N 倍的推理调用。当准确率比延迟更重要时（如错误敏感的分类、法律分析、医疗数据提取），可以使用此技术。
**Tree-of-Thought（思维树）**对此进行了扩展，它使用 BFS 或 DFS 将推理探索为树状结构，并在路径失败时进行回溯。其计算成本很高。请将其保留给真正的多步规划难题，因为在这些问题中，线性推理链是不够的。
**Chain-of-Table（表格链）**对于结构化数据推理非常有价值。它不使用文本推理，而是将表格操作（添加列、选择行、分组、排序）作为中间步骤。在 TabFact 上比标准方法提升了 8.7%，在 WikiTQ 上提升了 6.7%。如果你正在构建财务分析、数据转换或任何处理表格的 LLM 流水线，这项技术目前被严重低估了。
**Meta prompting（元提示）**关注的是推理结构而非内容示例。你不是向模型展示正确的输出是什么样的，而是告诉它如何思考 —— 推理步骤的顺序、首先考虑什么、何时拒绝。这越来越多地应用于生产环境的系统提示词中，以在各种输入中强制执行一致的推理风格。
破坏生产环境提示词的五个常见错误
1. 容易引发幻觉的模糊指令。 “使其专业化”或“清晰地总结”不是指令，它们只是某种“感觉”。请定义你的具体含义：指定受众、格式、语气标记、包含什么、排除什么。模糊性是模型即兴发挥的机会。
2. 假设存在隐含的上下文。 除非你告诉模型，否则它不会保留关于你的产品、用户群或领域的知识。生成平庸、无用输出最常见的原因是提示词中没有包含相关的背景信息。每次都要明确说明上下文。
3. 缺失输出格式规范。 如果你的流水线以编程方式处理模型输出，请准确指定格式 —— 不仅仅是“返回 JSON”，而是“返回一个包含字段 X、Y、Z 的 JSON 对象，其中 X 是字符串，Z 是字符串数组”。模型不会猜测你的 Schema。
4. 复杂的格式要求缺乏示例。 对你想要的内容进行描述，不如给出一个你想要的内容示例有效。对于复杂的格式要求，一个正确的示例比三段文字指令更有用。
5. 过度调优导致的提示词脆弱性。 当你针对一个狭窄的测试集调优提示词时，它在真实输入面前会变得脆弱。通过在广泛的分布上进行测试来构建鲁棒性。如果你的提示词只在看起来像示例的输入上有效，那么它就不是一个生产就绪的提示词。
工程师忽视的成本与质量权衡
一个真实的对比：一个 2,500 token 的详细系统提示词与一个 212 token 的结构化提示词在同一任务上实现了同等质量。在每日 100,000 次调用下：
- 详细提示词：约 3,000 美元/天
- 结构化提示词：约 706 美元/天
这 76% 的成本降低来自于提示词优化，而非模型降级。大多数团队会首先优化质量（这是对的），但从未回头优化成本（这也是对的，但不够完整）。
从业者的启发式方法：先进行质量“爬坡”，再进行成本“下坡”。先用任何有效的提示词把输出做对。然后系统地缩短提示词长度，简化指令，并测试质量是否保持稳定。通常情况下是可以维持的 —— 因为许多提示词携带了模型并不需要的冗余上下文。
提示词工程在大局中的位置
在你需要求助于 RAG、微调或多智能体架构等更昂贵的解决方案之前，提示词工程可以交付大约 85% 的可实现改进。这个比例来自高营收 AI 公司的从业者 —— 这不是一个理论假设。
团队的成熟度曲线如下：
- 随机实验（大多数团队从这里开始）
- 模板标准化 —— 提示词之间保持一致的结构
- 系统化评估 —— 黄金测试集、回归跟踪
- 生产可观测性 —— 记录提示词和输出，监控漂移
- 持续优化 —— 降低成本、改进格式、调优行为
大多数团队处于第 1 阶段和第 2 阶段之间。达到第 3 阶段 —— 在 CI 中建立黄金测试集和回归测试 —— 是提升 AI 质量最高杠杆的组织投入。工具是轻量级的，难点在于纪律。
提示词工程不是一次性活动。它是一项持续的工程实践。那些以此为准则的团队 —— 对提示词进行版本控制、系统化测试、跟踪成本 —— 始终优于那些将提示词视为“咒语”的团队。