第一次用 Vibe Coding 开发 App，我做了一个叫「晃见」的产品，功能很简单：求签掷币。
然而，它最终没能通过审核。苹果给出的原因是同质化产品过多（4.3 Repetitive App）。
是那一刻我才真正意识到：Vibe Coding 让开发变简单了，但把产品做好并没有变简单。
作为一名非计算机专业的小白，这是我第一次完整开发 App 的复盘。我想聊聊 UI 设计里踩过的坑，以及我对 Vibe Coding 的真实体悟。
整个过程大致分为四个阶段
我先把主流程跑通：实现摇签、掷币、结果展示，生成分享图的功能。
这一部分几乎完全依赖 Claude Code 多轮对话迭代完成，功能实现速度很快。
这是 Vibe Coding 的第一个优势：把功能从“不会”变成“可以做出来”。
名称「晃见·摇签掷币」是与Gemini和Deepseek多轮讨论后确定的。
过程非常折磨。因为我一直在纠结哪个更吸引用户、更增加曝光率。
（不过现在看来，这似乎并不重要？毕竟它连上架的机会都没有。。。。。。）
这是曾经的一些选项，你们决定哪个更好？
「逻辑神谕」、「掷得」、「赛博求签」、「签引力」
当功能跑通后，我发现：界面太丑了。
于是开始重构视觉：中式签筒、铜钱、字体、音效。
UI 统一风格的过程，比写功能难太多。
开发这款app，我几乎超过90%的时候都耗在UI 设计。
为了生成签筒素材，我尝试了三个 AI 设计工具，满意度排序是：
Lovart > Stitch > Figma
维度 | Lovart | Stitch | Figma |
|---|---|---|---|
视觉表现 | 质感最好，光影和材质表现非常自然 | 结构清晰，但细节较少 | 偏扁平化，效果平庸 |
| 导出内容 | 图片 | 图片+网页代码 | 图片+网页代码 |
复现难度 | 难，代码很难还原复杂的木纹纹理、光影渐变和材质细节 | 较难，签筒的网页设计在 App 中难以直接复用，实现过程中细节被明显简化。 | 易，生成的网页代码复现性高 |
| 效果图 |  |  |  |
我尝试将Stitch生成的网页代码喂给Claude Code和Codex，虽然能复现简单的铜钱页面，但签筒的设计却相差甚远。
即使我让 Gemini 充当“视觉翻译官”，去对比参考图和生成图的差异，并翻译成极度详细的编程 Prompt 给 Claude Code重绘，效果依然不理想。
总结代码复现失败的核心原因：
AI 生成的是“视觉图像”：它是连续的、充满复杂光影的位图。
代码渲染的是“结构布局”：它是离散的、组件化的离散逻辑。
最终我的做法是：
Lovart 生成图片 → Claude Code抠图 → 当素材使用
一开始，我只是把「名字 + 功能描述」直接交给 AI 生成 Logo。
生成的结果看起来很禅意、很东方，但和 App 内页的红色主色调明显不协调。
后来我又尝试在提示词中增加颜色限制，但生成的 Logo 往往元素过多，画面显得拥挤。
最后真正的突破来自：去小红书搜索大量相关的设计案例。
在看了不少案例后，我逐渐有了方向——将 Logo 设计成印章形式。这种形式不仅符合整体的中式风格，也方便在后续生成的分享图中自然融入。
确定方向后，再给 AI 提供更具体的设计指令，很快就生成了符合预期的方案。
Vibe Coding 确实降低了开发门槛，但与此同时，判断力的门槛反而提高了。
就在前几天，我刷到通义实验室发布了一个求签网页的制作教程，可以通过手势识别实现隔空抽签。这个交互功能其实早就被应用于类似「抽取塔罗牌」、「生成照片圣诞树」的场景。
然而，我自己的设计思路却始终停留在传统 App 的交互框架里，没有真正利用好 AI 带来的这些新奇可能。
vibe Coding 替代的是“写代码的体力劳动”，但它不能代替的是
产品判断： 用户真的需要这个吗？
审美判断： 这好看吗？风格统一吗？
差异化判断： 我和别人哪里不一样？
跟少数派的众多大佬比起来，我这个产品还很稚嫩。但能从 0 到 1 真正动手，做出一个完整的成品，也是好的。
现在的时代，已经没有“不会编程就不能做产品”的借口了，但同时也没有“工具强就一定成功”的捷径。
Vibe Coding 很 Vibe。
只是，真正不 Vibe 的，是做产品本身。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。