你团队里写代码最快的那个人——产出高、PR 从不积压、feature 完成数永远第一——可能是 AI 时代第一个变得平庸的。

这话说出来得罪人，但我越来越确信这个判断。

过去两年，我看着 AI 编码工具把"实现"这件事的边际成本压向零。GitHub 2022 年的 Copilot 研究显示，特定编码任务完成速度提升 55%。Accenture 2024 年的企业级测试更直接——启用 Copilot 后 90% 的开发者会将包含 AI 生成片段的代码推进生产。在我自己的工作中，中等复杂度的实现（写一个 REST API、做一次数据格式转换、搭一个 CRUD 模块）从小时级压缩到了分钟级。

这意味着什么？

意味着"写代码"这项能力的差异化价值正在坍塌。AI 给所有人加了相近的绝对产出量。过去 A 工程师一天 200 行高质量代码、B 工程师 100 行，差距是 2 倍。现在 AI 给每个人都加上了 1400 行的实现量，A 产出 1600 行，B 产出 1500 行。差距从 2 倍缩到了 1.07 倍。再往后推，实现速度这个变量会被完全拉平。

当所有人都能以差不多的速度写代码时，“写得快"就不再是区分因子了。

那什么才是？

我回头看自己这两年的时间分配变化：

两年前——60% 写代码，20% 调试测试，15% 方案讨论。我是个写代码的人，偶尔需要想一想方案。

现在——40% 定义问题和审查 AI 产出，30% 架构决策和技术选型，只有 20% 在自己"写"代码。但产出量没降，因为 AI 补上了那 40% 的实现量。

角色从"执行者"变成了"决策者”。而我发现，能做好这个转变的人和做不好的人之间，产出差距不是 2 倍，是 10 倍。一个决策对的人加上 AI 执行力，产出是乘法关系；一个决策错的人加上 AI 执行力，浪费也是乘法关系。

所以"10x 工程师"的定义需要重写。不是"写代码快 10 倍的人"，而是"做对决策、让 AI 帮他以 10 倍速度落地的人"。

接下来我用三个工程场景说明白这件事（诊断方向、架构选择、技术选型）。以下场景综合了我在多个团队的观察，细节有调整，但每个决策失误我都亲眼见过不止一次。

一、方向错了，AI 越快你越惨

我共事过的一个后端工程师，效率极高。5 年经验，手速惊人——能同时追踪三四个 PR、新 feature 从 ticket 到上线通常只要两天。团队 8 个人，他的产出量稳定占三分之一。

那次事故发生在 Q2 大促前两天。商品详情接口 P99 从 80ms 飙到 320ms。运营在群里炸锅——“商品页转化率掉了 40%，用户还没看到价格就关了”。技术 oncall 把告警丢到群里，他 15 分钟内就接手了。这种事交给他大家都放心——他处理性能问题的速度在组里是公认最快的。

他的反应非常快。打开 Cursor，跟 AI 对话了几轮，15 分钟后已经有了一个清晰的方案框架：Redis 多级缓存。L1 用本地 caffeine 做进程内缓存，TTL 30 秒；L2 用 Redis cluster 做分布式缓存，TTL 5 分钟。配套缓存预热、失效策略、降级兜底全套。

为什么他直觉就选了缓存方案？因为上一次 P99 告警就是缓存命中率下降导致的。路径依赖——拿到同类告警，直觉反应就是补缓存。加上 oncall 有 30 分钟 SLA 压力，他跳过了诊断步骤直接进入方案实施。

两天内代码完工。1200 行左右，单测覆盖率 87%。PR description 写了 3 页，有架构图有时序图。review 的同事评价"方案很成熟"。

确实成熟。但它没解决问题。

因为 P99 飙升的根因不是"缓存没命中"。根因是少量特定请求的响应时间从 50ms 变成了 2400ms，拖垮了整体 P99。具体来说，只有涉及"智能推荐属性"的请求（约 0.8% 的流量）触发了慢查询，但单次耗时 2400ms，足以将 P99 从 80ms 拉到 320ms。

