Vibe Coding 时代，真正重要的能力是什么

Vibe Coding 时代，真正重要的能力是什么

1. 写代码不再是瓶颈

2026 年，一个产品经理坐在 Cursor 前面，用自然语言描述需求，30 分钟后一个可运行的原型出现在屏幕上。他没有写过一行代码。

这就是 Vibe Coding——用意图驱动代码生成，让 AI 完成实现细节。Copilot、Cursor、Claude Code、Devin、Windsurf……工具在疯长，能力在飞升，写代码这件事本身正以肉眼可见的速度变得不那么重要。

但随之而来的是一个更深的问题：当代码不再是瓶颈，什么成了瓶颈？

答案不是”提示词工程”。提示词只是新的语法，就像 TypeScript 是 JavaScript 的语法一样。语法总会被抽象掉。

真正的答案是：在代码之前的一切。

过去，一个程序员 70% 的时间在写代码，30% 的时间在思考和沟通。Vibe Coding 把这个比例翻转了——你可能只花 10% 的时间”写”代码，但 90% 的时间在想清楚到底要写什么。

这 90% 的时间，需要的不是编程能力，而是以下四种能力。

2. 能力一：理解业务的本质问题

2.1 大多数项目失败不是因为代码烂

而是因为解决了一个没人有的问题，或者解决错了问题。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
常见失败模式:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

模式 A: 解决伪问题
  · 用户说"我要一个报表系统"
  · 实际问题是"老板看不到关键数据"
  · 解决方案可能是: 一条每日自动推送的 Slack 消息，而非报表系统

模式 B: 解决表面问题
  · 用户说"搜索太慢了"
  · 实际问题是"搜索结果不相关"
  · 优化查询速度 10 倍，用户仍然不满意

模式 C: 解决错层次的问题
  · 用户说"我们需要自动化"
  · 实际问题是"流程本身就不合理"
  · 自动化一个坏流程 = 更快地产出垃圾

Vibe Coding 让这类失败加速了——以前你至少要花几周写代码才发现方向错了，现在几小时就能生成一个错误方向的可运行原型。快速试错是好事，但快速试错也需要方向感，否则只是在错误的方向上跑得更快。

2.2 什么是”理解本质问题”

理解本质问题 = 区分症状（用户说的）和病因（实际发生的）。

一个框架：连续问五层为什么

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
场景: 电商客服团队要求"AI 自动回复系统"

第 1 层: 为什么要 AI 自动回复？
  → 因为客服回复太慢

第 2 层: 为什么回复慢？
  → 因为每个客服同时处理 30+ 对话

第 3 层: 为什么同时处理这么多？
  → 因为咨询量大，人手不足

第 4 层: 为什么咨询量大？
  → 因为商品页面信息不够，用户只能问客服

第 5 层: 为什么商品页面信息不够？
  → 因为上架流程没有强制要求填写关键参数

本质问题: 不是"客服回复慢"，而是"商品信息缺失导致大量不必要咨询"

解决方案对比:
  ❌ AI 自动回复系统 → 治标，咨询量不降
  ✅ 优化商品上架流程 + 商品信息补全 → 治本，咨询量下降 60%
  ✅ (如果仍需 AI) 针对残余咨询的智能辅助 → 规模小得多

2.3 业务理解的实操方法

方法 1: 跟着用户走一遍

不要在会议室里讨论需求，去坐在用户旁边，看着他工作 30 分钟。你会发现：

  • 他从不使用的”核心功能”
  • 他反复切换的两个页面（说明缺少一个整合视图）
  • 他用 Excel 补充系统做不到的事（说明系统缺功能）
  • 他跟同事口头确认的信息（说明系统信息不透明）

方法 2: 画出信息流

1
2
3
4
5
6
7
8
9
10
11
12
信息从哪里来？经过哪些人？在哪里卡住？在哪里丢失？

  用户下单 → 订单系统 → 仓库 → 物流 → 用户签收
                ↓
            客服（查状态）
                ↓
            "你的订单在途中"（信息粒度不够）
                ↓
            用户继续追问 → 客服压力 ↑

  卡点: 物流信息粒度不够 → 客服只能给模糊回答 → 用户反复追问
  本质: 不是客服能力问题，是信息透明度问题

方法 3: 量化问题的影响

