AI 编程不是公平的加速器,它正在创造新的认知阶层
当资深工程师还在争论 AI 能不能取代自己时,一批聪明的年轻人已经利用 AI 工具在复杂代码库中完成‘蛙跳’。这不再是一个关于‘工具好不好用’的问题,而是一个关于‘谁能在新时代重新定义自己的思维模式’的生存游戏。
核心观点:AI 编程工具带来的真正变革不是效率提升,而是它正在把开发者分成‘用 AI 思考的人’和‘用 AI 逃避思考的人’,而后者将在这场认知分化中迅速贬值。
过去几个月里,技术社区最热闹的争论始终围绕一个主题:AI 编程工具到底能不能替代人类开发者。但如果你仔细看过那些真正在动手的人——那些已经在 GitHub 上分享自己用 AI 重构项目的独立开发者,那些在 Reddit 上诚实地分享自己从 Electron 迁移到 Flutter 的工程师,以及在 Sequoia 峰会上剖析 LLM 能力的创业者——你会意识到,这场争论的双方都问错了问题。
真正的问题不是 AI 会不会取代你,而是你会不会在 AI 时代变成一个‘假装在思考’的人。这不是一个关于效率或恐惧的议题,而是一个关于认知分化的社会学命题。
我们先来看一个被大量讨论但几乎无人真正理解的案例。一位有七年经验的科技从业者在自己的帖子里分享了一个观察:他说自己在用 AI 构建产品时发现,团队里最有效率的不是那些最资深的人,而是那些愿意把 AI 当作‘思维外挂’的年轻人。这些年轻人不是用 AI 来写 CRUD,而是用 AI 来验证自己的假设,快速生成原型,甚至在 AI 的辅助下学习那些他们从未接触过的技术栈。相比之下,那些资深工程师更倾向于把 AI 当作一个‘更智能的自动补全工具’,他们依然用手动的方式编写核心逻辑,只在最后用 AI 来检查错误或者完成重复性工作。这个差异看似微小,但在实际产出的维度上,差距是指数级的。
这并不是年轻人的天赋异禀,而是他们没有被过去的成功经验所绑架。一个工作了十年的工程师,他的大脑已经内化了一套完整的开发流程:需求分析、架构设计、编码、测试、部署。对他来说,AI 只是一个可以加速其中某个环节的工具。但对于一个刚入行的年轻人来说,他没有这套既定的心智模型,他可以坦然地让 AI 承担起从理解需求到生成代码的‘前端’工作,自己则专注于更高层次的思考和决策。这种心态差异,比任何技术差距都更致命。
有人可能会反驳:这不是真正的能力,这是‘AI 依赖症’,一旦离开工具他们就会崩溃。这种批评听起来很有道理,但它忽略了一个关键的现实:AI 工具本身正在成为基础设施的一部分。就像今天没有人会批评一个使用 IDE 而不是记事本写代码的开发者‘依赖工具’一样,在未来,不会使用 AI 来加速思考的人,就像今天不会使用搜索引擎的人一样,不是更有能力,而是更有效率上的劣势。
更值得关注的是,这种分化正在以比我们想象中更快的速度发生。在 Reddit 的另一个讨论中,一位开发者在考虑是否要从 Electron 迁移到 Flutter 时,他的决策方式本身就说明了问题。他不是像过去那样阅读几十篇博客、看几个教程、做几个小项目来评估,而是直接让 Gemini 做了一个‘深度研究’,生成了详细的对比报告。然后他根据这份报告决定暂时留在 Electron,原因不是 Flutter 不好,而是‘我需要先确认 Flutter 没有太多让我踩坑的地方’。这是一种完全不同的决策模式:他不再把自己当作知识的积累者,而是把自己当作信息的决策者。AI 帮他完成了信息收集和初步分析,他把精力放在了对结论的批判性评估上。这才是所谓的‘用 AI 思考’——你依然是思考的主体,但你不再需要从零开始。
但这还不是最有趣的部分。在 Sequoia Ascent 2026 的炉边谈话中,一个观点让我意识到这种认知分化的另一层含义。发言者提到,LLM 的真正价值不仅仅是加速已有的工作,而是创造了全新的可能性。他举了三个例子:‘menugen’——一个完全由 LLM 驱动的应用,输入一张图片,输出一张图片,整个过程不需要任何传统代码;‘install.md’——用自然语言描述安装过程,让 LLM 去执行,而不是编写复杂的 bash 脚本;以及‘LLM 知识库’——一种用传统代码几乎不可能实现的功能,因为它需要对非结构化的知识进行实时计算。
这些例子的共同点是什么?它们都在挑战一个根深蒂固的假设:好的软件必须是精确的、可重复的、确定的。但 LLM 的能力恰恰在于处理模糊、不确定、上下文相关的任务。这意味着,那些习惯于‘写死一切’的开发者,会发现自己的技能树在 AI 时代突然变得不再适用。而那些愿意接受‘不确定性’、擅长与模糊性共舞的人,则找到了全新的发力点。
这让我想起了另一个来自独立开发者的故事。他开发了一个‘vibe coded dispute responder’——一个用 AI 自动生成的、用于应对 Stripe 争议的工具结果。他提到,自己过去十年几乎每次争议都会输,因为他不愿意花时间去整理证据。但自从他用 AI 写了一个自动收集用户活动证据、生成详细 PDF 的工具后,他开始赢得争议了。这个故事表面上是个‘AI 帮我省力’的例子,但真正的关键点是:他找到了一种方式,让 AI 去完成那些他‘知道该怎么做但不愿意做’的事情。这背后是一种对自身效率和 AI 能力的精准评估——他知道自己的精力应该花在什么地方,也知道什么地方可以放心交给 AI。
这种‘元认知’能力,恰恰是当前大多数资深开发者所缺乏的。他们已经习惯了在自己的舒适区里高效运转,以至于他们不再去思考:哪些事情其实不需要我来做?哪些事情只有我能做?而 AI 的存在,恰恰让这个问题变得无法回避。
如果我们可以做一个大胆的预测,那么未来两三年内,技术行业会出现一个明显的‘认知阶层分化’。在顶层,是一群能够与 AI 协作、把 AI 当作思维延展的‘AI 原生思考者’;在底层,是一群依然把 AI 当作效率工具、拒绝改变自己工作方式的‘AI 工具实用主义者’。这种分化的速度会比任何人想象的都要快,因为它不依赖于技术突破,只依赖于人的心态转变。
当然,这个观点也面临一个强有力的反驳:那些‘用 AI 思考’的人,真的比‘用 AI 逃避思考’的人更高效吗?有没有可能,前者只是在自欺欺人,他们以为自己是在做高层次决策,实际上只是在被 AI 牵着鼻子走?这是一个公平的质疑。事实上,在 Sequoia 的谈话中,发言者也承认,LLM 的能力是‘锯齿状’的——它可以在某些领域表现出惊人的能力,同时在其他领域犯下愚蠢的错误。如果开发者过度依赖 AI,他们可能会丧失对细节的敏感性,最终在关键时刻犯错。
但这种风险本身并不是反对‘用 AI 思考’的理由,而是提醒我们需要更审慎地使用 AI。一个真正优秀的 AI 原生思考者,不是盲目接受 AI 的输出,而是学会判断 AI 的‘锯齿边界’。他们知道什么时候该信任 AI,什么时候该质疑 AI。这种判断力本身,就是一种需要刻意练习的能力。
回到最开始的问题:AI 编程工具到底是福是祸?答案既不在于工具本身,也不在于你是否使用它,而在于你如何使用它。如果你只是把 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