AI不会淘汰程序员，但会改变程序员的成长路径

两个多小时的交流：AI 在接手什么，人又该守住什么

「产品做出来，只是技术闭环；有人持续使用并愿意付费，才是商业闭环」

两个多小时的交流里，我们没有把重点放在「AI 究竟会淘汰多少程序员」这样的预测上，而是讨论了几个更具体的问题：AI 正在接手程序员的哪些工作？哪些能力反而会变得更重要？当编码越来越容易，高级工程师的成长路径会不会出现断层？

话题也从技术延伸到了管理和创业：一个程序员如何从「自己解决问题」，走向「组织团队解决问题」，又如何在创业以后发现——产品做出来，只是技术闭环；有人持续使用并愿意付费，才是商业闭环。

AI 正在接手什么，程序员真正值钱的又是什么？

我不太愿意预测「AI 会淘汰 30% 还是 50% 的程序员」，现在没人能可靠地给出这个数字。但有一个趋势已经非常明显：把一个已经描述清楚的需求翻译成代码，正在迅速变便宜。过去程序员花很多时间查 API、写 CRUD、做页面、写模板代码、修改明确的 Bug，这些工作 AI 已经越来越擅长。如果一个程序员的主要价值是「别人告诉我做什么，我负责把代码写出来」，这部分价值确实会受到比较大的冲击。

但往上走一层，很多能力反而会更重要：这个问题到底应该怎么定义？一个复杂问题应该怎样拆解？架构应该怎么设计？AI 给出的方案到底靠不靠谱？哪些地方未来可能出现性能、稳定性或者维护问题？技术方案和业务目标是不是一致？最后谁对整个结果负责？

所以我的判断是：写代码本身的价值在下降，但解决问题的价值没有下降。甚至从某种意义上讲，优秀工程师的杠杆反而变大了。

我目前更倾向于后者。以前一个再优秀的工程师，也只有两只手。现在一个高级工程师可以先确定架构，把任务拆开，定义接口和边界，再让 AI 完成大量具体实现，自己负责 Review 和最终判断。某种意义上，一个优秀工程师开始拥有了一支 AI 执行团队。

所以以前一个人的技术能力，主要体现在「我自己能写出多复杂的系统」；以后会越来越体现在「我能不能把 AI 组织起来，完成一个更大的问题」。这时候人的上限不再只是编码速度——架构、判断、业务理解、问题拆解、质量控制，这些能力都会被 AI 进一步放大。

真正的问题，可能是高级程序员以后从哪里来

这是我最近越来越关注的问题。我们这一代高级工程师的成长过程，其实非常「低效」：写大量基础代码，代码写得不好会出 Bug，然后一点一点 Debug；系统上线出问题再慢慢排查；业务量上来发现架构不行再重新设计。很多事情当时看起来很痛苦，但几年后回头看，那些经历本身就是训练的一部分。

今天一个年轻程序员接到需求，可以直接告诉 AI「帮我实现这个功能」，几分钟后代码和测试代码都出来了。短期看效率当然提高了。但问题是：如果那些过去看起来低效、重复、痛苦、实际上具有训练价值的过程大量消失，高级工程师需要的判断力从哪里来？这可能是 AI Coding 时代一个容易被忽略的问题。

我觉得完全有这种可能。所以我真正担心的其实不是 AI 本身，而是使用 AI 的方式。如果一个年轻工程师只是「需求来了、让 AI 生成、程序跑起来、然后提交」，那他确实可能绕过很多原本应该获得的经验。但如果他利用 AI 以后，把省下来的时间拿去理解更大的系统、分析更复杂的问题，甚至更早承担过去三五年以后才能承担的任务，那 AI 反而可能加速成长。

所以未来的成长方式可能会发生变化：过去程序员很大程度上通过「写更多代码」逐渐成长，以后可能更多通过「负责更大的问题」来成长。这其实是我觉得最值得研究的变化。

