氛围编程踩坑实录：我花了三个月才懂的三件事

为什么有人用AI写代码越写越快，有人却越写越乱？

答案藏在"先规划还是先动手"这个选择里。

一位开发者花了三个月时间，从"上来就写"的蛮干模式，摸索出一套分层用模型的方法。他的教训很具体：不做规划直接让AI实现功能，结果往往是N+1查询代替SQL连接（数据库性能灾难）、返工成本翻倍、代码质量飘忽不定。

这套经验对已经入门的程序员尤其有用——你知道代码长什么样，只是想让AI写得更快更好。

一图看懂：氛围编程的正确打开方式

整个方法可以浓缩成一张流程图：规划层→模型分层→执行反馈。我们逐层拆解。

第一层：规划不是浪费时间，是省时间的

作者最初的错误很典型：拿到需求直接开干，追求"最快出结果"。

后果是功能半成品、特性损坏、长期维护困难。根本原因有三：

第一，你不知道AI会怎么走。同一个功能，它可能选N+1查询（循环里一次次查数据库），也可能写SQL连接（一次性搞定）。前者在数据量上去后直接卡死。

第二，修改成本不对称。规划阶段改一句话的事，代码写完后可能要重构三个文件。

第三，AI的执行质量差异。作者发现：先给AI一份详细规划，再让它按规划写代码，输出质量"显著更好"。猜测是因为规划给了AI决策锚点，直接实现则容易"模糊漂移"。

GitHub Copilot有专门的Plan模式做这件事。作者的习惯是用Ask模式做规划和迭代——本质一样，都是让人先审一遍AI的思路。

第二层：模型要分层调用，别一上来就砸顶配

Claude Opus很强，但烧token的速度比你打字还快。

作者的解法：按任务难度匹配模型，像公司按职级分活。

简单讨论和问答→Claude Haiku（轻量、便宜）

架构设计和规划→Claude Opus（像资深工程师）

中小功能实现→Claude Sonnet或OpenAI Codex（性价比之选）

UI相关任务→Gemini（作者的个人偏好）

这里没有"最好"的模型，只有"最合适"的模型。省下来的token额度，留给真正需要深度思考环节。

第三层：编程知识是过滤器，不是替代品

文章有个容易被忽略的前提：作者是有编程基础的。

这解释了为什么他能识别N+1查询问题、能判断规划是否合理、能选择SQL连接方案。纯新手可能连AI给的代码有问题都看不出来。

氛围编程（vibe coding）的流行，让很多人误以为"会说话就能写软件"。但这位开发者的经验指向另一个结论：AI是加速器，不是起点。你知道目的地在哪，AI帮你抄近路；你不知道，它可能带你绕进沼泽。

实用清单：下次写代码前对照

1. 任何功能先让AI出规划文档，你审完再让它写代码

2. 根据任务类型选模型，别用重型模型做轻型活

3. 保留"能看懂代码好坏"的能力，这是你的护城河

氛围编程的真正价值，是让有基础的人更快产出质量稳定的产品。如果你还在学习阶段，它的作用可能是反面教材——帮你快速见识各种错误写法。