aidea-server：用 Go 自架一個同時接 GPT、通義千問與 Stable Diffusion 的後端
AIdea 是一款支持 GPT 以及国产大语言模型通义千问、文心一言等，支持 Stable Diffusion 文生图、图生图、 SDXL1.0、超分辨率、图片上色的全能型 APP。
秒懂
- 它是什麼？
- 這個專案把多家大語言模型與圖像生成模型收斂到同一組 API 後面，並附上相容 OpenAI 協議的端點。它的價值在於整合層，不在模型本身；採用前要先確認授權條款與部署相依的雲端服務。
- 適合誰用？
- 如果你需要一個現成的多模型後端，而且能接受它綁定阿里雲、騰訊雲、七牛等中國境內服務，aidea-server 可以省下大量接入工作；如果你只想接一兩家模型、或必須部署在沒有這些雲服務的環境，自己寫一層薄封裝會更乾淨。動手前先確認三件事：倉庫是否附帶 LICENSE 檔案（目前無法從資料中確認授權條款）、docs/deploy.md 列出的外部依賴你是否都拿得到、以及 config.yaml 與 coins-table.yaml 的必填欄位。
- 可以商用嗎？
- 未經許可不行。GitHub 在這個儲存庫中沒有找到授權檔案；沒有授權，預設即「保留所有權利」：你可以閱讀程式碼，但不能重複使用。使用前請看看 README，或先取得作者同意。
- 還在維護嗎？
- 活躍度在下降。儲存庫最近一次提交在 6 個月前。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是接入成本，不是模型能力
把 GPT、通義千問、文心一言放進同一個 App，麻煩的地方不在呼叫，而在每家模型的請求格式、串流回應格式、錯誤碼、計費單位都不一樣。aidea-server 的做法是在 pkg/ai/chat 定義一層抽象聊天介面，README 說明所有聊天模型都會被包裝成相容 OpenAI Chat Stream 協議的形式。也就是說，上層業務邏輯只認一種串流格式，供應商差異被壓在 pkg/ai 底下。
圖像這邊走同一條路。README 把 Stable Diffusion 文生圖、圖生圖、SDXL 1.0、超解析度、圖片上色列為能力範圍，而 202401311800 版釋出說明提到新增藝術字支援，由阿里雲錦書提供服務。可以看出它的定位是聚合層：自己不訓練模型，只負責把外部供應商的能力轉成統一介面。
這也決定了它適合誰。需要快速做一個多模型 App 後端、又不想逐家寫 SDK 的團隊，能直接受益。反之，如果你的需求只有一家模型、或你打算自己控制每一次請求的細節，這層抽象反而多一層要讀的程式碼。
Glacier 與 Eloquent：兩個自研框架決定了閱讀曲線
這個專案沒有用主流 Go 生態的框架。README 明說它建立在 Glacier Framework 上，這是一套自研的模組化應用開發框架，內建以 go-ioc 為基礎的依賴注入，用來解決依賴傳遞與模組化問題；資料層則用 mylxsw/eloquent，一套受 Laravel PHP 框架啟發、基於程式碼生成的 ORM，支援 MySQL 等資料庫。
對要改程式的人來說，這是第一個實際門檻。依賴注入的註冊方式、模組啟動順序、ORM 的模型定義與生成流程，都得照這兩套自研工具的文件走，社群裡能直接套用的範例比 Gin 加 GORM 那種組合少得多。好處是目錄切得相當清楚：api 放相容 OpenAI 協議的端點，server 放給 AIdea 客戶端用的端點，兩者分開，第三方軟體可以只接 api 這一側。
分層上，pkg/repo 封裝所有資料庫操作，pkg/service 放不屬於 Controller 也不屬於 Repo 的邏輯，internal/queue 定義非同步任務、internal/queue/consumer 放消費者，internal/payment 放支付實作，internal/coins 放定價與計費策略。README 對程式碼品質給了一句坦白話：註解與技術文件目前有限，之後會補。另外它提醒命名有歷史包袱，程式裡的 Room 與 Advisory Group 指的都是 Digital Persona，Creation Island 的 v1 與 v2 完全不同，v1 只服務到 App 1.0.1 版。讀原始碼前先知道這些，可以少繞很多路。
部署前先盤點它依賴了哪些外部服務
自架入口是 docs/deploy.md，README 只給連結不給步驟，所以實際指令要以該文件為準。可以確定的是倉庫根目錄附了三份範例檔：config.yaml 是設定範例，coins-table.yaml 是定價表範例，nginx.conf 與 systemd.service 分別是反向代理與服務常駐的範例設定。另外有獨立的 aidea-docker 倉庫負責容器化部署，不想手動編譯的人可以從那裡開始。
真正的成本不在編譯，而在外部依賴。從 pkg 目錄可以看出，這個後端牽涉阿里雲的簡訊與內容安全、騰訊的語音轉文字與簡訊、七牛的檔案上傳與（目前停用的）語音合成、釘釘通知機器人、有道翻譯 API，以及支付相關的支付寶與 Apple 管道。README 也提到 pkg/sms 是一層統一簡訊抽象，把底層供應商藏起來。
這意味著兩件事。第一，config.yaml 要填的憑證數量不會少，且多數對應中國境內的雲服務帳號。第二，如果你打算部署在中國境外、或組織政策不允許使用這些供應商，你得自己替換對應實作，而替換點散在 pkg 底下多個子套件，不是改一個介面就能收工。README 另外提到 pkg/proxy 有 SOCKS5 代理實作，對需要繞出網路限制的部署情境可能有用。
計費是另一個要提早決定的部分。coins-table.yaml 是價格表的範例，internal/coins 負責定價與計費策略。如果你不打算對使用者收費，這塊可以擱著；但只要涉及額度扣減，就得先讀懂這份表怎麼對應到 internal/coins 的邏輯。
授權狀態不明，這是採用前的第一道關卡
資料中這個倉庫的 License 欄位是 unknown。README 標題寫的是 fully open-source，但沒有在可見內容裡指明授權條款。對個人實驗來說這或許無所謂，對要把程式碼放進商業產品的團隊來說，這是必須先釐清的問題：沒有明確授權，就沒有明確的使用、修改與再散布權利。
這裡不談法律結論，只講實務動作：去倉庫根目錄確認有沒有 LICENSE 檔案，沒有的話直接向維護者詢問。這件事應該排在評估部署可行性之前，因為它可能直接否決整個方案，而部署驗證要花的時間遠比問一句話多。
同樣值得注意的還有首頁上那個 Trendshift 徽章。它代表某種曝光度，但曝光度不等於授權清楚，也不等於長期維護承諾。判斷這個專案能不能倚賴，看的是釋出節奏與程式碼註解是否如 README 所說會逐步補上，而不是徽章。
非同步任務與計費是它真正的工作量所在
多數人看這類專案會先看模型接入，但真正決定能不能上線的往往是周邊。internal/queue 定義了所有非同步處理的任務，internal/queue/consumer 是對應的消費者。圖像生成這類請求耗時長，同步等待不現實，任務佇列就是它的解法。這也代表部署時 Redis 是必需品，pkg/redis 有對應的實例封裝，少了它整個非同步鏈路跑不起來。
pkg/jobs 放的是排程任務，README 舉的例子是每日使用者 token 消耗統計。這種任務看起來不起眼，但它是計費對帳的基礎，如果要做額度控管就不能忽略。
pkg/token 負責 JWT，pkg/rate 是限流實作。限流在有對外開放端點時是必要的，尤其是 api 目錄那組相容 OpenAI 協議的端點，一旦開放給第三方軟體使用，請求來源就不可控。這兩塊的設定值同樣落在 config.yaml 裡，實際可調參數以該檔案與 docs/deploy.md 為準。
把這些拼起來看，這個後端的複雜度主要來自營運面：佇列、限流、計費、對帳、多雲憑證。模型接入反而是相對單純的一段。評估人力時要照這個比例估，而不是照 README 第一段的關鍵字估。
什麼情況下你該自己寫而不是用它
最直接的替代方案是自己寫一層薄封裝：用官方 SDK 或直接發 HTTP 請求，在應用層做格式轉換。差異在於控制權與依賴面。aidea-server 幫你決定了資料庫結構（migrate 目錄下的 SQL 遷移檔）、佇列實作、ORM 選型、依賴注入框架，甚至計費模型；自己寫的話這些都由你決定，代價是每一家模型的串流格式、錯誤處理、重試邏輯都要自己處理一遍。
如果你只需要接一家模型，自寫幾乎一定更划算，因為抽象層的價值來自供應商數量。如果你需要的是圖像生成加上聊天加上語音加上翻譯的完整組合，而且能接受中國境內的雲服務，那自己重寫這些整合會是相當大的工作量，用現成的更合理。
中間地帶也值得考慮：只取 api 目錄那組 OpenAI 相容端點，把它當成一個自架的多模型閘道，客戶端繼續用原本支援 OpenAI 協議的軟體。這樣可以避開 server 目錄那套為 AIdea 客戶端量身打造的端點，也少綁一些客戶端專屬邏輯。前提是你讀得懂 Glacier 的模組啟動方式，能把 api 那部分單獨拉起來。
另一個現實變數是維護狀態。最近一次釋出是 2024 年 4 月，而倉庫最後推送時間是 2026 年 3 月，兩者之間有一段距離。這不代表專案停滯，但代表釋出節奏與提交節奏不一致，採用前值得看一下這段落差期間的提交內容是什麼。
升級成本與長期維護的實際樣子
這個專案的升級成本有兩個來源。一個是資料庫，migrate 目錄放的是 SQL 遷移檔，版本升級若涉及結構變動，你得自己安排遷移順序與回滾方案。另一個是供應商 API，各家模型的介面會變，包在 pkg/ai 底下的實作就得跟著改，這部分無法靠鎖版本避免。
設定檔的相容性也要留意。config.yaml 與 coins-table.yaml 都是範例檔，專案演進時欄位可能增減，升級前先比對新版範例與你線上設定的差異，會比直接覆蓋安全。
README 自己承認註解與技術文件有限。這對維護的影響是：遇到問題時，可依靠的往往是程式碼本身與社群。專案提供微信技術討論群與公眾號作為支援管道，這是它主要的求助途徑。對不熟悉中文社群或不使用微信的團隊來說，這是一個實際的摩擦點。
最後回到授權。在 License 欄位仍是 unknown 的情況下，任何升級計畫都應該先解決這個前提。條款不明時，升級與否不是技術問題，而是能不能繼續用的問題。
編輯結論
如果你需要一個現成的多模型後端，而且能接受它綁定阿里雲、騰訊雲、七牛等中國境內服務，aidea-server 可以省下大量接入工作；如果你只想接一兩家模型、或必須部署在沒有這些雲服務的環境，自己寫一層薄封裝會更乾淨。動手前先確認三件事：倉庫是否附帶 LICENSE 檔案（目前無法從資料中確認授權條款）、docs/deploy.md 列出的外部依賴你是否都拿得到、以及 config.yaml 與 coins-table.yaml 的必填欄位。編譯與部署細節以 docs/deploy.md 為準。
社群筆記