AI 终结的是软件开发,终结不了的是计算机科学

用 AI 生成一个 CRUD 接口，五分钟。写一个数据处理脚本，十分钟。接入一个第三方 API，根据文档描述，让 AI 一气呵成，几乎不需要自己动手。这些事情，我以前要花半天到一天。

有人说这叫效率提升。也有人开始想：如果这些都可以被替代，那我究竟是在做什么？

我认为，这个困惑背后有一个根本性的误解——很多人把”软件开发”和”计算机科学”混为一谈了。

软件开发和计算机科学，是两件不同的事

软件开发是什么？粗略地说，是用已有的工具、框架、语言，按照已知的模式，把一个业务需求转化成可运行的代码。

绝大多数工程师的日常工作，都在这个范畴里。写 API、接数据库、做界面交互、对接第三方服务。这些工作有技巧，有经验含量，但它的核心逻辑是在一个已被充分定义的空间里做填充。

AI 非常擅长这件事。

它见过几乎所有主流语言的海量代码，见过各种框架的用法，见过无数的设计模式和架构实践。当你描述一个需求，它能快速在这个庞大的知识空间里找到匹配的解法，然后组合输出。这不是投机取巧，这是它真实的能力上限——也是它的工作机制决定的强项。

计算机科学是什么？是研究计算本身——什么问题可以被计算，怎么设计更高效的计算方式，怎么构建支撑计算的基础设施。

具体来说，是编译器、解释器、操作系统内核、处理器体系结构、新的算法范式、新的编程语言设计。这些工作的特点是：它们在创造新的可能性，而不是在已有的可能性里做选择。

这里有一个关键的区别。

AI 处理的是”人类已经充分探索过的知识空间”。它的能力来自于对大量已有内容的学习和归纳。在这个空间里，它可以做得极好，甚至超过大多数人类工程师。

但计算机科学的前沿，恰恰是那些还没有被充分定义的空间。设计一个全新的指令集架构，探索一个尚未被证明的算法方向，提出一个新的系统抽象模型——这些事情，AI 可以辅助，但推动边界的那一步，依然需要人。

国内 CS 教育，把人培养去了哪里

这里有一个让我一直觉得可惜的问题。

国内计算机科学的教育，投入了大量的资源，培养了大量的学生，但最终的去向，绝大多数是业务开发岗——写 CRUD，做前端页面，对接接口，维护微服务。

这当然有现实的理由。市场需要这些工作，这些工作有薪资，毕业生需要就业。但如果我们拉长视角看，这件事有一种结构性的错位：CS 的教育，最后生产的是软件开发的劳动力。

编译原理，大家都考过。词法分析、语法树、中间代码生成，考试周背一背，考完了，基本忘干净了。真正手写过一个完整编译器的人，少之又少。

操作系统，大家都学过。进程调度、内存管理、文件系统，理论讲得头头是道，但真正进过内核代码库、亲手改过哪怕一行调度逻辑的人，少之又少。

体系结构，大家都上过。流水线、缓存层次、指令集，PPT 看过一遍，考卷做过一张，然后进入工作，再也没有用过。

这些知识，才是 CS 这个学科真正的核心。它们是构建整个软件世界的地基。但我们培养出来的大多数工程师，从来没有真正触碰过这个地基。

现在 AI 来了，把地基之上的那些业务逻辑都自动化了，大家突然发现，自己熟悉的那一层消失了。

但地基还在。而且，比以往任何时候都更需要人去建设。

鸿蒙：一次值得认真看待的工程实践

鸿蒙系统在网上争议很多。套壳、吹水、换皮，各种说法都有，我不打算在这里评判这些争论。

但有一件事，我觉得值得认真说：在驱动层和内核层做开发，本身就是一件极其非凡的工程实践，不管动机是什么。

内核开发不是写业务代码。内核里没有框架兜底，没有垃圾回收，没有友好的报错信息。你在直接操作硬件资源，直接管理内存，直接控制进程调度。一个指针错误可以导致整个系统崩溃，一个内存泄漏可以让设备慢慢死去，而你甚至没有清晰的报错信息告诉你问题出在哪里。

驱动开发也是如此。你需要理解硬件的通信协议，理解中断处理，理解 DMA，理解各种硬件寄存器的时序要求。这些东西，不是靠搜索文档就能搞定的，需要真正深入到系统底层去理解。

即便有人质疑鸿蒙的架构决策，但一个工程师如果真正参与过内核或驱动的开发，他对计算机系统的理解，会和只做过业务开发的工程师，有本质的不同。这种理解，是 AI 生成不了的，也是看文档学不到的。

抄，也比没抄强。照着 Linux 抄一遍内核，你对操作系统的理解会突飞猛进。照着 LLVM 抄一遍编译器前端，你对语言设计的理解会焕然一新。动手做这件事本身，就有价值。

抄不是问题，抄完之后有没有更好的理解才是问题

前段时间，Claude Code 的内部系统提示被逆向分析出来，随后大量 AI coding agent 如雨后春笋般冒出来。每隔几天就有一个新的开源项目，号称复现了某某功能，架构几乎一模一样。

