VibeCoding on 男娘教主

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

Mon, 05 Oct 2026 02:13:26 +0800

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

让 Agent 施工，让 Human 决定怎么走

Wed, 30 Sep 2026 09:05:24 +0800

第一次 Vibe Coding：让 Agent 施工，让 Human 决定怎么走

这是我第一次真正用 Vibe Coding 的方式完成一个项目。

现在回头看，它的自动化程度并不高。

Agent 每完成一个阶段都会回来问我：

Plan 可以执行吗？
要不要运行测试？
要不要继续修改？
这个 Task 可以结束吗？
是否进入下一个 Task？

后来我又尝试了自治程度更高的开发方式。

但我没有因此认为第一种方式已经落后。

恰恰相反，真正做过更自治的项目以后，我才重新理解它的价值：

Agent 负责提出路径和执行路径，Human 保留在关键分叉点修改路径的权力。

它不是 Autonomous Runtime。

它更像一种：

Human-Controlled Interactive Development。

一、最开始的问题不是怎么让 Agent 自治

第一次做完整项目以前，我使用 AI 写代码的方式很简单：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


想到一个功能
↓
告诉 AI
↓
AI 写代码
↓
发现问题
↓
继续聊天
↓
再修改

小功能没有什么问题。

但项目一旦变大，一个问题很快就会出现：

项目到底存在于哪里？

如果产品目标、架构、边界、任务和历史决策全部存在于聊天记录里，那么 AI 每一次工作都依赖当前 Conversation。

于是第一次真正做项目时，我开始把项目从聊天里搬出来。

逐渐形成：

1
2
3
4
5
6


PRODUCT.md
SYSTEM.md
DECISIONS.md
TASKS.md
BUILD.md
CHANGELOG.md

它们分别回答不同的问题：

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


PRODUCT
→ 我要解决什么问题？

SYSTEM
→ 系统准备怎么工作？

DECISIONS
→ 哪些关键选择已经确定？

TASKS
→ 接下来需要完成什么？

BUILD
→ Human 和 AI 怎么一起施工？

CHANGELOG
→ 项目实际上发生了什么？

从这里开始：

聊天不再是项目本身。

真正的 Source of Truth 开始回到项目文件。

二、第一次形成了三个角色

当时的协作结构并不是一个 Agent 自己把整个项目做完。

而是三个角色：

1
2
3
4
5
6
7


Product / Business Owner
 │
 │
 ├──────────────┐
 ▼ ▼
Design / Review Codex Worker
Assistant

Product / Business Owner

也就是我。

负责：

真实业务目标；
甲方规则；
架构关键取舍；
Review；
验收；
是否进入下一 Task。

真正的最终控制权仍然在人。

Design / Review Assistant

负责：

维护项目文档；
帮助拆 Task；
Review Worker 的 Plan；
Review Diff 和测试结果；
检查架构漂移；
帮助定位问题；
经我批准以后更新设计文档。

它不是主要施工者。

它更像我的设计和 Review 助手。

Codex Worker

Worker 才是真正负责施工的角色。

它负责：

阅读指定文档；
理解当前 Task；
输出 Plan；
等待 Review；
实现当前 Task；
运行测试；
报告 Diff；
根据 Review 修复；
Git Commit；
更新 CHANGELOG。

因此第一次 Vibe Coding 并不是：

1
2
3
4
5


Human
↓
告诉 AI 一个需求
↓
AI 写代码

而已经变成：

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


Human
↓
Project Docs
↓
Task
↓
Worker Plan
↓
Human Decision
↓
Implementation
↓
Evidence
↓
Human Decision

三、真正的核心：Task-by-Task

当时有一个非常重要的原则：

不要把 TASKS.md 全部一次性交给 Worker 自动完成。

每一次只执行一个 Task。

例如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


T01
↓
完成 / 验证
↓
T02
↓
完成 / 验证
↓
T03
↓
...

给 Worker 的任务类似：

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


阅读：

PRODUCT.md
SYSTEM.md
DECISIONS.md
BUILD.md

执行：

TASKS.md 中的 Txx

要求：

先输出 Plan。
不要修改代码。
等待 Review 后再执行。

这意味着 Worker 即使知道后面还有 T02、T03、T04，也不能自己一路向后施工。

项目推进权仍然属于 Human。

四、Task 开始之前，先给我 Plan

这是我后来依然非常喜欢第一种方式的原因。

Worker 拿到 Task 以后，第一件事不是修改代码。

而是：

1
2
3
4
5
6
7
8
9


Read Docs
↓
Read Relevant Code
↓
Understand Task
↓
Generate Plan
↓
STOP

Plan 至少需要告诉我：

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


当前 Task 是什么？

你怎么理解这个需求？

准备修改哪些文件？

准备分几步实现？

有什么风险？

准备怎么测试？

是否会触碰
PRODUCT / SYSTEM / DECISIONS？

然后才来到：

1
2
3
4
5
6
7
8
9


 Worker Plan
 ↓
 HUMAN GATE
 ┌──────┼──────┐
 ↓ ↓ ↓
 Accept Change Stop
 │
 ▼
 Implement

