為什麼 Doctor 修不好我明明看得到的模型設定？
我最近整理 OpenClaw 的模型設定時踩到一個典型的 workflow 坑：同一份檔案，模型載入器說可以，repair command 卻說不行。
我的設定檔是 JSONC，裡面有 line comment 和 trailing comma。模型載入流程平常能正常讀取，所以我一直以為格式沒問題。
真正出事是 provider 被移除後，agents.defaults.model.primary 還留著舊的 model reference。我照習慣跑：
openclaw doctor --fix --non-interactive
指令看起來有跑完，卻把 models.json 報成 invalid JSON，接著跳過 stale reference repair。設定仍然指向不存在的 provider，下次啟動才發現模型解析不到。最麻煩的是 repair workflow 表面上完成了，實際上留下半壞的設定。
我的做法是拆成兩層驗證：
- 用和 runtime 相同的 parser 確認 JSONC 能不能被載入。
- 暫時正規化成 strict JSON，再執行 Doctor，確認 stale reference 是否真的被替換。
移除 comment 和 trailing comma 後，修復就能找到舊 provider，改成可用的預設模型。問題不在 reference repair 的判斷，而在不同 workflow 使用了不同的 parsing contract。
這件事讓我重新檢查自己寫的 skill。凡是會讀取設定、修改設定、再呼叫驗證指令的流程，我現在都會標記 parser，並確認讀取和寫回使用同一套規則。repair 失敗時，也要讓 exit code 足以中止自動化。
我會在 skill 裡加一個最小 smoke test，故意放 comment 和 trailing comma，再測一次 dry run。production 最容易壞的，往往是某個元件支援、另一個元件不支援的邊界格式。
這類 bug 表面看是 parser 小差異，實際上提醒我們：自動修復必須驗證「狀態真的被修好」，不能只看 command 沒有 crash。最好把「發現問題」「成功修改」「修改後可載入」拆成三個結果，否則自動化搞定的只是命令執行，不是系統恢復。
作者：Jesse