我觉得这件事本身没有什么问题。学习、借鉴、参考，这是工程界的正常传统。没有人从零发明所有东西。Linux 借鉴了 Unix，Git 借鉴了 BitKeeper，很多优秀的系统都站在前人的工作上。

但我想问一个问题，这个问题很少有人提：在复现了基本架构之后，然后呢？

Agent 的工具调用机制，大家都照着做了。上下文管理的策略，大家都参考了。任务规划的逻辑，大家都抄了一遍。然后？继续抄下一个流行项目，继续追下一个热点？

还是说，有没有人停下来，认真思考：这个架构有什么问题？这个设计里有哪些取舍是值得质疑的？有没有更好的方式来解决同样的问题？

从抄到理解，从理解到质疑，从质疑到创新——这条路，每走一步都需要更深的 CS 基础。工具调用的底层是什么？上下文管理的根本约束是什么？任务规划的形式化表述是什么？这些问题，不是用工程技巧能回答的，需要真正的计算机科学训练。

现在这个领域发展很快，大量的基础性问题还没有被好好研究。Agent 的可靠性、可组合性、形式化验证——这些都是真实的研究方向，不是工程问题，是 CS 问题。而且，和业务开发不同，这些地方 AI 自己还在摸索边界，没有现成的答案可以给你。

编程语言，是为谁设计的？

我们今天用的编程语言——Python、Java、Go、Rust——都是人类为自己设计的。

语法要能被人读懂，命名要对人有意义，报错要能让人理解，调试要让人能逐步追踪。这些设计目标，几十年来都理所当然地以”人类工程师的认知习惯”为中心。

编程语言没有一个”最好的”。如果有，就不会同时存在几十种主流语言了。每一种语言都是一套取舍，在表达力、性能、安全性、可读性之间寻找平衡。不同的场景，不同的团队，最终选择不同的语言，本质上是在选择不同的取舍组合。

但现在有一个问题，平时讨论得不多：这些语言，对 AI 来说也是好的吗？

AI 写代码，不是在”理解语义然后表达”，而是在预测 token 序列。它处理的是语言的表面形式——字符、缩进、括号、关键字。人类觉得 Python 简洁优雅，是因为它接近自然语言的表达习惯。但对 AI 来说，Python 的缩进敏感语法、动态类型、大量的隐式约定，究竟是更容易预测，还是更难？

更进一步的问题是：有没有可能设计一种语言，专门让 AI 能更高效、更省 token 地工作？

这不是一个荒诞的问题。已经有人在做类似的实验——用更结构化、更形式化的 DSL 让 AI 生成代码，减少歧义，减少需要推断的上下文量。但这个方向还远没有成熟，更没有形成体系。

还有一个更激进的想法：编译器，是否可以针对 AI 优化？

今天的编译器，把人类可读的源代码翻译成机器可执行的指令。但这个”人类可读”的中间形式，对 AI 来说可能根本不是最优的。比如，AI 是否可以直接读写 Java 字节码，跳过源代码这一层，直接操作已经经过语义分析的中间表示？字节码比源代码信息密度更高，结构更规整，歧义更少——理论上，AI 在这个层次上操作，可能更准确，也更高效。

当然，这一切目前还在探索期，没有固定的答案，甚至没有足够多的人在认真研究。

但这恰恰说明：这是一个真实的前沿。不是有人把问题解决了然后等着你来学，而是问题本身还没有被好好定义，解法还没有出现，方向还没有被充分探索。

这才是 CS 应该做的事情。

前沿，始终需要人去推进

有人可能会说：AI 发展这么快，说不定再过几年，它自己就能做原创研究了。

这个可能性不能完全排除。但有一件事是确定的：在那个时刻到来之前，前沿依然需要人去推。

而且，这个”前沿”本身会一直移动。AI 掌握了今天的前沿，明天的前沿就已经在更深处了。这不是悲观，这是科学进步的本质。每一次工具变强，人类能够触达的边界就更远，而边界之外的未知也更大。

AI 的出现，其实是一次重新分配注意力的机会。

以前，工程师的大量精力花在”把已知的模式转化成代码”上——这件事有价值，但不是最稀缺的价值。现在 AI 接管了这一层，工程师的注意力可以被解放出来，去做更深的事：理解系统，设计系统，推动系统向前。

这要求的，恰恰是那些被大多数人在学校里学了又忘掉的东西：编译器、内核、体系结构、算法理论。

不是每个人都需要成为这些领域的专家。但如果你是 CS 出身，如果你打算在这个行业做二十年，那么你应该认真问自己一个问题：我对这个行业的贡献，是在已有的空间里做填充，还是在推动边界向前移？

前者，AI 做得越来越好了。后者，只要你选择走这条路，AI 帮不了你，也替代不了你。

这不是在呼吁所有工程师转去做系统研究。现实的职业选择有太多维度，没有那么非此即彼。

但我认为，整个行业需要更多选择往深处走的人。不是因为这条路安全，而是因为这条路，是真正意义上的 CS 工程师应该去的地方。

AI 会继续变强，会吃掉越来越多的软件开发工作。

而那个造 AI、改 AI、让 AI 变得更强的人，需要的是计算机科学，不是软件开发技能。

如果你觉得这篇文章对你有帮助，欢迎转发点赞收藏。

转载请注明出处，谢谢。