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

新员工打开入职文档。文档指向了十一个月前的一个服务架构图、一个最后更新于十月的名为 “我们的 LLM 技术栈” 的 Confluence 页面，以及一个 “我们使用的模型供应商” Notion 表格。这些文档都没有告诉他们哪个提示词是针对哪种失败模式优化的，哪些评估案例是在哪次事故后添加的，当模型从 4.5 升级到 4.6 时哪个评判模型被重新校准了，或者为什么支持代理的系统提示词有一段谁都不敢动的奇怪的三行前导内容。入职两周后，他们提交了一个 “小的提示词清理” PR，删除了这段前导内容。评估套件通过了。不到一天，生产环境的准确率下降了四个百分点。

标准的新员工入职指南 —— 阅读架构文档、配置电脑、在第二周前完成第一个 PR —— 是为加入服务端的工程师设计的。AI 工程师加入的是一种不同的制品。他们要编辑的不是某个主任工程师写的 5000 行 Go 服务；而是一个经历了 11 次事故和 17 次评估驱动重写的 30 行提示词，而这 30 行代码的意义只存在于团队中两个人的脑子里。你的入职文档无法捕捉到这些，而尝试写一份更长的文档是错误的修复方案。

我上个月交流过的一位 AI 初创公司 CTO 打开她的笔记本电脑，给我看了一个数字：47。那是目前在生产环境中运行的独立系统提示词（System Prompt）的数量，每个企业客户或每个逻辑分组各占一个。基础提示词在第四个月为一家需要更温和拒绝态度的医疗客户派生（Fork）了一次。然后为一家需要引用的法律客户又派生了一次。接着是为一家金融服务客户派生的，因为他们的合规团队有一份违禁词清单。当时，这些看起来都不是什么大事。每一个都是独立批准的小需求，让大客户经理团队能够顺利签下订单。

两年后，模型提供商宣布了她那些针对旧版本调优的提示词的切换截止日期。她的工程团队直觉反应是对新模型运行评估套件（Eval Suite）。评估套件仅针对基础提示词。基础提示词仍在为 0 号客户提供服务，该客户没有任何覆盖配置，且约占收入的 9%。

打开任何生产环境中的 LLM 代码库里的提示词文件，你会发现评审者的目光变得呆滞。这个 diff 是 15 行自然语言，其中包含一个微调过的 few-shot 示例，一条重新表述的指令，以及编辑器留下的一个多余的尾部空格。没有针对它的语法检查，没有 Linter 抱怨相互矛盾的指令，没有扫描器注意到 few-shot 示例包含上周二支持日志中真实客户的电子邮件地址，也没有冒烟评估（smoke eval）来确认这一更改不会导致系统实际提供的提示词延迟飙升。评审者凭感觉批准——就像 2008 年团队批准 HTML 模板的 diff 一样——然后在 6 小时后，生产遥测系统捕获到了回归。

围绕代码的内环工具（inner-loop tooling）已经成熟了 20 年。围绕提示词的内环工具则介于“我们在 git 中有一个 .md 文件”和“我们在入职后运行过一次 promptfoo”之间。这种差距正在扩大，因为在许多系统中，提示词现在是杠杆率更高的修改：一个 30 行的系统提示词更改比 1000 行的服务重写更能改变行为，而它的评审过程却像处理一份 Word 文档。

一位产品经理在 Slack 上私聊你，询问当客户要求助手取消订阅时会发生什么。你开始凭记忆输入答案，然后又自我怀疑，于是打开系统提示词读了 30 秒。你粘贴回一份摘要。他们向你道谢后继续忙别的了。三小时后，支持团队问了同样的问题。到了周四，合作伙伴负责人把提示词的截图贴进了交易审查中。

