Dyad：在本地跑 AI 應用產生器，但授權與專案狀態要先看清楚
Local, open-source AI app builder for power users ✨ v0 / Lovable / Replit / Bolt alternative 🌟 Star if you like it!
秒懂
- 它是什麼？
- Dyad 是一款主打本地執行、自帶 API key 的 AI 應用程式建置工具，定位類似 Lovable、v0 或 Bolt。本文從 README 與 repository 可見的資訊，拆解它的運作方式、安裝路徑、授權分割，以及採用前必須確認的幾個關鍵點。
- 適合誰用？
- Dyad 適合想要在本地環境快速生成 React 或 TypeScript 應用原型、且不希望把程式碼或 API key 交給雲端服務的開發者。它不適合需要完整開源授權、想直接修改 src/pro 目錄內功能、或依賴商業支援的團隊。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決什麼問題：本地 AI 應用產生器的定位
Dyad 宣稱是「local, open-source AI app builder」，目標是讓使用者在自己的機器上，用自然語言描述需求，然後產生完整的應用程式。它的對照組是 Lovable、v0、Replit 或 Bolt，這些服務通常以雲端為主，使用者必須把程式碼或提示詞送上別人的伺服器。Dyad 的賣點在於「本地」與「帶自己的 key」，也就是說，你使用自己的 AI API key，例如 OpenAI、Anthropic、DeepSeek 或 Ollama 這類本地模型服務，資料與產出都不經過 Dyad 的伺服器。這對看重隱私、或不想被單一雲端廠商綁住的開發者來說，是具體的誘因。README 的描述很直接：「fast, private, and fully under your control」，沒有含糊的承諾。但要注意，它沒有提到支援的模型清單或 API 格式細節，實際能接哪些服務，需要從原始碼或文件進一步確認。
架構與資料流：從 repository 佈局推測的運作方式
從 repository 的 topics 與主要語言來看，Dyad 是 TypeScript 專案，且 topics 包含 nextjs、react、typescript，這暗示它的前端或產生器本身可能以 React 生態系為基礎。README 沒有提供架構圖，但從目錄結構可以推測，src/pro 目錄是付費或 fair-source 功能所在，其餘程式碼則以 Apache 2.0 授權。這表示 Dyad 採用雙重授權策略：核心功能開放，但某些進階功能（可能與商業化有關）保留在 src/pro 內。資料流方面，既然強調「bring your own keys」，合理推測是使用者輸入提示詞後，Dyad 直接呼叫你設定的 API，取得回應後再轉換成應用程式骨架或檔案。但文件沒有說明它是否使用特定框架如 Next.js 來產生專案，或者是否支援匯出成獨立專案。這些細節只能從實際安裝或閱讀原始碼得知，目前無法從 README 確認。
安裝與執行：下載即用，但無指令細節
README 的安裝說明非常簡短：「No sign-up required. Just download and go.」並提供網站 dyad.sh 的下載連結。它沒有提供 npm install、git clone 或任何 CLI 指令，這點與多數開源專案不同。對於工程師來說，缺少指令安裝方式可能意味著 Dyad 是以桌面應用程式形式發行，而非單純的 CLI 工具。它標榜「Cross-platform: Easy to run on Mac or Windows」，但沒有提及 Linux。若要從原始碼建置，使用者需要自行 clone repository，但 README 沒有提供建置步驟。這是一個明顯的資訊缺口：如果你習慣用指令列操作，或需要自動化安裝，Dyad 目前的文件並不友善。實際執行方式，只能靠下載對應平台的執行檔，或者等待社群補充文件。
授權分割：Apache 2.0 與 Functional Source License 的界線
Dyad 的授權策略值得仔細看。README 明確指出，repository 內 src/pro 以外的程式碼採用 Apache 2.0，而 src/pro 目錄內則採用 Functional Source License 1.1（FSL）。FSL 並非 OSI 認證的開源授權，它屬於「fair-source」概念，允許使用與修改，但在特定條件下限制商業使用或再散佈。repository 的 license 欄位標示為 NOASSERTION，這在 GitHub 上表示作者未明確設定單一授權，可能是因為雙重授權導致無法用單一標籤表示。對採用者而言，這代表你不能把整個專案視為純 Apache 2.0。若你想修改或整合 Dyad 的功能，必須先確認你使用的部分是否落在 src/pro 內。這不是法律建議，但實際的風險是：如果你只看到 Apache 2.0 就放心使用，可能誤用 src/pro 的程式碼而違反 FSL 條款。
限制與誤用情境：什麼時候 Dyad 不是對的工具
Dyad 有幾個潛在限制，來自文件本身的沉默。第一，它沒有提到支援的模型清單或 API 端點格式，如果你使用的是 Ollama 這類本地模型，可能需要自己設定相容的 API 位址，但文件沒有給範例。第二，它宣稱「no lock-in」，但實際上你依賴 Dyad 的產生邏輯，如果產生的程式碼品質不佳，你還是得手動修改，這與任何 AI 工具相同。第三，它不支援 Linux，這對伺服器端或容器化開發是致命傷。第四，它的版本號 v1.14.0 顯示仍在快速迭代，但沒有提到向後相容性承諾，升級可能破壞既有專案。如果你需要的是可程式化的 CLI 工具，或需要整合進 CI/CD 流程，Dyad 目前的下載即用模式可能不適合。它更偏向互動式 GUI 工具，而非自動化元件。
替代方案：與 Bolt、v0 的本質差異
Dyad 的直接替代品是 Bolt、v0 或 Lovable，但這些大多是雲端服務。真正的差異在於部署位置與 key 管理：Bolt 或 v0 通常要求你把程式碼送到他們的伺服器，並使用他們提供的模型配額或你自己的 key，但資料仍經過第三方。Dyad 的本地執行意味著你掌控整個流程，但同時也喪失雲端服務的便利性，例如自動備份、協作功能或預建基礎設施。另一個替代方案是直接使用開源專案如 Bolt.new 的開源版，但 Bolt.new 本身也有雲端與本地差異。Dyad 的優勢在於它明確定位為本地優先，而 Bolt 等工具則以雲端為主要介面。若你重視資料隱私，Dyad 是更直接的選擇；若你重視協作與無痛部署，雲端工具仍較成熟。
維護與升級成本：活躍但未穩定的訊號
從 repository 的活動來看，最後一次 push 是 2026 年 9 月 9 日，且 v1.14.0 於同日發布，顯示專案仍在積極開發。版本號的快速推進（beta 到正式版間隔僅數天）暗示功能迭代頻繁，但這也意味著 API 或行為可能隨時變動。維護成本體現在幾個層面：首先，你必須追蹤每次 release 的變更，因為沒有 LTS 或穩定分支的承諾；其次，由於授權分割，升級時你無法簡單地用 git pull 取代整個目錄，因為 src/pro 的功能可能與核心版本綁定，但授權限制可能禁止你在某些情境下更新。文件沒有提供遷移指南或升級說明，這對長期採用者是個風險。若你打算將 Dyad 整合進商業產品，必須先確認 src/pro 的 FSL 條款是否允許你的使用情境。
編輯結論
Dyad 適合想要在本地環境快速生成 React 或 TypeScript 應用原型、且不希望把程式碼或 API key 交給雲端服務的開發者。它不適合需要完整開源授權、想直接修改 src/pro 目錄內功能、或依賴商業支援的團隊。採用前，請先確認你下載的版本是否包含 src/pro 目錄，並閱讀該目錄下的 LICENSE 檔案，理解 Functional Source License 1.1 對使用與再散佈的限制。同時，由於 repository 的 license 欄位標示為 NOASSERTION，且最後一次 push 是 2026 年 9 月，專案仍持續更新，但版本號 v1.14.0 顯示功能尚未穩定，建議先在隔離環境測試，再決定是否納入日常工作流程。
社群筆記