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

你刚接入的前沿模型对你的竞争对手早有定见。对于你产品旨在反驳的那些难题，它有一套默认答案。它对你所在的领域有一套“最佳实践”，而这些实践往往源于训练语料库中占据主导地位的内容；对于你在设计文档中反复纠结的每一个争议性决策，它都暗自偏向于传统做法。这些都不会出现在你的系统提示词（system prompt）中，也不是你写的。在涉及到你产品核心差异化的查询上，模型会先倾向于那些默认设定，而不是你告诉它的内容。

大多数团队在发布产品时，都把模型当成了一张可以任意配置的白纸。写好角色设定（persona），列出规则，粘贴品牌语气指南，运行几个能产生正确回答形式的 QA 提示词，然后就大功告成了。通过审核的提示词往往是处理简单查询的——在这些查询中，模型的先验认知（prior）恰好与你的预期相符。而那些真正有趣的查询，即如果产生通用回答就会让你的产品惨败的查询，几乎从未进入提示词迭代循环。在这些查询中，先验认知正在悄无声息地取胜。

200K token 的上下文窗口并不是真正的 200K token 窗口。将其填满，你刚刚付费使用的模型就会悄然变成一个更糟糕的版本——这种退化并非发生在“迷失在中间（lost in the middle）”所预言的中间位置，而是在右侧边缘，也就是近因偏差（recency bias）本应拯救你的地方。包装盒上的标签卖给你的是余量；而硅片卖给你的却是悬崖。

这是一种大多数团队尚未内化的不同失效模式。“迷失在中间”训练了一代提示词工程师（prompt engineers），让他们习惯于将关键指令放在开头，将关键问题放在结尾，坚信首因效应（primacy）和近因效应（recency）能确保信号得以传递。然而，当利用率接近宣称的窗口极限时，这种启发式方法会悄然失效。这种下降并非逐渐的、线性的，也与模型在半满状态下的表现不对称。一旦超过某个随模型而异的利用率阈值，你就进入了一个不同的运行机制，在 30K 时有效的提示词结构在 180K 时会彻底失败。

经济上的诱惑让情况变得更糟。如果你刚刚为百万 token 的窗口付费，那么使用它的压力是巨大的——你会倾倒整个代码库，喂入每一张支持工单，交给它季度财报，并让它找出重点。结果就是，你会得到一个看似推导严密、实则自信错误的答案，而在审计时它会瞬间瓦解。

一位队友提交了一个 PR，将你 Agent 的系统提示词（System Prompt）从 420 行重写为 380 行。Diff 是一片红绿交错的“惨状”：删除了段落、移动了章节、精简了语言。你批准了它，因为这些清理看起来很合理。一周后，退款请求的准确率下降了 8 个百分点，却没人能说出到底是哪一行导致的。

另一位队友在一条指令中添加了“简洁”（concise）这个词。Diff 只有三个字符。没人仔细审查它，因为几乎没有什么可看的。但这次修改导致 22% 的查询在工具调用（Tool-call）行为上发生了变化。

我接手时，我们客服智能体的提示词已经达到了 2,400 个 token，而编写它的工程师已经离职了。其中的每一条指令对于某些生产行为来说都是“承重的”，但没人能告诉我哪些才是关键。一条关于“在回答之前务必先复述用户问题”的条目看起来像是凑数的，直到我们删掉它后，CSAT（客户满意度）在一周内下降了四个百分点。事实证明，提示词就是规范（specification）。它既是实现（implementation），也是测试套件（test suite）——它是隐性的、未记录的，仅存在于那位已经离职的工程师脑中。

这就是“提示词即规范”的终局。提示词既是智能体应该做什么，也是它如何做，一旦提示词规模超过了单个作者的掌握范围，两者就会变得无法区分。你无法重构它，因为你不知道哪些行编码了需求，哪些行仅仅是暗示。你无法评审变更，因为没有可以与之对比的基准产物。你无法让任何人接手并负责它，因为负责意味着“最近阅读过全文并记得每一项条款存在的原因”，这是一项没人愿意批准的、长达六个月的投资。

“规范优先”颠覆了这种顺序。契约（contract）——输入、输出、不变量、错误情况、拒绝语义、升级触发条件——是一个先于提示词并约束每次修订的一等产物（first-class artifact）。对提示词的修改变成了针对规范的补丁（diff），而不是对规范本身的重写。这种转变听起来很官僚，直到你看到它所释放的潜力：评估（evals）源自规范而非反之，评审只需几分钟而非整个下午，最终能让新工程师在没有六个月学徒期的情况下直接接手整个模块。

工具描述不是文档。它是模型在每一轮对话中都会读取的 prompt，用于决定该工具是否触发以及如何触发。你不是在为对接该工具的开发者编写内容——开发者已经在 PR 中看到了 schema、类型和示例。你是在为一个从未见过这个代码库的随机读者编写内容，它在同一个上下文窗口中还拿着另外二十个工具描述，并且必须在下一次前向传播中选出一个。

大多数团队并没有意识到这一点。他们把 OpenAPI 摘要粘贴到 description 字段中，把 JSON Schema 贴在下面，然后就发布了。结果，agent 调用工具的次数过少，或者自信地调用了错误的邻近工具，又或者用了任何读过 schema 的人类都会觉得“显而易见”是错误的参数来调用正确的工具。团队责备模型，但模型读取的正是一字不差的你写的内容。

