这次打算挑战一次更快速的Vibe编程。

虽然应用的规模和难度不一样会影响开发时间，AI的“听话程度”也会造成很大的误差。但我还是打算试一下，并尽可能插进去一些新课题的研究，争取让需求难度和开发量差不太多。

本次依然是我们的老朋友Refly。

https://refly.com

——

首先还是整理需求。

这个应用将是一个给图片加画框和装饰的小应用，它的核心有点类似CSS中的border-image，以九宫格的形式将边框适合图片。但是border-image无法直接绘制到canvas上，所以导出图片有些麻烦。

在交互手段和界面上，它要比喵卡少一些数据处理和管理功能，但是要处理素材图片上传和展示，所以还是有点难度。

同时我打算让它关联到图片文件格式，使用户从网盘可以直接打开它。

而且，其实这个需求我在两周前开始开发喵卡之前就已经计划好了，当时一口气准备了四五个项目的计划，打算一个个的开发出来。

我依然提供了一个详细的需求文档，甚至画了一张界面示意图，但这些时间不打算计入开发时间里。

（上图在最终上线时有少量缩水，只能下次更新增加了。）

我把文档和图一起提交给AI,但依然先不让它开始编码：

请认真阅读和分析这个需求文档，将其重新整理成一份逻辑更通顺，表达更加明确的需求文档。不需要编码，我将在检查表述正确之后才要求编码。

这次开始时我打算用Gemini 2.5 Preview，它整理的需求文档质量看上去也还好。

开始计时 00h:00m

第一天的晚上19:30 正式编码

首先我让它生成了简化一些的目录结构，因为模块化会引起更多的问题。

它自动写的配置文件，看上去好像还行但我仍然不打算用它

打包文件我按照我的计划放在app文件夹中。

这一次我打算从前端开始开发，因为上次的CSS太屎山了。而且这个应用的主要功能还是在前端部分实现的。很快Gemini就给了我一个大约的界面预览。

反复调试了一会，由于border-image其实不是什么复杂的问题，所以初始的架构和边框部分大约在15分钟以内就实现了。

20:45 边框基本实现 00h:15m

然后我打算把生成图片的部分做完，这样来说核心的功能实现能跑通，应该就不会有太大的变数了。

在这里gemini给我推荐了一个第三方库html2canvas。

但是实际上，html2canvas并不支持border-image，复制出来的图片是没有边框的。

所以算是走了个弯路，但好在我测试的早，所以浪费的时间不多。

大约半小时后，边框可以成功复制到剪贴板了。

21:12 复制到剪贴板实现但存bug

但是图片的比例和图片的外缩有一些问题。

因为我打算制作通用于不规则卡通边框的功能，所以每个边宽度都会不同，边框“盖住”图片的程度也会不同。

于是要反复与AI确认和解释为什么要有不同的边宽，不同的大小，以及图片为什么要有外扩。

但是Gemini的理解能力还是很强的，只要你和它解释清楚逻辑，运算定位什么的就是它的强项了。比起自己要去开发每边的缩放比例之类可是简单多了。

21:20 边框bug修复但层次错误 总计2小时

折腾了2小时左右，最核心的功能基本跑通了，生成的图片基本达到了我的预期：

休息 总计时02h:00m

由于要哄娃睡觉，此处休息了几个小时

处理比例问题

之前的边框达到了预期，但显示比例还有问题，由于图片的宽高比和分辨率不同，边框要大小适合也要考虑一个比例，甚至窗口缩放的比例也同样要计算进去！

于是又反复折腾了一个小时，因为AI只是你让它做什么它就做什么，所以你的工作状态也会影响到它。这里我明显是有些累了，已经半夜两点多，好在比例的问题也解决了，所以第二天再继续。

核心功能完成 总计时 03h:10m

人算不如天算

第二天的Gemini情况比较糟糕，具体是当代码到了一定的体量，它就开始不断的省略，给我的代码很碎片，而且前后记忆不太一致。

给我的感觉是，好像AI也有“心流”一样，当心流被打算，可能很难恢复到之前的状态。

于是没办法，好在文件还不多，我把所有文件交给Claude，第二天的工作由claude接受完成。