这个停顿非常重要。

五、Plan Gate 不是形式上的“审批”

以前我可能会觉得：

AI 每一步都来问我，有点麻烦。

后来我才意识到，这恰恰是这种模式最重要的能力之一。

假设 Worker 原本准备：

1
2
3
4
5
6
7
8
9


修改 A
+
修改 B
+
修改 C
+
新增一个抽象层
+
重构一部分旧逻辑

但我看到 Plan 后可能马上发现：

不对。

真正需要的可能只是：

1
2
3


修改 A
+
一个最小测试

于是原本可能发生：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


错误方向
↓
写代码
↓
改多个文件
↓
测试
↓
Review
↓
发现方向错了
↓
返工

被提前截断成：

1
2
3
4
5
6
7


错误 Plan
↓
Human 发现
↓
修改 Plan
↓
再执行

错误停在了最便宜的位置。

所以 Plan Gate 真正做的不是：

“Human 给 AI 签字。”

而是：

在真正付出实现成本之前，让 Human 有机会重新选择路径。

六、我不需要比 Agent 更会写代码

这也是我逐渐理解的一件事情。

Worker 可能比我更熟悉：

1
2
3
4
5


怎么拆函数
怎么调用 API
怎么组织模块
怎么处理异常
怎么写测试

但这不代表它应该决定所有事情。

Human 更应该判断：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


这个功能真的有必要吗？

为什么要增加这个抽象？

有没有更简单的方法？

这是不是已经偏离当前 Task？

这个风险值得吗？

现在真的需要完整测试吗？

这个方向是不是和最初目标冲突？

于是 Human 和 Agent 的关系逐渐变成：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Human
负责目标 / 边界 / 取舍
 ↓
Agent
提出实现 Plan
 ↓
Human
修改路径
 ↓
Agent
负责具体施工

我不需要亲自写出所有代码，才能拥有项目控制权。

七、Plan 通过以后，Worker 才开始施工

只有 Plan 被接受以后：

1
2
3
4
5
6
7
8
9


Plan Approved
↓
Implement
↓
Test
↓
Diff Summary
↓
Review

Worker 只能修改当前 Task 所需要的内容。

如果施工过程中发现：

顺便还可以把另外一个模块重构一下。

不能直接做。

而是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


发现额外问题
↓
记录
↓
报告
↓
Human 决定
├── 加入当前 Task
├── 建立新 Task
└── Ignore

这个规则后来一直影响我的工程思维：

不要因为“顺手能做”，就让复杂度自然生长。

八、做完以后，再把选择权交回来

实现完成并不代表 Task 自动结束。

Worker 需要提供证据，例如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


git diff --stat

关键 Diff 摘要

实际运行的测试

测试结果

新增 / 修改测试

已知限制

是否与设计文档一致

然后再次：

1
2
3
4
5


Implementation
↓
Evidence
↓
HUMAN GATE

Human 再决定：

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


Accept

Fix

继续测试

查看 Diff

让 Review Assistant 检查

自己检查代码

Skip 某些验证

直接进入下一步

Stop

这也是第一代另一个非常重要的特点：

Human 不只是决定做不做，还可以决定做到多深。

九、每一步都问我，有时候就是优点

假设 Agent 说：

当前修改已经通过 targeted test，建议再运行 full regression。

我可以判断：

现在不用。

然后：

1
2
3


SKIP
↓
Next Step

也可能另一个 Task 改动了核心 Runtime。

这时候我会说：

跑全量测试。

于是：

1
2
3


RUN FULL TEST
↓
Review Result

甚至可能测试本身没有必要：

1
2
3
4
5
6


Agent 建议 Test
 ↓
 Human
 ┌────┼────┐
 ↓ ↓ ↓
 RUN SKIP CHANGE

因此第一代的运行路径并不是完全提前冻结的。

Human 可以不断根据刚刚获得的信息调整：

1
2
3
4
5
6
7
8
9


执行什么？

不执行什么？

验证多深？

要不要继续？

要不要改变方向？

十、Human 可以实时给执行路径剪枝

这是后来使用更自治的开发方式以后，我重新认识到的优势。

一个高度自治的 Runtime 可能提前规定：

1
2
3
4
5
6
7
8
9


Implement
↓
Test
↓
Review
↓
Regression
↓
Next Task

规则一旦满足，它就继续执行。

但 Human 有一种非常强的能力：

知道什么时候“不值得继续做”。

例如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


这个测试现在不用跑。

这个 Review 没必要。

这个方案不要继续研究。

先验证最小路径。

这个问题暂时接受。

这里不用继续优化。

于是 Human 可以直接剪掉执行树上的分支：

1
2
3
4
5
6
7
8


 Current State
 │
 ┌───────────┼───────────┐
 ▼ ▼ ▼
 Test Review Continue
 │
 X
 Human Skip

节省的不只是时间。

还可能包括：

1
2
3
4
5
6


Token
Context
Agent 调用
测试时间
返工
无意义探索

所以“每一步都问我”并不天然意味着设计落后。

它付出的是：

Human Attention。

换来的是：

运行时路径选择权。

