2025年初，OpenAI前研究总监 Andrej Karpathy 发了一条推文，引爆整个技术圈：

“I just mass-mass-produce code with AI. I barely look at the diffs. I call this Vibe Coding.”

“我现在用AI大规模生产代码，几乎不看diff。我称之为 Vibe Coding。”

这不是玩笑。这位顶级AI科学家在认真描述他的日常工作方式：

• 用自然语言告诉AI要做什么
• AI生成代码
• 直接运行看效果
• 有问题就让AI改

不看代码，只看结果。

这就是 Vibe Coding —— 一种全新的编程范式。

从"写代码"到"描述需求"

传统编程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# 手动实现一个用户登录功能
def login(username: str, password: str) -> dict:
    # 验证输入
    if not username or not password:
        raise ValueError("用户名和密码不能为空")
    
    # 查询数据库
    user = db.query(User).filter(User.username == username).first()
    if not user:
        raise AuthError("用户不存在")
    
    # 验证密码
    if not verify_password(password, user.hashed_password):
        raise AuthError("密码错误")
    
    # 生成token
    token = create_access_token(user.id)
    
    return {"token": token, "user": user.to_dict()}

你需要：

1. 了解所有API
2. 处理边界情况
3. 手动写每一行

Vibe Coding

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

You: 实现用户登录功能，要验证输入、查数据库、验密码、返回JWT token

AI: [生成完整代码]

You: 跑一下

AI: [执行测试] 测试通过

You: 加个登录失败次数限制，超过5次锁定账号

AI: [修改代码] 已添加

你需要：

1. 清楚地描述需求
2. 验证结果是否符合预期
3. 迭代优化

代码变成了"中间产物"，不再是最终目标。

为什么现在可行了？

1. 模型能力的跃升

Claude 3.5 Sonnet → Claude Opus 4.5 → GPT-5，代码能力指数级提升：

2. 工具链的成熟

• Cursor：AI原生IDE，理解整个项目
• Claude Code：终端里的AI程序员
• Windsurf：Copilot++，无缝集成
• Replit Agent：从描述到部署一条龙

3. 上下文窗口爆炸

• 2023年：4K tokens（一个文件）
• 2024年：128K tokens（小型项目）
• 2025年：1M+ tokens（大型代码库）

AI终于能"看懂"整个项目了。

Vibe Coding 实战演示

场景：从零搭建一个博客系统

传统方式：2-3天

Vibe Coding方式：2小时

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

第1轮对话：

You: 我要做一个个人博客系统，技术栈用 Next.js 14 + Prisma + PostgreSQL。
功能需要：
- Markdown 文章编辑
- 文章分类和标签
- 评论系统
- 暗黑模式
帮我搭建项目框架。

AI: 好的，我来创建项目...
[执行 npx create-next-app@14 ...]
[创建 prisma/schema.prisma]
[创建数据库模型]
[创建基础组件]
...
框架搭建完成，运行 npm run dev 查看效果。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

第2轮对话：

You: 首页看起来太丑了，参考 Vercel 官网的设计风格美化一下

AI: 明白，我来调整样式...
[修改 globals.css]
[修改 components/Header.tsx]
[添加渐变背景和动画效果]
...
已更新，刷新页面查看。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

第3轮对话：

You: 文章编辑器需要支持实时预览，左边写 Markdown 右边显示效果

AI: 
[安装 react-markdown]
[创建 SplitEditor 组件]
[添加语法高亮支持]
...
编辑器已完成。

2小时后：一个功能完整、样式精美的博客系统上线。

谁适合 Vibe Coding？

最适合

1. 资深开发者

   • 知道要做什么，懒得写具体实现
   • 能快速判断AI代码质量
   • 专注架构设计和业务逻辑

2. 创业者/独立开发者

   • 一个人当一个团队用
   • 快速验证想法，MVP开发
   • 把时间花在更重要的事情上

