5 篇博文 含有标签「prompt-management」

每个 AI 组织都有一个坟场。不是服务的坟场——服务会有操作手册（runbook）、弃用横幅、30 天的迁移窗口，以及在平台团队季度路线图上的位置。这个坟场是属于 功能 的：从未转正的智能摘要 Beta 版、两个大客户据此构建了工作流的自动分类器、演示效果极佳但在灰度发布后无人问津的 Agent 流程。弃用一个端点很容易。但与之关联的其他四个东西——提示词（prompt）、评测员（judge）、回归测试集（regression set）和事故记忆（incident memory）——才是真正需要一个季度才能搞定的，而且团队中没人写过这种手册，因为没人会因为下线某个功能而获得晋升。

这就是差距。大多数关于“模型弃用”的公开讨论都是针对供应商侧的下线：GPT-4o 在某天停止服务，Assistants API Beta 版在 8 月 26 日下线，DALL-E 3 在 5 月 12 日退休，而你的平台团队有一个通知期来进行迁移。这个问题有现成的手册，因为供应商发布了日期，迁移是被迫的，而且工作量可以塞进一个 Sprint 中。而“内部”版本——当你决定你构建的一个功能未能转正并必须将其撤除时——则没有任何这类强制因素。弃用日期由你说了算。迁移路径由你来构建。而且你必须退役的产物不是单个端点，而是一堆纠缠在一起的、与模型相关的资产，你的监控系统几乎感觉不到它们的存在。

一位工程负责人（Head of Engineering）在周一早晨打开了研发速率仪表盘。每周合并的 PR 数量：持平。完成的故事点：持平。改动的代码行数：低得可疑。图表显示，AI 团队在这个季度表现平平。而在两个楼层之外，那支团队在三周内重写了七次系统提示词（System Prompt），更换了一个让工具调用准确率翻倍的工具描述，增加了六个新的 few-shot 示例，并不断调整重排序（Rerank）指令，直到产品感觉像是一个完全不同的应用。所有这些工作都没有出现在 PR 图表中。但对用户来说，这些改变无处不在。

AI 团队所做的改动与工程仪表盘所测量的指标之间的不对称，已成为 2026 年最具影响力的误判。在重度依赖 AI 的产品中，行为的改变正日益与代码的改动解耦，而支配了软件组织十五年的指标——PR 吞吐量、提交量、涉及的代码行数——衡量的都是代码的改动。一个团队可能每周都在重塑线上响应的分布，但在领导层信任的每一张图表上，他们看起来却无所事事。

大多数公司的第一次 AI 事故都遵循一个剧本：一名提示词工程师发现模型对刚刚开始出现在实际流量中的某个类别进行了错误分类，于是提交了一个 PR，对系统提示词（system prompt）进行了一行微调，然后在模型继续在生产环境中进行错误分类的这 23 分钟里，盯着构建队列。修复手段只是一个字符串。而部署却是一个二进制文件。这种不匹配并不是工具层面的疏忽 —— 而是团队在将系统提示词与应用程序代码一同放入 .py 文件的那天起，就隐含做出的架构决策。

将提示词更改与部署管道耦合是你强加给自己的限制。分布式系统中没有任何定律规定模型的行为契约必须与编排代码封装在同一个制品（artifact）中。运行时提示词热重载模式通过像对待功能开关（feature flags）、路由规则和价格表那样对待提示词，从而切断了这种耦合 —— 即将其视为在请求时从版本化存储中拉取的配置，并辅以短效的本地缓存和定义明确的安全原语（safety primitives）。这样做的好处是事故响应时间从以分钟计的构建时长缩短到以秒计，而代价是你必须正视一个你的发布流程可能忽略的第三个部署平面。

对共享系统提示词的第一次修改感觉就像是优秀的工程实践。三个团队都在各自智能体的顶部粘贴了相同的 18 行安全前导指令，有人注意到了这一点，内部平台团队说了一个显而易见的提议：让我们把它中心化吧。于是 prompts.common.safety_preamble@v1 出现在了注册仓库中。由于这是阻力最小的路径，加上安全团队很高兴能由一个团队统一负责措辞，30 个团队在短短一个季度内就采用了它。在接下来的两个季度里，这看起来就像是一个完美的 DRY (Don't Repeat Yourself) 胜利。

随后，安全团队需要对措辞进行微调。可能是新的合规条例收紧了助手可以主动提供的用户信息范围，也可能是红队发现需要向拒绝条款中增加一句话。平台团队完成了修改，发布了 v2 版本。不到一天，支持队列就充满了消费团队的消息：我们的评估 (eval) 下降了、我们的格式崩了、我们的工具调用率减半了、我们的语气变了、延迟增加了（因为模型开始进行更多推理）。每个团队都希望回退修改。而安全团队需要发布它。没有人能在不进行重新评估的情况下升级，但又没有人负责重新评估。欢迎来到共享提示词的“旗帜日 (flag day)”。

对系统提示词（system prompt）的一个单词修改在生产环境中运行了 21 天，期间没有人发现它误分类了数千份抵押贷款文件。估算的损失：340,000 美元的操作效率低下和 SLA 违约成本。没有人能说出是谁做的改动，什么时候改的，或者为什么要改。提示词存放在一个环境变量中，有三个团队拥有写入权限，而且没有人认为自己有责任对其进行审核。

这就是提示词所有权（prompt ownership）问题。随着 LLM 驱动的功能在企业中激增，提示词已成为技术栈中影响最深远、但治理最薄弱的资产。它们控制模型行为、塑造用户体验、执行安全约束并定义业务逻辑——然而，大多数团队管理提示词的严谨程度甚至不如修改一次 CSS。