AI 时代，不应该拒绝 AI，而应该更早承担完整问题

首先，AI 肯定要大量使用。为了所谓「锻炼自己」而故意不用 AI，没有必要——AI 已经成为新的生产工具，未来不会使用 AI，本身就可能成为一个劣势。但与此同时，有几件事情不能一起外包出去。

第一，关键代码和关键方案必须真正理解。「能跑起来」不代表「我懂了」，尤其一个系统的核心部分，你至少应该知道：为什么这么设计？它有什么假设？风险可能在哪里？

第二，不要逃避 Bug、性能问题和线上故障。这些事情很烦，但它们仍然是形成工程判断非常重要的来源。如果每次遇到问题只是把日志扔给 AI、复制答案，问题可能解决了，但人不一定获得了经验。

第三，尽快扩大自己负责的问题范围。不要把目标定成「有了 AI 以后，我一天能写原来三倍的代码」，更值得追求的是「有了 AI 以后，我能不能比过去更早负责一个完整模块、一个完整系统，甚至一个完整的业务问题」。AI 把我们从大量重复编码中释放出来以后，省下来的时间应该用于理解更大的系统、解决更复杂的问题，并承担更完整的结果。

程序员可能写得越来越少，但需要理解得越来越多

我觉得这个趋势比较明显。一个真正可以上线、长期运行的产品，从来不只是生成几个页面、几个接口：数据库怎么设计？缓存放在哪里？任务怎么排队？GPU 怎么调度？某个服务失败以后怎么重试？用户量突然增加十倍怎么办？权限、安全、成本怎么控制？这些事情都需要有人理解整个系统。

比如一个 AI 图片处理产品，用户提交一张图片以后，背后可能涉及多个串行或者并行步骤：任务进入队列，不同服务领取任务，GPU 资源调度，不同模型处理，中间失败需要重试，最后再把多个结果聚合起来返回给用户。AI 可以帮助完成里面大量具体代码，但最终还是需要有人回答：这一整套系统到底靠不靠谱？

所以我觉得未来程序员可能会：写得越来越少，但需要理解得越来越多。

从 14 岁学编程开始，很多东西其实是长期积累出来的

我接触计算机比较早。14 岁读的是计算机专业中专，15 岁左右真正迷上了编程。那时候没有什么职业规划，就是单纯觉得这个东西特别有意思：写一段程序，电脑真的会按照你的指令运行；遇到一个东西不明白，我就想把它弄懂；弄懂以后，又想自己做出来。17 岁考了初级程序员，19 岁又考了高级程序员，18 岁左右开始工作。

我的求学路径比较特别。工作以后我一直在继续学习，后来先后获得北京大学计算机及应用专业成人学士学位，以及美国马里兰大学工商管理硕士（MBA）学位。但如果问我为什么最后做了二十多年技术，其实最开始和学历或者职业规划关系都不大，核心就是喜欢。这种习惯一直延续到现在——比如我看到一个新的模型架构，只把论文大概看懂有时候还不够，我会想自己写个 Demo 跑一下，甚至训练一个小模型，真正看看它是怎么工作的。

是的。我现在已经忘掉了很多年轻时候学过的具体技术，但有些东西留下来了：看到一个系统异常，会比较快地判断应该先往哪个方向查；看到一个技术方案，会比较自然地想到——业务量扩大十倍以后，什么地方可能最先出问题？这个设计短期很快，但未来维护成本会不会很高？这些东西很难通过背知识点得到。

所以我越来越觉得：工程经验，很大程度上是大量真实问题在一个人身上留下来的压缩结果。具体技术会过时，但是一个人理解技术、分析问题、寻找答案的方式会留下来。

从工程师到管理者，最难放下的是「我自己来」

最大的变化是：结果不再主要由自己产生。做程序员的时候，一个问题来了，如果自己能力足够强，可以自己把它解决掉；但管理几十个人以后不可能，你再厉害，也不可能把所有人的代码自己写掉。