3. 非专业程序员

   • 产品经理自己做原型
   • 设计师实现交互效果
   • 运营搭建内部工具

需要谨慎

1. 涉及核心算法的场景

   • 交易系统的风控逻辑
   • 推荐算法的核心实现
   • 需要100%正确的关键路径

2. 安全敏感场景

   • 加密解密实现
   • 认证授权逻辑
   • 需要人工审查每一行

3. 性能极端场景

   • 毫秒级响应要求
   • 资源受限环境
   • 需要手工优化

程序员的新技能栈

Vibe Coding 时代，程序员需要的能力正在转变：

重要性降低

• ❌ 记忆API语法
• ❌ 手写样板代码
• ❌ 调试简单Bug
• ❌ 代码格式规范

重要性提升

• ✅ 需求分析：把模糊需求转化为清晰描述
• ✅ 架构设计：决定系统如何组织
• ✅ 代码审查：快速判断AI输出质量
• ✅ Prompt工程：如何让AI更好地理解你
• ✅ 测试验证：确保结果符合预期
• ✅ 领域知识：理解业务，而不只是技术

新的工作流程

1
2
3
4

传统：需求 → 设计 → 编码 → 测试 → 部署

Vibe：需求 → 描述 → AI编码 → 审查 → 迭代 → 部署
          ↑_________←_________|

核心变化：你从"生产者"变成了"指挥者"和"质检员"。

一些实用建议

1. 学会"说人话"

1
2
3
4
5
6
7

❌ 不好的描述：
"写一个函数处理用户数据"

✅ 好的描述：
"写一个函数，接收用户注册表单数据（name, email, password），
验证邮箱格式和密码强度（至少8位，包含大小写和数字），
验证通过返回处理后的数据，失败抛出具体错误信息"

2. 分步迭代

不要试图一次性让AI写完所有功能。

1
2
3
4
5

第1步：搭建基础框架
第2步：实现核心功能
第3步：添加边界处理
第4步：优化性能
第5步：完善样式

3. 保持代码审查习惯

AI不会100%正确。关键代码一定要review：

• 安全相关（认证、权限、加密）
• 性能相关（循环、查询、缓存）
• 业务相关（核心逻辑、金额计算）

4. 建立项目规范

在项目中维护一个 CLAUDE.md 或 .cursorrules 文件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 项目规范

## 技术栈
- Next.js 14 (App Router)
- TypeScript 严格模式
- Tailwind CSS
- Prisma ORM

## 代码风格
- 使用函数式组件
- 所有函数必须有 JSDoc 注释
- 错误处理使用自定义 Error 类

## 禁止
- 使用 any 类型
- 直接操作 DOM
- 在组件中写内联样式

这是终点吗？

Vibe Coding 可能只是开始。

接下来可能发生的：

1. AI理解产品文档：直接从PRD生成代码
2. AI参与代码审查：自动发现问题并修复
3. AI运维系统：监控、报警、自动修复
4. AI产品经理：分析用户行为，提出优化建议

终极形态：

你描述一个想法，AI完成从设计到开发到部署到运维的全流程。

这不是科幻，可能就在3-5年内。

结语

Vibe Coding 不是要消灭程序员，而是在重新定义什么是编程。

20年前，“程序员"意味着要懂汇编和指针。 10年前，“程序员"意味着要懂框架和设计模式。 今天，“程序员"可能意味着要懂需求分析和AI协作。

不变的是：解决问题的能力、对技术的理解、对产品的洞察。

变化的是：实现方式从"手写代码"变成了"指挥AI”。

你可以选择抵触，也可以选择拥抱。但无论如何，这个浪潮已经来了。

我没写一行代码。但那个下午合并了五个 PR。

这不是什么"未来已来"的感慨。这是 2026 年 5 月一个普通工程师的普通下午。半年前——也就是 2025 年底——我的工作方式还不是这样。那时候 AI 编程工具的主流形态是"一个很聪明的补全",你在编辑器里写代码,它帮你接下一段。现在,补全这件事我几乎已经感觉不到它的存在了,因为我的注意力整个挪到了别处。

