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

对共享系统提示词的第一次修改感觉就像是优秀的工程实践。三个团队都在各自智能体的顶部粘贴了相同的 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。