【氛围编程的真相：模型不是瓶颈，工作流才是】

一个有趣的现象正在发生。

当Opus 4.6和Codex 5.3这些怪兽级模型摆在面前，很多人依然在重复同一个错误：打开对话框，开始聊天，期待奇迹发生。

这不是编程，这是赌博。

运气好的话，你可能一次成功。但大多数时候，你会陷入无尽的“修复循环”，代码库里堆满了从没人要求过的冗余代码，bug像地雷一样埋在各处，人和AI都无从下手调试。

Reddit上一位开发者分享了他的顿悟时刻：游戏项目卡在94%的完成度，无论投入多少Opus 4.6的算力都无济于事。最后他做了一件“古老”的事情，用自己的大脑思考了45分钟，重新设计了那部分架构，然后AI顺利完成了剩余工作。

有时候，思考比祈祷更有效。

社区逐渐形成了一套分层工作流的共识：

小功能迭代时，不要把整个代码库喂给模型。找到相关的一两个文件，精准提供上下文，控制影响范围。模型最擅长“修复”那些根本没坏的东西。

重构项目时，测试驱动开发是唯一的安全网。先写测试，再让AI重构代码直到测试通过。没有测试，你永远不知道迁移过程中丢失了什么功能。

小型项目和MVP，使用内置的计划模式就够了。把项目拆成模块化任务，每个检查点验证后再进入下一步。

大型项目则需要规格驱动开发。在动手之前，把整个范围用规格文档定义清楚。这些文档是唯一的真相来源。如果你现在不把需求写明白，等复杂度超过模型的理解能力时，一切都要推倒重来。

一位开发者提出了更深一层的洞见：真正的杠杆不在于你提供什么信息，而在于你以什么顺序、什么结构提供信息。每一步都应该消除自由度，直到模型别无选择，只能收敛到你想要的架构。这不是对话，这是编译。

另一个被反复强调的原则是：识别那些高杠杆决策，自己做。让AI处理几十个小选择，但那三到十个驱动一切的大决策，必须由人来定。当AI开始挣扎时，往往意味着你漏掉了某个关键决策点。

还有人提醒了一个容易被忽视的维度：安全性和合规性。有多少氛围编程的项目认真考虑过数据安全、GDPR合规？当用户数据流经这些快速搭建的系统时，硬编码的API密钥和环境变量可能正在某个角落等待被发现。

最后一条铁律：频繁提交代码。你必须能够随时回滚到上一个可用状态。当AI在第三步引入回归bug时，你可以用git diff找到差异，把它交还给模型处理。

模型的能力差距正在缩小，区分好输出和垃圾输出的，完全取决于你如何喂养它上下文。好模型给你速度，好工作流给你真正能用的产品。

www.reddit.com/r/ClaudeAI/comments/1qyphbw/vibecoding_is_no_more_about_models_its_about_how/