我用 AI 做了一个订阅 App,现实比别人说的难多了

靠感觉指挥 AI 写代码这事，热度是真的。但真正做起来，过程会很乱。

摘要

靠感觉指挥 AI 写代码，确实可以做出一个 App，但绝不是一个周末就能搞定。

Ethan Garr 用 AI 做订阅 App 的经历，把这波 AI 热潮经常轻描淡写带过的细节都摆了出来：看起来像产品的视觉原型，和真的能跑的产品之间差很远；很多技术复杂度会突然冒出来；App Store 审核和订阅变现系统，也最好一开始就认真处理。

现在这股 AI 热潮很猛，感觉好像所有人都能周末做个 App，然后每个月赚 10 万美元。这当然让人兴奋，但也很容易误导人。

“你的 App，OnTimer，Never Be Late，已经可以分发了。”

当我终于看到 Apple 审核团队发来这句话时，我知道两件事是真的。

第一，你确实可以用 AI 做出自己的移动 App。

第二，你大概率没法一个周末做完。我花了四个月。

我常开玩笑说，现在连傻子都能做 App 了。别问我为什么知道。但我们确实活在一个很神奇的时刻。好点子从来不只属于某一类人。任何背景、任何教育经历、任何技术水平的人，都可能冒出一个价值百万美元的想法。

真正的限制，一直是这些人有没有足够的技术能力，把想法变成现实。现在，大家都看到了，AI 正在抹掉这道限制。

用 AI 做第一个 App，现实到底是什么样

我不会写代码。

我在 2025 年 11 月开始做这个 App。那时候我只是想看看，靠感觉指挥 AI 写代码到底能做到什么程度。但每次我让某个功能跑起来，或者咬牙修掉一个 bug，我都更想把它做完。

看到 App 出现在 App Store 里，还拿到第一批客户，这件事特别有成就感。只是它也比我想象中难得多。

所以，没错，你可以用 AI 做出一个真正的订阅 App。它是不是像大家说的那么简单？答案要复杂一点。但我会把我学到的东西讲出来，希望你也能照着做，也许还能少踩几个我踩过的坑。

第一课：别等完美点子，先做点东西

如果你收过同事那种带着火气的短信：“我们都在 Zoom 里了，你来不来？”那你就能理解 OnTimer 的起点。

每天早上，我都会看一遍日历，然后在每个会议前两分钟手动设闹钟。我讨厌迟到，而普通日历通知太容易被我忽略。我需要一个更强硬一点的提醒。要不然，我可能会继续写邮件，或者盯着某张图表发呆。

所以，当我想看看这种 AI 写代码方式能做到什么程度时，我没有去找那个完美点子。我只是把自己的一个习惯自动化了。

我不知道它能不能赚钱，也不知道有多少人有同样的问题。我只知道，我不想再等了。

在一个“什么都能做”的世界里，如果你非要先找到一个完美、差异化十足的点子，很容易把自己卡住，最后什么都没做。

所以，当我在 LinkedIn 上看到 Supervibes 的帖子，说它是“给原生 App 用的 AI 写代码工具”，我就开始动手了。

第二课：画面不是产品，AI 经常分不清

一开始，我的提示词几分钟就把脑子里的 OnTimer 变成了屏幕上的界面，我真的被震住了。看到自己的 App 一下子“活过来”，那种感觉很容易让人上头。

但我很快就学到一件事：你看到的东西，和真正能工作的东西，是两回事。这几乎贯穿了整个开发过程。

我知道 OAuth 需要真正配置，这一点我有心理准备。但我没想到的是，AI 会把一些真正影响用户体验的东西也做成假的。

Supervibes 一开始用假日历数据写出了这个 App。作为起点，这还可以接受。但它还“伪造”了一些后来会反咬我的东西。首页上有一个同步图标，旁边写着“每 15 分钟自动同步”。结果后来我才发现，这根本不是功能，也不是设置，只是界面装饰。而我当时完全没意识到应该质疑它。

我花了大约一周，才把 OAuth 和最初的日历连接跑通。当我用连着 Xcode 的测试手机，第一次让 OnTimer 为一个会议响起闹钟时，我才第一次觉得，这东西可能真的能成。