十一、Human 不需要默认逐行看代码

保留 Human Gate 也不意味着：

每个 Task 我都必须逐行 Code Review。

否则 Agent 写代码的速度远远超过 Human 读代码的速度。

更合理的方式是从证据开始。

例如：

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


Task: T07

Goal:
实现 Context Builder

Changed:
3 files

Targeted Tests:
17 PASS

Regression:
324 PASS

Architecture Drift:
NO

Business Rule Change:
NO

Known Limitation:
xxx

Human 首先看：

1
2
3


Result
+
Evidence

如果已经足够：

1

CONTINUE

如果不够：

1
2
3
4
5
6
7
8
9


Result / Evidence
 ↓
Reviewer Analysis
 ↓
Diff
 ↓
Code
 ↓
Debug

逐层向下。

所以 Human Gate 的目标不是证明：

“我亲眼检查过 AI 写的每一行代码。”

而是：

我拥有足够证据决定项目是否应该继续。

十二、什么时候我会自己看代码？

当代码本身成为判断所需证据时。

例如：

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


业务规则变化

架构边界变化

State Transition

恢复 / 幂等

权限

删除 / 覆盖

外部副作用

测试无法解释的异常

Worker 与 Reviewer 判断冲突

我自己对结果产生怀疑

这时候：

1
2
3
4
5
6
7


Evidence 不够
↓
Human Drill Down
↓
Diff
↓
Code

所以：

看不看代码也是 Human 的运行时决策。

而不是固定仪式。

十三、原来的 Gate 很严格，但今天我不会全部写死

第一次项目里的 BUILD 对工程流程要求非常严格：

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


Plan Gate

Scope Gate

Review Gate

Git Gate

Test Gate

Documentation Gate

Log Gate

Regression Gate

这些 Gate 帮助我第一次真正把一个 AI 项目收口成工程。

所以它们非常有价值。

但如果今天重新使用第一种开发方式，我不会把所有 Gate 都理解成：

每次必须完整执行。

而更愿意理解成：

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


Available Gates

Plan
Scope
Test
Review
Regression
Git
Documentation
Log
 │
 ▼
Human 根据当前状态
决定执行深度

当然，真正危险或者不可逆的动作仍然应该有硬边界。

但普通施工过程没有必要为了流程完整而执行没有价值的步骤。

十四、这套模式真正控制的不是 Task，而是路径

一开始我以为：

Human 控制的是 Task 生命周期。

后来发现还不够准确。

Human 实际控制：

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


这个 Task 做不做？
↓
这个 Plan 怎么走？
↓
实现范围多大？
↓
要不要测试？
↓
测试多深？
↓
要不要 Review？
↓
我要不要自己看代码？
↓
这个结果够不够？
↓
要不要进入下一 Task？

所以第一代真正的运行模型应该是：

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


Agent
↓
提出下一动作
↓
Human 判断
├── RUN
├── SKIP
├── CHANGE
└── STOP
↓
Agent 执行
↓
产生新证据
↓
再次提出下一动作
↓
Human 再判断

因此我更愿意把它叫做：

Human-Controlled Interactive Development

Agent 负责工作。

Human 控制路径。

十五、为什么这种模式特别适合探索性项目？

因为有些项目在开始的时候，下一步本来就是未知的。

例如：

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


最初理解
↓
Task 1
↓
得到新信息
↓
修改原来的认识
↓
Task 2
↓
发现新问题
↓
重新调整
↓
Task 3

这时候如果提前要求：

把整个流程冻结，然后让 Runtime 自动执行。

可能反而是在强迫系统沿着一个还没有被证明正确的路径继续走。

而 Interactive Development 允许：

设计和施工交替演化。

每完成一步，Human 都重新获得一次决策机会。

所以这里的停顿不是浪费。

停顿本身就是开发过程的一部分。

十六、第一代真正的问题：Human 也是 Runtime

当然，这种模式有非常明显的成本。

整个系统实际上是：

 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


 Human
 │
 Select Task
 │
 ▼
 Worker
 │
 Plan
 │
 ▼
 Human
 │
 Approve
 │
 ▼
 Worker
 │
 Implement / Test
 │
 ▼
 Human
 │
 Accept / Change
 │
 ▼
 Next Task

也就是说：

Human 本身就是 Runtime。

如果我离开：

1
2
3
4
5


Worker 完成
↓
等待
↓
……

项目也会停下来。

所以它无法很好地无人值守运行。

Human Attention 也成为持续成本。

十七、什么时候这个缺点开始真正成为问题？

关键并不是项目“大不大”。

而是：

Human 每一次被叫回来时，还有没有提供新的判断？

假设 Agent 连续十次问：

1

Plan 是否执行？

我每次都：

Yes。

又连续十次问：

1

Targeted Test 是否运行？

我还是：

Yes。

Review PASS 以后：

1

是否进入下一 Task？

答案永远：

Continue。

这时候 Human Gate 已经没有提供新的信息。

它开始退化成：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Agent
↓
等待 Human 点 Yes
↓
Agent
↓
等待 Human 点 Yes
↓
Agent
↓
等待 Human 点 Continue

