第一款我完全认可的 Vibe Coding APP 开发见闻
纯银uncle约 9 分钟这个标题是不是有点标题党？
不是的，你知道我从来都不是标题党。
我一个朋友，十年经验的产品经理，三年前个人做了一款极简风格的记账 APP，交互创新的卡片式主题记账，适合懒人（也就是他自己）单独为某些重要的事件记账，比如旅行，比如装修，比如育儿。
这款 APP 发布到 App Store，没啥反响但也没啥关系，自娱自乐之作，自己能用就行。
今年，朋友忽然来了兴致想重构这款极简记账 APP，反复折腾了几个月，写代码写到崩溃。因为他只懂一点点代码，其实是三年前为了做这款 APP 自学一丢丢 Swift，甚至不能称之为野路子程序员，而是野生入门级开发者，自我评价代码水平 50 分。
与此同时，他的强项一是产品 sense 很好，二是交互极强，是我认识的交互最强的产品经理没有之一。
在这个背景下，Gemini 3 发布后，朋友用了不到一周时间，为自己定制了一套 Vibe Coding 的方法，目前已经完成了代码和交互重构，正在继续做几个新功能。
我因为跟他很熟，对这款极简记账 APP 也比较了解（之前还提供了一些重构建议），如果最终能顺利发布，这会是第一款我完全认可的 Vibe Coding APP。“完全认可” 的意思是，产品品质和用户价值是我认可的，而非那些 AI 噱头很足，但没有长期留存的 APP。
没错，我的评价就有这么高。
朋友授权我公开他是怎么 Vibe Coding 的全过程，工具是 Cursor。
第一步，围绕着这款产品的定位，背景，目标，和 ChatGPT&Gemini 进行大量的对话。早期用 ChatGPT 对话，Gemini 3 出来以后以 Gemini 为主。对话的意义并不是请大模型给自己建议，给不出来几个有价值的建议，而是用自然语言的随意表达，让大模型完全理解这款产品想做什么，然后请大模型复述一遍。相当于让 Gemini 作为翻译官，把朋友的口语转译为 AI 容易理解的语言。中译 AI。
第二步，在 Cursor 里上传四类文件：
和 ChatGPT&Gemini 对话的长截图，人工截取 AI 对产品准确了解的部分，作为任务背景
他自己画的高保真原型截图
从他朋友那里拷贝来的，对 Cursor 工作流程进行标准化约束的一些文档（# iOS 项目开发规范指南 # 工作流程规规范 # iOS 运行和测试规范，诸如此类），有意思的是，这些文件也是由资深程序员和 AI 大量对话后，AI 根据对话内容生成的，相当于中译 AI，这样 AI 理解文档的效率最高
这款 APP 的 1.0 烂代码
接着 Cursor 就吭哧吭哧地跑起来了，燃烧算力，根据他上传的文件，将项目拆解为一系列的 todo。由于这里并没有 PRD，只有背景和原型（连原型注释都没有，朋友太懒了），Cursor 根据自己的理解自动补全了一部分缺失的细节，对另一些把不准的细节向朋友提问，几个来回就能把细节敲定下来。
这样跑了一段时间之后，Cursor step by step，在所有 todo 上确定了所有的关键细节，直接拿出了一款可运行的 APP……
接着就是大家熟悉的调试环节：发现问题 - 提出问题 - AI 解决问题 - 没有解决好问题 - PUA AI 更好地解决问题（或自己动手改代码）。
如此循环了好几天，嘿，代码和交互重构竟然完成了！
在这个过程中——
没有 UI 稿！
而是 Cursor 根据高保真原型直出 UI，在调试环节对 UI 提意见修改。
没有 PRD！
产品细节是在大量对话中聊出来的，有些是 Cursor 提问，朋友回答；有些是朋友叱令 Cursor 反复修改。根据一开始约束的开发规范，Cursor 会把最终修改写入由 AI 维护的需求文档。我看过这个 AI 面向 AI 写作的文档，对人类来说完全不可读，硬要读的话很难受，但大致能看懂描述是准确的（不确定是否完整）。因为是一人维护的独立产品，似乎也没有 PRD 的必要，忘了啥细节临时问 Cursor 就好。
从到目前为止的进度来看，我和他都相信，Cursor 足够完成这次重构并发布全新的 APP。和老 APP 相比，除了定位一致以外，所有的界面和功能推翻重做，代码重写，宛如新生。
接下来是几个关键问题的 Q&A。
Q：为什么这会是第一款我完全认可的 Vibe Coding APP？
A：因为别的 Vibe Coding 产品，在我看来或者品质很差，或者用户价值很差，可用性达不到我的标准。而朋友这款极简记账 APP，受益于他的市场洞察与交互品味，一方面可用性较好，哪怕小众，也能为目标受众提供足够的用户价值；另一方面复杂度还好，功能比小猫补光灯复杂太多了，谈得上一款正式的轻量级产品。
这里边的重点，其实并不是 Vibe Coding，而是朋友作为十年经验，优秀的产品经理，他有能力设计一款我认可的独立产品。AI 只是他补足自己编程短板的效率工具。
Q： Vibe Coding 在他的研发流程里具体起到了怎样的价值？
A：我们细分为三个部分来讨论：功能、UI、交互。
功能实现是 Cursor 的长板，朋友这款产品前后端并不复杂，即便是 Vibe Coding 也能实现。
UI 对 AI 来说是有点苦手的，AI 优先输出一个语料之内的模板，如果需求和模板偏离度不大就还好，或者如果需求模糊也还好，但如果需求具体，并且和模板偏离度很大，这时用自然语言指导 AI 修改很容易鬼打墙。这一点对朋友来说并不是问题，他直接给了高保真原型，AI 照着原型生成视觉稿，并通过对任务背景的了解进行美化，交付已经很接近成品了。和需求的偏离度越小，修改就越容易。
交互分两部分，一是基础交互，二是特殊动效。朋友是交互高手，基础交互（有风格，有创新）自己就搞定了，但指定的动效 Cursor 做不出来。于是朋友把动效先降级，然后去跟 Gemini 聊，一直聊到 Gemini 能生成降级后的动效，再把代码拿过来让 Cursor 好好学习。否则，整个创新的交互方案对 Cursor 来说在语料里全无先例，凭空生成则必然鬼打墙。
Q：这种 Vibe Coding 的方法能扛得住怎样的产品复杂度？
A：朋友对我的心生一计相当了解，他丝毫不负责任地毛估，可以实现三倍产品复杂度的心生一计。
从这部分问答里，我们能看到一些 Vibe Coding 的关键约束。
关键约束一：AI 并不能帮你变得更聪明，但可以帮聪明人更高效率地完成任务。Vibe Coding 至今做不出几款我认可的产品，不是因为 AI 能力不足，是用 Vibe Coding 的人缺乏做出这个水准产品的市场洞察和产品能力。
关键约束二：如果需求模糊（越模糊越好），AI 在海量语料之内复制和微调模板是可以满足人类需求的。需求越具体，Prompt 越长，这时 AI 复制和微调模板的不确定性就越高，修改成本也越高。提高确定性的方法不是暴力 PUA AI，而是你自己输出一个具体的方案让 AI 去实现。比如我朋友自己搞定了高保真交互，再指挥 Cursor 去写 AI 擅长而他不擅长的代码。
关键约束三：朋友的实战证明了，这种没有 UI 稿，没有 PRD，细节靠 “聊” 的野路子 Vibe Coding 也是可行的。重点是，朋友作为资深产品经理，他能确定每一个需求细节——无论是事先准备好 PRD，还是 Cursor 向他提问，还是他叱令 Cursor 修改，这些需求细节在他脑子里是明明白白的，洞若观火。AI 能帮助你实现需求，甚至是填充一些需求细节，但确定 “做什么不做什么” 还得是你自己的智力活动。
所以 Vibe Coding 能力的提升，对于 APP UGC 生态并没有很大帮助。技术能力并不稀缺，专家的经验依然稀缺。就这个个案而言，独特的市场洞察是朋友的，支撑这份洞察的创新交互方案也是朋友的，AI 完全没可能代劳。如果提一些模糊需求，希望 AI 做出来自己想要的（以前没有过的）好东西，我觉得跟找关二爷许愿差不多……
这就像我跟朋友聊到生成 UI——你可以手绘原型让 AI 生成 UI，你也可以复制别人家的界面让 AI 生成 UI，唯独不能模模糊糊地说几句话，让 AI 生成你想要的独特的好 UI。这时 AI 傻了，哥们到底想要啥啊？人类设计师能更精确地理解和扩展你的需求，AI 只能抽卡，抽着抽着又鬼打墙了……
划重点：你越了解自己想要的东西，AI 才能给你更好的交付。决定性因素是需求的质量，而不是 AI 的能力或者运用 AI 的方法，而需求的质量取决于你的专业程度。否则，Vibe Coding 满足无限多的 60-70 分平庸需求，和 AIGC 生成无限多的八股文，没有本质区别。80 分代码和 50 分需求，木桶的短板是那个 50 分需求。反过来看，50 分烂代码和 80 分需求，只要产品能运行，80 分需求的长板就能创造更大的价值。
摄影圈子有句老话，什么昂贵镜头，都不如镜头后面的那个（你的）头。这句话复用在这里也是合理的。很多人感慨 AI 把自己不熟悉的领域提高到了 60-70 分输出，但并不稀缺的 60-70 分是没有商业价值的，什么高效率工具都不如你的高质量需求更重要。工具只能提高实现需求的效率，如果需求本身平庸，这件事只能说是 “自己体感上的正反馈很多”，结果依然平平无奇。想想看文生八股文万舸争流的互联网现状……
最后，如果我的朋友已经实践到这一步了，我可以按他的方法，或者让他手把手地教我，做出我想要的独立产品吗？
不可以。
so sad.
因为这套方法的前提是基本的代码能力，才能读懂 AI 给你的代码，反复调试，一直调试到跑通为止。而我在代码方面宛如弱智，就像我同时是一个英文盲一样，至今单词量很可能不到 300 个（高考英语不及格，大学英语三级没考过）。我身上有一些极端的长板与短板，这辈子就这样吧。
再说我的独立产品已经组队成功了，产品也做出来了，困扰我的是增长如何触达精准用户。如果我能突破这个致命瓶颈，极端点说，我出方案，出钱，找个粗通代码的朋友帮我 Vibe Coding 都行。所以重复一次，工具永远都不是关键约束。当你能搞明白什么是关键约束时，这才是你成为专家的第一步。
犬校一位产品经理对此发表意见：
Vibe Coding 最大的问题是维护，就像你举的例子里名为迭代，实为重做。例如我发现 AI 实现的某个页面效果很好，我很难在不修改其他页面的情况下只改这个页面，尤其是这个页面和别的页面联动的情况。这款记账工具，我猜测服务端逻辑和数据库没有特别多，Vibe Coding 特别适合重客户端或本地逻辑的轻产品。我的感受是，一旦涉及后端数据，AI 常常因为上下文限制，最后甚至连数据库字段都记混了……
我把这条回复给朋友看了，他觉得说得也对。
AI 目前还无法很好地处理代码结构，导致代码耦合太多，。好的程序员会自己设计结构，面向 AI 拆分成单元任务下发，实现解耦的效果。而 Vibe Coding 恰恰意味着没这个技术水平，只能跟随 Vibe 来指挥 AI 编程。
而我这朋友的处理方法是……耦合就耦合嘛，要改就一起改嘛。因为他的产品在页面结构上是很简单的，后端尤其简单，所以 “要改一起改” 也不是很费事，这里浪费的成本，远远低于他古法手搓代码的成本。
所以，Vibe Coding 的确无法应对更复杂的产品，更复杂的产品需要更好的技术能力 AI Coding。
Vibe Coding 更适合重客户端，轻后端，页面结构简单的产品，但不是小猫补光灯那种小玩具。小猫补光灯对职业产品经理来说没什么启发，因为又简单容易实现，又有一定用户量级，挖掘到这类市场需求的概率低到不可思议。
点击【阅读原文】，可见犬校最近一年的好帖索引。