导语

2025 年初，Andrej Karpathy 在 X 上定义了一个词——Vibe Coding："完全交给 vibes，拥抱指数级增长，忘记代码的存在。"他用语音输入加上 Cursor Composer 与 Claude Sonnet 协作，"Accept All"不读 diff，代码超出自己理解范围。这个定义专门标注了适用场景：throwaway weekend projects。

一年后，这个词被 Collins Dictionary 评为 2025 年度词汇。Y Combinator W25 批次 25% 的创业公司代码库 95% 由 AI 生成。Vibe Coding 从周末实验变成了产业现实。

与此同时，另一条叙事线在英文科技世界悄悄展开：用 AI 写代码的人，开始报告一种新类型的疲惫。不是传统意义上"加班太久"的 burnout，而是一种此前在编程工作中几乎不曾出现的认知消耗。

Andrew Ng 在 LangChain Interrupt 会议（2025 年 6 月）说了两句话，一句承认疲惫——“When I’m coding for a day with AI coding assistance, I’m frankly exhausted by the end of the day”；另一句拒绝放弃——“My teams and I just hate to ever have to code again without AI assistance.”

这两句话同时成立，本身就是问题所在。

过去 8 个月（2025 年 9 月至 2026 年 5 月），围绕"AI 编程让人类更累"的实证研究、一手证言和理论框架密集出现。核心问题：AI 编程到底让开发者更累了，还是更轻松了？如果更累了，"累"的机制是什么？

第 1 章 Vibe Coding 的词源与语义扩散

1.1 Karpathy 的原始定义

2025 年 2 月 2 日，Karpathy 在 X 上写了一段后来被引用数百次的定义：

I call it “vibe coding”—where you fully give in to the vibes, embrace exponentials, and forget that the code even exists… I just Accept All, I do not even read the diffs anymore.

他同时声明这种做法只适合一次性项目。但在传播过程中，这个限定条件被大量引用者忽略了。Karpathy 2023 年的先导声明——“The hottest new programming language is English”——为 vibe coding 提供了思想基础：LLM 的能力足以让人类不再需要学习特定编程语言。

1.2 语义扩散速度

Vibe Coding 的传播速度超出大多数技术概念的正常扩散周期：

2025-03-08：Merriam-Webster 列为 trending 词汇
2025-11-06：Collins Dictionary 评为年度词汇
2025-03-06：TechCrunch 报道 YC W25 批次 25% 公司代码库 95% AI 生成
2026-01-12：Linus Torvalds 在 README 中承认用了 vibe coding 来写 Python 可视化工具

中文翻译尚无统一译名。中文维基百科记录了"气氛编程"和"氛围编程"两种译法。财联社 2025 年 12 月报道"谷歌下注’氛围编程’“，彭博商周中文版译为"气氛编程”。台湾《数位时代》做了入门解读。

1.3 Simon Willison 的分界线

Ars Technica（2025 年 3 月）引用了 Simon Willison 的关键区分：

If an LLM wrote every line, but you’ve reviewed, tested, and understood it all, that’s not vibe coding—that’s using an LLM as a typing assistant.

Vibe Coding 的边界不是"是否用了 AI"，而是"是否审查并理解了 AI 产出"。这条分界线在 2026 年开始模糊——Willison 自己在 2026 年 5 月承认：“As the coding agents get more reliable, I’m not reviewing every line of code that they write anymore, even for my production level stuff.”

第 2 章 "更累"的五层机制

2.1 审查负担：瓶颈从"写"移到"审"

AI 工具一次生成 200-500 行代码，开发者需要从零重建心智模型来审查。Jorge Raad（前谷歌工程师）在 Substack 上描述了 “vibe coding fatigue” 的症状清单：在陌生代码中花更多时间调试、淹没在 AI 生成的 PR 中、无法进入节奏（持续 context-switch）、发现代码质量通过无数微小妥协逐渐衰退。