这才是真正值得自动化的信号。

十八、什么时候我今天仍然会选择第一代？

如果一个项目：

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


路径还不确定

每个 Task 都可能改变后面的设计

我希望跟着施工一起理解项目

下一步高度依赖刚得到的结果

我经常会拒绝 Agent 的 Plan

我经常会跳过某些 Test / Review

Token / Runtime 成本需要实时控制

项目不需要长时间无人值守

我会主动选择：

Human-Controlled Interactive Development。

因为这时候 Human Gate 不是瓶颈。

Human Gate 本身就在产生价值。

反过来，如果：

1
2
3
4
5
6
7
8
9


设计已经稳定

Task 明确

Acceptance 明确

正常 Transition 高度重复

Human 基本只是在点击 Continue

那么这些 Gate 才开始获得下沉给 Runtime 的资格。

十九、这不是第一代淘汰第二代，也不是第二代淘汰第一代

后来我尝试了更自治的开发方式。

Human 可以提前定义：

1
2
3
4
5
6
7
8
9


什么时候 Review

什么时候 Test

什么时候 Retry

什么时候 Stop

什么情况 Human Required

然后 Runtime 自己执行正常流程。

这同样非常有价值。

而且自治程度高也不代表 Human 失去控制。

因为：

协议仍然是 Human 写的。

Human 仍然可以规定：

1
2
3
4
5
6
7
8
9


Review 只在某些条件触发

Full Test 只在阶段结束执行

某些操作必须 Human 主动发起

某些异常必须立即停止

某些 Task 不允许自动推进

所以第一代和后来的自治 Runtime 不是：

1
2
3


Human Control
VS
No Human Control

而更像：

1
2
3
4


第一代

Human 在运行过程中
持续注入决策

与：

1
2
3
4
5
6


第二 / 第三代

Human 把更多决策
提前写进 Protocol
↓
Runtime 根据协议自治

它们只是把 Human Decision 放在了不同的位置。

二十、一个判断：这个 Gate 应不应该自动化？

现在如果让我重新判断一个 Human Gate 是否应该保留，我会问：

如果 Agent 每次问我，我的答案都可能不同吗？

如果答案是：

会。

那就保留。

因为 Human 仍然在提供信息。

如果：

它问我十次，我十次都会给出相同答案。

那就应该开始问：

为什么还要问？

这个 Gate 已经获得了下沉给 Runtime 的资格。

这也是后来我开始尝试更高自治开发方式的原因。

二十一、第一代完整运行模型

最终可以把这种开发方式压缩成：

 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


 Project Docs
 │
 ▼
 Current Task
 │
 ▼
 Worker
 │
 Propose Plan
 │
 ▼
 Human
 ┌─────────┼─────────┐
 ▼ ▼ ▼
 RUN CHANGE STOP
 │
 ▼
 Worker
 │
 Implement
 │
 ▼
 Result + Evidence
 │
 ▼
 Human
 ┌────┼────┬───────┐
 ▼ ▼ ▼ ▼
 TEST REVIEW SKIP DRILL DOWN
 │ │ │
 └────┴──────┬──────┘
 ▼
 Human
 ┌──────┼──────┐
 ▼ ▼ ▼
 NEXT FIX STOP

其中：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


Agent
→ 提出路径
→ 执行路径
→ 提供证据

Human
→ 选择路径
→ 修改路径
→ 决定执行深度
→ 决定是否继续

二十二、给其他 AI：如何生成这种开发模式

如果以后我要重新采用第一代方式，可以直接把下面的协议交给 AI。

 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
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238


我要使用一种：

HUMAN_CONTROLLED_INTERACTIVE_DEVELOPMENT

开发模式。

核心原则：

Agent 负责分析、提出下一步方案和执行；
Human 保留关键分叉点的路径选择权。

这不是 Autonomous Runtime。

不要自动连续执行整个 TASKS。
不要因为能够自动化就主动增加 Runtime、Queue、
Watcher、Graph 或其他自治机制。

一、项目资料

优先建立或读取：

PRODUCT.md
SYSTEM.md
DECISIONS.md
TASKS.md
BUILD.md
CHANGELOG.md

Project Files 是 Source of Truth。
Chat History 不是项目状态。

二、角色

至少区分：

1. Human Owner

负责：

- 产品目标
- 业务规则
- 架构关键取舍
- Scope
- 是否批准 Plan
- 验证深度
- 是否进入下一 Task
- 最终责任

2. Design / Review Assistant（可选）

负责：

- 帮助维护设计文档
- 帮助拆 Task
- Review Plan
- Review Diff / Test / Evidence
- 检查 Architecture Drift
- 帮助 Human 理解问题

它是 Human 的工具。
它不拥有项目推进权。

3. Worker

负责：

- 读取项目资料
- 读取当前 Task
- 分析相关代码
- 提出 Plan
- 获得批准后实现
- 运行被批准或协议要求的验证
- 输出 Evidence
- 根据 Human 决策修复
- 在批准后 Commit / 记录

三、Task 执行协议

每次只处理一个 Current Task。

开始时：

Read Docs
→ Read Relevant Code
→ Understand Task
→ Generate Plan
→ STOP

