先建 baseline 再說工具爛
Reddit 上最近有一串「OpenClaw sucks - I said it.」，score 72，105 則留言，很熱。大致上是說 minimax 2.7 表現差、任務常失敗、最後回去用 Claude 或 Codex。
看完第一個反應不是「對，真的很爛」，也不是「你不會用」。
是：「你怎麼知道它失敗了？」
這問題聽起來很蠢，但認真的。
很多人用 OpenClaw 的流程是：拿來跑任務 → 看起來沒成功 → 換模型 → 覺得是工具的問題。中間缺了一個環節：你有沒有一個可以重現的 baseline？
講白話就是：你有沒有辦法說「這個任務，在正常情況下，應該在 X 步以內完成，輸出 Y 結果」？沒有這個基準，你就沒辦法分辨「是模型爛、是 prompt 問題、是工具設定錯、還是任務本來就太模糊」。這四個原因的修法完全不同，但大部分人直接跳到「工具爛」。
baseline 是什麼，怎麼建
我自己在導入任何 AI 工具前會先跑三個「基準任務」。不是什麼特別的任務，就是三個我已經知道答案、而且有明確完成標準的任務。
比如其中一個是：「讀這個 repo 的 README，列出所有外部依賴，給我一份 JSON 格式的清單」。不難，但結果是可驗證的——我知道正確答案有幾個依賴、格式應該長什麼樣。
成功標準要量化。 「看起來不錯」不算。我的判斷方式：3 個基準任務都過才算 green；2 個過 1 個失敗，查那個失敗的；全失敗才考慮是工具或模型的根本問題。
跑完這三個任務之後，你才有資格說「這個設定下，OpenClaw 的成功率大概是多少」。
為什麼大家跳過這步
因為建 baseline 很無聊。
你滿腦子想的是「我要讓 AI 幫我做 X」，不是「我要先驗證工具是否正常運作」。
但這就跟你沖了一杯義式，喝起來味道怪，直接怪咖啡機一樣。有沒有可能是豆子問題？水溫？研磨粗細？你根本不知道，因為你從來沒建立過一個「基準杯」——同樣的豆子、同樣的設定、同樣的水，確認這個是正確的味道，然後才有辦法找偏差。
AI 工具也一樣。
故障排查的順序
假設你已經有 baseline，任務失敗的時候，排查順序是這樣的：
第一步：Prompt 先動，模型別動。 同一個任務換個 prompt 再跑一次。很多「模型失敗」其實是 prompt 沒給夠 context。
第二步：縮小任務範圍。 任務分五步，先確認每一步單獨跑是否正常。越複雜的任務，失敗點越難定位。
第三步：換模型是最後一步。 換了模型但沒改其他東西，你學不到任何東西——你不知道是模型造成的差異，還是你無意間調整了什麼。
記錄你換了什麼。 哪怕只是一行文字。我們用一個共享的 Notion 頁追蹤每次設定改動，三個月下來回頭看，有幾次「模型問題」其實是設定沒帶好。
那串 Reddit 討論裡有個回應說得準：「大部分人設定沒驗證就直接跑複雜任務，然後說工具爛。」
minimax 2.7 的特殊狀況
這個要單獨講，因為那串的引爆點就是這個。
minimax 2.7 在長 context 的多步驟任務裡，的確偶爾會在中間跳出來說「我完成了」但其實沒完成。這不是幻覺，是它對「任務完成」的定義跟你不一樣。
解法是在 system prompt 裡明確定義完成條件，而且要用可驗證的語言——「你完成任務當且僅當你已輸出包含 N 個項目的列表，並且每個項目都包含 X 欄位」。
麻煩，但有效。跟你帶新人是一樣的道理：不能假設他知道「完成」是什麼意思。
OpenClaw 有沒有爛的地方？有，每個工具都有。但那串討論裡大部分的抱怨，指向的不是工具的底線問題，而是用的人從來沒有建立過自己的底線。
先建 baseline，再抱怨。這順序很重要。☕
作者：咖啡驅動開發