Vibe Coding 实战开发手册：从 Prompt 驱动到决策驱动

以前我理解 Vibe Coding，很容易把重点放在：

怎么写 Prompt
怎么让 AI 生成 PRD
怎么让 AI 设计架构
怎么让 AI 写代码
怎么让 AI 自动测试

但真正做项目以后，我越来越发现：

Prompt 不是 Vibe Coding 的核心。

真正推动项目向前的，是：

讨论 → 判断 → 决策 → 文档 → Task → 执行 → 验证 → 反馈

Prompt 只是其中偶尔使用的控制工具。

如果项目本身没有被想清楚，再长的 Prompt 也只是让 AI 更有条理地执行一个模糊目标。

而如果项目目标、系统边界、任务范围和验证标准已经明确，很多时候一句：

读取项目文档，执行 T03。先给 Plan，不修改代码。

就已经足够。

所以这一版 Vibe Coding 方法，不再围绕“每一步该用什么 Prompt”展开。

而是围绕三个真正发生在开发中的循环：

1
2
3
4
5
6
7
探索循环
↓
施工循环
↓
产品循环
↓
重新进入探索循环

一、先重新定义 Vibe Coding

Vibe Coding 不是：

我描述需求，AI 帮我把代码写出来。

也不是：

我写一个超级 Prompt，让 AI 自动完成整个项目。

更准确地说：

人负责发现问题、判断价值、做关键决策和确认边界；AI 负责扩大分析能力、生成方案、整理文档和完成大量执行工作；系统通过文档、测试、Git、Trace 等机制把双方约束起来。

因此一个真正可上线的 Vibe Coding 项目，不应该是：

1
2
3
4
5
6
7
一句 Prompt
↓
AI 写代码
↓
跑起来
↓
完成

而应该是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
真实问题
↓
人与 AI 讨论
↓
形成决策
↓
沉淀项目事实
↓
拆成可验证任务
↓
AI 自主施工
↓
测试 / Review / Git
↓
真实使用
↓
发现新问题
↓
重新讨论

Vibe Coding 的核心不是“让 AI 替我开发”。

而是：

把人的判断能力和 AI 的执行能力组合成一个工程系统。

二、整个开发过程其实只有三个循环

以前我喜欢把开发拆成很多阶段：

1
2
3
4
5
6
7
8
9
Idea
→ Problem
→ Discovery
→ PRD
→ Architecture
→ Task
→ Coding
→ Test
→ Deployment

这些阶段本身没有错。

但实际开发并不会严格一格一格向前。

真实情况更像三个不断嵌套的循环。

三、第一个循环：探索循环

探索循环解决的问题是：

我们到底应该做什么？

它不是“写需求文档”。

而是一段不断从模糊走向明确的过程。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
观察
↓
提出问题
↓
AI 帮助分析
↓
发现新的变量 / 矛盾 / 边界
↓
继续讨论
↓
做出判断
↓
形成共识
↓
记录到项目文档

例如我做一个真实业务项目时，一开始可能只有一句：

我想把现在人工处理的业务流程做成一个 Agent。

这还不能开发。

首先要继续问：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
现在到底哪里痛？
↓
哪些是事实？
↓
哪些只是我的猜测？
↓
真正影响结果的是什么？
↓
现在为什么要人工做？
↓
AI 能解决哪一部分？
↓
哪一部分其实普通程序就够了？
↓
V1 到底做到哪里？

这整个过程不需要先设计一套复杂 Prompt。

我完全可以直接和 AI 讨论。

AI 给出判断，我不接受就继续反驳。

我发现异常，就继续补充业务情况。

AI 提出方案，我判断是否符合真实工作。

讨论过程中，系统会不断收敛。

四、探索循环不是“让 AI 替我思考”

这里有一个非常重要的边界。

AI 可以：

提候选方案
找遗漏
挑战假设
分析机制
帮我整理结构
比较不同路径

但不能因为 AI 说：

“我认为应该增加一个 RAG 模块。”

就自动变成项目事实。

正确的过程应该是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
AI：建议增加 RAG
↓
人：为什么？
↓
AI：解决什么问题？
↓
人：这个问题真实存在吗？
↓
如果存在：
    是否值得现在解决？
↓
如果值得：
    有没有更简单方案？
↓
最终决定

所以：

AI 可以扩展解空间，但人要负责收敛。

这就是 Vibe Coding 中非常重要的人机分工。

五、探索什么时候算结束？

其实没有一个绝对的“结束”。

更准确地说：

当某一件事已经讨论到可以明确说“就这么定”，就把它冻结下来。