所以技术人员转管理以后，需要完成一次很重要的认知转换：管理，就是通过别人完成目标。这句话听起来很简单，但真正做到并不容易。技术能力比较强的人很容易遇到一种情况：团队成员做出来的东西和自己的预期不一样，就觉得「算了，我自己来」。偶尔救火没有问题，但如果长期这样，本质上还是一个高级程序员，只不过旁边多了一群人，并没有真正完成向管理者的转变。

管理者要关注的是：目标是不是对的；事情怎么拆；谁最适合做；资源够不够；哪里应该介入；哪里应该让成员自己承担；最后团队整体能不能产生结果。

我比较认同一个原则：权利和责任应该尽量匹配。管理者需要承担管理责任和最终兜底责任，但具体执行者也必须对自己的工作负责。如果要求一个人承担结果，却不给他相应的决策空间，那团队很难有主动性；反过来，如果给了充分自由，却不要求承担结果，组织也会失序。

所以比较理想的状态是：成员在自己的职责范围内拥有比较充分的自主空间，同时也对结果负责；管理者在更大的范围内负责目标、资源、协调和最终兜底。我个人不太喜欢事无巨细地管理。真正好的管理不是所有人都按照管理者自己的方式做事情，而是大家清楚自己的目标、边界和责任，然后能够主动把事情推进。

CTO 最重要的，不是把最难的技术做出来

我觉得可以用一句话概括：优秀程序员擅长解决难题，优秀 CTO 首先要判断什么题值得解决。比如一个方案技术上可以做到 95 分，但需要 20 个人做一年；另一个方案只能做到 85 分，但 3 个人两个月可以上线。工程师比较容易问「哪个方案技术上最好」，CTO 必须问「在公司现在这个阶段，哪个方案最合适」。这已经不是纯技术问题，还涉及产品、成本、团队、时间和公司的发展阶段。

到了 AI 时代，这种能力会更加重要。现在技术上可以做的事情太多了：调用大模型 API、部署开源模型、做 RAG、微调、训练专业模型、做 Agent。「能不能做」越来越容易，真正难的是：为什么做？值不值得做？什么应该自己做？什么应该直接使用外部能力？什么虽然很酷，但公司现在根本不应该投入？所以工具越强，判断「什么不做」反而越重要。

AI 可能让组织变薄，但不会让「责任」消失

我觉得 AI 一定会替代大量管理工作，组织也确实可能因此变得更薄。比如过去很多管理工作是：整理会议纪要、收集信息、汇总周报、追踪项目进展、信息上传下达——这些事情 AI 会越来越擅长。

但管理真正困难的部分并不只是信息搬运：两个人发生冲突怎么处理？一个能力很强但破坏团队合作的人要不要留下？资源有限的时候砍哪个项目？一个决定大家都不喜欢、但公司必须做，谁来判断、谁来承担后果？这些事情背后是判断、关系和责任。

所以我的判断是：AI 会大量压缩「信息中转型管理」，但不会消除组织对判断和责任的需求。职位越高，工作里「判断」和「负责」的比例通常也越高。

从大厂到创业，对「优秀人才」的定义也变了

大厂里基础能力当然还是很重要，比如计算机原理、操作系统、网络、数据结构。除此之外，我一直比较看重学习能力、分析问题的能力、责任意识、沟通和协作能力。我过去遇到过一些试用期没有通过的情况，真正的问题未必是技术完全不行，而可能是协作出了问题——遇到问题不主动同步、习惯自己闷头处理，或者觉得「我的代码已经写完了，后面不关我的事」。在复杂组织里，这种人的价值会明显受到限制。

创业以后，我又会更加看重完整交付能力、主动性，以及面对不确定性的适应能力。大公司专业分工比较细；创业公司人少、问题多，而且边界经常变化，很多时候不能等着别人把完整 PRD 写好，再告诉你下一步应该做什么。你需要自己理解：用户为什么需要这个功能？方案怎么设计？上线以后用户到底用不用？