1
2
3
4
5
6
7
8
不说"客服压力大"，而说:
  · 日均咨询 5000 条
  · 其中 60% 是物流状态查询
  · 平均处理时间 3 分钟/条
  · 客服人力成本 ¥200/天/人
  · 总成本: 5000 × 60% × 3min / 480min × ¥200 = ¥3,750/天

  如果物流信息透明度提升 → 60% 的查询消失 → 每天省 ¥3,750

量化不是为了精确，而是为了优先级排序——影响 ¥3,750/天 的问题比影响 ¥50/天 的问题更值得解决。

3. 能力二：定义需要交付的结果

3.1 “做一个 XX 系统”不是需求

这是 Vibe Coding 时代最常见的坑：给 AI 一个模糊的指令，得到一个模糊的结果，然后反复修改，永远不满意。

1
2
3
4
5
6
7
8
9
模糊指令 → 模糊结果 → 无尽修改

  "做一个任务管理系统"
  → AI 生成一个 Todo List
  → "不对，我要的是看板"
  → AI 改成看板
  → "不对，我要的是甘特图"
  → AI 改成甘特图
  → "不对，我要的是..."

问题不在 AI，在于你没有定义清楚”完成”是什么样子。

3.2 交付定义的四要素

一个清晰的结果定义包含四个要素：

1
2
3
4
1. 谁在使用这个结果？（用户）
2. 他们要完成什么？（目标）
3. 怎样才算完成了？（验收标准）
4. 结果以什么形式呈现？（交付物）

案例：任务管理系统

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
❌ 模糊定义:
  "做一个任务管理系统"

✅ 清晰定义:
  用户: 5 人产品团队
  目标: 追踪每个需求的从提出到上线的全流程
  验收标准:
    · 每个需求有唯一 ID、状态、负责人、截止日期
    · 状态流转: 待评审 → 进行中 → 待验收 → 已上线
    · 任何人可以看到所有需求的状态和进度
    · 每周一自动生成本周交付报告
  交付物:
    · Web 页面，支持桌面端 Chrome
    · 数据存储在本地 SQLite
    · 支持手动添加和状态变更
    · 报告以页面形式展示，可导出 Markdown

为什么这很重要？ 因为 Vibe Coding 的 AI 是”你给什么就做什么”——你给模糊指令，它做最简单的解释；你给精确定义，它做最精确的实现。结果的质量上限由你的定义精度决定。

3.3 如何描述结果

原则：用具体场景代替抽象描述

1
2
3
4
5
6
7
8
9
10
11
12
抽象描述 → AI 的理解 → 可能的结果
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
"友好的界面"  → 大字体+圆角+蓝色  → 一个幼稚的界面
"专业的界面"  → 小字体+直线+灰色  → 一个无聊的界面
"现代感"      → 渐变+阴影+动画    → 一个花哨的界面

具体场景 → AI 的理解 → 可能的结果
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
"类似 Linear 的界面风格，
 深色主题，紧凑布局，
 左侧导航栏，主内容区表格，
 每行一个任务，状态用彩色标签"  → 你想要的

描述框架:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
## 交付定义

### 1. 用户画像
- 主要用户: [角色] ，[技术水平] ，[使用频率]
- 次要用户: [角色]

### 2. 核心场景 (3-5 个)
- 场景 1: [用户] 在 [情境] 下想要 [目标] ，通过 [操作] 完成
- 场景 2: ...

### 3. 验收标准 (必须通过)
- [ ] 标准 1: 可量化的通过条件
- [ ] 标准 2: ...

### 4. 不做 (明确排除)
- 不做移动端适配
- 不做用户登录/注册（单用户场景）
- 不做实时协作

### 5. 参考
- 界面风格参考: [URL]
- 交互模式参考: [URL]
- 数据模型参考: [描述]

3.4 如何交付

Vibe Coding 时代的交付不是”代码写完了”，而是结果可用了。

1
2
3
4
5
6
7
8
9
10
11
传统交付:
  代码完成 → 代码审查 → 部署 → 验收 → 交付
  ↑ 关注代码质量

Vibe Coding 交付:
  结果可用 → 用户验证 → 迭代改进 → 交付
  ↑ 关注结果有效性

区别:
  传统: "代码是对的" ≠ "结果是有用的"
  Vibe: "结果有用" > "代码优雅"

