从 0 到盈利：我用 AI 做的第一款 SaaS，终于跑通了商业化
见字如面，与大家分享实践中的经验与思考。
我于 2024 年开始接触 AI 技术，2025 年上半年开始大规模测试和使用各种 AI 工具与大语言模型。
但此前都以 Demo 或小工具验证为主，终究还是空中楼阁、纸上谈兵。于是，我萌生了一个想法：完全使用 Vibe Coding 开发一款企业级产品，把 AI 当作真正的员工，结合个人工作流，整理出一套 独立开发 + AI + 运维 + 运营 的标准工作流（SOP）。
接下来，我会分别聊两个部分：一是如何推进个人产品的商业化，二是我对 AI 使用的第一手感受，希望能让你少走一些弯路。文章略长，感兴趣的话不妨读一读。文末会贴上项目图。
背景
缘起于家人的生意模式，我决定开发一款进销存产品。当时我对这个行业并不了解，前期主要依靠 ChatGPT 和 Gemini 输出大量行业知识以及初步的业务模型，再通过这些模型进一步理解业务流程和核心逻辑。
我花了 2 个月开发出小程序 MVP 版本，又花了 1 个月开发出 PC 管理端，全部都是从 0 到 1。技术栈尽量选择最新方案，同时一步步提取通用组件、UI 组件，并统一分层架构（全部以后端 DDD 的分层架构模式为基准，来设计所有前端的分层架构）。
后面推广时，我发现很多试用客户的业务流程和我原先设想的并不一样，于是又针对不同客户的业务流程做了大量增量开发。其实，大量时间都花在了这件事上。和现在的产品形态相比，最初的 MVP 版本差得太远了，甚至早期客户付款都是直接打到个人微信，然后再通过管理端手动开通权限。
历经大半年的时间，才逐步把产品的逻辑和框架稳定下来，并开始陆续有客户试用、订阅以及转介绍。
我对产品商业化的看法
如果你想做一个产品，但它没有商业化路径，那么过一段时间之后，一旦没有用户、没有收入，你大概率就会放弃，因为缺少继续坚持的动力。所以，商业化是重中之重，也是最难的一部分。
我踩过的最大弯路，就是早期产品设计初衷偏向个人或小团队使用。后来有一个企业级客户前来咨询，我才决定将产品全面往企业化 ToB 方向演进。
我总结了较为重要的 6 个部分，也许不同项目、不同客户群体会有所不同，仅供参考。
01 多端产品形态
如果商业模式已经得到验证，让我重来的话，我会把后端、电脑管理端、小程序端以及移动端同时推进。但现实情况很难做到，一个人的精力有限，加上学习周期太长，但至少需要后端、PC 管理端和小程序端，不然很难有竞争力。
作为后端 TL / 架构师，在决定创业后，我首先开始转全栈。学习前端 Web 技术就花了不少时间，因为我知道，如果不掌握这些知识，就无法 Review AI 生成的前端代码，更谈不上判断这段代码能不能上生产环境。
我个人坚持使用原生技术，以便给用户更好的使用体验。但学习移动端的 iOS / Android 技术又要花费大量时间，所以打算等版本需求稳定之后，再开始着手准备。不过，这也意味着要接受部分客户的流失，这也是必然的。
02 企业级权限体系
企业级客户一定会有让员工共同参与经营管理的诉求，但不同员工需要配置不同的角色和权限，所以全端都要进行权限体系设计，绝不是“登录成功就行了”，权限设计千万不要偷懒。
后端可以基于 RBAC 进行底层设计，甚至做各种变种，比如支持身份、部门等维度，并将权限细粒度拆分为一个个权限码。
管理端要做业务菜单可见性、页面路由守卫、元素级别控制、数据权限等，移动端同理。
简单来说，要具备非常细粒度的权限控制，可以灵活按照不同企业的组织结构进行权限设置。
03 业务流程能力
个人记账和企业经营最大的区别，不在于数据量，而在于流程。企业本质上是一个流程组织，每一张业务单据都不只是“录进去”就结束了，而是要沿着责任链条持续流转。
那就需要审核机制、单据状态流转控制、核心操作留痕。让业务从发起到结束，每一步都清晰、可追踪、可管理。
04 企业级数据能力
当流程建立起来之后，企业管理者一定会非常关注数据，并希望用数据驱动经营。所以，一个真正面向企业的系统，需要具备完整的数据闭环能力。
第一层是报表能力，比如销售利润概览、销售利润明细、应收应付等关键报表。
第二层是导出能力，可以把单据、统计结果和经营数据拿出去做分析、汇报和归档。
第三层是导入能力，让基础资料能够被高效初始化，并支持批量导入和维护。
技术实现本身不是难点，但一定要考虑性能，尤其是数据量大的时候，别把服务器带崩了。
05 商业能力
一款 SaaS 产品走向商业化的第一步，就是搭建完善、合理的订阅体系。你可以根据企业规模设置成员人数限制，提供不同版本的价格梯度，还要通过功能差异化来支撑不同层级客户的选择。更进一步，这些能力最好都能在后台进行配置，而不是写死在代码里。
因为只有这样，产品才能适配不同规模的客户，形成清晰的套餐设计和长期可持续的收入模型。商业能力做得越扎实，产品就越有机会真正从项目式交付，走向标准化增长。
在国内，支付平台选择微信和支付宝基本就够了。不建议选第三方聚合收款平台，一是费率高，二是存在跑路风险。除非你是纯个人用户，缺少资质。
另外，支付流程设计一定要完整，比如生成支付单、异步接收支付成功回调、定期查询支付结果、自动关单、退款等一系列操作。
06 系统配置能力
产品在早期阶段，靠写死逻辑快速交付很正常，我也是这么做的。但一旦进入企业场景，这种方式很快就会遇到瓶颈。因为不同企业的流程习惯往往存在差异。这样一来，每来一个客户都改一版代码，交付效率会越来越低，维护成本也会越来越高。
所以，一定要配置化。比如流程节点可以配置，基础数据规则也可以配置。这样一来，系统面对不同企业时，就不是“重新开发”，而是“按规则组合和调整”。
配置能力越强，产品的适应性就越高；配置能力越完善，实施效率就越高，边际交付成本也会越低。这其实是企业级产品能不能规模化复制的核心能力之一。
我对 AI 使用的看法
首先说明一下，我每天使用 AI 至少 8 小时，几乎是不间断地使用。其中，绝大部分 AI 工具我都至少连续尝试过一个月以上，所以还是有一些发言权的。
01 AI工具的选择是第一步
直接说结论：
Claude Code / Codex 是核心生产力工具，其次是 Cursor / Google Antigravity 等，再者才是国产。
以上排序完全基于个人使用体感。如果条件允许，按照这个顺序选择基本不会有问题，但这并不代表其他工具就不能用。
在 Cursor 还有每月 500 次额度的时候，我几乎只需要 Cursor 就够了，因为项目初期开发量相对较小，更多时间花在设计上。后来 Cursor 开始按 Token 计费，我才开始使用 Cursor + Trae 的组合。没办法，量一旦上来，就需要把一些简单任务分给每月有 600 次额度的 Trae。也是在这个时候，我开始正式使用 SDD（规格驱动开发）给 Trae 拆任务。但这确实很累，就像带一个初级员工一样，不能指哪打哪，需要“喂饼式”开发。再后来，我开始使用 CLI，才发现这才是真正的效率大杀器。
最后，不要花太多时间和精力去折腾白嫖工具、反重力和中转。建议优先使用官方直连 API，有 Coding Plan 的优先上，因为使用量一大，如果不选 Coding Plan，产品还没赚钱，钱可能都先投给 AI 厂商了。
02 SDD + DDD 才是复杂业务的唯一解
我真的很喜欢 DDD，就算是个人项目也会坚持使用。感兴趣的话，可以去我公众号里找找关于 DDD 的文章。之前带团队时，我几乎一直在推 DDD 落地，但人一多，落地效果往往一言难尽。但这次用 AI 不一样了，通过 Rules 和 Memory 文档，可以严格约束 AI 的代码输出。同时，我把 DDD 分层架构全面推广到所有端，代码的可读性和可维护性都得到了极大提升，也非常适合 Mono Repo 架构设计，效率确实很高。
SDD 可以参考 Spec-kit 或 OpenSpec 做项目级改造。虽然它们都是英文的，但提取核心部分就够了。更重要的是，一定要结合项目实际情况做定制化，这样才最适合自己的项目。一味复用，最后只会苦了自己。我的观点是，SDD 这个概念非常好，本质上就是项目中架构师和 TL 做任务拆解、带团队高效产出的那一套方法论。但现在很多工具太花里胡哨了，有时候感觉是为了写文档而写文档，一天到晚维护 spec 文档，这就本末倒置了。其实，Spec 最适合的场景是超级复杂的任务，或者稍微笨一些的 AI 工具；如果你用的是能力很强的大模型，提示词写得好一点，或者直接使用 Plan 模式，它往往就能把事情干好。
复杂系统的核心不是代码生成，而是结构生成。先做领域建模，别让 AI 直接面向页面和表单开发。
03 Git 和 Review 一样不能少
每次明确的修改都必须先提交到 Git 仓库，便于后续将 AI 生成的结果与最新代码进行对比。不然，大量 AI 生成的代码混在一起，根本无法 Review。因为 AI 改代码太快了，而且可以成批修改，甚至有时候会“抽风”乱改，把原本看上去不错的落地实现全部改乱。这时候如果代码混在一起，你根本没法区分，所以一定要尽量规避。
至关重要的一点，那就是每次 AI 生成的代码，最后一道防线，一定要人工 Review！当然中间可以通过不同的 AI 工具进行互相 Review。
所以，保持小步提交，不要大段生成！
04 先定边界，再让 AI 写代码
AI 不是写得慢，最危险的是它会在错误的问题定义上高速产出。现在最顶级的前沿模型，代码质量已经很好了，最欠缺的还是顶层架构设计能力。以现在 AI 的发展速度看，这个短板可能也补上不了多久了。
我刚开始想完全使用 Vibe Coding 生成一个完整产品，但中间也吃了很多教训。让我印象最深的，就是支付平台对接和复杂库存逻辑改造这两件事。我当时采用 SDD 模式进行开发，最终还是推倒重来，重新使用“古法开发”。
所以在我的场景里，AI 还有这么几项工作不能很好地胜任：
顶层架构设计（技术栈选项、分层架构、全端权限设计、数据建模等）
外部系统集成（如微信支付对接等）
复杂的业务逻辑（涉及 5 张表及以上的事务逻辑、PDF/Excel 导出）
05 稳定可替换的AI工作流才是重点
首先，要对 AI 有一个清晰的定位：只让它负责相对清晰的产出物，并且这个产出物必须可以被人验证。
比如，我个人会将研发拆分成如下节点：
需求澄清（PRD 文档）
设计草稿（UX 设计稿）
领域模型（模型设计图）
架构设计（架构设计图）
技术栈选型（技术设计图）
AI 规则文件编写（Rules、AGENTS.md、Skills）
任务拆解（SDD）
代码开发（AI 工具）
Code Review（AI 工具 + 人工）
代码重构（AI 工具）
测试验证（目前人工）
运维（目前人工）
如果每一步都有明确的输入、明确的输出、明确的验收标准，那么你今天用 A 模型写代码，明天切换成 B 模型，也不会伤筋动骨。这就像你带高级程序员和初级程序员一样，只是需要投入的精力不同。
最后
当你真正开始高频使用 AI 工具之后，很容易生出一种自己无比强大的感觉，就像钢铁侠穿上了盔甲，能力瞬间被放大了。很多原本需要多人协作、反复推进的事情，现在一个人也能快速拉通，这种效率提升是非常真实的。
但打铁还需自身硬。软件工程本身的复杂度依然存在，系统边界、架构设计、业务抽象、稳定性保障，这些问题并不会因为 AI 的出现就被自动磨平。AI 可以极大提升产出速度，却不能替你承担所有关键判断。
不过，AI 最近几年的发展速度实在太快了。站在今天这个时间点，不会使用 AI 的程序员，未来大概率会被淘汰。因为真正拉开差距的，已经不只是写代码的能力，而是你能不能借助 AI，构建出一套更高效、更稳定、更可复制的生产方式。
附录
欢迎关注公众号"Eric技术圈"，原创技术文章第一时间推送。