为什么"我的智能体3天就烧光7天配额"和"我的智能体无视我的风格指南"其实是同一个注意力缺陷

我最近在几乎每个关于编程智能体的讨论帖里都看到同样的两个抱怨：周三就用光了每周配额；模型无视风格指南，写出过度防御、充满 nullable 和 fallback 的代码。通常讨论会变成一场辩论——从 Gemini 换到 Claude 或 ChatGPT 是否能解决问题。当我回溯自己失败的运行记录时，我意识到这两个抱怨其实是同一个闭环。为了让智能体不写出坏模式，我们很自然地会把一段坏代码示例粘贴到系统提示词里，注释写着"DON'T do this"。在 transformer 自注意力机制中，把 function foo(d?: Date | string | null) 放进提示词，就等于把这串 token 序列加载进了活跃的 KV-cache。在自回归生成过程中，KV-cache 中的 token 会充当语义吸引子。对模型说"盯着这张高清粉色大象代码片段时不要想粉色大象"，恰恰会激活它输出你想要禁止的 nullable 联合类型和静默 fallback 的倾向。于是模型违反规则，你花 25 轮争论、每次粘贴 50k token 的 diff，再往提示词文件里加三条"DON'T"规则，注意力进一步稀释，你的 7 天配额 72 小时就没了。而且由于公开训练仓库里充斥着防御性的教程 JavaScript 和 TypeScript，用同样的提示词文件换供应商，只是把循环转移到了另一个计费页面。在我最近 238 个生产工单中，有两件事终于帮我打破了这个循环：第一，用一个四部分的覆盖结构（1-2-3-4 -> NOOO! -> E-F-G-H）替代负面的"DON'T"示例——指出运行时崩溃、点明权重倾向于输出的那个确切教程捷径、明确授权智能体在 API 签名是个陷阱时可以停下来并提出替代方案、以及给出它应该采用的确切正面序列。第二，让我们的考古子智能体使用 1991 年 AT&T Bell Labs 的 Graphviz DOT（strict digraph）将调用图爆炸半径和状态机传递给编码和审查子智能体，而不是用英文散文或 Mermaid。散文描述会丢失入边调用者，Mermaid 在密集类型属性上会出问题，而 strict digraph 能让模型直接切换到它在 LLVM 和 GCC 编译器控制流上的训练模式。还有其他人注意到，添加"不该做什么"的代码示例反而让你的智能体更频繁地输出那个模式吗？