另外，创业公司招聘本身也是双向选择：创始团队在面试候选人，候选人其实也在面试创业团队。所以创业公司不是简单找「最优秀的人」，而是找真正匹配的人。

空降管理者最危险的时候，恰恰是最想证明自己的时候

我觉得最容易犯的错误，就是太快证明自己。新的管理者刚到公司，很容易觉得「公司把我请过来，我必须马上做点事情」，于是调组织、改架构、换流程、甚至换人——但这个阶段往往恰恰还不真正了解问题。

我更倾向于先把地图搞清楚：业务靠什么产生价值？用户为什么使用？团队真正的问题是什么？哪些人掌握关键知识？哪些事情看起来不合理，但其实有历史原因？还要和上级充分沟通，把目标、优先级和判断框架尽量对齐，然后再选择真正重要的问题去解决。

因为空降管理者还有一个很重要的任务：建立信任。团队不会因为你职位高，就自动认为你的判断正确。当大家逐渐发现你真的理解问题，而且判断能够带来结果，后面的组织和技术调整才更容易推进。所以我比较认可：先理解，再判断；先做出结果，再推动更大的改变。

大厂也做过 0 到 1，为什么创业以后才真正理解商业闭环？

在大公司里，很多基础能力已经存在了：品牌已经存在，用户或者流量可能已经存在，组织体系已经存在，财务、法务、销售、渠道、服务器等很多能力也已经存在。所以技术和产品团队往往会比较聚焦于「我们能不能把这个东西做出来？」

创业公司不是这样。产品做出来以后，你还得问：用户从哪里来？为什么他要用你，而不是别人？免费用户愿不愿意付钱？付了一次以后会不会继续付？获客成本能不能成立？这个收入最后能不能支撑一个团队？

所以我创业以后重新理解了什么叫「闭环」：技术交付完成，只是一个小闭环；用户愿意持续使用和付费，才是商业上的大闭环。在大厂里，「上线」有时候意味着一个阶段完成；创业以后，「上线」往往只是验证刚刚开始。

工程师擅长坚持，但创业有时候恰恰需要证伪

这是技术创业者很容易遇到的问题。因为工程师长期受到的训练就是：问题很难没有关系，继续查、继续改、总能解决。这在技术世界里很多时候是对的。但市场不一样——一个创业方向本质上是一组假设：用户是不是真的有需求？愿不愿意付钱？获客成本能不能成立？我们有没有能力比别人做好？外部平台和政策会不会变化？其中任何一个核心假设被证明不成立，方向就可能需要调整。

所以我现在会区分两件事情：坚持创业，和坚持某一个具体方向，这不是一回事。创业不是考试，不是只要努力足够多就一定有答案。方向错的时候，努力有时候只是在更快地消耗资源。真正重要的是不断获得真实的外部反馈，并且确保这一轮失败以后，你还有能力继续试下一道题。

平台给你效率，同时也可能拿走你的确定性

我觉得平台当然可以使用，它是非常重要的渠道，也可能提供流量和基础设施。真正需要警惕的是：不要把公司的命运完全建立在某一个平台的一条规则上。如果一个产品的价值完全依赖于某个平台目前允许的一种玩法，那么平台一旦调整规则，或者平台自己推出类似能力，创业公司就会非常被动。

所以后来我越来越倾向于：平台可以成为渠道，但最好不要成为创业的地基。真正比较稳定的东西还是：用户为什么需要你？产品到底解决了什么独立问题？即使渠道发生变化，用户是不是仍然愿意找到你？这种产品本身的价值更加重要。

AI 是巨大的产业机会，但不一定是「你的创业机会」

我觉得最重要的一点是：产业机会很大，不等于对某一个具体的人来说，现在就一定是创业机会。我不会仅仅因为「AI 是一次非常大的技术浪潮」，就建议一个人马上辞职创业。

