中层技术经理要么重新学技术，要么考虑退休：前 Stripe 工程高管警告，未来三年工程管理将彻底变样

AI 编程加速工程管理范式重构，传统中层技术经理面临能力贬值风险。Will Larson 以自身从 250 人团队转向 25 人团队的职业选择，印证工程管理角色正向小规模、高技术深度方向演进。

工程管理价值正从“协调规模”转向“技术判断力与系统权衡能力”；AI 降低执行层管理需求，但放大架构决策与跨职能对齐的难度；资深工程师与技术主管的职责边界正在实质性融合。

适合中层技术经理、CTO、技术负责人阅读

如果你是一名中层技术经理，过去十几年积累的管理经验，可能正在迅速贬值。

曾在 Stripe、Uber 担任工程管理职务，后来出任 Carta、Calm CTO 的 Will Larson，最近给同行们提出了一个相当不客气的建议： 要么退休，要么重新学习技能。 他甚至预测，未来三年，我们今天所熟悉的工程管理职业可能不复存在。

更有意思的是，Larson 已经用自己的职业选择践行了这一判断。他曾在 Carta 管理约 250 人的工程组织，后来却主动选择加入规模更小的 Imprint，负责约 25 人的技术团队。从管理数百人到管理几十人，在传统技术高管的职业晋升路径上，这看起来像是一次倒退。

为什么一位曾经管理数百名工程师的技术高管，会认为自己熟悉的职业道路正在失效？

在最新一期 The Pragmatic Engineer 播客中，Larson 结合自己在硅谷多家科技公司的经历，重新审视了工程经理、资深工程师和 CTO 的职责，并提出了一个颇具冲击力的问题： 那些曾经帮助工程经理晋升的能力，为什么今天反而可能成为他们的职业负担？ AI 编程的兴起，正在让这场变化进一步加速。

太长不看版

Q：AI 时代，中层技术经理还有前途吗？

A： 要么重新深入技术一线，要么考虑退休。未来三年，传统工程管理的那套能力可能不再被市场需要。

Q：为什么过去被认为是职业陷阱的 TLM（Tech Lead Manager，技术负责人兼经理），现在反而成了抢手人才？

A： 企业需要既懂管理、又能亲自写代码的人。最理想的工程经理，是有能力处理复杂管理事务，却更愿意把时间花在软件开发上的人。

Q：AI 都开始写代码、做 Code Review 了，软件工程师还剩下什么价值？

A： 软件实现的成本正在快速下降，但理解业务、判断该做什么、处理复杂约束并验证结果，依然需要工程师。

Q：为什么给一个进度落后的项目增加 15 名工程师，反而可能让事情更糟？

A： 更多人意味着更多沟通和协调成本。真正高效的团队需要长期稳定、清晰的责任边界，而不是遇到问题就不断往里面塞人。

Q：一名优秀的 CTO，究竟应该是技术专家还是管理专家？

A： 两者都必须是。既要懂技术、产品和软件交付，也要懂组织运作、激励机制和管理流程。只擅长其中一方面，都很难成为优秀的高管。

Q：为什么 AI 能迅速复制 Slack 的界面，却很难复制 Slack 的产品能力？

A： 真正难以复制的是长期积累的领域知识、产品决策和团队协作经验。而要让这些积累转化为新产品，还需要有人敢于打破规则、推动不受欢迎的决策。

Q：AI 可以帮人高效写作，为什么你却拒绝用它大量生产文章？

A： 我花了近 20 年建立自己的写作声誉，为什么要用 AI 垃圾内容毁掉它？如果没有值得表达的观点，我宁愿不写。一两篇真正有影响力的文章，远比几百篇没人看的内容更有价值。

从技术博客进入 Yahoo：一场服务器“黑市”带来的管理启蒙

Gergely Orosz：你最早是怎么对计算机产生兴趣的？小时候就喜欢编程吗？

Will Larson： 我大概五岁时，家里就有一台早期的 Macintosh 电脑。那时候我最喜欢用一个叫 Kid Pix 的儿童绘图程序，可以画正方形、圆形和各种简单图案。

当时几乎没有互联网，遇到问题也没什么地方可以查，只能自己不断尝试，直到弄明白怎么操作。某种程度上，这和后来写软件的过程很像：不断动手尝试，直到找到解决办法。