交付节奏:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Round 1: 原型 (2-4 小时)
  · AI 生成可运行的最小实现
  · 用户验证: 方向对不对？
  · 80% 的项目在这里发现方向偏了 → 立刻调整，成本极低

Round 2: 可用版 (1-2 天)
  · 修复 Round 1 的关键问题
  · 补充核心场景的完整流程
  · 用户验证: 能不能用了？

Round 3: 完善版 (3-5 天)
  · 边界情况处理
  · 性能和体验优化
  · 用户验证: 可以交付了吗？

4. 能力三：将业务转化为代码设计

4.1 业务和代码之间的鸿沟

业务说的是人话，代码说的是机器话。中间的翻译质量决定了系统的质量。

1
2
3
4
5
6
7
8
9
10
11
12
13
业务语言:
  "客户下单后，如果库存不足，通知采购补货"
  简单明了，一句话。

代码需要回答的问题:
  · "库存不足"的定义是什么？< 0？< 安全库存？
  · "通知"是发邮件？发消息？创建工单？
  · "采购"是特定的人？还是一个团队？
  · "补货"补多少？按什么规则？
  · 如果同时有多个订单导致库存不足，怎么处理？
  · 如果采购没响应，怎么办？超时机制？
  · 下单和库存检查是同步还是异步？
  · 需要事务一致性吗？库存扣了但通知失败了怎么办？

一句话的业务需求，展开后可能有 20 个技术决策点。这些决策点如果被忽略，系统就会在边界情况下出 bug；如果被错误决策，系统就会变得过度复杂。

4.2 转化的三层模型

1
2
3
4
5
业务层:  "客户下单后，库存不足时通知采购补货"
           ↓ 转化
模型层:  事件驱动 + 领域模型
           ↓ 转化
代码层:  OrderPlaced → InventoryChecker → RestockNotifier

第一层：业务 → 领域模型

领域模型是把业务语言翻译成结构化的概念和关系：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
业务: "客户下单后，库存不足时通知采购补货"

领域模型:
  实体 (Entity):
    · Order (订单): id, items, customer, status, created_at
    · Product (商品): id, name, stock, safety_stock
    · RestockRequest (补货请求): id, product, quantity, status, created_at

  值对象 (Value Object):
    · Money: amount, currency
    · Address: street, city, zip

  事件 (Event):
    · OrderPlaced: order_id, items
    · StockInsufficient: product_id, current_stock, safety_stock
    · RestockRequested: request_id, product_id, quantity

  规则 (Business Rule):
    · 库存不足 = current_stock < safety_stock
    · 补货量 = safety_stock × 2 - current_stock
    · 补货请求超时 = 24h 未响应 → 升级通知

第二层：领域模型 → 技术架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
架构决策清单:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 通信模式:
   · 同步 (REST) vs 异步 (事件驱动)
   → 补货通知是异步事件，不应阻塞下单流程
   → 选择: 事件驱动

2. 数据一致性:
   · 强一致 (分布式事务) vs 最终一致 (Saga)
   → 下单和库存是强一致（不能超卖）
   → 补货通知是最终一致（可以延迟）
   → 选择: 下单用事务，补货用异步

3. 存储选择:
   · 关系型 (PostgreSQL) vs 文档型 (MongoDB)
   → 订单和库存有强关联，需要事务
   → 选择: PostgreSQL

4. 通知方式:
   · 邮件 vs 站内消息 vs IM
   → 看采购团队用什么沟通
   → 选择: 先做 IM 通知，预留邮件扩展

第三层：技术架构 → 代码结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
src/
  domain/           # 领域模型（纯逻辑，无外部依赖）
    order.py        # Order 实体和规则
    product.py      # Product 实体和库存规则
    events.py       # 领域事件定义

  application/      # 应用服务（编排领域逻辑）
    order_service.py
    inventory_service.py
    restock_service.py

  infrastructure/   # 基础设施（外部交互）
    database.py
    message_queue.py
    notifier.py

  api/              # 对外接口
    routes.py

4.3 Vibe Coding 时代的转化策略

在 Vibe Coding 时代，你不需要手写上面的每一行代码。但你需要写好领域模型和架构决策——然后让 AI 根据这些设计生成代码。

1
2
3
4
5
6
7
8
传统: 需求文档 → 手写所有代码
Vibe: 领域模型 + 架构决策 → AI 生成代码 → 人工审查关键逻辑