这就是“提示词即文档”（prompt-as-documentation）反模式。当你第一次意识到这种情况发生时，感觉会很棒。你花了六个星期调优的制品，现在成了产品功能的权威真理来源。产品经理在读它，支持团队在读它，销售团队在读它，甚至某个角落的设计师也在读它。你的工作成了支柱，这在以前的服务层代码中从未有过。你可以通过计算有多少不相干的人能凭记忆调出这个文件来证明这一点。

翻开任何一个运行了一年的生产系统提示词（system prompt）的 git blame，你都会发现一些工程团队不愿承认的事实：这个文件有三个作者，而他们对“变更”的定义各不相同。上个月重构指令块的工程师将提交记录标为“无功能变更，仅为了清晰起见重新排序”。每季度读一次该文件的产品经理会这样描述同样的差异：“你改写了语气——客户会察觉到的”。运行回归测试套件的 ML 工程师会说：“你搞坏了第三个少样本示例（few-shot example），从那以后评估结果（eval）就一直变红了”。

这三者都是正确的。提示词同时具备代码、规范和超参数的属性。任何长期交付 AI 功能的团队都会发现，该文件的提交历史是一场缓慢进行的三方署名权争议，CODEOWNERS 无法捕捉到这一点，diff 查看器也无法体现出来。

一位资深工程师向 planner 提示词（prompt）提交了一个只有四个单词的修改——“if uncertain, ask first”（如果不确定，先询问）。Planner 自身的评估集（用于评分计划是否合理）提升了 0.5 分。他们合并了代码。两周后，verifier 的评估显示通过率出现了 3 个百分点的回归，且没人能复现。根本原因在于：planner 现在会提出更多澄清性问题，executor 在第二轮收到的任务描述变短了，而 verifier 的评分准则（rubric）是针对之前 executor 较长的输出进行隐式调优的。一个没人标记为高风险的修改，一次性改变了下游的三个分布。

当你把智能体（agent）内部的提示词看作一个扁平的文件文件夹，而不是一个带有“边”（edges）的图（graph）时，就会发生这种情况。提示词有负责人，但它们之间的“边”却无人看管。

打开任何已经上线超过九个月的 AI 功能的系统 Prompt。向下滚动，越过角色描述，越过格式规则，越过安全护栏。停在标题为 <examples> 或 ## Examples 的块，或者是你的团队在某人把前三个好用的 Slack 线程复制到代码块的那天给它起的任何名字。读一读它们。有 60% 的可能性，其中至少有一个引用了已经更名的功能、一个已不存在的按钮，或者产品经理在两个季度前悄悄砍掉的工作流。

这种衰退从评测（eval）仪表盘上是看不出来的。评测得分是绿色的。它们已经绿了好几个月了。它们之所以是绿色的，是因为评测集是针对 Few-shot 示例所引用的同一个产品界面编写的，两者已经同步老化。模型正在完美地模仿去年的产品，而在一个以此标准打分的测试集上，它是合格的，然而真实用户在与今年的产品互动，并默默忍受由此产生的幻觉（confabulations）。这就是没有人写进 LLMOps 路线图的半衰期。

在某个周二，一个全新的可选参数被添加到了工具描述中。这个改动很小——在 diff 中只有六行代码，没有破坏性的签名变更，没有更新调用者，也没有触及任何评估用例。PR 描述写着“为现有搜索工具添加了可选的 language 过滤器支持”。两名评审员批准了，随后上线。

一周后，成本仪表板显示，搜索工具的调用频率比之前的基准线增加了 18%。受影响的 agent 延迟也以大致相同的比例攀升。没人能指出哪一个评估用例失败了。新参数在使用时表现正常；在不使用时，也无关紧要。然而，planner 显然改变了它对何时使用该工具的看法——而评估套件（用于衡量工具的“正确性”）对于工具“频率”的变化却无话可说。