具体原因：商品属性表的动态查询——产品经理两周前加了"智能推荐属性"功能，把 IN 子句的枚举值从 3 个膨胀到了 47 个。ORM 拼出来的 SQL 走不了原有索引，变成了全表扫描。240 万行的表全扫一遍，每个请求 2-3 秒。

EXPLAIN ... → type: ALL, rows: 2,400,000

一眼就能看出问题。

修复方案？一行 DDL：ALTER TABLE product_attributes ADD INDEX idx_product_attr (product_id, attr_type)。几分钟内通过 online DDL 上线，P99 降回 80ms 附近。

对比一下两个方案：

缓存方案：耗时 2 天，代码约 1200 行，新增 Redis Cluster + caffeine 两个依赖，引入缓存一致性、预热、降级全套运维负担。结果？没解决问题（缓存了慢查询的结果，慢查询本身仍在）。

正确方案：耗时 30 分钟（含灰度验证），1 行 DDL，无新依赖，无运维负担。问题解决。

他不是能力不行。恰恰相反——缓存方案在技术上无可挑剔。问题在于他没有花 10 分钟确认"该解决的是什么问题"。他跳过了问题定义，直接进入了解决方案。

AI 让这种跳跃更容易发生，也更危险。过去"写一套多级缓存"需要一周，实施成本高到你会先停下来想想"这是不是最优解？"。现在有了 AI 辅助，两天就能搞定。门槛低了，反而更容易跳过诊断直接进入实施。而且你做了之后感觉还挺好的——代码质量高、覆盖率够、方案完整。一切看起来都对，除了方向。

方向错误 × 高速执行 = 高效浪费。 AI 放大了执行力，也放大了方向错误的代价。

在动手之前花 10 分钟确认方向对不对，区分"症状"和"根因"，不被 AI 的高效执行迷惑——这是 10x 的第一个维度：问题定义准确。

二、大决策比小优化值钱得多

另一个场景。12 人后端团队，负责一个内部 CRM 系统，DAU 大约 2000，峰值 QPS 不到 50。系统要从老旧的 PHP 单体迁移到 Go——这个决策本身没问题，PHP 版本已经 EOL 了。

争论焦点是迁移后的架构。

“微服务派"由 3 个高级工程师组成。他们的方案：拆成 5 个服务——用户服务、权限服务、审批流服务、通知服务、报表服务。每个服务独立 repo、独立部署、gRPC 通信。论据很充分：

• “单体到了一定规模就是噩梦，不如一开始就拆好”
• “微服务好招人——你去看看 JD，哪个不要求微服务经验”
• “AI 能帮我们快速生成 proto 和脚手架，不费事”

他们不是在空谈。用 Cursor 确实 30 分钟就能生成完整的微服务骨架代码：proto 定义、服务注册、health check、CI pipeline template，全套。Demo 做得很漂亮。

但这里藏着一个 AI 时代的独特陷阱：AI 把脚手架成本降到几乎为零，让**“过度设计"看起来没代价**。但脚手架只是微服务运维成本的冰山一角。

我看了几个数字之后有不同判断。

DAU 2000，峰值 QPS < 50——这是一个典型的内部工具级负载，不是面向百万用户的高并发系统。12 人团队里有 4 个今年入职的 junior——他们连单体的业务逻辑还没吃透，现在要他们理解分布式事务和服务间调用链？没有独立 SRE 或 DevOps——所有运维由开发兼任。业务变化快——产品经理每两周改一次审批流程。

5 个微服务在这个场景下意味着什么？

5 套独立的 CI/CD pipeline，每个服务版本号独立，灰度发布要考虑兼容性。跨服务事务——审批流改了要同时改权限服务，要么 saga 要么最终一致性，都是复杂度爆炸。本地开发从 go run main.go 变成 docker-compose up 起 5 个容器加一个 API gateway。Debug 一个 bug 要看 5 个服务的日志。Junior 上手时间从"两周能写 feature"变成"两个月还在理解服务间调用关系”。

我的判断：这个团队、这个阶段、这个负载量级，微服务的运维成本远大于它带来的收益。 模块化单体是更优解——包结构清晰、接口抽象到位、未来真到了拆分的那天（DAU 破万、团队过 30 人），沿着模块边界拆就行。

