3 篇博文 含有标签「system-prompt」

你的法务团队花了四次会议来打磨那一句披露的措辞。工程团队把它放到了系统提示词的最顶端。QA 确认每个会话的第一轮都会出现。三个月后，一位监管者转发了一份对话记录：这是一段处理投诉的对话的第十四轮，整整一小时围绕一笔退款纠纷给出实质性建议，而在那十四轮里，用户从未看到「我是一个 AI」这几个字。你那份通过单轮合规评审批准的披露，在结构上根本无法在真正需要它的对话里存活下来。

这就是「披露衰减」（disclosure decay），它是 2025–2026 那波聊天机器人监管浪潮没有设计去捕捉、你的 QA 流程也没有配置去测试的多轮 Agent 失败模式。欧盟 AI 法案第 50 条的义务将在 2026 年 8 月 2 日正式可强制执行，罚款最高可达 3500 万欧元或全球营业额的 7%。加州的 SB 243 已于 2026 年 1 月 1 日生效，附带私人诉讼权，消费者可以直接起诉，每次违规最低赔偿 1000 美元。华盛顿州要求重复披露，对未成年人采取每小时一次的频率。这些监管体系没有一个是在假设「披露会在第三次工具调用后悄无声息地从会话里掉出去」的前提下写出来的——但这就是你的运行时此刻正在做的事，在每一个长时间运行的对话里，正在生产环境中发生。

打开任何已经上线超过三个月的生产环境 AI 功能的系统提示词（system prompt）。数一数其中的负向条款——“不要”、“绝不说”、“避免”、“在任何情况下都不”、“你绝不能”。如果计数达到了两位数，你看到的就不是一个系统提示词。你看到的是一个坟场。每一块墓碑都标志着一个特定的用户投诉、一个特定的事故报告，或者一条来自利益相关者的 Slack 消息，因为他们看到模型做出了一些令人尴尬的事情。团队在表面打了补丁后就继续前进了，现在这个提示词读起来就像一份被强行嫁接了人格的法律免责声明。

负向提示词是代码异味（code smells）。并非隐喻意义上的，而是字面意义上的。它们在提示词工程中相当于吞掉异常的 try/except 块、没有文档的配置标志，或者是 2022 年留下的 // TODO: refactor this。它们在某种程度上有效，直到它们失效。而且它们所掩盖的失败模式，几乎总是比它们被添加用来压制的那个失败更有趣。

大多数团队发现他们的系统提示词存在冗余问题的方式都如出一辙——一次成本审查、一次延迟激增，或者某位工程师终于从头到尾读了一遍。他们通常会发现一个在六个月内有机增长的 2,000 token 的文档，其中散落着三个不同版本的“保持简洁”，还有指向二月份就已弃用的产品工作流的指令，以及模型在每次运行时都明显忽略的十几条规则。提示词规模庞大，但大部分内容其实毫无用处。

这就是 Prompt 信用分配问题 (Prompt Credit Assignment Problem)：弄清楚一个数千 token 的系统提示词中，哪些指令真正驱动了模型行为，哪些只是消耗 token 并分散注意力的冗余负重。坏消息是，大多数团队完全跳过了这一步——他们在行为出错时添加指令，却从未减少过。好消息是，这有一套可重复的工程准则。