
当 Andrej Karpathy 说出”Vibe Coding”这个词
2025年初,OpenAI联合创始人Andrej Karpathy发了一条推文。
他说他现在写代码的方式变了。
他不再逐行敲键盘,而是对着AI说需求,然后看着代码流出来。
他给这种方式起了一个名字:Vibe Coding。
“跟着感觉走,完全沉浸在vibes里,拥抱指数级变化。”
这条推文引发了两极反应。
一派欢呼:终于不用写CRUD了,人人都是产品经理。
另一派沉默:如果写代码不需要思考了,那我们这些”古法程序员”还剩什么?
一年半过去了。
2026年的今天,数据给出了答案——但可能不是你想的那种。

一、Vibe Coding的繁荣与幻灭
1.1 表面上的繁荣
GitHub 2026开发者调查:82%的开发者每天使用AI编程工具。
Cursor月活突破800万。
Claude Code在Auto模式下,一个周末可以提交388个PR。
看起来,Vibe Coding赢了。
1.2 数据的另一面
但FarosAI对2.2万名开发者的追踪研究,揭示了一个反直觉的结果:
| 指标 | 数据 |
|---|---|
| 人均任务完成量 | 增长66.2% |
| 每周实际部署次数 | 下降11.7% |
| PR平均审查时间 | 激增441.5% |
| 未经审查就合并的PR | 31% |
| 每周至少回滚的团队 | 69% |
代码产出多了66%。
部署反而少了12%。
审查时间翻了4倍。
产能在涨,交付在降。这不是效率提升,是债务积累。
1.3 “AI乞丐”现象
技术社区出现了一个新词:AI乞丐。
指的是那些完全依赖AI编程工具,自己不理解代码逻辑,遇到bug只能反复让AI”再试一次”的开发者。
他们能跑通Demo。
能做出漂亮的GitHub仓库。
能通过面试的初筛。
但在生产环境出问题时——
只会对着屏幕说:”AI,帮我修一下。”
然后AI修了。
引入了两个新bug。
二、会写代码和会做工程,差在哪
2.1 一个真实的故事
某创业公司的CTO讲过一个案例。
团队用Cursor两周搭了一个完整的微服务系统。
16个服务,47个API,3个消息队列,2个缓存层。
Demo跑起来很丝滑。
投资人看了很满意。
然后上线了。
第一天:正常。
第二天:缓存击穿,数据库连接池耗尽,服务雪崩。
第三天:发现16个服务中有5个没有熔断机制,3个服务间调用的超时时间设成了0。
第四天:CTO把整个系统推倒重来。
AI可以帮你盖一栋楼,但它不会帮你做结构计算。
2.2 六个维度的差距
| 维度 | Vibe Coding | 工程化思维 |
|---|---|---|
| 目标 | 功能跑通 | 系统可靠 |
| 思考 | “能运行就行” | “出错了怎么办” |
| 边界 | Happy Path | 异常、超时、重试、降级 |
| 可维护性 | AI写了没人懂 | 有文档、有测试、有review |
| 扩展性 | 加功能=重写 | 架构预留了扩展点 |
| 安全 | 完全不考虑 | 输入校验、权限、日志 |
2.3 最危险的盲区
AI代码最大的问题不是bug多。
而是bug的类型变了。
人工代码的bug通常是显性的——拼写错误、API误用、逻辑遗漏。
AI代码的bug是隐性的——边界条件看起来对但实际错,异常处理看起来有但实际不生效,并发看起来安全但实际有竞态。
测试是绿的,摘要是顺的,diff很长——最容易发生的动作就是扫几眼,点通过。
这就是”完成感”的陷阱。
AI给你一种”搞定了”的错觉。
但那些藏在边界条件里的炸弹,只有生产环境才会引爆。
🧱 三、”古法程序员”的护城河
3.1 什么是古法程序员
有多年前后端实战功底。
精通数据库、并发、服务架构。
习惯手写代码排查问题。
对大模型有接触,但没有完整AI项目落地经验。
面对AI浪潮内心摇摆。
这描述的是不是你?
3.2 你的旧技能,其实是新护城河
很多人觉得传统工程能力在AI时代没用了。
恰恰相反。
| 传统技能 | 在AI时代的价值 |
|---|---|
| 并发与锁 | AI完全不懂分布式锁的正确使用场景 |
| 数据库设计 | AI会建表但不会设计索引策略 |
| 服务架构 | AI能写微服务但不懂数据一致性边界 |
| 性能调优 | AI不知道瓶颈在哪,只会堆缓存 |
| 异常处理 | AI系统性缺失,这是最大的安全漏洞 |
| 系统设计 | AI没有全局视角,只会局部最优 |
企业不缺会调API的Demo选手,更想要懂传统软件工程同时懂大模型边界的人。
3.3 面试数据印证
拆解37个2026年真实AI岗位JD:
| 高频要求 | 出现率 |
|---|---|
| Python | 75.7% |
| LLM API调用 | 67.6% |
| LangChain | 48.6% |
| RAG | 37.8% |
| Agent开发 | 32.4% |
但注意——这些JD的”加分项”栏里,出现最多的是:
- 分布式系统经验
- 高并发处理
- 微服务架构
- 生产环境运维
AI技能是入场券,工程能力是天花板。
️ 四、三步转型路径
4.1 第一步:从Vibe Coder变成AI Piloteer
Vibe Coding和AI Piloteering的区别:
| 维度 | Vibe Coding | AI Piloteering |
|---|---|---|
| 交互方式 | “帮我写个功能” | “按这个架构设计实现,注意以下约束” |
| 代码审查 | 扫一眼,看着对就合并 | 逐行审查边界条件和异常处理 |
| 错误处理 | “报错了,再试一次” | 分析根因,调整生成规则 |
| 目标 | 快速出原型 | 可维护、可扩展、可上线 |
具体做法:
给AI设定约束,而不是只给需求。
不要说”帮我写一个用户注册接口”。
要说”写一个用户注册接口,要求:密码bcrypt加密、邮箱格式校验、注册成功发异步消息、失败返回具体错误码、并发场景下邮箱不能重复”。
4.2 第二步:补上AI工程的课
不需要学Transformer的数学原理。
但需要理解三件事:
1. 模型的边界在哪
模型擅长什么:文本生成、代码补全、文档总结。
模型不擅长什么:精确计算、实时数据、复杂推理链。
2. 上下文怎么管理
不要把所有信息都塞进一个对话窗口。
用RAG注入结构化上下文。
按任务开新对话。
3. Agent怎么编排
理解”思考→行动→观察→反思”的循环。
学会设计工具调用→验证→恢复的闭环。
掌握状态持久化和断点续做。
4.3 第三步:做一个完整的AI项目
不要只跑通Demo。
完整走一遍:
需求分析 → 架构设计 → AI生成代码 → 人工审查 → 测试覆盖 → 部署上线 → 监控告警 → 迭代优化。
然后把整个过程写成博客。
这一套走下来,你就不是”AI乞丐”了。
你是AI工程师。
️ 五、一张表看懂你在哪一层
| 层级 | 特征 | 可替代性 | 典型月薪 |
|---|---|---|---|
| L0 纯Vibe Coder | 只会说”帮我写”,不懂代码 | 极高,AI自己就能替代 | 8-12k |
| L1 AI辅助开发者 | 能用AI写代码,能做基本审查 | 高,AI审查工具在追赶 | 12-20k |
| L2 AI应用工程师 | 能设计RAG/Agent系统,能上线 | 中等,市场缺口大 | 25-45k |
| L3 AI系统架构师 | 能设计Harness,能做工程闭环 | 低,稀缺性高 | 45-80k |
| L4 AI平台设计者 | 能设计AIinfra,能定义规则 | 极低,行业级稀缺 | 80k+ |
从L0到L1,需要学会审查AI代码。从L1到L2,需要补上AI工程能力。从L2到L3,需要系统设计思维。从L3到L4,需要基础设施视角。
每一层的跃迁,核心都不是”学一个新工具”。
而是”思维方式升级一层”。

本文要点回顾
- Vibe Coding不是错的——它是快速原型的利器,但把它当生产方式就是灾难
- 数据已经证明:产能涨66%但部署降12%,审查时间翻4倍,31%的PR未经审查就合并
- AI代码最大的危险不是bug多,而是”完成感”会麻痹审查者——测试全绿不代表代码安全
- 传统工程能力是AI时代的护城河:并发、架构、异常处理、性能调优——AI技能是入场券,工程能力是天花板
- 三步转型:从Vibe Coder变成AI Piloteer(设定约束而非只给需求)→ 补AI工程课(模型边界、上下文管理、Agent编排)→ 做一个完整AI项目
- 面试市场已经给出答案:75.7%的AI岗位要求Python,但加分项是分布式、高并发、微服务——AI技能+工程能力才是不可替代组合
文章摘自:https://www.cnblogs.com/badhope/p/22501546/vibe-coding-illusion-2026