这个"不做"的决策，后果是什么？

团队没花 3 个月踩分布式调试的坑。4 个 junior 在单体项目结构里两个月上手，第三个月开始独立交付 feature——如果是微服务，他们第三个月可能还在跟 docker-compose 的网络配置搏斗。产品经理的需求迭代速度快了——改审批流就在一个仓库里改，上午提需求下午能看到灰度，不需要协调三个服务的联动发布窗口。

半年后回头看，这个决策省下的不只是 3 个月开发时间。它省下的是整个团队的心智负担——每个人只需要理解一个系统，而不是理解 5 个系统之间的交互关系。这种简单性的复利效应比任何微服务的"弹性扩展"都值钱。

AI 能帮你快速生成微服务脚手架，但它不会提醒你"你的团队撑不起这个复杂度”。做出这个判断需要综合考量团队构成、业务阶段、运维资源。AI 可以给你选项分析和约束条件罗列，但最终的优先级排序——junior 的真实水平、产品经理改需求的频率、团队能承受的运维复杂度——需要你对这个团队的体感判断和责任承担。

所以架构判断力——这是第二个维度——本质上是在特定约束条件下识别总成本最低的路径。一个对的大决策，比一百个对的小优化值钱，因为大决策是乘法因子，做对了全团队提速，做错了全团队踩坑三个月。

三、不追新是一种能力

最后一个场景。6 人团队要重构通知系统，从轮询改为实时推送。两个候选方案摆在桌上。

方案一是 Hacker News 本月当红炸子鸡——某个实时通信框架（姑且叫它 PushWave）。发布仅 4 个月，v0.3，官方宣传"比 WebSocket 快 3 倍"“零配置分布式"“AI-native 设计，prompt 驱动 API”。GitHub star 两周涨了 8000。社交媒体上到处是"试了一下太爽了"的安利帖。

团队里有人用 AI 跑了个 demo——10 行代码建立实时连接，比手写 WebSocket 的确简洁太多。Demo 里消息秒达，体验很好。他在技术分享会上演示了这个 demo，反响热烈。

方案二是 coder/websocket（前身 nhooyr.io/websocket）——Go 生态当前最活跃的 WebSocket 库，API 设计简洁、并发安全、零外部依赖——加上自己写连接管理层。代码量多不少，没有 demo 的那种"啊哈时刻”，但每一行你都知道它在干什么。

表面看，选方案一是理所当然的。AI 让"试新东西"的成本几乎为零——10 分钟跑通 demo，为什么不选体验更好的？

我把两个方案拉到几个维度上看：

成熟度：PushWave v0.3，核心贡献者只有 2 个人。coder/websocket 有多年积累（其前身维护近 8 年），API 稳定，5000+ star。

生产案例：PushWave 官网列了 3 个小项目，都是个人开发者做的 side project。coder/websocket 被 Coder、Mattermost 等生产系统使用，并发验证充分。

遇到 bug 怎么办：PushWave 提 issue 可能等几周——作者只有 2 个人，还在忙着写 v1.0。coder/websocket 你去 Stack Overflow 搜，10 秒有答案，因为踩过这个坑的人太多了。

AI 辅助准确率：AI 对 PushWave 的训练数据几乎为零（太新了），生成的代码经常是错的。对成熟 WebSocket 库，AI 有大量训练样本，生成的代码准确率非常高。

我选了方案二。原因很简单：成熟度本身就是信息量。一个经过千万用户验证的工具，它的边界在哪、什么场景会出问题——你能通过搜索和社区经验查到。新工具的边界，需要你自己踩出来。每次"踩边界"都是时间和精力的支出。

结果验证了这个判断。三个月后，隔壁组选了类似新框架的团队跟我们吐槽：最致命的是作者在第 10 周宣布暂停维护全力开发 v1.0，等于他们在用的版本变成了孤儿。紧接着连接数超过 5000 时出现内存泄漏——官方文档没提这个限制。他们第 8 周被迫回退重新实现，两个月开发时间打水漂，上线日期推迟了一个月。

这里的核心洞察是：AI 让你"试新框架"的门槛降低了，但demo 跑通和生产可用之间的鸿沟并没有缩小。AI 只是让你更快地站到了鸿沟边上。越容易跳进去，就越需要克制力。