但还记得我前面说自己是傻子吗？这里就又说回来了。

核心功能“看起来能用”之后，我开始用晚上和周末去啃 App Store 那套有点绕的流程，最后终于把第一个版本发到了 TestFlight。

这一下让我大开眼界，而且不是好事。全屏闹钟在我的测试手机上很好用，但那只是 App 在前台时。到了后台，它根本不工作。自动同步又是假的，所以 OnTimer 所谓“永不迟到”的承诺，基本就是空的。

后来我从 Supervibes 换到了 Claude Code，但这其实是各种 AI 工具都会遇到的坑。它们画出来的“画面”很真实，但画面不是产品。哪些东西是硬编码的，哪些东西是真的做出来的，这种不一致让我几乎没法判断，一个东西到底真的能用，还是只是看起来很像。

如果能重来，我会在写第一个提示词之前，先拿白板花几个小时问自己三个问题。

每个阶段的成功标准是什么？

什么才算真的能用？

作为用户，我对这个 App 有什么期待？

第三课：你以为简单的 App，可能比想象中复杂很多

很早就把第一个版本发到 TestFlight，后来证明是个非常好的决定。反馈来得又快又疼。

接入 OAuth 反而是容易的部分。难的是做一个能在后台稳定工作的持续通知系统。难的是手机静音时，仍然兑现“永不迟到”的承诺。难的是可靠同步多个日历。每当我解决一个问题，新的问题就会冒出来。

这某种程度上就是 AI 的特点：从外面看，它做出来的东西既好看又像能用。就算出了问题，好像也能很快解决。但每个问题和后续修复背后，那些野路子拼凑出来的方案，都会打成一个个结，迟早绕回来折磨你。因为我们只能看到 AI 工具的正面，所以很多时候，问题看起来像被解决了，其实只是被糊上了一层。

我很快学到，做一个“简单” App，也会有大量复杂度。如果你是靠感觉指挥 AI 写代码的人，这里基本只能靠自己。

如果在团队里，你有人，也有经验，可以一起把这些事想清楚。很多坑之所以能避开，是因为工程师以前已经踩过。可用 AI 单打独斗时，只有你和一个大语言模型。如果你不知道该问什么，就很难预判接下来会发生什么。

这里有几件事，我当时应该早点做。

让大语言模型把我的方案拿去对照 App Store 规则和 iOS 限制。

创建一个 Perfect.md 文件，写清楚理想中的端到端用户体验，并要求 Claude 的每次改动都对齐它。

早点找真人聊这个想法，把潜在问题提前挖出来。

第四课：这种写法的雷区很吓人，但不致命

做 OnTimer 的过程中，有三四次我撞上了看起来完全过不去的墙。有些问题会让整个项目停住，也会把我逼到快崩溃。

几周后，我掉进了一个循环：发现 bug，提示 Claude 修复，Claude 说“完美，我修好了”，结果什么都没变，然后重复。

我的提示词后来一路退化，最后变成对 Claude 发火，让它滚一边去。这当然没用。

有一次，我真的急了，就让 Claude 教我怎么手动改首页上的一个词。我已经快疯了。Claude 连最简单的改字都做不到，更别说修 bug。

然后我看到，自己手动改的东西瞬间又被还原了。我不知道为什么，但那一刻终于看清发生了什么。原来我之前做的一次更新，会把新代码保存到一个备份盘里，而真正运行的文件一直没变。

那一周简直像地狱。最后真正的修复只花了五分钟。

这种写法的问题在于，你没有工程师那套直觉和处理方式。我们没法像工程师那样看代码。东西一坏，就很容易迷路。

但我学到的是：别一直重复做同一件无效的事，也别让 Claude，或者任何 AI 工具，一直这么干。就算你要求它做根因分析，它也经常会继续盯着代码里同一个区域反复修。你得把它从自己的惯性里拉出来。

我发现一个挺好用的办法，是用另一个大语言模型来挑战 Claude。如果某个修复不生效，我会拉 ChatGPT 进来。

我会把 Claude Code 的对话和相关文件交给 ChatGPT，让它重新分析，并写一个新的提示词。

