每次开一个新对话都要重新解释一遍背景，这件事真的很烦。
不是因为模型不够聪明，而是因为大多数 AI 工具保存的是聊天记录，不是项目里已经想清楚的东西。
你上周花了两个小时讨论技术方案，今天换了个 session、换了台电脑，或者从 Claude 切到 Codex，AI 还是会一本正经地问你：这个项目是做什么的？为什么不用方案 B？这个决定之前讨论过吗？
而 MindMux 的出发点，就是想解决这个问题。
MindMux 更关心的是另一件事：怎么把一次次讨论，慢慢沉淀成一个不会失忆的项目大脑。
这个 brain/ 是本地的，是 Markdown 的，是可以跟着项目走的。你可以放进 git，可以换模型读，可以在不同电脑上继续用。下一次对话开始时，AI 读到的不是一串零散聊天记录，而是你们之前已经确认过的背景、决策、约束和路线。
这篇文章我想要说说：我现在是怎么用 MindMux 推进一个项目的。
我现在的工作流，基本是三步
第一步：先聊，不急着立刻开工
新项目刚开始的时候，最容易犯的错不是写得慢，而是太快开始写。
我一般会先在 MindMux 里围着同一个主题聊几轮。可能是产品方向，可能是技术方案，可能是 roadmap，也可能只是为了把一个模糊想法讲清楚。
这一步最重要的不是“得到答案”，而是把几个关键问题聊透：
- 这件事到底要解决什么问题？
- 哪些方向我们已经明确不做？
- 技术上有哪些选项，为什么选这个，不选那个？
- 这一版先做到哪里就够了？
你可以把它理解成先积累几个稳定的判断，再进入执行。
在 MindMux 里，这些讨论不会只停留在聊天窗口里。等一轮对话收敛之后，它会被提炼进 brain/：有的是项目级文档，有的是单独的 decision page，有的是背景和约束，还有的是以后做任务时必须带上的上下文。
这里有一个很关键的区别：
聊天记录是过程，brain 是结论。
MindMux 不想保存一切原话，MindMux 想保存的是以后还会反复用到的东西。
第二步：开始做，但把高频动作收成固定套路
等需求和方向比较清楚之后，才进入开发。
这时候我不想每次都用自然语言重新描述一遍“现在请你整理需求”“现在请你总结背景”“现在请你准备交接上下文”。这些高频动作应该被固化成稳定的工作流。
所以在 MindMux 里，slash command 不是一个花哨的输入法功能，它本质上是 skill 的入口。
今天内置的是像 /background、/ingest、/handoff 这样的能力。它们分别对应：
- 快速补全项目背景
- 把一轮讨论里已经想清楚的东西提炼进 brain
- 把上下文打包交给下游 agent
而再往前一步，完全可以继续长出更贴近团队习惯的命令，比如：
/feat：把一个新需求整理成可执行描述/fix：把一个 bug 的上下文、边界和验收条件收拢清楚/review：在看改动前先把相关历史决策拉出来/commit：在提交前回看这次工作到底改变了什么判断
这些命令不是凭空长出来的，它们本质上都是通过 MindMux 的 创建技能 能力生成的。也就是说，当你发现某个动作会反复发生，就可以把它整理成一个可复用的 skill，保存下来，直接变成一个新的 slash command。
这样做不是为了“更像 IDE”，而是为了把一类重复动作变成统一协议。你不用每次重新组织语言，AI 也不用每次重新猜你的意图。
当讨论已经收敛成一件明确的工作时，MindMux 会把它派发出去。它自己不替你写完所有代码，而是把相关的 背景、约束和验收标准 一起交给 Claude Code、Codex 这类下游执行者。
这件事非常重要，因为很多项目不是死在“不会做”，而是死在“开始做的时候已经忘了为什么这么做”。
第三步：做完一轮，再回到项目大脑
这是我最喜欢的一步。
很多工具都能帮你开始，但很少有工具认真处理“做完之后怎么办”。
现实里的开发不是线性的。你做完一个需求，用户会给反馈；你修完一个 bug，会发现之前的判断要调整；你推进 roadmap，会发现某个方向其实应该砍掉。
如果这些变化最后只留在新的聊天记录里，那过一周它们还是会丢。
所以我的习惯是：每推进完一轮，就通过已经创建好的 skill 回到 brain，把这次真正改变了什么写清楚。
不是写流水账，而是借助这些 skill 更新这些内容：
- 我们现在确认的目标是什么
- 哪个设计已经定了
- 哪个方向被否了
- 哪个约束比之前更重要了
- 下一次讨论从哪里接着来
这也是为什么 MindMux 里的 page 不是一坨随便记的笔记。它有一层 compiled_truth，表示当前最稳的理解；也有一层 timeline，表示这些理解是怎么一步步形成的。
前者帮你继续工作，后者帮你回头追溯。
为什么这么在意项目大脑
因为真正让项目变慢的，很多时候不是编码速度，而是上下文丢失。
没有 brain 的时候，你会经常遇到这些情况：
- 开新会话时，得重新讲一次之前的需求
- 换模型时，之前讨论过的限制条件全没了
- 一周后回来看，已经不记得当时为什么选这个方案
- 想把任务交给另一个 agent，结果又得重新整理一遍背景
这些动作单看都不大，但它们会稳定地吞掉注意力。
而一旦有了 brain/，整个感觉会很不一样。
你不是在维护一个“更长的聊天历史”，你是在维护一个项目自己的长期记忆。
它有我认为特别重要的几个特点：
- 它不是绑死在某个模型里的 memory，而是一个独立存在的文件夹
- 它不是黑盒数据库，而是普通 Markdown
- 它不是只服务一个 session，而是服务整个项目
- 它不是只能在一台机器上读，而是可以随着项目一起移动
最直接的结果就是：方向不会轻易漂。
尤其是在产品早期，这一点非常值钱。因为你会频繁讨论、频繁试错、频繁改变细节，但真正已经想清楚的大方向，不应该在每一次新对话里重新被打散。
对我来说，MindMux 更像一个“不会失忆的讨论层”
我现在越来越不把它看成一个“AI 客户端”，而是把它看成项目的一层长期记忆。
你可以接入不同的模型，但中间不变的是那份 brain。
你可以在这里讨论产品、整理方案、准备任务、回看历史判断，也可以把一段已经成熟的上下文交给下游去执行。最关键的是，不管你今天在哪个 session，明天在哪台电脑，后天换到哪个模型，只要还在同一个项目里，你就不是从零开始。
这就是 MindMux 的核心价值所在：它不是一个功能很多的东西。
而是一个真正能让你在做项目时少重复解释、少丢判断、少走回头路的东西。
如果你第一次用 MindMux，我建议你这样开始
很简单：
- 选一个正在推进的真实项目，不要拿 demo 试。
- 先用它聊一轮你现在最卡的产品或技术问题。
- 讨论收敛后，把背景、关键决策和约束写进 brain。
- 下一次再开新会话时，不要重新描述，直接接着往下推进。
- 当一件事已经足够明确，再把它派发给下游 agent 去做。
如果用完后，你第一次明显感觉到“这次我不用再重复讲一遍了”，那它就开始发挥作用了。
有了 MindMux 之后，你能更专注于产品和技术本身，而不是每次都在重复解释和回忆。
原文发布于 MindMux Blog。
程序员
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。