AIaW 已封存：一個 local-first AI 客戶端在被 Nya AI 取代前的技術全貌
AI as Workspace - An elegant AI chat client. Full-featured, lightweight. Support multiple workspaces, plugin system, cross-platform, local first + real-time cloud sync, Artifacts, MCP | 更好的 AI 客户端
秒懂
- 它是什麼？
- AIaW 以 Quasar 與 TypeScript 打造跨平台 AI 聊天客戶端，主打本地優先儲存、多工作區、MCP 與外掛系統。README 已明確標示專案棄用並由 Nya AI 接手，本文拆解它的機制、啟動方式與採用判斷。
- 適合誰用？
- 若你已在自架 AIaW 並依賴其工作區與外掛生態，繼續使用可行，但升級路徑只有一條：依 docs.aiaw.app/migration/ 轉往 Nya AI，因為 v1.8.10 的版本標題已寫明 Migrating to Nya AI。若你是新評估者，不建議從這個 repo 起步，直接看 Nya AI 的技術棧更省事。
- 可以商用嗎？
- 可以。BSD-3-Clause 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 121 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
AIaW 想解決的是把對話綁在瀏覽器分頁上的問題
多數人用 AI 的方式是開一個網頁、登入、開始問。對話留在供應商的伺服器上，換裝置要重新登入，換模型要重開一個分頁，提示詞每次重打。AIaW 針對的正是這一段：把對話、助手、提示詞變數與附件收進使用者自己控制的儲存層，再往上疊一個跨平台的介面。README 對目標族群的描述很直接，支援 Windows、Linux、Mac OS、Android 與 Web（PWA），並且把「資料本地優先儲存，離線可用、載入即時」列為資料儲存章節的第一條。
它同時支援多個供應商，README 點名 OpenAI、Anthropic、Google、DeepSeek、xAI、Azure 等。這代表使用者的訴求不是「用某一家模型」，而是「用同一個工作區介面切換模型」。多工作區的設計進一步把對話按主題分開，工作區還可放進可嵌套的資料夾，助手則可存在單一工作區內或設為全域。這一層組織方式，是它與單純聊天頁面最大的差別。
本地優先加上登入後同步，資料流的兩段式設計
README 把資料儲存拆成兩件事：本地優先，以及登入後的雲端同步。前者保證離線可用與即時載入，後者處理跨裝置。這種順序意味著讀寫的主要路徑不經過伺服器，同步是附加層。
同一章節還提到多視窗協作：在同一個瀏覽器開多個分頁時，資料會即時同步。這是一個容易被忽略但實際影響使用方式的機制，因為它讓「左邊開一個工作區、右邊開另一個」變成可行的工作流，而不必擔心兩邊的狀態互相覆蓋。
需要說清楚的是，README 沒有交代同步的衝突解決策略，也沒有說明資料以什麼格式落地、儲存在哪個路徑。這些在自架情境下是會直接影響備份與遷移決策的細節，文件層級只到功能描述，沒有到實作描述。如果你的場景需要對資料落地位置有明確掌握，這一點必須自己去翻程式碼或自架文件確認。
MCP、外掛與 Artifacts 是三個不同層次的擴充點
這三個功能常被混為一談，但 README 把它們放在不同章節，職責也不同。
MCP 章節說明支援 Tools、Prompts、Resources 三類，連線方式有 STDIO 與 HTTP 兩種，可以從外掛市集安裝 MCP 類型的外掛，或手動加入 MCP server。這裡的關鍵是協定層的相容性，而不是這個客戶端自己發明了什麼。
外掛章節則列出內建的計算機、文件解析、影片解析、圖像生成外掛，可從市集安裝更多，也能把 Gradio 應用設為外掛，並註明相容部分 LobeChat 外掛。README 特別寫了一句「外掛不只是工具呼叫」，這句話值得停下來看，因為它暗示外掛能觸及的不只 function calling 這一條路徑，但文件沒有展開具體還能做什麼。
Artifacts 是另一個層次：可以把助手回應的任何部分轉成 Artifact，使用者可編輯，帶版本控制與程式碼高亮，並能控制助手對 Artifact 的讀寫權限，同時開啟多個。這比較接近「把回應變成可持續編輯的產物」，而不是單純的訊息呈現。
這三者的組合是 AIaW 最有辨識度的部分，也是遷移到 Nya AI 時最需要逐項核對的部分，因為 README 只承諾新專案提供「大部分功能與一致體驗」，並沒有逐條對應。
用 pnpm 與 quasar 把它跑起來
README 給的開發流程很短，全部基於 pnpm 與 Quasar CLI。安裝依賴：
pnpm i
開發模式，帶熱重載與錯誤回報：
quasar dev
檢查：
pnpm lint
正式建置分兩種模式，SPA 與 PWA：
quasar build
quasar build -m pwa
自架部署則指向 docs.aiaw.app/self-host/，README 本身沒有列出 Docker 或環境變數的細節，topics 裡有 docker 標籤，但實際設定要看自架文件。
這裡有一個實務上的判斷點：README 沒有列出任何環境變數名稱、設定檔路徑或資料目錄。對於一個主打 local-first 的客戶端，資料落地位置與備份方式是自架者最先要問的問題，而這些在 repo 首頁層級是空白的。要評估維運成本，必須先讀完自架文件再決定。
棄用狀態是這個專案目前最重要的事實
README 開頭有一段 WARNING，寫明專案已棄用，由 Nya AI 接手，後者是使用新技術棧的完整重寫，並提供這個專案的大部分功能與一致體驗，另加新功能與最佳化。既有使用者被導向 docs.aiaw.app/migration/。
版本紀錄也印證了這條線：v1.8.10 的標題直接寫著 Migrating to Nya AI，v1.8.11 與 v1.8.12 隨後發布。這代表最後幾個版本的工作重心已經轉向遷移，而不是功能擴張。
對於正在評估的人，這改變了整個判斷框架。你面對的不是「這個專案好不好」，而是「我願不願意現在投入一個已經宣告終點的程式碼庫」。BSD-3-Clause 授權讓 fork 與自行維護在法律上可行，但自行維護意味著承擔上游不再處理的安全性與相容性問題，包括 MCP 協定演進與各家模型 API 的變動。這不是授權問題，是人力問題。
與 LobeChat 這類工具的差異在哪裡
README 自己提到外掛系統「相容部分 LobeChat 外掛」，這等於承認兩者在擴充模型上有重疊。差別在於定位：LobeChat 這類專案以市集與外掛生態為主要賣點，而 AIaW 把自己描述為 lightweight，並在 Lightweight and High Performance 章節強調啟動不需等待、切換對話順暢。
這是一個明確的取捨。輕量的代價通常出現在功能廣度與生態規模上，而 AIaW 選擇用工作區、Artifacts、動態提示詞變數這些偏工作流的功能來補。動態提示詞變數的做法是用模板語法建立提示詞變數，並可把重複部分抽成工作區變數，這對需要維護一組固定提示詞的人比市集數量更有意義。
反過來說，如果你要的是大量現成外掛與社群整合，這個專案的取向並不對應那個需求，而它又已經棄用，比較的基準其實應該換成 Nya AI，而不是繼續拿它跟活躍專案對比。
什麼情況下它會是錯的工具
第一種情況是團隊協作。README 描述的是個人層級的資料儲存與跨裝置同步，多視窗協作講的是同一個瀏覽器內的多個分頁，不是多人共用同一份工作區。如果你的需求是團隊共享對話與權限管理，這個設計不對應。
第二種情況是需要穩定 API 或長期支援的整合。專案已棄用，最後的版本節奏也指向遷移，把生產系統綁在這裡等於接受一個不再演進的依賴。
第三種情況是對資料落地有硬性要求。local-first 聽起來符合資料自主，但 README 沒有說明實際儲存位置與格式，也沒有交代同步時的衝突處理。在合規或稽核情境下，「聽起來本地」不等於「可證明本地」，這個落差必須靠讀原始碼補上，而這對一個棄用專案是不划算的投入。
還有一種容易被忽略的情況：如果你的 MCP server 依賴較新的協定特性，README 只列出 Tools、Prompts、Resources 與 STDIO、HTTP 兩種連線方式，沒有承諾協定版本，相容性需要自行驗證。
編輯結論
若你已在自架 AIaW 並依賴其工作區與外掛生態，繼續使用可行，但升級路徑只有一條：依 docs.aiaw.app/migration/ 轉往 Nya AI，因為 v1.8.10 的版本標題已寫明 Migrating to Nya AI。若你是新評估者，不建議從這個 repo 起步，直接看 Nya AI 的技術棧更省事。若你只是想找一個可自架的 MCP 客戶端介面，先確認你的 MCP server 是 STDIO 還是 HTTP，再對照文件中的連線方式，這兩條路徑的設定差異決定了你能不能沿用現有腳本。
社群筆記