独立开发者穷鬼套餐：从博客到 AI 短剧的低成本实战

项目还没赚到第一笔钱，部署、数据库、登录、邮件、监控已经各自准备好了一张订阅账单。

最近看到一张「独立开发者穷鬼套餐」的工具清单，我最认同其中那句：跑起来之后再升级。

但真正动手做项目以后，会遇到清单没有回答的问题：免费额度够不够？这些服务能不能接在一起？做第二个应用时，哪些东西还要重新搭一遍？

这段时间，我折腾了个人博客 meme、Fluxship 背后的 AI 产品，以及斗地主、Open Cookie 记账和 Shortdrama Studio 画布短剧工作台。把这些项目放在一起看，我越来越愿意把预算花在两件事上：让用户完成核心操作，让出了问题的系统能够恢复。

这篇就把我的选型摊开，看看一个人做不同类型的应用，怎样把起步成本压下来。

五类应用共用哪些技术

先看项目，工具名字会更容易理解。

这些项目并没有使用完全相同的技术栈。博客不需要照搬 AI 产品的生成队列，短剧工作台也没有为了部署在 Cloudflare 上，就把业务数据库强行改成 D1。

能反复用起来的，是 TypeScript、熟悉的 UI 组件、清楚的数据模型，以及登录、上传、邮件和任务处理的经验。每次开新项目，都少重新研究几个问题，这笔时间账很可观。

博客先把服务数量减下来

meme 现在的组合比较紧凑：TanStack Start 负责页面和服务端渲染，Elysia 提供 API，一个 Cloudflare Worker 承接应用入口；D1 保存文章、账号和评论，R2 保存图片，KV 承担部分缓存及互动兼容数据。

对这种内容站，我更在意打开文章、搜索发现、编辑保存和图片加载。把前台、后台和 API 放在同一个应用里，已经能完成主要工作。

这个博客过去接过更多外部服务。随着内容、账号和互动数据逐渐收回到明确的模型里，维护时需要来回切换的控制台也少了。现在正式域名已经直接绑定 Worker；早期迁移文章里提到的 Vercel 代理，是当时的过渡方案。

对照具体实现，可以读个人博客的 Cloudflare 重构记录。

如果你做的是博客、作品集或小工具站，我建议先把这一层做通。登录只在确实需要保存用户数据时加入，后台先满足自己的编辑需求，统计先回答“有人来吗、看什么、从哪里来”。

少接一个暂时用不上的服务，就少一套配置、权限和故障排查。

斗地主和记账要把钱花在状态与数据上

做游戏以后，省钱的重点会变。

斗地主用 PixiJS 处理牌桌画面和交互，服务端则需要知道谁坐在哪张桌、轮到谁出牌、断线以后怎样继续，以及一局结束有没有重复结算。项目里的牌桌使用 Durable Objects，账号和战绩等数据进入 D1。

画面可以慢慢打磨，结算得先算对。一次断线重连就多发奖励，或者旧连接恢复后把新状态覆盖掉，都会直接伤害体验。后端工作量要围绕这些具体问题安排。

Open Cookie 记账又是另一种取舍。Web 端使用 PGlite，原生端使用 Expo SQLite，让本地先保存可用的数据视图和待同步修改，再通过同步协议与服务端 D1 对齐；R2 保存票据等附件。

这样能让记一笔账、翻历史记录这些操作少受网络波动影响。但离线能力也带来了工作：重复提交怎样去重，两台设备改同一条记录怎样处理，切换账号后本地数据怎样隔离。

本地优先很适合这类工具，却需要为同步和恢复预留开发时间。做第一版时，也可以先实现单端可靠保存和导出，再逐步增加多端能力。

这部分我在Open Cookie 的记账与同步设计里拆得更细。

AI 应用要单独算生成成本

到了 Fluxship 和 Shortdrama Studio，成本结构会明显变化。

页面可以很便宜。用户每点一次生成，模型供应商却可能开始计费；图片、视频和配音还会产生文件存储、任务查询与失败恢复的工作。

Shortdrama Studio 的画布使用 React Flow，把角色、分镜和素材组织起来。后端通过 Elysia 处理业务，Turso / libSQL 保存项目与任务，R2 保存媒体，Queues 和 Durable Objects 分别参与生成派发、协作与 Agent 执行。

这里有个很实际的细节：模型返回一个图片地址以后，还要把文件保存为项目自己的素材。上游临时地址过期，用户昨天做好的内容就打不开，这种便宜很难接受。

