
最近,Hacker News 上有一篇关于“AI与理解力”的帖子火了,斩获 450+ 赞和 300 多条硬核评论。评论区里,许多资深程序员坦承了一个隐秘的焦虑:随着深度依赖 Copilot 和 Cursor,自己从零开始纯手写代码的能力似乎正在退化。
大家都在担心 AI 会让人“不知不觉地失去理解能力”。但这究竟是危言耸听,还是技术演进的必然?这篇文章里的一个思想实验,或许能给我们提供一个全新的技术演进视角。
假设有两个同一年入学的计算机方向博士生,小 A 和小 B,研究同一个底层系统方向。
一年后,两人交出了质量相当的论文和开源项目。答辩表现差不多,GitHub 上的 Star 数也差不多。
但内部状态有一个致命的不同:小 A 真正理解了系统。小 B 不理解。
小 A 知道为什么锁的粒度要这么设计,知道极端高并发下哪里的缓存会击穿。而小 B 不知道,他只知道 AI 给了他一坨跑得通的代码,并且测试用例都亮了绿灯。
这不是空想。帖子里举了一个真实的物理学界案例:资深物理学家 Schwartz 让 Claude 写了一篇物理论文。排版精美、公式严谨、引用详实,外行看来无懈可击。但 Schwartz 凭借几十年的学术直觉,一眼看穿了里面虚构的常数和拼凑的推导逻辑。
这引出了当前 AI 辅助开发中最大的悖论:你需要先成为资深专家(Senior),才能安全地使用 AI;但如果所有初级工作(Junior)都被 AI 做了,未来谁来填补专家的断层?
《沙丘》作者 Frank Herbert 曾写过一句话:
“我们能在不思考的情况下做的事情越多,真正的危险就越大。”
这也是 HN 上开发者们焦虑的根源。威胁不是 AI 突然在生产环境删库跑路,而是一个安静、隐蔽、像温水煮青蛙一样的过程——我们习惯了不去问“为什么”,习惯了直接 Tab 键接受代码。
原文的推导逻辑是:AI 让人跳过基础训练 → 失去深层理解 → 因此我们必须回归传统路径。
我认同前半句,但反对后半句。真实世界并不是只有“受苦的小 A”和“偷懒的小 B”。
假设还有个小 C。他和小 B 一样用 AI 生成代码,但他不是“跑通了就行”。他让 AI 给出了 5 种不同的并发控制方案,然后自己深入去 Review 每一套方案:判断哪种 I/O 消耗最小、哪种在分布式场景下会发生死锁、哪种违背了业务的最终一致性。
在同样的时间里,小 A 手写了一套完整的系统;而小 C 借助 AI,阅读并审查了十套不同的系统架构,见识了十倍的错误模式。
小 C 同样在积累技术直觉,只不过他不再通过“手敲键盘”来积累,而是通过**“海量 Code Review”**来积累。他的核心动作不再是“写(Write)”,而是“判别(Judge)”。
在 AI 出现之前,“会敲代码”和“理解业务/系统”是强绑定的。你不懂 C++ 语法,就无法验证你的架构设计。所以,“写代码”成了理解问题的前提门槛。
但平心而论,以前那些熟练背诵 API 和设计模式的“大牛”中,有多少人是真的具备顶层设计能力,又有多少人只是熟练掌握了特定的手工执行流程?
AI 把这层绑定解开了。
当手工写 CRUD、写样板代码不再是门槛时,真正的技术壁垒就赤裸裸地暴露出来了:
这些能力,以前被“会写代码”、“会配环境”这些体力活儿掩盖了,现在掩盖不住了。
很多人担心 AI 会让所有开发者都变成小 B,丧失核心竞争力。但现实往往更加残酷:AI 不会让人变蠢,它只会让一部分人变得更强,让另一部分人原形毕露。
有些人会把一切交给 AI,舒舒服服地停止思考,沦为 AI 的操作员;
而有些人会借助 AI 从繁琐的重复劳动中解放出来,去思考系统可用性、去攻克真正的核心难题。他们会成为真正意义上的技术专家。
在这个门槛被抹平的时代,AI 是一面最残酷的镜子。它照出的不是你会写多少种语言,而是离开键盘后,你脑子里还剩下多少真正的系统性思考。
参考文献与扩展阅读:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。