# AI时代软件行业发展趋势与开发者成长路径分析报告 > **基于InfoQ圆桌对话：黄东旭、李令辉、马驰三位技术专家的深度洞察** ## 📋 核心观点概览 ### 🎯 三位嘉宾的核心立场 * **黄东旭**（PingCAP CTO）：古典程序员流派，注重经典学习与品味培养 * **李令辉**（ClapDB创始人）：实用主义程序员，强调解决实际问题 * **马驰**（北欧FinTech工程师）：国际化视野，关注工具效率与生活质量 ## 🔍 主要讨论议题分析 ### 1. 🇨🇳 中国技术软件国际竞争力问题 #### 核心观点 * **黄东旭**：中国技术软件厂商具备竞争力，但缺乏品牌认知和社区建设经验 * **李令辉**：问题根源在于教育体系，过度注重"做题"而非"出题"能力 #### 关键洞察 * 中国顶级程序员技术实力不逊色于美国同行 * 缺乏定义新赛道和塑造行业标准的能力 * 国际社区参与方式方法仍在摸索阶段 ### 2. 🎓 程序员能力提升路径 #### 学习建议对比 | 嘉宾 | 学习方式 | 核心理念 | | --- | ----- | ------------- | | 黄东旭 | 经典学习法 | 从历史源头学习，培养品味 | | 李令辉 | 实用驱动法 | 只为付费项目学习，注重效率 | | 马驰 | 国际化视野 | 接触最前沿技术社区 | #### 共同建议 * **避免信息过载**：不要沉迷于微信公众号等浅层内容 * **注重实践**：理论学习必须结合实际编程练习 * **培养品味**：学会做技术选择时的判断标准 ### 3. 🚨 行业现状与挑战 #### 李令辉的"激进"建议 > "我的第一个建议是别当程序员了！" **理由分析**： * 程序员可能是"末代职业" * AI工具正在改变软件开发模式 * 传统CRUD架构面临淘汰 #### 技术趋势判断 * **云原生**：存算分离将带来架构革命 * **AI工具**：代码生成工具存在局限性，无法替代优秀工程师 * **基础技能**：万变不离其宗，基本功仍然重要 ## 💡 关键洞察与建议 ### 🎯 对年轻开发者的建议 #### 1. 学习策略 * **回归经典**：学习Unix、Plan9等经典系统设计 * **国际视野**：参与Hacker News等国际技术社区 * **英语能力**：作为全球化交流的必要工具 #### 2. 职业发展 * **兴趣驱动**：做自己感兴趣的事情，避免功利心 * **问题导向**：专注于解决实际问题，而非重复造轮子 * **去魅思维**：挑战权威，培养独立思考能力 #### 3. 技术选择 * **避免过时技术**：不再深入研究传统企业Java架构 * **关注新兴技术**：Rust、云原生、AI等前沿技术 * **保持基础**：系统性能、分布式原理等核心概念 ### 🌍 国际化发展建议 #### 文化差异观察 * **美国程序员**：更注重产品设计和宏观规划 * **中国程序员**：编码速度快，但容易返工 * **北欧程序员**：工具使用效率高，生活质量更好 #### 提升路径 * **思维方式转变**：从具体功能转向整体架构思考 * **产品意识培养**：学习优秀的产品设计方法论 * **工具效率提升**：减少无用功，提高信噪比 ## 📊 行业趋势预测 ### 🔮 技术发展方向 1. **云原生架构**：存算分离将成为主流 2. **AI辅助开发**：工具化程度提升，但无法完全替代 3. **基础软件重要性**：底层技术价值凸显 ### ⚠️ 风险警示 * **技术过时风险**：传统架构经验可能成为束缚 * **工具依赖风险**：过度依赖代码生成工具可能带来质量问题 * **竞争加剧**：全球化竞争要求更高标准 ## 🎯 总结与建议 ### 核心观点 1. **中国技术软件具备竞争力**，但需要提升品牌建设和标准定义能力 2. **程序员需要转变学习方式**，从浅层信息转向经典学习 3. **国际化视野至关重要**，英语能力和国际社区参与是必要条件 4. **兴趣驱动比功利心更重要**，做自己喜欢的事情才能持续成长 ### 行动建议 * **立即行动**：开始学习英语，参与国际技术社区 * **长期规划**：培养产品思维和抽象能力 * **持续学习**：关注前沿技术，但不要忽视基础知识 * **保持初心**：在快速变化的时代保持对技术的热爱 *** *本报告基于InfoQ圆桌对话内容整理，旨在为开发者提供职业发展参考。* ## 🤖 报告生成信息 **AI模型**：Claude 3.5 Sonnet\ **生成时间**：2025年1月28日\ **分析工具**：PromptX系统辅助分析 *** ## 📝 原始对话摘录 **底层与应用层的"知名度"差别** 比如把基础软件公司和小红书、TikTok、抖音去对比，这就好比不能拿美国的 ARM 和苹果对比。ARM 虽然是更基础的软件公司，但它的市值跟苹果没法比，苹果每天跌掉的市值可能都比 ARM 高。这说明越靠近消费市场、越靠近最终用户的产品，声浪越大、市值越高、收入越高。但这并不意味着底层的技术提供商和供应商不重要。苹果公司几乎全世界人都知道，但除了从业者，知道 ARM 的人并不多。 **"老汤换新料"** 我曾在社交媒体上吐槽，中国之前没有所谓的科技公司，只是利用科技做传统行业的公司，如利用科技做电商、媒体、聊天等。在没有科技时，用传统方式不也能进行吗？所以科技是造福其他行业的，但我们没有真正意义上的自己的科技行业。严格来说，2010 年以后，随着 GDP 增长，中国大公司有钱投入，才有了真正的计算科技公司，像华为，早期也是通信领域的设备公司。 **制度和"出卷子"** 关于影响力的问题，我们不太擅长掌握规范、话语权，我觉得责任主要在教育。中国教育让学生都在做题，做题的人怎么去研发新试卷呢？Oracle 数据库诞生后，创造了数据库行业，这张卷子是谁出的？亚马逊做云之前连云都没有，这张卷子又是谁给的？如果把所有优秀的人才在 20 岁前都困在屋里做卷子，以此筛选人才，筛选出来的人将来却要开创，这不是开玩笑吗？这就相当于培养赛跑运动员去游泳，通过跑步选拔了你，但家里却没有水。现在你长大了要去游泳，这本来就是缘木求鱼。我觉得从业者要思考这个问题，更关键的是整个行业的上下游，上游是生产人才的学校，下游是招聘方和消费者，我们是中间环节，学校培养人才，我们生产商品再卖出去，形成闭环。美国大学靠校友捐款培养人才。 **概念赛道定义 与 技术本身 相关却不完全对等** 我完全认同这个结论，虽然可能不是全部原因，但至少这是一个从宏观上看很重要的能力缺陷。就拿 Databricks 来说，大家都知道它最近融了一大笔钱。回顾其历史，在大概三年前甚至更早一点的时候，Databricks 推出了一款新的云端计算引擎叫 Photon，这个引擎并未开源。当时它原有的产品线还是基于 Spark 的批量处理云平台。但有了 Photon 这个新东西后，Databricks 做的第一件事并不是急着去卖，而是先定义了一个市场，叫做 Delta Lake，宣称自己的产品就是 Delta Lake，说以前的数据仓库已经过时了，它的 Delta Lake 最厉害。这么一宣传，赛道里就成了它一家独大，用户一试，确实不错。从技术层面剖析，它用的还是那些老技术，如存算分离、存储引擎优化等。我觉得中国在性能、数据量等方面很擅长"内卷"，但在像 Databricks 这样定义赛道方面，确实与美国差距较大。 **数学题与数学家** 李令辉：首先，我觉得这个问题还是得让教育来背锅，但咱们就不深入展开了，大家只要记住是教育的问题就好。我们太喜欢做题了，我有个朋友曾跟我说他孩子数学考试分数不错，但数学本质上不是算数比赛，而是抽象概念的比赛。真正的数学家一辈子没算过几个数，他们主要是推导公式。 **规模人数的反噬？ —— 抽象思维** 其次，从我个人的创业感受以及在大公司工作的经历来看，我发现创业过程中我的抽象思维不断提高，这是一个被动的过程。核心原因是我手里的研发资源变少了，抽象能力就提高了。当我手下有 200 个程序员时，我就不想费劲去抽象，直接把子功能、子模块拆分给大家做就行。但当我发现手里只有两个人时，我就会想着要么写个代码生成器，要么写个编译器。所以我觉得很多时候创新是被逼出来的，我真的是这么觉得的。我自己创业时，公司研发人员很少，对外却宣称有百万大军，其实也就不到 10 个人。我觉得我们的代码其实就是个代码生成器，先生成一堆代码，再生成一堆代码，原因并非后来发现这样做有很多好处，起初完全是因为人手不够。如果我像华为那样有上万开发人员，我干嘛费劲写代码生成器呢，直接给每人分配一个 SQL 去优化就行。 **人力成本低的陷阱：稳定但很难又挑战和创造** 我觉得美国人这么做也有一个原因是他们人力成本太高。这件事很可能在我们的人均 GDP 越来越高时发生变化，当大家发现与其雇 10 个人，不如让一个人闲下来，冷静下来，抽象一下更划算时，情况就会改变。有个很好的比喻，他说只要看中国什么时候洗碗机普及了，就说明人均 GDP 上去了，因为总有人算账，觉得让老婆洗碗比用洗碗机便宜。只有当洗碗机比人工洗碗更划算时，我们才会更愿意使用机器。想想大公司里那些年薪五六十万、七八十万的程序员，他们在做一些非常细节、具体的小优化，比如一个页面分给三个人，这三个人写了 10 年，这是真的。有什么必要把这三个才华横溢的年轻人限制在一个页面上呢？还是因为页面优化和人力成本差不多，差不多 1000 个页面，就分配 500 个程序员，每人两个；或者两个人一个团队，分四个页面。我觉得核心还是行业从业者应该提高要求，让工作更有挑战性，有更多的事情可做，这是一种被动提高的方法，主动提高我觉得挺难的。 **非线性思考 —— 思考惰性：加入是最简单的动作** 黄东旭：我每年都会回头看团队的效率，特别关注这个指标，即多少人能干出多少事。对我们这样的公司来说，大部分成本是人力成本，而人力成本里绝大多数是程序员。所以一个优秀的程序员，他产生的影响一定比很多人要大。我在做事时，倾向于不轻易说"给你 10 个人去做"。因为一旦给团队说 10 个人去做，团队就不思考了。加人是最简单的动作。有时为了防止大家陷入思考惰性，我会故意提出一些看似疯狂的要求，比如让系统性能提升 100 倍，成本下降 1000 倍。如果目标只是让性能提升 10%，大家就不会去思考和创新，因为 10%的小修小补很容易实现。但如果目标是优化 1000 倍，虽然你自己心里得先有可行性验证，但不能直接告诉团队答案，因为思考过程也是达成共识的过程。总之，优秀的程序员通过自己的思考，产生的影响是非线性的，一定要用好这种能力。 **学习经典** 从刚才聊的宏观层面，如思考方式、抽象能力，单从程序员个人发展角度看，如何锻炼这些能力呢？我的经验是，程序员不要自己乱思考。世界上很多好东西已经发明出来了，比如 Unix 等，人家已经做出来了，背后的思考成果和过程都以博客、文章、访谈等形式存在。我的建议是，动手前先多看经典的东西，多思考，写代码并非关键动作。我会花很多时间看一些老东西，如 Unix、Plan9 等漂亮的设计，这个过程也是学习过程，思考人家为什么要这么做。 ## 摘录 —— 关于自我提升的建议 **- 尽量提高信噪比** **- 微信公众号避雷** 微信公众号上肯定无法让你看到真正的经典，那上面的内容大多很表面。因为这世界上所有不花努力、茶余饭后花 10 分钟就能获得的东西，一定不是好东西，也不会让你有实质性的收获。 ``` **索引，起点，而非真正的内容。** 同样适用于短视频等信息密度低的媒介。 零食也可以吃吃，别当主食。 ``` **- 经典，历史，追根溯源 —— 从设计思想，设计哲学开始，然后深入细节** 第一，要去找到经典，从历史入手，追溯到最根源、最接近经典源头的地方，看第一手资料。不一定非要看具体代码，我以前就犯过这个错误，初中、高中时对 Linux 很感兴趣，一上来就看源码，但感觉没什么用，当时虽然看起来很努力，最后却没什么收获，看过就忘了。反而是去看一些访谈，了解设计思想、作者背后设计系统的哲学，先理解这些，再深入细节，这才是看经典的好方式。 **- 实践和肌肉记忆** 第二，即使你理解了系统为何精妙、设计为何出色、经典为何是经典，也还不够，关键在于实践。实践部分其实更重要，就像成为钢琴家必须练琴一样。前面听音乐、了解好东西是在培养品位，不能只听低俗音乐，要听经典，培养审美。然后通过练习，让手形成肌肉记忆。我觉得知行合一，把这两者结合起来是比较好的。以前我和很多年轻人交流，他们说平时天天 996，没时间干别的。但我认为，现在大环境变差了，996 拿的钱也有限，不如趁这时候多提升自己，把心态放平，这也不耽误挣钱。 **- Taste 品味 ： 意味着放弃和取舍** 在我看来，什么是品味？我从 Linus Torvalds 的观点说起。虽然我不太喜欢他的品味，但他讲的有道理。\*\*在庞大的 Linux kernel 项目中，保持简洁的代码，不搞魔法，用基础的 C 语言而非高级语言，是完全正确的。\*\*这样能有效维持项目的简单直白和可维护性，也不易被黑客埋后门。但这换到其他项目未必适用。很多程序员讲品味时，会引用 Linus Torvalds 的观点，但 Linus Torvalds 也只是在 Linux kernel 中如此。所以，我认为所谓品味，你应该问自己：解决这个问题该用什么方法最优雅？这包括几方面考虑：一是你面临的脑力负担，需不需要了解全貌才能解决；二是你要承担多大风险，作为工程师，首先要考虑的是项目会不会因你的选择而失败；三是收益。**灵活且因地制宜** 不同项目的品味是不一样的，但核心是，如果你不能量化为什么做这个选择，那这个选择很可能是人云亦云。中国人其实很谦卑，我面试时喜欢问程序员都看什么技术文章和博客。如果他列举超过 3 个，我就不太想要；超过 10 个，我觉得这人肯定有问题。因为中文媒体没什么可读的，有那么多时间看中文媒体，不如去干别的。这也说明他品位差，看不出哪些是垃圾。更可怕的是，他很可能被这些垃圾影响。我最害怕的是，一些程序员在项目讨论中搬出大名词，却不知道这些人的真实水平。你放着权威的教材不看，去看中文博客，如果你要相信权威，就找最权威的。东旭读经典的做法是对的，因为经典被那么多人筛选过，你获得营养的概率远高于垃圾，时间不会白费，比订阅一些不靠谱的博客强多了。 黄东旭：我觉得品位这种事，最终体现在你做选择时。作为一名 CTO 或资深程序员，设计众多系统，每时每刻都在做决定，比如这个接口设计成什么样，或者这个地方要不要抽象成一个模块。\*\*品位就是在这些决定中的一种行为准则。\*\*你会觉得某个地方需要这么设计接口，虽然当下看不到收益，但相信未来你会感谢自己当初的决定。 **- 简洁的品味 KISS原则** 有意思的是，现在我回头去看 PingCAP 系统，至少是我参与决策的那些部分，发现大多数正确的决定在当时看起来都非常反直觉。如果当时按照那个环境下所谓的大 V 或主流设计方案去做，最后回头看你会庆幸自己没听那些微信公众号或主流人士的说法。尤其是当你的组织变大后，作为技术掌舵人或决策者，你做出反直觉的决定，就意味着底下的人会问为什么要这么做，眼前的利益明明应该这么做，为什么不做呢？所以我自己在做重大决定时，第一个倾向是**能不做就不做，能晚点做就晚点做**，保持系统的简洁，也就是所谓的品味。作为古典程序员流派，我更倾向于以简单为美。 ## 摘录 —— 关于解决问题 的 生态和"超越" **- 考核制度催生重复，代码层面的复用可以延伸到工具层面的复用，人均Raft确实没必要** 我觉得程序员这个职业和传统职业最大的不同在于，我们不需要做前人做过的工作。传统工作比如做面，你做不到别人做的面，所以你要不断练习，做到接近那碗面的水平，才能成为好厨师。但程序员不是这样，别人把一个库放到 GitHub 上，你拉下来就能用。TiDB 开源了，你直接用就好了，何必换种语言再写一遍呢？大厂最喜欢做这种事，他们喜欢把别人的东西换种语言再写一遍，然后证明自己更厉害，评完级就把项目扔掉。我觉得这是考核机制的问题，一个人把别人做过的事再做一遍，这没什么了不起，甚至在这个行业是可耻的。如果所有人都重复做一件事，我们就不会有现在的计算机科学和互联网。我们是在前人的肩膀上再走一步，才形成了现在的巨塔。Google 那么厉害，它重写 Nginx 了吗？它做的 GFS、BigTable 等都是以前世界上没有的东西，它需要这些东西。至少一开始，Google 的初心不是为了考试。我觉得不存在超越，你可以做最好的自己。看看世界上需要什么，有什么问题需要解决，把问题解决好，你就厉害了。你不需要和任何人比较，你就是最厉害的。 我们应该庆幸现在的年轻人比我们那时候卷多了。比如东旭他们刚创业时，用 Rust 写的 Raft 应该是市场上的第一家。现在你知道市场上有多少家吗？大厂几乎人均一套 Raft。有什么必要每个年轻人都写一遍？写完了又怎么样？也没有发明 Raft。为什么要把别人的工作再做一遍呢？如果你觉得这就是一种超越，那我觉得你永远超越不了，这就是最大的问题。 在我之前两三年，经济还没这么差的时候，我面试了很多大厂的年轻人，人人都擅长 Raft，每个人都精通。我不知道我们为什么需要这么多精通的人，硅谷可能都没有这么多精通的人。Google 也就一个组在做这个事，Meta 也是一个组在做，而且那些组也不是专门做这个事的，我觉得没必要这样。 ## AI之外 这段不是很扣题 **有趣的挑战 —— 探索新技术的应用** 黄东旭：我觉得我做很多事情的出发点，不仅仅是公司业务上的探索，更多的是因为有趣，或者是因为我自己需要。比如我现在的助理不够智能，我想用人工智能来整理我的日历、邮件和个人数据。这可能看起来是一个有趣的挑战，或者是我自己需要的东西。在做的过程中，我至少会倾向使用以前没用过的那些技术。 **抬杠和祛魅** 马驰改变了我的一个观点。我以前觉得抬杠很没意义，虽然我自己以前也爱抬杠，后来反思觉得挺浪费时间，就不怎么抬了。但后来我发现抬杠有两个好处：一是去魅。你不抬杠，容易在我们这个文化体系里把位高权重人的话奉为圭臬，觉得他说什么都是对的。其实你抬抬杠，会发现没人总是对的。在这个过程中，你能了解对方是怎么想的，想想这个想法对不对。如果这个人连思考过程都没有，就是拍脑袋，你不用听了。抬杠的过程有助于去魅，并且强迫自己找证据、了解真相。拍人马屁时你不需要时间，只要付出点尊严就行，但抬杠不一样，你不学习就不能抬杠。敢于抬杠是一个挑战权威的过程，并且强迫自己学习。对很多想从事真正有价值事情的人来说，这是有意义的。无论是创业还是做科研，其实都是挑战别人的共识。没有跟一万个人抬杠的勇气和决心，很难做成事。无论做什么创新的事，都是这样。 黄东旭：我觉得"去魅"这件事在程序员或软件开发行业里特别重要。老实说，编程本质上是个手艺活。编程语言其实没那么了不起，无非就是那几个关键字。程序这东西，你写多了，自然就熟练了，大家水平也差不多。所以，没必要因为谁说过什么就觉得他特别厉害。这种盲目崇拜权威的做法其实不太好。 **"去魅"之后 能够发自内心地欣赏曾经的"敌人"做得好的地方** 我也不是完全反对抬杠这件事。抬杠更多是一种心态。现在我年纪大了，有时候会说"你说得都对"，但心里其实会想一遍抬杠的过程。这种内心的质疑很重要。我回想一下自己，编程能力最强、精力最充沛、头脑最开放的时候大概是在初中和高中。那时候我学编程比较早，正好处于叛逆期，又赶上了开源运动的浪潮。90 年代中后期的开源社区，大家的共同"敌人"是微软，一提到微软大家都嗤之以鼻。大家都觉得自己是民主战士，这种氛围让我在各种论坛里很活跃，也让我对权威有了更多的质疑。但后来我发现，真正重要的不是怼天怼地，而是完成"去魅"之后，能够发自内心地欣赏曾经的"敌人"做得好的地方。比如以前我觉得微软的东西都不好，但后来才发现，微软的 IOCP（输入/输出完成端口）在并发和异步处理方面做得非常好。这就是我想说的最后一个建议：当你完成内心的质疑和"去魅"之后，能够真正欣赏对手的优点，这就是一种成功。放弃自己的自我优越感，你会发现无论是朋友还是曾经的"敌人"，都有值得学习的地方。 马驰：我觉得在很多领域，我抬杠都能抬胜，但这并不是因为我经验丰富或能力超强。我觉得有一点特别重要，尤其是在中文圈子——就是要和国际上最先进的技术和社区保持接触。开源社区就是一个很好的例子，它不分国籍，是世界上最前沿的圈子。如果你能融入这个圈子，就能站在巨人的肩膀上。当你再去看一些封闭行业里的所谓权威、老师傅或大 V 时，就会发现他们其实已经和时代脱节了十几年甚至几十年。 **Cursor在复制系统面前的有限性** 黄东旭：现在很多工具可以自动生成代码，比如 Cursor，它在局部生成代码可能还算可以，但如果一次性生成几百行代码，我觉得这种做法完全不可靠。现在很多人还在鼓吹 Coding Agent 之类的东西，但在我看来，除非你只是开发一些简单的系统，比如食堂管理系统，或者做一些前端的简单功能，这些工具或许还能用。但如果指望它们能替代一个优秀的工程师，那我觉得还差得很远。 **S3分布式存储的工作原理** 说到学习建议，我还是觉得要回归一些万变不离其宗的基础知识。比如现在大家都在讨论 Serverless、Lambda，包括我们自己也在用，TiDB 的云服务也很快会完全运行在 Lambda 架构上。但你会发现，很多基础的东西其实并没有变。比如，一个系统的性能瓶颈在哪里？吞吐量和延迟受什么影响？在这个快速变化的时代，我对年轻程序员的期望是不要丢掉基本功。举个简单的例子，最近大家都在说云原生对象存储，S3 是新的磁盘。很多年轻人看到这个结论，就觉得 S3 很厉害，是新的存储方式。但如果你真正去设计系统，会发现当 S3 遇到瓶颈时该怎么办？S3 本身也是一个大型的分布式系统，可能需要扩容。你不一定非要自己做一个 S3，但你得了解这个系统是怎么工作的。所以在这个日新月异的时代，我还是要建议大家去看经典的东西，这些才是根本。 **严肃与低幼化** 马驰：我观察到在云计算和技术软件领域，很多产品经理有一种"低幼化"的倾向。他们会把一些很严肃的生产力工具，比如数据库、操作系统或对象存储，设计得过于可爱、甚至做一些布偶。这其实是一种非常独特的中国现象。在欧美，这种情况很少见到。我认为这种做法其实显得很不专业。 黄东旭：在美国，一些基础软件创业公司，尤其是近几年的小公司，也出现了类似的"低幼化"倾向，这其实随着"开发者关系"岗位的兴起而逐渐显现。你会发现，这些公司大多处于早期阶段，可能只有三五个人。他们这么做，一方面是为了招聘，因为这个群体大多是年轻人，公司需要打造一个酷炫的形象。但你会发现，这些公司一旦发展到一定规模，有了企业客户，他们的形象就一定会向更严肃的方向转变。举个例子，大家都知道的小强数据库（CockroachDB），其实有不少企业客户因为名字的问题而不喜欢它。当然，他们的 CEO 个性也比较强，但我个人认为，如果面向企业客户或做严肃的基础软件，还是应该更严肃一些。