这半年到底发生了什么,值得拆开看看。

三级跳:补全 → 终端 agent → 后台 agent

如果要给 AI 编程工具这半年画一条线,它是这样三级跳的:

flowchart LR
  A[代码补全
2023-2024] --> B[IDE 内 agent
2025] --> C[终端 agent
2025 下半年] --> D[后台/云端 agent
2026]
  style A fill:#e8e8e8,stroke:#999
  style B fill:#fde7c2,stroke:#e8b23c
  style C fill:#fde7c2,stroke:#e8b23c
  style D fill:#c2e0fd,stroke:#3c8ce8

第一级是补全:Copilot 那套,光标后面灰字提示,你按 Tab 接受。这个形态决定了一件事——AI 是你的副驾驶,方向盘还在你手里,你得一直盯着路。

第二级是 IDE 内的 agent:Cursor 的 Composer、Windsurf 的 Cascade。它不再是接一段,而是"你说要干什么,它跨多个文件改完给你看"。方向盘开始松动了,但你还在车里。

第三级是 终端 agent:Claude Code 是把这个形态做出影响力的那个。它干脆不要 IDE 这个壳了,就是个命令行程序,你跟它说话,它自己读文件、改代码、跑测试、看报错、再改。这一步的意义比看上去大——它把 AI 编程从"编辑器里的一个功能"变成了"一个独立的进程"。一旦是独立进程,你就能开很多个,就能让它在后台跑。

第四级,也就是现在,是后台 / 云端 agent:活儿不在你机器上跑了。Cursor 的 cloud agents、GitHub 的 coding agent、Cognition 的 Devin,它们在云端的容器里干活,干完给你提个 PR。你甚至可以在手机上派活。

每跳一级,人和代码之间就多隔一层。半年前我的手指还在键盘上,现在我的手指主要在做一件事:点"approve"或者"reject"。

当前四强,各自站在哪

把这半年最主流的四个工具摆在一起,它们其实已经不在同一个赛道上竞争了——这是很多人没意识到的。

Cursor 这半年走得最稳。3.3、3.4 连着发,Composer 2.5 五月中刚出。它现在的核心卖点已经不是"补全多准",而是 /multitask——你可以同时开一堆异步子 agent 并行干活,加上云端 automation 能直接从 Linear、Jira、GitHub 读工单、起 PR、回写状态。Cursor 想做的是你的指挥台:本地一份 agent,云端一支舰队,你坐中间派活。它甚至能帮你把云端 agent 需要的开发环境(克隆仓库、装依赖、配凭据)自动搭好——因为没有环境,agent 舰队就跑不起来。

Claude Code 走的是另一条路。它不抢"IDE"这个身份,就守着终端。这半年它加了 Agent View——一个能同时盯多个后台会话的界面,加了 /goal——你给它一个目标,它自己写代码、跑测试、debug、再跑,直到达成。我个人的体感:Claude Code 是这四个里最适合干"脏活重活"的。一个要动二十个文件、还得反复跑测试验证的重构,我现在默认丢给它。它的 fast mode 现在默认跑 Opus 4.7。

Windsurf 是这半年最唏嘘的一个。2025 年底它被 Cognition(做 Devin 的那家)以约 2.5 亿美元收购,这中间还夹着 Google 的技术授权和 OpenAI 当初的竞购,过程一地鸡毛。产品本身没死,Wave 13 还带来了多 agent 会话和 Git worktree 支持,2026 年 2 月它在 LogRocket 的 AI 开发工具榜上还排第一。但今年 3 月它把原来便宜、可预测的 15 美元信用额度套餐换成了 20 美元加严格日 / 周配额,直接惹毛了一批老用户。更要命的是定位上的不确定:Cognition 明说了想把 Windsurf 的 IDE 能力并进 Devin。所以现在用 Windsurf,你得想清楚——你是在用一个 IDE,还是在用一个早晚会变成 Devin 入口的东西。

