过去一年，AI编码工具的进步速度超出了大多数人的预期。Meta刚发布了Muse Code，又一个CLI编码智能体加入了战场。Cursor、Windsurf、Copilot、Claude Code……工具越来越多，代码越来越便宜。

便宜到什么程度？一个中级工程师用AI，一天能产出过去一周的代码量。这不是夸张，是很多团队正在经历的现实。

但代码便宜了，一个问题就浮上来了：如果代码不值钱了，那什么值钱？

产量不是瓶颈，判断力才是

我观察到一个现象：AI让代码产出速度翻了好几倍，但项目交付周期并没有同比缩短。

为什么？因为真正的瓶颈从来不在写代码这个环节。

想想看，一个需求从提出到落地，写代码占多少时间？通常不到三分之一。更多的时间花在：理解需求到底要什么、设计方案选型、审查代码、修bug、协调依赖、灰度验证。

AI把"写"的时间压缩了，但前后那些环节一点没少。甚至因为代码产出太快，后面的环节压力更大了——代码审查的人跟不上生成的速度，测试资源更加紧张，技术债务以更快的速度累积。

值钱的三件事

我认为在代码贬值的时代，真正值钱的是三件事：

做了这么多年技术面试，回头看，最贵的成本不是招错一个人，而是你根本不知道自己错在哪里。

早期我面试有个执念：能把算法题写出来的人，工程能力不会差。这个信念让我错过了一些人，也让我招错了一些人。直到有次被现实教育——一个面试表现非常出色的候选人，入职三个月就让我开始怀疑自己的判断力。

第一次看走眼

那个候选人来的时候，我们聊了两个小时。从系统设计到编码细节，他都能接住。我问他一个并发场景怎么处理，他几乎是脱口而出地给了三种方案，还主动比较了优劣。

面试结束我就跟团队说，这个人我要了。

入职后呢？代码确实写得不错，Review也能过。但慢慢地问题浮出来了：跟产品对需求理解有偏差时，他不会主动澄清，而是按自己的理解做完再说。跟后端联调遇到接口不一致，他倾向于等别人改而不是沟通解决。分配任务时，他永远选技术最有趣的那个，而不是业务最紧急的那个。

三个月后我开始反思：我在面试里到底看到了什么？

答案是：我看到了一个"面试能力强"的人，但没看到一个"工程能力强"的人。这两个东西，重叠度远没有我想象的高。

"流畅"的陷阱

上个月，一个技术朋友跟我吐槽。

他的团队花了两周设计了一套重构方案，要把跑了五年的单体应用拆成微服务。架构设计很扎实，领域划分清晰，接口定义规范，甚至连服务间通信方案都做了三版对比。

评审会上，他讲了45分钟，从领域驱动设计讲到CAP定理，从服务网格讲到可观测性。CTO听完，问了一个问题："这个事做了之后，下个季度的大促能少出几次故障？"

他愣了一下，说："理论上会改善。"

CTO说："你们再想想。"

没有然后了。

这不是段子。我见过太多类似的场景，包括我自己。一个技术方案，技术上无懈可击，但就是过不了决策者那关。大部分技术Leader的第一反应是：他不懂技术。但如果你仔细复盘，问题往往不在技术本身。

决策者到底在听什么

技术方案被否，十有八九不是技术有问题，而是呈现方式和决策者真正关心的东西之间有错位。

技术Leader做方案评审，通常的逻辑是：先讲现状有什么问题，再讲对比了几种方案，最后讲为什么选这个。这个逻辑没毛病，但讲着讲着就容易变成技术展览——架构怎么拆、数据怎么迁移、性能数据有多好看。30分钟里25分钟在讲HOW，5分钟讲WHY，而且这个WHY还是技术视角的WHY。