用 AI 写代码很爽,直到我开始上线自己的工具
vibe coding 不是不会代码的人开挂,而是不会代码的人提前进入工程现场。

这篇文章写得有点尴尬。
因为我一边在写 vibe coding 的复盘,一边 Windows 那边的登录授权 bug 还没修完。
问题说大不大,说小也不小。
授权界面无法跳转到官网登录。
在 Mac 上看着好像还行,到了 Windows 就不行。
当时我的补救方式也很笨:开两个 Codex,一个在 Mac,一个在 Windows,各自在各自的环境里修。
我知道这肯定不是最优解。
应该有更好的跨平台开发、测试和排查方式。
但对当时的我来说,能补救的也就这个了。
这可能就是我现在对 vibe coding 最真实的感受。
不是坐在那里一句话让 AI 给我变出一个产品。
更像是我被提前丢进了工程现场,旁边站着几个 AI 帮手,但地上的线还是乱的,火还是要救,锅也还是我的。

01
先说爽,是真的爽
过去这一个月,我一直在用 vibe coding 做一个自己的工具箱,叫 ssaitool。
它最开始不是一个技术练手项目。
说白了,就是我想把自己做电商时经常遇到的那些麻烦事,尽量做成工具。
比如 ROI 计算器加 AI 分析,让运营更好地控制数据。
比如生成电商套图,主图、详情图、白底图、SKU 图。
比如定制品生成图。
比如带货视频。
这些东西都不玄乎,也不是什么高大上的 AI 概念。
它们就是电商从业者每天都会碰到的活。
其中我最有感触的是电商套图生成。
用户上传一张产品图,输入一个产品名,AI 根据图片和名称自动补全提示词,然后生成一套电商图。
对于大公司来说,这可能只是提效。
但对于很多夫妻店、小团队来说,这件事意义不一样。
他们本来就负担不起一个专业美工。现在有了这个工具,至少等于有了一个能先顶上的 AI 美工。
两分钟出一套图,成本几块钱。
先不说它能不能完全替代人,也不说效果是不是每次都完美。至少对很多小团队来说,它给了一个可以开始试的机会。
这也是我做这个工具最有动力的地方。
我不是为了做一个“看起来很 AI”的东西。
我是想把自己经营里那些重复、麻烦、但又不得不做的事情,慢慢变成一个开箱即用的工具箱。

所以前期真的很上头。
想到一个功能,就跟 AI 描述一下。
它写代码,我试运行。
有问题,再让它修。
修完继续加。
看着一个个功能从没有到能跑出来,那种感觉很容易让人产生错觉:
好像我真的会做软件了。
而且我自己用得很爽。
外人用起来怎么样,我不知道。
但那一刻我很确定:这个东西越来越接近我想要的样子。
这就够了。
这不就是我当初做工具的初衷吗?
先让自己用爽。至于别人,先放一边。
02
问题也是从“能跑”开始的
后来我慢慢发现,“能跑”这件事,很容易骗自己。
本地能跑,不代表上线能跑。
Mac 上能跑,不代表 Windows 上能跑。
你自己电脑上能跑,也不代表换一个环境还能跑。
一开始我没有规划好。
我用 Mac 开发,Windows 适配没有提前考虑。
等到各种 bug 冒出来的时候,我根本判断不了它到底是哪一层出了问题。
是前端?
是后端?
是环境变量?
是依赖?
是构建?
是接口?
还是我一开始架构就没设计好?
我不知道。
很多时候,我只能听模型的判断。
它说这里要改,我说,好的,执行。
它说下一步检查这个,我说,继续,下一步。
听起来好像很顺。
但真实感受不是顺,是没底。
因为我并不知道它判断得对不对。
我只是被推着往前走。
最典型的就是登录授权。
原本我想做成类似 Codex 那种体验:点击跳转官网授权,然后工具箱完成登录。
这个需求听起来不复杂吧?
甚至有点基础。
但 Windows 那边,授权界面就是无法跳转到官网登录。
更真实一点说,我写这篇文章的时候,这个 bug 其实还在修。
这就很讽刺。
我一边在写 vibe coding 的复盘,一边那个工程现场还没收工。

