AI 會寫程式碼了，但還是總忘記你上週已經決定了什麼
MindMux 的核心不是儲存聊天記錄，而是把討論沉澱成一個不會失憶、能跟著專案走的專案大腦。
每次開一個新對話都要重新解釋一遍背景，這件事真的很煩。
不是因為模型不夠聰明，而是因為大多數 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 之後，你能更專注於產品和技術本身，而不是每次都在重複解釋和回憶。