从 0 到 1：一个失业者的 AI 创业自救记

2025年10月，我失业了。凌晨三点，我在出租屋里盯着空白的简历和招聘软件上“AI产品经理”“AIGC工程师”的岗位要求，感到一阵窒息。我懂点技术，但离“AI专家”差得太远。

朋友给我发来一条消息：“试试 BuildingAI，开源的，能搭自己的AI应用，也许你能搞点东西出来。” 我点开了链接。

一、探索：在“玩具”与“工业级”之间徘徊

最初，我像个无头苍蝇。市场上有很多选择：Dify 可视化强但商用要授权，扣子（Caze）轻便但功能有限，LangChain 灵活但对新手像天书。我需要一个能快速验证想法、能商用、能自己掌控的平台。

2025/11/03 23:41
$ git clone https://github.com/BidingCC/BuildingAI
$ docker-compose up -d
部署日志显示 5 分钟完成。我第一次在本地看到了那个“企业级”界面——它不像玩具，它有用户体系、支付开关、权限管理。

我决定以“写作与视觉内容生成平台”为方向，针对自媒体小团队和个人创作者，提供从文案生成到配图、短视频脚本的一站式AI服务。核心逻辑是：用 BuildingAI 作为基础平台，集成 Dify 的工作流、扣子的轻量级智能体，并用 LangChain 串联一些自定义逻辑。

二、决策：为什么最终选择了 BuildingAI作为核心？

1. 商业闭环内置：BuildingAI 自带了用户注册、会员订阅、微信/支付宝支付。我不需要再对接支付网关、设计用户体系——这对一个想快速验证商业模式的个人开发者来说，是救命的。

2. 开源可私有化：代码全公开，我可以部署在自己的服务器上，数据不经过第三方。这一点在向早期用户承诺“数据隐私”时非常有用。

3. 应用市场机制：我可以直接安装社区已有的AI应用（如图文生成、视频剪辑），也可以把自己开发的模块上架。这让我在初期功能不足时，能快速补齐能力。

技术决策日志片段
架构选型：

• 前端：BuildingAI 自带 Nuxt 4 + Vue 3，直接沿用，节省 3 周前端开发时间

• 后端：BuildingAI 基于 NestJS，我在此基础上增加 LangChain 集成的微服务

• 工作流：导入 Dify 的“多步写作流程”并改造

• 智能体：用扣子搭建“标题生成专家”，通过 API 接入 BuildingAI 智能体模块

三、搭建：从“Hello World”到第一个付费用户

第一阶段：组装最小可行产品（MVP）

我在BuildingAI 后台：

• 开启“知识库”功能，上传了500篇爆款文案样本

• 配置“大模型聚合”，接入了 OpenAI 和国内一家性价比高的模型商

• 在“应用市场”安装了“AI绘画”“视频脚本生成”两个官方应用

• 设置会员套餐：9.9元/月（基础写作），29.9元/月（含绘画与视频）

第一个挑战：工作流不通
我从 Dify 导出的工作流，在BuildingAI中运行时总是卡在“意图识别”环节。日志显示 MCP 服务连接超时。

解决过程
我检查了 BuildingAI 的 MCP（Model Context Protocol）配置，发现需要手动允许外部智能体接入。
# 在 .env 中增加
MCP_EXTERNAL_AGENTS=true
MCP_ALLOWED_ORIGINS=http://localhost:3000,https://我的域名.com

第二阶段：集成与优化

为了让“写作→配图→视频脚本”流程自动化，我用 LangChain 写了一个简单的编排器，将 BuildingAI的智能体、Dify 的工作流、扣子的标题生成器串联起来。

第二个挑战：性能瓶颈
当用户同时使用“写作+绘画”时，响应时间从 2 秒延迟到 12 秒。监控显示 PostgreSQL 查询缓慢。

优化记录

1. 启用 BuildingAI 内置的 Redis 缓存，将频繁调用的知识库向量结果缓存 5 分钟

2. 将绘画任务改为异步队列，用户提交后立即返回“排队中”，通过 WebSocket 推送结果

3. 升级服务器配置：2核4G → 4核8G（成本每月增加 200 元）

第三阶段：上线与早期反馈

我在一个创作者社群发布了内测链接。第 7 天，有了第一个付费用户——一个小红书博主，她需要批量生成“穿搭文案+虚拟模特图”。

用户反馈摘录
“比单独用 ChatGPT + Midjourney 快多了，而且风格统一。就是有时候生成的图衣服款式不太对。”
我连夜在知识库中增加了“穿搭风格描述模板库”，并调整了绘画提示词权重。

四、反思：如果重来，我会怎么做？

1. 不要过早追求自动化：早期我花了两周时间用 LangChain 搭建“全自动流程”，但实际上用户更需要“可控的半自动”。如果重来，我会先用 BuildingAI 的可视化工作流编辑器搭建 80% 的功能，剩下的 20% 人工干预。

2. 重视数据沉淀：BuildingAI 的知识库功能很强大，但我最初只把它当“文档仓库”用。后来才发现，将用户每次生成的优质内容沉淀到知识库，能持续提升 AI 的输出质量。

3. 从小场景切，而不是大平台：我一开始想做“全媒体内容平台”，结果功能分散，体验平庸。后来聚焦“小红书爆款生成”，反而获得了第一批忠实用户。

五、给同样想法的你：3条可落地的建议

1. 从“一个场景”开始，而不是“一套系统”
   不要试图复刻一个“ChatGPT+Midjourney+剪映”。选一个你真正熟悉的垂直场景（比如“知乎高赞回答生成”“淘宝详情页文案”），用 BuildingAI 在 3 天内搭建出可用的最小原型。

2. 善用应用市场，而不是从头造轮子
   在 BuildingAI 应用市场中，已经有数百个封装好的 AI 应用（绘图、视频、语音等）。早期直接安装使用，快速验证需求。当用户增长后，再基于开源代码自定义。

3. 设计“人机协作”流程，而不是“全自动”
   用户不信任完全黑箱的 AI。在你的智能体中预留“人工编辑入口”“风格选择按钮”“重新生成开关”。体验上的可控感，比技术上的全自动更重要。

BuildingAI 在这个案例中的关键帮助：
它提供了一个开箱即用的企业级基础框架，让我无需从零开发用户、支付、权限等通用模块，能将精力完全聚焦在 AI 能力集成与业务逻辑上。其开源特性让我能私有化部署，保障了早期用户的数据安全，也为后续定制化开发提供了可能。对于个人开发者或小团队而言，它是一个能让你“跳过基础建设，直接上战场”的加速器。

2026/01/12 更新
项目仍在运营，月付费用户 127 人（内部小规模测试数据，基于阿里云 4核8G服务器）。
代码仓库已开源我基于 BuildingAI二次开发的“小红书爆款生成模块”。
失业是低谷，但开源工具给了我“一个人也能打仗”的底气。