⚖️ 人机分工与长期不失控——把项目做大的三道防线
前面三篇讲的是一轮之内怎么做对：切小、验收、纠偏。
这一篇讲的是一轮之外的事：
- 哪些事该你管，哪些事该它管？
- 项目做到第 30 轮，它开始忘事、开始重复劳动，怎么办？
- 怎么让这个项目明天还能接着做？
先想清楚一件事：为什么你会失控？
因为 vibe coding 有一个隐藏前提：
你放弃了「看懂代码」，换来了「快速做出东西」。
这笔交易在项目小的时候非常划算，在项目变大的时候开始出问题。
| 项目规模 | 你的状态 | 结果 |
|---|---|---|
| 几十行 | 一眼看得出对错 | 很爽 |
| 几百行 | 看得出大概，细节要问 | 开始吃力 |
| 几千行 | 看不出全貌，只能局部判断 | 失控感从这里开始 |
但这不是「vibe coding 不行」，而是「vibe coding 需要一套纪律」。
区别在这：
❌ 传统开发：规模变大 → 你被迫学会更多代码 → 变强
✅ vibe coding：规模变大 → 你必须建立新的判断方式 → 保持掌控
这个"新的判断方式"，就是这一篇的三道防线。
防线一：分工——你管方向，它管实现
一张表说清
| 事情 | 谁来做 | 为什么 |
|---|---|---|
| 产品决策 | 🧑 你 | 「我到底要什么」只有你知道，AI 猜不到 |
| 验收标准 | 🧑 你 | 「做到什么算对」必须你定义 |
| 视觉偏好 | 🧑 你 | 好看不好看，是主观的 |
| 优先级 | 🧑 你 | 哪个功能先做，你说了算 |
| 代码实现 | 🤖 AI | 这正是它最强的地方 |
| 调试找错 | 🤖 AI | 读报错、定位问题，比你快 |
| 样板代码 | 🤖 AI | 增删改查、配置、路由 |
| 技术选型 | 🤖 AI | 除非你已有明确偏好 |
| 写文档 | 🤖 AI | 让人看得懂就行 |
关键的一句
你管「做什么」和「算不算对」，它管「怎么做」。
一旦你开始管「怎么做」，你就掉回了传统编程的苦路；一旦你不管「算不算对」，它就会按自己的理解跑到底。
什么时候你必须亲自介入？
有三件事，AI 替代不了：
1. 说清「我要什么」
「简洁」「好看」「专业」——这些词 AI 无法理解，因为它们指向的是你的标准，不是客观事实。
2. 判断「这个方向对不对」
AI 能做出来 ≠ 该这么做。产品判断是人的活。
3. 决定「什么时候停」
「够了」这个判断，只有你能做。 AI 永远不会说「我觉得可以了，你先用着吧」——它会一直优化下去。
防线二：三条红线——不能碰的地方
有些事一旦让 AI 自由发挥，损失是不可逆的。提前立好红线：
🚫 红线一：不要让它动「你的数据」
涉及真实数据、账号、密钥的操作 → 必须你来按确认典型场景：它要「顺便清一下项目里的旧文件」「把数据库重置一下」。
为什么：代码可以重写，数据没了就是没了。
话术：
「这一步先别执行，把要做的事列给我，我确认了再动。」
🚫 红线二：不要让它动「你没选过的方案」
换框架、换数据库、换部署方式 → 必须你点头为什么：这类决策的影响是「全局的、隐形的」。它在你不知情的时候换了底层方案，接下来所有东西都建立在一个你没同意的基础上。
话术：
「你要换 X 吗？先说清楚为什么要换，换了之后会有什么影响。我同意再动。」
🚫 红线三：不要让它「顺手优化」
每次改动的范围 = 你说的那一件事 + 必要的连带修改为什么：这是新手失控的头号原因。上一篇提到的「改了 10+ 个文件」就是这么来的。
话术：
「这次只做 XXX，其他地方不要动。如果发现有必须一起改的地方，先告诉我。」
💡 一个更省事的做法：养成习惯，每次收尾问一句 「这轮你一共改了哪些地方？有没有超出我说的范围的？」 这一句话能挡掉绝大部分失控。
防线三：上下文管理——项目变大后不失忆
到了第 20、30 轮，你会遇到这些问题：
- 它开始忘事，之前说过的要求要重复讲
- 它开始重复劳动，把同样的功能实现两遍
- 它开始记不清文件之间的关系
- 你跟它说「改一下那个」，它不知道是哪个那个
这不是它变笨了，是对话太长了。 你需要主动管理上下文。
招数一：定期「收口」
每 5～10 轮做一次，让它总结：
「先停一下。总结一下我们现在到哪了：已经有哪些功能、还差什么、有哪些坑是踩过的。写成一份简短的说明。」
这相当于给它做人工摘要，把散落在几十轮对话里的信息压缩成一份清晰的现状。
顺便还收获了两个好处：
- 你自己也清楚项目现在什么样了
- 这份说明可以直接存成文件，明天接着用
招数二：把重要结论落到文件里
💡 这是最有效的一招。
对话会忘，文件不会。与其反复强调「我们的约定是 XXX」，不如让 AI 把它写下来：
「把我们刚才定下的几个约定写到一个文件里，我要的是：项目结构、每个文件干什么、给 AI 的硬性要求、踩过的坑。」
写完之后：
- 每次开新对话，第一句就是「先读 XXX.md」
- AI 每次都有据可依，不会瞎猜
- 你也留下了一份别人能看懂的文档（自己也是受益者）
💡 顺带说一句：这一步其实是在给未来的自己写说明书。 隔一周回来你自己都忘了当时为什么这么设计——但文件记得。
招数三：新开对话时带上「交接说明」
如果某个对话已经聊得很乱，或者你明天再来：
「写一份交接说明：我现在要什么、项目到哪了、约定是什么、有哪些坑。下个对话我直接把这个贴过去。」
招数四：用 git 当安全带
这个不是 AI 的活，但比任何话术都管用：
| 用途 | 怎么做 |
|---|---|
| 回退 | 改砸了随时退回去，不用重做 |
| 看变化 | 一眼看出这轮改了什么、动了哪些文件 |
| 存档 | 每个能用的版本存一个 |
为什么它对 vibe coding 特别重要？
因为 vibe coding 的核心风险是「改过头、退不回」。而 git 提供的正是一个绝对安全的撤销键。
三道防线，一张图记住
| 防线 | 防什么 | 关键动作 |
|---|---|---|
| 分工 | 你掉回苦逼的读代码，或它替你做决策 | 我管方向和验收，它管实现 |
| 红线 | 不可逆损失、隐式全局改动、范围失控 | 数据/方案/范围，三件必须先问 |
| 上下文 | 聊久了忘事、重复劳动 | 定期收口、结论落文件、git 存档 |
最后：从「会用」到「用得好」
回头看这四篇，其实只讲了一件事，但换了个说法：
把判断力放在刀刃上。
| 新手 | 熟手 | |
|---|---|---|
| 一轮做多少 | 越多越好，一次到位 | 刚好能一眼判断对错 |
| 怎么验收 | 看着能跑就行 | 按要求真的操作一遍 |
| 出问题 | 沉默 | 明确说「我要 X，不是 Y」 |
| 变大之后 | 硬撑 | 收口 + 落文件 + git |
| 分工 | 全包给 AI，或者全自己扛 | 方向归我，实现归它 |
而这一切的核心，其实就是第一篇那句话的延伸：
你越不懂代码，就越要把每一轮切小； 越要把每一轮切小，就越需要你练「判断」这个能力。
「vibe」不是随便乱来，是把判断力用在刀刃上。
主线学完了，去做点东西吧
| 章节 | 你会学到 | |
|---|---|---|
| V1 | 什么是 vibe coding | 它跟「让 AI 写代码」差在哪 |
| V2 | 一轮该做多小 | 粒度、打断时机、每轮必问三句 |
| V3 | 怎么验收与纠偏 | 三个信号、红线表、纠偏三招 |
| V4 | 人机分工与长期不失控 | 分工、三条红线、上下文管理 |
接下来的路：