AI 会写代码了，非科班还要补 CS 基础吗？

2026-04-20·3 分钟阅读职业学习思考

一个我反复纠结的问题

我是半路出身的全栈工程师，不是科班。这两年最直观的变化是：AI 能帮我写一大半代码。需求拆好、上下文给够，它出活的速度比我快得多。

于是一个问题就一直在我脑子里转：既然代码都有人（有 AI）替我写了，我还有必要回头去补计算机科班那一套基础吗？数据结构、操作系统、网络、数据库……这些东西看起来离日常搬砖很远，补它们是不是纯属浪费时间？

我想了挺久，结论很明确：有必要，但要挑重点。

一句话说清理由：基础薄的人用 AI，很容易被它牵着走，分不清它什么时候在认真干活、什么时候在一本正经地胡说。

AI 确实会写代码，但它不替你做这几件事：

判断代码好坏。同一个需求有十种写法，能跑只是及格线，哪种更清晰、更好维护、更不容易埋坑，得你来拍板。

定位性能瓶颈。线上慢了一截，AI 给不出现场，它只能猜；真正缩小范围、找到那个拖后腿的环节，靠的是你对系统运转方式的直觉。

设计系统边界。模块怎么切、数据往哪放、哪里该解耦，这是判断题不是填空题，AI 帮不上太多。

读懂报错堆栈。一长串 stack trace 糊到脸上，能一眼看出问题出在哪一层，是省时间的硬功夫。

这几件事，全都吃基础。基础扎实的人，是把 AI 当一个干活很快但需要盯着的助手；基础薄的人，则容易把 AI 的输出当圣旨——它对的时候你抄得很爽，它错的时候你根本看不出来，还会理直气壮地把 bug 带上线。AI 写得越多，这道分水岭就越明显。

补基础不等于从头重读一遍大学课程。对我们这种半路出身的人来说，时间有限，得挑回报最高的补。我的优先级是这样的：

数据结构与算法基础——数组、哈希、树、图，加上基本的复杂度分析。这是回报最快的一块：读懂别人的代码、应付面试、判断 AI 给的方案是不是合理，都直接靠它。它不让你去手撕红黑树，而是让你看一段代码就知道它大概多快、会不会爆。
操作系统 + 网络——进程与线程、内存是怎么回事，TCP 和 HTTP 又是怎么跑的。这部分给你的是排查线上问题的底层直觉。为什么这个请求卡住了、为什么内存一直涨、为什么连接偶尔断——没有这层垫底，你只能瞎试。
数据库原理——索引、事务、执行计划。只要你做后端，这关就绕不过去。一条慢查询背后到底发生了什么，索引为什么没走上，事务为什么互相卡住，搞懂了能省下大量抓瞎的时间。
编译原理、分布式——这两块按需再补。用不到的时候不必硬啃，真撞上了（比如要搭一套多节点的服务）再回来补对应部分，反而学得进去。

我踩过的最大的坑，就是想正襟危坐地从第一页啃起，结果啃两章就放弃了。

更实际的做法是：结合手头的工作，遇到问题再回头补对应章节。 我现在主要写 Vue、做全栈，那就让真实问题来牵引——调优的时候顺手把索引学了，排查页面卡顿的时候顺手把事件循环搞明白。带着具体问题去看，知识是「长」在你身上的，比凭空背诵牢得多。

材料上，我更推荐这两类，都比大学教材好上手：

《Designing Data-Intensive Applications》（DDIA）——讲数据系统怎么设计，把数据库、分布式那些抽象概念落到了真实工程场景里。
MIT 的实战向公开课——比如 6.S081（操作系统）、6.824（分布式），都是动手做的路子，跟着写一遍，比看十遍理论都管用。

所以回到开头那个纠结：AI 都会写代码了，还补不补基础？

补。而且恰恰因为 AI 会写了，才更得补——AI 替你写得越多，你越需要看得懂它写的到底对不对。