Fluxship 则需要进一步处理模型目录、积分、订单、支付与任务状态。我会把这些通用能力放在可复用的模块里，让更换供应商或执行后端时，尽量少动业务规则。

想看实现，可以接着读短剧工作台的 Cloudflare 架构和生成任务的多 Provider 设计。

做 AI 产品时，我会先设试用额度、并发限制和单次任务上限，再扩大免费体验。 对已经送到供应商的任务，重试前还要判断它是否仍在运行；一次本地超时，可能对应一笔已经发生的外部成本。

举个纯假设的算账例子：100 位试用用户，每人每天生成 2 次，每次供应商成本 0.05 美元，一天就是 10 美元，持续 30 天就是 300 美元。这还没有计入重复执行、失败消耗和存储。这个数字用于说明计算方法，实际单价取决于模型与参数。

便宜的托管，仍然需要配上一套算得清楚的业务。

免费额度具体能覆盖什么

下面的额度按 2026 年 10 月 13 日查询的官方说明整理，适合用来估算起步条件。它们有各自的计量方式，不能直接相加成“整个产品每月只要多少钱”。

Workers 的付费基础费按账号收取。多个项目可以共用账号的套餐，但也会共同消耗相应额度；一个项目突然增长，要一起看账号的总用量。

可以做一个很窄的示例：在 Workers Standard 下，假设一个账号每月总共处理 100 万次动态请求，每次平均消耗 5 ms CPU，就是 500 万 CPU-ms，落在套餐包含的 1000 万请求和 3000 万 CPU-ms 内，这部分 Workers 运行费用为每月 5 美元。数据库、对象存储、队列、实时连接等服务，以及域名、模型和开发工具，需要继续分别核算。计费规则

静态资源还有单独的计费规则。以 meme 为例，它的部署配置会先运行 Worker，因此估算时也要看实际请求经过了哪些处理。仅凭“这是个博客”很难推导出零运行成本。

域名我会看续费价；AI 编程助手的订阅会放进开发预算；验证码邮件、模型调用和支付手续费则放进业务预算。基础设施账单之外，自己的维护时间也值得记下来。

我会避开的几个省钱误区

把 KV 当成 Redis 的直接替代品。 KV 很适合读多写少、允许一定延迟的数据。它采用最终一致性，不能顺手拿来承接严格余额、原子扣减或需要强一致性的锁。Cloudflare 官方也明确说明了这些边界。KV 一致性说明

把免费套餐默认当成商用套餐。 例如 Vercel Hobby 官方限定为个人非商业用途。准备接支付、做经营性产品时，就需要重新选择适用的套餐或部署方式。Vercel Hobby 说明

为了用同一家平台而重写整个项目。 已经稳定工作的 Next.js、PostgreSQL 或 Redis，有自己的价值。迁移要看能够减少多少维护、解决什么问题。像短剧工作台保留 Turso、Fluxship 保留更完整的数据库与任务体系，都有对应的业务背景。

把自部署软件的价格当成总成本。 用 Dokploy 管理应用、自己部署统计或数据库，可以增加控制力；服务器、备份、升级和故障处理仍然需要预算。已有服务器且熟悉运维时，这条路更值得考虑。

项目刚开始就补齐所有配套。 热力图、复杂漏斗、自动化营销、客服平台，都可以在出现具体问题以后再加。一次只接一个能回答当前问题的工具，通常更容易判断它是否值得保留。

如果现在从零开始

做博客或小工具，我会先选熟悉的页面框架，接上托管、域名和必要的数据存储，把发布与备份走通。

做记账或日常工具，我会先把核心操作、数据导出和恢复做好，再根据用户场景决定是否增加离线同步。

做游戏，我会先完成一局可重复玩的流程，围绕房间、断线和结算增加服务端能力。

做 AI 应用，我会从一个明确的生成场景开始，同时建立额度、任务状态和成本记录。模型数量可以慢慢增加，用户已经付费的任务需要能够解释、恢复和对账。

这些项目做下来，我愿意长期复用的是一套自己熟悉、出了问题知道从哪里查起的基础设施。等用户真的需要更多能力，再增加对应的服务和预算。

独立开发者的预算有限，值得多留一点给产品本身。

如果你也在配自己的「穷鬼套餐」，欢迎分享：哪些服务你一直用免费额度，哪一项付费真正帮你省下了时间？