他用了"TikTok 化"的比喻：coding workflow 变成"滑到下一个任务、快速审查、合并、重复"——和刷短视频一样，每个单元都觉得在做事，但连起来看什么也没沉淀。

Atomic Robot 的文章将问题命名为"vibe coding hangover"：AI 在几秒内生成 200 行，开发者需逐行审查错误处理、架构模式、竞态条件、正确性。一次性交付所有复杂度，而非渐进构建时自然分摊的认知负荷。

threatmodeling.dev 提出"PR-Fatigue"概念：vibe-coded PR 比传统 PR 涌入更快，开发者开始经历 alert fatigue 的新版本。“现在我们做的所有事情都是阅读——scrutiny，以及日益增长的 exhaustion。”

2.2 认知负荷类型质变：从"创建型"到"评估型"

Tabula Magazine（2025 年 7 月）的一手体验报告描述了这种质变：

AI 以如此速度工作，完成需要接受或审查的东西，感觉我的大脑无法处理或跟上。我需要暂停才能重新开始。作为开发者以前从未有过这种感觉。

以前写代码时，工作记忆自然追踪自己创建的上下文——变量含义、调用关系、设计意图。现在阅读 AI 生成的代码时，这些上下文必须从零重建，且重建的对象可能遵循你不熟悉的设计逻辑。

arXiv 论文 “The Vibe-Check Protocol: Quantifying Cognitive Offloading in AI Programming”（2026-01-02）提出了一个关键区分：初级开发者的语法挣扎和调试过程看似 “extraneous load”（外在负荷），实际上是形成基础心智模型的 “germane load”（必要负荷）。Vibe Coding 在学习阶段应严格限制，否则会剥夺构建编程心智模型的必要挣扎——那些看起来"浪费时间"的试错过程，恰恰是技能生长的土壤。

2.3 决策层级升迁与时间压缩

The Economic Times（2026 年 3 月）采访了多位创始人和工程师。Prasanna Krishnamoorthy（Upekkha）指出：AI 之前开发者做编码级决策，现在做更高层的架构/设计/产品决策——通常是 senior 的工作——且需要在更短时间内做。决策层级升迁加上决策时间压缩，产生了新类型的 burnout。

Kalyan Sivasailam（5C Network）同时跑 5 个 Claude Code + 1 个 Antigravity + 1 个 Codex：“有太多代码被生成，你很容易迷失在构建和验证中。”

Business Insider（2026 年 2 月）报道了一位工程师的主张：vibe coding 在最高速状态下一天只有约 3 小时有效产出。“领导者和管理者需要意识到这一点。”

2.4 多任务切换与 Agent 管理疲劳：“Brain Fry”

BCG + UC Riverside 联合研究（1,488 样本，HBR 2026 年 3 月发表）定义了 “AI brain fry”——过度使用或监督 AI 工具超出认知容量导致的精神疲劳。14% 的受访者报告 mental fog，39% 报告更多重大错误，33% 更多决策疲劳，34% 更高离职倾向。

一位高级工程经理的描述：

像十几个浏览器标签页在脑子里打架。我发现自己反复读同一段内容，比平时更频繁地犹豫，莫名其妙地不耐烦。思维没坏，只是吵——像精神静电。

CNN（2026 年 3 月）进一步区分了 brain fry 与 workslop（认知投降）：brain fry 是过度投入而非放弃——“像与 AI 进行智力对决”。但研究同时发现适度使用 AI（1-3 个工具用于重复任务）反而降低 15% burnout。Brain fry 主要出现在使用 4+ 个 AI 工具的密集监督场景。

Francesco Bonacci（Cua AI CEO）命名了"vibe coding paralysis"：

每天结束时筋疲力尽——不是因为工作本身，而是因为管理工作。6 个 worktree 打开，4 个半完成的功能，2 个"快速修复"变成兔子洞，越来越觉得自己在失控。

