别当外包用：vibe 开发的人机结对编程协议实战

Vibe coding 最危险的翻车，从来不是 AI 写错了一段代码。写错的代码会被测试抓住、被报错拦下、被你一眼看穿。真正的翻车是悄无声息的：三个月后你打开自己"做出来"的项目，发现你已经读不懂它了——不知道某个模块为什么这样设计，不敢动任何一行，改一个 bug 要先花一下午"考古"。人还坐在键盘前，但对代码的掌控感已经交出去了。这篇指南不教你"怎么让 AI 写得更好"，而是给你一套可执行的结对协作协议：把经典结对编程里的"驾驶员 / 导航员"模型，改造成一人 + 一 AI 的工作纪律。

划界说明（先说清这篇不是什么）：本站已有《一个人指挥四个 Agent：vibe 项目的多 Agent 并行开发工作流实战》（vibe-project-parallel-agents-workflow），讲的是"当经理"——一个人编排多个 agent 并行干活；也有《AI 写完代码之后：vibe 项目的代码审查实战流程》（vibe-project-ai-code-review-workflow）与《AI 代码审查清单》（ai-code-review-checklist），讲的是事后审查；还有《一人一 AI 的每日工作节奏》（solo-ai-daily-cadence-guide），讲的是一天的节奏。这篇的领地是它们都没覆盖的：单次结对会话之内，你和 AI 这"两个人"怎么分工、什么时候换手、怎么互相制衡。"当搭档"，不是"当经理"，也不是"当质检员"。

一、结对不是外包：驾驶员与导航员的 AI 时代重构

先把一个最常见的误区钉死：很多人嘴上说"AI 结对"，实际干的是"AI 外包"。外包模式是这样的：你把需求描述丢过去，AI 吭哧吭哧写完，你跑一下，能跑就合并，不能跑就让它再改。在这个模式里你是甲方，验收只看结果，过程是个黑盒。而结对编程的原始定义恰恰相反：两个人、一台机器、一个问题，对过程共担责任——写代码的人（驾驶员，driver）负责敲下每一行，坐在旁边的人（导航员，navigator）负责盯着方向、随时叫停、思考下一步。

为什么这个区分在 AI 时代更重要了？因为 AI 把"外包"做得太舒服了。舒服到你会不知不觉签下一份隐形合同：AI 负责写对，你负责点"通过"。这份合同的问题在于，AI 违约时你毫无察觉——它不会告诉你"这段逻辑我其实是猜的"，它只会用自信的注释和工整的格式让你放松警惕。结对模式的价值，就是把这份隐形合同撕掉，换成三条明规则：

规则 1：永远有一个人在开车，另一个在导航

不能两个人同时开车：你写核心逻辑的同时让 AI 也写同一模块，最后合并 diff 的时候就是灾难。也不能两个人同时导航：光讨论架构、谁都不动手，一下午过去仓库里多的是聊天记录、少的是代码。每次只明确一个驾驶员。开工时就说清楚："这段我来写，你盯着"或者"这段你写，我来 review 每一行 diff"。

规则 2：导航员的权力大于驾驶员

这是经典结对里最容易被忽略的一条：导航员可以随时叫停、要求解释、否决一个实现方向。人机结对里这条要双向落实。AI 当导航员时，你要明确授权它打断你——"如果你发现我的方案有问题，直接打断我，不要等我说完"。你当导航员时，对 AI 的每一句"就这么办吧"保持怀疑，要求它先讲清楚 trade-off 再动手。

规则 3：换手是常态，不是仪式

经典结对建议每 25 分钟换一次手，人机结对不建议按时钟换，而建议按信号换——信号来了就换，没信号就别为了换而换。信号是什么？第三章专门讲。

	外包模式（甲方心态）	结对模式（搭档心态）
责任归属	AI 负责写对，我只负责验收	过程共担：每一行最终都是"我们"写的
提问时机	跑不起来了才问	动手前、动手时、动手后都问
对代码的熟悉度	能跑就行，不必读懂	必须能讲清楚每一处关键逻辑为什么这样写
出错时的反应	"AI 又写错了，重写一版"	"我们哪里没对齐？协议哪个环节漏了？"
三个月后的结果	读不懂自己的项目，不敢重构	代码是自己参与长大的，敢动、敢改、敢删

二、开工协议：动手前 15 分钟，先对齐再让 AI 写第一行

所有结对翻车的根因，几乎都能追溯到开工的前 15 分钟：目标没对齐、边界没划清、验收标准没说。人类结对时，两个人坐下来自然会聊两句"今天搞什么"；人机结对时，AI 不会主动跟你对齐——你必须把"对齐"变成一个强制动作，发生在第一行代码之前。

开工协议只有三件套，缺一不可：

