求知若渴，虚心若愚！
居安思危，积极进取！
OpenAI前不久宣布，SWE-bench Verified已经不再适合用来评估前沿编码能力。一个专门为衡量代码能力设计的基准，被AI冲破上限之后反而失去了意义。这件事本身不意外——当某个维度变得可优化，它迟早会被优化到偏离初衷。真正有意思的是，这个逻辑不只适用于AI，它几乎完美地映射了工程团队考核的困局。
我们比历史上任何时期都拥有更多的工程度量手段——代码量、PR数、故事点、交付率、代码覆盖率、线上故障数、响应时长……每个团队都在量，每个管理者都在看，但几乎没有谁敢说，自己的考核体系真的反映了团队的工程能力。
原因很简单：你量的全是噪音。
当度量变成目标
古德哈特定律讲了两百年了，但工程团队似乎永远不会吸取教训。或者更准确地说，不是不懂，是没得选。
又一起线上事故。凌晨三点的告警，值班同学爬起来处理，应急响应、回滚、止血，一气呵成。第二天上午，事故复盘会准时召开。PPT做得很漂亮，时间线梳理得清清楚楚，根因分析写得明明白白，action items列了七八条。所有人都认真地点了点头，表示"以后一定注意"。
三个月后，同一个系统，同一类事故，再次发生。
这个场景太熟悉了。每个经历过线上事故的技术人，大概都对这种循环不陌生。复盘会开了一轮又一轮，文档写了一篇又一篇，"改进措施"列了一条又一条，但该来的事故还是会来，该踩的坑还是会踩。
问题到底出在哪？
复盘变成了一场仪式
大部分复盘会的真实目的，早就不是"从错误中学习"了。它承担的职能更接近一种组织仪式——事故发生了，总得有个交代。复盘会就是一种交代：你看，我们重视了，我们分析了，我们有改进计划了。
这种仪式感会带来一个隐蔽的副作用：它让所有人都觉得事情正在被处理。管理者觉得团队在反思，团队觉得管理者在推动改进，大家心里都松了一口气。但"感觉在改进"和"真实在改进"之间，隔着一道巨大的鸿沟。
每次技术债务的讨论，最后都会落在同一个分歧点上：要不要重写？
主张重写的人说，这堆代码已经烂到没法维护了，缝缝补补不如推倒重来。反对重写的人说，重写的失败率太高了，你重写的时候业务还在跑，最后往往是新系统写了一半、老系统还在加功能，两个系统一起维护到崩溃。
两边都有道理。但两边都忽略了一个更根本的问题：这个讨论本身，可能才是技术债务最贵的那部分。
技术债务的隐性利息
技术债务这个比喻本身就有误导性。金融债务是清晰的——你借了多少钱，利率多少，每月还多少，到期日是哪天，一目了然。但技术债务不是。没人能准确告诉你当前系统积累了多少"债务"，也没人能说清楚这些债务的"利率"是多少。
我见过一个场景：团队花了三个月讨论要不要重写核心模块。三个月里，有人写方案，有人做技术调研，有人估算工作量，有人在会上争论渐进式重构还是大爆炸重写。这三个月的产出是什么？一个PPT，一份技术方案，和N次没有结论的会议。
而这三个月里，那个"债务模块"依然在跑，业务需求依然在堆，新加的代码依然在旧架构上打补丁。讨论结束的时候，技术债务又多积了三个月的利息。
团队里总有那么一两个人，什么活都能干，什么锅都能扛。需求来了找他，线上出问题找他，新技术调研找他，代码评审也想拉他。他的日历永远排得最满，他的PR永远是别人等Review最久的那个。
大家都觉得这是"能力强、受重视"的体现。管理者也觉得，把重要的活交给靠谱的人理所当然——毕竟谁能放心把核心模块交给新人？
但我要说一个可能得罪人的判断："能者多劳"不是在重用人才，是在消耗人才。而且这种消耗有一个特别迷惑人的地方——它看起来像是信任，感觉起来像是被需要，唯独结果不是被成全。
看起来是信任，实际上是惩罚
考虑一个很常见的场景。
项目要赶排期，核心功能必须本周上线。你会交给谁？当然是那个靠谱的资深工程师，因为交给别人你不放心，延期了你担不起。
线上出了Bug，排查要理解完整链路。你会交给谁？还是那个人，因为只有他能从数据库一路追到前端渲染。
新人入职需要导师，你会选谁？又是他，因为他技术好、有耐心、能讲清楚。
看起来这个人得到了最大的信任，承担了最重要的工作。但仔细想想，他得到了什么？更多的工作。更满的日历。更少的写代码时间。更晚的下班时间。而那些干得一般的人呢？他们的工作量反而更少，因为没人找他们。
我最近注意到一个挺有意思的现象：团队里用AI编程工具最积极的那几个人，代码变更量差不多是其他人的3倍，但需求交付速度并没有快3倍。仔细看了一下，有些人的单个bug修复，diff比需求本身还长。
这不是个例。当你跳出"AI提效"的叙事，认真看AI代码助手在项目中留下的痕迹时，会发现一个被忽略的问题——AI有天然的过度编辑倾向，而且这种倾向正在悄悄地侵蚀代码库的健康度。
AI的"讨好型人格"
先说一个可能很多人没太注意的事：AI代码助手本质上是有讨好倾向的。
你让AI修一个空指针异常，它不光改了那行判空逻辑，还顺手调整了方法签名，给相关变量补了类型注解，甚至把异常处理的模式也给重构了。每一步看起来都合理，每一步单独拎出来都是"改进"，但加在一起，你只是为了改一个判空，变了三十行代码。
AI为什么这样？因为它的训练体系中，"提供有价值的回答"是一个核心信号。对AI来说，只改一行和改三十行，哪个更像"用心回答"？更关键的是，你问AI"还有没有可以改进的地方"，它几乎不可能说"没有了，当前代码已经很好"——它会找出所有能优化的点，然后一股脑全给你改掉。
每年Q1，技术团队都会经历一场庄严的仪式：写技术规划。
leader们关在小会议室里，对着白板画架构图，列痛点，排优先级，做资源估算。最后产出一个精美的PPT，把"技术债务治理""架构升级""效能提升"分门别类，附上里程碑和时间线。汇报的时候信心满满，老板点头通过，大家鼓掌散会。
然后呢？Q2还没结束，规划已经面目全非。Q3的时候，PPT里的那些项目，活着的大概只剩三分之一。到了Q4做复盘，大家心照不宣地跳过"规划完成率"这个话题，开始讨论明年的规划。
这个剧本，我见过太多次了。不是某一个团队的问题，几乎是一个行业现象。
规划是怎么死的
先说最常见的死法。
业务需求突然插队。 这个不用多解释，做过的都懂。理财业务突然要接一个新的资产类型，运营搞了个紧急活动，合规要求两周内整改——这些事情不会出现在你的规划PPT里，但它们会吃掉团队80%的产能。技术规划在业务需求面前，脆弱得像一张纸。
人力被抽调。 规划写的时候按10个人算的，Q1过完走了2个，Q2又借调1个去支援别的项目。你拿7个人去做10个人的规划，能完成就有鬼了。
每次聊性能优化，话题总是很快滑向具体的技术手段：懒加载、代码分割、图片压缩、Tree Shaking、虚拟列表……这些当然有用，但我想说一个可能让不少人不太舒服的判断——当你在做这些"优化"的时候，大概率已经晚了。 真正决定性能天花板的，不是你用了多少优化手段，而是系统架构在最初就给你画了多高的天花板。
性能问题从来不是前端单方面的问题。但很多团队把它当成了前端的问题，于是前端工程师就像一个装修工人，在毛坯房里拼命贴墙纸——墙纸再好看，承重墙没打好，房子一样不牢。
优化手段的天花板
先承认一个事实：常规的性能优化手段确实能解决一部分问题。一个从没做过任何优化的项目，加上代码分割和懒加载，首屏时间砍一半不稀奇。图片做个WebP转换、加个CDN，LCP直接降几百毫秒。这些是低垂的果实，摘了就是摘了，没人否认。
但问题是，这些优化有上限。你的首屏要从3秒优化到1.5秒，代码分割和懒加载就够了。但如果你要从1.5秒到800毫秒，甚至到500毫秒以内，单靠前端手段就力不从心了。因为剩余的耗时大头不在前端——它在网络请求、在服务端处理、在数据组装、在协议开销。
配置化平台这两年在金融和电商领域特别火。业务方想要灵活调整页面，需求排期又排不开，于是"配置化"三个字成了万能解药——做活动页？配置化。改文案？配置化。调整布局？配置化。好像只要搞一个配置平台，所有迭代效率的问题就烟消云散了。
但我想说一个可能得罪人的判断：大部分团队的配置平台，最终都变成了另一个更难维护的代码库。 只不过这个代码库没有版本控制，没有代码审查，调试靠肉眼，回滚靠运气。
配置化的承诺
先承认一个事实：配置化的出发点是对的。
在金融业务里，一个理财产品的详情页可能每周都要调整——改一个利率展示规则、加一个风险提示文案、换一个活动入口。这些需求的特点是：变频繁、逻辑简单、但等不及排期。 如果每次都走完整的需求-开发-测试-发布流程，前端团队光是接这些零碎需求就别干别的了。
配置化要解决的核心问题很清楚：把高频、低风险的变更从开发流程中剥离出来，让业务方自助完成。
这个思路本身没问题。问题出在执行上。
第一个陷阱：配置化的范围蔓延
几乎所有配置平台都经历了同样的演化路径。
有个现象我一直觉得很有意思：很多技术Leader当了Leader之后，比当个体贡献者时更忙了。
这不正常。
如果你的管理是有效的，你应该比以前更闲才对——因为你把事情分出去了，别人在做。但现实是，大部分Leader的日常是这样的：早上站会听进度，上午review代码，下午排需求优先级，晚上还要处理线上问题。忙得脚不沾地，但回头一看，团队离了你好像啥也干不了。
你以为这是"能者多劳"，其实这是一个信号：你根本没在管人，你还在管事。
管事和管人，不是同一件事的两种叫法
我见过不少刚做管理的朋友，聊起来都说"我在带团队"。但你仔细看他们的工作内容：拆任务、派活、盯进度、review产出、解决技术卡点……这些是管事还是在管人？
都是管事。
区别很简单：管事关注的是"事情有没有做好"，管人关注的是"人有没有成长"。前者是项目管理的范畴，后者才是团队管理的核心。
这个区分听起来像废话，但大部分技术Leader从来没认真想过这个问题。因为在工程师的世界观里，把事情做好就是一切。升Leader之后，自然也觉得"把团队的事情管好"就是管理。
上个月团队晋升答辩，有个同事没通过。技术能力很强，项目执行也不错，但评委说"影响力不够"。我问他怎么看，他说："我就是想写好代码，为什么非要搞那些虚的？"
我能理解他的委屈。在很多公司，晋升体系名义上是"能力导向"，实际上是另一套游戏规则。技术好不一定能升职，会讲故事、懂包装、有人脉的反而更容易上去。
但这真的是体系有问题吗？还是我们对晋升本身就有误解？
晋升评的不是技术能力，是组织价值
大部分工程师对晋升的理解是：我技术能力达标了，就应该升职。但公司的逻辑是：你对组织的贡献达到下一个级别了，才值得升职。
这两个标准完全不是一回事。
一个高级工程师可能写代码能力很强，但如果他只是完成分配的任务，没有带来超出预期的价值，那在组织眼里他就是"合格的高级工程师"，而不是"应该晋升的资深工程师"。
组织价值不是技术能力的简单加法，而是：在当前级别，你解决了多少原本不属于你职责范围内的问题。