如果你用 Claude Code 用了一段時間，但還是覺得結果不對、來回修改很多次——問題可能不在 Prompt。
用了幾個月之後，我才意識到 Claude Code 的效果幾乎完全取決於幾件使用方式的差異。這不是文件上找得到的東西，是一次次卡住、一次次解決之後摸出來的。以下是我整理出的 5 件事。
01. Context 是一切
Claude Code 的輸出品質，幾乎完全取決於你給它多少 context。這不是比喻——你給的資訊越豐富、越準確，它執行的結果就越精準。
兩個主要的 context 來源：
- CLAUDE.md：放在專案根目錄的永久設定檔。告訴 Claude 你的專案在做什麼、你的偏好、哪些事情不要做。每次 Claude Code 啟動，它會自動讀取這個檔案。
- Project Context：session 開始時給的背景資訊。現在做到哪裡、這個 session 的目標是什麼、有什麼限制。
我自己用的方式叫 Progressive-loading：不是一次把所有東西塞給 Claude，而是根據任務需要分階段載入相關的 context。需要什麼就給什麼，不需要的就不給——這樣可以避免 context window 浪費在不相關的資訊上。
給對 context，Claude 才能給對答案。這是使用 Claude Code 最重要的一件事。
02. Flow First，再做實作
有想法，直接叫 Claude Code 做——這是很多人一開始的直覺，我也一樣。然後發現方向不對，再改，又再改，來來回回花了很多時間。
Before：你想做一個自動化系統，直接告訴 Claude 去做，它開始寫，但方向不是你要的。改到第三次才對，但前兩次的 code 已經亂了。
After：同樣的需求，你先進 Plan Mode，或者告訴 Claude「先不要做任何事，給我 5 個不同的實作方案，我選一個再開始」。Claude 給你 5 個方向，你選一個，它一次就做對了。
差別不在 Claude 的能力，在你有沒有先確認方向。
03. 大型專案用 Superpowers Brainstorming
如果你在建的是一個比較大的系統，記得用 Superpowers skill 裡的 brainstorming 功能。
你一旦啟動它，Claude 不再把你當成一個只是「想做某件事」的使用者——它會把你當開發者，一步一步問你細節：目標是什麼？有什麼限制？需要哪些功能？整體架構要怎麼規劃？
這些問題逼你把模糊的想法轉成清楚的 spec。你的 spec 越清楚，最後做出來的東西就越接近你真正想要的。沒用這個的話，你可能花了兩個小時叫 Claude 做，最後發現方向完全偏了——因為一開始的指令就不夠清楚。
04. 能用 CLI 就用 CLI
接外部工具時，不要用 API，不要用 MCP。
API 的問題是它會回傳大量的 JSON——metadata、status code、header、nested object，一大堆你用不到的東西。這些塞進 Claude 的 context，浪費 token，還要額外處理解析的邏輯。MCP 很強大，但佔的 context 很多，session 越長越擁擠。
CLI 的輸出很乾淨。你給一個指令，它回傳你需要的結果，不多不少。以 Gemini 為例：用 API 你要一層一層 parse JSON 才能拿到答案；用 Gemini CLI 你直接輸入問題，它直接給你答案。同樣的結果，更少的干擾。
05. Claude Code 開發，Codex Debug 與更新
新功能的開發、架構設計、主要的 coding work——都在 Claude Code 裡做。但當我卡住了、有 bug 不知道怎麼解、或者想對現有的 code 做更新和優化——這時候我會切到 Codex。
Codex 在 review 現有 code、找問題、提出修改建議這類任務上表現得很好。它的思考方式跟 Claude Code 不一樣，所以有時候 Claude Code 繞不出去的問題，Codex 一下就找到了。
最簡單的規則：在 Claude Code 卡住了，就切到 Codex 試試看。
免費下載：完整學習資源 PDF
12 頁速查表，包含 5 個心得對照表、CLAUDE.md 設定指南、CLI vs API vs MCP 比較、Key Takeaways。