AI 正在彻底改写技术行业的工作范式。AI 大幅提升效率的同时，也带来协作疏离、质量把控难等全新问题。本文结合一线高管经验，解读 AI 时代工程师与管理者的能力转型趋势。

如果有一天，工程师写代码的时间只占工作的一小部分，那工程师还算不算工程师？这听起来像是个遥远的假设，但在Anthropic的Claude Code和Cowork团队里，这已经是正在发生的现实。Fiona Fung是这两个团队的负责人，她最近在Lenny’s Podcast上分享了一组数据，Anthropic的工程师平均每个季度交付的代码量，是几年前的八倍。不是缓慢爬升的曲线，是一条一直很平的线突然冲上了天。

听完这期播客，我脑子里冒出来的第一个念头是，编程这件事可能真的变了，而且变得比我们大多数人意识到的还要彻底。Fiona的经历很有说服力，她当工程师超过25年，从IBM写底层操作系统服务起步，到微软做Visual Studio和TypeScript整整11年，再到Meta从零搭建Facebook Marketplace，现在这个产品每年的GMV超过1000亿美元。她还参与过Meta第一代智能眼镜和AR眼镜项目，在Instagram带过500人的团队。这样一个人来谈AI怎么改变工程师的工作方式，分量是不一样的。

写代码不再是稀缺资源

Fiona讲了一个让我印象很深的对比。她说自己当年在微软做Visual Studio的时候，软件是刻在CD上发行的，每一次发布都有硬性截止日期，工程师的时间被当成最稀缺的资源，团队会花大量精力做计划，确保在有限的时间窗口里把事情做对。但现在情况完全反过来了，coding不再是瓶颈，反而把每个人能做的事情的天花板都给掀开了。

这句话我反复琢磨了好几遍。以前的限制是人手不够、时间不够，所以一个想法好不好，往往要先问值不值得投入工程资源去做。现在限制变了，理论上什么都能做，问题变成了你敢不敢想得更大。Fiona提到团队里一个工程师的真实经历，他本来不是做移动端的，但当产品需要补上移动端功能时，他直接说没关系，现在有Claude帮我一起做这件事。这种心态的转变，比八倍的代码产出数字本身更值得注意。产出是结果，敢于伸手去做以前觉得超出能力范围的事情，才是原因。

我自己在做内容创作和产品的过程中，也越来越能体会到这种感觉。以前觉得某个想法太复杂，需要专门去学一项新技能才能落地，常常因此放弃。现在反而会先问一句，这件事真的需要我亲自掌握所有细节吗，还是说我可以借助工具，把精力放在判断方向对不对上。这其实是把人的角色从执行者往前推到了决策者的位置，这个转变对很多人来说是机会，但对还停留在旧思维里的人来说，可能就是一种被甩在后面的焦虑。

Agency和accountability要绑在一起

Fiona提到一个词，agency，中文大概可以理解为主动性，或者说自主决策的能力。她说在Claude Code团队里，遇到一个问题，不是等着被分配任务，而是每个人都会主动想办法去解决，这是团队最看重的特质之一。但她马上补了一句，高agency必须配上高accountability，也就是高问责。给你足够的自由去发挥，但你也要清楚地说明你想解决的问题是什么，你的假设是什么。

我觉得这句话点出了一个很容易被忽略的陷阱。很多人理解AI agent带来的变化，只看到了自由度变大这一面，觉得反正有工具兜底，做错了重新生成就好，胆子可以放得更大。但Fiona强调的是，自由和责任是一体两面的，agency越高，越要能讲清楚自己在为什么目标负责，而不是把责任都甩给工具。这其实跟以前管理团队的逻辑没有变，变的只是行动的速度和门槛。门槛降低了，反而对判断力和说清楚动机的能力要求更高了。

这一点对我自己的工作方式也有启发。以前做一件事，流程本身会过滤掉很多不靠谱的想法，因为光是执行成本就足够让人三思。现在执行成本几乎消失了，真正能区分一个人做得好不好的，变成了他有没有能力提前想清楚要解决的问题是什么，做完之后能不能讲明白这个结果到底解决了什么。换句话说，思考的权重在上升，执行的权重在下降。