BCG 研究的一个意外发现：brain fry 人群反而体验更少 burnout。Kellerman 解释了两者的机制差异——brain fry 是急性体验，休息后消退；burnout 是慢性累积。两者的因果方向尚不明确：是 AI 导致了疲劳，还是疲劳者更倾向于密集使用 AI？

2.5 技能脱节与自我强化循环

Mo Bitar（2026 年 1 月）两年深度 vibe coding 后回归手写，核心发现：Agent 产出的单个变更在隔离状态下看似合理，但整体代码库变成"pure, unadulterated slop"——缺乏对整体结构和邻近模式的尊重。

他的写作比喻比大多数技术类比更精准：

Agent 给我看了一段好几个段落，看起来结构正确语法正确。但读完整章，一团糟。在整本书的上下文中毫无意义。

决定回归时他的伦理底线：“I’m not shipping this shit. I’m not gonna charge users for this. And I’m not going to promise users to protect their data with this.”

评论者 Verdi 提炼了自我强化循环：AI 生成的微妙问题随时间复合成 LLM 本身也难以导航的代码库；同时，开发者丧失了对代码的深层洞察连接——没有 AI 就无法排障。结果：你变成了在飞机或火车上 0% 生产力的开发者。

Armin Ronacher（Flask 创建者、Sentry 初期核心贡献者）2026 年 1 月发表 “Agent Psychosis”，自述被 Claude 钩住后的两个月："I did not sleep. I spent two months excessively prompting the thing and wasting tokens… I ended up building a ton of tools I did not end up using much."他用凌晨 3 点的画面结尾：“I don’t see productivity. I see someone who might need to step away from the machine for a bit.”

TechSpot（2026 年 5 月）报道了程序员被迫 vibe coding 后技能退化的问题。The New Stack 命名了"认知漂移"（cognitive drift）：心智模型落后于代码库现实。“认知负债”= 嵌入习惯和假设中的技术债务。

第 3 章 Dark Flow：一个心理学解释框架

fast.ai（Rachel Thomas，2026 年 1 月 28 日）将 vibe coding 类比为赌博的 “dark flow” 和 “junk flow”，提供了目前最系统的心理学解释框架。

3.1 Csikszentmihalyi 的 Flow 与 Junk Flow

Csikszentmihalyi 的 flow 理论有两个核心条件：技能与挑战适当匹配、提供清晰的绩效反馈。Optimal flow 出现在高技能加上高挑战的区域——你在做一件能力刚好够但需要全神贯注的事，每一步都能感知到进展或偏差。

Csikszentmihalyi 本人 2014 年在访谈中定义了 “junk flow”：

实际上你在对一种表面体验成瘾，它一开始可能是 flow，但过了一段时间变成你成瘾的东西而非让你成长的东西。问题在于，找到不产生成长但有吸引力和诱惑力的快乐更容易。

3.2 Loss Disguised as a Win

“Dark flow” 来自赌博研究者（Dixon et al., 2017, PMC5846824）。Multiline 老虎机允许 20 行同时运作，下注 20 美分获得 15 美分"credit"——实际损失 5 美分，但机器播放庆祝音效触发正面多巴胺反应。PubMed 同行评审论文证明 LDW 诱导与真实赢钱相似的生理反应，玩家更易进入高度沉浸的 flow-like 状态。

Vibe Coding 的 LDW：大量代码看似产出，实则 slop。几小时后发现 bug，几周后发现架构问题，几个月后发现维护困难——反馈延迟与老虎机的即时庆祝形成对称欺骗。

3.3 三个并行

fast.ai 指出 Vibe Coding 与赌博机制的三个并行：

不提供清晰绩效线索（甚至提供 LDW 式误导）——代码看起来能跑，但跑对了不代表写对了
skill 与 challenge 匹配关系模糊——LLM 替你做了技能部分，你只剩审查部分，但审查不是你想做的挑战
虚假能动感——LLM 给出的选项与程序员自主做的架构决策完全不同，你是在从菜单里选而非自己设计菜单