我更建议先真正做几件事情：真正把 AI 用起来；真正做一个产品；真正接触一些用户，哪怕先只有几十个用户；如果可能，再看看有没有完全陌生的人愿意为你的东西付钱。这个过程和天天看新闻、看模型榜单、看哪家公司融资，是完全不同的。

创业最好不是「AI 太火了，我怕错过」，而是「我发现了一个真实问题，而且我在这个问题上确实拥有一些别人没有的理解、能力或者资源」。还有一个很常见的问题：大厂里的人容易拿现实工作的全部缺点，去比较想象中创业最好的一面。现实道路是高清的，每一个问题你都知道；没有发生的创业人生，却天然没有 Bug。所以创业以前，最好真正接触创业者，了解现金流、招聘、销售、获客和长期不确定性到底意味着什么，再决定。

如果今天重新创业，我不会先问「哪个 AI 方向最火」

我不会先问「现在最火的 AI 方向是什么」，我会先问三个问题：我比别人更懂什么？我离哪些用户更近？哪些事情因为 AI 出现以后，今天第一次真正变得可以做了？

我个人比较关注 AI Coding、多模态和视觉 AI、Agent，以及很多垂直行业里的专业模型。但我觉得比方向名字更重要的是：AI 到底能不能真正进入一段完整工作流。比如跨境电商里，过去可能需要人去完成找商品信息、翻译、做图片、生成 Listing、发布、分析数据、再优化——如果 AI 只能帮助其中一个步骤，已经有价值；如果未来它可以连续完成更长的一段业务流程，价值会更大。

我比较看好的一种结构是：大基础模型提供通用智能，专业模型提供垂直能力，Agent 把这些能力组织起来，最终进入真实业务流程。

写作的第一个受益者，很多时候其实是自己

我以前可能首先想到的是个人影响力、认识更多人。现在我越来越觉得：写作首先是在帮助自己形成观点。一个想法只存在于脑子里的时候，经常会觉得已经想得很清楚；但真正要把它写下来，让一个完全不了解背景的人也能够看懂，你才会发现：这里有没有矛盾？这个判断的依据是什么？这只是我的个人经验，还是有一些能够复用的规律？

公开写作还会多一层约束：因为别人会看到，所以对事实和观点都要更加负责。从这个意义上说，写作最大的受益者，很多时候首先是作者自己。

当然，持续表达也会产生很多意想不到的连接——包括今天这次访谈，本身就是因为你看到了我之前写的文章，觉得里面有些东西值得聊，才有了今天两个多小时的交流。所以我现在觉得：写作既是在向外建立连接，也是在向内整理自己。

技术人的成长，本质上是在不断扩大自己负责的问题

我觉得是：不断扩大自己负责的问题。最早的时候，是把一段代码写对；后来是把一个模块做对；再后来，是设计一个完整系统；做管理以后，变成怎么让一个团队共同解决一个问题；做到更高的技术管理岗位以后，又开始关心什么问题值得解决；到了创业以后，还要再往前一步：用户到底需不需要这个问题被解决？他愿不愿意为此付费？

所以如果把整个过程连起来，是一条非常清晰的路径：写代码 → 解决问题 → 设计系统 → 组织团队解决问题 → 判断什么问题值得解决 → 验证用户愿不愿意为这个问题付费。

具体的工具一直在变化：二十年前程序员写代码的方式和今天已经完全不同，未来五年可能变化得更快。但真正长期有价值的东西，还是理解问题、形成判断、创造解决方案，并且对最终结果负责。

所以我并不特别担心「程序员这个职业是不是很快会消失」，我更关心另一个问题：当 AI 帮我们绕过越来越多成长中的困难以后，我们怎样才能不同时绕过成长本身？过去程序员主要通过「写更多代码」逐渐成长；未来，我们可能更应该利用 AI，让自己更早去负责更大的问题。这可能才是 AI 时代，每一个程序员真正值得认真思考的事情。