Hivemind

🚀 Hivemind研究文檔索引

Hivemind是一個MCP服務器，它通過Obsidian為AI工具提供規範的世界構建上下文。本目錄包含了關於Hivemind的全面研究和規劃文檔。

關鍵洞察：Hivemind是Obsidian（世界構建者工作的地方）和Claude/AI工具（需要一致上下文的工具）之間的“橋樑”，並非要取代其中任何一方。

📄 文檔介紹

1. 📋 FEATURES.md（40 KB - 主要研究文檔）

全面的功能研究文檔

涵蓋內容：

• 核心MCP功能（工具、資源、提示、查詢模式、最佳實踐）
• Obsidian庫功能（文件夾結構、模板、元數據模式、關係建模）
• AI上下文交付（特定任務上下文、角色一致性、位置/時間線上下文、資產引用）
• 規範管理（草稿→審批工作流程、版本控制、衝突解決、驗證）
• 資產來源（ComfyUI工作流程、元數據跟蹤、可重複性）
• 功能優先級（MVP功能、0.2版本及以上的可選功能、1.0版本及以上的未來功能、超出範圍的功能）

閱讀時機：想要全面瞭解系統設計和功能時。

閱讀時長：30 - 45分鐘

2. 🎯 RESEARCH_SUMMARY.md（8 KB - 快速參考文檔）

關鍵研究結果的執行摘要

包含內容：

• 各主要領域的高層次研究結果
• 設計決策及理由
• 風險評估與緩解措施
• 實施路線圖階段
• 來源驗證

閱讀時機：想快速瞭解研究驗證的內容及原因時。

閱讀時長：5 - 10分鐘

3. ✅ IMPLEMENTATION_CHECKLIST.md（12 KB - 可操作文檔）

分階段實施指南

包含內容：

• MVP清單（0.1版本）
• 第一階段詳細任務（第1 - 2周）
• 第二階段擴展任務（第3 - 4周）
• 第三階段完善任務（第5周及以後）
• 可複製的代碼模式
• 成功標準

閱讀時機：想了解要構建的內容及構建順序時。

閱讀時長：10 - 15分鐘

4. 🏗️ ARCHITECTURE.md（在庫中）

系統設計和組件圖

查看路徑：.planning/research/ARCHITECTURE.md

5. 📚 STACK.md（在庫中）

技術選擇及理由

查看路徑：.planning/research/STACK.md

按角色快速導航

👨‍💻 開發者：“我如何構建這個項目？”

1. 起步：閱讀RESEARCH_SUMMARY.md（瞭解範圍）
2. 深入研究：閱讀FEATURES.md中的“核心MCP功能”和“Obsidian庫功能”部分
3. 開始構建：參考IMPLEMENTATION_CHECKLIST.md
4. 參考資料：閱讀FEATURES.md中的“查詢模式”部分以進行API設計

🏛️ 架構師：“整體設計是怎樣的？”

1. 總體瞭解：閱讀RESEARCH_SUMMARY.md
2. 設計細節：閱讀ARCHITECTURE.md
3. 功能範圍：閱讀FEATURES.md中的“功能優先級”部分
4. 約束條件：閱讀FEATURES.md中的“超出範圍”部分

🧪 測試人員：“我應該測試什麼？”

1. 測試範圍：閱讀IMPLEMENTATION_CHECKLIST.md中的“測試與驗證”部分
2. 成功標準：參考IMPLEMENTATION_CHECKLIST.md
3. 數據格式：閱讀FEATURES.md中的“Obsidian庫功能”部分
4. 邊緣情況：閱讀FEATURES.md中的“風險與緩解措施”部分

📝 產品經理：“項目願景是什麼？”

1. 快速概覽：閱讀RESEARCH_SUMMARY.md
2. MVP範圍：閱讀FEATURES.md中的“功能優先級”部分→MVP
3. 路線圖：閱讀RESEARCH_SUMMARY.md中的“實施路線圖”部分
4. 風險：閱讀RESEARCH_SUMMARY.md中的“風險與緩解措施”部分

🎨 設計師：“用戶體驗是怎樣的？”