Plan 至少说明：

- Current Task
- Requirement Understanding
- Files To Change
- Implementation Steps
- Scope
- Risk
- Suggested Tests
- 是否触碰 PRODUCT / SYSTEM / DECISIONS

在 Human 明确批准前：

不得修改代码。

Human 可以：

RUN
CHANGE
SKIP
STOP

四、执行阶段

Plan 获批后，只在批准 Scope 内施工。

发现额外问题时：

记录并报告。

不要顺手扩展 Scope。
不要顺手重构整个项目。
不要自动增加新的架构复杂度。

需要改变：

PRODUCT
SYSTEM
DECISIONS
业务规则
关键依赖
重要边界

时，STOP 并返回 Human。

五、完成阶段

实现后返回最小但足够的 Evidence：

- Changed Files
- Diff Summary
- Acceptance Status
- Tests Already Run
- Suggested Additional Tests
- Known Limitations
- Architecture Drift
- Business Rule Change
- Suggested Next Action

然后等待 Human。

不要默认自动进入下一 Task。

六、验证深度由 Human 决定

Human 可以选择：

RUN TEST
SKIP TEST
TARGETED TEST
FULL REGRESSION
AGENT REVIEW
HUMAN DIFF REVIEW
HUMAN CODE REVIEW
FIX
NEXT
STOP

不要假设每个 Task 都需要相同验证深度。

如果建议执行 Test / Review，请同时说明：

为什么建议执行；
不执行的主要风险是什么。

让 Human 根据当前目标、成本和风险选择。

七、Review 原则

Human 不需要默认逐行阅读代码。

默认从：

Result
+
Evidence

开始。

证据不足时再逐层下钻：

Result / Evidence
→ Reviewer Analysis
→ Diff
→ Code
→ Debug

Human 的目标不是证明自己检查了每一行代码。

Human 的目标是获得足够证据决定项目是否应该继续。

八、项目推进权

Worker 完成当前工作后不得自动领取下一 Task。

必须等待 Human：

NEXT
FIX
CHANGE
STOP

只有 Human 拥有项目推进权。

九、复杂度原则

复杂度必须获得存在资格。

自治也必须获得存在资格。

如果某个 Human Gate 仍然经常产生不同决策，
保留它。

如果同类 Gate 反复出现，
而 Human 几乎总是给出相同答案，
记录这个信号。

它可能已经适合在下一阶段下沉给 Runtime。

十、最终目标

这套模式追求的不是最大自动化。

它追求：

Agent 承担施工能力，
Human 保留有价值的运行时判断。

Agent 每到重要分叉点，
把选择权还给 Human。

如果最终生成的开发流程变成：

1
2
3
4
5
6
7


Human
↓
START
↓
Agent 自动完成全部 TASKS
↓
Human

说明已经偏离了这种模式。

正确形态应该始终保留：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Agent
↓
Propose
↓
Human Decide
↓
Agent Execute
↓
Evidence
↓
Human Decide
↓
Next

二十三、后来为什么还要继续进化？

第一代已经能够很好地完成项目。

真正推动我继续改变它的，并不是：

它不能工作。

恰恰相反。

是因为它工作以后，我开始发现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


有些 Plan
我总是批准。

有些 Test
我总是执行。

有些 Review PASS
我总是进入 Next Task。

有些 Transition
已经不再需要我真正思考。

如果 Human 每一次出现都在提供新的判断，那么 Human 应该留下。

但如果 Human 只是机械地重复：

Yes。
Continue。
Run。
Next。

那么问题就变成了：

这些已经稳定下来的判断，为什么不能提前写进协议？

于是我的第二次尝试开始改变一个东西：

不是让 Agent 写更多代码。

而是尝试把那些已经不再需要 Human 临场判断的控制权，逐渐交给 Runtime。

第一代解决的是：

怎么让 Agent 在 Human 控制下完成一个真实项目。

而接下来的问题变成了：

哪些控制权应该继续属于 Human，哪些已经获得了下沉的资格？

这成为下一阶段的起点。

第二次 Vibe Coding：把 Human 从施工循环里移出去

Sun, 27 Sep 2026 05:39:46 +0800

第二次 Vibe Coding：把 Human 从施工循环里移出去

第一次 Vibe Coding 时，我已经能够把一个完整项目拆成：

1
2
3
4
5


PRODUCT
SYSTEM
DECISIONS
TASKS
BUILD

然后：

1
2
3
4
5
6
7
8
9


Human
↓
启动 Task
↓
Agent 完成
↓
Human
↓
下一 Task

这种方式很好理解，也很好控制。

但它有一个非常明显的特点：

项目能不能继续运行，取决于 Human 有没有回来。

后来开始做企业知识库项目时，我想尝试另一种开发方式：

如果产品、系统、关键决策和任务已经基本确定，能不能让 Agent 自己完成正常施工循环？

于是第二次 Vibe Coding 的核心问题从：

怎么让 Agent 完成一个 Task？

变成了：

怎么让一个项目在 Human 不持续调度的情况下继续施工？

一、Human 先退出施工，而不是退出项目

