我是一个技术人，既不是那种天天需要写代码的，也不是那种天天都不写代码的，Coding纯属兴趣，不求完全靠这个吃饭，只求在探索的过程中找到自己的快乐。正如网名所示，我的文风将会是“流水账”，因为我相信，技术的探索永远在过程中，如果有人在乎过程，那么经过一定提炼的探索流水账，将比一个精炼的总结更有价值。
我怎么开始的Vibe Coding
我对Vibe Coding探索的开始来源于2个月前的一次面试，遗憾的是不是面试之前的准备，而是面试之后的复盘。一场提前告知用一小时写一个Agent的现场测试，被我想当然地理解成了低代码（因为本来也是解决方案岗位），复习了1天扣子平台的使用，结果现场说全代码的时候就有点懵了。来都来了，只能利用之前积攒的代码片段+ChatGPT/Gemini的方式硬上一份LangGraph.js，结果1个多月没有尝试，LangGraph.js从v0.3升级到了v1.0，相关的其他依赖库也出现了一些变化，之前的代码片段很多都不工作了。
在凑合工作就行的要求下不断妥协，舍弃了PDF解析（因为依赖问题），舍弃了使用State运行Graph（因为现场着急，少写了一个参数，一直跑不通），而直接使用LangChain.js加上下文的方式（不得不在开始加个意图识别），当把PDF转成复制粘贴放进去，意图识别各个分支都跑通的时候，我的1小时到了，而我的主逻辑还什么都没写。
面试官告诉我，我这个玩法，除非提前透题，基本1小时不太可能，如果真的用Cursor之类的配好了，1个小时一般都能搞定。
这一幕就好像15年第一次真正见识到iPhone的顺滑，手里的诺基亚顿时不香了。
Vibe Coding我用什么工具
把目光放在当下，Vibe Coding的工具琳琅满目，IDE和CLI各展神通。看了一些CLI的介绍，尝试了一下Gemini CLI，感觉对我来说还是有点高端了。我感觉关键的点可能在于，当大牛在Vibe Coding的时候，主要就是设计和审阅代码，而我除了做个POC，其他的还是需要一些学习，这个时候能快速跳转到定义，新加代码的diff之类的IDE功能对我来说就很有必要，所以决定还是留在IDE。
另一方面，实话说Cursor在四五个月之前就尝试过，但是作为JetBrains 10+年的ToolBox用户，实在是有点接受不了那个用户界面（包括VSC，我也从来只是用来改配置和当剪贴板用）。再加上不知为何一直有一个执念就是左上角必须永远展开根目录的文件树，第一次安装Cursor后看着四处空荡荡加上不知从何开始的界面，不到1小时就放弃了。后来在2个月前再次安装新版本的时候，感觉新版本的界面上就清晰了很多，勉强是可以接受了，这里就不再赘述了。
尝试用Cursor做了一些POC，免费用户，流量用完之前还是很6的，可惜持久性不太行，如果想持久当时试着可以换Gemini的2.5 Flash，便宜很多，基本就不太能用完了，但是效果也确实打了折扣。
之后也尝试了一下G家的Firebase Studio，这是一个在线版本的IDE，也是VSC的界面，全浏览器的方式还是挺新颖的，不过考虑G家产品的你懂的的情况，即使有了辅助工具，但是效果还是差一些，偶尔会出现掉线的情况。
最近尝试的比较多的是JetBrains + Google Code Assist的方式，Google Code Assist虽然是一个插件，但是具有Vibe Coding的能力，但是考虑JetBrains相对不那么开放，使用过程中还是有很多功能方面的额限制。比如过程中不能通过点击运行脚本而只能手动将它给你的命令复制到命令行，周边的工具支持也接近于没有。我是在WebStorm 2025.1.1 （2025年年中发布）上开始尝试的，这个版本的拓展功能只有Prompt模板和MCP，而MCP还不支持HTTP请求，stdio测试中发现也有各种问题，模型不能选，实测应该使用的是Gemini 2.5。
考虑到MCP不好使，我尝试把WebStorm升级到了最新的2025.3.1，结果奇迹出现了，我发现我的Gemini又连不上了，利用AI研究了半天，大概的结论是2025.3大版本有一个比较大的变更，JavaScript有单独的Runtime，结果就导致用之前的全局代理或者全局变量就挂不上了代理了，又是一顿研究发现似乎用用现在的代理配置是无解，AI给出的建议是配置一个TUN模式的代理，就先放在一边了。
之后又看了一些其他的候选的，在这个过程中尝试了Gemini CLI一个小时然后放弃了。又回去看了看Cursor结果额度很快用完了。最后看到的是G家新出的Antigravity，这个IDE看上去调起的很高，想先试试，结果卡在了登录上，网上搜一搜发现，还是前面类似的代理问题。这个时候我意识到，这个TUN可能真的得花点时间研究研究了。于是之后一天就在弄这个了。
今天当我把这个TUN弄好之后，Antigravity的登录通过了，也终于可以开始了尝试。
那么就可以回来说说我们的主题——版本问题了。
Vibe Coding的版本问题有多苦
如果你用到的库在设计的时候，都考虑了前向兼容，生态上各种依赖包也考虑了相互的版本兼容，那么你可能永远都体会不到它的苦。
我这几天在折腾Google Code Assist的过程中想到的关键的一个主题就是，想解开我当时面试过程中遇到的一个结：最新的很多软件库变化太快，很多更新出现在大模型训练边界之后，新的变化和老的很多还不兼容，导致大模型里老的代码加上安装的latest库就不太好使。而如果不用latest，AI经常会给出一些比较随机的版本，再使用其他版本的方式给你代码，这种代码基本就是跑不通。
这里给大家举几个比较明显的例子:
LangChain.js里的OpenAI API模型调用
LangChain/LangGraph的代码让AI来写，是一个大坑，主要体现在至少我了解的LangChain.js和LangGraph.js，v0.1, v0.2, v0.3和v1.0的语句变化都非常大，而AI在给出解答时经常不太能对上版本，结果就会导致，要么参数报错跑不通，要么用了已经过时的语法。
比如在LangChain.js v0.3中，如果你这么调用OpenAI API兼容模型（这里以豆包的API为例）是没有问题的
const model = new ChatOpenAI({
apiKey: process.env.OPENAI_API_KEY,
configuration: {
baseURL: process.env.OPENAI_BASE_URL,
},
model: "doubao-seed-1-6-flash-250828",
temperature: 0.7,
});
而如果在v1.0里，这么调用就会报错，错误如下
'Incorrect API key provided: ************************. You can find your API key at https://platform.openai.com/account/api-keys.'
你猜的没错，v1.0把这个model只给OpenAI用了，且拿这个参数当做认定是OpenAI的标准，而其他兼容模型必须用另一个参数modelName，有意思的是。
同样的这段代码，我还见过AI给出这样的写法的
const model = new ChatOpenAI({
apiKey: process.env.OPENAI_API_KEY,
baseURL: process.env.OPENAI_BASE_URL,
model: "doubao-seed-1-6-flash-250828",
temperature: 0.7,
});
而事实上LangChain.js之前应该是没有这样的语法，AI能训练出来这样的语法很可能来源于LangChain的Python版本有一个放在这个位置的叫base_url的参数。
Kubernetes JavaScript SDK的版本变更
道理上K8S也是很大的项目了，可能用K8S+JavaScript/TypeScript的人太少，导致了这个问题。
这个问题也出现在我使用WebStorm + Google Code Assist的过程中，我让AI帮我生成调用K8S资源的代码时，它总是给出类似这样的调用
await coreV1Api.readNamespacedPod("my-pod", "default");
而如果现场看readNamespacedPod的签名，发现它的签名第一个参数应该是params，里面包含了所有的这些name, namespace等等。应该是
await coreV1Api.readNamespacedPod(
{
name: "my-pod",
namespace: "default"
});
而这应该是这个SDK过去某个版本的整体变更，因为在现在最新的v1.4版本里，所有对资源的调用，基本都改成了这种新格式。
在埋了这种大坑之后，Vibe Coding的过程就是，聊点别的，让它给你改代码，它顺手就把文件里所有这种调用给改成老的格式了，你让它别改，告诉它应该是什么样，结果也记不住几轮。哎...
这么苦我该怎么办
今天写太久了，就明天接着写吧。