例如：

V1 不接 RAG。

这就是一个决策。

文章切分先采用纯逻辑规则，不引入 LLM。

这是一个决策。

系统由 Parent Runtime Graph 和 Article Agent Subgraph 组成。

也是一个决策。

一旦确定，就不要只停留在聊天记录里。

应该马上变成项目事实。

六、文档不是开发阶段，而是项目的外部记忆

以前容易把文档理解成：

1
2
3
4
5
先写 PRODUCT.md
↓
再写 SYSTEM.md
↓
再写 DECISIONS.md

但实际开发不是这样。

更好的理解是：

文档是不同类型项目事实的存储容器。

讨论产生什么事实，就写进对应文档。

PRODUCT.md：产品事实

记录：

1
2
3
4
5
6
为什么做？
给谁做？
解决什么问题？
V1 做什么？
V1 不做什么？
什么叫成功？

它回答的是：

我们到底在造什么？

SYSTEM.md：系统事实

记录：

1
2
3
4
5
6
7
业务流程
数据流
控制流
失败流
核心状态
模块边界
组件关系

它回答：

这个系统实际上应该怎么运行？

DECISIONS.md：决策历史

这里非常重要。

不要只记录：

最终用了什么。

还要记录：

1
2
3
4
5
6
Problem
Options
Decision
Reason
Rejected Alternatives
Re-evaluate When

因为过几个月以后，最容易忘的不是：

当时用了什么。

而是：

为什么当时没用另外一种方案？

TASKS.md：当前工作

TASK 不是功能愿望清单。

它应该是：

一个可以独立实现、独立验证的问题单元。

每个 Task 最少包含：

1
2
3
4
5
6
Goal
Input
Output
Scope
Constraints
Acceptance

一个好的 Task 应该让 Worker 看完以后知道：

1
2
3
我要解决什么？
不能动什么？
做成什么样算完成？

BUILD.md：施工合同

这是专门给 AI Worker 的。

它不是产品设计文档。

它规定的是：

在已经确定的项目边界内，AI 被允许怎样工作。

例如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
先读代码
↓
理解调用链
↓
最小改动
↓
不做无关重构
↓
写测试
↓
运行测试
↓
检查 diff
↓
一个问题单元一个 commit

以及 AI 必须停止的情况：

1
2
3
4
5
需求出现冲突
核心架构需要改变
接口需要重大调整
数据库 Schema 要变化
出现重大权限 / 安全 / 成本风险

这些情况不能由 Worker 偷偷“顺手优化”。

必须重新回到人的决策层。

七、所以文档真正形成的是项目共享记忆

可以把整个项目理解成：

1
2
3
4
5
6
7
聊天
↓
产生理解
↓
做出决策
↓
写入文档

以后 AI 不需要依赖几十轮聊天上下文。

只需要读取：

1
2
3
4
5
PRODUCT.md
SYSTEM.md
DECISIONS.md
TASKS.md
BUILD.md

就可以恢复项目上下文。

于是：

1
2
3
4
5
聊天 = 临时思考空间
文档 = 已确认事实
代码 = 当前实现
测试 = 正确性证据
Git = 历史记录

这几个东西共同构成真正的项目记忆。

八、Prompt 的地位应该下降

以前我容易保存很多 Prompt：

1
2
3
4
5
6
7
Problem Discovery Prompt
Product Prompt
Architecture Prompt
Pre-Mortem Prompt
Task Prompt
Build Prompt
Review Prompt

后来我发现：

这些东西可以有，但不能把开发变成“Prompt 流程表”。

因为真正的情况是：

有时候我一句：

这里是不是还有一个问题？

整个系统设计就会发生变化。

有时候 AI 会主动指出我遗漏的边界。

有时候我根据真实业务经验，直接否决一个理论上更高级的方案。

真实开发是动态的。

所以 Prompt 应该成为：

思考卡住或者 AI 开始失控时的脚手架。

而不是开发流程本身。

九、什么时候才需要 Prompt？

我现在会把 Prompt 用在几种情况。

讨论开始发散时

例如：

现在不要继续给方案，先帮我区分哪些是事实、哪些是假设，真正需要验证的问题是什么。

AI 开始过度设计时

不要增加任何新模块。先说明当前问题是什么、现有设计为什么不足、最小修改方案是什么。

我自己卡住时

给我三种候选方案，但不要替我决定。分别说明解决的问题、机制、成本、风险和什么时候不值得使用。

Worker 进入施工时

甚至只需要：

读取项目文档和代码，执行 T03。先输出 Plan，不修改代码。