你花时间的重点:
  · 定义领域模型 (30%)
  · 做架构决策 (20%)
  · 审查 AI 生成的代码 (30%)
  · 处理边界和异常 (20%)

给 AI 的设计指令示例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
请基于以下领域模型和架构决策生成代码:

## 领域模型
- Order: id, items[], customer, status, created_at
- Product: id, name, stock, safety_stock
- 事件: OrderPlaced → 检查库存 → StockInsufficient → 创建 RestockRequest

## 架构决策
- 事件驱动，使用 asyncio 事件总线
- PostgreSQL 存储，SQLAlchemy ORM
- 下单和库存扣减在同一个事务中
- 补货通知异步发送

## 代码结构
- domain/ 纯逻辑，无外部依赖
- application/ 编排
- infrastructure/ 外部交互

## 验收标准
- 下单时库存扣减失败 → 订单回滚
- 库存 < safety_stock → 创建 RestockRequest
- RestockRequest 24h 未响应 → 日志警告

这样 AI 生成的代码比”写一个订单系统”精确 100 倍。

5. 能力四：拆解问题与子任务

5.1 为什么拆解是核心能力

Vibe Coding 的 AI 有一个根本局限：它能做好一个明确的任务，但不能自行发现和拆解模糊的任务。

1
2
3
4
5
6
7
8
9
10
11
12
13
给 AI 一个大任务:
  "做一个电商后端"
  → AI 会生成一个"标准"电商后端
  → 80% 的代码你可能要重写
  → 因为你需要的是"你的"电商后端，不是"标准"的

给 AI 一组小任务:
  1. "设计商品和订单的领域模型，商品有 SKU/价格/库存，订单有状态流转"
  2. "基于上述模型，实现商品 CRUD API"
  3. "实现下单流程：创建订单 → 扣减库存 → 发送确认通知"
  4. "实现库存不足时的补货通知逻辑"
  → 每个小任务 AI 都能做得很精确
  → 组合起来就是"你的"电商后端

核心原则: 每个子任务应该足够小，使得 AI 一次生成就能正确；又足够大，使得每个子任务有独立的价值。

5.2 拆解的维度

一个问题可以从多个维度拆解。选择哪个维度，取决于问题的性质：

维度 1: 按功能模块拆解（最常见）

1
2
3
4
5
6
7
8
9
问题: "做一个项目管理工具"

按功能模块拆解:
  1. 项目 CRUD
  2. 任务 CRUD（含状态流转）
  3. 成员管理
  4. 时间线/甘特图
  5. 通知系统
  6. 报表/统计

适合：功能边界清晰、模块之间耦合度低的系统。

维度 2: 按用户旅程拆解

1
2
3
4
5
6
7
问题: "做一个外卖 App"

按用户旅程拆解:
  1. 浏览餐厅 → 看到菜品 → 加入购物车
  2. 确认订单 → 选择地址 → 支付
  3. 等待配送 → 查看骑手位置 → 收到外卖
  4. 评价 → 积分 → 复购

适合：以用户操作流程为核心的产品，每个旅程可以独立交付。

维度 3: 按风险拆解

1
2
3
4
5
6
7
问题: "做一个 AI 客服系统"

按风险拆解:
  1. (高风险) AI 回答准确性 → 先做一个最小验证：100 条测试问答
  2. (高风险) 意图识别准确率 → 先做意图分类器的 benchmark
  3. (中风险) 上下文管理 → 多轮对话的记忆机制
  4. (低风险) 界面和交互 → 最后做

适合：有技术不确定性的项目。先验证最大风险，避免在错误方向上投入大量时间。

维度 4: 按数据流拆解

1
2
3
4
5
6
7
8
问题: "做一个实时数据监控平台"

按数据流拆解:
  1. 数据采集: 从 Kafka 消费数据
  2. 数据处理: 聚合、过滤、异常检测
  3. 数据存储: 时序数据库写入
  4. 数据展示: WebSocket 推送 + 前端图表
  5. 告警: 阈值触发 → 通知

适合：数据密集型系统，按数据的生命周期拆解。

5.3 子任务的颗粒度

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
太大: "实现用户系统"
  → AI 会生成一个通用的用户系统，可能不符合你的需求
  → 需要继续拆分