不过，我小时候其实没有真正写过多少程序。到了高中，我开始接触 IRC（互联网中继聊天）和 MUD（多人文字冒险游戏）。这些工具支持触发器、正则表达式和简单脚本，我就是在那个时候学会使用正则表达式的。但真正开始编写软件，已经是上大学之后了。

Gergely Orosz：你在大学里为什么选择计算机科学？当时就打算成为职业程序员吗？

Will Larson： 刚进大学时，我其实不知道自己想学什么。物理、英语、经济学都考虑过。我父亲是经济学教授，所以经济学也算是一个很自然的选择。

我就读的是肯塔基州一所规模很小的私立大学。学校要求学生修读一些通识课程，其中包括计算机科学导论。我上完之后发现自己很喜欢，于是逐渐转向计算机科学。

我们学校的计算机科学专业非常小。我毕业那年，整个专业可能只有 13 名学生，而同届毕业生只有 4 人。

这和滑铁卢大学、MIT、斯坦福这样的学校很不一样。在那些学校，学生通常有非常明确的软件工程职业路径。比如滑铁卢大学有成熟的 Co-op（带薪实习）体系，学生之间还会交流面试经验、练习面试题。只要能够顺利完成学业，往往就有一条相对清晰的道路进入科技行业。但在我们学校，根本没有这样的路径。

我记得上一届有个非常优秀的毕业生，最后去了肯塔基州列克星敦一家开发赛马博彩软件的公司，那里可能只有不到五名工程师。这已经是他当时能够找到的不错的机会。所以，我毕业时也不知道自己究竟会去哪里。

Gergely Orosz：那你后来是怎么进入硅谷的？

Will Larson： 我 2007 年大学毕业，之后参加了日本的 JET 项目，在岐阜县一个非常偏远的地方教了一年英语。

那段经历让我更加确定，自己不会长期当英语老师。我的合同只有一年，我也完全没打算续约。于是，我开始大量写技术文章，尝试寻找进入软件行业的机会。

2009 年初左右，我开始为 Yahoo 工作。有意思的是，最初我并没有直接进入硅谷，而是在美国东海岸远程担任 Yahoo 的合同工。这份工作实际上是我写博客写出来的。

当时 Yahoo 推出了一个叫 Yahoo BOSS（Build Your Own Search Service）的产品，允许开发者基于 Yahoo 的搜索能力构建自己的服务。我围绕它写了三四篇技术教程，包括如何使用 Python、Django 集成 Yahoo BOSS，还做了一个相关的 Django 搜索库。

那个产品当时似乎没有获得太多开发者关注，所以 Yahoo 团队看到有人主动写教程，就对我产生了兴趣。最终，这些文章帮我获得了一份合同工作。

当时正值金融危机之后，Yahoo 一直在裁员，基本冻结了正式员工招聘，但还能雇用少量合同工。我就是在这样的背景下加入公司的。按照当时的规定，合同工工作满一年后，要么转为正式员工，要么结束雇佣关系。后来，我也因此获得了转正的机会。

Gergely Orosz：2009 年左右的 Yahoo 已经开始被 Google 超越，但它仍然是一家很有技术实力的公司。你在那里经历了什么？

Will Larson： 我一直觉得 Yahoo 是一家非常有意思的公司。如果你在 2007 年、2008 年进入软件行业，会发现很多开源软件已经让开发工作变得相对容易。但 Yahoo 成立得更早，早在这些开源基础设施成熟之前，就需要解决大规模互联网服务的各种问题。所以，Yahoo 内部几乎所有东西都是自己造的。

比如，运行 Web 服务器用的是 YApache，也就是 Yahoo 自己维护的 Apache 分支。编程语言有 YPHP，是他们自己的 PHP 分支。前端有 YUI（Yahoo User Interface Library）。甚至软件安装和依赖管理也有一套内部工具，叫 Yinst。它是用 Perl 编写的脚本，用来处理软件安装过程中的依赖关系，有点类似 Ubuntu 上的 APT。他们还有一套类似后来 Kafka 的系统，我记得可能叫 YREPL。它通过日志复制来管理状态，不完全依赖数据库本身的复制机制。

对一个刚进入行业的工程师来说，这是一段非常特别的经历。你会发现，这家公司为了支撑自己的业务，几乎从头构建了整套技术基础设施。