第一次验证器捕捉到糟糕的 LLM 输出时，感觉像是一场胜利。第二次，你会调整提示词以降低失败的可能性。到第二十次时，团队中没人能解释为什么提示词中存在那三个段落 —— 它们是早已被遗忘的事故留下的瘢痕组织，而模型在阅读警告上花费的 Token 比推理实际任务还要多。

这就是验证器陷阱。你添加的每一个事后防护（post-hoc guard）—— JSON 模式检查、正则表达式、内容分类器、第二个作为裁判的 LLM —— 都会对上游提示词施加反馈压力。提示词会增加防御性指令来安抚验证器，验证器反过来又会捕捉到一类新的失败，接着你又会添加更多指令。每一次迭代在局部看来都是合理且明智的。但总体而言，系统变得越来越慢、越来越贵，而且在原本设计的任务上的表现也明显变差了。

一个平台团队对他们的摘要服务的系统提示词（system prompt）进行了一行细微的调整。没有代码审查，没有迁移指南，没有版本更新——这“仅仅是一个提示词”。两周后，法律产品团队发现他们的合规自动脱敏功能一直在静默地泄露姓名。调查耗费了一个冲刺（sprint）。修复很简单。损害的是信任。

这是 AI 变更日志问题的缩影。行为现在是你系统的一等输出（first-class output），当提示词、模型、检索器或工具模式（tool schemas）发生变化时，行为也会随之改变——而这些变化都不会出现在消费方应用的 git diff 中。如果团队像对待后端部署那样对待 AI 更新，认为在 #releases 频道发一条 Slack 消息就足够了，那么他们最终会重蹈 2010 年代早期那种“我们先上线，稍后再告诉 QA”工作流的覆辙。

当你从一位刚刚离职的工程师那里接手一个 AI 系统时，会有一种特殊的恐惧感袭来。系统提示词长达数百行，有一个叫 evals/ 的文件夹里存着 340 个测试用例却没有 README，代码中的注释写着 # 不要修改这里——找 Chen 问 而 Chen 已经联系不上了。

你不知道为什么客服机器人被禁止在星期二讨论定价，不知道哪些评估用例是为了捕捉六个月前的回归问题而写的，哪些只是随机示例，也不知道屏蔽某些产品类别的护栏究竟是法律要求、合规实验，还是某人因为某个副总裁看到了一条糟糕的输出而随手加上的。

系统还在运行。目前如此。但你无法安全地修改任何东西。

三个词差点毁掉一个生产功能。一个团队在例行的文案优化中，向一个面向客户的 prompt 添加了"请简洁回答"。四小时内，结构化输出错误率急剧攀升，下游解析崩溃，创收工作流陷入停滞。修复方案很简单——回退变更。噩梦在于他们根本不知道是哪次变更导致了问题，因为这个 prompt 以硬编码字符串常量的形式存在，没有版本历史，没有测试，也没有回滚机制。这个事故本可以通过大多数团队至今仍未构建的基础设施来预防。

Prompt 现在是你系统中最重要、却治理最薄弱的代码。

三个词。就这么多。

一个团队在现有 prompt 中添加了三个词，目的是改善"对话流畅性"——这个调整在 playground 里看起来无害。几个小时内，结构化输出错误率急剧攀升，一个创收工作流停止运作，工程师们争相还原 prompt 改动前的内容。没有版本历史，没有回滚机制，只有一条 Slack 消息，来自某个"大致记得"内容的人，以及一份与 Google 文档中过时副本的 diff。

这不是假设场景，而是几乎每个规模化交付 LLM 功能的组织都在重复经历的模式。Prompt 从应用代码中的字符串起步，经过非正式编辑演化，积累了无文档记录的微小调整，最终到达无人确信生产环境里运行着什么、也不知道为何如此表现的状态。

解决方案不是一个新工具，而是对团队一直以配置文件方式对待的东西施加工程纪律。

大多数团队都是通过惨痛的教训才发现系统提示词蔓延（System Prompt Sprawl）问题的。AI 功能发布了，用户发现了边缘情况，而修复方案总是如出一辙：增加另一条指令。六个月后，你就有了一个 4,000 token 的系统提示词，没人能完全记在脑子里。模型开始执行一些并非初衷的任务——不是因为它坏了，而是因为你写的指令之间存在细微的矛盾，而模型正悄悄地代表你处理这些矛盾。

蔓延并不是一种灾难性的故障。这正是它的危险之处。当你的指令发生冲突时，模型不会崩溃或抛出错误。它会做出选择，通常很流利，通常看起来很合理，而且通常错误得刚好足以成为真正的支持负担。

你的 LLM 功能已经上线。用户开始问那些涉及时间的问题——"最新政策是什么？""帮我总结本周发生的事""这条信息还是最新的吗？"——模型自信、流畅地回答，却答错了。

模型不知道今天是几号。它从来都不知道。你熟悉的聊天界面让你忘了这件事，因为那些界面在背后悄悄注入了当前日期。但你的 API 集成不会。你发布的系统在不知道自己处于时间轴哪个位置的情况下，仍然在推理时间相关的问题——这是一类 bug，会在你还没想到去找它之前就出现在生产环境里。