Prompt 是杠杆。

不是驾驶方向盘。

十、第二个循环：施工循环

当 Product 和 System 已经足够清楚以后，项目进入施工。

这里最重要的一条原则是：

不要把整个项目一次性交给 AI。

AI 的自主权应该存在于一个已经批准的问题单元内部。

整个结构是：

1
2
3
4
5
Project
↓
Task
↓
AI Worker

项目级方向由人控制。

Task 级目标由人和 AI 共同确认。

Task 内部实现可以高度自动化。

十一、每一个 Task 的施工流程

标准循环：

 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
选择 Task
↓
AI 读取项目文档
↓
AI 读取相关代码
↓
AI 输出 Plan
↓
Review
↓
批准
↓
AI 实现
↓
AI 写 / 修改测试
↓
运行测试
↓
修复
↓
重新测试
↓
检查 Git Diff
↓
Review
↓
Commit
↓
记录 CHANGELOG
↓
Next Task

这里最重要的不是每一步都要人工点击确认。

而是：

人的介入发生在关键 Gate，而不是每一个 AI Action。

十二、AI 自主 ≠ AI 随便改

这是施工阶段非常容易混淆的地方。

当一个 Task 已经批准以后：

AI 可以自己决定：

1
2
3
4
5
函数怎么拆
变量怎么命名
测试怎么写
Bug 怎么定位
小范围怎么重构

这些不值得每一步都问人。

但 AI 不能自己决定：

1
2
3
4
5
6
修改产品目标
扩大 Task 范围
换掉核心架构
增加一个大型基础设施
改变业务规则
修改关键接口

所以自主权应该是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
             人
             ↓
      项目目标 / 边界
             ↓
          Task Gate
             ↓
       ┌──────────┐
       │ AI 自主区 │
       │          │
       │ Code     │
       │ Test     │
       │ Debug    │
       │ Refactor │
       └────┬─────┘
            ↓
        Review Gate
            ↓
           Git

这是我认为最适合 Vibe Coding 的授权方式。

十三、为什么必须先 Plan？

Plan 不是为了多一道手续。

而是为了在代码改变以前，先暴露 AI 的理解。

如果 AI 的 Plan 写成：

顺便重构整个 Tool Registry。

而当前 Task 只是：

增加一个字段。

那我在 AI 写几百行代码以前就可以发现：

它理解错范围了。

所以：

1
Plan Review

实际上是在检查：

AI 对当前任务的系统模型是否和我一致。

这比代码写完以后再返工便宜得多。

十四、为什么一定要看 Diff？

测试通过，并不代表改动正确。

可能出现：

1
2
测试绿了
但 AI 顺便删了别的逻辑

或者：

1
2
功能实现了
但偷偷修改了公共接口

甚至：

1
2
结果正确
但实现范围远远超出 Task

所以验证至少应该有三层：

1
2
3
4
5
Result
+
Test
+
Diff

高风险功能还需要再看：

1
2
3
4
5
调用路径
数据流
状态变化
权限变化
失败路径

十五、AI 说“完成了”不是证据

这条一定要单独记住。

1
AI：已经完成并验证。

只能证明：

AI 生成了这句话。

真正的证据是：

1
2
3
4
5
6
测试结果
实际输出
Git Diff
调用路径
日志
验收结果

所以：

AI 的结论是信息，系统证据才是事实。

十六、Git 在 Vibe Coding 里不是普通版本控制

传统学习代码时，Git 可能只是：

保存版本。

但在 AI 大量参与施工以后，Git 其实承担了更多角色。

它同时是：

1
2
3
4
5
安全边界
历史记录
回滚能力
变更审计
实验记录

所以我会坚持：

一个独立可验证的问题单元，一个 Commit。

不是：

每改一行 Commit。

也不是：

一整个星期最后 Commit 一次。

而是：

1
2
3
4
5
6
7
8
9
Task
↓
实现
↓
测试
↓
Review
↓
Commit

这样以后才能知道：

到底是哪一次决策让系统发生了变化。

十七、CHANGELOG 保存的是“实际上发生了什么”

项目文档描述的是：

应该怎样。

Git 描述的是：

每一份代码变化。

而 CHANGELOG 更适合记录：

实际完成了什么重要变化。

例如：

1
2
3
4
5
6
7
T03 完成

- 新增 ArticleAgent 子图
- 接入 Parent Runtime Graph
- 新增对应单测
- 全量测试通过
- 未修改原有 Tool Registry 接口

它让人和 AI 能快速恢复项目进度。

