2025 多模型工作筆記：文件、程式與額度怎麼分工

2026-09-07 修訂：本文保留 2025 年的個人工作紀錄，移除缺乏本文實測支持的模型優劣、晶片與供應鏈推論。舊版把 MCP、LangChain 與硬體推論相容性放在同一層比較，也不恰當，已刪除。下列經驗有時間與任務限制，不代表目前模型或方案的表現。

當時的分工，從手上的工作出發

2025 年寫這篇筆記時，我會在 GPT、Claude、Codex 和 Cursor 之間切換。GPT 是日常討論的主力，Claude 用來整理文件與拆解架構，程式實作和重構則交給 Codex 或 Cursor。這是我當時的使用習慣，沒有控制題目、版本與重試次數，不能據此排出誰最強。

Cursor 搭配 Claude 原本讓我很期待，但當時用了幾個小時就碰到額度限制。這個經驗影響了我是否繼續訂閱的判斷，卻不能推論每個人都會在相同時間用完額度。實際用量還會受到任務、上下文與當時方案影響。

文件多了，交接反而需要篩選

Claude 很容易產出一大批文件，我因此會定期清理。留下來的企劃、架構與技術分析有用，但不是每份產物都值得維護。每多一份文件，就多一個可能與程式不同步的地方。

如果要沿用這套分工，可以在交接前先回答三個問題：下一個工具要完成哪一件事？哪些決定已經確定？最後要用什麼操作或產物驗收？把相關檔案與限制一起交出去，比把整段聊天紀錄全部貼上更容易檢查是否漏掉重點。這是整理交接的方法，不是本文完成過的效率實驗。

換模型之前，先留一份可比較的任務

碰到不滿意的答案，很容易立刻換工具重問。但如果第二次問題寫得更清楚，就不能把進步全部歸功於模型。可以先保留相同輸入、必要檔案與完成條件，再分別記錄結果。

例如重構一段程式時，除了能否編譯，還可以列出原本的操作路徑，確認修改後仍能完成。文件整理則可抽查每個結論能不能回到來源，以及是否把提案寫成已決定事項。同一張表能留下失敗，比只收藏最漂亮的一次輸出更適合下一次選工具。

分工不必一次做成平台

只有一個穩定任務時，先把單一工具用清楚就夠了。真的遇到額度、能力或交接問題，再拆出另一個工具負責的步驟。多模型會增加轉交上下文與核對的成本；如果沒有保留結果，工具數量變多，也不會自動變成更可靠的工作流程。

這份筆記能留下的判斷是：先定義你要完成的工作，再記錄工具在哪裡幫上忙、在哪裡中斷。當年的方案與模型會變，具體的交接與驗收紀錄才有辦法拿來比較。