我修这里,那边又出问题。
我再让 AI 修,它又给我改另一块。
有时候表面问题没了,但我心里更没底。
因为我不知道它到底是解决了问题,还是只是把问题挪到了另一个地方。
这就是最难受的地方。
不是功能做不出来。
功能很多时候是能做出来的。
难的是,我知其然,不知其所以然。
03
不是 AI 不行,是我没把问题讲清楚
刚开始遇到问题,我很容易怪 AI。
它怎么又改错了?
它怎么修 A 坏 B?
它怎么上下文又忘了?
但越往后,我越发现,这里面当然有 AI 的问题,可也有很大一部分,是我的问题。
我没描述清楚。
我没说清楚边界。
我没告诉它哪些地方不能动,哪些地方只是排查,哪些地方才是要修改的目标。
有时候我自己都没想明白,到底是要修 bug,还是要重构,还是要先定位问题。
那 AI 怎么可能稳定给我一个好结果?
所以我现在经常会在后面加一句:
先理解,反馈,等我确认后执行。
这句话对我来说挺重要的。
它不是一个所谓的提示词技巧。
它更像是我开始重新拿回一点控制权。
以前是我把问题丢给 AI,然后它直接动手,我跟着它跑。
现在我会先让它复述理解,告诉我它准备怎么查,可能有哪些原因,准备改哪里,会影响什么。
等我确认后,再让它执行。
这一步看起来慢了,其实是变稳了。
因为 vibe coding 最危险的地方,不是 AI 写错一行代码。
最危险的是,你在自己也没理解的情况下,不断允许它继续往前改。
改着改着,项目就变成了屎山。
而且是你自己亲手点头同意堆起来的屎山。
这句话有点扎心,但很真实。
04
我终于理解老程序员为什么强
这一个月最大的收获,不是我做出了多少功能。
而是我突然理解了,老牌程序员为什么强。
以前我理解的程序员强,可能就是代码写得快,懂技术,能解决 bug。
现在我觉得不止这些。
真正强的是,他们知道一个项目从一开始就不能乱来。
他们会先想架构。
会想流程。
会想模块之间怎么拆。
会想日志怎么打,错误怎么处理,出了问题怎么定位。
会想本地环境和线上环境有什么差异。
会想 Mac、Windows、服务器、浏览器、依赖版本之间会不会互相打架。
他们不是等火烧起来再救。
他们是在一开始搭房子的时候,就知道哪里不能省,哪里以后一定会塌。
这就是我之前缺的东西。
我用 vibe coding,确实可以把功能做出来。
但功能越堆越多,我越能感受到另一件事:
一个工具箱不是一堆功能的集合。
它背后必须有结构。
如果没有结构,今天加 ROI,明天加生图,后天加视频,再后天加登录授权。
每一个功能单独看,好像都没问题。
但它们放在一起,就会互相影响,互相拖累。
最后外表看似完美,内部一片混乱。
更麻烦的是,当内部已经混乱了,AI 也不一定救得回来。
因为 AI 修 bug 也需要上下文,需要边界,需要清晰的问题描述。
你给它的是一团乱麻,它就只能在乱麻里面继续补洞。

05
vibe coding 不是让人不用学编程
我现在对 vibe coding 的理解变了。
一开始我也会觉得,它是不是让不会代码的人开挂了?
好像只要会描述需求,就能做软件。
现在我觉得,这句话只说对了一半。
vibe coding 的确让普通人更容易进场。
以前你想做一个工具,可能第一步就被代码门槛挡住了。
现在不一样。
你可以先把需求说出来,让 AI 帮你写,让它先跑起来。
这件事非常重要。
因为很多业务人、运营人、内容创作者,脑子里其实有很多真实需求,只是以前没能力把它变成工具。
AI 把这个门打开了。
但门打开之后,你进去的不是游乐园。
你进去的是工程现场。
里面有需求拆解,有架构设计,有平台兼容,有环境配置,有登录授权,有日志,有测试,有上线,有回滚。
还有修 A 坏 B。
还有本地能跑,上线就炸。
这些东西不会因为你用了 AI 就消失。
它们只是更早出现在你面前。
所以我现在越来越觉得:
vibe coding 不是不会代码的人开挂,而是不会代码的人提前进入工程现场。
这句话听起来没那么鸡血。
但它更接近我的真实感受。
它确实让你快了。
也确实让你爽了。
但它同时会把你原来缺的东西全部暴露出来。
你不会描述问题,它会暴露。
你不会拆边界,它会暴露。
你没有架构意识,它会暴露。
你不懂日志和错误处理,它会暴露。
你只会说“好的,执行,下一步”,它也会暴露。
暴露出来不一定是坏事。
至少你终于知道自己缺什么了。
06
我现在才算刚刚进场
如果现在让我回到 ssaitool 开发的第一天,我肯定不会像之前那样,想到什么就加什么。
我会先规划整体框架。
先设计流程。
先想清楚哪些是核心能力,哪些是后面再加的模块。
我也会把主 agent 和子 agent 的任务分清楚,让它们专司其职。
不是所有问题都丢给一个模型一把梭。
我会更重视日志和错误处理。
因为没有日志,你连问题在哪里都不知道。
我也会补基础开发知识,尤其是架构层面的东西。
不是为了把自己包装成职业程序员。
而是为了在和 AI 协作的时候,至少知道自己在做什么。
这可能就是我这一个月最大的变化。
我还是觉得 vibe coding 很爽。
甚至比以前更觉得它有价值。
但我不再把“爽”误认为“简单”。
也不再把“能跑”误认为“完成”。
工具先让自己用爽,这没问题。
这本来就是我做工具的初衷。
可如果我想让它走得更远,就得承认另一件事:
工程不会因为 AI 存在就变简单。
只是普通人终于有机会,提前走进那个现场了。
而我现在,刚刚进场。

夜雨聆风