Vibe Coding,真的让想法的实现变得简单了吗? 早在去年年末的时候,我的社交媒体主页便被浩浩荡荡的各种原生支持AI的IDE刷屏了。无论是科技大佬,还是普通程序员,似乎都在宣扬着一件事:ai coding的时代已经到来。作为一个对新技术抱有着好奇心的人,我早就有了借助着这技术的东风,实现一下我脑子里各种新奇的想法了,但是最初苦于考试和期末各种ddl的临近,错过了第一批吃螃蟹的机会。是大概是一月初的时候吧,期末考试终于到了尾声,虽然紧接着十四天的军训,但是总归没有指标和ddl的压力push,我也便有了尝试vibe coding的时间。
但是我脑子里面的想法这么多,上手的第一个项目应该做什么呢?手上股票的一通爆雷,给了我开始的动力和想法。作为一个大A新科韭菜,连吃三个跌停之后,我痛定思痛,决定做一个股票分析工作流 —— 这个项目不仅实用性很高,而且实现起来的逻辑并不困难,无非是让AI写个脚本爬数据,接个接口做数据分析嘛。当时我只想着:需求有了,workflow也确定了,时间也有了,那还说啥了,立马开干!但是最初幼稚和不够周到的设想,却让这个简单的项目做起来有些磕磕绊绊。
第一步要做的,便是PM的工作,也是在和AI的协作里面人最核心的角色:确定需求和技术路线。自己同时身兼PM和客户两个身份,最终目标输出很快就确定了下来:列出推荐股票。技术路线就更是简单了:包含多个工作环节,去年很火的n8n就能很方便地串联我整个流程会用到的所有工具。剩下的技术细节,比如用python脚本爬取数据啊,输出json文件啊,js code节点分析数据啊更不必多说。AI时代嘛,除了在搭建工作流的时候使用AI, 实际的产品里面怎么能少得了AI赋能?一个AI-driven的报告输出节点,成为了初版项目构思的最后一块拼图。刚开始时满怀不切实际的幻想,以为AI真的就可以替代人类完成所有工程上的问题的我,没过几天就意识到了自己的错误,不过这也是后话了,且让我继续道来我的第一次vc心路历程。
开发第一版MVP产品的时候大体上很顺利,但是在细节上也出现了一些问题。我选择了Qwen模型作为我的报告总结最终节点。但是n8n的原生AI节点并不支持Qwen的api, 尝试了多种open-ai格式的api key输入均无果。后面便转为使用http request 节点,换个格式通过api发送请求。不过在这个方案上也存在着AI无法解决的问题,在部署时,Gemini 反复给我提供错误的调用URL, 这也让我对AI的能力初次产生了祛魅。不得已,到最后查看了官方的文档,才把问题解决。如果说各色各样的开源项目AI也难以通过公开的资料完全掌握,那么纯代码编写和一些较老的软件工程需求便是AI的舒适区。三下五除二,第一版股市数据获取的脚本便被AI写好了。
在n8n里面连接好节点,我信心满满地点击了 “Execute Workflow” 这个醒目的橙色按钮。“怎么没有反应?”我心里直犯嘀咕。多按两下,屏幕右下角接连弹出报错:not a valid JSON。我才意识到:AI并非万能,完成这个项目也不是给AI发几个要求就能做好。换了claude和Gemini交叉验证之后,我加上了转换数据格式的节点,修改了好几版js code里面的代码。再次点击 “Execute Workflow” ,跟第一次尝试有所不同了,可惜不是成功的提示,而是新的报错。我不死心,至此开始了我心里不断在心里骂娘,不断要求AI debug的历程…
由于正值军训,我只有晚上有时间做这个小项目。军训前我还以为我军训期间的夜晚会和冬促刚刚入手的神界原罪2打交道,但是将一个有意思的想法落地的行为实在是太酷,太有意思了,让我乐不思绿维珑。项目总体框架aigc出的结果在大多数模块能work, 反复debug的不顺,我也比较乐在其中。终于在军训开始一周之后,周一开盘的前一晚,第一份可用的版本部署成功。
这个版本相较于前面的MVP构思,加入了开盘前和盘中定时触发,通过webhook让飞书机器人发送报告到群里等功能。看起来算是有个产品的样子了。我心里打着能通过这个工具回本的打算,期待着第二天的到来。不出我所料,搭建好的workflow成功捕捉到了电网设施爆发的趋势,借助着工作流选的票,我小小回血了一点。不过工作流的推荐也并非十全十美,报告推荐的票还需要人来二次筛选。正当这个工作流稳定运行了没几天,我优化的心思又起来了:我的投研分析助手只能抓取数据,不能根据我的个人持仓数据来进行定制化报告制定。
优化的方向有了,接下来的几天里,我还是难以顺利完成改进,我却再次陷入了缺乏系统技术栈知识,而导致debug总在一个错误的方向狂奔的误区。在功能开发的初期阶段,为解决本地环境无法接收回调的问题,AI 建议采用内网穿透方案,通过将内网服务映射为公网 URL,实现对飞书机器人消息事件的实时捕获。这个方法需要我每次重启工作流之后都在飞书后台填入cloudflare重新gc的url, 费时费力。可直到下一个大版本更新时才更换了更好的方案。这也可能是我偏信AI的后果吧。这期间还有个很有意思的小插曲。在原本的对话里,由于上下文过于长,导致AI的能力开始出现偏差,我开启了一个新对话。copilot新对话的第一个操作就是给我直接写了一个完整的工作流,让我导入到飞书里,把原来的工作流关闭了。我在听信了它的建议之后直呼上当。新生成的工作流完全不符合我的要求,但是旧的数据存在的docker容器因为我的使用不熟练,在一开始没有保存好,后面在终端虽然能找到对应的容器,但是容器里面什么都没有。
唉,这就是所谓的AI删库跑路吧,也算是让我遇上了。我个人的原因固然是第一位的,但是这次经历也给我提了个醒:最好不要交给AI你缺乏了解和掌控权的任务,不然最后能捅出什么大楼子真的难以预料。也一下子将我变成了和朋友打趣的玩笑话的主角:“AI可能会删库跑路” 。所幸项目的规模还不是很大,项目的思路也不是很复杂,断断续续做了几天晚上就恢复到了原来差不多的样子。正当我以为此后就高枕无忧,可以跟着这份报告买股票躺着数钱的时候,现实又给我浇了一盆冷水。
在持仓数据监控功能才没加上几天,问题又来了。这次是数据来源的问题。由于之前使用的是国外平台针对A股的数据接口,难免会追不上最新的热点和题材。最开始尝试的几个国内接口都有反爬虫机制,使用了多种反爬虫机制之后都爬取不到可用数据,后面也是作出了一点妥协,使用了两个不算最好的数据接口。正当我以为这个项目真的做完了,可以实现下一个创意时,只能说我还是太年轻了。用了两个多礼拜的上下文,导致AI的能力出现了倒退,想在最后优化一把接受处理数据的代码,却是越优化越糟糕。不得以只好回退大版本,重开对话,手动修改代码,才最后有了这个版本。目前这个版本只上线测试了两天,我估摸着还有很多可以优化的地方。Anyway, 我的第一次Vibe Coding经历,大概到此就没太多值得分享的地方了。
到此,我应该就能给出我开头提出的问题一个我主观视角的回答了:就我这次粗浅的体验来看,vibe coding 确实让实现一个MVP产品变得简单了很多。不过,使这个MVP产品不断进化,趋于成熟,依然需要系统性的知识作为支撑。换句话来说,我觉得只有懂技术的PM,才能把AI的潜力最大化。同时,最核心的权限最好还是掌握在自己手中比较好,避免真的发生AI删库跑路的惨案。
有些老调重谈太多也没有太多意思,题外话里面,我想分享一个有意思的现象和观点。本学期末我的社科报告主题是:AI时代的心流体验。在查询资料的时候,Google Dora 团队做的AI时代员工体验变化报告引起了我的兴趣。里面提到了一个现象:AI时代办公过程里面,员工体验到有意义的时候少了。研究人员因此提出了真空理论:是由于AI接管了简单低级的工作,为员工创造出了更多可用的时间,而导致的工作价值感下降。在我做这个小项目的过程里面,我得到的价值感减少不仅仅是由于AI接管了低级工作增加了我的空闲时间,我本来也没有上司限定的ddl 。更因为我在等待AI修改代码或者agent测试产品时,其自动运行长耗时任务中间创造出来的工作中空闲。在这段时间里面我无法实施有效的干预,我的思路也远远跟不上AI跑起来的速度。导致两次agent执行任务期间我只能干坐着,而两个任务中间测试代码和给出修改思路所耗费的时间又短于agent执行任务的时间。这正是我价值感缺失的另一个重要来源。
AI coding的种种问题仍然存在。不过这次项目的执行里面我感觉更多的原因还是出自我自身,确实,我缺乏系统性的训练来将AI的潜力发挥到极限。也许未来不断进化的llm会逐渐将一个普通人和资深程序员的鸿沟补足,但是到了那个时候,我们普通人做出来的还算是有灵魂有质感的产品吗?不经过普通人做出的不经用心打磨的产品还能够俘获用户的青睐吗?还能引申出很多很多的问题,我也期待着能见到这些问题被解答的那一天。
经过了这一次的尝试,我也算是尝试了一次自上而下了解项目的学习方法。也许完成下一个项目的过程中,我会和AI磨合得更好,有更多的收获,届时我也会分享到我的blog上面。夜已经很深了,就让我们相约在下一篇文章的开头吧,