然后我把这个提示词发给 Claude，让它进入 Plan mode，再在两个模型之间来回对。

修好之后，我会把详细解释写进 Claude.md，避免以后再遇到类似问题。

Bug 可能是这种方式最痛苦的部分。它们不只是浪费时间，还会一点点偷走你的信心。这个过程不好玩，但你越能熬过去，就会修得越快，也越知道怎么修。

第五课：早点变现，你不会后悔

从一开始，我就知道自己要把 OnTimer 做成订阅 App。让 App 变现，会逼你关注价值交付，以及产品和市场是否匹配。即使你还在学习，这些压力也是很好的约束。

你必须做真正的决定：免费增值还是付费？免费试用多长？哪些功能放在付费墙后面，哪些不放？我选择了免费增值加年订阅。免费层让用户体验核心闹钟功能。付费层解锁多个日历，以及 Time-to-Leave 出发提醒。

决定哪些功能该放到付费墙后面，会逼我问自己：什么东西有价值到用户愿意付钱？什么东西必须免费，才能让用户先上手、先被吸引住？这种思考让 OnTimer 变成了一个更好的 App。

变现会带来很多层额外复杂度。

App Store 会更复杂。订阅 App 在审核时会受到更多审视，而当你急着发布时，被拒会更疼。

权益判断也会更复杂。你的 App 必须知道用户已经为哪些功能付费，并正确展示。

付费墙也要认真处理。糟糕的付费墙不只会伤害转化，还可能直接让 App 被拒。

好在 RevenueCat 让这些事快了很多，也简单了很多。他们给用 AI 写代码的人提供了一个集成提示词，当时对我来说真的像魔法。

我把它喂给 Claude，几分钟后就开始跟着 RevenueCat 的设置向导往下走。不到一天，我就有了一个能工作的付费墙。

它并不完美。我确实因为付费墙问题被 App Store 拒了两次。RevenueCat UI builder 里的一个细节，视觉上看起来是对的，但实际行为不对，会退回默认状态，而不是我选的状态。我联系了客服，很快把问题解决了，OnTimer 最后也通过了审核。

很酷的一点是，几天前我再回到付费墙编辑器时，发现当时我踩到的那个问题已经修好了。自己的反馈能帮下一个开发者避开同一个坑，这感觉很好。

RevenueCat 扛下了很多重活，我就能把注意力放在 App 的核心价值上。他们处理订阅系统里的各种麻烦，让你可以继续专心做出别人愿意付钱的东西。

所以，我真的建议你早点变现，原因有三个。

第一，它会逼你诚实面对价值。如果没人愿意付钱，那也是信息，越早知道越好。

第二，付费用户给的反馈比免费用户更有价值。他们投入了钱，也更希望产品真的好用。

第三，收入会改变你的心态。哪怕每个月只有几美元，也会让你更认真地发布、更认真地改进。

去做你的第一个 App，值得

你真的应该去做自己的第一个 App。它没有网上说得那么简单。东西会坏，你会撞墙，也会有真正沮丧、怀疑自己的时刻。

但你也会有一些特别有成就感的时刻。昨天我去看医生，OnTimer 的 Time-to-Leave 功能根据路况和距离，给我响了出发提醒。

这是我做出来的！

好吧，Claude 也帮了忙。

重点是，这种做法是真的能用。你可能不会像 LinkedIn 和 X 上很多人说的那样，一上来就每个月赚 10 万美元。它大概率会比你想象中花更久。我花了大约四个月才上线。但如果你能熬过那些难的部分，你真的可以做出让自己骄傲的东西。

现在，我在发布、学习，也开始看到最早的收入信号。下一个挑战是增长，而这也会很难。

但我已经进来了，而且我敢肯定，这不会是我做的最后一个 App。

是 AI 让我动手，是坚持让我走到这里。

你也可以去看看 OnTimer，Never be late。

原文信息

原文标题：Yes, you can build a subscription app with AI (but it might hurt a bit)

作者：Ethan Garr

发布平台：RevenueCat

发布时间：2026-04-23

原文链接：

https://www.revenuecat.com/blog/engineering/vibe-coding-reality-vs-hype/

摘要