AI 正在制造一种新的“数字文盲”
当 AI 编码工具让“写出代码”变得前所未有的容易时,一个危险的悖论出现了:那些用它加速思考的人正在创造全新的工作范式,而那些用它替代思考的人,正在丧失最基本的判断力。
核心观点:AI 的真正分水岭不是谁在用、谁不用,而是用 AI 思考的人和用 AI 逃避思考的人之间的差距正在急速拉大,而后者正在被无声地抛下。
这几年关于 AI 的讨论,从最初的“AI 会不会取代我的工作”,到后来的“AI 能帮我做什么”,再到现在的“AI 让我变得更强了吗”,话题不断翻新,但有一个核心问题始终没有被认真对待:AI 究竟是在拓宽人的能力边界,还是在悄悄收窄它?
我不是在说技术悲观主义那一套。我亲眼见过,也亲手用过那些令人惊叹的 AI 工具。GitHub Copilot 让我写后端逻辑的速度提升了至少两倍,ChatGPT 帮我梳理过几十页的 API 文档。但正是在这种“效率狂欢”中,我注意到一个令人不安的分化正在发生:同样是用 AI,有些人用它来撬动自己认知的盲区,而另一些人则用它来为自己本应负责的任务铺上一层“完成了”的假象。
这个观察并非空穴来风。最近 Reddit 上一个在科技行业工作七年的开发者分享了他的洞察,他认为真正的分界线不是“AI 是否取代你”,而是“你是否在用 AI 思考”。他举了一个例子:他的团队里有个刚毕业的实习生,用 AI 在三天内重构了一个遗留的老模块,代码质量甚至超过了团队里一位干了五年的高级工程师。但问题在于,那个高级工程师虽然写代码慢,但他知道每一个函数为什么这么设计,边界条件在哪里,而那个实习生在被问到“为什么这里要用递归而不是迭代”时,沉默了。
这不是个例。我在过去几个月里观察了至少十几个类似的场景。AI 让“产出”变得廉价,但让“理解”变得可有可无。更致命的是,这种“可有可无”正在被包装成一种新的能力:所谓“prompt engineering”的流行,本质上是在训练人们如何向机器提问,而不是训练他们如何自己思考。当一个开发者把大部分认知负担外包给语言模型时,他其实是在用“熟练度”置换“深度”。
当然,反对者会说:这不就是工具演进的自然结果吗?计算器出现的时候,不也有人哀叹人类的心算能力会退化?但这里的根本区别在于,计算器处理的是数学运算,那是逻辑链条中可以被明确封装的一环,而 AI 工具处理的是语义理解和模式匹配,这是人类认知中最核心、最不可替代的部分。你把核心认知过程外包出去,久而久之,你就不再拥有它。
我承认,这个观点听起来有些危言耸听。毕竟 AI 也在帮我们做很多之前做不到的事。比如 Andrej Karpathy 最近在一次闭门分享中提到的“menugen”概念——一个完全由 LLM 驱动的应用,不需要一行传统代码,输入图像,输出图像,所有逻辑都由模型完成。这确实令人兴奋,它打开了一个全新的可能性空间。但问题是:当所有人都能“生成”一个应用时,谁还真正理解这个应用在做什么?谁还能在模型出错时干预它?
更现实的矛盾在于,经济系统正在加剧这种分化。当一家公司发现,一个会用 AI 的初级开发者可以完成一个高级开发者 80% 的工作量时,它会毫不犹豫地选择前者。但那个高级开发者的价值恰恰在于那 20%——处理极端情况、识别系统风险、做出架构决策。而这些能力,恰恰是 AI 最难替代,也最容易被初学者忽略的。
我并不是要指责那些选择“用 AI 偷懒”的人。生存压力下,每个人都会选择最省力的路径。但我们必须意识到,这种选择是有代价的。当一个行业里越来越多的人依赖 AI 来完成原本需要深度理解才能完成的工作时,这个行业的整体认知水位就在下降。而更可怕的是,这种下降是无声的、渐进的,只有当某个关键系统崩溃时,人们才会发现:原来我们已经没人知道它为什么这么工作了。
在我看来,真正明智的做法不是拒绝 AI,而是主动设计自己的使用方式,确保每一次与 AI 的交互都是一次认知的扩展,而不是替代。比如,让 AI 生成一个函数的多个实现方案,然后自己去分析优劣;或者让 AI 解释一段复杂代码的原理,然后自己去重构它。关键是要保持一种“认知上的紧张感”——永远知道自己在做什么,以及为什么这么做。
这不是一个技术问题,这是一个教育问题,也是一个文化问题。如果我们继续把“能写出 AI 生成的代码”等同于“会编程”,把“能问出好问题”等同于“有深度思考”,那么不出五年,我们会看到一批表面上极其高效、实则认知空洞的“数字文盲”充斥整个行业。他们可以生成任何东西,但理解不了任何东西。
如果把这个判断再往前推一步,真正重要的不是 Has anyone switched…、7 years in tech, no…、Fireside chat at Se… 本身,而是它们共同暴露出的分配逻辑。 reddit、x 在同一轮里把注意力推向同一问题,通常意味着这个主题正在从圈层内部经验,转向更可共享的公共议题。 这也是为什么这种内容值得写成长文:短帖只负责提醒你“这里有事发生”,但只有长文才能把背景、代价、误判空间和后续影响放到同一张桌面上。 换句话说,AI 的真正分水岭不是谁在用、谁不用,而是用 AI 思考的人和用 AI 逃避思考的人之间的差距正在急速拉大,而后者正在被无声地抛下。 之所以重要,不是因为它看上去新,而是因为它会重新定义用户接下来应该如何理解这一类内容。
当然,这个判断仍然有边界。技术 领域的很多内容天生带有夸张表达、圈层黑话和强情绪包装, 这意味着原始材料本身未必可靠,甚至会故意放大戏剧性。 所以这里真正需要辨认的,不是表层标题是否足够抓人,而是标题下面有没有重复出现的结构:问题是否反复被提到,解决路径是否开始稳定, 以及不同来源是否在无意中指向相同结论。只有这些条件同时成立时,AI 的真正分水岭不是谁在用、谁不用,而是用 AI 思考的人和用 AI 逃避思考的人之间的差距正在急速拉大,而后者正在被无声地抛下。 才算站得住。否则,它最多只能算一个值得观察的苗头,而不是已经完成的判断。
参考来源
- Has anyone switched from Electron to Flutter? Here is what I am considering. - https://www.reddit.com/r/electronjs/comments/1t0xejh/has_anyone_switched_from_electron_to_flutter_here/
- 7 years in tech, now building AI products on the side. What I actually see happening and honest take for freshers navigating this mess - https://www.reddit.com/r/developersIndia/comments/1t0ig0f/7_years_in_tech_now_building_ai_products_on_the/
- Fireside chat at Sequoia Ascent 2026 from a ~week ago. Some highlights:
- The first theme I tried to push on is that LLMs are about a lot more than just speeding up what existed before (e.g. coding). Three examples of new horizons:
- 1. menugen: an app that can be fully engulfed by LLMs, with no classical code needed: input an image, output an image and an LLM can natively do the thing.
- 2. install .md skills instead of install .sh scripts. Why create a complex Software 1.0 bash script for e.g. installing a piece of software if you can write the installation out in words and say "just show this to your LLM". The LLM is an advanced interpreter of English and can intelligently target installation to your setup, debug everything inline, etc.
- 3. LLM knowledge bases as an example of something that was *impossible* with classical code because it's computation over unstructured data (knowledge) from arbitrary sources and in arbitrary formats, including simply text articles etc.
- I pushed on these because in every new paradigm change, the obvious things are always in the realm of speeding up or somehow improving what existed, but here we have examples of functionality that either suddenly perhaps shouldn't even exist (1,2), or was fundamentally not possible before (3).
- The second (ongoing) theme is trying to explain the pattern of jaggedness in LLMs. How it can be true that a single artifact will simultaneously 1) coherently refactor a 100,000-line code base *and* 2) tell you to walk to the car wash to wash your car. I previously wrote about the source of this as having to do with verifiability of a domain, here I expand on this as having to also do with economics because revenue/TAM dictates what the frontier labs choose to package into training data distributions during RL. You're either in the data distribution (on the rails of the RL circuits) and flying or you're off-roading in the jungle with a machete, in relative terms. Still not 100% satisfied with this, but it's an ongoing struggle to build an accurate model of LLM capabilities if you wish to practically take advantage of their power while avoiding their pitfalls, which brings me to...
- Last theme is the agent-native economy. The decomposition of products and services into sensors, actuators and logic (split up across all of 1.0/2.0/3.0 computing paradigms), how we can make information maximally legible to LLMs, some words on the quickly emerging agentic engineering and its skill set, related hiring practices, etc., possibly even hints/dreams of fully neural computing handling the vast majority of computation with some help from (classical) CPU coprocessors. - https://nitter.net/karpathy/status/2049903821095354523#m