夜雨聆风技术经理最该担心的，不是 AI 会不会替代自己。
更真实的问题是：当团队写代码的速度突然变快十倍，你还在用过去那套办法管团队吗？
我最近看了 Fiona Fung 在 Anthropic Code w/ Claude 2026 上的一场演讲。Fiona 现在负责 Claude Code 相关工程团队，之前在微软做过 Visual Studio，也在 Meta 带过 Facebook Marketplace 和 Instagram 的工程团队。她这场演讲的题目听起来很普通，叫《Running an AI-native engineering org》，大意是 AI 时代怎么管理一个工程组织。
但我看完之后，感觉它真正讨论的不是“AI 工具怎么用”，而是一个更尖锐的问题：
如果研发组织进入 AI 原生阶段，什么样的技术经理会变得更值钱？什么样的技术经理会被组织自然淘汰？
我的结论很简单：AI 原生组织里，技术经理不能只做协调者了。你必须重新变成一个有产品判断、有技术信用、能亲自使用 AI 改造工作方式的超级 IC。
Fiona 在演讲里讲了一个很有意思的对比。
她早年在微软参与 Visual Studio 2005 时，软件还要通过 CD-ROM 分发。那个时代的软件交付有非常明确的物理限制：代码必须在某个日期前封版，然后送去工厂压盘，再进入商店货架。
后来互联网分发出现，物理介质的限制消失了。团队可以更快发布，更快修 bug，更快收到反馈。
到了今天，AI 正在拿掉另一个限制：写代码本身的带宽。
过去一个功能要不要做，往往要先问：工程资源够不够？排期排不排得进去？做这个会不会挤掉另一个需求？
这些问题不是错的。它们只是建立在一个旧前提上：代码很贵。
但在 AI 原生研发里，代码开始变便宜。一个产品经理可以用 Claude Code 改小功能，一个工程师可以让 AI 生成几种 API 方案，一个管理者也可以在会议间隙看代码、改脚本、补自动化。
问题随之改变了。
真正贵的东西不再是“谁来写这段代码”，而是：
谁能判断这个方案是不是对用户更好？
谁能判断 AI 生成的代码有没有架构风险？
谁能判断哪些流程已经过时？
谁能在大量产出里保持质量、安全和一致性？
这就是 AI 原生组织的第一个变化：瓶颈从开发资源，转向专家评审和人类判断。
代码多了，判断力反而更值钱。
传统工程团队里有一种很常见的场景：大家围着白板争论 API 设计、模块边界、实现方案。每个人都能讲出一套逻辑，会议开完，结论还停在空气里。
在过去，这样做有一定道理。因为写代码贵，试错也贵，所以大家希望在动手前多想一点。
但如果原型成本已经很低，继续长时间争论就变成了浪费。
Fiona 提到，她现在遇到技术分歧时，不一定会继续说服对方。更有效的办法是直接让 AI 生成几个不同方案的 PR，然后把真实代码摆出来看。
这件事改变了讨论的性质。
以前大家争论的是“我觉得这样更好”。现在可以直接比较：
调用方会不会变复杂？
测试会不会更难写？
依赖关系有没有变乱？
后续维护成本是不是更高？
代码胜过雄辩。
这句话在 AI 时代会变得更重要。因为构建成本下降后，组织里最昂贵的东西，往往不是多写了一个原型，而是十几个人在会议室里悬而未决。
很多管理者有一种安全感，来自一份看起来很完整的半年路线图。
每个季度做什么，每个团队负责什么，每个里程碑在什么时间完成。它给人一种“事情在掌控中”的感觉。
但 AI 原生团队的节奏会让这类路线图更快失效。
不是说规划不重要，而是规划的形态会变。过去的规划像铁路时刻表，提前排好车次，到点发车。AI 原生组织里的规划更像导航软件：方向要清楚，但路线要根据实时路况不断重算。
如果一个团队三个月前写下的计划，到今天还完全不用改，那不一定说明计划好，可能说明团队对新信息太迟钝。
我更喜欢把它叫“即时规划”。
项目启动前，只做足够必要的判断。能用原型验证的，就别在文档里猜。能用用户反馈修正的，就别把半年后的细节写死。
这对技术经理提出了一个新要求：你不能再只靠排期制造确定性。你要能建立一种更快吸收信息、更快修正方向的团队习惯。
Fiona 讲到一个小故事。
他们曾经想把终端里的 Claude 图标做成一个雪人。AI 很快生成了一个版本，但结果看起来不像雪人，更像一个奇怪的“花生先生”。
这个例子有点好笑，但背后很严肃。
AI 可以生成大量方案，但它不知道哪个方案让用户觉得舒服，哪个方案只是“看起来完成了任务”。它能补文案、补设计、补代码，却不能替你承担最终的品味判断。
这也是我认为 AI 时代工程师和技术经理都必须补的一课：产品感和审美会变成硬能力。
过去很多技术人会把这件事外包给产品经理、设计师或者老板。自己只负责实现。
但 AI 原生组织里，角色边界会变模糊。产品经理可能直接提交代码，工程师可能直接改交互，管理者可能直接写自动化脚本。
当每个人都能跨过原来的技能门槛，真正拉开差距的就不是“会不会写”，而是“知不知道什么值得写”。
有一种误解是：AI 越强，专家越不值钱。
我反而觉得正好相反。
AI 会吃掉大量常规代码、样板代码、迁移代码、胶水代码。可当这些工作被拿走后，剩下的往往是更难的部分：
分布式系统里的边界条件
大规模并发下的性能问题
远程执行环境里的安全风险
多团队共享模块的长期演化
用户体验里那些无法量化的细节
这类问题不是“问一下 AI”就能解决。AI 可以帮你搜索上下文、生成候选方案、写测试，但最终需要有人知道系统为什么会坏，知道哪里不能动，知道一个看似优雅的改法会不会在三个月后变成事故。
所以 AI 原生组织不是不需要专家，而是更需要真正的专家。
它不需要的是只靠信息差生存的人。它需要的是能处理复杂性的人。
这可能是整场演讲里对管理者最不舒服的一点。
Fiona 提到，她希望管理者在团队里先作为 IC 运转一段时间。不是象征性体验一下，而是真的使用产品、理解代码、参与工作流。
这和很多传统管理路径不一样。
过去技术经理的价值，经常来自协调、分配、同步、汇报。团队规模越大，会议越多，管理动作越重，看起来就越像“管理”。
但在 AI 原生组织里，这套东西会被压缩。
因为很多信息同步可以被 AI Routine 替代，很多状态更新可以自动生成，很多上下文检索不需要人工搬运。管理者如果还把主要时间花在“收集信息再转述信息”上，就会越来越像一个低效中转站。
新的技术经理要做三件事。
第一，亲自使用 AI 改造自己的工作。
不是转发几篇 AI 文章，不是要求团队提交 AI 使用周报，而是自己真的用 AI 写脚本、查日志、改小功能、生成 PR、整理客户反馈。你只有亲自使用，才知道工具边界在哪里，才知道团队的摩擦在哪里。
第二，保留技术信用。
技术经理不一定每天写核心代码，但你不能离代码太远。AI 会让上下文切换成本下降，也让管理者有机会重新参与一些小而具体的技术工作。哪怕只是修一个内部工具、补一段自动化、review 一个关键 PR，也比只在会上问“进展怎么样”更能建立信任。
第三，杀掉过时流程。
Fiona 讲过一个很典型的画面：一个 50 人周会，所有人都低头看电脑，只有被叫到名字时才抬头说几句状态。
这种会议应该当天取消。
AI 时代不是所有事情都要加速，但那些本来就低价值的流程，会在高吞吐环境里变得更刺眼。技术经理的职责不是维护仪式感，而是清理噪音，让团队把注意力放回判断、验证和用户价值上。
我不太喜欢“X% 的代码由 AI 生成”这种指标。
它适合做标题，不适合管理研发组织。
因为代码生成比例高，不代表系统质量高。提交次数多，也不代表用户体验更好。AI 可以让团队更快制造代码，也可以让团队更快制造技术债。
更有意义的指标应该看这些：
新人多久能提交第一个有效 PR
从 PR 创建到验证通过要多久
自动化测试和代码评审能覆盖多少风险
安全问题是否更早被发现
用户是否真的感到产品更好用
如果 AI 让代码产出变快，而 CI、测试、评审、安全扫描没有跟上，团队只是把瓶颈从编码搬到了验证。
这不是进步，只是换了一个堵点。
如果你已经做了很多年技术经理，我觉得不必焦虑。
AI 不会自动淘汰老管理者。真正危险的是：你把过去有效的经验，当成未来也必然有效的规律。
老技术经理其实有优势。
你见过系统怎么坏，见过组织怎么慢，见过需求怎么变形，见过一次错误架构选择如何在几年后收利息。这些经验不会被 AI 取代。
但你需要把经验接到新的工作方式上。
可以从几个问题开始自查：
我这周有没有亲自用 AI 解决一个具体技术问题？
我这个月有没有取消一个低价值会议或流程？
新人能不能在第一周就借助 AI 提交第一个 PR？
团队的争论是否能更快变成原型对比？
我的主要价值是在传递信息，还是在提升判断质量？
技术经理在 AI 时代的价值，不是站在团队外面指挥 AI 化。
你要进入现场。
你要知道工具怎么改变工作，知道团队哪里卡住，知道什么该保留，什么该删掉。你要能用经验判断方向，也能用新工具亲自改变局部。
这类管理者不会变便宜。
他们会变得更稀缺。
如果只从这场演讲里带走一个动作，我建议是这个：
今天就找出团队里最吵、最耗时、最少产生判断的流程。
可能是一个大型状态会，可能是一份没人看的周报，可能是一套为了节省开发资源而设计的审批动作。
然后问一句：在 AI 已经能生成摘要、检索上下文、创建原型、辅助评审的情况下，它还有存在的理由吗？
如果没有，就删掉。
AI 原生研发组织的起点，不是买更多工具，而是承认旧流程不再天然正确。
当代码变便宜，争论就变贵。
当产出变快，验证就更重要。
当 AI 能做更多事，人类的判断、审美和责任感，反而更值钱。
这才是技术经理在 AI 时代真正的机会。