我还记得一个特别有意思的故事。Yahoo 联合创始人 David Filo 当时会亲自审批公司分配的每一台服务器。这套制度最初的目的是强化责任意识。如果你想申请更多服务器，就必须证明自己确实需要这些资源。但实际结果却是，公司内部出现了一个服务器“黑市”。

我们团队有位工程师，手里掌握着大约 30 台服务器，都是之前一个被取消的项目留下来的。他一直没有把这些服务器归还公司。如果你的项目申请不到新服务器，就可以去找他借。当然，这不是正常的资源分配，而是靠人情、交换帮忙或者欠个人情来完成。某种程度上，他就像在私下出租这些服务器。

结果，Yahoo 内部积累了大量老旧服务器。这些机器的能耗效率很低，但大家都不愿意归还，因为一旦交出去，下次需要资源时可能就申请不到了。为了让自己的项目顺利上线，你必须先找到一个愿意借服务器给你的人。

这让我觉得非常有意思。 一项原本为了提高资源使用效率的管理制度，最后竟然制造了完全相反的激励，让所有人都倾向于囤积资源。

Gergely Orosz：这应该也是你后来成为工程管理者时，一直记得的教训吧？

Will Larson： 没错，这件事给了我很深的启发。我有时也很好奇，David Filo 是否知道公司内部真的存在这样一个服务器黑市。我猜他可能知道，但即便如此，这项自上而下的管理规定也没有改变。

Digg 灾难性重写内幕：上线当天开香槟庆祝，网站却瘫痪了

Gergely Orosz：离开 Yahoo 后，你去了 Digg。当时它还是一家非常知名的互联网公司，你为什么决定加入？

Will Larson： 当年的 Digg 是一个非常重要的网站，一度跻身全球访问量前十。它最初依靠人工筛选内容，决定哪些文章能够登上首页，后来逐渐发展成一个动态的内容社区。

这种模式有自己的问题。因为首页流量非常有价值，一些用户会通过 IRC 频道交换利益，想办法让特定内容登上首页。甚至有人以此为生，靠出售首页曝光机会赚钱。

后来我们在 Digg v4 中修改了推荐算法，切断了这类操作空间。结果，有人威胁要杀了我，因为新算法毁掉了他们的生计。这不是夸张，他们真的发出了人身威胁。

不过，Digg 当时面临的最大问题并不是社区内部的利益纠葛，而是整个互联网的流量分配方式正在发生变化。

Gergely Orosz：我记得 Digg 当时非常受欢迎，但后来进行了一次大规模重写，也就是 Digg v4，结果引发了灾难。从外部看，这似乎是一家发展不错的公司突然把自己搞垮了。内部究竟发生了什么？

Will Larson： 我是在 Digg v4 上线前三到六个月加入公司的。入职前的那个星期五，CEO 刚刚被撤换，创始人 Kevin Rose 重新回来担任 CEO。公司随后给 v4 的发布设定了一个非常紧迫的期限。

从外部看，Digg 似乎还在正常发展，但内部情况已经相当糟糕。

当时 Facebook 正在崛起，Digg 的用户流量开始受到冲击。与此同时，Google 搜索算法的调整也在改变流量分配方式。Digg 大约 60%—70% 的流量来自搜索引擎，主要进入网站的永久链接页面。这些页面收录了用户分享的文章、原始链接和相关评论，有时在 Google 搜索结果中的排名甚至高于原始内容。

这既是 Digg 的重要流量来源，也是广告收入的核心来源。一旦搜索流量下降，公司的财务状况就会迅速恶化。

我记得公司曾经有过一个月的盈利，但随后搜索算法发生变化，流量开始持续下滑。我们很清楚，如果不采取行动，公司可能很快就无法继续经营。

当时 Digg 大约有 110—120 名员工。放在今天，这不算什么特别大的规模，但在 2010 年，创业公司一轮融资可能只有 100 万到 300 万美元，养活一百多人已经是很大的开支。我们的现金正在迅速耗尽。所以，公司决定进行一次彻底重写，试图扭转局面。

Gergely Orosz：那次上线到底出了什么问题？是技术没准备好，还是社区用户无法接受变化？

Will Larson： 两方面都有，但技术上的准备确实非常不足。

Digg v3.5 主要使用 PHP 和分片 MySQL，虽然架构比较复杂，但至少能够正常工作。到了 v4，我们做了一个非常激进的决定：用 Cassandra 替换原来的分片 MySQL 系统。

