大多数人学 Vibe Coding 的方式，是买了一把好刀，然后用来开罐头。
我见过太多这样的场景：
装上 Cursor，接好 Claude，兴冲冲地说"帮我做一个 XX 产品"。
AI 开始写。你开始等。
三小时后，代码生成了，跑不起来。再让 AI 改。改完，另一个地方坏了。再改。又坏了。
最后关掉窗口，觉得 Vibe Coding 是骗局。
不是工具的问题。是你缺了工具上面的三层东西。
道：你在解决什么问题？
有人问我，为什么他让 AI 写了一周，项目还是一团乱麻。
我问他：你有没有在开始之前，用一句话写下"这个产品要做什么，不做什么"？
他说没有。
这就是症结。
AI 是执行机器，不是决策机器。你想不清楚，它帮你把"想不清楚"执行得非常彻底。
vibe-coding-cn 社区把这层叫做"道"，第一条原则是：目的主导，开发过程中的一切动作围绕"目的"展开。
还有一条，我觉得更重要：先结构，后代码。一定要规划好框架，不然后面技术债还不完。
这不是废话。这是 Vibe Coding 崩溃的根源。
大多数人一上来就让 AI 写代码。AI 写得很快，你也很爽。但没有结构的代码，每加一个功能都在借债。借到某一天，还不了了。
道，是你在动手之前，先想清楚你在做什么。
这一层，AI 帮不了你。
法：你的操作方式对了吗？
假设你想清楚了目标，下一步大多数人做的事是：把整个需求一股脑扔给 AI。
"帮我做一个用户系统，包括注册、登录、权限管理、社交绑定……"
然后 AI 给你一坨几千行代码。
你哪里知道哪里对哪里错。改动一个地方，三个地方出问题。
正确的法，是逆向的：先明确需求，从需求倒推模块，每次只动一个模块。
社区总结出来的原则：接口先行，实现后补。一次只改一个模块。
还有一条我自己最认同的：文档即上下文，不是事后补。
AI 的能力上限，是你给它的上下文质量。你事前写清楚每个模块的接口和边界，AI 就在边界里干活。你什么都没写，AI 就在猜。
猜出来的代码，是你最贵的技术债。
术：你有没有让 AI 在正确的边界里工作？
有个细节，大多数人没做但非常有用：
每次开始一段 AI 开发任务，明确告诉它能改什么，不能改什么。
听起来多此一举。实际上救过我很多次。
AI 有一种倾向：在解决你指定的问题时，顺手"优化"它觉得不好的地方。
你让它改登录逻辑，它顺手动了你的数据库 schema。
"优化"之后，别的地方坏了。你不知道是哪里，因为你没让它改那里，但它改了。
社区的术，第一条：明确写清能改什么，不能改什么。
第二条我每天在用：Debug 只给"预期 vs 实际 + 最小复现"。
不要给 AI 讲故事，不要解释你为什么觉得这里有问题。给它两样东西：你期望它做什么，它实际做了什么。一段最小的代码复现。
这两样东西给对了，AI 的 debug 命中率高两倍不止。
还有一条很反直觉：代码一多就切会话。
同一个对话窗口越来越长，AI 的注意力越来越分散。开新窗口，重建上下文，干净的 AI 比拖着一条长对话的 AI 好用。
器：工具是最后一层，也是最容易换的一层
说到这里你可能注意到，我还没提 Cursor。还没提用哪个模型。
这是故意的。
器是道法术都想清楚之后，才值得认真讨论的东西。
有了前三层，Cursor、Claude Code、Gemini CLI 都是工具，选适合当前任务的用。
社区在维护一个模型性能分级列表，每周更新。排第一梯队的这个月是 codex、claude opus、gpt-5.2。但这个名单下个月可能全变。
器是最容易换的一层。
换刀很简单。换脑子才难。
大多数人学 Vibe Coding，在器这层死磕。
用哪个 IDE、用哪个模型、用哪个插件。
换了一圈，代码还是烂的，项目还是跑不起来。
不是因为刀不好，是因为道法术没有。
vibe-coding-cn 社区把这四个字排在最前面，不是装哲学，是真的把最多人踩过的坑浓缩进去了。
道，想清楚做什么。 法，规划怎么拆。 术，约束 AI 怎么干。 器，最后再选刀。
你现在用 Vibe Coding，卡在哪一层？
评论区聊聊。
