坤霆@全栈技术研究室

"全栈"正在被AI重新定义：从"掌握多种技术栈"变成"能调度AI能力、交付完整解决方案"。技术实现不再是瓶颈，问题拆解、质量判断和领域理解成为新的核心竞争力。

Netflix 最近分享了如何重新设计其实时服务依赖地图，核心不是技术细节，而是拆分决策的时机和方式。做了很多年技术管理，我发现架构该不该拆、什么时候拆、怎么拆，是最考验技术管理者判断力的问题。多数团队在两个极端之间摇摆：要么忍着不动直到系统崩溃，要么一上来就大规模重构然后烂尾。

大部分公司积累的数据，产生的价值远低于维护成本。真正有价值的数据建设，不是看数据湖有多大，而是看团队能不能在5分钟内拿到需要的数据并行动。

从Cloudflare Agent Tracing的"先免费后收费"模式出发，讨论可观测性工具的真实成本结构。免费期最贵的不是服务费，而是工程团队的沉没投入和未来的锁定成本。

一个反直觉的观察：事故报告数量增加，不一定意味着系统可靠性在下降，反而可能说明组织的安全文化在改善。讨论工程团队如何建立健康的事故管理文化，以及管理者如何向上汇报这个反直觉的信号。

六个月，十倍增长

JetBrains最近分享了一个数字：半年内，公司开发相关的AI支出增长了大约十倍。

十倍。不是10%，不是翻倍，是十倍。

而且这不是什么AI创业公司，这是做IDE的公司——全球最懂开发者工具的那批人。他们自己都被AI成本的增速吓了一跳，普通团队可想而知。

大部分技术管理者还没意识到，AI工具的账单正在成为一个管理问题。不是"贵不贵"的问题，是"怎么管"的问题。

一个让我愣住的数据

前两天刷到一条消息，a16z的合伙人透露，Cursor的创始人把30%到40%的时间花在招聘和文化建设上。

Cursor，一个估值几十亿美元的AI编码工具公司。按理说，这种公司的创始人应该忙着研究模型、优化产品、跟投资人喝咖啡。结果人家把将近一半的时间放在了一件事上——招人。

说实话，看到这个数字我愣了几秒。不是因为不理解，而是因为太理解了。

技术人读MBA，到底在读什么

先说结论：技术人读MBA，不是为了学知识，是为了换脑子。

我身边有不少技术出身的同事和朋友，听说我在读MBA，第一反应出奇一致："你一个搞技术的，读那个干嘛？"语气里带着不解，也有点揶揄——好像这是某种中年危机的信号。

先讲一个场景

我见过一个团队，技术选型会上，Leader 说"这个组件我们用开源的，社区活跃、文档齐全"。然后呢？然后就没了。没有维护计划，没有贡献策略，没有 license 审计。三个月后，依赖的库作者跑路了，代码里留着几十个 GitHub issue 没人管。更尴尬的是，这个库的 license 是 GPL，法务找上门来问"咱们的代码是不是也要开源"。

AI产品谁都能做，但谁来做判断？

最近见到一个有意思的现象：同一个团队里，同一个AI工具，三个不同的人试用后给出了三个截然不同的结论。

A说"太强了，再迭代一下就能上线"，B说"方向对了但产品还不成熟"，C说"这是在浪费大家时间"。

三个人都是靠谱的工程师，谁都没看错，只是他们站在不同的楼层看问题。

最近看到一条数据让我有点恍惚——Sonar 的2026年开发者调查报告显示，AI 已经占了提交代码的42%，但96%的开发者并不完全信任这些代码。拿了就用，用了又不信，整个行业陷入了一种奇怪的拧巴状态。

我挺能理解这种拧巴的。上个月我们团队做了个内部统计，工具生成的代码在PR里占比确实越来越高，但真正的问题不是"AI能写多少代码"，而是——写了之后，谁来确认这些代码是对的？

贡献者退场，守护者上场

一、35岁不是终点，是拐点

每隔一段时间，“35岁被裁”就会冲上热搜。评论区一片哀嚎，好像到了这个年纪，代码生涯就自动进入倒计时。

我见过不少同行的真实经历。有人35岁确实被优化了，但转头拿了更好的offer；有人28岁就焦虑到不行，觉得35岁魔咒会落到自己头上。这两种人的区别，不是技术能力，而是对职业周期的理解。

一个让我印象深刻的场景

有一次产品经理找我聊一个需求：首页改版，引导用户从"浏览"到"下单"。她给我看了转化漏斗数据，入口到下单的转化率很低，她说问题出在交互体验上。

