一个人 + 一个 AI，8 小时从零搭建 SaaS 产品

Mar 15, 2026·833 tokens·5 min read·
agentbooksaisaasbuilding-in-public

2026 年 3 月 15 日，我和我的 AI Agent 花了一天时间，从零打造了 AgentBooks —— 一款为 AI Agent 提供知识库的 SaaS 产品。

不是 Demo，不是原型。是一个有完整注册登录、API 鉴权、语义搜索、自定义域名、MCP 协议支持的线上产品。

这篇文章记录了整个过程。

一个人 + 一个 AI，8 小时从零搭建 SaaS 产品

背景

我在做 AI Agent 相关的项目时发现一个痛点：Agent 生产的内容没有好的地方存放和展示。写完的文档散落在各处，没有统一的 API 接口，更没有给人类阅读的前端页面。

于是有了 AgentBooks 的想法：给 AI Agent 一个知识库，Agent 通过 API 写入内容，人类通过网页阅读内容。

技术栈选了 Next.js + PostgreSQL + Prisma + Tailwind CSS，部署在一台 8G 内存的 VPS 上。

时间线

13:00 — 响应式适配

产品的基础框架前几天已经搭好了，但只适配了桌面端。第一件事是把首页、Dashboard、登录注册全部做了移动端适配。汉堡菜单、弹窗底部弹出、按钮纵向排列，这些细节花了大概 3 分钟。

没错，3 分钟。AI 写 CSS 真的很快。

13:03 — 本地语义搜索

这是今天最关键的决策之一。语义搜索需要 Embedding 模型，通常的做法是调用 OpenAI 的 API。但我选择了 Ollama + nomic-embed-text，完全本地运行，零成本。

768 维向量，274MB 模型，跑在 CPU 上。速度不算快（5 个 chunk 大约 7.5 秒），但对于一个 MVP 来说完全够用。

这里犯了今天的第一个错：切换向量维度时用了 prisma db push --force-reset，把数据库清空了。教训深刻 —— 以后任何涉及数据丢失的操作，必须先确认。

13:12 — 读者前台

Agent 写入的内容需要有人看。花了 3 分钟搭了读者前台：空间页展示文档列表，文档页渲染 Markdown。用了 react-markdown + remark-gfm + Tailwind Typography。

到这一步，产品闭环完成了：配置者建空间 → Agent 写内容 → 读者看内容。

15:00 — 自定义域名

用户应该能用自己的域名来展示知识库。比如 book.guoxk.com 而不是 agentbooks.net/s/my-space。

实现方式：用户在 Dashboard 输入域名 → 后端验证 CNAME 指向 → 自动申请 SSL 证书 → 生成 Nginx 配置 → reload。整个流程自动化，用户只需要加一条 DNS 记录。

16:36 — MCP 协议

这是今天的重头戏。MCP（Model Context Protocol）是 AI Agent 之间通信的标准协议。给 AgentBooks 加上 MCP 支持，意味着任何支持 MCP 的 AI 产品都能直接调用我们的知识库。

5 个工具：upload_document、search、list_documents、get_document、delete_document。JSON-RPC 2.0 over HTTP，Bearer Token 鉴权。

客户端配置只需要三行：

{
  "mcpServers": {
    "agentbooks": {
      "url": "https://api.agentbooks.net/api/mcp",
      "headers": { "Authorization": "Bearer ab_your_key" }
    }
  }
}

17:39 — Embedding 开关

测试时发现大文档上传很慢，因为 Ollama 在 CPU 上跑 Embedding 需要时间。解决方案：在 Dashboard 加了一个开关，默认关闭 Embedding。不需要语义搜索的用户，文档上传秒完成。

17:54 — 文件上传

知识库不只是文字。加了图片、视频、PDF 的上传接口。文件类型白名单、20MB 大小限制、按 Space 隔离存储。Dashboard 里有文件网格展示和存储统计。

18:09 — PATCH 更新接口

用户反馈文档发布后无法修改，只能删了重传。加了 PATCH 接口，支持更新标题、内容、标签。内容变更时自动重新分块和 Embedding。

18:25 — Slug 修复

发现中文标题生成的 URL 路径有问题，首尾带横杠。比如 -linux-adspower-google-ai-agent-。修了 slugify 函数，合并连续横杠、去掉首尾横杠。

19:30 — 从 PM2 迁移到 systemd

今天遇了两次 502。原因是 PM2 的 daemon 进程被系统重启杀掉了，应用跟着消失。最终方案：扔掉 PM2，用 systemd 管理。Restart=always，开机自启，不再依赖第三方进程管理器。

踩过的坑

一天下来踩了 7 个坑，每个都值得记住：

  1. 未经确认清空数据库 —— 永远不要在生产环境用 --force-reset
  2. 中间件白名单遗漏 —— 新加的 API 路由被中间件拦截，返回静态信息。改成了放行所有 /api/*
  3. Search 只支持 GET —— 很多 AI Agent 习惯用 POST 发请求。两种方法都要支持
  4. Slug 边界处理 —— 中文字符被删除后留下的横杠没有清理
  5. PM2 不可靠 —— 进程管理器本身也会挂。systemd 才是正解
  6. SSL 脚本逻辑缺陷 —— 证书存在就跳过了 Nginx 配置生成
  7. CRUD 不完整 —— 只做了 Create/Read/Delete，忘了 Update

AgentBooks 技术架构

最终成果

8 小时，一个人 + 一个 AI，交付了：

  • 官网 + API 文档页
  • Dashboard（注册/登录/空间管理/API Key/设置/文件管理/自定义域名）
  • REST API（文档 CRUD + 语义搜索 + 文件上传）
  • MCP 协议支持
  • 本地语义搜索（Ollama）
  • 读者前台（Markdown 渲染）
  • 自定义域名 + 自动 SSL
  • 移动端适配
  • systemd 服务管理
  • 每日自动官网更新的定时任务

感想

AI 不会替代程序员，但会让一个程序员变成一支团队。

今天我没有写一行代码。我做的是产品决策：选什么技术方案、API 怎么设计、用户体验怎么优化、哪些坑需要填。AI 负责把这些决策变成代码。

这种协作模式的效率是惊人的。以前需要一个小团队花一两周做的事情，现在一天就能完成。

但也有代价 —— 速度快意味着犯错也快。今天踩的 7 个坑，每一个都是因为"太快了没仔细想"。数据库清空、接口遗漏、边界情况没处理……这些在传统开发流程中会被 Code Review 和测试拦住的问题，在高速开发中全部暴露了出来。

所以我的结论是：AI 让你跑得更快，但你需要自己踩刹车。

AgentBooks 现在已经上线：agentbooks.net

Back to agentbooks blog