十八、什么时候 AI 必须停止？

这是整个施工循环真正的安全阀。

如果 Worker 遇到：

1
2
3
4
5
6
7
8
9
Task 和 PRODUCT 冲突
Task 和 SYSTEM 冲突
现有架构无法支持需求
必须改变核心接口
必须改变数据库结构
必须新增核心组件
出现严重安全风险
出现权限边界变化
成本大幅变化

正确行为不是：

AI 自己想办法继续。

而是：

1
2
3
4
5
6
7
8
9
停止
↓
报告事实
↓
说明为什么现有规则不足
↓
列出候选方案
↓
人做决策

然后：

1
2
3
更新 SYSTEM / DECISIONS / TASKS
↓
重新施工

也就是说：

施工不能偷偷修改设计。

十九、第三个循环：产品循环

代码全部完成，并不代表项目完成。

真正的 Product 必须进入现实。

所以第三个循环是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
构建完成
↓
E2E
↓
部署
↓
真实使用
↓
观察
↓
反馈
↓
发现新问题
↓
重新进入探索循环

这个循环非常重要。

因为很多问题在开发阶段根本不存在。

只有真实用户开始使用以后才会出现。

例如：

1
2
3
4
5
用户根本不用某功能
流程太复杂
AI 经常在某类输入上失败
某个接口成本远高于预期
用户真正需要的是另一个结果

这些不是“Bug”。

它们可能意味着：

一开始的问题定义就不完整。

二十、真实反馈不能直接变成需求

用户说：

能不能加一个按钮？

不能直接：

1
新增按钮 Task

而应该先重新回到探索循环：

1
2
3
4
5
6
7
为什么需要这个按钮？
↓
用户现在遇到了什么问题？
↓
这个按钮是解决方案，还是问题本身？
↓
有没有更简单的解决方式？

所以：

用户反馈首先是观察，不是需求。

这一点和最初 Problem Discovery 完全一样。

二十一、整个 Vibe Coding 的真正闭环

现在整套方法可以压缩成：

 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
            ┌──────────────┐
            │   探索循环    │
            │              │
            │ Observe      │
            │ Discuss      │
            │ Decide       │
            │ Document     │
            └──────┬───────┘
                   ↓
            ┌──────────────┐
            │   施工循环    │
            │              │
            │ Task         │
            │ Plan         │
            │ Build        │
            │ Test         │
            │ Review       │
            │ Git          │
            └──────┬───────┘
                   ↓
            ┌──────────────┐
            │   产品循环    │
            │              │
            │ Deploy       │
            │ Use          │
            │ Observe      │
            │ Feedback     │
            └──────┬───────┘
                   │
                   └────────→ 探索循环

再压缩就是：

Discuss → Decide → Document → Task → Build → Verify → Git → Use → Learn

二十二、人、AI、系统到底分别负责什么？

这也是我现在对 Vibe Coding 最清楚的一次划分。

人

主要负责：

1
2
3
4
5
6
What
Why
Boundary
Risk
Decision
Acceptance

也就是：

我们为什么做、做什么、做到哪里、什么风险可以接受、什么叫成功。

AI

主要负责：

1
2
3
4
5
6
7
8
9
Analyze
Search
Structure
Document
Read
Implement
Test
Debug
Refactor

AI 越来越强以后，这部分会继续扩大。

系统

负责：

1
2
3
4
5
6
7
Permission
Test
Trace
Git
Rollback
Monitor
Recovery

它解决的是：

人不可能实时盯着 AI 每一个动作，那应该靠什么控制？

答案不是：

每一步都让人确认。

而是：

把控制变成系统机制。

二十三、AI 能力和 AI 权限是两回事

这是 Vibe Coding 里越来越重要的一条规律。

例如 AI 有能力：

1
2
3
4
删除数据库
修改生产配置
部署服务器
重构整个系统

不代表它应该默认获得这些权限。

所以设计 Agent 时要区分：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
Capability
↓
AI 能不能做？

Permission
↓
允许它做什么？

Authority
↓
哪些事情它可以最终决定？

尤其高风险行为：

1
2
3
4
5
生产环境
数据删除
支付
权限变更
不可逆操作

不能因为 AI 足够聪明就默认完全放权。

二十四、Vibe Coding 的目标不是减少人，而是改变人的位置

传统开发里，人负责：

1
2
3
4
5
6
想
设计
写
测
改
部署

AI 越来越强以后：

1
2
3
AI
↓
承担更多执行

那么人的位置应该逐渐上移：