由于从之前喵卡中得到了经验，聊天记忆太久了其实不是什么好事，于是我新开了一个聊天线程，放弃了和Gemini的纠结记录，只是把之前的项目文件重新导入给Claude让它去先理解：

请理解附件中的文件及代码内容，并在此基础上修改。 代码中已经实现了边框部分的功能，不要改动现有结构及功能。 现在我希望开始增加“装饰”的功能，

Claude在这一方面还不错，很快地理解了问题，并给我提供了它修改的代码部分。加上由于我在系统提示词中设置了严格的要求，所以原有Gemini开发的功能除了稍有走样外，基本得到了保留。

添加装饰的部分基本实现，边框也得到了保留。

但是现在的问题是，Claude并不理解之前纠结过的屏幕缩放问题，而且Dom元素和canvas元素不对齐的情况越来越明显了。

如果说Claude有些东西还不擅长，那么它擅长的是什么呢？要我说，它擅长的是“重构代码”，这里要加个黑脸🌚

即使是平时正常的小改动，Claude都会动不动把代码给重构了，优化一些只有它自己会注意到的优化问题。我不知道是不是跟人类程序员学的，但这个毛病其实很讨厌。

即使前面说的开发挺顺利，其实也已经完全重构过两次代码了！好在它的重构也比较快……

但是这一次，我打算主动让它完全重构代码。

由于之前对边框部分实现得也相当好，所以我打算趁它还有记忆，把整个应用的机制改为全canvas的模式，即每一步都直接在 canvas上绘制，这样就避免了无法所见即所得的问题。

没想到啊，这家伙对我说：这个方法很好，而且是主流解决方式，巴拉巴拉……

我就一头黑线，你咋不早说？

所以这里有一个心得，有一些优化的机制，如果你自己不知道或不提出来，AI不会建议你用更好的模式去实现，它只会死板的按你的需求去做。

至重构且进行一番调式完成，又过了两个多小时。

总计时间 05h:45m

在重构完成后重新实现装饰功能，以及调试恢复边框功能，又增加了25分钟。

但所幸的是这一次非常顺利，整个流程完美跑通了，实际生成的图片也完全符合要求。

终于，可以开始后端了。

这个应用的后端比较简单，因为主要是记录上传历史、保存以前生成的图片，以及素材管理。

我初期打算不用数据库，直接列举文件夹中的文件就好了。

所以，其实AI在一两个回合的问题里就给我写完了所有的代码！

总计约 07h:00m

可惜好景不长，在跨时两天总工作小时为7小时左右的时候，AI的记忆力终于又崩了。

之前提到的Claude爱重构代码的毛病又犯了，每次给我的解决方案都是完全不同的，会把之前的功能用新的方法写出来，然后还会漏掉功能或改掉以前正常的功能。

下图是我废弃的问答，在Refly中如果你觉得AI开始频繁出错答非所问，可以轻松地废弃掉这些线程，从较早之前的线程开始。

不过这一次重新开始了三四次支线后，结果还不理想，而且投入的时间和得到的有效回答相比，有效的效率越来越底，所以我打算还是放弃。

懂得放弃也是一种重要技术。

转手动

好在是，项目的基本功能已经差不多了，我想了下还是不跟他磨了。刚好我也需要了解一下这个机制学习一点写法，于是决定开始自己读代码修改。

由于所剩的修改大部分是CSS，所以其实还好。个别的JS和后端文件，就要一点点的查找整个功能链路去判断。

这个过程花了我大约5个小时。

虽然其实很久了，但我认为如果AI不崩，大概再有个一两个小时就能够搞定整个应用了。

这个Refly画板因为需求相对简单，而且没有包含后端的调试，所以比之前的喵卡画板要小得多,真实有效的回答其实只发生在绿色部分里。

如果是代码大神，编这样一个小应用估计用不了太久，可能总共三五个小时也就搞定，说不定更少。

但是我用的时间里也还包含初始素材的处理和素材配置文件的制作、界面的交互梳理和美化，这7+5个小时算是由需求出发，从零到一的完整全栈开发过程。

自我感觉还是不错的。