Typebot：把「对话」变成可拖拽的积木

想象你要给公司做一个报名页。传统做法是：产品经理画流程图，工程师用代码实现分支逻辑，运营提一次需求就得排一次期。Typebot 想把这个链路压缩成一次拖拽——你在画布上摆出气泡、输入框、条件分支，保存后立刻得到一个能嵌进官网的聊天窗口，还能把用户填的内容以表格形式收回来。

Typebot 由法国独立开发者 Baptiste Arno 于 2021 年 11 月创建，目前在 GitHub 收获 10593 星、3245 个 fork，累计提交约 3923 次，贡献者 89 人。它不是「大模型套壳」，而是一个 对话式表单与流程编排平台：AI 是它的一个可选积木，而不是全部。

图：Typebot 仓库主页横幅（图片已本地化）

它长什么样

Typebot 的核心是 Builder（构建器）和 Viewer（播放器）两个 Next.js 应用。Builder 左侧是积木列表，中间是画布，右侧是属性面板；Viewer 则是真正对终端用户展示的聊天界面，可以独立部署到子域名，用原生 JS 嵌入脚本以气泡或弹窗形式挂到任意页面——不走 iframe，因此没有跨域和性能损耗。

积木分四类：气泡（文本、图片、GIF、视频、音频、嵌入）、输入（文本、邮箱、电话、按钮、日期、文件上传、Stripe 支付）、逻辑（条件分支、跳转、JavaScript 脚本、A/B 测试）、集成（Webhook、HTTP 请求、OpenAI、Google Sheets、Analytics、Zapier 等）。官方称积木总数超过 34 个。

图：输入类积木（文本、邮箱、按钮、日期、支付等）

技术上是怎么搭的

仓库是一个 bun + Nx 驱动的 monorepo，5400 个文件，40 余个 packages 包，代码以 TypeScript 为主（code_profile 中 TypeScript 约 5.2MB 字节量，占绝对主导）。关键结构：

• apps/：builder、viewer、docs、landing-page、workflows 五个应用
• packages/blocks/：base、bubbles、core、fileInput、inputs、integrations、logic、webhook 八类积木的 schema 与实现
• packages/forge/blocks/：第三方积木生态，含 anthropic、openai、deepseek、groq、mistral、perplexity、togetherAi、openRouter、difyAi、elevenlabs、gmail、nocodb、segment、posthog、zendesk、calCom、qrcode 等
• packages/ai/：统一的模型调用层，底层用 Vercel AI SDK（ai@^5.0.52），配合 zod schema 做工具调用与结构化输出
• packages/prisma/：PostgreSQL / MySQL 双 schema 与迁移脚本
• packages/bot-engine、chat-api、chat-session、embeds、whatsapp：运行时、聊天接口、会话存储、嵌入 SDK 与 WhatsApp 渠道

图：OpenAI 积木配置界面

工程规范也相当完整：113 个单元测试文件（bun test），另有 Playwright 端到端测试覆盖鉴权跳转、webhook 鉴权、预览会话隔离、WhatsApp 会话访问等场景；pre-commit 钩子会跑 format-and-lint、lint-repo、check-broken-links、test、generate-openapi 等多目标任务；代码库还内置了 .claude / .codex / .agents 等 AI 协作配置目录。

部署可行性

容器化：满分。 仓库提供多阶段 Dockerfile（bun 依赖层 → Prisma 生产依赖 → Next.js standalone 运行时），并锁定 Node 24.22.1 以修复 CVE-2026-111497；docker-compose.yml 直接编排 postgres:16、redis:alpine、typebot-builder、typebot-viewer 四个服务，数据库与 Redis 均带 healthcheck，数据落在命名卷里。

上手门槛：低。 官方文档给出三行命令的路径：下载 compose 文件与 .env.example，改好 DATABASE_URL 与 ENCRYPTION_SECRET，然后 docker-compose up -d。Builder 起在 8080、Viewer 起在 8081，迁移自动执行。需要注意两点：一是服务本身只跑明文 HTTP，正式环境必须自己加 Nginx / Traefik 反代做 TLS；二是自托管版本按 LTS 节奏发布，每月同步一次经过云端验证的更新，想第一时间拿新功能得用官方云服务。

硬件需求：纯 CPU 应用，无 GPU 依赖。2 核 4GB 内存、10GB 磁盘起步比较稳妥——Postgres、Redis、两个 Node 应用同时跑，1GB 内存会偏紧。

图：Typebot Viewer 端到端预览效果

争议与局限

许可证是最大的争议点。 Typebot 用的是 Functional Source License 1.1（FSL-1.1-Apache-2.0），不是 OSI 认可的「开源」许可：你可以自由使用、修改、商用、分发，但两年内不能把该版本作为竞争性 SaaS 对外提供，届时才转为 Apache 2.0。README 的徽章写着 AGPLv3，与仓库根目录 LICENSE 文件的实际内容并不一致——这是 GitHub API 返回 NOASSERTION 的原因。官方自己反复强调「Fair Source」而非「open source」，并把云订阅收入作为项目主要资金来源。这个模式对自建团队完全友好，但对想二次封装成 SaaS 的创业者是硬约束。

复杂度偏高。 5400 个文件、40+ 包的 monorepo，fork 起来的维护成本不低；想深度定制需要熟悉 Nx、bun、Next.js、Prisma 这一整套。另外它不是「开箱即用的 AI 客服」——OpenAI/Anthropic 等模型接入是可选积木，要做语义理解仍需自己配 API Key、提示词和知识库。

行业意义

Typebot 代表了开源 AI 应用的一种务实路线：不与商业平台在模型能力上正面竞争，而是把对话流程抽象成一套可复用的积木 DSL，把「AI 接入」降级为其中一个标准积木。这让中小团队不必写编排代码，就能拿到多渠道嵌入、结构化结果回收和基本的模型调用能力。10593 星、3245 fork、89 位贡献者的体量，说明「可视化 + 可自托管 + 不锁定供应商」这三点组合仍然有明确的市场缺口。

对想做 AI 应用落地的团队来说，Typebot 值得作为流程编排层被评估——但要先想清楚 FSL 两年窗口期是否与你的商业模式冲突。