昨天下午参加了腾讯云上海架构师同盟组织的线下沙龙《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对就业的影响。
这一切,似未曾拥有