我并不是想让 AI 自己决定整个产品。

知识库项目开始施工之前，Human 仍然负责：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


问题定义
↓
PRODUCT
↓
SYSTEM
↓
关键 DECISIONS
↓
TASKS
↓
BUILD

尤其是：

1
2
3
4
5
6
7


产品到底解决什么问题？
LLM 应该做什么？
LLM 不应该做什么？
知识如何检索？
什么必须保留证据？
什么判断必须留给 Human？
哪些设计已经冻结？

这些东西仍然需要先确定。

所以 Human 并没有退出。

Human 只是从：

1

施工过程的每一次状态转换

里退出。

整个结构开始变成：

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


 Human
 │
 Product / System
 Decisions / Tasks
 │
 ▼
 Frozen Design
 │
 ▼
 Agent Runtime
 │
 Autonomous Build
 │
 ▼
 Product
 │
 ▼
 Human

Human 控制：

设计和边界。

Runtime 控制：

已经确定范围内的施工。

二、为什么一个 Agent 不够？

如果仍然把所有事情交给同一个 Agent：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


读取 Task
↓
写代码
↓
测试
↓
判断自己是否正确
↓
宣布 PASS
↓
进入下一 Task

会出现一个很明显的问题：

写代码的人同时拥有最终验收权。

它可能：

1
2
3
4
5
6
7


误解 Task
↓
按照自己的误解实现
↓
再按照同一个误解验证
↓
认为自己完成了

所以我开始把不同责任拆开。

最基础的是：

1
2
3


Control
Implementation
Verification

在当时的项目里，它们可以表现为：

1
2
3


Orchestrator / Lead
Worker / Builder
Reviewer

名称不是最重要的。

真正重要的是职责分离：

1
2
3
4
5
6
7
8


Control
→ 现在应该做什么？

Worker
→ 把当前任务实现出来。

Reviewer
→ 它真的符合 Acceptance 吗？

于是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


 Control
 │
 ▼
 Worker
 │
 ▼
 Reviewer
 ↙ ↘
 FAIL PASS
 │ │
 ▼ ▼
 Rework Next Task

这时候 Human 第一次有可能退出正常施工循环。

三、多个 Agent 不能靠聊天记住项目

角色拆开以后，一个新的问题马上出现：

Worker 做完以后，Reviewer 怎么知道发生了什么？

如果靠 Human：

1
2
3
4
5
6
7


Worker
↓
告诉 Human
↓
Human 复制给 Reviewer
↓
Reviewer

那 Human 只是从：

Task 调度器

变成了：

Agent 消息搬运工。

这没有解决问题。

所以 Agent 之间必须共享同一个外部世界。

这个外部世界就是：

1
2
3
4
5


Shared Project
+
Markdown Contract
+
Shared State

四、Shared Project：真正发生了什么

代码、测试、配置、文档都存在同一个项目目录。

例如：

1
2
3
4
5
6
7
8


src/
tests/

PRODUCT.md
SYSTEM.md
DECISIONS.md
TASKS.md
BUILD.md

Worker 修改：

1

src/retrieval.py

Reviewer 不需要 Worker 把整个文件重新复制给它。

Reviewer 自己读取真实项目即可。

所以：

Project Files 是事实。

Agent 的描述不是事实本身。

五、Markdown Contract：大家应该怎么协作

只有共享项目还不够。

Agent 还需要知道：

1
2
3
4
5
6
7


我是谁？
我负责什么？
我不能做什么？
现在应该读取什么？
完成以后交给谁？
什么时候必须停下来？
什么时候需要 Human？

所以协作规则也开始从聊天中移出去。

例如：

1
2
3
4
5
6
7


.agents/
├── COMMON.md
├── RUNTIME.md
└── roles/
 ├── CONTROL.md
 ├── WORKER.md
 └── REVIEWER.md

这些文件不是项目业务事实。

它们定义的是：

Agent 如何围绕这个项目协作。

于是：

1
2
3
4
5


Project
= 做什么

Contract
= 怎么协作

开始被分开。

六、Shared State：现在运行到哪里

即使所有 Agent 都知道规则，还需要知道：

当前项目现在在哪里？

所以出现 Shared State。

例如：

1
2
3
4
5
6
7
8


{
 "current_task": "T007",
 "current_role": "WORKER",
 "status": "RUNNING",
 "review_attempt": 1,
 "human_required": false,
 "pause_requested": false
}

它回答：

1
2
3
4
5


当前 Task 是什么？
现在轮到谁？
刚刚发生了什么？
Review 到第几轮？
是否需要 Human？

这样新的 Agent 被启动以后，不需要依赖旧 Session 的聊天历史。

它可以：

1
2
3
4
5
6
7
8
9


读取 Contract
↓
读取 State
↓
读取 Current Task
↓
读取真实 Project
↓
恢复当前工作

这时候 Conversation 第一次真正从 Runtime State 里被剥离出去。

七、Project、Contract、State 开始各自负责一件事

整个结构逐渐稳定成：

 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


Shared Project
│
│ 保存真实工作结果
│
├── Code
├── Tests
└── Docs


