2.2 VibeCoding 工作流

---

1. 为什么要学这个?

很多新手是这样用AI的:

"帮我写个贪吃蛇。" → AI写了一坨代码 → 跑不起来 → "你写错了,再改改。" → AI又改了一坨 → 还是跑不起来。

这就是典型的**"盲目发射"。你把AI当成了许愿池**,扔个硬币(提示词)就指望它吐出完美结果。

想象你是钢铁侠。

• 错误方式:穿上机甲后闭上眼睛,喊一句"去打坏人",然后就睡觉了。
• 正确方式:你时刻盯着屏幕,告诉JARVIS"瞄准左边那个","火力调到80%","现在发射"。

关键理解:

• AI不是神,它是一个极其强大但需要引导的超级实习生
• 你是指挥官,AI是执行者
• 人在环路(HITL),时刻微调AI的输出

---

2. 核心概念

2.1 你 - 指挥官

技术定义:在Vibe Coding中,人类负责创造力、审美、业务逻辑,AI负责执行。

就像钢铁侠Tony Stark。

• 职责:你有创造力、有审美、懂业务逻辑。但你记忆力有限,手速慢。
• 任务:决定"我们要做什么","这个功能要怎么设计"。

2.2 AI - 机甲

技术定义:AI像JARVIS一样,计算速度快,记忆力强,精通所有编程语言,但没有"灵魂"。

就像钢铁侠的机甲JARVIS。

• 职责:计算速度无限,记忆力无限,精通所有编程语言。但它不知道什么是"好设计"。
• 任务:负责"瞄准锁定","计算弹道","输出火力(代码)"。

graph TD
    A[你/指挥官] --> B[发送意图]
    B --> C[AI/JARVIS]
    C --> D[生成草稿代码]
    D --> E[你检查/Vibe Check]
    
    E --> F{满意吗?}
    F -->|不满意| G[微调/追问]
    G --> C
    F -->|满意| H[Git Commit存档]
    
    style A fill:#e1f5ff
    style C fill:#fff3e0
    style D fill:#f3e5f5
    style E fill:#e8f5e9
    style F fill:#fff3e0
    style H fill:#e1f5ff

---

3. 5步标准工作流

🔍 Step 1: 探索

让AI先看一眼现在的环境,建立短期记忆。

# 指令示例
"@Codebase 帮我梳理一下当前项目的目录结构,我准备在src/app下新增一个用户页面。"

目的:避免AI瞎编不存在的文件路径。

📝 Step 2: 规划

让AI先写方案,不写代码。

# 指令示例
"基于上述结构,请列出实现用户页面的步骤。不要写代码,只列步骤。"

目的:对齐认知。如果这一步它理解歪了,后面写多少代码都是废的。

💻 Step 3: 编码

确认步骤无误后,让它分步执行。

# 指令示例
"好,执行第一步:创建组件文件。"

技巧:小步快跑。一次只写一个功能点,不要让它一次性写10个文件。

✅ Step 4: 验证

运行代码,肉眼检查。

# 关键动作
1. 运行 pnpm dev
2. 检查页面效果
3. 如果有报错,把完整报错日志发给AI

关键:Vibe Check。用你的直觉去感觉——按钮颜色对吗?交互流畅吗?

💾 Step 5: 存档

功能正常后,立刻提交。

# 指令示例
"功能正常,生成一条Git Commit Message,中文。"

目的:游戏存档。防止下一次AI改乱了回不去。

---

4. 什么时候用这套流程?

🎯 场景	严格程度	理由
修改一个按钮颜色	🟢 随意	这种小事,直接让AI改就行
新增一个页面	🟡 标准5步	复杂度足以让AI迷路,必须规划
重构数据库	🔴 超级严格	必须先写技术文档,人肉确认无误后再动工

---

5. 避坑指南

❌ 不要这样做	✅ 应该这样做	为什么
"帮我把整个项目重构了"	"先重构Header组件"	步子迈太大,AI会顾头不顾腚,改崩整个项目
盲目信任AI的代码	必须Review每行代码	AI经常会引入不存在的库(幻觉)
不给上下文就让AI写代码	用@引用相关文件	AI不知道你有utils.ts,会自己造一个重复的
一次性让AI写10个文件	一次只写一个功能点	AI会晕,容易出错

---

6. 真实案例

---

7. 本章小结

1. 🧠 角色认知:你是指挥官(Tony),AI是机甲(JARVIS)
2. 🔄 核心流程:探索→规划→编码→验证→存档
3. 👁️ HITL原则:人在环路,永远不要让AI脱离你的视线独自干活
4. 📦 小步快跑:一次只做一个功能点,不要贪多
5. ✅ 必须Review:AI会幻觉,每行代码都要扫一眼