Claude 寫 code 到底怎麼用才對？一個工程師視角的實戰教學
結論先說
- Claude 在 coding 上的強項不是「幫你打字」，而是理解你的意圖再給架構——跟直接貼 error 讓它修完全是兩回事
- context window 的利用方式決定 80% 的使用品質，大部分人沒有好好用這一點
- 有幾個場景 Claude 明顯勝過其他工具：複雜邏輯重構、寫測試、解釋陌生 codebase——這篇會一個一個拆給你看
Claude 在 coding 上到底強在哪？
直接說結論：Claude 最強的地方是推理和解釋，而不是純粹的 autocomplete 速度。
白話講就是，你丟給它一段 300 行的 legacy code 問「這在幹嘛」，它給你的答案通常比 GPT 更有條理、更抓得住業務邏輯；但你要它一行一行 tab 補全，那就不是它的主場了（那種事情 Copilot 或 Cursor 做得更順）。
2026 年的 Claude 3.7 Sonnet 在 SWE-bench Verified 上拿到接近 70% 的成績，這個數字的背景是——這個 benchmark 測的是真實 GitHub issue 的修復能力，不是刷出來的，工程師比較在意這個。
你可以把它想成：Claude 是那種會先問「你的需求是什麼、這個 function 要在什麼情境跑」的資深同事，而不是一個打字很快的實習生。
怎麼設計 prompt 才能讓 Claude 真正幫上忙？
大多數人用 Claude 寫 code 的體驗不好，問題幾乎都出在 prompt。以下是幾個直接有效的改法：
1. 給背景，不只給問題
❌ 不好的方式：「幫我寫一個 API endpoint」
✅ 好的方式：「我在用 FastAPI 做一個後台系統，需要一個 POST /user/update endpoint，接受 JSON body 更新用戶資料，資料庫是 PostgreSQL，已經有 SQLAlchemy ORM 的 base model。幫我寫這個 endpoint 跟對應的 Pydantic schema。」
你給的 context 越接近真實環境，它產出的代碼就越能直接用，而不是要你再改一輪。
2. 明確說你要什麼格式
「只給我 function，不需要完整 class」、「順便加 docstring」、「用 TypeScript 寫，不要用 any」——這些限制條件要直接說，Claude 不會自己猜你的 style guide。
3. 用「角色設定」收窄行為
在 system prompt 或對話開頭加一句：「你是一個熟悉 Python backend 開發的工程師，code review 風格偏嚴格，會指出潛在的 security issue 和效能問題。」會讓後續的整個對話品質提升不少。
Claude 最適合哪些 coding 場景？實際場景對照
這裡直接給你一個對照表，免得你每次都在猜要不要開 Claude：
| 場景 | Claude 表現 | 建議做法 |
|---|---|---|
| 理解陌生 codebase | ⭐⭐⭐⭐⭐ | 直接貼整個檔案，問它解釋架構 |
| 寫單元測試 | ⭐⭐⭐⭐⭐ | 給它 function 簽名 + 業務說明，讓它生 edge case |
| 複雜邏輯重構 | ⭐⭐⭐⭐ | 說清楚重構目標（可讀性？效能？解耦？） |
| Debug 錯誤訊息 | ⭐⭐⭐⭐ | 貼完整 stack trace + 相關代碼段 |
| 即時 autocomplete | ⭐⭐ | 這個場景用 Copilot 或 Cursor 比較對 |
| SQL 查詢優化 | ⭐⭐⭐⭐ | 給 schema + 現有 query + 說明資料量級 |
寫測試這件事特別值得多說一句。你可以把一個 function 丟給 Claude，讓它幫你想「我可能沒想到的 edge case」，它在這件事上很可靠——因為它會從業務語意去想，而不只是語法層面。
為什麼 context 管理是 Claude coding 的核心技巧？
Claude 的 context window 很長（200K tokens），但大多數人根本沒好好利用這件事。
你可以做的事：
- 在對話開頭貼你的「專案背景文件」：包含技術棧、目錄結構、命名慣例，之後每個問題都不用重新解釋
- 把相關的多個檔案一起貼進去，讓 Claude 理解跨檔案的依賴關係再回答
- 把之前討論過的設計決策留在 context 裡，它會記得「你說過要用 event-driven 架構」
但有一件事要注意：context 太長、太雜的時候，它的注意力會分散。如果一個對話聊了很多主題，重要的設定最好在問新問題時重新提一下。
這跟 RAG 的概念有點像——你給模型的資訊品質，直接決定輸出品質，而不只是資訊量。
情境案例：用 Claude 處理一個真實的 bug
假設你有一段 async Python 代碼，偶發性地在高併發情況下出現 race condition，error log 不穩定，你自己看了兩個小時找不到。
一般人的做法：貼 error message，問「這是什麼問題」
更有效的做法：
- 貼完整的 stack trace
- 貼相關的 3~5 個 function（不只是出錯那一個）
- 說明「這個問題在低流量時不出現，只在壓測的時候觸發」
- 問它「請從 async 的 race condition 角度分析可能的原因，並列出你認為最有可能的 2~3 個假設」
這樣它給你的答案會是有排序的假設清單，而不是一個猜測。你可以逐個驗證，效率高很多。
順帶一提，如果你也在用 ChatGPT Codex，兩個工具的使用邏輯其實有點不同——Codex 更偏向 agent 式的自動執行，Claude 更偏向協作式的討論，各有場合。
延伸思考：Claude coding 接下來的方向
2026 年這一波 AI coding 工具的競爭，重點已經從「能不能寫」移到「能不能理解整個 repo、然後自主完成任務」。
Anthropic 在 Computer Use 和 Claude Code（CLI 工具）上的投入，就是在往這個方向走。你現在學的 prompt 技巧，其實也是在為之後「給 AI 一個 issue，讓它自己開 PR」的工作流做準備。
不同模型在這條路上走的策略差很多——Claude 的路線是讓你信任它的推理過程，而不只是信任它的輸出結果。這個差異在 coding 場景裡特別重要，因為你最後還是要 review 代碼的。
常見問題 FAQ
Q1：Claude 跟 GitHub Copilot 要怎麼選？
兩個不衝突，用法不一樣。Copilot 是在編輯器裡即時補全，Claude 是你要討論架構、理解邏輯、產生完整功能塊的時候用。很多工程師兩個都開著，各司其職。
Q2：用 Claude 寫的代碼可以直接上 production 嗎？
不建議不看就直接用。Claude 產出的代碼邏輯通常是對的，但 edge case 處理、error handling、security 考量還是要自己 review。把它當「快速的第一版草稿」，而不是「可以 merge 的 PR」。
Q3：免費版的 Claude 夠用嗎？
免費版有對話次數限制，context window 也比 Pro 版短。如果是偶爾問問題，夠用；如果你要把整個 codebase 貼進去、長時間跑複雜的 coding 任務，Pro 版的 200K context 和優先回應速度差距會很明顯。
Q4：Claude 會記得我上次對話的代碼嗎？
不會，每次對話都是獨立的。如果你有跨 session 需要保留的設定或代碼片段，最簡單的方法是準備一個「project context 文件」，每次開對話時先貼進去。
Q5：問 Claude 解釋開源專案的代碼，效果好嗎？
效果很好，這是它的強項之一。直接把整個檔案或相關模組貼進去，讓它畫出資料流、解釋設計決策、或是幫你找某個功能在哪裡實作——比自己硬啃文件快很多。
結論
Claude 在 coding 上最值錢的地方，是它讓你不用當那個「看懂陌生代碼的人」或「想出所有 edge case 的人」——它幫你做這件事，然後你做決策。
Prompt 的品質決定輸出的品質，context 的設計決定你能不能把它當一個真正懂你專案的工具用。這兩件事搞定了，你對 Claude 的評價很可能會從「還好」變成「這個真的好用」。
常見問題
Claude 跟 GitHub Copilot 要怎麼選？
兩個不衝突，用法不一樣。Copilot 是在編輯器裡即時補全，Claude 是你要討論架構、理解邏輯、產生完整功能塊的時候用。很多工程師兩個都開著，各司其職，不用二選一。
用 Claude 寫的代碼可以直接上 production 嗎？
不建議不看就直接用。Claude 產出的代碼邏輯通常是對的，但 edge case 處理、error handling、security 考量還是要自己 review。把它當「快速的第一版草稿」，而不是「可以直接 merge 的 PR」。
免費版的 Claude 寫 code 夠用嗎？
免費版有對話次數限制，context window 也比 Pro 版短。偶爾問問題夠用；但如果你要把整個 codebase 貼進去、長時間跑複雜 coding 任務，Pro 版的 200K context 和回應速度差距會很明顯。
Claude 會記得我上次對話的代碼嗎？
不會，每次對話都是獨立的。最簡單的解法是準備一個「project context 文件」，記錄技術棧、架構決策、命名慣例，每次開新對話時先貼進去，就能讓它快速進入狀況。
問 Claude 解釋開源專案的代碼，效果好嗎？
效果很好，這是它的強項之一。直接把整個檔案或相關模組貼進去，讓它畫出資料流、解釋設計決策、或幫你找某個功能在哪裡實作——比自己硬啃文件或 README 快很多。
分享這篇