METR 数据佐证了这个框架：开发者使用 AI 时自估提速 20%，实际减速 19%——感知与实际差距近 40%。这正是 LDW 的欺骗性反馈特征。

第 4 章量化证据

4.1 METR RCT：AI 让经验开发者慢 19%

METR（非营利研究机构）2025 年 7 月发表了一项随机对照试验：16 位经验丰富的开源开发者、246 个真实 issue。使用 AI 工具（主要为 Cursor + Claude 3.5/3.7 Sonnet）比不使用时慢 19%。

开发者事前预期加速 24%，事后仍自认为加速了 20%——主观感受与客观事实方向完全相反，差距约 40%。

适用范围标注：19% 慢仅适用于"经验丰富的维护者在大型已有代码库上使用 early-2025 AI 工具做预选任务"。METR 2026 年 2 月更新数据显示原参与者子集从 -19% 变为 +18% speedup，但因选择偏移严重，METR 明确声明新数据不可信。多位批评者指出 56% 参与者从未用过 Cursor，测试了最不利的情境。

Microsoft/GitHub Copilot 研究（55.8% faster）和 Google 内部研究（21% 提升）测试的是 greenfield 新项目加上清晰规格，与 METR 情境根本不同。两者不可简单对立——AI 工具对开发者速度的影响取决于情境。

但"主观感知与客观事实差距 40%"这一发现在其他情境下是否成立，仍缺乏验证。这是目前最值得追问的数据。

4.2 GitClear：技术债务的量化追踪

2020-2024 年追踪 2.11 亿行代码：代码重构比例从 25% 降至 <10%，代码重复增长约 4 倍，copy-pasted 首次超过 moved code，代码 churn（合并后不久即重写）翻倍。

4.3 CodeRabbit：AI 代码 1.7 倍更多重大问题

分析 470 个 OSS PR：AI co-authored 代码比人写的多 1.7 倍 major issues，安全漏洞 2.74 倍，misconfigurations 75% 更多。

4.4 BCG/HBR Brain Fry 研究

1,488 样本调查：14% mental fog，39% 更多重大错误，33% 更多决策疲劳，34% 更高离职倾向。但使用 1-3 个 AI 工具做重复任务时 burnout 降低 15%。

第 5 章 “更累” vs “更轻松”：辩论矩阵

维度	"更轻松"方	"更累"方
门槛降低	非程序员也能产出软件（Kevin Roose/NYT）	低门槛 = 高风险（安全漏洞 2.74x）
速度感受	主观感知快（METR开发者自估+20%）	客观可能慢（METR RCT -19%，情境依赖）
认知负荷	释放手写负担，聚焦意图	“frankly exhausted”（Andrew Ng）；“agent psychosis”/sleep deprivation（Ronacher）
代码质量	快速原型、个人化工具	“pure unadulterated slop”（Bitar）；重构率暴跌、重复率翻倍（GitClear）
心理机制	flow-like 沉浸体验	“dark flow”/“junk flow”——类似赌博的 Loss Disguised as Win
长期后果	技能不再重要（部分 CEO 预测）	bus factor of zero、丧失代码心智模型、自我强化依赖循环
界限问题	Agentic engineering = 审慎的 AI 辅助	Willison 2026 年 5 月承认：两者在实际工作中已开始重叠

第 6 章 Simon Willison 的临界反思

25 年经验的工程师、Datasette 和 LLM 工具作者、AI coding 重度使用者，在 2026 年 5 月 6 日承认 vibe coding 与 agentic engineering 的界限在他自己的工作中开始模糊：

As the coding agents get more reliable, I’m not reviewing every line of code that they write anymore, even for my production level stuff.

他用组织间类比解释：其他团队的代码他也不逐行读——但关键区别是人类团队有声誉系统。“Claude Code does not have a professional reputation! It can’t take accountability for what it’s done.”

