🌀 当 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%。
审查耗时却涨到原来的四倍。
产能往上走、交付往下掉，这算不上效率提升，只是在不断累积技术债。
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技能是入场券，工程能力是天花板
- 转型分三步：先做 AI Piloteer（给约束而非只提需求）→ 补齐 AI 工程课（模型边界、上下文管理、Agent 编排）→ 真正做完一个完整 AI 项目
- 面试市场已经给出答案：75.7%的AI岗位要求Python，但加分项是分布式、高并发、微服务——AI技能+工程能力才是不可替代组合
评论0