Vibe Coding 的爽感来自”凭感觉也能出活”，翻车也往往来自同一个原因。几个不花哨的习惯——任务切小、随时自测、Git 兜底、管好上下文、摆正心态——能让即兴的写法和可控的结果兼得。

任务切小步

一次只让 AI 干一件事。”顺手把登录、支付、缓存一起改了”是翻车的标准开局：改动面一大，出了问题连该留哪块、该扔哪块都分不清。把需求拆成半小时到两小时能完成的小任务，每个任务目标单一、可以独立验收，做完一个看一个的 diff，再开下一个。

切小任务还有个附带好处：prompt 变短了。约束越集中，AI 越容易抓住重点；你要在一个长提示里同时交代五件事，它大概率漏掉两件。

随时让 AI 自测

不要等全部写完再验证。每个小任务完成后，让 AI 自己跑测试、贴出命令输出，而不是听它说一句”已完成”就收工。更稳的玩法是要求它先写会失败的测试再改实现：

先不要改实现。
先按需求补测试，覆盖正常路径、参数非法、权限不足、无数据这几种情况。
测试现在应该失败。我确认测试合理之后，你再改实现，直到测试通过。

测试先红后绿，比”一边改代码一边补一个永远通过的测试”可信得多。还要立一条规矩：没跑就必须明说”未运行”并给出原因，绝不接受一句”已验证”糊弄过去。

版本控制兜底

Git 是 Vibe Coding 最重要的安全网，应该在 AI 动手之前就位，而不是写砸之后才想起。开工前先确认工作区干净，然后给任务开专用分支，绝不在主分支上裸跑——AI 就算写歪了，歪的也只是这一个分支。

AI 每完成一小步、测试转绿就提交一次，一个 commit 只做一件事，message 写人话。这样出问题时能精确回滚到任意一个绿点，也能用 bisect 定位缺陷是哪一步引入的。改坏了优先用可控的回滚方式，合并之前自己完整看一遍 diff——AI 的总结写得再自信，也不如 diff 本身可信。

git switch -c feat/order-export   # 专用分支
git add -p                        # 分块暂存，一个提交只做一件事
git restore path/to/file          # 丢弃未提交的误改

上下文管理

会话不是越久越好。一个会话里先写登录、再改支付、再重构缓存，旧约束、失败尝试和废弃方案堆在一起，模型迟早把噪声当信号。上下文窗口大不等于效果好——装得下和找得到重点是两回事。

经验法则很简单：一个会话只做一件事；同一个问题纠正两次还不对，就开新会话，只带上当前任务说明、相关文件、失败日志和验收命令重新开始。长任务让 AI 顺手维护一份 handoff 笔记，记录已完成什么、还剩什么、下一步该读哪些文件，新会话直接从笔记接力，比口头重述半天历史可靠得多。另外，别把半个仓库塞进上下文，当前任务用不到的文件，给路径让它需要时自己读。

心态：快但会犯错的搭档

最后一条是心态。把 AI 当成一个手速极快、知识面广、但没有记性也不担责任的搭档：它能十分钟写完你一天的量，也会面不改色地编造一个不存在的 API。指望它自觉谨慎是不现实的，因噎废食回到纯手写也没必要。

合理的姿势是重新分工：方向你定，验收标准你写，合并按钮你按；它负责速度，你负责把关。信任要建立在测试、diff 和 review 这些证据上，而不是它自信的语气上。AI 写代码越快，Git、测试、评审这些老工程实践越不能丢——以前它们约束人，现在顺手约束 AI。快是它的本事，不出事是你的本事。

小结

  • 任务切小到一次一件事，每个任务独立可验收。
  • 随时自测：测试先红后绿，命令输出比”已完成”可信。
  • 专用分支加小步提交，随时能回滚到绿点。
  • 一个会话只做一件事，进展落进 handoff 笔记，及时开新会话。
  • AI 是快但会犯错的搭档：享受它的速度，把信任放在证据上。