打开过去六个月内发布的任何 AI 功能的系统提示词（System Prompt），将其与授权该功能的 PRD 并排阅读。你会发现这两个文档在互相争吵。PRD 写道：“助手应该是提供帮助且专业的，避免胡编乱造，如果无法回答则体面地拒绝。”系统提示词则写道：“你是一个 AI 助手。保持简洁。如果不确定，说‘我不知道’。绝不捏造事实。”PRD 占了一整页。提示词只有九行。它们之间的鸿沟就是你本季度发布的所有行为 Bug 的所在地。

这种便利的虚构说法认为，提示词只是 PRD 的“实现细节”。实际关系恰恰相反。提示词是模型执行的契约；而 PRD 是由一个从未编译过它的作者用模型听不懂的语言编写的契约草案。每一个 AI 功能的 PRD 都是一个未经测试的提示词。那些承认这一点并在签字确认前通过评估（Eval）运行 PRD 的团队，发布的功能会少一个上线后产生意外的根源。

一个团队负责摘要生成器。另一个团队负责摄取这些摘要的搜索排序器。第三个团队负责一个路由，根据排序器的置信度分数在不同的智能体人格之间进行选择。这些团队都没有共同的值班轮换，也没有人参加同一个站会，他们之间唯一的契约就是“上一个功能的输出是下一个功能的输入”。周二，摘要团队收紧了一个提示词，以修复销售演示中反馈的幻觉问题。六小时后，搜索排序器的质量骤降。到周三早上，路由开始将任务交给错误的智能体人格。复盘报告会将原因记录为“提示词变更”，但实际原因是团队的 AI 功能已经悄然组成了一个没人绘制过的有向图。

这是最常见的 AI 故障形式，它不会触发你为 AI 故障构建的任何警报。模型没有宕机。被修改功能的评估套件显示为绿色。Token 成本曲线很平稳。真正断裂的是两个功能之间的接口，你的依赖工具将其视为纯文本，因为在 API 边界它确实只是纯文本——并且将其视为惰性的，因为纯文本不携带版本、Schema 或弃用策略。

打开一个成熟的生产系统提示词（system prompt）并搜索“not”这个词。在一个已经发布了三个季度并经历过几次事故的功能中，你几乎总能发现一个看起来像“遗憾清单”的章节——“不要提供医疗建议，不要生成匹配这些模式的代码，不要使用这个正则表达式生成内容，不要冒充这些竞争对手，不要使用这些短语。”每一行都可以追溯到一起特定的事故。每一行都是由一位满怀信心地说“这能解决问题”的工程师添加的。而这个列表，每一个季度都像博物馆增加展品一样不断增长。

极少数团队会公开承认的是，这个列表——提示词中最具防御性、经过最仔细审查的部分——对于错误的读者来说，也是整个功能中最有用的产物。一个决意提取系统提示词的用户，现在拥有一份经过策划、组织良好且模型可读的清单，其中包含了团队所担心的所有行为。禁止列表就是一份食谱。而团队亲手编写了这本烹饪书。

当一个多租户 SaaS 团队在其系统提示词（system prompt）中添加第三个 if tenant_industry == "healthcare" 分支时，那一刻他们其实已经在不经意间为自己聘请了一位编译器工程师。没有人申请过这个人头（headcount），也没有人事先规划过这项工作。团队以为自己在交付一个功能，实际上交付的是一套构建系统，而这套系统仅靠 f-strings 勉强维系。

任何试图将 AI 功能推广到具有哪怕轻微差异的客户群体的团队，最终都会撞上同一堵墙。租户 A 属于医疗行业，需要符合 HIPAA 标准的回答框架。租户 B 属于法律行业，需要严格的引用规范。租户 C 是购买了自定义安全准则的大型企业。租户 D 是免费层级用户，使用默认设置。最直觉的做法是用运行时条件语句（runtime conditionals）处理差异，这些条件不断嵌套，直到除了作者之外没人能读懂这个提示词。第二种直觉——也是大多数团队在撞墙后得出的方案——是提示词编译（prompt compilation）：规范的“提示词”不再是一个字符串，而是一个源码产物（source artifact），最终触达模型的则是编译后的输出。