信任代理的是经验性归纳（每次都做对了）而非制度性问责（声誉与职业后果），两者可靠性不等价。前者是"到目前为止还没出事"，后者是"出了事有人负责"。

SDLC 断裂论点更值得深思：

If you can go from producing 200 lines of code a day to 2,000 lines of code a day, what else breaks? The entire software development lifecycle was designed around the idea that it takes a day to produce a few hundred lines of code.

代码生产速度变了，但审查、测试、部署、运维的流程没有相应变化。断裂不仅下游——review 和测试跟不上——也上游——设计流程的前提条件变了。Anthropic 设计负责人 Jenny Wen 的观察：传统设计流程基于"设计必须对，否则工程师花三个月建错东西就是灾难"；但如果建设成本大幅降低，设计流程可以更冒险。

Willison 用"偏差正常化"（normalization of deviance）概念自警：每次模型在没被密切监控的情况下写出了正确代码，就存在一个风险——会在未来不该信任的时刻信任它。他的新评价标准从"代码/测试/文档质量"转向了"是否有人真正用过"。

第 7 章中文科技媒体覆盖现状

主流中文科技媒体（InfoQ 中文版、36 氪、虎嗅、极客公园、机器之心、CSDN）在过去 8 个月内没有将"AI 编程让人更累"作为独立报道主题。

找到的中文来源：

36 氪（2026-04-20）：报道了 Karpathy 在 X 上"详细吐槽 AI 编程 Agent 的各种毛病"，但聚焦于吐槽内容本身而非"开发者更累"议题
ofox.ai（2026-04-10）：商业博客，提到"Code Review 的责任没减少"、“对技术能力薄弱的开发者来说，Vibe Coding 有时候只是帮你更快搭起一个你自己也看不懂的系统”、“心流断了很难接回来”——但这些警告是为"正确用法"铺垫
腾讯云开发者社区（2026-03-25）：纯正面宣传 vibe coding 的效率，无疲劳讨论
财联社（2025-12-05）：报道"谷歌下注’氛围编程’"，聚焦商业投资角度

英文世界已形成成熟话语体系——brain fry、dark flow、agent psychosis、vibe coding hangover、PR fatigue、cognitive drift、normalization of deviance。中文媒体尚未建立对应的讨论框架。这可能是引入滞后，也可能是中文科技媒体的选题偏好偏向正面叙事。

第 8 章知识缺口与不确定性

8.1 METR 数据的外推性

19% 减速仅适用于特定情境（大型代码库维护 + early-2025 AI 工具），不应泛化为"AI 让所有开发者更慢"。但"主观感知与客观事实差距 40%"这一发现在其他情境下是否成立，缺乏验证。

8.2 Brain Fry 与 Burnout 的关系

BCG 研究意外发现 brain fry 人群反而体验更少 burnout——两者机制不同。是 AI 导致了疲劳，还是疲劳者更倾向于密集使用 AI？因果方向需更严谨的实验设计验证。

8.3 Dark Flow 类比的边界

Vibe coding 有技能成分（prompt engineering、上下文选择），赌博基本没有。这使得"dark flow = vibe coding"的映射比原意更宽泛。但 speed-quality paradox 的实证部分支撑了这个类比的方向——ICSE 2026 论文 “Vibe Coding in Practice” 确认了"开发者为速度而来，但产出 fast-but-flawed"。

8.4 中文深度报道缺失

brain fry、dark flow、agent psychosis 等概念框架尚未被中文科技媒体系统引入和讨论。中文开发者的疲劳体验是否与英文世界同构，或者有本土化的特殊维度（比如不同的团队协作模式、不同的工具生态），目前缺乏数据。

第 9 章小结

AI 编程让很多开发者感到更累，但"更累"的机制与传统 burnout 不同。这不是体力消耗增加，而是认知负荷的类型发生了质变。五层机制各自独立又互相强化：

