每個 AI 寫程式的對話都結束於同一個尷尬的瞬間。代理宣布任務完成，測試全過，程式就緒。也許是真的。但說這話的代理，正是寫下每一行程式、沿途做了一百個小判斷、並且一個個把自己都說服了的那個。問它自己的活做得怎麼樣，多少有點像讓學生批改自己的考卷。
2026 年 10 月 28 日，MiniMax 建了一個公開儲存庫 MCode Stack，第二天加上了 Claude Code 和 Codex 的安裝入口。裡面不是新模型，也不是提示詞合集，而是開發 MiniMax Code 那個團隊每天真實在用的工作習慣——技能、檢查清單、工作流——以任何相容代理都能直接載入的檔案形式公開。其中最有意思的一件，正面回答了「自己批自己考卷」的問題。
乾淨上下文裡的審查員
這個技能叫 independent-review，規則簡單到近乎苛刻：審查員只看三樣東西。程式改動（diff）。這次改動要滿足的需求。以及真實的測試結果，包括失敗的和跳過的。
就這些。審查員拿不到作者的對話記錄、計畫、中間推理和自我評價。技能文件裡對為什麼這樣做的解釋值得轉述：繼承了作者對話的審查員，容易順著同樣的推理走，漏掉同樣的東西。所以審查員要回答的問題被刻意換了一個。不是「作者的邏輯成立嗎」，而是「這個改動滿足需求嗎」。這是兩個不同的問題，而只有不在寫作現場的人，才能誠實地回答第二個。
這個技能的講究不止於設定。它給審查員指了幾類具體的坑：程式依賴但從未檢查過的假設；diff 悄悄跳過的需求條目；通過了但並沒有真正檢驗需求的測試——同一個代理寫的測試，帶著和作者一樣的盲區；以及超出聲明範圍的行為變化。發現的每個問題都要按固定結構返回：位置、原因、外加 blocking、should-fix、nit 三檔嚴重度；沒有位置和原因的，按意見處理，不算缺陷。
然後是防止你反過來盲信審查員的最後一步：回到主對話後，不要整批照單全收。每一條先對著真實程式核實，最好用一個會失敗的測試來確認，然後再改。被駁回的發現連同理由記下來，下次審查就不會再提一遍。
儲存庫裡還有什麼
儲存庫按團隊成員的個人棧組織。主力是 MiniMax Code 研發負責人的 ronny 棧，按一天裡的工作場景分組裝了大約十五個技能。有判斷一個任務到底該不該交給子代理的檢查清單——independent-review 的配套文章標題就很直給：「子代理不是越多越好」。有把工作拆成可審查的小 PR 的技能，有審計你的工具和注入上下文每次請求吃掉多少的技能，有防止長對話變遲鈍的，有決定一條 shell 指令該等多久的，也有教你怎麼不慌不忙處理熱修復的。另一個棧裡加了一條挺扎心的技能：找出那些你一直在給自己的代理當手動步驟的迴圈，把你從裡面摘出來。
所有內容都是通用的 SKILL.md 格式，所以大部分能裝進 MiniMax Code、Claude Code、Codex 或任何支援技能的代理。安裝就是一兩行外掛指令——claude plugin install ronny --marketplace MiniMax-AI/mcode-stack——只想要單個技能的話，把對應資料夾拷進代理的 skills 目錄就行。
它不是什麼
在有人過度解讀之前，先澄清三件事。這不是 MiniMax Code 本體開源，工具在另一個儲存庫，這個儲存庫只有工作流和技能。這不是新模型，也不附帶任何免費算力——你的代理跑在哪個模型上，費用照算。另外儲存庫整體是 MIT 授權，但那幾條工程評審技能改自 Google 的工程實踐文件，按 CC-BY 3.0 保留署名要求，想轉載再發佈的話要注意。
再補一句實話：這些技能我們自己沒有裝過、跑過。一份公開的清單不能證明它能抓到更多 bug——它能證明的是，有一個正經團隊每天就是這麼做事的，而且覺得值得分享。
那為什麼還值得看
AI 程式的討論一直圍著「生成」打轉：更大的模型、更長的上下文、更多的並行代理。MCode Stack 押的是另一頭：下一波提升來自代理周圍那一層工程習慣——什麼時候讓它停下來檢查自己的活、誰來審、審查員可以看什麼。independent-review 這條技能尤其點破了一個大多數人都感覺到過、卻很少被正式說出來的失敗模式：所謂第二意見從來都不獨立，因為它讀過第一意見的日記。
AI 審 AI 算不算真正的審查，可以爭論。但一個眼神乾淨、拿著固定清單、指著需求說話的審查員，總好過今天多數團隊實際在跑的那個流程——作者批完自己的考卷，所有人管這個叫完成。