產品
設計原則
MindMux 的設計圍繞一個非常聚焦的核心命題：持久化的專案上下文，比一次性的聊天記錄更有價值。
產品原則
持久輸出優先於瞬時互動
一次成功的會話，應該讓專案比開始時狀態更好。好答案固然重要，但持久的知識更重要。
預設本地優先
專案知識應該易於查閱、版本控制、遷移和備份。基於檔案的儲存不是實現細節，而是產品特性。
對範圍保持強約束
MindMux 刻意避免變成通用聊天客戶端、通用 wiki 或完整任務看板。邊界越清晰，產品反而越有用。
知識可跨執行時遷移
知識層不應該依賴單一模型供應商或單一執行時。團隊應該可以替換執行層，而無需重寫核心上下文。
輸出必須人類可讀
重要產物既要能被人閱讀，也要能被機器複用。Markdown 成為預設選擇，正是因為它在這兩方面都表現良好。
討論應該走向結構
MindMux 不把對話當作終點。產品應該順暢地幫助使用者從對話走向根文件、頁面或任務。
輸入和輸出邊界清楚
Task 負責把已經收斂的討論向外派發執行。產品邊界清晰，整個應用才更容易理解。
對 UX 的影響
這些原則會直接塑造介面設計：
- 對話是入口，但不是終點
- 文件被當作一等輸出
- 任務交接輕量且帶上下文
- 工作區邊界清晰可見
- 在早期流程裡，應用更偏向清晰，而不是高度可配置
對架構的影響
這些原則也解釋了若干實現選擇：
- 持久知識儲存在
brain/ - 執行狀態單獨放進專案本地儲存
- 執行時從專案大腦模型中抽離出來
- MCP 工具暴露結構化專案上下文，而不是只靠提示詞填充
- 會話和任務被當作真實產品物件，而不是偶然出現的介面標籤
非目標
MindMux 不打算成為：
- 完整的知識圖譜平臺
- 通用的企業協作套件
- 承接所有工作流的 AI shell
- 工程系統 of record 的替代品
這種剋制本身就是設計的一部分。產品應該在有價值時與這些系統整合，而不是吞掉它們的全部職責。