前段时间 dsV4 刚出的时候，我就接到了 Claude code 里试了试，跑了几个模型的对比和消融实验，发现性价比确实不错。
偶尔刷抖音会刷到一些 vibe coding 作品，便有了尝试的想法。
选番茄钟主要是因为我对这种 APP 的开发流程的了解是浅薄的，因此，我应该可以较好的作为一个没有相关多少专业基础的人，试试看使用 AI 工具实现作品需要多少精力和成本。
其次也是因为它不需要过于复杂的逻辑和功能的同时也能切实有点用，不至于做不出来或者做个纯玩具。
总结一下：
下面简单看看成果：
大多可以直接感受的内容基本很早就完成了，更多的时间是我打开-发现 bug -让AI修改再打开-继续发现 bug 的过程，包括但不限于：
这些都是比较明显的，还有很多细碎的内容。
这部分很耗费心力的一点是除去最基础的调调窗口尺寸（以我的水平而言）外，任何问题都需要再抛给 AI。
有时它给出了看起来很专业的解决方案但实施后并没有解决问题。
有时我一眼就知道这一定是改 1 行代码就能解决的问题，但是我因为不了解仍然做不到去手动更改。
因此，如果想要在这部分改善体验，要么就是换更强大的 AI ，要么就是下一点内容。
这点最关键的地方在于它会直接影响你如何描述问题。
因为用很白的话去描述问题一定是会影响 AI 对问题的定位的，尤其是涉及到 UI 这种没有实际报错但是确实存在问题的方面。
在这个项目里最关键体现就是上面的脏区问题，我最初的描述大致是这样的：
当前项目的 UI 设计中出现问题，窗口的四角存在灰色区域，修复它，让主界面的 UI 色调统一。
AI 进行了一些很专业的改动，但测试没有解决问题，我又这么说：
问题仍然存在，现在的情况是整个主界面的四角有圆角，存在灰色区域，让整个窗口出现了“双重边框”的视觉效果，排查问题，让整个主界面只有一个外边框。
继续改，依旧没有解决问题，但是我从它的回复里知道了，它叫这块为“脏区”。
到这我已经发现了如果我不能给出更精确的提示词，问题很难解决，于是我把问题给 GPT，让它给我生成了一版提示词：
关键来了，第二天（不排除是清理上下文的原因），我把这段粘贴给它，仍然没有解决问题，但是在回复里我发现它已经定位到问题了，它称最外层的窗口叫物理窗口，而内部窗口是 CSS 边框。
所以我最后解决问题的提示词是这样的：
去除主界面中包裹内部组件的 CSS 边框的圆角设计，让其和物理窗口完全贴合。
至此这个问题才解决，很明显的一点就是如果我知道了这两个专业称呼，这个问题很快就能解决。
这部分最大的感觉是：没有详细的定位就直接描述客观现象让 AI 自己思考，抽象的指令会让 AI 跑偏，反之就会提高效率。
这点其实是因为我发现 /plan 十分好用，它会先根据你的问题规划一个完整方案，然后让你选择直接执行还是让它继续改。
而实测下来，虽然会多用一些 token ，但带来的效率提升是显而易见的。
感觉这其实也是一种解耦的逻辑：不让 AI 同时思考和执行。
这和那条著名的原则：一次只改一个模块，其实是一个道理。
抛开这个项目，其实在我熟悉的 DL 部分感觉到的就是：AI 是一个效率极高的执行者。
我把各种参数、层级、处理方式、损失逻辑全部规定好，它可以完美实现我的设计，这其实是我在代替它思考。
而在这个项目中，我没有提前设计好那么多边界和约束，所以在它自己的规划中就出现了诸多 bug。
这点的想法是：要么代替 AI 思考让它执行，要么审查 AI 的思考后执行，不要让 AI 同时思考和执行。
这点是老生常谈了，一个问题一直解决不了就试试 /compact 或者 /clear，一般都会有奇效，不再多说了。
最大的感触是：只要开始构建就会有所收获。
因此，个人认为 vibe coding 的重点其实是在于过程，跑模型对我来说不算 vibe coding ，它只是在帮我干活。这种在不熟悉的细分领域实现一个想法更符合我对它的认知。
很多东西动手一搜，会搜出来特别多的优秀、成熟的作品，但这是幸存者偏差，不是所有的作品都是完美的，而是更好的才能被搜索到。
源码和安装包都传到了 github 上，有兴趣可以帮忙找找 bug。Release Tomato v0.1.0 · Goblinsscholar/Tomato
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。