夜雨聆风“现在AI写代码这么厉害，还有必要花时间研究源码吗？”
“HTTP协议那些RFC文档，还有必要看吗？”
“TCP/IP这些底层知识，平时开发根本用不到，是不是可以不用学了？”
这个问题，我自己思考了很久。
毕竟现在开发方式确实变了。
以前写一个功能，需要自己设计代码结构，一个类一个类地写。
现在很多时候，只需要把需求描述清楚，AI就能帮你生成一套代码。
一个简单的接口，一个工具类，一个业务模块，AI生成速度确实比人快很多。
但是从目前来看，我有一个感受：
AI改变的是写代码的方式，但没有改变软件开发本身的复杂性。
那些真正困难的问题，依然存在。
举一个很普通的开发场景。
产品提了一个需求：
“增加一个订单查询接口。”
对于刚工作的程序员来说，可能想到的是：
Controller接收参数。
Service查询订单。
Mapper查询数据库。
返回JSON。
功能完成。
但一个负责过线上系统的人，会继续往下想：
如果用户量增加怎么办？
订单表几千万数据以后，分页查询还能撑住吗？
这个SQL有没有走索引？
查询条件变化后，联合索引是否还有效？
接口被频繁调用，会不会拖垮数据库？
是否需要缓存？
缓存更新失败怎么办？
用户重复点击提交订单怎么办？
服务超时后，是否可以重试？
这些问题，AI都可以帮你生成代码。
但是它不知道：
你的业务为什么这么设计。
你的系统为什么这么拆分。
你的线上环境到底有什么限制。
软件开发最难的地方，从来不是把代码写出来。
而是做出正确的技术判断。
答案是：
需要。
但是目的和以前不一样了。
以前很多程序员研究源码，是为了学习框架内部实现。
比如学习Spring。
会研究：
BeanFactory怎么创建对象。
IOC容器如何管理Bean。
AOP代理到底怎么实现。
循环依赖为什么能解决。
这些知识当然有价值。
但是在AI Coding时代，看源码还有一个新的意义：
帮助你判断AI生成的代码是否可靠。
举个简单例子。
AI帮你生成线程池代码：
ExecutorService executor = Executors.newFixedThreadPool(20);代码没有问题。
运行也正常。
很多项目甚至测试环境都不会发现问题。
但是上线以后呢？
你知道：
Executors底层使用的是什么队列？
任务堆积以后会发生什么？
大量请求进入时，线程池会不会导致内存增长？
为什么很多互联网公司的开发规范禁止直接使用Executors？
如果不了解源码，你可能觉得：
“代码能跑，就没问题。”
但生产环境不是这么简单。
线上系统关注的是：
稳定性。
性能。
异常处理。
资源控制。
AI可以帮你快速写出代码。
但最终负责系统的人，还是需要知道：
这段代码背后的运行机制。
很多业务开发人员可能觉得：
“现在Spring Boot、Gateway、Nginx都封装好了，HTTP协议不用深入研究了吧？”
我以前也觉得，很多协议细节距离业务开发比较远。
但是经历过几次线上问题后，会发现：
很多问题，最后都会落到底层。
比如：
某天线上一个接口出现偶发超时。
监控显示：
业务代码执行时间只有100毫秒。
SQL也没有慢查询。
但是用户请求却需要等待几秒。
问题在哪里？
如果只看业务代码，很容易陷入：
查SQL。
看代码。
加日志。
但是如果了解HTTP和网络过程，你会想到：
是不是连接建立耗时？
是不是连接池不足？
是不是网关转发等待？
是不是Nginx timeout配置问题？
是不是服务之间调用出现阻塞？
很多线上问题，不是代码写错了。
而是代码运行的环境太复杂。
理解HTTP，不是为了让你每天背RFC。
而是在出现异常时，你知道：
请求从浏览器到服务器，中间经历了什么。
每一个环节可能出现什么问题。
很多人认为：
“我又不是写网络程序的，学习TCP/IP有什么用？”
其实很多我们每天使用的技术，都建立在这些基础之上。
比如：
为什么RPC框架需要连接池？
为什么服务调用需要设置超时时间？
为什么不能无限重试？
为什么消息队列需要确认机制？
为什么一次简单接口调用，可能导致整个系统雪崩？
这些问题背后，都和网络通信有关。
TCP为什么可靠？
因为它有：
数据确认。
顺序控制。
重传机制。
流量控制。
拥塞控制。
理解这些之后，你会更容易理解：
为什么微服务调用需要超时。
为什么需要熔断。
为什么需要限流。
为什么一个服务挂掉，会影响几十个服务。
很多架构设计，本质都是在解决底层问题。
以前，一个程序员能力强，可能体现在：
代码写得快。
熟悉框架。
开发效率高。
但现在，AI可以把很多人的编码速度拉到一个接近水平。
于是新的差距会出现。
有人拿到AI生成的代码：
复制。
运行。
提交。
结束。
有人拿到AI生成的代码：
检查设计。
分析性能。
发现风险。
优化架构。
这两类程序员，长期价值会完全不同。
AI让写代码变简单了。
但让技术判断变重要了。
程序员真正需要积累的，不是某一个框架。
因为框架会变。
Spring会升级。
数据库会变化。
AI工具也会变化。
真正有价值的是：
你理解计算机系统的方式。
你知道一个请求为什么慢。
你知道一个系统为什么不稳定。
你知道一个架构为什么这样设计。
可能很多年以后，你不再每天看TCP协议。
不再研究JVM源码。
不再翻HTTP RFC。
但是当线上出现一个别人解决不了的问题时，
你能够从业务开始，
一路分析到：
应用代码。
框架机制。
JVM。
操作系统。
网络。
最终找到原因。
这就是技术深度。
AI Coding不会让程序员失去价值。
但它会提醒我们：
不要只做一个写代码的人。
成为那个能够理解系统、解决问题、创造价值的人。
因为代码可以让AI帮你写。
但系统为什么这样设计，
为什么这样运行，
为什么这样优化，
这些能力，依然属于技术人自己。
关注〔我在回龙G敲代码〕，解锁回龙观及周边本地群聊，个人出租群，个人房东群，个人闲置群，烟火人间群，程序员创业群，IT成长群，内推工作机会信息！