164 篇博文 含有标签「prompt-engineering」

大多数提示词迁移在预发布环境看起来都很顺利。90% 的测试用例通过，新模型的响应感觉更清晰，演示也运行得很流畅。然后你上线了，不到两天，结构化输出解析器开始在 12% 的响应中抛出异常，一个面向用户的分类流水线开始返回错误标签，一个工具调用 Agent 在一个之前能正常处理的 Schema 上陷入了循环。没有人改动过提示词。是模型变了。

这就是提示词-模型耦合陷阱：在某个模型上可靠运行的提示词，会悄然积累对该模型特定行为怪癖的依赖，而这些依赖在迁移日之前根本看不见。

大多数团队发现 Schema 问题的方式都是错误的：下游服务开始返回乱码，仪表盘充斥着垃圾数据，经过 20 分钟的调试才发现，LLM 在三周前就开始悄悄地将其 JSON 包装在 Markdown 代码块中。没人注意到，因为应用程序没有崩溃 —— 它只是在静默地消耗格式错误的数据。

修复方法只是修改了一行提示词。但造成的损失是数周的错误分析和一次非常尴尬的复盘。

Schema-first 开发是防止这种情况发生的准则。这意味着在你编写任何提示词 Token 之前，先定义 LLM 输出必须遵循的确切结构。这并不是为了限制创造力；而是将输出格式视为下游系统可以依赖的契约，就像你在编写消费者端代码之前会先对 REST API 进行版本化一样。

你会花一个下午的时间来调整提示词（prompt）。你会移动一个句子的位置，把“classify”（分类）换成“categorize”（归类），添加一条关于边缘情况的注释，并针对笔记本中记录的少量示例进行抽查。到这一天结束时，提示词有了略微的改善——你觉得是这样。但你无法证明这一点。你没有一个可重复的基准。一周后，一位同事改动了几个词，整个系统就退化了。

这就是目前大多数团队提示词工程的现状。DSPy 是斯坦福大学给出的答案。与其手动编写指令文本，你只需声明你的 LLM 程序应该做什么，定义一个指标，然后让优化器为你编译实际的提示词。MIPRO——多提示词指令提案优化器（Multi-prompt Instruction PRoposal Optimizer）——是一种让这种方法能与人工编写的替代方案竞争（且通常优于人工编写方案）的算法。

当你的 API 成本飙升，有人建议“直接压缩上下文”时，这个方案听起来很简洁：输入更少的 token，支付更低的费用，获得同等的输出。LLMLingua 的基准测试显示，在数学推理上实现了 20 倍的压缩，而准确率仅下降了 1.5%。这听起来怎么会不好呢？

问题在于，这些基准测试衡量的是压缩后的上下文在干净、精心策划的测试集上的得分。它们没有衡量当你的智能体悄悄丢弃三轮对话前给出的约束、将代词解析到错误的实体，或者因为原始工具输出被总结掉而胡编乱造一个确切的文件路径时会发生什么。上下文压缩不仅仅是减少 token —— 它改变了模型实际看到的内容。而原始上下文与压缩版本之间的差距，正是你的系统注定会失败的地方。

一个平台团队修改了意图分类器的 Prompt，旨在“更好地处理复合问题”。只改动了一个句子。他们自己的评估套件（eval suite）变绿了——复合问题的准确率提升了 6 个百分点。他们在下午 3 点合并了代码。到下午 5 点，三个下游 Agent 团队开始收到告警：路由 Agent 将退款请求发送到了物流队列，摘要 Agent 在不同的边界处截断，而工单打标 Agent 开始输出一个没有任何 Schema 能识别的类别。那些下游团队中没有一个参与了评审。也没有人负责“意图 Prompt”的轮值。

这不是假设。当 Prompt 变成共享依赖却未成为共享 API 时，这就是必然发生的情况。提升一个团队指标的 Prompt 修改，可能会悄悄破坏另一个团队建立在其之上的假设。与破坏性的 API 变更不同，这里没有反序列化错误，没有 Schema 不匹配，没有 500 错误——下游只是开始做出微妙的、更糟糕的决策。

传统的 API 工程在几十年前就通过契约测试（contract tests）解决了这个问题。消费者发布它所期望的形状；提供者有义务保持该形状正常工作。Pact、消费者驱动的契约、共享 Schema——这是 HTTP 服务发布工程的正统做法。Prompt 也应该遵循同样的纪律，而大多数组织仍然像处理团队间传递的贴纸一样对待它们。

一个团队在路线优化任务上测试 Gemini 3 Flash，零样本准确率达 93%。他们开始添加示例，性能一路攀升——但在添加到八个示例时，准确率骤降至 30%。这不是噪声，而是少样本饱和曲线的猛烈反噬。这是大多数工程师只有在部署了一个四个示例时看起来正常、十二个示例时却出现问题的提示之后才会发现的故障模式。

"更多示例严格意味着更好"的直觉是错的。跨 12 个 LLM 和数十种任务类型的数据显示了三种截然不同的失败模式：稳定平台期（收益趋于平缓）、峰值回归（收益先升后崩）和选择诱导崩溃（更换示例检索策略后收益蒸发）。理解自己处于哪种模式，会改变你构建提示的方式、何时放弃少样本方案，以及是否应该转向微调。

你的团队在周二下午发布了一个提示词（prompt）修改。改动看起来很合理——你收紧了系统提示词，删除了冗余指令，并添加了更明确的语气指令。预发布环境（Staging）看起来没问题。你上线了。到周三早上，你的支持工单量翻了一番。在这次收紧过程中，你破坏了模型识别某类用户查询的能力，而这些查询以前是可以优雅处理的。你的 HTTP 错误率是 0%。你的仪表盘显示全绿。在人工查阅工单之前，这个问题是隐形的。

