随着 Vibe Coding 实践越来越多，越来越顺手，效率提高了不少。但有些选择，还是琢磨了很久：
- 长会话还是短会话？
- 代码出问题，推翻重写还是让它改？
- Plan 模式还是 Agent 模式？
- 用 Git 管理还是用工具自带的功能？
- 用最强模型还是最快模型？
和周围 Vibe Coding 的朋友聊过，发现大家也有类似的琢磨。这篇就聊聊这 5 个选择，不一定对，权当一个探索中的讨论。
1. 长会话 vs 短会话
长会话：一个任务从头到尾在一个对话里完成。交代背景、提需求、写代码、发现问题、继续改，一路聊下去。
短会话：任务拆成小块，每块开一个新对话。每次对话只做一件小事，做完就开新的。
在琢磨什么？
核心问题是上下文。
长会话的好处是 AI 知道你之前说过什么。你说”把刚才那个函数改一下”，它知道你在说哪个函数，不用每次都解释一遍背景。
但长会话有两个坑：
第一个是上下文”污染”。聊着聊着，之前的错误尝试、被否定的方案、临时的 debug 代码，全都还在 AI 的记忆里。它可能会被这些东西影响，做出奇怪的选择。
第二个是信息丢失。现在各大产品在上下文变长之后，都会采取压缩或总结之类的策略。这会导致一些信息丢失——而且这些策略目前不太透明，不是一个完全可控的状态。你不知道它什么时候压缩了，压缩掉了什么。
短会话的好处是每次都”干净”，没有历史包袱。但代价是你得自己维护全局视角，每次开新对话都要交代背景。
我的选择
我现在偏向短会话，会控制上下文用量不超过 70%。当然，有时候偷懒了也会直接聊下去。这块还在摸索。
还没想清楚的地方
什么时候算”上下文污染”了？有没有一个明确的信号？
有时候 AI 开始说一些奇怪的话，但你也不确定是上下文污染，还是它本来就没理解你的意图。
2. 推翻重写 vs 修改代码
推翻重写：完全回滚到某个状态，让 AI 重新生成代码。”这条路走不通，换一条。”
修改代码：基于当前状态，让 AI 继续修改。”这条路有坑，但我们能绕过去。”
具体来说，”推翻重写”我一般会做两种操作：
- 回退：直接回到之前的某个版本
- 清除 + 重开：拒绝变更，或者用 Git 清除未暂存的代码，然后重新开一个会话，重新沟通需求
在琢磨什么？
两个典型的场景：
合并冲突类：你用 worktree 并行开发了两个功能，合并的时候冲突了一片。代码逻辑可能没问题，但版本状态乱了。
实现逻辑类：AI 写的代码能跑，但实现方式不对。或者写着写着，方向歪了，做成了另一个东西。
我的选择
我以前其实很少推翻重写，基本都是让 AI 在原基础上改。
但现在不一样了。自从用了 Spec 驱动的方式之后，推翻重写变多了。因为有了规格文档，重写的成本变低了——AI 不用从零开始猜你要什么，它可以直接看文档。推翻重写不再意味着”从头再来”，而是”换一条路再试”。
还没想清楚的地方
改了几轮算”该止损了”？
有时候 AI 改了两三轮还没改对，你会纠结：是再给它一次机会，还是直接回滚重来？
3. Plan vs Agent
Plan 模式：AI 先输出一个计划/方案，你确认之后它再执行。”让我想想怎么做 → 好，开始做”。
Agent 模式：AI 直接开始写代码、调用工具。”边做边想”。
在琢磨什么？
Plan 模式让你在执行前有机会纠正方向，但多了一个步骤。Agent 模式效率高，但你得等到代码出来才能判断方向对不对。
还有一个问题：如何识别”复杂”的边界在哪？
我以前被灌输的观点是”复杂任务才用 Plan”。但问题是，有时候你觉得简单的任务，做着做着就变复杂了。
我的心路历程
说实话，我之前基本都是用 Agent 模式。
为什么？因为 Agent 快啊。你说一句话，它直接开始干活，几秒钟就能看到代码。Plan 模式呢？它还要先想一想、输出一个计划，你得看一眼再让它执行。感觉多了一步，有点”浪费时间”。
而且当时我对 Plan 的理解是：这是给复杂任务准备的。简单的事情，直接 Agent 不就行了吗？何必多此一举。
但问题来了——什么叫”复杂”？
我发现这个边界特别难判断。有时候你觉得挺简单的任务，做着做着就变复杂了。等你意识到应该用 Plan 的时候，Agent 已经写了一堆代码，方向还歪了。
转变
后来有一天我突然想通了一件事：Plan 模式的”成本”到底是什么？
无非就是多花几秒钟生成一个计划。
那这几秒钟，我真的在乎吗？
以前我在乎，因为我只能串行工作——等 AI 输出的时候我就干等着。但现在不一样了，我在逐步提升自己并行工作的能力。Plan 生成的那几秒钟，我可以看看别的任务、回复个消息。这个时间成本，突然就不存在了。
那既然时间成本没了，Plan 还有什么坏处吗？
想了想，没有。
- Plan 不会让结果变差。最坏情况下，它和 Agent 一样，只是多花了点时间生成计划。
- Plan 可能让结果变好。它会在执行前帮你理清思路，提前发现方向偏差。
既然没有坏处、可能有好处，那为什么不默认用 Plan 呢？
我的选择
所以我现在的做法是：Plan 是默认，Agent 是辅助。
大概的分配是：80% 的任务我都用 Plan 模式，只有一些很小很确定的事情（比如”给这个函数加个注释”）才直接用 Agent。
接着上面”推翻重写”那个话题说——用 Plan 模式，走偏的概率会降低。因为在执行前你就能看到它打算怎么做，偏了可以直接调整，不用等到代码写完才发现不对。
另外，如果你用了 Spec 驱动的方式（比如先写好需求文档、设计文档），再配合 Plan 模式，回滚重新执行会变得更可控、成本更低。因为 AI 有文档可以参考，重新生成的一致性更高。
如果你和我以前一样，觉得 Plan 模式”太慢”或者”只有复杂任务才用”，可以试试把它当成默认选项。你可能会发现，它对你没有任何负面影响，反而可能帮你少走弯路。
4. Git vs 工具自带
Git：用 git 命令或 GUI 工具管理 AI 生成的代码。git diff、git checkout、git stash、git reset 这些。
工具自带：用 AI IDE 提供的功能。比如采纳/拒绝按钮、回滚功能。
在琢磨什么？
核心是粒度和管理维度的问题。
- 工具自带提供的是块级别的采纳——你可以在一个文件里选择接受这一段、拒绝那一段。
- Git 基础功能更多是文件级别的——
git checkout一个文件，整个文件就恢复了。当然 Git 也能做到更细的粒度，但需要一些特殊技巧，比如git add -p或者用 GUI 工具手动选行。
还有一个区别是管理维度：
- 工具自带可以从会话级别来管理代码变动——这一轮对话 AI 改了什么，你可以整体采纳或拒绝。
- Git 没有”会话”的概念，它只知道文件变了，不知道这些变化是哪次对话产生的。
我的选择
我现在很少用工具自带的功能，基本都用 Git。
首先混用会带来混乱。Git 处理的是底层文件变更，工具自带处理的可能是 IDE 层面的状态，两者不一定同步。如果混用，最后会很难追踪：哪些改动被采纳了，哪些没有？
所以我需要 选一个，坚持用（至少作为主力）。目前对我来说，Git 的确定性更高。
还没想清楚的地方
有没有一种方式，既能享受工具自带的块级采纳的便捷，又不会和 Git 状态冲突？
5. 最高性能 vs 最快速度
最高性能：选能力最强的模型。质量优先，愿意等。例如 Claude Opus、GPT-4o。
最快速度：选响应最快的模型。速度优先，能接受质量损失。例如 Claude Haiku、Gemini Flash。
在琢磨什么？
简单任务用顶级模型是不是浪费？复杂任务用快速模型会不会翻车？
我的心路历程
我之前的做法是：用性能最好的模型打地基。
为什么？因为地基很重要，框架质量不高的话，后面修补成本会很大。
但问题来了——后续遇到一些困难的问题，我还是不太放心交给速度优先的模型，最后还是会选性能好的。这样一来，最终其实没有拆分模型，大部分工作还是用的顶配。
后来我开始尝试一个新思路：先用有性价比的模型打地基，遇到疑难问题再用最好的模型。
为什么这个思路可能可行了？因为我有详细的 Spec 文档。AI 不用猜我要什么，它可以直接看文档，而现在”普通”模型在纯执行层的能力基本可靠，所以这种情况下打地基问题也不大。只有遇到真正复杂的问题（比如一些诡异的 bug、需要深度推理的逻辑），再切到最强模型。
还没想清楚的地方
这里有一个核心难题：怎么判断一个任务该用什么模型？
用好模型做地基，后面修补是不是也得用好模型？遇到小 bug，用好模型去修感觉大材小用，但用普通模型又不一定能修好。
说实话，这个判断挺难的。不同模型的局限和特长，需要自己慢慢摸索。所以更好的方式，是让工具自动帮你选模型。
现在很多 AI 编程工具都有这类功能，比如 Cursor 的 Auto 模式、Claude Code 的模型切换等。它们会根据任务复杂度、类型自动选择合适的模型——简单任务用快的，复杂任务用强的。这样既不用自己纠结，也能在保证效果的前提下提升效率、降低成本。
如果你也有类似的纠结，可以试试这类自动选择模型的功能。
写在最后
这 5 个小岔路口，没有标准答案。
我分享的也不是什么最佳实践，只是我的一些想法和尝试。你的答案可能和我完全不一样，这很正常。
不过有一点我觉得非常正确：Vibe Coding 看起来上手简单，但真要用好，还是需要刻意去练的。
就像我们当年学过设计模式、架构思维、各种技术方案一样，它不是一个天然就会的东西。都需要在工作中刻意积累、刻意练习。用得好和用得一般，工作效率差距挺大的。
这 5 个选择只是我琢磨过的一部分，肯定还有很多我没想到的。如果你也有类似的”琢磨”，或者有不同的选择，欢迎在评论区聊聊——
- 你试过 Plan 模式吗？是默认用还是只在复杂任务时用？
- 你有没有发现某个模型特别适合某类任务？
- 你更倾向长会话还是短会话？有没有自己的一套判断标准？
- 代码出问题到什么程度，你倾向于直接推翻重写？
毕竟 Vibe Coding 这件事，大家都还在摸索，多交流说不定能少踩点坑。
评论