本文要点：
- AI会替代一部分初中级程序员，但替代不了真正有实力的工程师
- 零基础用AI写App只是玩具，真正的编程复杂度远超想象
- 程序员要从"写代码的人"升级为"驾驭AI的架构师"
- 附具体学习路线和我的IM项目真实案例
一、一个反直觉的现象
最近刷社交媒体，你一定见过这种类型的帖子或者评论：
"不会写代码，用AI一天做了个XX App，震惊！"
评论区一片"学编程没用了""会用AI就行了""未来程序员要被淘汰了"。
2025年初，OpenAI的联合创始人Andrej Karpathy提出了一个概念叫**"Vibe Coding"**——不写代码，靠感觉和自然语言指挥AI写。这个词迅速火遍全网，成了AI编程的代名词。不过连他自己后来都承认，AI生成的代码"can still be gross"——还是可能很烂。
听起来很美好，对吧？
但我想说一个可能让你不太舒服的观点：AI越强，越需要扎实的技术基础。不是不重要了，是比以往任何时候都重要！
AI只是把瓶颈从"写代码"转移到了"审代码"，从"执行"转移到了"决策"。以前你需要会写，现在你需要会驾驭。而驾驭的前提，是你真的懂。
二、"AI会替代程序员"——这句话对了一半
先说一个很多人不爱听的真相："AI会替代程序员"这句话太笼统了。 准确的说法是——AI会替代一部分初中级程序员，但替代不了真正有实力的工程师。
什么意思？
我们先看看AI现在能做什么。一个CRUD接口、一个增删改查页面、一个简单的数据展示列表——这些过去是初级程序员每天干的活。写一个Controller、配一个MyBatis的XML、调一个数据库查询、拼一个前端列表页。这种工作，AI现在干得比初级程序员更快、更准、还不用下班。
你说，如果一个程序员的核心价值就是"把需求翻译成代码"，那他跟AI有什么区别？区别只有一个——AI更快，不要工资，不请假。
所以这部分岗位，确实危险了。
但你要是说"AI要替代所有程序员"，那就是危言耸听了。因为编程这件事，远远不止"把需求翻译成代码"这么简单。
关于这个问题，业界其实早有共识（相关讨论）：
"Strong engineers are not valuable because they can type syntax. They are valuable because they understand problems, constraints, and trade-offs."
翻译过来就是：强工程师的价值不在于会敲代码，而在于理解问题、约束和权衡。
这些东西，AI目前做不到。
所以结论很清晰了：
- 只会写CRUD的初级程序员——危险，AI能干你的活
- 只会照搬框架模板的中级程序员——危险，AI也能干你的活
- 能做架构决策、能权衡技术选型、能排查疑难杂症的高级工程师——安全，AI是你的加速器
AI不会替代程序员这个行业，但会重新定义"什么样的程序员有价值"。 而这个"有价值"的标准，比以前更高了。
三、AI擅长0→1，但1→100还得靠你
AI确实厉害。给它一个Prompt，10分钟它能搭出一个看起来像模像样的应用。前端界面有了，后端接口有了，数据能存能取，点两下还真跑得起来。
但这只是0→1。
从"能跑的原型"到"能上线的真实产品"，中间的距离，比大多数人想象的要远得多。
AI做出来的东西，也许能跑，但"也许并不是你想要的"。它的理解跟你的意图之间，永远存在偏差——理解偏差、设计偏差、细节偏差。你以为它懂了，它其实只懂了个大概。
到了1→100的阶段：消息丢了怎么补？并发上来怎么扛？数据一致性怎么保证？跨服务器怎么路由？
你可能会说："这些问题我告诉AI，它也能处理啊。"
没错。但前提是——你得先知道有这些问题。
我拿一个具体的场景说明。假设你让AI帮你写一个"用户下单"的功能。如果你只是简单地说"帮我写一个下单接口"，AI很快给你生成代码——接收请求、检查库存、扣减库存、创建订单、返回结果。看起来没毛病，跑起来也没问题。
但如果你懂行，你知道下单远不止这些：
- 两个人同时下单，库存只有一件，会不会超卖？——并发问题
- 扣了库存但订单创建失败了，库存回不回滚？——事务一致性问题
- 订单创建成功了但消息通知发送失败了怎么办？——分布式事务问题
- 10000个人同时抢购，数据库能扛住吗？——性能问题
- 如果有恶意用户用脚本刷单呢？——安全问题
你知道这些问题的存在，你就能跟AI说："帮我写下单接口，需要处理并发超卖、保证事务一致性、考虑分布式事务、做限流防刷。"AI收到这个指令，大概率能给你一个不错的方案。
但如果你不知道"并发超卖"这个概念的存在呢？ 如果你从来没听过"分布式事务"这个词呢？你压根就不会想到要跟AI提这些要求。AI也不会主动提醒你——因为它不知道你不知道什么。
这就是问题的核心：不是AI不会，而是你不知道该让它做什么。
AI的能力没有上限，但你的知识储备决定了你能从AI那里拿到什么质量的输出。你的Prompt写得越精准、考虑得越全面，AI给你的结果就越好。而精准的Prompt，来自扎实的技术功底。
所以真正可怕的不是"AI写错了"，而是——你连AI漏了什么都看不出来，因为你自己就不知道那里应该有什么。
四、"我零基础用AI写了3个App"——我想说 兄弟 😂 别闹了
现在社交媒体上到处是这种标题："不会写代码，用AI一天做了个XX"。
我直说：那只是玩具。
为什么？看下面这张图就明白了。零基础的人只看到水面上那10%——一个能跑的界面、几个功能按钮。而水面下真正的编程复杂度——并发安全、数据一致性、性能扩展、架构决策——他们压根看不到。
先说清楚，AI对普通人确实很有用。帮你整理Excel数据、生成PPT、写工作总结、处理图片、翻译文档、甚至做个简单的网页展示——这些场景AI表现得非常好。AI对普通人的意义就是提升工作效率，这个毋庸置疑。
但"提升工作效率"和"开发一个完整的商业化App"，中间的差距是数量级的。
Stack Overflow的官方博客讲过一个真实故事。他们的一位非技术编辑，用Bolt做了一款App。表面上10分钟搭出来了，界面还挺好看。但交给工程师一看——安全漏洞一堆、数据没有任何保护、代码混乱到无法维护、没有单元测试，甚至Redis是什么都不知道就已经在用了。
66%的开发者在使用AI工具时都遭遇过所谓的"生产力税"——AI生成的代码"几乎对但又不完全对"，你反而要花更多时间去修它。
你零基础用AI做的那个App，上线试试？用户数据要不要保护？并发扛不扛得住？支付接进去安不安全？做出来和能用是两回事，能用和能上线又是两回事。
所以别自嗨了。零基础用AI做App，发个朋友圈炫耀一下没问题，但别真以为自己会开发了。 因为前面说过的那些坑——并发安全、数据一致性、性能扩展、异常处理——你一个都不知道，AI也不会替你操心。
行外人觉得"AI编程很简单"，因为他们压根看不到水面下的冰山。
五、真实案例：一个IM系统到底有多复杂
说这些可能还是太抽象。我拿我自己做的项目举例。
我花了两年业余时间，一个人做了一个即时通讯系统——XZLL IM。Java微服务后端 + Flutter客户端，从零开始。
很多人觉得"做个聊天软件能有多难？不就是一个发送按钮一个消息列表吗？"
来，我列一下一个IM系统真正要解决的问题：
1. 消息可靠性
你发出的消息，对方一定要收到。不能丢，不能重复。听起来简单？这需要你理解TCP的三次握手、ACK确认机制、消息去重策略。消息发出去但网络断了怎么办？重试几次？重试期间对方收到了怎么办？幂等性怎么保证？
如果这些问题你回答不了，那你用AI写的聊天功能，大概率在弱网环境下就出bug了——而你连为什么出bug都不知道。
2. 高并发长连接
几万人同时在线，每人一个WebSocket长连接。操作系统告诉你：一个进程能开的文件描述符是有限的。怎么突破？需要理解Netty的Reactor线程模型，理解Boss Group和Worker Group怎么分工，理解Epoll和NIO的区别。
AI可以帮你生成Netty的启动代码，但它不会告诉你"你的线程模型在高并发下可能会阻塞"。只有你自己懂，才能提前规避。
3. 数据存储分层
用户和好友关系存MySQL，聊天记录存MongoDB，缓存和未读计数存Redis，消息搜索用Elasticsearch。为什么不用一个数据库搞定？因为每种数据库的特性和适用场景完全不同——这需要对存储引擎、索引原理、CAP理论有理解。
这个技术选型决策，AI做不了。它不了解你的读写比例、数据量级、查询模式。选型是架构师的事，不是AI的事。
4. 离线消息
用户下线了，发给他的消息怎么办？存哪？上线后怎么拉取？拉取的时候怎么保证不漏不重？我用Redis的ZSet按时间戳存储离线消息，上线后按时间范围拉取——这个设计决策，AI能帮你想出来吗？也许能，但前提是你得知道ZSet是什么、为什么用它、它有什么限制。
5. 跨服务器消息路由
用户A连接在服务器131上，用户B连接在服务器132上，A给B发消息怎么送达？需要一个gRPC的跨服务器转发机制。如果B同时登录了手机和电脑呢？多端同步怎么办？这些架构决策，不是AI帮你写几行代码就能解决的。
6. 群消息广播
一个群500人，一条消息要推给500个设备。500个人里有的在线有的离线，有的在一台服务器上有的分散在十台服务器上。不能一个人一个人地推，需要通过RocketMQ做消息广播，需要设计消息扇出策略——这背后是对消息队列、发布订阅模型的理解。
这还只是冰山一角。 还有Protobuf协议设计、JWT鉴权、API网关路由、MongoDB到Elasticsearch的数据同步、音视频通话的信令设计……
你说，这些是AI能帮你从0→1搞出来的吗？
也许它能帮你写出一些框架代码、生成一些CRUD接口。但每一个环节的设计决策、性能权衡、异常处理，都需要人有足够的知识储备。我在开发过程中也大量使用了AI工具（Claude Code、Cursor等）来加速编码，但核心的架构设计、消息流转路径、协议定义，全部基于我对底层技术的理解。
AI帮我写得更快，但不会帮我设计得更好。 设计，只能靠我自己。
六、程序员的角色转变：从"开发者"到"架构师"
所以结论来了：AI时代程序员不是要被淘汰，而是要升级。
什么意思？不是所有人都会失业，但所有人的角色都会变化。以前的程序员和未来的程序员，干的是不一样的事。
来看看前后的对比：
以前一个程序员的工作流：需求 → 设计 → 编码 → 测试 → 部署，大部分时间花在"编码"上。
现在呢？需求 → 架构设计 → 指挥AI编码 → 审查验证 → 调优。
编码的部分被AI加速了，但你的核心能力变成了三样东西：
1. 架构能力——系统怎么拆？模块怎么分？技术怎么选？用MySQL还是MongoDB？用HTTP还是gRPC？消息同步用推模式还是拉模式？这些决策AI做不了，因为它不理解你的业务、你的用户量、你的约束条件。
2. 验证能力——AI写的对不对？有没有安全隐患？性能能不能扛住？并发下会不会出问题？代码结构合不合理？你如果连TCP三次握手都说不清楚，怎么验证AI给你的网络方案？
3. 驾驭能力——怎么给AI精确的指令？怎么把一个复杂任务拆解成AI能处理的小任务？怎么在AI跑偏时及时纠正？这就像一个导演指挥演员——你不懂表演，你就导不了戏。
Google的资深工程师Addy Osmani说过一句话："Vibe Coding不等于AI辅助工程。前者是盲信AI的输出，后者是驾驭AI的能力。"
而这三种能力——架构能力、验证能力、驾驭能力——全部建立在扎实的技术基础之上。 没有基础，你就是个只会说"帮我写个App"的外行，而不是能驾驭AI的工程师。
打个比方：以前你是驾驶员，自己开车。现在你是车队策略师，AI是你的车手。车手负责执行，但你得比车手更懂赛道——才能制定正确的策略，才能在车手跑偏的时候把他拉回来。
你不需要亲手换每一个挡，但你必须知道什么时候该换挡。
七、哪些程序员会被淘汰？哪些不会？
说到这里，我想更直白地回答一个很多人关心的问题：到底谁会被淘汰？
画了一张分界图，一目了然：
先说会被淘汰的
1. 只会CRUD的"增删改查工程师"
如果你的日常工作就是：接到需求 → 打开IDE → 写一个Controller → 写一个Service → 写一个Mapper → 测试通过 → 提交代码。这种工作模式，AI现在就能替代80%。不是未来，是现在。
2. 不理解原理只会用框架的"调参侠"
会用Spring Boot，但不知道Spring的IoC容器是怎么工作的；会用Redis，但说不清Redis为什么快、什么场景该用什么数据结构；会用MQ，但不知道消息丢了怎么办。这种人，AI生成的代码跟他写的差不多，但AI快100倍。
3. 缺乏系统思维的"单点程序员"
只会写自己那一块代码，不理解上下游，不理解整个系统怎么运转。出了问题只能靠日志猜，猜不到就找大佬。这种人，AI也替代不了大佬，但能替代他。
再说不会被淘汰的
1. 能做架构决策的人
知道一个系统该怎么拆、技术该怎么做选型、性能瓶颈在哪、怎么横向扩展。这种能力不是AI能给的——它需要对业务的深刻理解和对技术的全局把控。
2. 能排查疑难杂症的人
线上CPU飙到100%怎么排查？消息队列积压了100万条消息怎么办？数据库死锁了怎么分析？这些问题，AI给你一段排查命令容易，但判断问题出在哪、该怎么做决策，需要经验和对底层原理的理解。
3. 能驾驭AI的人
知道怎么把一个复杂需求拆解成AI能理解的任务，知道AI生成的代码哪里可能有坑，知道什么时候该让AI干活、什么时候该自己动手。这种人，AI是他的倍增器。
看清这个分界线，就知道自己该往哪个方向努力了。
八、那到底该怎么做？程序员的学习路线
不是让你不用AI工具，而是：先用基础武装自己，再用AI放大能力。
那具体该学什么？我结合自己做IM项目的经历，按优先级列一个路线：
我画了一个学习路线金字塔：
第一层：计算机基础（最重要，别跳过）
这是所有编程能力的根基。没有这一层，上面盖什么都是空中楼阁。
网络原理（TCP/IP、HTTP、WebSocket）——我设计IM的消息传输方案时，如果不懂TCP的可靠性机制和WebSocket的全双工通信，根本无法做出合理的选择。AI可以帮你写Netty代码，但它不会告诉你"这个场景应该用WebSocket而不是HTTP轮询"。学了网络原理，你才能判断AI给你的网络方案对不对。
操作系统（进程/线程、内存管理、IO模型、Epoll）——高并发程序的本质是在跟操作系统打交道。你不懂IO多路复用，就理解不了Netty为什么快；不懂线程调度，就不知道线程池参数该怎么配；不懂内存模型，就排查不了内存泄漏。这些是AI写代码时的"隐形假设"，你不懂就发现不了。
数据结构与算法——不是让你去刷LeetCode应付面试，而是真正理解。知道B+树怎么工作的，才能理解MySQL索引为什么高效；知道哈希表的冲突处理，才能理解Redis的渐进式Rehash；知道图的遍历算法，才能设计消息路由策略。AI能帮你实现算法，但只有你理解了，才知道该让AI实现哪个算法。
第二层：数据库与存储（吃饭的家伙）
几乎所有程序都绕不开数据存储。
关系型数据库（索引原理、事务ACID、锁机制、隔离级别、慢查询优化）——IM系统里用户、好友、群组、会话全部存在MySQL。如果你不理解索引的B+树结构、事务的隔离级别、行锁和表锁的区别，你连AI生成的SQL有没有问题都看不出来。SQL写错了AI不会提醒你，但你线上数据出问题了那可是真金白银。
NoSQL（Redis数据结构与适用场景、MongoDB的文档模型、Elasticsearch的倒排索引）——IM系统用了MongoDB存消息、Redis做缓存和未读计数、Elasticsearch做搜索。每种存储用在哪里、为什么用它、它有什么限制——这些选型决策全是架构层面的，AI做不了。
第三层：并发与分布式（进阶必备）
这一层是区分"会写代码"和"会做工程"的分水岭。
并发编程（线程模型、锁机制、CAS、线程池、volatile）——万人在线的消息推送，如果不懂线程池的参数配置和锁的粒度控制，AI写出来的代码在并发场景下分分钟出bug——而你根本看不出问题在哪。并发bug是最难调试的bug，因为它不是每次都复现。
分布式系统（消息队列、RPC、服务发现、CAP理论、分布式事务）——IM系统涉及gRPC跨服务器通信、RocketMQ消息广播、Nacos服务注册发现。这些架构决策，AI能帮你写实现代码，但选型决策必须你自己做。
第四层：架构思维（高级方向）
这一层不是学出来的，是在前三层的基础上，通过实战项目练出来的。
- 怎么从需求推导出技术架构？
- 怎么评估一个方案的性能瓶颈？
- 怎么在多种技术方案之间做权衡取舍？
- 怎么设计一个可扩展、可维护的系统？
这些能力的培养没有捷径，只有一个办法：做真实项目。 不是做一个Todo List，而是做一个真正有复杂度的系统。比如一个IM系统、一个电商系统、一个推荐引擎——任何能让你面对"真实复杂度"的东西。
同时：学会驾驭AI工具
以上四层是基础，同时你要学会使用AI工具（Claude Code、Cursor、Copilot等），它们确实能极大提升效率。但永远保持对代码的理解和掌控——你不是在"让AI帮你写代码"，你是在"用AI加速你的想法落地"。
一句话：不懂代码，就无法真正驾驭AI。懂代码，AI就是你的倍增器。
九、一个新概念：Harness Engineering
说到这里，我想引出一个2026年正在快速升温的概念——Harness Engineering。
Google的资深工程师Addy Osmani在O'Reilly上发表过一篇文章，标题就叫《Agent Harness Engineering》。他还专门做了一个AI辅助工程的实践指南。他说了一句很关键的话：
"一个裸的AI模型不是Agent，Harness（驾驭装置）让它成为了Agent。"
什么意思？
就好比一匹千里马，它跑得再快，没有缰绳、马鞍、方向指引，你也骑不了。Harness Engineering就是这个缰绳和马鞍——它指的是围绕AI Agent设计的那套约束、反馈循环、验证机制和上下文管理。
具体来说，一个Harness包括：
- 约束设计：AI能做什么、不能做什么、边界在哪
- 上下文管理：给AI提供正确的项目背景、代码规范、架构约定
- 验证机制：AI生成的代码怎么验证对不对、跑测试、过Review
- 反馈循环：AI做错了怎么纠正、怎么让它从错误中学习
- 工具接口：AI能用哪些工具、怎么调用、权限怎么控制
你看出来了吗？这恰好就是这篇文章一直在说的"驾驭AI"的具体实践。
前面我说了，AI时代程序员的核心能力是架构能力、验证能力、驾驭能力。Harness Engineering就是这三样能力的工程化落地。它不是一句口号，而是一套可操作的方法论。
拿我自己做IM项目来说，我并不是简单地跟AI说"帮我写个IM系统"就完事了。我会先告诉它整个系统的架构分层——网关层负责鉴权路由，长连接层用Netty做WebSocket，业务层处理消息存储和好友关系，数据同步层消费MQ写ES。我会规定消息的Protobuf协议格式，约定Chat ID的生成规则，说明离线消息用Redis ZSet存储的策略。我会把一个复杂功能拆成十几步，让AI一步一步来，每一步都验证结果。
这个过程，本质上就是在给AI搭建一个Harness——告诉它约束是什么、上下文是什么、怎么验证做得对不对。
而这一切的前提是：我自己先搞懂了Netty的线程模型、Redis的数据结构、消息队列的投递语义、Protobuf的序列化原理。如果我不懂这些，我连Harness该约束什么都不知道。
你的基础越扎实，你的Harness就越精密，AI的输出就越可靠。
关于我是怎么在IM项目中从零搭建Harness、有哪些具体实践和踩过的坑，我会在下一篇文章中详细展开。
十、最后说几句掏心窝的话
这篇文章写到这里，我想回到一个最根本的问题：基础技术到底有多重要？
我用整篇文章在说这件事，但让我再总结一次：
AI能帮你写代码，但不能帮你理解代码。AI能帮你搭框架，但不能帮你做架构决策。AI能帮你快速出原型，但不能帮你把原型变成生产级产品。这些能力的背后，全部是基础——网络原理、操作系统、数据库、并发、分布式。没有这些，你跟AI之间的对话就只能是"帮我写个XX"，而不是"帮我实现这个架构方案，注意处理并发和事务"。
基础决定了你能从AI那里拿到什么质量的输出。 这就是为什么AI越强，越要学基础。
那程序员到底怎么避免被AI淘汰？
说难听点，路就两条：
第一条：死磕技术，往上走。 把基础打牢，从"写代码的人"升级为"做架构决策的人"。学会驾驭AI，让AI成为你的倍增器。这条路不难理解，但需要时间和汗水——没有捷径。
第二条：认清现实，趁早转行。 如果你既不想补基础，又不想升级能力，只想靠AI混日子——那说实话，趁早转行可能是更理性的选择。不是每个人都要当程序员，但如果你想留在这个行业，就必须提供AI提供不了的价值。温水煮青蛙，煮到最后是最惨的。
没有第三条路。 指望"AI替代不了我"是自欺欺人，指望"我会用AI就行了"是掩耳盗铃。
AI是一个放大器——放大高手的能力，也放大菜鸟的无知。基础扎实的人用AI，效率提升10倍；基础不牢的人用AI，只是把错误放大了10倍。
AI不会淘汰程序员，但会让不懂基础的"程序员"裸泳。
所以回到标题那句话：零基础用AI写App？醒醒吧，那只是个玩具罢了。
真正有价值的，不是你用AI做出了什么，而是你理解了多少。理解得越深，AI能帮你做的就越多。理解得越浅，AI只能帮你做玩具。
说完了技术和职业，最后我想说点题外话。
不管你是刚入行的新手，还是干了十几年的"程序大叔"，我想说一句：保持空杯心态。
AI这波变化来得太快，快到所有人都有点慌。新手慌"还要不要学"，老手慌"会不会被替代"。但你冷静想想，哪一轮技术革命不是这样？从汇编到高级语言，从单体到微服务，从手工部署到DevOps——每一次都有人喊"要完蛋了"，但每一次挺过来的人，都变得更强了。
这次也一样。AI不是洪水猛兽，它就是一波新的技术浪潮。你不需要比浪潮跑得快，你只需要站在对的方向上，别被冲走就行。
所以尽可能别焦虑。好好学你的基础，好好做你的项目，好好生活，保持一个好心态。技术这条路很长，不是百米冲刺，是马拉松。能跑到最后的，从来不是跑得最快的，而是心态最稳的。