当时业内甚至有个玩笑，说 Cassandra 是 Facebook 放出来摧毁竞争对手的“特洛伊木马”，因为谁用了 Cassandra，谁就可能陷入麻烦。对 Digg 来说，这个玩笑几乎成了现实。

上线前两天，我和另一名工程师 Rich 突然被叫过去。原本负责 Cassandra 压力测试的团队根本没有完成测试，现在要求我们两个人在两天内把它做完。我们只能临时安装 JMeter，边学怎么使用，边尝试进行压力测试。

测试过程中，我发现 Cassandra 的读写存在严重问题。我去找负责 Cassandra 项目的 Chris，告诉他系统无法正常读取数据。他说这不可能。我又说写入也有问题，他还是说不可能。最后我只能把问题说得更明确：如果正在写入 Cassandra，我就无法读取；如果正在读取，我就无法写入。这一次，他承认了。可问题是，我们还有两天就要上线了。最终，这个问题没有解决，系统还是按计划发布了。

Gergely Orosz：明知道系统有这么严重的问题，还是上线了？当天是什么情况？

Will Larson： 那可能是我整个职业生涯中最不可思议的一天。公司决定为 Digg v4 举办一场盛大的上线派对。办公室里到处都是穿着礼服的餐饮服务人员，端着寿司和香槟。大家准备庆祝新版本发布。与此同时，工程师们坐在办公室中央的一张大桌子旁，拼命尝试让系统运行起来。

更糟糕的是，我们没有足够的硬件同时运行新旧两套系统。当时 Digg 使用的是自己购买、部署在托管机房里的服务器，无法像今天使用云服务一样随时扩容。为了部署新系统，我们必须一台接一台地清空旧服务器，重新安装软件。这意味着我们根本没有回滚的条件。

公司已经快没钱了，没有预算购买足够的服务器，却还有预算举办上线派对。

结果，新系统根本没能正常启动。网站大约有 24 小时只能显示维护页面。而在办公室里，香槟还在端来端去，楼上有人在接受按摩，还有人在打乒乓球。工程师们却在拼命抢救一个正在崩溃的网站。整个场景荒诞得像魔幻现实主义。

Gergely Orosz：这确实不是一般人能想象到的上线场景。后来你们是怎么把网站救回来的？

Will Larson： 我们最终让网站勉强运行起来了，但问题远没有结束。随着故障持续，越来越多的人不再参与抢修。最后大概只剩下六个人，继续努力维持网站运行。

最初两天，我和 Rich 从零开始，在 Redis 之上写了一套缓存系统。它让网站至少能够连续运行几个小时。但系统仍然存在严重的内存泄漏。为了维持服务，我们不得不每隔一两个小时就滚动重启所有进程。我花了大约四周时间，才最终找到核心问题。

当时我们开发了一套供第三方调用的 API 服务，使用 Python 编写。负责开发的工程师对 Python 并不十分熟悉。这套服务还会调用另一个 Python 服务，再访问 Cassandra。问题出在 Python 函数的默认参数上。如果把一个可变对象，比如列表，设置为函数的默认参数，那么这个对象可能在多次函数调用之间被重复使用。

我们的代码恰好犯了这个错误。每次 API 接收到用户 ID，就会把它追加到默认列表里，但这个列表不会随着函数调用结束而清空。结果，随着请求不断增加，列表里积累的用户 ID 越来越多。原本只应该返回本次请求对应的用户对象，最后却会把此前请求过的用户对象也带出来。

这不仅造成内存持续增长，还让中间的缓存服务不断崩溃，最终进一步拖垮 Cassandra。这个问题花了我大约四周才定位出来，但找到之后，修复本身非常简单。

Gergely Orosz：所以你们最终修好了系统，但 Digg 还是没能挽回局面？

Will Larson： 是的。从技术角度看，我们最终成功了，系统恢复了运行，我对此仍然感到自豪。但对于一个以网站访问和用户社区为核心的公司来说，主要服务连续一个月都难以正常使用，造成的损失已经无法挽回。后来，新 CEO 上任，接下来一年里，公司基本完成了裁员。

不过，回头看，我也不能确定当时彻底重写就是一个错误决定。如果我们什么都不做，继续运行旧网站，Digg 可能同样会倒下。公司原本就面临严重的流量下滑和资金压力。所以，我不知道还有没有更好的选择。只是当时经历这一切，确实让我非常沮丧。