1. 系統概述：閱讀FEATURES.md中的“MCP是什麼”部分
2. 用戶工作流程：閱讀FEATURES.md中的“規範管理”部分
3. 數據模板：閱讀FEATURES.md中的“筆記類型與模板”部分
4. 上下文示例：閱讀FEATURES.md中的“AI上下文交付”部分

關鍵研究結果（簡版）

✅ 已驗證的內容

• MCP可以在不修改Obsidian的情況下公開世界構建數據
• Obsidian的YAML和維基鏈接足以進行關係建模
• Claude的200K令牌上下文窗口足以提供世界上下文
• 現有工具（ComfyUI、Dataview）無需重新實現即可集成
• 基於Git的審批工作流程適用於協作式世界構建

🎯 已做出的設計決策

1. 單一事實來源：Obsidian庫（而非外部數據庫）
2. 架構：MCP服務器作為只讀橋樑
3. 關係：通過維基鏈接和YAML元數據實現雙向關係
4. 審批：基於Git（主分支 = 規範，功能分支 = 提案）
5. 資產：在圖像中嵌入元數據；版本工作流程

📊 功能範圍

• MVP（0.1版本）：基本查詢、模板、手動審批
• 0.2 - 0.3版本：過濾查詢、一致性檢查、ComfyUI集成
• 1.0版本及以上：多世界、Web UI、協作功能

🚫 超出範圍的內容

• 取代Obsidian（它不是編輯器）
• 外部存儲（庫是事實來源）
• 任意代碼執行
• 自動生成完整世界
• 即時多人編輯

整體架構

用戶（世界構建者）
        ↓
Obsidian庫（事實來源）
        ↓
Git倉庫（版本控制）
        ↓
Hivemind MCP服務器（橋樑）
        ↓
Claude / AI工具（上下文消費者）

數據流：

1. 世界構建者在Obsidian中編輯角色/地點
2. 更改提交到Git
3. Hivemind MCP服務器從Git讀取數據
4. Claude向MCP查詢上下文
5. Claude生成一致的內容（對話、圖像、情節）
6. 結果返回給世界構建者

研究來源

2025年1月進行的研究使用了以下資源：

• 1000多個MCP服務器示例（MCPMarket.io）
• 5個以上的Obsidian世界構建庫模板
• 官方MCP文檔（modelcontextprotocol.io）
• Claude API文檔（platform.claude.com）
• ComfyUI工作流程文檔
• 領先的世界構建工具（World Anvil、Reality Forge、Urdr）

實施時間表（預估）

成功指標

MVP成功標準

• ✅ Claude可以查詢角色數據
• ✅ 上下文保持在令牌限制內
• ✅ 一致性檢查正常工作
• ✅ 模板易於使用
• ✅ 審批工作流程正常運行

1.0版本成功標準

• ✅ 多用戶協作式世界構建
• ✅ 平穩處理1000多個實體
• ✅ 用於瀏覽的Web界面
• ✅ 完整的資產來源跟蹤
• ✅ 社區採用（外部庫）

實施中的開放性問題

1. MCP運行時選擇（TypeScript、Python、Rust？）

   • 決策點：語言專業知識、部署目標

2. 如何處理庫更改（Git鉤子、輪詢、文件監視器？）

   • 設計點：延遲與系統負載

3. 緩存位置（進程內、Redis、持久文件？）

   • 性能點：內存與響應性

4. 如何驗證一致性（嚴格規則還是警告？）

   • 用戶體驗點：有用與煩人

5. 何時集成ComfyUI（0.1版本、0.2版本、1.0版本？）

   • 範圍點：複雜性與達到MVP的時間

答案可查看IMPLEMENTATION_CHECKLIST.md中的“要創建的關鍵文件”部分。

貢獻文檔

更新文檔時：

• 保持FEATURES.md作為規範的詳細參考文檔
• 將摘要同步到RESEARCH_SUMMARY.md
• 範圍更改時更新清單
• 將新發現添加到適當的部分
• 保證代碼示例與實現保持同步

最後更新時間：2025年1月
狀態：✅ 完成研究階段
下一步：實施規劃和第一階段開發