异步和routines改变了管理者的一天

Fiona分享了她自己工作方式的变化，这部分我觉得特别真实。以前她每天早上喝咖啡的时候，会去看团队的反馈渠道，自己判断哪些问题值得花时间处理。现在她设置了routines，可以理解成自动化的工作流程，每天早上自动扫描所有反馈渠道，总结出主题，甚至直接生成可以审查的PR。她说这就像是从自己生成prompt，变成了有一个agent帮她生成prompt和PR，抽象的层级又往上提了一层。

她还提到自己保留了一个Claude Code的远程会话，接入公司所有的代码仓库，也接入所有的Slack频道，这样她对团队在做什么有完整的可见度。每个月她会和团队一起回顾，过去这段时间聚焦在哪些方向，产品上线后效果怎么样，反馈渠道里都说了什么。她说以前这些会议大部分时间用来生成PR和修bug，现在这些会议变成了真正意义上跟人对话的时间，聊的是影响力，而不只是产出了多少。

这一段让我重新理解了管理者这个角色在AI时代应该往哪个方向走。管理的核心从来不是盯着任务清单，而是帮团队判断方向对不对、资源该往哪里投。以前因为信息获取成本高，管理者不得不花大量时间做信息整理这种体力活，真正花在判断和对话上的时间反而被挤占了。现在工具把信息整理这一层接管过去了，管理者被还原成了它本来该有的样子，一个负责判断和沟通的人，而不是一个信息搬运工。我觉得这才是Cowork这类工具真正厉害的地方，它解放出来的不是工作量，而是注意力。

Trust but verify，验证比写代码更难

产出涨了八倍，质量怎么保证，这是我听这期播客时最关心的问题。Fiona给出的答案是trust but verify，也就是信任但要验证。她说Claude在有明确框架可以对照验证的时候表现非常好，所以她们的做法是把什么叫好的标准写成spec，放进代码仓库里，跟随代码一起更新，这样Claude做代码审查的时候，就有一个清晰的标尺可以对照。

她还分享了一个很形象的框架，叫bad和sad。bad是指那种不可恢复的严重错误，比如程序崩溃导致工作丢失。sad是那种可以恢复、但体验不好的小问题，比如界面闪烁了一下。她说sad堆得多了，也会慢慢演变成bad，所以团队会主动盯着sad的数量，而不是等它恶化成真正的事故才处理。这种分级方式比单纯看一堆性能指标仪表盘有用得多，因为指标太多太碎的时候，人反而很难判断一个数字到底好不好。

我觉得这套思路的价值，远远超出了软件工程的范畴。任何依赖AI agent去批量产出内容或者执行任务的场景，都会遇到同样的问题，产出快了，谁来把关质量。Fiona给出的解法本质上是把人的精力从逐条检查，转移到了设计验证标准和监控体系上。人不再是质检流水线上的一环，而是定义什么叫合格的那个人。这个角色转变，我觉得比单纯讨论AI agent能不能写好代码，更值得每个用AI做内容或者做产品的人认真想一想。

一个人对着agent干活，会孤独

这一点是我完全没想到、但听完觉得特别真实的细节。Fiona说团队最近发现，大家因为太频繁地各自跟自己的agent协作，工作开始变得孤独。以前团队协作是真正意义上的协作，有人写后端，有人写前端，大家互相依赖、互相讨论。现在每个人都可以独立完成一整条任务链，人和人之间的交集反而变少了。

团队的应对方式是搞了一个pair-wise programming lunch，也就是结对编程午餐，大家一起观察彼此是怎么用Claude Code和Cowork的，互相学习不同的使用方式。Fiona说每个人用这些工具的方式都很不一样，光是看别人怎么操作，自己就能学到东西。她们还会专门安排hackathon，确保团队还有一起做事的时间。

这让我意识到，效率的提升和人的连接感，有时候是两件需要分别花心思维护的事情，不会自动同步发生。工具让单个人的能力边界扩大了，但团队作为一个整体的粘性，不会因为每个人都变强而自动变强，反而可能因为大家各自为战而被稀释。我觉得这对任何团队都是一个提醒，效率工具带来的孤独感是真实存在的副作用，需要主动设计一些机制去对冲，而不是假设它会自己消失。

