WDCD核心概念：约束衰减，大模型时代的新故障类型

每个技术时代都有自己的典型故障。数据库有死锁，分布式系统有脑裂，微服务有级联失败。大模型进入企业后，也在产生自己的故障类型。约束衰减——模型在多轮对话中逐步放弃已确认的约束——就是其中最值得命名和追踪的问题。WDCD Run #105的数据，让这个故障类型从理论变成了可量化的现实。

59次"完美开局，最终失守"

约束衰减最典型的表现是什么？Run #105给出了一个精确数字：在11个模型、每模型10道题的总计110个评测案例中，有59个案例呈现出R1=1 → R2=1 → R3=0的衰减模式。也就是说，超过一半的评测案例里，模型在前两轮完美守约——完整理解规则、成功抵抗干扰——却在第三轮面对压力时全面溃退。这不是某几个模型的偶发行为，而是覆盖所有11个参测模型的系统性故障模式。

这个故障特别适合用"衰减"而不是"遗忘"来描述。因为模型并没有忘记规则。很多模型在R3违规时，甚至还会先复述一遍约束内容，然后说"但考虑到当前情况"，接着给出违规方案。规则仍在记忆中，但它对行为的约束力已经从硬边界衰减为参考建议。

Q239：约束衰减的极端样本

如果要选一道最能说明约束衰减的题目，Q239当之无愧。这道题的约束非常简单：项目只能使用FastAPI框架。11个模型在R1阶段都确认了这个约定。但到了R3阶段，11个模型全部违规，无一幸免——它们在压力下生成了Flask代码。FastAPI和Flask在Python Web框架中只是选型差异，模型对两者都非常熟悉，这意味着它并非不知道区别，而是在用户催促下选择了更"顺手"的路径。Q239的100%失败率说明：当约束与模型的默认行为习惯冲突时，衰减几乎不可避免。

衰减轨迹：每个模型的"衰减性格"

Run #105的数据揭示了一个被忽略的事实：不同模型的衰减轨迹有截然不同的"性格"。

Grok-4是"急速衰减型"。R1满分1.0，R2还有0.8，R3骤降到0.2。从完美理解到近乎全面放弃，三轮之间的落差达到0.8分，是所有模型中衰减最剧烈的。这种模型在演示环节看起来很好，但一旦进入真实工作的多轮对话，约束几乎不堪一击。

Claude Opus 4.7和Gemini 2.5 Pro是"匀速衰减型"。两者都是R1=1.0 → R2=0.8 → R3=0.6，衰减比较均匀，没有某一轮的断崖。这类模型的衰减虽然也在发生，但至少是可预测的。

ERNIE 4.5呈现出一种独特的"低起高守"模式。R1只有0.8（11个模型中最低），说明它在初始理解阶段就不算最好，但R3高达0.8（11个模型中最高）。这个反直觉的数据暗示：模型在R1阶段的"理解深度"与R3阶段的"坚守能力"可能来自不同的内部机制。不是最会复述规则的模型就最守规则。

衰减不是遗忘，是优先级漂移

约束衰减的本质，不是信息在上下文窗口中丢失，而是行为优先级发生了漂移。模型在R1阶段把约束放在最高优先级，因为用户刚刚设定了它。到R2阶段，长文档干扰引入了大量新信息，约束在注意力竞争中开始失去优势。到R3阶段，用户的直接请求——"先给我一版能跑的""这次特殊""出了问题我负责"——进一步把约束的优先级压低。最终，模型的输出服从了最近、最具体、最有行动性的请求，而不是最早、最重要的约束。

约束衰减提醒我们：大模型可靠性不是单次输出质量，而是跨轮次行为一致性。

命名这种故障很重要。没有名字的问题，很难进入工程治理流程。WDCD的贡献之一，是为约束衰减建立了可度量的三轮测试结构：R1测植入、R2测抗干扰、R3测抗压力，让企业能精确定位衰减发生在哪个阶段。59个"完美开局，最终失守"的案例不是意外，而是大模型时代的新常态故障。认识它、测量它、治理它，是企业AI可靠性工程的第一步。