GitHub Copilot 是那个"看起来落后、其实没掉队"的。补全起家的它,这半年把 Agent Mode 和云端 coding agent 都补齐了:coding agent 现在能自己选模型、开 PR 前先用 code review 自审一遍、还在流程里跑代码扫描和密钥泄露检查。它最大的护城河从来不是模型,是它长在 GitHub 身体里——issue、PR、Actions、code review 一条龙。五月它还放出了从 JetBrains IDE 把任务交给本地 Copilot CLI agent 的预览。Copilot 不耀眼,但对一个深度绑在 GitHub 上的企业团队,它是阻力最小的选择。

我的判断是:别再问"哪个最好"了。这个问题在 2025 年还成立,现在不成立。Cursor 是指挥台,Claude Code 是重型施工队,Copilot 是贴着 GitHub 的传送带,Windsurf 是一张赌 Cognition 未来的票。它们解决的是不同的问题。我自己是 Cursor + Claude Code 一起用,前者派活、后者啃硬骨头,一点都不冲突。

“终端 agent"为什么会赢

值得单独说一句:为什么 2025 下半年杀出来的是终端 agent 这个形态,而不是更花哨的 IDE?

因为终端 agent 砍掉了"图形界面"这个包袱,换来了三样东西:可组合、可并行、可上云。

一个命令行程序,你能用 shell 脚本把它串起来,能在 CI 里调它,能开十个进程同时跑。一个 IDE 你做不到这些——IDE 天生是给"一个人坐在前面"设计的。当 AI 编程从"辅助一个人"变成"同时干很多活”,IDE 这个外壳反而成了约束。

flowchart TB
  Dev[开发者] --> Plan[拆任务 / 写清楚要什么]
  Plan --> A1[agent 1: 后台改 bug]
  Plan --> A2[agent 2: 本地写新功能]
  Plan --> A3[agent 3: 云端跑重构]
  A1 --> Review[人:审 diff / 提 PR / 决定合不合]
  A2 --> Review
  A3 --> Review
  Review --> Dev
  style Dev fill:#fde7c2,stroke:#e8b23c
  style Review fill:#fde7c2,stroke:#e8b23c

注意这张图里,人只出现在两个地方:开头拆活,结尾审活。中间那段"写代码"已经不在人的关键路径上了。这就是这半年最实质的变化——它不是工具变好用了,是工作流的形状变了。

Cursor 也很清楚这一点,所以它一边守着 IDE 这个用户习惯,一边拼命往云端 agent 和 /multitask 上加码。它在用 IDE 的外壳,装终端 agent 的内核。

你的工作从"写"变成了"审"和"派"

这是我最想说的一段,也是这半年我自己感受最深的。

半年前,我的核心技能是写代码。现在不是了。现在我每天花最多时间的三件事是:

第一,把活拆清楚。 Agent 干得好不好,八成取决于你派活派得清不清楚。一个含糊的"帮我优化下这个模块",和一个"把这个模块的数据库查询从 N+1 改成批量加载,保持现有接口不变,加上对应测试"——出来的东西天差地别。这半年我越来越觉得,写清楚需求本身就是一种正在升值的技能。Claude Code 的 /goal 之所以好用,前提是你得能说清楚那个 goal。

第二,审 diff。 这是最累、也最危险的一件事。Agent 一天能给你交十几个 PR,业界数据是引入 agent 后 PR 数量涨了 40% 到 60%。问题来了:你审得过来吗?审不过来就会有人开始"假装审过了"——扫一眼,点 approve。这是 2026 年最真实的风险,不是 AI 写出 bug,是人审不动了,于是不审了。

我给自己定了条规矩:agent 写的代码,审查标准要比人写的更高,不是更低。因为人写错了通常错得"有道理"、好猜;agent 错起来经常错得很离谱、很自信,藏在一堆看着没问题的代码中间。

