PromptHub：把 Prompt、SKILL.md 與 Agent 資產收進本機工作區的 Electron 桌面工具
一款包含了 Prompt管理，Skill管理，Agent管理的一站式AI工具箱，助你高效管理提示词，一键分发skills ，一站式管理Agent资产，并实现云同步，备份，版本管理 | An all-in-one AI toolbox for prompt, agent, and skills management. Reuse prompts, distribute skills with one click, manage agent assets, and support cloud sync, backup, and version control
秒懂
- 它是什麼？
- PromptHub 以本機優先為前提，用 Electron 桌面端管理 Prompt 版本、把同一份 Skill 分發到十幾個 AI 程式工具，並透過 WebDAV 或自部署 Web 做同步。核心判斷是：它解決的是資產散落問題，代價是 AGPL-3.0 授權與 beta 版本並行的維護節奏。
- 適合誰用？
- PromptHub 適合手上同時使用多個 AI 程式工具、且 Prompt 與 SKILL.md 已經散落在各專案目錄裡的人；如果你的團隊只固定在一個工具、或需要一個可審計的多人協作後端，它目前不是合適的選擇。採用前先確認三件事：v0.5.9 穩定版與 v0.6.0-beta 之間你要跟哪條線、WebDAV 同步的衝突處理行為是否符合你的預期、以及 AGPL-3.0 對你打算自部署的 Web 版是否構成義務。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 11 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
PromptHub 要解決的是資產四散，不是 Prompt 寫得好不好
多數人用 AI 程式工具的實際狀態是這樣：Claude Code 有一份指令檔，Cursor 有另一份規則檔，Codex 又是第三個位置，專案層級還各自有一份 SKILL.md。這些檔案的內容大量重疊，但沒有任何一處是權威版本。改了其中一份，其他幾份不會跟著動。
PromptHub 針對的就是這個問題。README 開頭寫得很直接：把你的 Prompt、SKILL.md 和專案級 AI 編程資產放進一個本地工作區，資料預設存在你自己的電腦上。注意這句話的範圍。它沒有說要幫你寫 Prompt，也沒有說要取代任何一個 AI 程式工具。它把自己定位成工作台，工具仍然是 Claude Code、Cursor、Codex、Windsurf、Antigravity、Cline 這些，PromptHub 負責的是這些工具共用的資產層。
適用對象因此相當明確：同時開兩到三個 AI 程式工具、且已經感受到版本不同步的人。如果你只用一個工具，而且它的規則檔就放在專案根目錄，PromptHub 帶來的管理層會多於它省下的工。
Electron 加 SQLite 的本機工作區，雲端是可選項
從 README 的技術標籤可以看出堆疊：TypeScript、Electron、React、TailwindCSS、SQLite。這組合代表資料落在本機的 SQLite 檔案裡，桌面端是 Electron 殼，介面是 React。README 對資料位置的說法是「數據默認存在你自己的電腦上」，這句話是整個設計的起點。
同步與備份是另外疊上去的。README 列出兩條路徑：透過 WebDAV 同步到其他裝置，或把完整快照備份到自部署 Web。兩者都不是必要條件，也就是說一個完全離線的 PromptHub 是可以運作的。這一點對處理客戶程式碼或內部規格的人有實際意義，因為 Prompt 內容經常夾帶不該外流的片段。
Skill 的分發則是 PromptHub 比較具體的機制。README 的說法是「一鍵安裝到 Claude Code、Cursor、Codex、Windsurf、Antigravity、Cline 等十幾個工具」。這裡的運作方式是把同一份 Skill 來源寫入各工具各自讀取的位置，而不是要求那些工具去讀 PromptHub 的資料庫。這個設計選擇讓 PromptHub 可以隨時移除而不影響既有工具，但也意味著分發之後的檔案仍然是普通檔案，工具端如果有人手改，PromptHub 未必知道。README 沒有交代反向偵測的細節，這是採用前值得自己驗證的地方。
取得與啟動：桌面版、自部署 Web、CLI 三條路
README 提供三種使用方式。最直接的是桌面版，從 GitHub Releases 下載對應平台資產，README 標示 macOS、Windows、Linux 三個平台。文件提到直鏈下載指向 GitHub Latest 穩定版資產，理由是避免 CDN 鏡像尚未就緒時出現 404，鏡像同步完成後會切回固定檔名 CDN 直鏈。
第二條是自部署網頁版，README 有獨立的 self-hosted-web 章節。第三條是命令列，README 的 CLI 章節列出 cli-tool 這個 topic，代表有可用的命令列介面。這兩條路徑的具體指令與設定鍵，在提供的 README 內容裡被截斷，我沒有實際執行過，因此不在這裡編造參數。
可以確認的設定面是模型服務。README 的贊助段落說明 PromptHub 支援在應用內配置 Provider 與模型，並提到相容 OpenAI 標準介面，可接入 ChatGPT、Claude、Gemini、Kimi、GLM、DeepSeek 等。這對應到 README 提到的多模型測試功能，也就是同一個 Prompt 可以丟給不同模型比較輸出。這部分需要你自己申請 API Key，README 中的推廣連結屬於贊助內容，與功能本身無關。
版本選擇上要注意：README 徽章標示 v0.5.9 stable，而 release 列表同時有 v0.6.0-beta.1 與 v0.6.0-beta.2。穩定線與 beta 線並行，跟著 beta 走就等於接受功能與資料格式可能變動。
AGPL-3.0 對自部署 Web 版的實際約束
授權是 AGPL-3.0。這個選擇對桌面端使用者幾乎沒有影響，自己電腦上跑一個工具不涉及散布。真正需要停下來想的是自部署 Web 版這條路。
AGPL 的關鍵條款在於網路服務：如果你把修改過的 PromptHub Web 版架起來讓其他人透過網路使用，即使沒有散布執行檔，通常仍需要向使用者提供對應的原始碼。這對內部單人使用影響有限，但如果你打算把它改造成團隊共用的內部服務，或包進商業產品對外提供，就需要先確認義務範圍。這不是法律意見，只是一個必須在架構決定前釐清的問題。
實務上的替代做法是把 PromptHub 留在本機，用 WebDAV 或快照備份來滿足同步需求，避開自部署 Web 這條路徑。README 把同步與備份列為可選，這個設計本身就允許你這樣用。
beta 線與穩定線並行帶來的維護成本
release 節奏顯示的是雙軌：v0.5.9 在 2026 年 7 月 14 日發布，v0.6.0-beta.1 在 8 月 19 日，v0.6.0-beta.2 在 9 月 3 日。兩個 beta 之間相隔兩週，穩定版與 beta 之間相隔約一個月。
這種節奏對個人使用者是好事，功能推進快。對要把 PromptHub 納入團隊流程的人是成本。Prompt 與 SKILL.md 是會被分發到各工具目錄的實體檔案，一旦資料格式或分發路徑在 beta 之間改變，已經散出去的檔案要重新同步。README 沒有提供遷移指南或格式版本說明，release notes 是唯一線索。
比較穩健的做法是鎖在 v0.5.9 這條穩定線，把 beta 當成觀察對象而非生產環境。桌面版可以從 GitHub Releases 下載歷史版本，這讓回退在技術上可行，但 README 沒有說明資料庫 schema 是否向下相容，回退前應該先備份 SQLite 檔案。
和純檔案方案相比，PromptHub 多付了什麼
最直觀的替代方案是純檔案：把 Prompt 放進 Git 倉庫，用目錄結構區分工具，用 symlink 或複製腳本分發到各工具讀取的位置。這個做法零依賴、可審計、diff 清楚，而且沒有授權問題。
PromptHub 相對多出來的是三件事：版本管理介面、多模型測試、以及分發動作的封裝。純檔案方案要自己做版本管理就得靠 Git，而 Prompt 的迭代通常不是線性提交，用 Git 管會產生大量瑣碎 commit。多模型測試在純檔案方案裡幾乎沒有對應做法，你得自己寫腳本呼叫各家 API。分發則是 PromptHub 最實在的一塊，因為它把十幾個工具的路徑差異吸收了。
反過來說，純檔案方案在可審計性上勝出。PromptHub 把資產收進 SQLite，要 review 變更就得透過它的介面，而不是 git diff。如果你的流程需要對 Prompt 變更做 code review 或合規留痕，這一點會是阻力。兩種方案解決的不是同一個問題，選哪個取決於你更在意分發便利還是變更可審計。
什麼情況下 PromptHub 是錯的工具
第一種情況是團隊協作。README 描述的是本機優先加個人同步，WebDAV 與自部署 Web 是備份與跨裝置同步的手段，不是多人同時編輯的後端。如果你的需求是幾個人共用一份 Prompt 庫並看到彼此的修改，PromptHub 目前的架構不直接對應，你要自己處理衝突。
第二種情況是只需要一個工具。如果你固定用 Claude Code，規則檔就放在它讀取的位置，加一層管理工具只是多一個要同步的地方。
第三種情況是對供應鏈有嚴格要求。Electron 桌面應用意味著你要信任它的打包與更新流程，而目前是 beta 與穩定並行的階段。若你所在環境不允許安裝未經內部審查的桌面程式，自部署 Web 版會是唯一選項，但那又回到 AGPL 的義務問題。
還有一個實際限制：README 提到的分發目標工具清單以「等十幾個工具」帶過，沒有在提供的內容裡完整列出。如果你依賴的工具不在支援清單內，分發功能就幫不上忙，這點必須在採用前確認。
編輯結論
PromptHub 適合手上同時使用多個 AI 程式工具、且 Prompt 與 SKILL.md 已經散落在各專案目錄裡的人；如果你的團隊只固定在一個工具、或需要一個可審計的多人協作後端，它目前不是合適的選擇。採用前先確認三件事：v0.5.9 穩定版與 v0.6.0-beta 之間你要跟哪條線、WebDAV 同步的衝突處理行為是否符合你的預期、以及 AGPL-3.0 對你打算自部署的 Web 版是否構成義務。這三點在 README 裡都沒有完整交代，需要自己看 release notes 與 LICENSE 才能定案。
社群筆記