我做了一个 AI SaaS，跑了 26 天，付费用户 0 — 错的不是流量

3 月 25 日下午，我注册了管理员账号，把整套 AI 设计 SaaS 推上线。

3 月 26 日凌晨 3 点到下午 3 点，我用这个号生成了 45 张图，调通了所有路径，存了一份成品 design。

3 月 27 日开始，没有任何人再操作过这个产品。

但服务一直在跑。

数据库一直在监听。LLM gateway 一直在 idle 中维护着到上游的连接。后端 33 次崩溃 33 次重启。一直跑了 24 天。

4 月 20 日下午 4 点 38 分，我登上服务器，敲了 pm2 stop dabids-backend，停了。

整个项目的真实账面：

注册用户:   2 (含管理员)
设计作品:   1
生成任务:   45 (41 done, 4 failed)
充值订单:   0  (recharge_orders 表都没建出来 — 因为不需要)
营收:      ¥0
存活时间:  26 天
有人用的时间: 12 小时

这是一份典型的中文小型独立开发者的 AI SaaS 死亡数据。写出来不是为了哭，是为了记一记我曾经搞错了什么。

我以为的问题

那天主动停服之前，复盘了一晚上。当时归因的方向有四条：

一、产品没做好——但产品其实做完了。Hono + Postgres + Redis + Sharp + JWT auth + 充值套餐（4 档：¥9.9/¥39.9/¥79.9/¥299）+ 46 个 AI 模型配置 + 7 个工具配置 + 4 个 quick prompts。后端代码 5000+ 行 TypeScript，编译通过，prod 跑得稳。

二、技术栈选错了——但 stack 经得住时间检验。24 天 prod uptime，33 次 restart，没出过数据丢失。崩溃模式都是已知的小问题（连接池超时、内存抖动），没遇到任何"卧槽这架构错了"的事。

三、UI 不够漂亮——前端拼了一套 Vue 3 + Tailwind，能用、不丑、能登能调能生图。

四、AI 模型质量不行——46 个模型配齐，覆盖主流图像生成 + 文本生成 + 视频生成的供应商。没人用的 24 天里我自己跑过几次，质量符合预期。

四条都不成立。Stack OK、产品 OK、UI OK、模型 OK。

那为什么没人用。

真正错的那件事

我没有任何拉新的方案。

3 月 25 日晚我把 SaaS 推到 shop.touzileida.cn，第二天调通自己用了 12 小时——然后什么都没做。

没投流。没做 SEO。没在任何社区发帖。没朋友圈。没找过 KOL。没加过任何用户群。完全没有把这件事告诉任何人。

我心里那个朴素的、不可饶恕的假设是：“产品好就会有人来”。

这个假设比 stack 错、比 UI 丑、比模型差，杀伤力大一个数量级。

因为产品差你能改。stack 差你能换。UI 丑你能调。但「没有用户进来」这件事，只要分发渠道不动，明天还是 0、后天还是 0、24 天后还是 0。

数据是单方向积累的：

day 0:  build 完成
day 1:  自己用一遍
day 2:  0 用户
day 3:  0 用户
...
day 24: 0 用户  ← 不会自然变好
day 25: 0 用户  ← 不会自然变好

24 天的 0 不是"还没起势"，是这一组特定的运营动作（什么都不做）的稳态结果。如果第二天没用户，第二十二天大概率也没有；如果第二十二天没有，第二百二十天也没有——除非中间某一天真的做了一件不一样的事。

我没做。所以产品没动。

为什么我会犯这个错

不是没听过"build vs distribution"那个老掉牙的口号。听过。但听过和真信是两件事。

我一直觉得"产品先做好"是个谨慎的、有把握的策略。把代码写得稳、bug 修干净、stack 能扛住流量——等流量来了就不会崩。

但等流量来了这五个字，是个完全没人写的逻辑分支。代码里没有这一段。日历上没有这一段。文档里没有这一段。我心里也只是一个被默认填上的"自然会发生"的事。

复盘到这一刻才意识到："等流量来了"这个 if 分支，自然不会发生。流量是被人主动召唤过来的，不是被产品自然吸引过来的。召唤动作必须自己写。

写代码这件事会有反馈：写错了 compiler 报错、跑挂了 logs 报错。写到不会报错就完成了。

写"流量召唤"没有反馈：你今天在群里发了一条没人理，明天发了 5 条还是没人理，后天发了 10 条第 1 个人来了。没有"完成"的概念，只有持续 push。

这两种工作的肌肉是反的。会前者的人不会自然学会后者。我那 24 天的 0 用户，就是用前者的肌肉去做后者的事的代价。

该停的时点其实早就到了

如果问"你这 26 天里什么时候应该停"，复盘看其实是 day 3。

day 1：产品上线，自己用一遍——正常。 day 2：0 用户——正常，刚上线，没人知道。 day 3：0 用户——这一天是判断节点。

day 3 的 0 用户不是"还没起来"，是"我没让它起来"的第一个信号。

那一天该问的问题不是"产品哪里没做好"，是"今天我做了什么动作让用户能进来"。如果答案是"没有"，问题不在产品，在我自己当天的 to-do list。

day 3 之后任何不解决"今天怎么让一个新用户来"的工作，都是浪费。继续写代码是浪费、继续优化 UI 是浪费、继续加 AI 模型是浪费、继续修崩溃是浪费——24 天的服务器、43 次 LLM gateway uptime 报告、33 次后端 restart——全是浪费。

不是浪费在 stack 错了上面，是浪费在「问题不是产品」这件事我整整 24 天没承认。

决策框架（写给下一个我）

下次再做小型 SaaS 之前，先把这一段抄到日历上：

判断标准只有一个：“今天有没有一个具体的、新的人，因为我做了某个具体动作来用了一下”。这个标准比"产品迭代到 v0.3 了"硬一万倍。

写在最后

26 天前我以为做 SaaS 难的是 stack。

26 天后我才确认：stack 是最不难的那一段。

真正难的是——每天醒来，知道今天该找谁、说什么话、做什么动作，让一个新的人愿意试一下你的东西。

这件事代码不能替你做。框架不能替你做。AI 不能替你做。LLM gateway 不能替你做。46 个模型不能替你做。4 档充值套餐不能替你做。

只有你自己每天主动伸手出去，才会有人伸手回来。

这 24 天的 0 用户，是我一个人坐在家里写代码、一直没伸手的代价。