产品
设计原则
MindMux 的设计围绕一个非常聚焦的核心命题：持久化的项目上下文，比一次性的聊天记录更有价值。
产品原则
持久输出优先于瞬时交互
一次成功的会话，应该让项目比开始时状态更好。好答案固然重要，但持久的知识更重要。
默认本地优先
项目知识应该易于查阅、版本控制、迁移和备份。基于文件的存储不是实现细节，而是产品特性。
对范围保持强约束
MindMux 刻意避免变成通用聊天客户端、通用 wiki 或完整任务看板。边界越清晰，产品反而越有用。
知识可跨运行时迁移
知识层不应该依赖单一模型供应商或单一运行时。团队应该可以替换执行层，而无需重写核心上下文。
输出必须人类可读
重要产物既要能被人阅读，也要能被机器复用。Markdown 成为默认选择，正是因为它在这两方面都表现良好。
讨论应该走向结构
MindMux 不把对话当作终点。产品应该顺畅地帮助用户从对话走向根文档、页面或任务。
输入和输出边界清楚
Task 负责把已经收敛的讨论向外派发执行。产品边界清晰，整个应用才更容易理解。
对 UX 的影响
这些原则会直接塑造界面设计：
- 对话是入口，但不是终点
- 文档被当作一等输出
- 任务交接轻量且带上下文
- 工作区边界清晰可见
- 在早期流程里，应用更偏向清晰，而不是高度可配置
对架构的影响
这些原则也解释了若干实现选择：
- 持久知识保存在
brain/ - 运行状态单独放进项目本地存储
- 运行时从项目大脑模型中抽离出来
- MCP 工具暴露结构化项目上下文，而不是只靠提示词填充
- 会话和任务被当作真实产品对象，而不是偶然出现的界面标签
非目标
MindMux 不打算成为：
- 完整的知识图谱平台
- 通用的企业协作套件
- 承接所有工作流的 AI shell
- 工程系统 of record 的替代品
这种克制本身就是设计的一部分。产品应该在有价值时与这些系统集成，而不是吞掉它们的全部职责。