管理者也要先做执行者，也要持续用自己的产品

Fiona提到她们招管理者有一个原则，新管理者入职之后，会先有一段时间纯粹做IC，也就是个人贡献者，先深入代码和产品本身，再去承担带人的责任。她说如果一上来就急着扮演管理者的角色，反而很难真正跟团队建立信任。先花时间理解产品和代码，再去支持别人，这个顺序很重要。

她自己也是这么做的，即便带着几百人规模的团队，她仍然会自己写一点代码，自己用团队做出来的产品处理日常工作，比如报销出差费用。她说这不是为了证明自己还能写代码，而是为了保持对产品的真实体感，不让自己变成只看仪表盘和PPT的管理者。她提到一个细节，卖二手MacBook的时候在Facebook Marketplace上差点被骗，这种第一手的踩坑经历，比任何数据报表都更能告诉你产品哪里出了问题。

我觉得这是一种很朴素、但极容易被忽略的纪律。职位越高，离产品的真实使用场景往往越远，听到的反馈也越容易被层层过滤和包装。Fiona讲的这个习惯，本质上是逼着自己始终站在用户的真实体验里，而不是活在汇报材料构建出来的那个版本的现实里。这一点不管是不是在做软件，放到任何管理岗位上都成立。

留意latent demand，别人用产品的方式，常常超出你的设计

Fiona讲了一个我特别喜欢的例子。她身边有朋友开餐厅，生活很辛苦，经常坐在吧台前一堆账单算到很晚。她自己用Cowork处理出差报销的时候，发现这个工具对处理票据和表格特别擅长，于是想，如果这对我这么有用，对这些小生意主肯定也很有用。她帮朋友们上手之后，发现大家用的方式完全超出她的预期，有个开餐厅的朋友直接让Claude去比较同地区同类菜系的定价水平，得到的结果像一份市场分析报告。

这就是latent demand，也就是潜在需求，指的是用户已经在用某个产品做一些你没设计过、但其实很有价值的事情，只是你没注意到。Fiona说团队一直会留意这种信号，Cowork后来专门为小企业做了一个功能打包，就是从这些观察里长出来的。她总结的方法论是，当你看到有人为了让某个东西work而拼命想办法绕弯路，这时候就值得问一句，能不能把这条弯路直接铺成一条直路。

这个观察方式我觉得特别值得借鉴。很多产品决策依赖的是用户调研和需求文档，但真正有价值的信号，往往藏在用户自己都没意识到要主动反馈的那些边缘行为里。要捕捉到这些信号，前提是你自己也在真实地使用产品，或者真的花时间去看身边的人怎么用，而不是坐在办公室里猜。

Context switching，一个还没人解决的新问题

播客接近结尾的时候，Fiona被问到现在还有哪些问题是团队没想明白的。她提到一个我觉得特别值得展开聊的点，因为routines和异步工作变得普遍，大家同时盯着的事情变多了，context switching，也就是注意力在不同任务之间切换的负担，正在变得越来越重。她说自己也会同时启动好几个agent去处理不同任务，结果发现自己反而需要专门留出一段时间，去消化所有这些异步任务跑出来的结果。

她坦白说这个问题自己也还没想清楚怎么解决。听到这里我反而松了一口气，因为这说明AI带来的不全是单方面的解放，它解决了一类问题，同时制造了一类新问题。以前的瓶颈是产出速度，现在产出速度不再是瓶颈了，瓶颈变成了人的注意力带宽够不够撑得起这么多并行的进展。

我自己最近写东西、做内容的过程中也有类似的感受。借助工具之后，可以同时推进的事情变多了，但脑子里要同时装着的线头也变多了。这让我觉得，接下来真正值钱的能力，可能不是怎么用好某个具体工具，而是怎么设计自己的工作节奏，让自己不被这么多并行的进展压垮。这是一个新问题，Fiona没有答案，我自己也没有，但至少现在知道这是一个值得认真对待的问题，而不是简单归结为不够自律或者工具用得不够熟练。