Content

妥协累积效应是指：在设计评审或决策流程中，每个参与方各自提出一个单独看起来合理的修改，但所有改动累积起来后，最终产品偏离原始目标、不再服务任何人。其病理核心在于每项妥协单独看都”没毛病”，没有一个人为整体结果负责。

Acceptance

这个术语化自「Your Website Is Not For You」(websmith.studio/blog/your-website-is-not-for-you/) 一文中的观察：开发者会议里每个人对设计都有自己的看法，“我不太喜欢这个颜色”就能推翻用户研究团队几周的工作。设计师只能挑战争打，退让一次再退让一次，最终上线的东西等于”领导层的心情板”——签字的人觉得美，真正要用的人觉得没用。
类似现象在软件架构中表现为”架构侵蚀”（Architectural Drift）：每次 sprint 做出的局部合理决策累积后，系统架构偏离原始设计。

妥协累积的本质是责任分散。每项妥协的决策者都不是最终产品的 owner，所以他们天然缺少”全局最优”的动力。设计师知道哪个改动有害，但评审会上坐了一桌人，每个都只对自己负责的部分提意见，合起来就把设计杀了。

这和YAGNI的联系很有意思：YAGNI 是防止过度设计，而妥协累积是防止设计退行——两者都指向同一个问题：做少比做多更难。但 YAGNI 是开发者主动克制，妥协累积是被动接受”看起来无害”的改动，后者更难防御。

在 AI 辅助开发的场景里，我怀疑妥协累积的发生反而更快——因为 AI 执行快、没有心理防御、不会对”无害但有害”的改动抗议。Jeff 那天说”AI 输出的不确定让很多原有工作流程难以为继”，这里面就包含了一旦 AI 不能判断”这是否属于妥协累积”的风险。

如何区分”必要的妥协”与”致命的妥协累积”？

一个测试标准：看这次妥协是解决用户的问题还是解决评审者自己的审美/偏好问题。每次打算改动前问「这个改动帮的是用户还是我自己？」——如果答案是”自己”，它就是妥协累积的种子。

在 AI 辅助开发环境中，妥协累积的速度是被加速了还是减慢了？

加速了。AI 生成和修改代码的成本极低，一个”试一下换个颜色”的请求在传统开发中可能需数小时，在 AI 辅助下只需几十秒。低成本使”无害的小改动”数量激增，累积曲线更陡。且 AI 缺乏维护设计一致性的”长期记忆”，不会在第 7 次妥协时喊停。

有没有一种流程设计可以从机制上防止妥协累积，而不依赖个人的”坚持”？

有，核心手段是引入对抗性角色。例如每次评审会指定一名「设计守护者」——他的唯一职责是说”不”，不负责输出创意。另一种机制是”零轮妥协”：每个改动必须有量化证据支持（用户测试、A/B 数据），而非主观偏好。类似 Spec-First Development 中的约定前置思维。

这个现象在组织行为学中被称为”阿比林悖论”（Abilene Paradox）的变体——一群人在个体层面觉得方向不对，但集体层面仍然走了过去。