1. 目标：这次会话结束时，什么东西能跑起来

不是"做用户系统"这种愿景，而是可演示的结束状态。好例子："用户能注册、登录，登录后看到自己的 dashboard，数据落在 Postgres 里"。坏例子："把认证模块搞一下"。目标必须具体到"结束时我能亲手点一遍"的程度。如果一个会话的目标需要超过 2 小时，说明目标太大，先切小。

2. 禁区清单：AI 绝对不能碰的东西

这是整套协议里 ROI 最高的一张清单。AI 的"顺手"是灾难之源：顺手升级了依赖、顺手重构了隔壁文件、顺手把你的环境变量提交了。禁区清单要每次开工时亲口（亲手）列出来，不要指望 AI 记得上次的。参考模板：

• 不动数据库 schema，不删、不改已有迁移文件
• 不引入新依赖——要加先问我，说明理由和体积
• 不重构本次范围之外的代码，看到坏味道先记下来，不顺手改
• 不写死任何密钥、Token、内网地址
• 不"顺手"修不相关的 lint 和格式问题——diff 必须干净，只包含本次任务
• 删代码前先问我，确认没有别处引用

3. 验收标准：怎么证明做完了

验收标准 = 可运行的命令 + 可观察的行为 + 不被破坏的现有行为。三句话模板："跑 npm test 全绿；浏览器里走一遍注册-登录-退出流程；已有的订单流程不受影响。"把验收标准写在前面，AI 写代码时心里就有了一根线，而不是写到哪算哪。

开工话术模板（直接复制改关键词就能用）：

"你是我的结对搭档，不是外包。先立规矩：1）动手前先复述你理解的目标，得到我确认再写第一行代码；2）禁区：不动 schema、不加新依赖、不碰范围外代码、不写死密钥，删代码前先问；3）每完成一个子任务停一下，等我确认再继续；4）不确定的地方先问我，不要猜。现在，请复述你理解的本次目标。"

注意第 1 条里的"复述"：这是整个协议里最便宜、最好用的质量门。AI 复述目标时暴露的偏差，是全文最便宜的 bug——在它写 500 行代码之前纠正，成本是 1 分钟；在它写完之后纠正，成本是一下午。

三、角色切换的四种信号：什么时候该换人开车

前面说了，换手不按时钟、按信号。信号就是那些"你继续当前分工会吃亏"的时刻。我把它收敛成四种，每种都给识别方法和第一句话术——信号出现时，你不需要思考，直接执行。

信号一：需求模糊时，你开车

AI 在模糊需求下最危险的特质不是"写不对"，而是"自信地猜"。你含糊地说"大概像 Notion 那样"，它能给你一套完整的数据模型和界面，跑得还挺顺——但那是它猜出来的 Notion，不是你要的。猜错方向的返工成本，远高于你自己先想清楚再写的成本。

识别方法：检查你刚写的 prompt，如果里面出现了两个以上的"大概""可能""差不多""看着办"，需求就是模糊的。另一个信号：你发现自己在反复让 AI"换个思路"——这说明你心里也没想清楚要什么，只是在用 AI 的输出帮你思考。

动作：收回键盘。自己先写 10 分钟伪代码或接口草稿——哪怕只是注释里的大纲。把"想清楚"这件事从 AI 手里拿回来，再让它去填充实现。第一句话术："停。这部分需求我还没想清楚，先别写。你帮我列三个问题，问清楚了我再定接口。"

信号二：体力活时，AI 开车

这是 AI 的主场：样板代码、CRUD 接口、测试脚手架、重复性数据迁移、把 20 个文案 key 批量接入 i18n。这类工作的特点是：你闭着眼睛都知道怎么写，写的过程不产生任何新认知。让人写是浪费，让 AI 写是赚到。

识别方法：问自己"这件事做完，我会比做之前更懂这个系统吗？"如果答案是"不会"，就是体力活。

动作：把规范一次讲清（命名、前缀、放哪个目录、参考哪个现有文件），然后让 AI 全速写，你当导航员，只看 diff 不看过程。第一句话术："这是体力活，你全速写。规范：参考 src/api/order.ts 的结构，命名用 camelCase，写完列出你新增的文件清单等我过目。"

信号三：关键决策前，强制换手

选数据库、定核心数据模型、定对外 API 的形状、选第三方库——这类决定的特点是改起来很贵，一旦写进几十个文件，再想换就是 migration 级别的痛苦。贵决策不能由"当前在开车的人"顺手定。

识别方法：问"这个决定如果下周被证明是错的，改掉要花多久？"如果答案超过半天，就是关键决策。

