什么是提示工程？优化大模型输出

提示工程，是一门设计输入——指令、上下文、示例与输出契约——使语言模型能够稳定、可重复、可规模化地产出你所依赖的结果的学科。它常被描述为「好好跟模型说话」，这种说法既低估了它，更糟的是，让它听起来不可度量。做得对的话，它更接近于"为一个概率系统做接口设计"：你规定任务、约束输出空间、提供证据，然后用一组用例测试这份规格说明，直到它的行为变得可预测。

它在商业上重要，是因为同一个模型，被提问的方式不同，产出质量会有实质性差异。这种方差，正是"在演示中令人印象深刻的试点"与"在真实用户面前活下来的系统"之间的差别。本文讨论提示工程是什么、哪些技术确有可度量的帮助、如何评估提示而不是靠猜，以及——同样重要的——提示工程在哪里不再是合适的工具，而应该由函数调用接手。

到底什么是提示工程？

提示（prompt）是模型接收到的全部输入：设定角色与约束的系统指令、用户的请求、任何检索到的上下文、任何示例，以及累积的对话。提示工程就是有意地组合这五者的实践。

• 系统指令。常设的任务简报：模型是谁、必须始终做什么、绝不能做什么。这一层跨请求保持稳定，是策略的栖身之处。
• 任务指令。具体请求，写成带明确成功条件的祈使句，而不是写成一个话题。「总结一下」是话题；「用三条要点总结，每条不超过 20 字，只使用所给文本」才是任务。
• 上下文。模型必须使用的证据——检索到的文档、表结构、客户记录。你往这里放什么，比你在别处写什么更能决定结果的落地性。
• 示例。展示模式的输入-输出配对样例。这是影响格式一致性与语气的最强杠杆。
• 输出契约。对答案形态的显式声明——JSON schema、markdown 标题、要点数量、单位，或在无法回答时应输出的字符串。

最有帮助的心智模型是：你不是在说服模型，你是在约束它。你在提示里留下的每一处歧义，都是模型会通过采样来解决的一个自由度；而采样带来的选择，正是让输出在多次运行之间不一致的原因。

为什么提示结构会改变模型输出？

因为语言模型不是在检索答案，而是在延续一种由它面前的文本所条件的模式。由此产生三个推论，每一个都对应一项技术。

顺序很重要。模型对上下文窗口开头与结尾的权重高于中部。请把指令和输出契约放在最前，把证据放在中部，把具体问题放在最后——并在模型开始生成的位置重复关键约束。

示范胜过描述。给出三个正确的样例，比写三段描述更能可靠地传达一种格式。样例把描述转化成模型可以延续的模式，这也正是少样本提示在格式类任务上带来阶跃式提升、而在推理类任务上只带来边际改善的原因。

推理受益于被外化。要求模型先分步思考再作答，能提升多步问题的准确率，因为中间步骤会成为条件化最终输出的那段上下文。收益是真实的但有边界：它在算术、逻辑与多跳问题上帮助最大，在简单检索或分类上帮助最小——在那里它只增加成本，不增加准确率。

还有第四个较少被讨论的推论：随着同时施加的约束数量增加，指令遵循能力会退化。十条规则放在一个提示里，并不是每条都被执行得和一条规则时一样好——而是每条都被执行得更差。当一个提示的硬约束超过大约十二条时，请把任务拆成多个阶段。

哪些核心技术真正起作用？

按在典型企业任务上的实测效果排序，并附上诚实的保留意见。

检索增强生成（RAG）。把相关原文放进上下文，是任何依赖"模型未训练过"或"会随时间变化"的事实的任务中，最大的单项准确率杠杆。它还让答案可审计，因为你可以引用被使用的段落。失效模式在于检索质量：切分不当或向量匹配太弱，会把错误证据放进上下文，而模型会忠实地使用它。

少样本样例。两到五个覆盖数据变化的样例，能大幅改善格式遵循与语气一致性。要精心挑选；随机采样的样例教的是噪声。

显式输出契约。要求一个 schema，并把 schema 提供给它。带校验与修复循环的结构化输出，能把一个散文生成器变成其他系统可以消费的组件。工程价值大部分在这里。

