Vibe Coding 的上限，不在模型智商，而在上下文窗口

Vibe coding 这词是 Andrej Karpathy 半开玩笑抛出来的——"我不想读代码了，我跟 AI 聊感觉，能跑就行"。但这事传着传着变味了，变成"资深程序员是不是快下岗了"的焦虑。先把结论搁这儿：vibe coding 的上限在 ~30K 行 / 500KB 量级的原型，超过这条线它会系统性失控；资深程序员不会被它替代，但工作流一定会重构成"指挥 AI 写，人把关"的模式。

下面拆两层说。

---

一、Vibe Coding 的真实上限：不是模型笨，是上下文的物理天花板

很多人误判 vibe coding 的上限是"模型聪不聪明"，其实不是。Axiom Capital 给过一组挺实在的数据：

• 20 刀/月的普通订阅模型，舒适区在 200–500KB、15–30K 行代码，对应原型、MVP、CRUD 后台——这是 vibe coding 的真正主场。
• 真实生产级 SaaS 后端普遍 200K–500K 行，大产品百万到千万行级。
• Transformer 的 attention 是 O(n²) 的，多加 100 token 计算量约 ×10,000——代码库一大，上下文窗口不是"挤一挤"的事，是物理上装不下。

所以超过 10 万行之后，业界已经反复验证会出这些问题：

• 模块漂移：你让 AI 加个"批量上传"，它前两轮挺好，第四轮悄悄把你已有的 FileUploader 换成了新造的 BatchUploadManager，接口签名全改，调用点散六个文件——这是掘金那篇作者刚踩过的坑。
• 幻觉 API / 重复工具函数 / 接口名不一致：三轮之后开始冒，五轮之后项目你自己都不认识了。
• 架构腐烂：没人能 review 几千行 AI 生成的代码每一行，技术债是按指数积的。

Karpathy 原话里那个"vibe"本来就是指周末小项目、脚本、demo这种场景，不是让你拿它写支付核心。把适用范围搞错，是 2025–2026 年一堆"vibe coding 生产事故"的根源。

💡 一句话锚定上限：vibe coding 擅长"造片段"，造不出能活过三年的复杂系统。 CRUD 后台、内部工具、表单系统、MVP 验证——这些是它的地盘；金融交易、实时系统、强一致分布式、高性能底层——这些它进不去。

---

二、资深程序员的工作流会被替代吗？不会，但会"重组"

这里有个常见误解：以为 vibe coding 的对立面是"传统手敲每一行"。其实 2026 年 staff engineer 圈子里流行的是五种比纯 vibe 更严的 workflow（Product Leaders Day India 那篇总结得清楚）：

流派	人干啥	AI 干啥
Orchestrated AI Coding	先定架构 / 数据模型 / API contract	只填约束好的逻辑块
TDD + AI	人写 test	AI 写 code 让 test 过
Spec-driven	先写 tech spec 当 system prompt	AI 按 spec 生成
Strict AI Pair	人握方向盘，逐行读、逐行 commit	AI 当高级补全
Scaffolding only	AI 搭路由/目录/CRUD 骨架，然后关掉	核心业务逻辑人写

Stripe 的 Minions 系统每周让 AI 出上千个 PR，听着吓人，但前提是工程师只做 review——也就是上面那套"AI 生码、人防墙"的工业版。人家不是"vibe"是"orchestrate"。

为什么资深程序员反而更值钱了

Vibe coding 暴露了一个反直觉的事实：写代码从来不是资深工程师的核心价值，把控 AI 覆盖不了的那部分才是。

• 问题定义与需求拆解：AI 只能被动执行已明确的事，但"挖掘隐性需求（合规/容灾/风控）""划清模块边界""判断技术选型取舍"这些，AI 目前给不出靠谱判断。
• 架构决策与跨域集成：超过 30K 行之后，模块依赖、一致性、性能约束是全局问题，不是局部"感觉对不对"能解决的。
• 质量管控与风险防控：隐藏 bug、性能劣化、安全漏洞、技术债——这些 AI 不主动告诉你，得人来审。
• Debug 深水区：生产炸了，AI 没法替你去翻三个月前的 migration 和那条冷门 corner case。

知乎那篇说得直白："AI 负责生码，人负责筑墙"——工程壁垒没塌，反而因为 AI 能生更多码，需要更多人去筑墙。

那工作流到底变啥样了

对一个资深工程师而言，2026 年的典型节奏大概是：

1. 前半段加速：需求探索 → 让 AI 出原型/MVP → 验证逻辑（这部分原来占不少时间，现在 vibe 掉）
2. 中段卡点：架构、contract、核心链路——人定，AI 不许乱动
3. 后半段严控：测试人写（或人审 AI 测），PR 人 review，上生产前过静态分析+集成测试

Axiom 那句判断挺准："软件工程 20–30% 是造系统，70–80% 是维护和演化"——vibe coding 能把造的那部分提速，但维护那部分反而因为 AI 产出的代码更多而更吃资深人力。所以结论是"一人 + AI 能干之前 2–3 人的活"，但不是"不用那人了"，是那人门槛更高了。

---

三、给个分层判断，别走极端

• 全栈原型 / 内部工具 / CRUD 后台 / Demo → vibe coding 可以全接，资深程序员在这儿就是"高级 prompt + review"，效率翻倍没问题。
• 中型产品、多模块、有性能/一致性要求 → 放弃纯 vibe，切到 orchestrated / spec-driven / TDD+AI，人是 conductor。
• 核心交易、实时系统、分布式存储、长生命周期基础设施 → AI 最多干脚手架和单点辅助，架构和核心逻辑必须人写人审，vibe coding 在这儿是负债不是资产。

⚠️ 一个容易被忽略的点：vibe coding 最大的隐形成本是review overhead。Prompt 写得糙，AI 产出飘，reviewer 耗的心力比自己写还多。所以"资深程序员能不能依赖"这个问题的真答案是——能依赖，但依赖的是"AI + 强 governance + 自己的工程判断"这套组合，不是依赖"我不管了 AI 你看着办"那种 vibe。

Karpathy 当初那句 joke，本质是给周末小项目省时间的，不是给支付系统开的后门。把这句话记牢，就不会被两边的 hype 带偏——一边"AI 替代程序员"是瞎喊，另一边"AI 也就是玩具"也是装睡。真相在中间：vibe coding 是新的脚手架，不是新的工程师。