动作：停下手，强制进入"导航员对谈"：让 AI 列出 2~3 个方案的利弊和适用场景，你来拍板；或者反过来，你列方案，让 AI 负责挑刺——"假设我们选了方案 A，你扮演反对者，找出它三个月后最可能爆的三个问题"。第一句话术："这是关键决策，先别写代码。你给我两个方案的对比：改动成本、长期维护成本、最坏情况。讲完我来拍板。"

信号四：AI 开始"自由发挥"时，立刻接管

这是最需要肌肉记忆的一条。AI 的"自由发挥"有固定前兆，认出来就要像副驾驶抢方向盘一样果断：

• diff 突然变大：你让它改一个函数，它交回来 8 个文件的 diff
• 改了你没提的文件："顺手"动了配置文件、入口文件、其他模块
• 注释里出现"为了 robustness，我还顺手……"——"顺手"是警报词
• 开始重构不相关的代码，或主动升级依赖版本
• 你连续两次说"不是这个意思"，它还在同一方向上打转

动作：叫停，回滚到上一个检查点（git 就是你的安全带），把范围重新钉死，一次只给一个最小指令。第一句话术："停。回滚到上一次提交。这次只改 login.ts 这一个文件，其他文件一个都不许碰。复述一遍你的任务范围。"

信号	谁开车	识别方法	第一句话术
需求模糊	你	prompt 里"大概/可能"超过两个	"停，先别写。你先问我三个问题。"
体力活	AI	做完也不会更懂系统	"你全速写，规范参考 xx 文件。"
关键决策	先都不开，谈完再定	改错的成本超过半天	"先别写代码，给我方案对比。"
AI 自由发挥	你立刻接管	diff 变大/动了没提的文件/"顺手"	"停，回滚。这次只改这一个文件。"

四、信任校准三阶段：从"逐行审查"到"放手"

信任不是一下子给出去的，也不是永远不给的。健康的结对关系里，信任度应该跟着"AI 的实际表现"动态校准。我把它分成三个阶段，每个阶段有明确的审查强度和降级触发条件——升级靠表现，降级靠规则，不靠感觉。

阶段一：逐行审查（新搭档 / 新项目前两周）

刚开始合作，或者刚开一个新项目时，默认进入这个阶段。AI 的每段输出你都读 diff、都跑测试、看不懂就追问。这个阶段的目标不是"抓 bug"，而是建立你对 AI 出错模式的认知：它在哪类问题上最爱翻车？是边界条件？是并发？是过度设计？把它的"错题本"记在心里，这是后面两个阶段敢放手的前提。

阶段二：抽查（磨合期）

当 AI 连续几个会话表现稳定，进入抽查阶段：只看关键路径的 diff，普通 diff 随机抽查 20% 左右，测试照样全跑。省下来的审查精力，投到架构和需求层面——这才是人该干的活。抽查不是偷懒，是把审查资源从"每一行"重新分配到"关键行"。

阶段三：放手（成熟期）

长期合作、AI 对你的代码风格和项目约束已经吃透之后，可以放手：只看验收结果和架构级 diff。但"放手"不等于"放羊"——放手阶段必须保留一票否决的触发器，触发条件见下。没有触发器的放手，就是外包。

降级触发条件（任何一条命中，立刻退回上一阶段，不讨论）：

• 连续两次"停车检查"（见第五章）发现问题——说明当前信任水位虚高了
• 进入不熟悉的技术栈或模块——新领地一律从阶段一重新开始
• AI 换了模型版本，或你换了结对工具——搭档换了"脑子"，信任清零重计
• 项目超过两周没碰——上下文腐烂了，你和 AI 都不再是"知情者"

阶段	审查强度	适用时机	目标
一：逐行审查	每段 diff 都读，测试全跑	新搭档、新项目、新模块	摸清 AI 的出错模式
二：抽查	关键路径全看，普通 diff 抽 20%	连续数个会话表现稳定	把精力转到架构和需求
三：放手	只看验收结果和架构级 diff	长期合作、约束已吃透	让人只做人该做的事

五、验证节拍：每 20 分钟一次"停车检查"

开车的人不看路，迟早翻沟——不管开车的是你还是 AI。所以协议里要有一个不依赖"感觉"的固定节拍：每 20 分钟（或每个子任务完成时，取先到者），停下来做一次停车检查。20 分钟不是拍脑袋的：它短到问题还没发酵，长到不至于打断心流；更重要的是，它是一个"不管顺不顺利都要停"的纪律，顺利时的检查恰恰最有价值——顺利往往意味着你放松了警惕。

停车检查只做三件事，每件都不超过 3 分钟：

1. 跑测试——不是"应该能跑"，是"跑了"

