ChatJS：把聊天機器人的基礎設施先做完，再談你的產品差異
Production-ready AI chat. Start here and make it your own. Formerly Sparka AI
秒懂
- 它是什麼？
- ChatJS 是一個以 Next.js 與 AI SDK 為底、Apache-2.0 授權的 AI 聊天起點專案，內建驗證、多模型閘道、串流續傳與工具呼叫。它的價值在於省下重複搭建的工，代價是你得接受它對 Vercel 生態與 PostgreSQL、Redis 的整套假設。
- 適合誰用？
- 如果你要的是一個已經接好驗證、多模型閘道、附件、分支與分享的聊天殼，並且願意把資料放在 PostgreSQL 加 Redis、部署在 Vercel 生態上，ChatJS 可以省下數週的鋪路工作。若你的核心價值在推論層或資料層，或你無法接受它的儲存與部署假設，直接用 AI SDK 自己寫一層會更省事。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它想省掉的是「每個人都會重寫一遍」的那一層
做過 AI 聊天產品的人都知道，真正花時間的從來不是呼叫模型。串流要處理中斷與重連，對話要能分支與分享，附件要上傳、解析、塞進 context，驗證要接第三方登入又不能強迫註冊，模型供應商要能在 Claude、GPT、Gemini、Grok 之間切換。這些東西每一項都不難，全部加起來就是好幾週。
ChatJS 的定位就是把這一層先做完。README 開頭寫得很直白：Stop rebuilding the same AI chat infrastructure。它的目標讀者不是要研究 LLM 推論的人，而是已經知道自己產品要長什麼樣、只差一個能跑的聊天底座的團隊。專案前身叫 Sparka AI，現在以 monorepo 形式維護，apps/chat 是聊天應用本體，apps/site 是官網，apps/docs 是文件，packages/cli 是互動式腳手架。
值得注意的是它把「120+ 模型」放在功能列表第一條。這個數字來自 Vercel AI Gateway，不是 ChatJS 自己維運的推論服務。理解這一點很重要：ChatJS 是路由與應用的層，模型可用性取決於閘道，不是這個專案。
多模型不是抽象層，是 AI SDK 加閘道的組合
ChatJS 的技術棧寫得很完整，而且幾乎沒有自製輪子。Next.js App Router 與 React Server Components 負責渲染，AI SDK 負責模型呼叫與串流，Vercel AI Gateway 提供統一的多供應商入口，Better Auth 處理 GitHub、Google 與匿名登入，Drizzle ORM 對 PostgreSQL 做型別化查詢，Redis 負責快取與可續傳串流，Vercel Blob 存附件。tRPC 與 Zod 顧前後端契約，Zustand 顧前端狀態。
資料流大致是這樣：使用者送出訊息，前端透過 tRPC 打到 Next.js 的 route handler，AI SDK 以串流方式向 AI Gateway 請求，回應以 chunk 形式回推前端；Redis 在這個過程中保存串流狀態，所以 README 才敢說 Resumable Streams，重新整理頁面後生成可以接續。附件走 Vercel Blob，對話與分支關係落在 PostgreSQL。
這個架構的意涵是：它把「可續傳」當成基礎設施問題而不是前端問題。串流狀態離開瀏覽器記憶體、進到 Redis，才可能跨頁面存活。反過來說，Redis 不在你的部署清單裡，這個功能就不成立。
工具能力方面，README 列出網頁搜尋、圖片生成、沙箱程式執行與 MCP 支援。這些是 AI SDK 生態既有的能力被接進來，ChatJS 提供的是把它們掛進聊天介面的那層整合。
從 CLI 開始，然後被 chat.config.ts 決定你能用什麼
啟動方式只有一行：
npx @chat-js/cli@latest create my-app
根據 README，這個 CLI 會依序問你 gateway、功能與驗證方式的選擇，產生 chat.config.ts，最後列出你的選擇所對應的環境變數。這個順序值得留意：設定檔是產物，不是你先寫好的東西，環境變數清單則由選擇推導出來。
本地開發用 bun 系列指令。bun dev 跑聊天應用，bun dev:docs 跑文件，bun lint 做全 workspace 檢查，bun test:types 跑聊天應用的型別檢查。
有一個容易踩到的細節：README 明確要求在 .env.worktree.local 設定 CHATJS_DEV_SLOT，為每個 worktree 保留連續十個埠。在這個區間裡，chat 用 offset 0、Electron 用 offset 1、site 用 offset 2，實際配置寫在 .worktree-env.json。這個檔案被 Git 忽略，並且與 Vercel 管理的 .env.local 分開。README 的建議是直接跑 bun dev:info 查這個 worktree 被指派的網址，不要自己猜埠號。多 worktree 並行開發的團隊會感謝這個設計，單一 checkout 的人則會覺得多一層設定負擔。
發佈流程由 Changesets 驅動：每個要發佈的套件加一個 changeset，合併版本 PR，公開套件如 @chat-js/cli 推到 npm，桌面安裝檔則走 GitHub Releases。
桌面打包與匿名登入是兩個容易被低估的設計選擇
功能列表裡有兩項值得單獨看。第一是 Electron 桌面應用，README 說可以把專案打包成 macOS、Windows 或 Linux 原生應用。這件事在架構上不是附贈品：它解釋了為什麼開發埠配置要為 Electron 保留一個 offset，也意味著你的聊天應用可能同時存在瀏覽器與桌面兩個執行環境。如果你的產品完全不需要桌面版，這部分對你只是多出來的建置負擔。
第二是匿名登入。Better Auth 支援 GitHub、Google 與匿名三種方式，README 用 Ready to go 形容。匿名登入對聊天類產品的實際意義是降低首次使用門檻，但同時把身分與資料歸屬的問題丟回給你：匿名使用者的對話要保存多久、之後綁定帳號時怎麼合併、分享連結如何避免被當成公開資料。這些 README 沒有回答，屬於你要自己決定的產品層問題。
可觀測性方面，專案選了 Langfuse 做 LLM 追蹤與分析，Pino 做結構化日誌，Vercel Analytics 做網頁分析。三者分工清楚，但也都指向同一個方向：這個專案預設你會在 Vercel 上跑。
限制一：它預設了一整套基礎設施，換掉等於換掉骨架
ChatJS 最實際的限制不是功能缺什麼，而是它對環境的假設有多深。PostgreSQL 是主資料庫，Redis 負責快取與可續傳串流，Vercel Blob 存附件，AI Gateway 提供模型，Better Auth 管身分，Drizzle 管存取。這六項不是可選配件，而是彼此咬合的骨架。
想換掉其中一項，成本並不對稱。把 Vercel Blob 換成 S3 相對單純，因為它只是儲存端點。把 Redis 拿掉就會直接失去可續傳串流，因為那正是這個功能得以成立的地方。把 AI Gateway 換成自己直連各家 API，你要接手的是金鑰管理、額度、供應商差異與錯誤處理，那已經接近重寫一個閘道層。
還有一個容易被忽略的訊號：README 的功能列表全部沒有標註哪些是穩定、哪些是實驗性。MCP 支援、程式碼沙箱、圖片生成這幾項在生態裡都還在變動，把它們當成可以依賴的生產功能之前，應該先到 apps/chat 對應的程式碼確認實作深度。
最後是維護節奏。從 release 記錄看，@chat-js/cli 在 2026 年 5 月、7 月、9 月各有一次發佈，大約兩個月一個節奏，屬於穩定推進而非高頻迭代。這對採用者是好事，但也意味著你不該期待上游很快追上每個供應商的新 API。
限制二：你繼承的是一個完整的全端應用，不是一個可抽換的套件
很多人看到「start here and make it your own」會理解成套件，實際上 ChatJS 是一個 monorepo 形式的應用模板。CLI 產生的是一個完整的 Next.js 專案，不是一個可以 import 進既有系統的 library。
這個差別在整合時會立刻顯現。如果你已經有一個跑得好好的後端與資料庫，ChatJS 不會幫你接上去，它會要你接受它的 Drizzle schema 與 tRPC 路由。反過來說，如果你要的正是從零開始的一個新產品，這個「什麼都給你」的做法就是它的核心價值。
另一個結構性事實是技術棧的耦合方向。Next.js App Router、React Server Components、AI SDK、tRPC、Drizzle 這一串都是 TypeScript 生態裡相對年輕且變動頻繁的選擇。ChatJS 把這些全部綁在一起，等於把上游的 breaking change 風險也一起承接下來。這不是缺陷，是這類模板的固有代價，採用前應該把它算進維護預算。
至於授權，專案採 Apache-2.0。這通常意味著你可以商用、可以修改、可以閉源散布，但具體的專利授權條款、商標使用與再散布時的聲明義務，仍應由你自己的法務確認，本文不構成法律意見。
對照組：Vercel AI Chatbot 與自己用 AI SDK 拼一層
最直接的同類是 Vercel 官方的 AI Chatbot 模板。兩者都建立在 Next.js 與 AI SDK 上，都提供聊天介面、串流與多模型支援，也都預設部署在 Vercel。差異在取捨方向。
官方模板的範圍較窄，重點是把聊天這件事做對；ChatJS 的範圍明顯更寬，把分支、分享、網頁搜尋、圖片生成、程式碼沙箱、MCP 與 Electron 桌面打包都納進來，並且用一個互動式 CLI 把 gateway、功能與驗證方式的選擇固化成 chat.config.ts。換句話說，ChatJS 賣的是「選項已經幫你決定好一部分」的整合度，代價是它替你做的決定比較多。
另一條路是完全不採用模板，直接用 AI SDK 自己寫。這條路的成本曲線是反過來的：前期慢，因為驗證、附件、串流續傳、資料庫 schema 都要自己來；後期輕，因為每一層都是你寫的，沒有需要對齊的上游。如果你的產品核心在推論層、在資料模型、或在你打算做一個跟一般聊天介面很不一樣的互動方式，這條路通常更划算。
判斷方式可以很簡單：把 README 的功能列表逐項問「這一項拿掉我的產品還成立嗎」。如果多數答案是不成立，ChatJS 幫你省下的就是實打實的工；如果多數答案是可有可無，你付的是整合稅。
編輯結論
如果你要的是一個已經接好驗證、多模型閘道、附件、分支與分享的聊天殼，並且願意把資料放在 PostgreSQL 加 Redis、部署在 Vercel 生態上，ChatJS 可以省下數週的鋪路工作。若你的核心價值在推論層或資料層，或你無法接受它的儲存與部署假設，直接用 AI SDK 自己寫一層會更省事。動手前先跑 npx @chat-js/cli@latest create，把產生的 chat.config.ts 與環境變數清單讀完，再確認 apps/chat 的 Drizzle schema 是否對得上你既有的資料庫，這兩件事決定你要改的是設定還是架構。
社群筆記