这是 LLM 生产系统的典型故障模式。提示词变更会静默失败。它们在产生垃圾内容的同时返回 200 OK。它们的性能下降方式是单元测试无法捕捉、错误率监控无法标记、仪表盘也无法体现的。解决方案不是在预发布环境进行更好的测试，而是将每一次提示词变更都视为一次生产部署，采用与关键代码发布相同的流量分片、回滚和监控纪律。

上个季度，一家中型AI初创公司的系统提示词中落地了一个单行变更。这个差异看起来无害：一位工程师收紧了关于响应长度的指令。审查者在两分钟内批准了它，就像批准一个变量重命名一样。48小时内，支持工单激增。模型开始在复杂查询的句子中间截断答案，而旧措辞几个月来默默处理的边界情况现在都失败了。原来的指令不仅控制着长度——它隐式地锚定了模型关于何时一个主题已经完成的判断。没有人捕捉到这一点，没有人去寻找它。

这就是当今提示词审查的核心问题：我们正在将代码审查的直觉应用于一个这些直觉大多数是错误的媒介。代码审查之所以有效，是因为被审查的工件是确定性的，语义可以从语法中恢复。提示词两者都不是。它的含义分布在模型的权重、训练数据以及推理时运行的随机采样中。你在屏幕上看到的差异只是你正在批准的变更的一小部分。

大多数团队在采用推理模型时都会做同一件事：把现有的系统提示词复制过去，指向 o1 或带扩展思考的 Claude Sonnet，然后期待模型升级完成剩余工作。基准测试分数上去了，生产准确率却原地踏步——甚至下滑。问题不在模型，而在于提示词的思维模型从未改变。

推理模型的工作方式与指令跟随模型截然不同。那些能从 GPT-4o 榨取性能的策略——精心设计的系统提示词、精选的 few-shot 示例、明确的"逐步思考"指令——都是为另一种推理架构设计的。把这些策略用在推理模型上，恰恰会限制那些让这类模型具有价值的核心能力。

本文是一份实用指南，聚焦于真正重要的差异以及切实有效的调整方法。

走进几乎任何一家拥有在线 LLM 功能的工程团队，问一个简单的问题：谁负责管理提示词（Prompts）？你会听到一阵停顿，然后是一个耸肩，接着是一个经不起推敲的回答。“产品经理写了第一个版本。”“PM 在上个迭代（Sprint）里改了一下。”“我觉得它在某个 Notion 文档里，或者可能是 agent.ts 里的那个 const SYSTEM_PROMPT。”提示词正在生产环境中运行。它决定了用户看到的内容，决定了智能体采取的操作，也决定了下季度收入图表中显示的数字。然而，它的治理覆盖面甚至不如那个没人愿意承认动过的 CSS 文件。

这就是影子提示词库：堆积如山的字符串——系统提示词、few-shot 示例、工具描述、路由规则、评估器准则——它们共同定义了产品行为，却集体缺乏代码审查、部署流水线、负责人、弃用策略和审计追踪。它们是你 AI 技术栈中最关键的承重构件，也是受监管最少的环节。

后果已不再仅仅停留在理论层面。现在有 98% 的组织报告存在未经授权的 AI 使用，近一半的组织预计在 12 个月内会发生影子 AI 事件。监管机构的步伐比治理速度更快：欧盟 AI 法案（EU AI Act）的高风险条款将于 2026 年 8 月生效，其中第 12 条明确规定，将输出结果与提示词及模型版本绑定的日志必须是自动生成的，而非设想中的。如果你的提示词散落在十几个代码库和一个 Slack 讨论串中，你拥有的不是审计追踪，而是隐患。

你的智能体中杠杆率最高的 prompt 并不在你的系统 prompt（system prompt）中。它是你六个月前在某个工具定义下写的那句描述，它随实现代码一起提交，之后就再也没动过。模型在每一轮对话中都会读取它，以此决定是否调用该工具、绑定哪些参数，以及当响应不符合预期时如何恢复。工程师将其视为面向人类的 API 文档，而模型则将其视为一个 prompt。

这两种视角之间的鸿沟，正是最糟糕的工具使用（tool-use）类 bug 的温床：模型调用了正确的函数名，传入了正确的参数，发出了正确的 API 调用 —— 但原因却是错的，场景是错的，或者它放着旁边更合适的工具不用。没有任何异常抛出。你的评估套件依然通过。这种退化（regression）只会表现为衡量智能体是否真正起到帮助的指标在缓慢下降。

你发布了一个新的平台级防护栏 (guardrail) —— 一条防止 AI 讨论竞争对手价格的规则。它在周一早上上线。到了周三，你最大的企业客户提交了一个支持工单：他们的销售助手 (他们曾精心调整该助手，以便为采购团队比较供应商选项) 停止工作了。他们没有更改任何东西。你更改了一些东西，而其影响范围 (blast radius) 在无形中波及了他们。

这就是多租户提示词问题 (multi-tenant prompt problem)。允许客户定制的 B2B AI 产品实际上是在运行一个分层指令系统，但大多数团队并没有将其视为一个系统。他们将其视为字符串拼接：获取平台提示词，附加客户的指令，也许再附加用户偏好，然后调用 LLM。模型会处理剩下的事情。

模型并不能处理好。它会默默地挑选一个赢家，而你直到有人投诉才会发现是哪一个。