一、为什么复杂性被系统性奖励
1、晋升包的叙事天然偏向复杂
作者用两个工程师的对比说明了这个问题。工程师 A 看完需求，挑最简单的方案，50 行代码，两天交付，运行稳定。工程师 B 选择了”更健壮”的路：新增了抽象层、引入了发布订阅系统、搭了一套配置框架，花了三周，一堆 PR，文档里充满兴奋的表情。
晋升评审时，B 的包几乎自动写好了——“设计并实现了可扩展的事件驱动架构，引入了多团队复用的抽象层……”而 A 的工作能写下的只有”实现了功能 X”。A 的方案更好，但完全隐形。复杂性之所以被奖励，不是因为它正确，而是评估体系更擅长衡量”做了什么”而非”避免了什么”——这就是所谓的可见性偏差（complexity looks smart not because it is, but because our systems are set up to reward it）。
2、面试文化从起点就强化了这个问题
系统设计面试轮次里，候选人提出简洁方案时，面试官往往追问”如果有一千万用户呢”。于是候选人加服务、加队列、加分片，白板上越画越复杂，面试官才满意。候选人从此学到的教训是：简单的答案不够有趣。尽管面试官推演扩展性有时确实有价值，但当候选人带走的结论是”简单不够用”，问题就出现了。
设计评审中也同样：有人提出干净简洁的方案，马上被问”这个能不能面向未来扩展”——于是加了不需要的层、为不存在的需求预留了灵活性，不是因为问题需要，而是因为房间里的人期待这样做。
二、反转的路径：让简单性被看见
1、工程师：主动记录你不做的决策
真正的资深不是掌握更多工具和模式，而是知道什么时候不用它们。任何人都能增加复杂性，有经验和自信才能把复杂性留在外面。
但这需要工程师主动让简单性可见，而不是等系统发现它。具体做法是：记录你评估过并最终拒绝的复杂方案。“实现了功能 X”三个字什么都没说，但换成”评估了三种方案包括事件驱动架构和自定义抽象层，判断直接实现满足当前和可预期需求，两天上线，六个月零故障”——这是同一份简单的工作，但捕捉到了背后的判断力。
在设计评审中，当有人问”应该面向未来吗”，不要直接妥协加层。试试这个回答方式：“这是后期加入的成本，这是现在加入的代价，我认为可以等。“这不是在推回问题，而是在展示你做了功课、主动选择不承担复杂性。
2、管理者：重写提问框架，把举证责任（burden of proof）放到复杂性上
作者对工程领导者说得很直白：这个问题大部分在你。大多数晋升标准的设计，即便无意为之，也是在奖励复杂性——“影响力”用规模和范围来衡量，隐含地偏向了”构建了多少”。
改变从问题开始。设计评审里，把”我们想过规模吗”替换成：“最简单的可发布版本是什么？什么信号会告诉我们需要更复杂的方案？“这一个问题就改变了默认值——简单成为起点，复杂需要说明理由，而不是反过来。
在晋升讨论中，当有人的包基本上是一张炫酷系统的清单，值得追问：这些都是必要的吗？我们真的需要那个发布订阅系统，还是它只是看起来好看？当工程师交付了干净简洁的方案时，帮他们写出叙事——“评估了多种方案，选择了解决问题的最简方案”是值得被当作晋升案例认真对待的，但前提是你真的当回事。
最后，注意你公开表扬什么。如果团队频道里每次的喝彩都是给那个大的复杂项目，那就是在告诉所有人去优化什么。开始表彰那个删了代码的人，那个说”我们还不需要这个”而且说对了的人。
核心归纳
Q1: 为什么工程师学会了把复杂性当成晋升工具？
- 评估体系更容易衡量”做了什么”，看不到”避免了什么”，复杂方案天然能写出更长的晋升叙事。面试文化也在强化同样的逻辑——追问扩展性让候选人从进门就学到”简单不够用”。
Q2: 工程师和管理者各自该怎么做？
- 工程师：主动记录并表述你拒绝的复杂方案，把”不做什么”也写进总结，让判断力可见。管理者：改变提问框架，把举证责任放在复杂性上；在晋升讨论中主动为简洁工作写出叙事；用公开表扬校准团队优化方向。