[其他] VibeCoding实战反思：从单兵作战到文档驱动与Agent团队的效率演进

最近启动了一个新项目，我再次选择了VibeCoding的方式。但这次的开局体验，与以往大不相同。

还记得之前进行VibeCoding时，流程非常简单：用一句话描述需求创建项目，然后把任何功能需求都直接用自然语言告诉Cursor。它会“哗啦哗啦”地生成代码，我简单Review一下，跑一跑没问题就直接提交了。

这次项目时间非常紧迫，所以我打算将VibeCoding贯彻得更彻底——连Cursor都没用，直接上手OpenAI新推出的CodeX，尝试全程不盯代码。起初一切看似顺利，但很快我就碰到了一个棘手的WebSocket连接问题。我反复修改了许多个版本，甚至把CodeX用到了限流，问题依然没能解决。

无奈之下，我只好回归老搭档：Cursor配合Opus模型。通过不断增删日志来定位问题，最终找到了症结所在。问题虽然解决了，但整个开发节奏因为人的深度介入而明显慢了下来。看到网上很多人把AI用得神乎其技，我不禁开始怀疑，是不是我自己的VibeCoding方式出了问题？但对于如何处理这类复杂问题，我一时也没有头绪。

在VibeCoding刚火起来时，我听说过一个概念叫“文档驱动开发”，一直挺好奇但没深究。前几天，一位同事在群里分享了一个GitHub仓库：https://github.com/yibie/SPEC-AGENTS.md，这正是实践文档驱动开发的工具。

这个工具的核心工作方式是：一个主Agents.md文件，配合一系列辅助的、经过意图识别后的Prompt Markdown文件，来强制Cursor识别不同意图并执行对应的Prompt（有点像技能意图识别）。此外，还有一个phrase文件夹，用于保存各种过程文件。面对不同任务，它会拆解并创建不同的文档，来记录产品定义、工作流状态以及所有的改动历史。

这么做有几个显著的好处：首先，产品的实现有了完整的文档定义，AI在实现功能时始终有一个宏观的产品框架可以参考，避免了“盲人摸象”。其次，所有改动都会留档。无论是人还是AI，在很久以后需要回来维护或修改时，都能通过清晰的改动记录快速回忆起来龙去脉，这一点至关重要。最后，它让AI自动进行任务拆解，这点看似与Cursor官方的PLAN功能重合。但基于文档的优点是，它可以维护任务拆解后的执行状态，而PLAN的内容往往在一次执行后就弃之不用了。

所以你看，虽然都叫VibeCoding，但之前那种“一句话描述”的原始方式，和现在这种基于文档、结构化的方式，仿佛已经是两个物种。后者是一种基于软件开发工作流的高级VibeCoding，它让AI的产出过程变得更加标准化、可管理。

这种方式本质上是将VibeCoding的过程管理了起来。虽然它可能依然无法完美解决我遇到的那种极端棘手的技术难题，但按照这种思路开发，遇到此类难题的概率或许会大大降低。如果你也对这种结构化的开源实战方法感兴趣，可以深入了解一下这个项目。

技术的迭代从未停歇。最近，Claude推出了全新的VibeCoding模式——基于团队协作的Agent Team模式。它允许Claude扮演“团队领导”的角色，并根据任务需求，动态地通过工具生成并指挥多个“队友”。我还没有亲自试用，但网上的初步评价相当不错。

这不再仅仅是Prompt层面的技巧提升，而是从工具层面革新编程速度的技术。它在文档驱动编程的基础上，叠加了多Agent协作，这很可能就是未来VibeCoding演进的主流方向。又是Anthropic这家公司率先推出，不得不承认，他们在模型与Agent能力的每一次关键升级上，都走在了前面。

AI世界的进化速度实在令人咋舌。短短一年间，我们已经见证了VibeCoding从概念到实践的巨变，而且这种加速进化的趋势仍在持续。说真的，我非常好奇，到了2026年，VibeCoding到底能进化到什么地步？

在这个过程中，保持对新技术、新工作流的敏锐度和讨论，对开发者而言至关重要。像云栈社区这样的技术论坛，正是交流这些前沿实践、碰撞思想的好地方。