"应该能跑"和"跑了"之间，隔着 AI 全部的幻觉。让 AI 说"测试通过了"你就信，等于把验收外包给了被验收的人。测试必须在你看得见的地方跑：本地终端、CI 日志，亲眼看到绿色。跑不起来？先修测试环境，再谈代码——环境问题拖过 20 分钟，就会变成"先绕过去"的技术债。

2. 读 diff——只看"增量"，不看"全量"

停车检查不读整个文件，只读这次增量。git diff 拉出来，逐 hunk 过一遍，重点找三样东西：我没要求的东西（顺手改的）、我看不懂的东西（看不懂就问，不要"应该没事"）、悄悄引入的新依赖或配置项（对照禁区清单）。

3. 追问"为什么这样写"

这是三个动作里最重要的一个。它不是质疑，而是在逼 AI（和你自己）把隐式假设显式化。"为什么用 Redis 而不用内存缓存？""这个重试次数 3 是怎么定的？""如果用户量涨 10 倍，这里会先崩哪里？"——AI 回答的过程，就是你们俩共同把设计想清楚的过程。很多 bug 不是写错的，是"想都没想"漏掉的，而这个问题专门打捞"没想"的东西。

停车检查清单（打印出来贴在显示器旁边）：

• ☐ 测试亲眼跑过且全绿（不是"应该能跑"）
• ☐ diff 里没有我没要求的东西
• ☐ 我能用一句话解释每一处新增逻辑
• ☐ 没有悄悄引入的新依赖 / 新配置项
• ☐ git 状态干净，回滚点还在（随时能退回这一步之前）
• ☐ 问过至少一个"为什么这样写"，得到了说得通的答案

六、收尾：决策日志与"下次开工包"

AI 结对和人类结对有一个本质区别：人类搭档记得上周你们为什么选了方案 B，AI 下次打开会话时是一个全新的它——上下文窗口清空，记忆归零。你今天跟它对齐的所有东西（禁区、约束、那些"千万别这么干"的教训），下次都要重来一遍，除非你把它写下来。所以收尾不是"可选项"，而是协议的最后一环：让上下文不随会话关闭而丢失。

每次收尾写两份东西，5 分钟搞定：

1. 决策日志（给未来的你看）

只记"决策"，不记"流水账"。模板：

• 日期 / 会话目标：一句话
• 做了什么：2~3 条，要点即可
• 关键决策：选了什么、为什么选、否决了什么（否决了什么比选了什么更重要——防止下次重蹈）
• 遗留问题：没做完的、当时绕过去的、下次必须面对的

2. 下次开工包（给下次的 AI 看）

这是给"全新的它"的 briefing，让它 2 分钟内达到今天结束时的认知水平。模板：

• 项目一句话：这是什么、给谁用的
• 当前状态：做到哪了，什么是能跑的
• 下一步：下次会话的第一个任务（具体到"改哪个文件的哪个函数"更好）
• 禁区提醒：把禁区清单里本次 relevant 的 2~3 条抄过来
• 关键文件路径：3~5 个，新搭档最需要读的文件

收尾话术模板："会话结束前，帮我生成两份东西：1）今天的决策日志：做了什么、关键决策（选了什么/为什么/否决了什么）、遗留问题；2）下次开工包：项目一句话、当前状态、下一步、禁区提醒、关键文件路径。存成 SESSION_LOG.md，下次开工我会先贴给你看。"

坚持一个月，你会得到一本"项目的黑匣子"：任何时候打开 SESSION_LOG，都能回答"我们当时为什么这么干"。这本日志的价值在出问题时最大——线上爆了、要回滚、要重构，第一反应不是翻 git log 猜，而是看日志里"当时否决了什么"。

结语：把"掌控感"变成纪律，而不是感觉

回到开头：vibe coding 最大的翻车不是 AI 写错代码，而是人逐渐失去对代码的掌控感。掌控感这东西很玄——你觉得自己还有，其实已经没了。结对协议做的，就是把"掌控感"翻译成可执行的动作：开工前对齐三件套、按四种信号换手、信任分三阶段校准、每 20 分钟停车检查、收尾留下决策日志。AI 越强，这套纪律越重要——因为 AI 越强，你"感觉良好"地交出掌控感的速度就越快。

最后送一张速查表，贴在你跟 AI 结对的第一个会话旁边：

环节	动作	一句话
开工	目标 + 禁区 + 验收，三件套对齐	让 AI 复述目标再写第一行
进行中	四种信号决定谁开车	模糊你开、体力 AI 开、决策先谈、乱发挥立刻接管
信任	逐行审查 → 抽查 → 放手	升级靠表现，降级靠规则
每 20 分钟	跑测试、读 diff、问为什么	顺利时的检查最有价值
收尾	决策日志 + 下次开工包	上下文不随会话关闭而丢失

别当外包用。结对，才是 vibe 开发里人该坐的位置。