第 13 章：经验总结

---

开源 vs SaaS：完全是两件事

做完这个项目最大的感受：

维度	开源版	SaaS 版
用户群	技术人群，能自己部署	所有人，包括不懂技术的
部署	用户自己搞定	你帮他搞定
安全	用户自己负责	你负责（出事算你的）
出 bug	用户提 Issue，你修不修看心情	出 bug 要退钱
稳定性	偶尔挂没关系	挂了用户发邮件问你
维护	几乎为零	每周要看看有没有异常
收入	0	有，但很少

开源是"我做了个东西放出来"，SaaS 是"我替用户维护一个服务"。 后者的心理压力和责任感完全不同。

---

核心结论：技术复杂度不等于商业价值

核心功能（AI 新闻聚合）技术上并不复杂 — 抓数据、调 AI、生成日报。有经验的开发者一周能做完。

但让它"能卖钱"，需要的工程量是核心功能的 3 倍以上：

• 用户系统 — 注册登录认证
• 支付 — 支付宝接入 + 订单状态机 + 套餐升降级
• 安全 — 4 层防薅 + 封禁策略
• 运维 — 多服务部署 + 监控 + 备份
• 前端 — 完整的 Web 应用

如果你想做 SaaS，一定要在心里把"非功能性需求"的工作量乘以 3。 很多人评估时只看核心功能说"两周能做完"，然后在支付、安全、部署上花了两个月。

---

项目积累的复利效应

WeChat RSS (第一个 SaaS 项目)
    → 用户/支付/部署模式跑通
        → AI News RSS SaaS（复用整套架构，改业务逻辑）
            → 下一个项目（继续复用）

每做一个项目，下一个的启动成本就低一些。复用的不只是代码片段：

• 架构模式 — 前后端怎么分、API 怎么设计、数据库怎么建
• 运维经验 — 域名怎么配、SSL 怎么搞、服务器怎么维护
• 防护策略 — 防薅逻辑直接搬，不用重新设计
• 支付对接 — 支付宝接口跑通了就不用再折腾
• 部署流程 — 知道哪些坑要注意，启动顺序是什么

这是非技术背景做 SaaS 最大的优势积累：你的每一个项目都在为下一个铺路。 第一个项目最痛苦，后面越来越快。

---

AI 协作的真实体验

整个项目 AI 参与了大约 70% 的代码编写。但有明确的分工：

AI 写不了的（需要人来做）：

• 产品判断 — 做什么不做什么
• 架构决策 — 用什么技术、怎么分层
• 异常处理 — 线上出了什么 bug 怎么修
• 防护策略 — 被攻击后怎么应对

AI 擅长的（交给 AI 效率高）：

• 标准化实现 — CRUD 路由、数据库模型
• 模板代码 — JWT 认证中间件、支付回调验签
• 格式转换 — RSS XML 生成、邮件 HTML 模板
• 工具函数 — 日期转换、URL 标准化

AI 是执行者，不是决策者。 你负责"做什么"和"为什么"，AI 帮你完成"怎么做"。如果你连"做什么"都不清楚，AI 也帮不了你 — 它只会给你一个看起来完整但方向可能完全错误的实现。

---

方法论的验证

回头看，这个项目几乎对应了教程里提到的每一步：

方法论步骤	本项目实际体现
发现真实问题	自己每天需要 AI 信息聚合
验证需求	有类似开源项目存在，说明不是自嗨
MVP 先行	开源版只做核心四个功能
技术选型匹配阶段	开源用 SQLite，SaaS 才上 PostgreSQL
迭代扩展	基于已有底座扩展而非从零开始
测试匹配阶段	个人阶段手动测，商业化后关键模块自动化
开源协议选对	AGPL 保护了商业利益
部署选最简单的	开源单容器，SaaS 用 1Panel 不上 K8s

---

给想做类似项目的人

1. 先做个自己每天用的版本 — 如果自己都不想用，别人更不会
2. SaaS 的门槛在非功能性需求 — 核心功能是最简单的部分，认清这一点
3. 有底座再做新项目 — 从零做第一个 SaaS 会非常痛苦，但第二个就快多了
4. 宣传和开发同等重要 — 这个项目最大的问题是宣传投入不够
5. 收入预期要现实 — 小众工具的付费转化率很低，单靠一个产品养活自己不现实

---

真实数据（截至 2026 年 6 月）

• 实际付费用户：2 人（含 1 名包年）
• 早鸟体验用户：21 人
• 总注册用户：88 人
• 累计收入：128.8 元
• 信息源：18 个
• 每日产出：15-25 条精选
• Token 累计消耗：1400 万

数据很诚实。这不是一个"月入 X 万"的成功故事 — 是一个真实的、从 0 到 1 的完整过程。它证明了方法论可行，也说明"做出来"和"赚到钱"之间还有很长的路要走。宣传、运营、产品打磨 — 每一步都是下一个要攻克的课题。