Vibe Coding 的十大习惯：让你的 AI 编程更高效
如果你也是一个经常和 AI 一起写代码的开发者，可能已经形成了一些属于自己的「肌肉记忆」。今天我想分享一下我在 Vibe Coding 过程中积累的十个习惯，看看能不能给你一些启发。
1. 每次任务开始前都会新开一个会话
这可能是我最坚持的一个习惯。每次开始一个新的开发任务，无论是实现一个功能、修复一个 bug，还是重构一段代码，我都会新建一个对话会话。
为什么要这样做？原因很简单——保持上下文的纯净。长时间的对话虽然方便，但往往会导致几个问题：AI 的注意力会被分散，早期的上下文可能已经过时，或者某些历史对话会不经意间影响当前的决策。新建会话就像给大脑一次「重置」，让 AI 能够以最清晰的状态来面对当前的任务。
当然，这也会带来一些「代价」——每次都需要重新输入项目的背景信息。但在我看来，这个代价是值得的，因为清晰的开端往往能带来更高质量的代码输出。
2. 开头就立好规则：先讨论，再动手
会话建立后，我不会着急让 AI 开始写代码，而是会先发送完整的上下文信息，包括角色设定、项目背景、约束条件、任务目标等等。我还会特别强调：先不要开始做，跟我讨论细节，等我确认后再开始。
这个习惯的背后逻辑是：磨刀不误砍柴工。在真正动手之前，把需求理解透、把方案讨论清楚，能够避免后续大量的返工。当 AI 理解了「为什么」之后，它给出的方案通常也会更加合理。
有时候，我甚至会使用 Claude Code 的 plan 模式，让 AI 先输出一个完整的执行计划，然后再进入 coding 阶段。这种「三思而后行」的方式，往往能让最终的代码质量提升一个档次。
3. 关掉自动压缩上下文功能
这是一个「反主流」但非常实用的习惯。很多 AI 工具默认会开启上下文压缩功能，目的是防止对话过长导致性能下降或者 token 消耗过大。但我会把这个功能关掉。
为什么？因为压缩上下文本质上是一种「信息丢失」。当你和 AI 讨论了很多细节之后，这些细节可能包含了重要的决策理由、排除掉的备选方案、特殊的边界情况处理等等。一旦被压缩掉，AI 就失去了这些重要的背景信息，后续的代码输出质量也会受到影响。
当然，关掉压缩意味着更高的 token 消耗，也意味着需要在适当的时候主动「清理」对话历史。但我觉得，相比之下，保持上下文的完整性更加重要。
4. 上下文有问题？立即回滚
这是一个需要「感觉」的习惯。当你在对话过程中发现 AI 的理解开始出现偏差，或者给出的代码方向不太对，不要犹豫，立即回滚上下文。
回滚之后，我会重新审视之前的对话，找出是哪个环节导致了误解。可能是我的提示词表达不够清晰，可能是某个关键约束没有说明白，也有可能是 AI 在某个地方「跑偏」了。找到问题后，重新编辑上下文，确保信息准确，然后再发送出去。
这个习惯帮我避免了很多次「将错就错」的情况。有时候及时止损，比坚持错误的路径要明智得多。
5. 规划用 Claude Code，编码用 Codex
这是我在工具选择上的一个小技巧。Claude Code 更适合做规划、思考、分析问题，它的能力更全面，理解能力更强，适合在需求讨论、方案设计、技术方案撰写这些「动脑」的阶段使用。而 Codex 在代码生成方面更加专注和高效，适合在明确了方向之后的编码阶段。
当然，这并不是说 Claude Code 不能写代码，或者 Codex 不能做规划。只是在长期的实践中，我发现这种「分工」能够让我在不同的阶段发挥工具的最大优势。
6. 只用御三家的模型
这里的「御三家」指的是 Anthropic、OpenAI 和 Google (Gemini)。不是我不想尝试其他的模型，而是在生产环境中，我更信任这三家的稳定性和可靠性。
这三个模型在代码理解、逻辑推理、指令遵循等方面的表现都是行业领先的，而且它们的 API 稳定性、服务质量都有保障。对于日常的开发工作来说，这种可靠性是非常重要的。
当然，如果你有特殊的需求，比如本地部署、成本控制、特定场景的优化等等，可能需要考虑其他的方案。但在大多数情况下，御三家的模型是不会让你失望的。
7. 先文档，后代码
在开始真正的 coding 之前，我一定会先产出需求文档和技术文档。这些文档不是写给别人看的，而是帮我理清思路的。
需求文档要回答的问题是：我们要做什么？为什么要做？做到什么程度才算完成？
技术文档要回答的问题是：我们怎么做？有什么技术选型？方案的优势和潜在风险是什么？
写完这些文档之后，我会和 AI 一起讨论，确保双方对问题的理解是一致的。这个过程可能会发现一些之前没有考虑到的问题，也可能碰撞出更好的解决方案。等讨论完毕、确认无误之后，再进入 coding 阶段。
8. 让 AI 给「选择」而非「答案」
当我需要 AI 帮我解决一个问题时，我通常不会让它直接给出唯一的解决方案，而是会说：给我可能的解决方案，并且说明他们的优劣。
这个习惯让我受益良多。AI 给出多个选项，能够拓宽我的思路，让我看到更多的可能性。同时，分析各个方案的优劣，也是一个很好的思考训练。有些时候，AI 提到的某个「劣势」可能是之前没有考虑到的关键点，这往往能帮我做出更好的决策。
而且，在让 AI 分析的过程中，我自己对问题的理解也会更加深刻。这种「教学相长」的方式，比直接要一个答案要有价值得多。
9. 规则手册要定期更新
每个项目都应该有一个「宪法」性质的文件，用来记录开发规范、团队约定、项目特有的约束等等。对于 Claude Code，这个文件叫 CLAUDE.md；对于 Codex，这个文件叫 AGENTS.md。
这些规则手册不是写一次就束之高阁的，而是需要随着项目的演进不断更新。每当遇到一个新的决策、发现一个需要注意的点，我都会及时把它加入到规则手册中。这样，AI 在后续的对话中就能自动遵循这些规范，大大减少重复沟通的成本。
一个好的规则手册，就像一个靠谱的「老员工」，能够把项目的「隐性知识」传承下去，让 AI 也能快速理解项目的特殊要求。
10. 用 AI 辅助写测试
测试是软件开发中非常重要但又经常被忽略的部分。在 Vibe Coding 中，我会充分利用 AI 来辅助编写测试代码。
前端部分，我使用 Playwright。Playwright 是一个强大的端到端测试框架，能够模拟真实的用户交互，对于前端 UI 的测试非常有效。我会让 AI 帮我编写测试用例，覆盖各种用户场景和边界情况。
后端部分，我更倾向于编写单元测试。单元测试更加精细，能够验证各个模块的内部逻辑。通过 AI 辅助，我可以更快地编写出覆盖率较高的测试用例，同时也能发现一些容易被忽略的边界情况。
有了测试的保障，代码的质量和可维护性都会大大提升。这也是「Vibe Coding」不「Vibe」的区别所在——真正的专业开发者，无论是否使用 AI，都不会忽视测试的重要性。
写在最后
以上就是我在 Vibe Coding 过程中积累的十个习惯。这些习惯不是一蹴而就的，而是在长期的实践中慢慢总结出来的。希望能够给你一些参考。
如果你也有什么好的习惯，欢迎在评论区分享！大家一起交流，才能共同进步。
最后，用一句话来总结我的 Vibe Coding 理念：和 AI 一起工作，不是让它替我写代码，而是让它帮我更好地思考。 毕竟，代码只是手段，解决问题才是目的。
