我用 Codex 克隆了一个 30 亿美元的应用，现在它永远免费

我用 Codex 克隆了一个 $30 亿的 app。现在它永远免费了。 August 28, 2026 · 6 min read · View source ↗ Mobile Apps Claude Automation 我用 Codex 克隆了一个 $30 亿的 app Calendly 的估值约为 $30 亿。Cal.com 的估值在 $1.5 亿左右，已经融了几千万。 我用 Codex 克隆了核心的排期体验，把它命名为 SnagTime，而且可以在本地免费运行。 产品能用。这次构建也消耗了 334 个聚合智能体小时、76 个独特的子智能体、321 亿输入 token，以及大约 $15,000 的等价推理。 TL;DR → SnagTime 处理实时可用性、预约链接、付费通话、团队角色和品牌工作区 → 一条大 prompt 让 Codex 走完了研究、规划、构建和反复测试 → 智能体蜂群找到了技术 bug，但我仍然得去修人的体验 → 五天的实际工作变成了 334 个聚合小时，因为智能体并行运行 → 我通过 Codex 订阅避开了等价的 API 账单，但拥有软件意味着要维护它 SnagTime 到底做什么 主屏显示即将到来的预约、本月已预约的会议数、总预约小时数，以及每一条已发布的排期链接。 我可以打开一个预约看详情、改期或取消。 工作区设置也覆盖实用内容：密码、头像、工作区图片、颜色、描述、团队邀请。被邀请的队友可以是 member 或 admin。 事件类型完全可定制。 我可以改名称、描述、URL slug、颜色、地点和时长。可用性规则可以包含日期范围和缓冲时间。 我也可以添加自定义问题，让某人在预约前回答。一个事件可以是免费或付费。 公开预约页带着工作区品牌，而不是看起来像一个通用排期器。 视频里它跑在 localhost 上，这就是为什么开发期间托管不花我钱。要给客户发真实链接，我会通过 Vercel 之类的东西把它部署到一个公开域名，接上 Google、一个后端数据库和 Stripe。 在这里拿：https://github.com/nateherkai/snagtime 预约流程 可用性和我的真实 Google Calendar 绑定。 当周五早上和 3:00 到 4:00 有会议时，SnagTime 移除了那些时段。当我在周一加了一个新的 1:00 到 6:00 的阻塞时段并刷新预约页时，那些时间也消失了。 流程的其余部分如你所料： 1️⃣ 选一个可用的日期和时间 2️⃣ 输入联系信息并回答任何自定义问题 3️⃣ 查看详情并确认 4️⃣ 收到确认和日历邀请 5️⃣ 需要时改期或取消 付费事件类型在会议确认之前把客户路由过 Stripe Checkout。我用 Stripe 的 sandbox 卡演示了它，但切到生产 API key 就变成真实的支付流程。 可用性设置覆盖工作日、周末、小时、时区、日期覆盖和休假。 SnagTime 还缺一些 Calendly 的自动化功能。区别在于我拥有软件这一层，所以当痛点出现时，我可以让 Codex 或 Claude Code 加一个自动化或改一个工作流。 五条 Prompt 的构建 第一条指令是一个大的 /goal prompt，把项目拆成四个阶段。 1️⃣ 研究 Calendly、Cal.com，以及客户喜欢或不喜欢什么 2️⃣ 规划功能、架构、数据库、集成和智能体职责 3️⃣ 构建应用 4️⃣ 测试它、修掉失败、然后再测一遍 我没有要一个概念验证就停在那儿。我让 Codex 派智能体蜂群穿过管理端体验、注册、预约流程和事件创建过程。 有些测试循环涉及至少 50 个智能体试图搞崩 app。它们会发现 bug、汇报、修复、再循环。那个循环跑了好几天。 第一个结果叫 TempoCove，看起来非常有 vibe coding 的味道，所以接下来几轮是把它重塑并重新设计成 SnagTime。 性能需要单独过一遍。鼠标移动和打字卡得厉害，有些交互感觉接近一秒。我给 Codex 一个接近 10 毫秒的目标，把它重新送过整个 app。 然后我移动按钮、清理界面、重做了用户体验的一部分。 智能体漏掉的东西 测试智能体很擅长找技术故障，但它们并不总是像人一样用产品。 最清楚的例子是预约进度条。在 review 步骤上，我立刻想点前面的阶段退回去。界面看起来可点，但最初的构建只让我用一个小箭头导航，那个箭头几乎抓不住我的注意力。 智能体一遍遍点穿流程，从没标出这个。 我甚至提示过它们去想体验，但更好的交互只有在我自己用产品时才变得明显。 当人们说几条 prompt 就能搭出整个 SaaS 生意时，这个缺口很重要。 一个对一个人或一个小的内部团队管用的软件，和一个被期望每月赚几万美元的产品，之间有巨大的差别。 一个规模化产品带来推理成本、数据库工作、bug、支持、安全，以及源源不断的功能请求。在第一次构建结束之后，还是得有人去拥有这些决策。 真实成本 这个项目横跨大约两个日历周，因为我会发一条 prompt、去做其他视频、有时就让它闲置。 实际活跃的智能体时间是五天零五小时。 因为智能体并行工作，那变成了 334 个聚合的 Codex 小时在这个项目上跑。 系统创建了 76 个独特的子智能体，但看起来它在任务之间复用了其中很多。把测试和验证蜂群算进去，我估计它委托工作超过 300 次。 token 数字更大： → 32,103,178,736 输入 token → 47,364,103 输出 token → $14,982.96 等价推理 我没有付 $15,000 的 API 账单。 大部分工作跑在我每月 $200 的 Codex 套餐上，我把它完全用满了。根据 app 里显示的使用数字，那个套餐交付了大约 $14,000 的推理。用满可比的那个 $200 Claude Code 套餐则接近 $8,000，少了大约 $6,000。 我还用了大约 $150 的额外使用额度。 它真的免费吗？ SnagTime 在本地运行对我免费，而且它可以替代一个小内部团队的月度排期订阅。 但订阅成本被拥有权取代了。 如果我完全采用它，我预期每个月要发几条 prompt 去修 bug、改进性能、维护集成、加功能。当你想要对产品的掌控并且愿意投入脑力时，这依然是一笔好交易。 有用的教训不是 Codex 能把五条 prompt 变成永久软件。而是：一个智能体系统能把一个有能力的构建者带到一个真实产品里比一年前远得多的地方，而人仍然拥有判断、维护和后果。 我在视频里走查了 app、构建过程和完整成本拆解。链接在第一条回复里。 Tags: # X # Mobile Apps # Claude # Automation # Mobile Apps Related articles The New $10,000 AI Product Is Not an App. It's a Workflow Claude Can Run Most people building with AI are still trying to make another app. They take a model everyone can already access, place it behind a cleaner interface, add billing, authentication and a dashboard, the… Claude AI Mobile Apps Automation