不是说永远不用新工具——而是区分"有充分理由的技术升级"和"被社交媒体热度驱动的冲动选型"。选择成熟方案不是保守，是基于信息不对称的风险管理。在 AI 时代试新的成本太低导致人人都在追新，能克制住冲动反而变得稀缺。

技术选型稳，这就是第三个维度的核心。不赶时髦、不过度设计，在诱惑面前保持判断力。

四、三个维度，一个框架

回过头看这三个场景，它们指向同一个底层逻辑：

当实现成本趋近于零，决策质量成为唯一剩余的乘法因子。

过去"项目价值"这个公式里有三个变量：方向正确度 × 实现质量 × 实现速度。AI 把后两个变量拉平了——所有人都能以差不多的质量和速度完成实现。剩下的唯一区分变量就是方向正确度。

这三个维度不是独立的清单，它们之间有乘法效应：问题定义准确（不做错的事）× 架构判断快（在约束下选最优路径）× 技术选型稳（不在执行层引入新风险）。三个维度同时对的人，产出呈乘法效应——因为每个正确决策都放大了其他决策的收益。反过来，任何一个维度出错，都会让其他维度的努力归零。缓存方案技术完美但方向错误，微服务派的架构选型精致但不匹配约束，PushWave 的选型让整个实现要推倒重来。

这不只是我的观察。DHH 多次表达过类似态度——AI 放大的是你已有的判断力，不会凭空创造新的。如果判断力不行，AI 只是让你更高效地犯错。

越来越多大厂已经意识到这个问题——当 AI 让所有人都能快速产出代码时，缺少判断力的产出反而成了风险。实现门槛降低了，但决策门槛没有降低。AI 民主化的是实现能力，不是判断力。

回头看我自己的时间分配变化——写代码从 60% 降到 20%，决策相关的工作从 15% 升到 70%——不是因为公司给我升了职不用写代码了。是因为决策环节成了产出的瓶颈。AI 解放了我的手，但没有解放我的判断力。恰恰相反，它让我的判断力成了全流程的限速环节。

回到开头

你团队里写代码最快的那个人——如果他的"快"只是打字快、实现速度快、PR 提交频率高——那 AI 正在消解这种优势。每个人加上 AI 都能打字快。

但如果他的"快"是另一种快——定义问题快（一小时内锁定真实瓶颈）、架构判断快（一天内给出可执行的技术路线）、选型决策快（半天内排除不靠谱的选项）——那他在 AI 时代会更强。因为 AI 放大了他每一个正确决策的执行速度。一个对的方向，现在能以 10 倍速度被落地。

旧 10x：一个人写了 10 个人的代码量。

新 10x：一个人做的决策，让整个团队少走了 10 倍弯路。

你可能会说：“手速仍然重要。AI 不是万能的，很多场景还是需要工程师快速迭代。” 对。但快速迭代的瓶颈从来不在"打字速度"——而在于"知道迭代的方向"。一个方向错误的快速迭代只会更快地到达错误的终点。手速是加法因子，方向是乘法因子。

有人问过我：“10x 从来不是手速。好工程师从来就是靠判断力。” 也对。但旧时代我们衡量"好工程师"的指标偏向产出量——PR 数、feature 完成数、代码行数、bug 修复数。这些量化指标在 AI 时代全部失效了，因为 AI 让每个人的产出量指标都漂亮。我们需要新的衡量框架——而"旧 10x"定义中那些关于判断力的成分，恰恰是没被量化过、也没被认真对待过的部分。

我给出的答案是三个维度：问题定义、架构判断、技术选型。

不一定完美。但至少比"判断力很重要"这种空话多了三个可以对照自检的方向。下次做技术决策之前，试试问自己：我在解决正确的问题吗？我的架构选择在当前约束下总成本最低吗？我选的技术栈经得起三个月的生产考验吗？

想清楚这三个问题，比"我能不能写得更快"重要得多。写代码的速度，AI 已经帮你搞定了。方向的事，还得你自己来。

你的团队里，10x 靠什么赢？留言区聊聊。

原文发布于 止语Lab