为什么你的 Vibe Coding 体验那么差？

昨天下午参加了腾讯云上海架构师同盟组织的线下沙龙《AI时代架构师如何Vibe Coding》。对于这个前沿话题，分享嘉宾各有观点，引发了激烈的辩论，作为听众的我也是收获颇丰。

由于这半年的时间，我几乎每天都在与Vibe Coding打交道，从最初Cursor、到后来的Trae、CodeBuddy、Claude Code，每次接触新工具，我都会用一个实际的可上线小产品为目标去尝试，也就是说整个过程会涉及到数据库设计、后端开发、前端开发、运维部署等多方面的考量。

所以对于Vibe Coding，我还是有很深的体会。在听分享的过程中，也是激发了很多思考，但是昨天没能有机会表达，所以最近准备开几篇聊聊关于Vibe Coding的一些想法。

为什么你用不好 Vibe Coding ？

很多人在刚开始尝试Vibe Coding的时候，都会遇到一些问题，目前所看到的各种吐槽，其实我都遇到过，开始我也吐槽，但是多用一段时间之后，我发现这些其实都不是问题，根据工具迭代的过程以及使用技巧的掌握，大多问题都是可以解决的。

下面拆解几个典型的问题：

问题 1：一下生成一大堆内容，几十个、上百个文件，持续对话越调越差

这个问题其实目前随着工具的迭代，我已经很久没有遇到过了。目前的先进Vibe Coding工具，基本都具备任务规划和逐条确认的功能，所以不太会出现一下出来很多内容的情况。AI与开发者是一个逐步review、confirm的小步快跑模式。所以，如果遇到此类问题，我的建议是：先升级到更先进的工具！

Vibe Coding工具是是目前迭代最快的工具，所以千万不能因为一两次的使用体验不佳就去否定和放弃它。因为换个更新的工具或等下周的版本，可能就解决了你的问题。

问题 2：解决不了复杂问题，无法胜任大规模系统

对于这类问题，主要有三种情况，常见于不同阶段的实践者：

• 模糊问题：常见于刚开始使用的开发者，处理结果不尽如人意往往是由于：对于实现的目标描述过于模糊，这就使得AI很难明确理解你的目标，自然就很难猜对并产出你想要的结果。所以，在 Vibe Coding的时候，清晰的语言组织能力，将需求清楚的描述出来很重要。
• 复杂问题：常见于我们使用Vibe Coding做了一个Project之后，需要做一些变更，此时我们已经具备一些基本使用技巧，能够详细描述我们的需求要点，但由于该需求的实现在一个Project中需要跨越多个不同模块（比如：用户、订单、库存）、不同职能（比如：涉及前端开发、后端开发）、工程管理相关内容（部署脚本的变更、监控端点的对接等），由于上下文的限制，AI很难全面的理解当前情况以给出合理的修改。最简单的解决方式是，缩小AI解读的边界，节省无谓或错误的解读，在提出需求的时候，就指定参考范围、使用什么工具类、前后端实现的边界确定等措施，这依然可以有效地帮助我们解决复杂问题。
• 系统问题：再进一步，当业务复杂的情况下，已经抽取不同的微服务进行独立管理。Vibe Coding是否依然可以胜任呢？我的答案是：必须可以。但我们需要通过设定任务的边界去执行任务，而不是粗暴的把几个project在一个窗口中打开，然后开始Vibe Coding。这种情况下AI可能更无法全面了解系统情况，导致更差的结果。而且这种就目前的上下文限制来说，可能步子还是迈的大了一些。

针对这些问题，可能有人会说：“问题这么多，是不是要学习很久才能掌握和用好Vibe Coding呢？”

从我个人经验来说，自己摸索的话，确实可能需要话费不少时间。但是从团队组织来说，为了加速组织进步，我觉得未来可能会出现一种职位：Vibe Coding架构师。

他们的主要任务类似现在的基础平台架构师（不同公司可能有不同的叫法），主要针对于公司的技术规约做基础框架支持的人。

他们通过封装组件、提供工程脚手架等措施，让组织的项目能够通过预设的结构来让代码符合标准，而手段就是通过MD文档的形式，预设在各个项目里，比如以Claude Code为例，我们可以为不同类型的工程加入一下Vibe Coding的规范，比如：

• 预制好不同的CLAUDE.md文件来统一公司项目技术栈和一些基础规约
• 根据不同类型的工程，设置好不同的sub-agent来拆分处理不同的任务

由于Vibe Coding作用于业务代码产生过程中，所以这些规约将增强基础平台架构师对业务开发细节上的把控。

举个最简单的例子，以往我们通过脚手架，能控制的主要是工程结构、监控埋点、统一依赖版本等比较固化的东西，而对于类似参数命名等约定性的东西依然缺乏控制。所以，我觉得Vibe Coding架构师是基础平台架构师的一种升级形态，利用Vibe Coding的规约，更好的把控项目规范。

感谢阅读，下一篇再聊聊Vibe Coding对就业的影响。