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上面。夜已经很深了，就让我们相约在下一篇文章的开头吧，