OpenAI前不久宣布，SWE-bench Verified已经不再适合用来评估前沿编码能力。一个专门为衡量代码能力设计的基准，被AI冲破上限之后反而失去了意义。这件事本身不意外——当某个维度变得可优化，它迟早会被优化到偏离初衷。真正有意思的是，这个逻辑不只适用于AI，它几乎完美地映射了工程团队考核的困局。

我们比历史上任何时期都拥有更多的工程度量手段——代码量、PR数、故事点、交付率、代码覆盖率、线上故障数、响应时长……每个团队都在量，每个管理者都在看，但几乎没有谁敢说，自己的考核体系真的反映了团队的工程能力。

原因很简单：你量的全是噪音。

当度量变成目标

古德哈特定律讲了两百年了，但工程团队似乎永远不会吸取教训。或者更准确地说，不是不懂，是没得选。

每次聊性能优化，话题总是很快滑向具体的技术手段：懒加载、代码分割、图片压缩、Tree Shaking、虚拟列表……这些当然有用，但我想说一个可能让不少人不太舒服的判断——当你在做这些"优化"的时候，大概率已经晚了。 真正决定性能天花板的，不是你用了多少优化手段，而是系统架构在最初就给你画了多高的天花板。

性能问题从来不是前端单方面的问题。但很多团队把它当成了前端的问题，于是前端工程师就像一个装修工人，在毛坯房里拼命贴墙纸——墙纸再好看，承重墙没打好，房子一样不牢。

优化手段的天花板

先承认一个事实：常规的性能优化手段确实能解决一部分问题。一个从没做过任何优化的项目，加上代码分割和懒加载，首屏时间砍一半不稀奇。图片做个WebP转换、加个CDN，LCP直接降几百毫秒。这些是低垂的果实，摘了就是摘了，没人否认。

但问题是，这些优化有上限。你的首屏要从3秒优化到1.5秒，代码分割和懒加载就够了。但如果你要从1.5秒到800毫秒，甚至到500毫秒以内，单靠前端手段就力不从心了。因为剩余的耗时大头不在前端——它在网络请求、在服务端处理、在数据组装、在协议开销。

做技术管理这些年,我发现一个有趣的现象:越是成功的技术Leader,越不愿意分享自己踩过的坑。大家都在讲"如何打造高效团队"、"OKR落地实践"、"技术人才培养体系",却很少有人聊那些让人坐立不安的尴尬时刻。

但恰恰是那些尴尬时刻,构成了技术管理的真实底色。

当你意识到自己是瓶颈

2019年,我负责的前端团队刚从5人扩到10人。团队扩张后的第三个月,我突然发现一个问题:所有人都在等我review代码。

不是他们不主动,而是我在无意识中给自己设置了一个隐形职责——"技术质量守门人"。每个PR我都要亲自看一遍,每个技术方案我都要参与讨论,每个难题组员都会第一时间找我。

表面上看这是负责任,实际上是灾难。

团队的吞吐量被我一个人的工作时间卡死了。更糟糕的是,我发现自己在培养"等待型工程师"——遇到问题不是先思考,而是先找Leader确认。这不是我想要的团队文化。

那段时间很煎熬。一方面我知道必须放手,另一方面又担心代码质量下滑。最让人尴尬的是,当我试图"授权"时,发现自己根本不知道该怎么做。

过去几年里,我习惯了"事必躬亲就能保证质量"的工作方式。现在要求我"不插手也能保证质量",完全是另一套技能。

最近在和几个技术管理者交流时，发现他们都在规划或已经落地了BFF（Backend for Frontend）架构。问为什么要做BFF，得到的答案惊人地一致："解耦前后端"、"提升开发效率"、"这是最佳实践"。

但当我问："你们团队有多少后端开发？前端开发呢？"，答案通常是"后端6-8人，前端3-4人"。这让我意识到一个问题：大部分团队上BFF，可能不是因为真的需要，而是因为"别人都在用"。

我想聊聊这个话题，不是要否定BFF的价值，而是想说：很多团队高估了BFF的收益，低估了它的成本。

BFF真正解决的问题

先说清楚，BFF不是伪需求。它在特定场景下确实有价值：

场景一：多端适配。你的后端API是为Web设计的，现在要支持移动端、小程序、IoT设备。不同端的数据需求、交互逻辑差异很大，用一套API很难搞定。这时候BFF可以为每个端定制API，后端保持稳定。

场景二：聚合调用。前端一个页面需要调用5-6个后端服务，串行调用太慢，并行调用又要处理复杂的依赖关系。BFF可以在服务端聚合这些调用，减少前端的复杂度和网络开销。