上个月有件事让我想了一阵子。

一个需求，评估工期。我看了看，大概涉及三四个接口联调、一套状态管理的重构、还有几个页面的交互调整。按我的经验，五天差不多。结果旁边一个同事，工作经验三年，拿着AI工具两天就交了。

说实话当时心里是有点不是滋味的。不是说嫉妒，是困惑——我花了五年才练出来的手速，好像被一个工具直接抹平了。

但代码审查的时候，我发现他生成的代码里有一个挺隐蔽的问题：状态管理在断网重连场景下会丢数据。这个场景不常见，但在金融业务里，一旦碰上就是资金问题。我花了半天帮他理清楚，又花了半天把相关的边界情况全部过了一遍。

五天 vs 两天，这个对比看起来我慢了。但如果算上后面排查线上问题的时间，到底谁快？

这件事不大，但它让我开始想一个问题：当"手快"不再是稀缺能力，我们这些年积累的经验，到底该怎么重新估值？

速度这个变量，贬值了

做了十几年技术，我一直把"手快"当成一个核心竞争力。写代码快、调 bug 快、出新功能快——在大部分团队里，这就是"资深"的标签。别人一天写完的模块你半天搞定，你就有话语权。

但现在这个优势被AI工具几乎抹平了。一个两年经验的开发者加上 Cursor，代码产出速度可能比十五年经验的工程师还快。代码补全、脚手架生成、单元测试编写——这些以前吃经验、吃手速的活，现在AI做得又快又像样。

如果你还拿"我写代码快"当自己的卖点，就像在计算器面前炫耀珠算——方向错了。

ACM前阵子发了一篇文章，标题很直白：AI Didn't Make Programming Easier, It Just Made It Differently Difficult。AI没有让编程变简单，只是让难点换了位置。以前难在"怎么写出来"，现在难在"怎么判断AI写的东西到底对不对"。以前难在"实现"，现在难在"验证"。

这个转变很微妙。表面上看，大家都在用AI写代码，产出速度都提升了。但真正的差距不在于谁敲键盘快，而在于谁能在AI生成的代码里发现那个藏在第300行的、只有在特定并发条件下才会触发的竞态问题。

这种能力，不是装了个插件就有的。

评价体系在偷偷换赛道

速度贬值的同时，另一件事也在发生：评价资深工程师的标准，正在悄悄变化。

以前评价一个人厉害不厉害，看代码量、看交付速度、看能不能hold住复杂需求。这套体系运行了很多年，大家也习惯了。但现在，AI让基础编码变成了廉价品，组织对工程师的期望也在调整。

小红书技术团队最近提了一个概念叫"产品工程师"（PE），核心变化是把衡量标准从"代码质量和按时交付"转向"业务结果"。这听起来挺合理的，但对很多资深工程师来说，其实挺尴尬的。

尴尬在哪？在于你可能很擅长解决复杂的技术问题，但不擅长把自己的工作翻译成业务语言。你花了两周重构了一个模块，代码优雅了、性能提升了、维护成本降了——但业务方问的是"这对转化率有什么影响"，你答不上来。

我自己也踩过类似的坑。前几年我花了不少精力把团队的前端配置平台从零搭起来，技术上我觉得做得挺好——零代码变更、热发布、灰度可控。但年底汇报的时候，领导问的不是"技术有多牛"，而是"这个平台帮业务省了多少人天、缩短了多少上线周期"。我当时愣了一下，回头才去翻数据：平均每个运营需求的上线周期从3天降到了4小时。

这个数字比任何技术细节都有说服力。但我花了大半年才学会用这个角度去看自己的工作。

慢能力的溢价

说到这里，我想澄清一件事：我不是在唱衰资深工程师。

恰恰相反，我觉得有一类能力正在变得越来越值钱——那些看起来跟"手快"无关、甚至有点"慢"的能力。比如：知道一个问题不值得解决，直接砍掉需求的判断力。比如在三个都能跑通的方案里，凭直觉选出长期最优解的品味。比如理解一个技术决策会怎样影响后面三个环节的决策链，从而提前埋好扩展点的系统思维。

这些能力没法靠装个AI插件获得。它们是在一次次线上事故、一个个被自己推翻的方案、一场场跟产品和业务的争论中长出来的。

有个数据我觉得挺有意思的。DoorDash前阵子分享了一个案例：他们用多Agent系统自动清理代码库里的过期Feature Flag。6万个Flag，AI处理每个平均13.8分钟，成本4.79美元。人工做要1-2小时。效率差了几十倍。

但关键是那15个AI处理不了、需要人工介入的Flag。它们为什么处理不了？因为涉及业务逻辑的歧义判断——某个Flag到底是"暂时关闭等待重新打开"还是"永久废弃应该删除"，这需要理解当时的业务决策背景。AI读不了这层意思，只有做过那个决策、或者能找到当时做决策的人，才能搞清楚。

这就是资深工程师的价值锚点：不是写代码快，而是在AI搞不定的那15个case里，你能搞定。

这些"慢能力"的溢价正在上升，但我得承认，它们的变现方式变了。以前是"我比你快所以我有话语权"，现在可能是"因为我能提前看到坑，所以团队少走了弯路"。问题是——"少走的弯路"很难量化。没人知道你避免了多少次线上故障，就像没人知道大楼的地基多扛了几级地震。

没想通的部分

写到这里，有个问题我自己还没完全想明白。

如果资深工程师的价值确实在判断力、品味和系统思维这些"慢能力"上，那它应该怎么被组织看到和评价？以前靠速度说话，有明确的度量——你一天写多少行代码、一周交几个需求。现在靠判断力说话，度量标准是什么？你避免了多少个bug？你否决了多少个不靠谱的方案？这些东西很难写进周报。

我自己最近在试一个方法：每次做技术决策的时候，把"为什么不做某件事"也记下来。比如我否决了一个用微前端拆分某模块的提案，我会写下当时的理由、预期的风险、以及如果不否决可能会发生什么。过几个月回头看，有些判断是对的，有些是错的，但至少有据可查。

我不知道这个方法能坚持多久，也不知道它能不能变成一种可复制的评价方式。但至少比单纯比"谁需求做得快"要有意思一些。

上周跟一个朋友聊这事，他说了句我觉得挺到位的话："以前当资深工程师，像是跑百米——谁快谁赢。现在更像是下棋——快不是不重要，但你得先走对。"

走对这件事，好像确实快不了。