第三,决定什么不交给 agent。 这点反直觉但很重要。核心架构、安全边界、那些"错了代价很大"的地方,我现在反而更倾向自己写,或者自己写完让 agent 来挑错。会派活的人不是把所有活都派出去的人,是知道哪些该派、哪些该自己攥着的人。

工具厂商其实也在顺着这个变化走。GitHub Copilot 的 coding agent 现在开 PR 前会先自审一遍、跑安全扫描——本质上是它知道"人审不过来了",所以先帮你过一遍。Cursor 给你看 agent 的 context 用量,也是同一个逻辑:当你不亲自写,你至少得知道它在想什么。

所以如果你问我,这半年一个开发者最该练的是什么,我的答案是三个词:拆活、审 diff、判断边界。写代码的肌肉不会废掉——你得能写,才看得懂 agent 写的——但它不再是那块最值钱的肌肉了。

接下来半年,我赌什么

简单说几个判断,赌错了年底再来认。

后台 agent 会变成默认,但"全自动"还早。 派活给云端 agent、它提 PR 给你审,这套流程会变成常规操作。但"把整个需求扔进去、不管了"——Devin 那个最初的承诺——我认为这半年还到不了。卡点不在模型聪不聪明,在验证:你怎么确认它真做对了?在这个问题被解决之前,人必须留在审查这一环。

工具会继续分化,不会收敛。 不会出现一个"赢家通吃"的 AI IDE。终端 agent、IDE、云端 agent 是三种不同的形态,服务三种不同的场景,它们会长期共存。你最终大概率是手上同时握着两三个,按场景切。

审查会变成瓶颈,然后变成新工具的战场。 当 agent 产出快到人审不过来,下一波工具竞争的焦点不会是"写得更快",而是"帮你审得更快、更可信"。谁能让人重新跟得上 agent 的产出速度,谁就赢下 2026 下半年。

半年前我担心的是 AI 会不会写不好代码。现在我不担心这个了——它写得够好。我现在担心的是另一件事:当写代码这件事变得这么便宜,我们会不会因为审不过来,而让一堆没真正看懂的代码,合进了主干。

工具的演化已经跑到前面去了。该追上的,是我们自己审视代码的方式。

下面说说为什么。

GitHub Copilot：稳

优点：

• 和VS Code集成最好，不卡
• 企业合规，公司一般都愿意买单
• 代码补全中规中矩，不会出太离谱的东西

缺点：

• 对整个项目的理解不如Cursor
• 有时候补全太保守，不敢写多

适合谁： 大厂员工、需要合规的团队

Cursor：快

我现在主力用Cursor。

为什么？

1. Tab补全太爽了。它能预测你下一步要改哪个文件、哪一行，按Tab就跳过去了。用久了回不去普通IDE。

2. 对代码库理解深。问它"这个项目怎么加个新API"，它真的会去翻代码，不是瞎编。

3. Composer模式。告诉它"帮我重构这个模块"，它能同时改好几个文件。

缺点：

• 有时候太激进，改得多你得仔细review
• 月费$20，不便宜

适合谁： 追求效率的老手、个人开发者

Claude Code：聪明

Claude Code是后来者，但确实有点东西。

亮点：

• 理解能力最强，复杂逻辑描述清楚它就能写对
• 解释代码特别清楚
• 处理大项目上下文比较好

缺点：

• 速度比Cursor慢一点
• 还在迭代，功能没那么完善

适合谁： 需要处理复杂项目、喜欢AI帮忙想方案的人

我的使用习惯

日常写代码：Cursor 遇到复杂问题：切到 Claude Code 聊两句 公司项目：用公司配的 Copilot

不冲突，看场景切换就行。

一点建议

别把AI编程工具当"代码生成器"，把它当"结对编程的同事"。

• 它写的代码你得review
• 它不懂的地方你得教它（给上下文）
• 它写错了跟它说，它会改

用好了效率能提升2-3倍，用不好反而添乱。

有问题留言，我看到会回。