Gergely Orosz：经历 Digg 之后，你是怎么走上工程管理道路的？我们后来都在 Uber 工作过，虽然没有直接共事。

Will Larson： Digg 最后经历了几次不同形式的资产出售。它的一部分专利被收购，其中包括信息流原生广告相关的专利；Digg.com 网站品牌被另一家公司收购；工程团队则被 SocialCode 收购。SocialCode 当时隶属于拥有《华盛顿邮报》等业务的公司，主要从事 Facebook 广告相关业务。我跟随团队去了 SocialCode，又在那里工作了几年。

离开时，我开始认真考虑如何进入更高级别的工程管理岗位。当时我大概管理着一支 12 人的工程团队，但想应聘大型公司的高级管理岗位时，就遇到了一个很现实的问题：没有管理过大规模团队，就很难获得管理大规模团队的机会。

如果去一家只有五名工程师的小型创业公司，即使成为工程负责人，也很难积累大型组织所需要的管理经验。所以我当时的想法是，如果想管理更大的团队，就必须加入一家正在高速增长的公司。我开始寻找这样的机会，最后注意到了 Uber。那是 2014 年初，Uber 的高速增长才刚刚开始。

加入高速扩张的 Uber：两年内将团队从 6 人扩张到 70 人

Gergely Orosz：2014 年的 Uber 还处于发展早期，当时只有身在旧金山的人才知道它增长得有多快。你是怎么发现这个机会的？

Will Larson： 没错。2014 年，如果你不在旧金山，可能根本不知道 Uber 发展得有多好。直到 2015 年，相关消息才开始广泛传播，2016 年它已经成为全球关注的公司。

我之所以注意到 Uber，是因为之前在 Digg 共事的一名基础设施工程师 Jeremy Grosser 加入了那里。

这里还有一段有意思的技术传承。Digg 当年开发过不少内部工具，其中一个叫 Clusto，用来管理基础设施的状态信息，本质上有点像键值存储系统。它的功能与后来 HashiCorp 的 Consul 有些相似，但出现得早得多，大概在 2008 年或 2009 年。

据我所知，真正使用过 Clusto 的公司可能只有 Digg、Uber 和 Second Life 背后的公司等极少数几家。Jeremy 是 Uber 最早的一批基础设施工程师之一，他把 Digg 的不少技术栈也带了过去。当时他的团队正在招聘，我就这样发现了机会。

Gergely Orosz：你之前主要做什么技术工作？加入 Uber 后又负责什么？

Will Larson： 我一直是个比较典型的全栈通才型工程师。最初在 Yahoo，我被招聘去做前端开发，但坦白说，我也不确定自己当时是否真的具备足够的前端能力。后来在 Digg，我既做前端，也做 Cassandra、后端开发，基本上什么都干。

Uber 招聘我去管理一个 SRE 团队。但严格来说，那并不是真正意义上的 SRE 团队，只是一个被称作 SRE 的基础设施团队。有意思的是，接下这份工作时，我对 SRE 其实也没有特别系统的认识。入职前一周，我还在临时读相关书籍，想弄清楚这个岗位究竟应该做什么。我记得当时可能读的是一本 DevOps 相关的书，也可能是《凤凰项目》（The Phoenix Project），具体已经记不清了。

Gergely Orosz：当时你管理的团队有多大？承担哪些职责？

Will Larson： 我刚加入 Uber 时，公司大约有 2000 名员工，其中工程师约 200 人。我负责的团队只有大约 6 个人，但职责范围非常广。数据库、Kafka、服务器运行管理、服务部署与资源配置，几乎所有基础设施都归我们负责。

当然，也有一些例外。比如，公司有一支两人的开发者体验团队，还有专门的技术运维团队，负责服务器上架和物理安装。但服务器部署完成之后，后续的管理基本就是我们的工作了。所以，虽然只有六个人，我们却要支撑整个 Uber 的基础设施。这是一段非常特别的经历。

Gergely Orosz：从 Uber 到后来的 Stripe、Carta，你的管理职责是怎么一步步扩大的？在 Uber 的团队最终发展到了什么规模？

Will Larson： 我刚加入时，团队大约只有五六个人。两年后我离开 Uber 时，这个团队已经扩大到了 70 人，而且这些增长全部来自外部招聘。

当时 Uber 最惊人的地方，就是工程师人数大约每六个月翻一番。在这种增长速度下，你根本没办法简单地从其他团队调人。因为所有团队都在快速扩张，大家都缺人，工作负荷也都非常重。所以，我们只能不断从外部招聘新工程师。

