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

一个平台团队修改了意图分类器的 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。模型会处理剩下的事情。

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

每个严肃的工程团队在合并代码前都会运行一次 Lint 检查。ESLint 捕获未定义的变量，Prettier 强制格式规范，Semgrep 标记安全反模式。没有人会在不先运行至少一次静态检查的情况下将 JavaScript 发布到生产环境。

现在想想你的团队在发布一次提示词变更之前会做什么。如果你的团队和大多数团队一样，答案是：在 PR 里审阅一下，用肉眼扫描，也许手动测试几个输入用例，然后合并。你生产 AI 功能的系统提示词——控制模型如何为每一位用户表现的指令集——所受到的预部署审查比一次 CSS 改动还要少。

这个差距不是一个微小的流程疏漏。一项分析了 2,000 多个开发者提示词的研究发现，超过 10% 的提示词存在提示词注入攻击的漏洞，约 4% 存在可衡量的偏见问题——而这一切都在没有人察觉的情况下部署到了生产环境。自动捕获这些问题的工具已经存在，只是大多数团队还没有把它接入流水线。

在你最优秀的提示词工程师转岗到新项目六个月后，一个面向客户的 AI 功能开始出现异常。响应质量下降了，输出格式偶尔损坏，还有一个说不清道不明但持续存在的语气问题。你打开提示词文件，里面是 800 字的自然语言。没有变更日志，没有注释，没有测试用例。写下它的人确切地知道每一段话存在的意义。但那份知识已经消失了。

这就是提示词考古问题，它已经让团队付出了真金白银的代价。一家全美抵押贷款机构最近发现，文档分类的准确率下降了 18%，原因可以追溯到三周前有人在所谓的“常规工作流优化”中向提示词添加的一句话。两周的调查，大约 340,000 美元的运营损失。而那次修改的作者早已离开了。

2024年，加拿大航空的聊天机器人凭空发明了一项并不存在的丧亲票价退款政策。法院裁定该公司须对机器人的言论负责。根本原因并非传统意义上的模型幻觉——而是优先级反转。系统提示写着"乐于助人"，实际政策写着"遵循已记录的规则"。当用户询问赔偿问题时，模型悄悄地将"高效解决问题"置于"升级投诉"之上，而没有人在这一判断影响公司之前对其进行审计。

这就是利益相关者提示冲突问题。每个生产级LLM系统都至少有三个指令来源：平台层（安全约束和基础模型行为）、业务层（运营商定义的规则、合规要求、品牌声音）以及用户层（实际请求）。当这些层相互矛盾时——它们终将矛盾——模型会选出一个胜者。问题在于，这个选择是由你的工程团队有意为之，还是模型在无人察觉的情况下自行决定的。

你写了一个清晰的系统提示词。在测试环境中验证通过后，你将它部署上线了。三周后，一名用户发现你的安全约束并不能稳定触发——不是因为什么精妙的越狱手段，而是因为你在上个迭代中新增了一个400 token的上下文块，恰好把那条约束顶到了后面。模型就这样……忘了它的存在。

这就是指令位置问题——它不是你提示词里的一个bug，而是基于Transformer的模型处理序列的结构性属性。你提示词中的每一个token，并非获得相同的注意力权重。你放置指令的位置，以一种可量化的方式，决定着模型是否会遵从它。