Markdown Contract
│
│ 保存协作规则
│
├── Common Rules
├── Runtime Rules
└── Role Rules


Shared State
│
│ 保存当前运行现场
│
├── Current Task
├── Current Role
├── Status
├── Retry
└── Human Required

于是三个问题被分开：

1
2
3
4
5
6
7
8


发生了什么？
→ Project

应该怎么协作？
→ Contract

现在运行到哪里？
→ State

这比把所有东西都塞进聊天历史稳定得多。

八、Handoff 只需要告诉下一角色去哪里看

Agent 之间仍然需要交接。

但既然大家共享 Project，就没有必要复制完整工作内容。

例如 Worker 完成：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


Task: T007
Status: WORK_DONE

Changed:
- src/retrieval.py
- tests/test_retrieval.py

Verification:
- targeted tests PASS

Attention:
- semantic fallback branch

Reviewer 看到以后：

1
2
3
4
5
6
7


知道改了哪里
↓
自己读真实文件
↓
自己看 Diff
↓
自己运行必要验证

所以 Handoff 更像：

导航卡。

而不是：

工作结果的副本。

可以简单概括为：

Project 保存事实，Handoff 保存指针。

九、正常状态转换开始从 Human 手里移出去

第一代：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Worker 完成
↓
Human
↓
Reviewer

Reviewer PASS
↓
Human
↓
Next Task

第二代希望变成：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Worker 完成
↓
State = WORK_DONE
↓
Reviewer

Reviewer PASS
↓
State = REVIEW_PASS
↓
Next Task

也就是说：

正常、重复、已经有明确规则的 Transition，不再需要 Human 每次重新判断。

Human 不应该一直回答：

1
2
3


可以 Review 了。
可以返工了。
可以进入下一 Task 了。

这些如果已经是项目协议的一部分，就应该由 Runtime 自己完成。

十、Human 的位置开始发生变化

于是 Human 从：

1

Task Scheduler

逐渐变成：

1
2
3
4


Product Owner
Architecture Owner
Boundary Owner
Exception Handler

正常施工：

1
2
3
4
5
6
7


Task
↓
Worker
↓
Reviewer
↓
Next Task

Human 不进入。

只有出现：

1
2
3
4
5
6


需求不明确
设计冲突
架构问题
无法收敛
需要改变冻结决策
高风险动作

才重新把控制权交回来。

所以目标不是：

Human 不参与。

而是：

Human 不参与已经能够由规则处理的正常状态转换。

十一、Human Control 变成 Runtime Control

Human 仍然需要拥有最终控制权。

但控制方式不应该是不断进入内部施工。

更合理的是：

1
2
3
4
5


START
PAUSE
RESUME
STOP
OVERRIDE

例如：

当前工作完成以后暂停。

Runtime 记录：

1

pause_requested = true

当前工作完成以后：

1
2
3
4
5


检查 Human Control
↓
PAUSE
↓
不领取下一 Task

Human 控制的是：

Runtime 生命周期。

而不是：

每一次内部 Action。

十二、Review 也不能无限循环

自治以后，一个新的风险是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Worker
↓
Reviewer FAIL
↓
Worker
↓
Reviewer FAIL
↓
Worker
↓
Reviewer FAIL
↓
...

如果 Human 不再每轮介入，就必须给自治设置边界。

例如：

1
2


review_attempt = 3
max_review_attempts = 3

达到上限：

1
2
3


HUMAN_REQUIRED
↓
STOP

因为连续失败本身已经产生了新信息。

问题可能已经不是：

再改一次代码。

而可能是：

1
2
3
4
5


Task 定义错误
Acceptance 冲突
架构理解不同
Reviewer 标准不合理
当前方案无法实现

所以：

自治必须有边界。

十三、测试也应该进入施工协议

第一代里 Human 很容易不断说：

跑一下测试。

但如果施工阶段已经自治，测试什么时候运行也应该提前确定。

例如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


普通修改
→ Targeted Test

共享模块变化
→ Impact Regression

阶段完成
→ Integration Test

最终完成
→ Full Regression

这样 Worker 和 Reviewer 不需要每次询问 Human：

现在要不要跑测试？

测试成为 Runtime Contract 的一部分。

十四、第二代真正改变的是控制权

如果把第一代和第二代放在一起：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


第一代

Human
↓
Task
↓
Agent
↓
Human
↓
Next Task

第二代：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


Human
↓
Frozen Design
↓
Runtime
├── Control
├── Worker
└── Reviewer
↓
Product
↓
Human

真正变化的不是：

一个 Agent 变成了三个 Agent。

而是：

Human 把一部分正常控制权交给了 Runtime。

这也是我第一次真正开始理解：

1

Implementation

和：

1

Runtime Control

并不是同一件事。

十五、自动化并不是免费的

第二代最大的好处很明显：

Human 不需要一直守着项目。

但是实际运行以后，我也开始感受到它的另一面。

第一代路径通常非常清楚：

1
2
3
4
5
6
7
8
9


T01
↓
Human
↓
T02
↓
Human
↓
T03

我几乎始终知道系统正在做什么。

第二代变成：

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