思维链与任务分解。要求先推理再作答，或把复杂任务拆成显式的子步骤。请有选择地使用：先度量它是否真的改善了你的任务，再决定是否为全部流量付出延迟与 token 成本。

受限解码与护栏。在可能之处限制词表，按 schema 校验输出，并在重试时把校验错误一起放进提示。这能把"通常正确"转化为"要么正确、要么拒绝"。

提示链。把大任务拆成一串更小的调用，每步都有窄指令和自己的输出契约。链式提升可靠性的原因是每一步的自由度更少，而且失败变得局部、可调试。

自一致性。采样多个补全结果，取多数或证据最充分的那个。成本高，但对于单次采样出错不可接受的高价值决策很有用。

如何写出一个有效的提示？

一个实操例子。合同审查提示的朴素版本长这样：

「总结一下这份合同，告诉我有没有风险。」

它在四个具体方面失败："总结一下"没有长度和范围；"风险"没有定义，于是模型自行选择；没有说明信息缺失时该怎么办；输出是散文，下游无法消费。生产版本是：

• 角色与范围。「你正在从买方视角审查一份商业供货协议。只考虑所给文本中的条款。」
• 任务。「识别对买方造成财务或运营敞口的条款。」
• 分类体系。「把每条归为以下之一：payment_terms、liability_cap、termination、indemnity、delivery_sla、data_protection、other。」
• 输出契约。「返回一个 JSON 数组。每项：{clause_ref, category, exposure (high|medium|low), explanation（不超过 30 字）, quoted_text}。若没有条款造成敞口，返回 []。」
• 落地规则。「引用条款原文。不得推断文本中不存在的条款。若某条款含义模糊，把 exposure 设为 medium，并在 explanation 中注明该模糊之处。」
• 示例。给出一条高敞口、一条低敞口的完整样例，严格使用上述输出 schema。

然后校验：解析 JSON、检查枚举取值、检查 quoted_text 是否在原文中逐字出现；若校验失败，带着错误信息重新提示一次。这个循环，正是"一个提示"与"一个系统"之间的差别。

少样本提示什么时候不再划算？

少样本提示的收益先递减、后转负，而转折点是可预测的。

值得用的情况：输出格式特殊或严格；任务涉及企业风格或领域惯例；分类边界微妙、示例能澄清它；或者模型必须在几种都说得通的表述之间做选择。两到五个样例通常就能捕获大部分收益。

不值得用的情况：任务是有明确 schema 的简单抽取或分类；样例太长、占用了你需要留给证据的上下文；或者样例不具代表性——此时它们会主动把模型引向错误的模式。

有害的情况：样例取自"手边方便"而非"有代表性"的样本，这是少样本出错最常见的方式。如果你的样例聚集在某一个类别上，模型就会过度预测该类别。请拿样例的标签分布去对齐真实分布。

务实规则是：先用严格的输出契约做零样本，然后度量。只针对你实际观察到的失效模式添加样例，并且每加一次就重新度量一次。没有度量的提示修改，是迷信。

如何在不靠猜测的前提下评估提示？

这是大多数团队失败的地方，也是回报最高的能力建设。四个组成部分：

留出测试集。五十到几百个真实输入，带期望输出；在无法给出期望输出时，带一份显式评分细则。它必须是留出的：针对你每天都盯着的那几个用例调优出来的提示，会对它们过拟合。

与任务相称的指标。抽取用精确匹配；分类用 F1 或分类别精确率与召回率；结构化输出用 schema 合法率与字段级准确率；RAG 用落地性与引用准确率；散文用人工或模型按细则评分。选定一个主指标和两个护栏指标，并在开始调优前把它们写下来。

回归纪律。在每次提示变更、每次模型版本变更时，以及按固定周期运行这套测试。模型供应商会静默更新模型；上个季度得分 94% 的提示，今天可能只有 87%，而你这边一行未改。

错误分析优先于聚合分数。下降 6 个点说明不了任何事；仔细检查二十个失败案例，才能准确告诉你该修什么。按类型把错误分桶——格式错、缺少落地依据、过度拒绝、拒绝不足、分类错误——然后修最大的那一桶。大多数提示问题，其实是两三种失效模式穿着不同的外衣。