太大: "实现登录注册"
  → 还是太模糊——邮箱登录？手机登录？OAuth？
  → 需要继续拆分

合适: "实现邮箱密码注册，密码用 bcrypt 加密，注册后发送验证邮件"
  → 足够具体，AI 一次就能做对
  → 有独立的验收标准

太小: "写一个 bcrypt 加密函数"
  → 这种粒度让 AI 做反而更慢——你花在描述上的时间比写代码还长
  → 应该合并到更大的任务中

原则: 每个子任务 = 一个 AI 提示词 = 一次代码生成 = 一次验证

5.4 子任务的依赖和顺序

拆解后需要排列执行顺序。核心原则：先做阻塞其他任务的任务，先做验证假设的任务。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
项目管理工具的任务依赖图:

  [数据模型设计] ──→ [项目CRUD] ──→ [任务CRUD] ──→ [甘特图]
       │                                  │
       └────→ [成员管理] ───────────────→ [通知系统]
                                                   │
                                            [报表统计]

执行顺序:
  1. 数据模型设计 (所有后续任务依赖它)
  2. 项目 CRUD + 成员管理 (可以并行)
  3. 任务 CRUD (依赖项目)
  4. 通知系统 + 甘特图 (依赖任务)
  5. 报表统计 (依赖所有数据)

Vibe Coding 的并行优势: 不同子任务可以分配给不同的 AI 会话并行执行。前提是数据模型已经设计好，接口契约清晰。

5.5 拆解实操：一个完整案例

问题: “给我做一个个人博客系统”

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
第 1 步: 理解本质问题
━━━━━━━━━━━━━━━━━━━━━━
  表面需求: "个人博客系统"
  五层追问:
    → 为什么要博客？→ 分享技术文章
    → 为什么不用现成平台？→ 想要自定义样式和域名
    → 为什么自定义很重要？→ 个人品牌
    → 什么样的文章？→ 技术深度文章，需要代码高亮
    → 谁看？→ 开发者社区

  本质问题: 一个面向开发者读者的技术写作与发布平台

第 2 步: 定义交付结果
━━━━━━━━━━━━━━━━━━━━━━
  用户: 我自己（唯一作者）
  目标: 写技术文章，发布到个人域名，被搜索引擎收录
  验收标准:
    - 支持 Markdown 写作，代码高亮
    - 文章有标签和分类
    - SEO 友好（SSG 或 SSR）
    - 响应式设计，移动端可读
    - 页面加载 < 2s
    - 部署到 Vercel
  不做:
    - 不做评论系统（用讨论区链接替代）
    - 不做 CMS 后台（直接写 Markdown 文件）
    - 不做用户系统

第 3 步: 业务 → 代码设计
━━━━━━━━━━━━━━━━━━━━━━
  领域模型:
    · Post: slug, title, date, tags, categories, content_md, excerpt
    · 没有更复杂的实体——这是静态博客

  架构决策:
    · Hexo / Hugo 静态生成 → Vercel 部署
    · 不需要后端服务器
    · 代码高亮用 Prism.js
    · 评论用 Giscus (GitHub Discussions)

第 4 步: 拆解子任务
━━━━━━━━━━━━━━━━━━
  T1: 初始化 Hexo 项目 + 基础配置 (主题、部署)
  T2: 创建文章模板和 frontmatter 规范
  T3: 配置代码高亮和 Markdown 扩展
  T4: 实现标签和分类页面
  T5: 实现响应式布局和移动端优化
  T6: 配置 SEO（sitemap、meta tags、Open Graph）
  T7: 配置 Giscus 评论
  T8: 配置 Vercel 部署和自定义域名
  T9: 写一篇样例文章验证全流程
  T10: 性能优化（图片压缩、字体加载、缓存策略）

  依赖关系: T1 → T2-T8 (可并行) → T9 → T10

6. 四种能力的关系

这四种能力不是孤立的，它们形成一条链：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
理解本质问题 → 定义交付结果 → 业务转代码设计 → 拆解子任务
     ↑                                    │
     └──────────── 反馈循环 ←──────────────┘

理解问题 → 你知道要解决什么
定义结果 → 你知道"完成"长什么样
转译设计 → 你知道怎么做
拆解任务 → 你知道先做什么后做什么

每一步的输出是下一步的输入。
任何一步做不好，后面全白费。

