来分享一个自己刚刚经历的 Vibe Coding 例子。我的几个项目,都需要用到把本地一份 XML 同步到远端 GitHub 仓库的功能。
项目部署后,可以正常工作,直到虚拟机有次意外重启,项目再次初始化时,需要从 GitHub 拉取最新版本的 XML 文件,结果报错。
Vibe 了半天,Gemini 2.5 Pro 发现这是因为 GitHub 对于大小超过 1MB 的文件,需要设置 download_url 等方式,才可正常拉取。
本着懒人原则,我没有对其它暂时没出问题的同类型项目进行修复,直到昨天。
这次我再次让 Gemini 2.5 Pro 修改,roll 了几次,都没能正确识别出「 1 MB 」的问题,给我瞎改。最后我忍不住了,把之前他教我的,再反馈给他,就成了。
细想,如果第一次修复时,没有 roll 到正确的解决方案,我可能至今不能作出简洁有效的修复,更无法反馈给始终没有 roll 到正确方案的 2.5 Pro.
这个例子,可能也有其他替代方案,但比较低效和冗余。我不确定这种情况在 vibe coding 里面的占比大不大。也许明明模型有一定概率可以 roll 到更好的方案,但几率太低,所以就变成屎山。而 vibe coding 的用户未必会不断地 roll 同样的问题,来观察模型输出方案之间的差别。
我愿称之为:Vibe Coding 下的 Gacha Coding 时代。
![]() |
1
greygoo 9 天前
|
![]() |
2
greygoo 9 天前
@greygoo 意思也就是该查还是要查,该做的判断还是要做,AI 现在的定位非常清楚,就是写代码,工具而已,工具你能指望他解决你的问题吗,他顶多给你一些信息,还是要你自己去解决.而 gemini 在这点上面就非常差劲喜欢自己凭空捏造,不是一个忠实的助手,所以才说 gemini 就是赌博
|
3
jiejia 9 天前
抽奖编程
|
4
kneo 8 天前 via Android
所有工具制造出来都是解决问题的。
说什么“工具而已”然后巴拉巴拉的,基本上就等于在自曝“我也不知道为什么不行还是别多想了”。 |