审查负担增加——瓶颈从"写"移到"审"，审查他人代码本来就比自己写更难。认知负荷类型质变——从"创建型"变为"评估型"，工作记忆的自然追踪被剥夺。决策层级升迁加上时间压缩——编码级决策变成架构级决策，时间反而更短。多 Agent 管理疲劳——brain fry 是急性认知过载，与慢性 burnout 机制不同。技能脱节与自我强化循环——丧失心智模型后没有 AI 就无法排障，依赖不断加深。

Andrew Ng 的两面性证言（exhausted but refuse to give up）是整个现象的缩影。fast.ai 的 dark flow 框架给出了心理学解释：vibe coding 提供了类似赌博的欺骗性反馈——Loss Disguised as a Win，让开发者误判自身生产力，同时产生足以维持成瘾的多巴胺奖励。

Simon Willison 的偏差正常化反思指向了一个更深层的问题：当审查成本不变但生产速度增加 10 倍时，整个软件开发流程的设计前提就崩溃了。这不是工具问题，是流程问题。

中文科技媒体尚未系统覆盖此议题。英文世界的 brain fry、dark flow、agent psychosis 等概念框架对中文开发者社区有直接的引入价值。命名本身就是一种基础设施——有了命名，一种体验才能被集体识别、讨论和改进。

参考来源

#	来源	日期	可信度	复核状态
1	Karpathy: Vibe Coding 原始定义 (X)	2025-02	5	✅ 一手资料
2	METR RCT: AI让经验开发者慢19%	2025-07	5	⚠️ 适用范围被缩小
3	BCG/HBR: AI Brain Fry (14% mental fog, 1488样本)	2026-03	5	✅ 已验证（基于自我报告）
4	fast.ai: Breaking the Spell (dark flow/junk flow)	2026-01	5	⚠️ 类比映射比原意更宽泛
5	CNN: AI brain fry 报道	2026-03	4	✅ 已验证
6	Andrew Ng: “frankly exhausted” (Business Insider)	2025-06	5	✅ 一手访谈
7	Mo Bitar: 两年vibecoding后回归手写 (Substack)	2026-01	4	✅ 个人叙事，HN 865点
8	Armin Ronacher: Agent Psychosis	2026-01	4	✅ Flask/Sentry创建者一手经验
9	Simon Willison: 界限模糊反思	2026-05	5	✅ 一手反思
10	GitClear: 技术债务量化 (2.11亿行追踪)	2025-02	4	🔍 方法论待查
11	CodeRabbit: AI代码1.7x更多问题 (470 OSS PR)	2025-12	4	🔍 方法论待查
12	Fast Company: “vibe coding hangover”	2025-09	4	🔍 403无法获取
13	Ars Technica: Will the future run on vibes?	2025-03	5	✅ 主流科技媒体
14	IT Pro: AI amplifies burnout	2026-03	4	✅
15	The Economic Times: AI burn out in coders	2026-03	4	✅
16	TechSpot: Forced to vibe code, skills deteriorating	2026-05	4	✅
17	Tabula Magazine: Too Fast to Think	2025-07	4	✅ 一手体验
18	Jorge Raad: Recovering from Vibe Coding Fatigue	2025-08	4	✅ 前谷歌工程师
19	threatmodeling.dev: Vibe Coding and PR-Fatigue	2025-07	3	✅
20	arXiv: Vibe-Check Protocol (认知卸载量化)	2026-01	4	⚠️ 学术论文
21	arXiv: Vibe Coding Kills Open Source	2026-01	4	⚠️ 未同行评审
22	Collins Dictionary: 2025年度词汇	2025-11	5	✅
23	36氪: Karpathy吐槽AI Agent毛病	2026-04	4	✅ 二手引用
24	ofox.ai: Vibe Coding完全指南	2026-04	3	✅ 商业博客