我真正学会如何招聘，就是在 Uber 的这段经历中。加入 Uber 之前，我其实完全不知道该怎么招聘。但 Uber 当时招人的速度实在太快了，我只能在实践中不断学习。

我记得有个从 Eventbrite 过来的工程师，我们下午四点给他发了 Offer，他下周一早上八点就来上班了。后来我管理了他大约一年半。还有一个更离谱的故事。有个人已经参加过四次 Uber 面试，而且四次都被拒绝了。后来我竟然又看到他来参加第五次面试。我当时就说，不能再这样浪费人家的时间了，已经面试过四次了。

没想到，第五次面试的团队真的给了他 Offer。他接受了，也正式入职了。但他只工作了六个小时就辞职了，因为他同时拿到了 Twitter 的 Offer，而 Twitter 的办公室就在附近，可能只隔了一个街区。所以，这个人花在 Uber 面试上的时间，竟然比他正式在 Uber 工作的时间还长。

类似的故事还有很多。那两年里，我们的团队从六个人扩张到七十人，负责的业务范围也不断扩大。整个公司都处于一种近乎疯狂的增长状态。

我记得当时每到周五，我们都要手动调整服务器上的软件部署，努力确保系统能够撑过晚高峰。因为周五下班时间通常是 Uber 一周中最繁忙的时段。周六的总订单量可能更高，但分布在更长的时间里，而周五大量用户会集中在下班时段叫车。

现在有些公司的发展状态会让我想起当年的 Uber。那确实是一段非常疯狂的经历。

Gergely Orosz：后来你去了 Stripe，并在那里工作了大约四年。为什么又决定离开，去担任 CTO？

Will Larson： 我在 Stripe 工作了大约四年，从 2016 年到 2020 年初。我加入时，公司大约有 500 名员工。离开时，已经增长到 1500—2000 人左右。在我任职期间，Stripe 的员工规模每年大约增长 70%。这个速度已经相当快了，但比起 Uber 每六个月翻一番的增长速度，还是温和得多。当然，Uber 后来收缩得也远比 Stripe 激进，这某种程度上也是超高速扩张的自然结果。

到了那个阶段，我开始认真考虑自己的下一步。

一方面，我担心自己的大部分积蓄都集中在同一家尚未上市的公司上。我当时甚至觉得 Stripe 可能永远不会上市，而至少到现在，这个判断还没有被推翻。所以，离开也有分散个人财务风险的考虑。另一方面，我真的很想知道，完整地领导一家公司的工程组织究竟是什么感觉。

在 Stripe，我已经非常接近公司的最高管理层。第一年我向 Jeff Winter 汇报，后来一直向 David Singleton 汇报，直到 2020 年初离职。David 最初加入 Stripe 时担任工程负责人，之后升任 CTO。也就是说，我距离 CTO 的位置只有一步之遥。

但我一直在想：如果真正坐到那个位置上，我能不能把某些事情做得更好？我觉得自己应该去尝试一下。后来事实证明，这确实是一段很有教育意义的经历。

Gergely Orosz：所以你后来先后担任了三家公司的 CTO？

Will Larson： 是的。我先在 Calm 担任了大约三年半 CTO，之后在 Carta 工作了两年，再后来加入了 Imprint。到现在，我在 Imprint 已经工作了一年到一年半左右。

成为工程经理后，就不应该再做技术决策了？

Gergely Orosz：你已经在三家公司担任过 CTO，我很想问一个最基本的问题：CTO 究竟是做什么的？我想很多工程师都曾经向往过这个职位。因为在我们的想象中，CTO 既承担管理职责，又能保持技术深度，离实际工程工作并不遥远。你自己也写过关于工程高管职业发展的书。经历了这么多公司之后，你现在如何理解 CTO 的职责？尤其是在 AI 出现之后，你觉得这个角色发生了什么变化？

Will Larson： 我觉得，2010 年代担任工程经理最糟糕的一件事，就是当你刚进入工程管理岗位时，通常学到的第一条规则是：“从现在开始，你再也不应该做任何技术决策了。”我当年真的就是被这样告知的。当时整个工程管理领域都推崇这种理念： 成为管理者，就意味着要学会放手，把技术决策交给工程师。 但今天，这套理念已经不再适用了。