反过来，拆解执行中的发现会回溯修正前面的认知:
  · 拆解时发现任务太多 → 可能问题定义太大，需要缩小范围
  · 设计时发现领域模型太复杂 → 可能业务理解不够深，需要简化
  · 执行时发现 AI 生成的代码总不对 → 可能设计描述不够精确

一个诊断清单:

1
2
3
4
5
6
7
8
如果 AI 生成的代码总是不对:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  代码偏离业务意图     → 问题 1: 你没有理解本质问题
  AI 做的不是你要的    → 问题 2: 你没有精确定义结果
  代码结构混乱        → 问题 3: 你没有做好领域建模
  单个任务 AI 做不好   → 问题 4: 子任务拆得太大或太模糊
  子任务之间对不上     → 问题 4: 拆解时没有定义接口契约
  反复修改无法收敛     → 问题 2: 验收标准不清晰

7. Vibe Coding 时代的新工作流

7.1 从编码者到架构者

1
2
3
4
5
6
7
8
9
传统程序员的工作流:
  需求 → 设计 → 编码 → 测试 → 调试 → 部署
                   ↑ 70% 的时间在这里

Vibe Coder 的工作流:
  理解问题 → 定义结果 → 建模设计 → 拆解任务 → AI生成 → 审查 → 集成
     ↑                                                    ↑
     60% 的时间                                         30% 的时间
     (思考)                                             (审查和集成)

**编码时间占比从 70% 降到 10%**。但总工作量没有减少——思考的工作量增加了。

7.2 新的核心技能树

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Vibe Coding 时代的技能树:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

核心 (不可替代):
  ├── 业务分析能力
  │   └── 识别真问题 vs 伪问题
  ├── 系统设计能力
  │   └── 领域建模 + 架构决策
  ├── 任务拆解能力
  │   └── 颗粒度控制 + 依赖排序
  └── 代码审查能力
      └── 快速判断 AI 代码的正确性和质量

重要 (增强效率):
  ├── 提示词技巧
  │   └── 如何精确描述需求给 AI
  ├── 工具链掌握
  │   └── Cursor / Claude Code / Devin 等
  └── 集成和调试
      └── 把 AI 生成的多个模块组装起来

次要 (AI 可以替代):
  ├── 语法记忆
  │   └── 不需要背 API，AI 知道
  ├── 模板代码
  │   └── CRUD / 样板代码，AI 秒生成
  └── 日常调试
      └── AI 可以定位大部分 bug

7.3 最大的陷阱

Vibe Coding 最大的陷阱是跳过思考直接生成。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
陷阱流程:
  需求 → 立刻让 AI 写代码 → 看到结果 → 不满意 → 修改 → 不满意 → 修改 → ...

  为什么是陷阱:
    · 没有理解问题 → AI 解决了错误的问题
    · 没有定义结果 → 你不知道什么时候算"做好了"
    · 没有设计 → AI 生成的代码结构混乱
    · 没有拆解 → AI 一次处理太多，质量下降
    · 反复修改 → 比手写还慢

正确流程:
  需求 → 思考 1 小时 → 定义清楚 → 让 AI 写代码 → 审查 30 分钟 → 完成

  "慢思考，快执行"

8. 结论

Vibe Coding 时代，代码从稀缺资源变成了充裕资源。稀缺的是想清楚要写什么代码的能力。

这四种能力——理解业务本质问题、定义交付结果、业务转代码设计、拆解问题与子任务——不是新能力。它们一直是优秀工程师的核心竞争力。只是过去被”写代码”这个体力活掩盖了。

当写代码不再是瓶颈，这些能力从”加分项”变成了”决定项”。一个想不清楚的人配上最强的 AI，产出仍然是一堆方向错误的代码。一个想清楚的人配上最强的 AI，产出是精准解决问题的系统。

代码是廉价的，思考是昂贵的。 Vibe Coding 让这个事实变得无法忽视。

最后一句：Vibe Coding 的本质不是”用 AI 写代码”，而是”把思考从编码中解放出来”。 解放出来的思考力，才是这个时代真正稀缺的东西。

本文观点形成于与 AI 的协作实践，而非理论推演。Vibe Coding 仍在快速演化，最佳实践会持续变化——但思考的价值不会。

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

程序员，关于技术我所知甚少，唯有探索，方得真知。