为什么提示工程不足以支撑企业级的准确性？

因为提示能让模型把答案表达得好，却不能让答案为真。有三重限制是结构性的，不是靠更好的措辞能修好的。

事实性。一个被问到它没有的数字的模型，会编出一个可信的数字。没有任何指令能消除这一点；只有落地到检索到的证据，以及——当这个数字重要时——真正做一次计算才能解决。Gartner 被广泛引用的估算——数据质量低下平均每年给组织造成 1,290 万美元损失——提醒我们未经核实的数字在下游会造成什么代价。

算术与聚合。语言模型是在近似地做算术。让一个模型在上下文里把三十个数字加总，等于接受一个你绝不会容忍于电子表格的错误率。正确的设计是：让模型写查询或调用函数，由确定性系统来做算术。

时效性与新鲜度。训练截止之后发生的一切，都在模型知识之外。提示修不了陈旧；检索与工具调用可以。

正因如此，成熟的模式是「提示工程 + 工具」。提示负责行为——模型如何拆解问题、引用什么、如何格式化输出、何时拒绝；函数调用负责事实。蜂启咨询（Beehive Strategy）正是按这个分工落地：受治理的语义层定义有哪些工具可用、它们可以返回什么；MCP 连接器针对实时系统执行查询；提示则约束模型只能组合经过认证的度量，而不能发明度量。结果是答案既表达得好、又可验证——这是唯一能经得起审计的组合。

最常见的提示错误有哪些？

成功条件模糊。「写得简洁些」不是规格说明。请写「不超过 120 字」或「三条要点」。

同时施加过多约束。超过约十二条规则之后，每一条的遵循度都会下降。请拆成链式步骤。

把指令埋起来。关键约束应当放在开头，并在生成点之前再次重复。

没有设定拒绝路径。如果从没告诉模型答不上来时该做什么，它就会硬答。请显式规定兜底行为。

要求了输出契约却不做校验。要求返回 JSON，不等于拿到合法 JSON。请解析并校验每一个响应。

样例不具代表性。顺手拿来的样例，会把模型引向你手上恰好有的那些类别。

没有测试集就调优。这是根源性的错误；其他都还可救，这一条不行。

用提示去绕开数据问题。如果底层数据本身是错的或过期的，再好的提示也只会产出措辞更好的错误答案。

提示与函数调用、智能体是什么关系？

三者互补，分工稳定。提示负责理解：用户是什么意思、如何拆解、引用什么、如何呈现。函数调用负责执行：跑查询、取记录、做计算、写系统。智能体则增加一个规划循环，负责编排工具调用、观察结果，并在落地依据薄弱时重试。

对建设者来说，实操含义是：随着工具覆盖面改善，投入重心会从雕琢巧妙的指令，转向设计好的工具和好的 schema。一个命名清晰、描述精确、参数带类型的函数，比三段指令更可靠地教会模型。这也正是生产系统的演进方向从提示工程走向工具设计的原因——我们在另一篇关于「为什么函数调用正在取代提示工程」的分析中对此有详细展开。

团队应该如何把提示工程工业化？

把提示当代码对待，因为它们本来就是代码。

• 对每个提示做版本管理，与调用它的代码放在一起，并附变更日志说明每次修改的原因。
• 用参数化而不是字符串拼接。使用带类型槽位的模板，使用户输入无法重构指令。这也是你的提示注入防御：把不可信内容与指令分离，并把它标记为数据。
• 固定模型并记录版本。把模型标识与提示版本随每次响应一起记录，以便归因行为变化。
• 把评估套件自动化接入 CI，并在发生回归时阻断部署。
• 在生产环境做监控。跟踪 schema 合法率、拒绝率、延迟、单次请求成本，以及抽样质量分。任何一项漂移都是你的早期预警。
• 明确归属。无人拥有的提示，就是会静默腐坏的提示。为每个生产提示及其测试集指定负责团队。

做到这些，提示工程就不再是发烧友练的手艺，而成为一门有可度量错误率的工程学科——而只有这个版本，才配进入企业系统。