我扫了一眼数据，发现一个细节：大部分流失发生在"确认金额"这一步，而不是她说的"产品选择"那一步。这不是交互问题，是用户对金额没有预期、被吓跑了。

我跟她说，这个改版的核心不是优化交互流程，而是要在入口就给出价格预期，减少确认页的认知冲击。后来我们改了入口文案，转化率直接提升了 12%。

一个观察

最近在Lobsters上看到一篇文章，标题很直白：《AI is removing the middle class of software engineering》。大意是，AI正在把软件工程师分成两极——能驾驭AI的人和被AI替代的人，中间那层"能写代码但缺乏判断力"的工程师，生存空间正在急剧压缩。

从一个物理学概念说起

2002 年，Elon Musk 想造火箭。他去俄罗斯买，一枚翻新洲际导弹报价 840 万美元。买不起。

大多数人的反应是：火箭就是这么贵，这个行业就是这样，只能在现有供应商里比价。

Musk 没有接受这个前提。他问了一个更基本的问题：火箭到底是由什么组成的？

上周跟一个做技术管理的朋友吃饭，聊到一个让他头疼的事。

季度绩效评估，团队里有人用 AI 工具写了以前三倍量的代码，需求交付速度飞快。按传统标准，这绝对是高绩效。但他总觉得哪里不对。

"代码是写了挺多，但上线后 bug 也比以前多了。而且有些代码，他自己都说不清楚为什么这么写。"

这不是个案。当 AI 编码工具把"写代码"这件事的门槛拉到极低，传统的工程师绩效评估框架，基本上已经失效了。

以前的标准为什么不灵了

过去评估工程师，核心维度无非几个：代码质量、技术难度、问题排查能力、架构贡献。这些都建立在一个前提上——代码是人写的，写得好不好直接反映能力。

AI 改变了这个前提。

现在一个中级工程师借助 AI 工具，一天能产出以前三天的代码量。代码看着像模像样，命名规范、注释齐全、测试也有。但你仔细看，会发现有些实现绕了远路，有些边界条件没覆盖，有些设计决策——根本没有决策，AI 给了什么就用了什么。

产出的量上去了，但产出中"人"的含量变了。

最近跟几个技术管理者聊天，发现一个有意思的现象：大家都在重新考虑招人的标准。

原因很简单——AI编码工具太强了。Cursor、Copilot、Codex这些工具，让一个中级工程师的输出量接近以前的高级工程师。团队不再缺"手快"的人，缺的是"能判断"的人。

这个变化，正在悄悄改变技术招聘的底层逻辑。

编码速度，曾经是硬通货

做了很多年技术，见过不少高P工程师的核心竞争力，说白了就是"手快"——需求来了能迅速出方案，别人三天的活他一天搞定。在编码为主的年代，这种能力确实值钱。

但这个优势正在被稀释。AI工具写得越来越像样，大部分情况下能直接给出80分的代码，改改就能用。当编码速度不再是瓶颈，手快的优势就没那么突出了。

这不是说技术能力不重要了，而是"会写代码"这个能力的市场价值在下降。就像Excel普及后，打字员这个岗位消失了一样。

资深工程师的真正壁垒

资深工程师的价值，从来就不只在写代码上。真正的壁垒是判断力——在信息不完整、约束条件模糊时做出正确选择的能力。

举个常见场景：系统选型，三个方案各有优劣，参数对比AI可以做，但最终选哪个，要考虑合规要求、团队技术储备、未来三年的业务增长方向。这些判断依赖经验和对业务的理解，AI帮不上忙。

什么是 AI Native

过去两年，大多数公司做的事情是"AI+"——在已有产品上叠加一层 AI 能力。搜索加个对话框，客服加个机器人，IDE 加个 Copilot。本质上，产品架构没变，AI 只是一个插件。

AI Native 完全不同。它不是"给产品加 AI"，而是"用 AI 重新定义产品"。

区别在哪里？

• AI+ 产品：传统搜索引擎 + AI 摘要 = 还是搜索引擎
• AI Native 产品：Perplexity = 答案引擎，搜索这个概念本身被重新定义了

前者是增量优化，后者是范式转移。

AI Native 的三个核心特征

1. 交互范式的重构

传统软件的交互模型是命令式的：用户点击按钮、填写表单、执行操作。每一步都需要用户理解系统的抽象模型。

AI Native 产品的交互模型是意图式的：用户表达目标，系统理解意图并执行。用户不需要知道系统内部有多少模块、多少步骤。