Control
↓
读取 State
↓
Worker
↓
读取 Project / Contract
↓
实现
↓
测试
↓
Reviewer
↓
再次读取 Project / Contract
↓
验证
↓
可能返工
↓
Control
↓
Next Task

Human 操作减少了。

但内部步骤增加了。

每个 Agent 都需要重新建立上下文。

每次 Review、Replan、Retry 都需要额外推理。

于是一个非常现实的问题出现：

自治减少了 Human Attention，却增加了 Runtime Cost。

最直接的表现就是 Token 消耗明显增加。

十六、路径也开始变得不可见

第一代里：

1

我启动 T04

所以我天然知道：

现在正在做 T04。

第二代里 Human 可能只看到：

1

START

然后 Runtime 内部：

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


Task
↓
Worker
↓
Reviewer
↓
Retry
↓
Reviewer
↓
Next Task
↓
Worker
...

如果不主动查看 State 和 Trace，我并不知道它具体运行到了哪里。

所以自治带来的交换关系开始变得明显：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


Human 操作减少
 ↓
Automation 增加

但同时：

Path Visibility 下降
Runtime Cost 上升
Token Predictability 下降
Debug Difficulty 上升

这并不说明自治错误。

只是说明：

自动化本身也有成本。

十七、第一代因此没有失效

做到这里以后，我反而重新理解了第一代。

如果：

1
2
3
4
5


任务明确
路径明确
项目不长
Human 希望理解每一步
Token 成本敏感

那么：

1

Human-Controlled TaskList

可能反而更加简单。

如果：

1
2
3
4


项目很长
Task 很多
正常 Transition 高度重复
Human 调度已经成为主要成本

那么才值得把更多控制权交给 Runtime。

所以：

1
2
3
4
5


第一代
≠ 落后

第二代
≠ 更高级

它们交换的是不同的成本。

第一代支付：

1

Human Attention

换取：

1
2
3


Visibility
Predictability
Control

第二代支付更多：

1
2
3


Token
Runtime Complexity
Observability Cost

换取：

1
2
3


Autonomy
Human Attention
Long-running Capability

我开始意识到：

自治也必须获得存在资格。

十八、但第二代还暴露出了一个更具体的问题

到这里，逻辑上的 Runtime 已经基本成立。

State 可以告诉系统：

1

current_role = WORKER

Worker 完成以后可以写：

1

next_role = REVIEWER

控制逻辑也可以知道：

1
2


WORK_DONE
→ REVIEWER

但是实际运行时，我发现这里隐藏着一个一直没有被区分的问题：

知道下一步是谁，不等于能够把下一步的人叫起来。

如果 Worker 和 Reviewer 是两个彼此独立的 AI Session：

1
2
3


Worker Session

Reviewer Session

那么 Worker 即使知道：

1

next = REVIEWER

Reviewer 也不会因此自动开始运行。

逻辑世界里：

1
2
3


Worker
↓
Reviewer

物理世界里却仍然可能是：

1
2
3
4
5
6
7


Worker 完成
↓
等待
↓
Human 打开 Reviewer Session
↓
Reviewer 才真正开始

十九、如果强行回到 Control，也会出现新的成本

一种很自然的想法是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Control
↓
Worker
↓
Control
↓
Reviewer
↓
Control
↓
Next

逻辑上非常漂亮。

但如果：

1
2
3


Control
Worker
Reviewer

本身就是三个独立 Session，那么 Human 实际操作会变成：

1
2
3
4
5
6
7
8
9


打开 Control
↓
打开 Worker
↓
打开 Control
↓
打开 Reviewer
↓
打开 Control

为了让逻辑上的控制中心始终存在，反而增加了物理 Session 切换。

这时候我才发现：

我一直把“决定下一步”和“真正启动下一步”当成了同一件事。

其实它们是两个问题。

二十、第二次实践停在这里

第二代解决了第一代暴露的问题：

1

Human 每个 Task 都要回来

于是我建立了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Shared Project
+
Markdown Contract
+
Shared State
+
Control / Worker / Reviewer
+
Bounded Review
+
Human Runtime Control

Human 开始退出正常施工循环。

但是实际运行又暴露出了新的边界：

1
2
3


Logical Transition
≠
Physical Wake-up

State 可以知道：

下一步是 Reviewer。

Runtime Contract 可以规定：

Worker 完成后进入 Review。

但如果 AI 软件本身没有跨 Session 启动能力：

谁真正把 Reviewer 叫起来？

继续解决这个问题当然可以加入：

1
2
3
4
5
6


CLI
API
Queue
Polling
Process Manager
Desktop Automation

但这样又会产生新的复杂度。

而如果当前 AI 软件本身支持：

1
2
3


Host
+
SubAgent

问题又完全不同。

于是我开始意识到：

也许问题不是继续寻找一种“最强的 Multi-Agent Runtime”。

真正应该拆开的，是：

1
2
3
4
5


协作协议
↓
控制逻辑
↓
物理执行方式

同一套协作协议，在不同 AI 环境下，也许本来就应该采用不同的执行方式。

这成为第三次重新设计 Vibe Coding 方法的起点。