1
2
3
4
5
6
7
8
9
执行
↑
Review
↑
System
↑
Product
↑
Problem

最终：

AI 负责越来越多的 How，人负责越来越清楚的 What、Why、Boundary 和 Result。

这也是我现在理解 Vibe Coding 最大的变化。

二十五、我以后真正需要培养的能力

因此我的目标不是：

成为最会 Vibe Coding 的人。

也不是：

收集最多 Prompt。

而是训练下面这条能力链：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
发现真实问题
↓
区分事实和猜测
↓
理解底层机制
↓
判断是否值得解决
↓
定义 Product
↓
设计 System
↓
划定 AI 边界
↓
把问题拆成 Task
↓
让 AI 自主执行
↓
验证结果
↓
从现实重新学习

可以压缩成：

Problem → Product → System → Agent → Harness → Verification

二十六、那我还需不需要学代码？

需要。

但学习目标也应该改变。

不是为了和 AI 比：

谁写代码快。

而是至少要有能力看懂：

1
2
3
4
5
6
7
入口
模块
接口
调用链
数据流
State
Control Flow

并且能够判断：

1
2
3
4
5
AI 改了哪里？
为什么改？
有没有越界？
会影响什么？
测试为什么能够证明它？

以后 AI 越强，我手写的代码可能越少。

但：

如果完全看不懂 AI 改了什么，就没有真正掌握系统。

二十七、Vibe Coding 不是“不需要懂”

恰恰相反。

它只是把要求从：

全部亲手完成。

变成：

必须能够理解、判断和负责。

过去一个人可能需要：

1
2
70% 执行
30% 判断

AI 时代可能逐渐变成：

1
2
20% 执行
80% 判断 / Review / System

所以 AI 并没有消灭工程能力。

而是把工程能力的价值重新分配了。

二十八、最终我只保留几条规则

如果以后忘记整篇文章，只需要记住下面这些。

1. 真实问题先于技术

不要：

1
2
3
我学了 RAG
↓
哪里能用？

而应该：

1
2
3
4
5
6
7
问题
↓
机制
↓
需要什么能力
↓
技术

2. 对话先于 Prompt

Prompt 是辅助思考的脚手架。

不是开发流程。

3. 决策必须沉淀

聊天里说过不算项目事实。

确认以后写入文档。

4. 文档记录“应该怎样”

1
2
3
4
5
PRODUCT
SYSTEM
DECISIONS
TASKS
BUILD

构成项目共享记忆。

5. Task 是 AI 自主施工的边界

AI 可以在 Task 内高度自主。

不能偷偷扩大问题。

6. Plan 是第一次 Review

先确认 AI 理解对了，再让它写。

7. Test + Diff 才接近证据

“AI 说完成了”不是证据。

8. Git 是 AI 开发的安全绳

小问题单元、可验证、可回滚。

9. 设计变化必须重新决策

施工过程中发现系统设计不成立：

1
2
3
4
5
Stop
→ Discuss
→ Decide
→ Document
→ Continue

不能偷偷改。

10. 真正的终点是现实反馈

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
能跑
≠
有人用

有人用
≠
有价值

有价值
≠
长期正确

最终仍然要回到现实。

二十九、我的 Vibe Coding 最终模型

现在我会把整套方法定义成：

用对话探索真实问题，用人的判断完成收敛，用文档固化项目事实，用 Task 划定 AI 的自主施工边界，用 Plan 和 Review 检查理解，用测试和 Diff 验证结果，用 Git 保存证据和恢复能力，最后让真实用户重新检验最初的判断。

整个循环：

 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
Reality
↓
Observe
↓
Discuss
↓
Decide
↓
Document
↓
Task
↓
Plan
↓
Build
↓
Verify
↓
Git
↓
Deploy
↓
Use
↓
Feedback
↓
Reality

而 Prompt，只是在这个循环中偶尔被拿出来使用的一件工具。

三十、最后

以前我容易把 Vibe Coding 理解成：

如何更好地指挥 AI 写代码。

现在更准确的理解应该是：

如何建立一个“人负责判断、AI 负责执行、系统负责约束”的开发方式。

AI 越来越强以后，我不需要坚持自己做所有事情。

但我要越来越清楚：

1
2
3
4
5
6
7
8
为什么做？
做什么？
做到哪里？
为什么这样设计？
AI 被允许做什么？
什么结果才算正确？
如果错了怎么发现？
怎么恢复？

这才是我认为真正值得长期积累的 Vibe Coding 能力。

AI 可以越来越自主地施工，但项目的目标、边界、授权和最终结果，始终必须有人真正理解并负责。