用說人話叫它寫程式

4.1　先搞懂它是怎麼工作的

在開始叫它做事之前，先花一分鐘認識它的工作方式，你後面會更安心。

每次你交給 Claude 一個任務，它背後都會跑三個階段（這三步常常是交織在一起、來回進行的）：

1. 蒐集脈絡：它會自己去搜尋、讀取相關的檔案，先搞懂你的程式長什麼樣。
2. 動手執行：跨好幾個檔案做出修改。
3. 驗證結果：跑測試、確認它剛剛做的有沒有做對。

這裡有一個跟你想像可能不一樣的關鍵：它看得到你整個專案，不是只看你打開的那一個檔案。所以當你說「修一下登入的 bug」，它會自己去翻出哪些檔案跟登入有關、一起改、再跑測試確認；你要求的話，它還能順手幫你把這次的改動存檔（commit，第 6 章會教）。

這三步不是各跑一次就結束，而是會反覆循環好幾輪，而且它下一步要用哪個工具，完全看上一步的結果來決定，不是照固定劇本走。用修 bug 來舉例你會更有感覺：它可能先跑一次測試看錯誤訊息，照錯誤訊息去搜跟這個功能有關的檔案，讀進來看懂之後動手改，改完再跑一次測試確認——如果還是沒過，它會自己繞回去再查、再改，不需要你在旁邊喊「再試一次」。

💡 具體長怎樣：一次修 bug 任務可能經歷的來回

# 示意用，不是逐字畫面，讓你有感覺這個循環怎麼轉
你的需求：「登入後，個人資料頁面一直轉圈圈跑不出來。」

① 跑一次相關測試 → 沒有測試涵蓋這個情境
② 搜尋跟「個人資料頁面」有關的檔案 → 找到 profile.js
③ 讀 profile.js → 發現它呼叫一個 API，但沒處理逾時
④ 搜尋這個 API 定義在哪裡 → 找到 api/user.js
⑤ 讀完兩個檔案、判斷問題出在哪 → 提出修改，給你看 diff
⑥ 你核准之後 → 動手改檔案，再跑一次測試確認沒問題

4.2　怎麼把需求講清楚（這是最重要的技巧）

這是整章最值錢的一節。好消息先說：你不需要會下「完美的指令」。Claude 是用對話的方式跟你互動的，可以邊講邊修——先講你要什麼，它做得不對，你再開口調整就好。沒有標準答案，也不會「講錯」被它罵。

但有一個原則會讓結果差很多：你講得越具體，它做得越準。看下面這組對比就懂了。

還有兩個小技巧，會讓你跟它合作更順：

• 可以一次給它好幾個步驟（用編號列出來，它會照順序做）。例如你可以一次這樣交代：

  1. 幫使用者資料建一張新的資料表
  2. 建一個 API 可以讀取和更新使用者資料
  3. 在前端加上編輯個人資料的表單

  複製
• 不滿意就直接說，不用客氣。例如：「不太對，問題應該出在 session 處理那邊。」它會立刻修正方向，不會跟你鬧脾氣。

再進階一點，這兩招是老手常在用、新手比較少想到的：

• 能給例子就給例子，讓它自己驗證有沒有做對。比起單純描述「我要一個檢查 email 格式對不對的功能」，不如順手附上幾個例子，讓它做完可以自己對答案：

  幫我寫一個檢查 email 格式的功能。
  範例：user@example.com 要判定為正確，
  invalid、user@.com 都要判定為錯誤。
  寫完後自己跑一次這三個例子，確認有沒有全部通過。

  複製

  它會照你給的例子自己檢查、自己抓錯，不用你事後一個一個手動測試。

• 與其自己形容，不如直接指給它看。「這裡的排版要跟登入頁一致」比「排版要好看、專業」明確得多；「這個功能的寫法照 UserService 那個檔案的風格」也比空講一套規範清楚得多。把「你腦中的參考答案」直接指出來給它看，它抓的方向會準很多。
• 不只是形容，也可以直接指出「答案在哪裡」。有時候你要的不是它憑空生出一個做法，而是要它先弄懂「這個東西過去是怎麼運作的」。這時候與其自己先研究一輪再轉述給它聽，不如直接請它自己去查：「去看 PaymentService 這半年的存檔紀錄，摘要一下它的介面是怎麼演變過來的，我們這次要接得上。」它自己查、自己整理，通常比你先做完功課再下指令快得多。

4.3　看懂並核准它的修改（diff 是什麼）

這一關，是新手最重要、也最該慢慢來的一關。先記住整個流程長這樣：

你下指令 → 它提議怎麼改，並把 diff（改動對照）給你看 → 你批准 → 它才真的動手改檔案。

關鍵字是 diff。它不是什麼難懂的東西，就是一張「改之前 vs 改之後」的對照表，讓你一眼看出它打算動哪裡：

• 通常綠色、或開頭是 + ＝ 它要新增的內容；
• 紅色、或開頭是 - ＝ 它要刪掉的內容。

你會先看到它打算怎麼改，確認沒問題，再決定要不要放行。

看到 diff 之後，你有兩種放行方式。第一次用，我們強烈建議你跟著下面做一遍，把「逐項核准」的手感建立起來：

1. 1
   ✋動手做

   用平常的話下一個指令

   在 Claude 的輸入框，用講話的方式打出你要做的事，按 Enter。例如：「把首頁標題的文字改成『歡迎光臨』。」不用懂程式怎麼寫，講清楚要什麼就好。

2. 2
   ✋動手做

   看它提議的 diff（先別急著答應）

   它不會馬上改，而是先把打算怎麼改攤開給你看——綠色（+）是要新增的、紅色（-）是要刪掉的。花幾秒看一下它動的地方，是不是你要的。

   ✅ 預期會看到

   # 它會像這樣把改動攤開給你看（綠色 + 是新增、紅色 - 是刪除）
   - <h1>Welcome</h1>
   + <h1>歡迎光臨</h1>
   
   是否套用這項修改？ (y/n)

   複製
3. 3
   ✋動手做

   逐一答應或拒絕

   看一項、答一項。同意這項改動就按 y（yes），不要就按 n（no）。剛開始就用這種「一個一個看」的方式，你會很快學會看懂它在做什麼。

4. 4
   ✋動手做

   放行後，它才真的動手改

   你按下同意，它才會把改動寫進檔案。沒按同意之前，你的檔案一個字都不會被動到——所以放心慢慢看，按錯也不怕。

   ✅ 預期會看到

   # 你同意後會看到類似這樣的完成訊息
   已更新 index.html

   複製

不管你選哪一種放行方式，事後想一次回顧到底改了什麼，都可以打 /diff 叫出一個互動面板，不用再一則一則往上滑對話紀錄找。

💡 一次看完整清單：叫出 diff 面板

/diff

面板裡通常會有兩種切法：一種等同把這次對話裡所有還沒存檔（commit）的修改一次攤開來看；另一種是照對話的每一輪分開看，方便你回頭確認「剛剛那一句我打的話，它到底改了哪裡」。（面板的實際名稱與切法可能依版本略有不同，以你畫面上看到的為準。）

還有一個你可能會擔心的問題：萬一按錯、同意了一個其實不想要的修改，怎麼辦？放心，Claude Code 幫你準備了一層安全網——每次你送出一句指令，它都會記一個時間點；每次要動手改檔案前，也會先幫那個檔案拍一張快照，這個機制叫 checkpoint（檢查點）。真的反悔了，把輸入框清空、連按兩下 Esc（或直接打 /rewind），會跳出一個「回到過去」的選單：

（選單實際文字可能依版本略有出入，意思大同小異，照畫面上看到的選就好。）

4.4　修 bug 實戰：把紅字錯誤整段貼給它

程式出錯時，畫面上常會冒出一大段紅色的英文字（叫「錯誤訊息」），看起來嚇人，但對 Claude 來說那是最好的線索。修 bug 最快的方法，就是把那段紅字整段複製起來，原封不動貼給它，然後問它一句話。

跟著做一遍，你會發現修錯誤比想像中簡單：

1. 1
   ✋動手做

   把整段紅色錯誤訊息複製起來

   在終端機或畫面上，用滑鼠把那段紅字從頭到尾選起來複製。不用挑、不用刪，整段一起帶走最好——你看不懂沒關係，它看得懂。

2. 2
   ✋動手做

   貼回 Claude，後面附一句話

   把剛剛複製的錯誤訊息貼進 Claude 的輸入框，接著在後面打一句你的請求，按 Enter。最簡單就這樣問：

   這是什麼問題？幫我修。

   複製
3. 3

   等它自己追根究底

   它會自己去搜尋相關檔案、找出問題的根本原因，然後提議修法（一樣會給你 diff，你照 4.3 那樣批准就好）。

   ✅ 預期會看到

   # 它會先回報它找到的原因，再提議修改
   找到問題了：login.js 第 42 行少了結尾的括號。
   我來幫你補上，請看以下修改：

   複製

有時候你只看得到「怪怪的症狀」、根本沒有錯誤訊息可以複製，那也沒關係——直接用講的描述你看到什麼就行：

我按下「儲存」按鈕之後完全沒反應，幫我找出原因。

它一樣會自己去查：搜尋相關檔案 → 找出根本原因 → 修好給你看。你只要負責描述「哪裡怪怪的」。

修 bug 修久了，你會慢慢摸出幾招老手才知道的問法，能讓它抓根因抓得更快、更準：

💡 範例：把「消音陷阱」擋掉的問法

建置（build）失敗，錯誤訊息如下：
[貼上完整錯誤訊息]
幫我修好，並確認建置能成功。
要修根本原因，不要只是把錯誤壓下去。

4.5　做一個新功能（完整示範）

修 bug 會了，「無中生有做一個新功能」也是一模一樣的套路——用講的就好。比方說，你想要一個會員註冊表單，直接這樣交代它：

幫我做一個會員註冊表單，需要驗證 email 格式是否正確。

它會先幫你規劃做法 → 跨好幾個檔案把程式寫好 → 再驗證它能不能正常運作。整個過程你都會看到 diff，每一步都可以批准、也可以隨時喊停說「先停一下」。換句話說，你全程握著方向盤，它負責踩油門。

4.6　給它看檔案、圖片、截圖、網址

光用打字描述有時候不夠——你手上可能有一張設計稿、一張錯誤截圖、或一份線上文件想給它參考。Claude Code 這些都收。下面這張表整理了常見的幾種「餵料」方式，挑你需要的用。

順道一提，上面這張表都是「你主動把東西送過去」的做法。很多時候其實不用這麼麻煩——你只要用講的告訴它「我要哪些資訊」，它自己就會動手用終端機指令去查，不一定要你先找到、複製、貼過去（回頭想想 4.1 提到的，它本來就看得到整個專案）。上面這張表比較像是「我要確保它一定有看到這個東西」時的手動保險，需要才用，不是每次都必要。

還有一個小細節，順便知道就好：用 @ 引用單一檔案時，除了那個檔案的完整內容，它也會順便載入這個檔案所在資料夾、以及上層資料夾裡的 CLAUDE.md（如果有的話）。也就是說，你 @ 一個檔案，其實同時也把「這個區塊的專案規則」一併帶進來了，不用你自己再額外交代一次。

貼圖片這個動作，不同系統手法略有不同。切到你的系統看對應做法：

# WSL 裡貼上圖片，用 Alt + V（不是 Ctrl + V）

一次對話裡，你不是只能丟一張圖——需要的話可以同時貼好幾張進同一句話，例如「這是修改前後的兩張截圖，幫我確認差異」。問法也不用想得太複雜，照你想知道的直接問就好：

💡 圖片分析，幾種常見問法

這張圖顯示的是什麼？
說明一下這個畫面上有哪些介面元素。
這是錯誤訊息的截圖，可能是什麼原因造成的？
照這張設計稿，幫我寫出對應的 CSS。

如果你常常要它讀同一類網址（例如同一個 API 文件站），每次都要它先問過你會有點煩——這種常用網域可以先加進白名單，之後就不用每次都確認。這招要用到 /permissions，第 7 章會完整教。

4.7　對話太長怎麼辦：上下文（context）與壓縮

跟它聊久了、做了一堆事之後，你可能會聽到「上下文（context）」這個詞。別被名字嚇到，它就是 Claude 的「工作記憶」——裡面裝著這次對話的內容、它讀過的檔案、指令的輸出、CLAUDE.md（第 5 章會講）等等。重點是：你用得越久，這個記憶就越來越滿。

當記憶快滿的時候，下面這幾個指令會派上用場：

再多知道兩個小工具，現在記個大概就好：如果只是想問一句跟目前任務無關的小問題（例如「這個縮寫的全名是什麼」），不想讓它也擠進正式對話紀錄，可以打 /btw，它會另外開一個小視窗回答你，不會污染 context，也不用特地 /compact。另外，如果任務本身就需要它讀非常多檔案（例如「幫我搞懂整個專案的權限設計，寫一份說明」），與其在目前對話裡硬讀到記憶塞滿，之後你會學到可以把這種大範圍調查外包給一個獨立的分身（術語叫子代理／subagent，第 10 章會細教）——它自己在另一個乾淨的空間裡讀個夠，只把整理好的結論帶回來給你，你的對話記憶完全不受影響。

還有一種常見情況：你今天做到一半，想明天再接著做，又不想每次都重講一遍前因後果。這時候有兩個好用的開關，讓你直接接回之前的對話。

💡 接續用：接回這個資料夾最近一次的對話

claude --continue

💡 接續用：從清單裡挑一段舊對話接回去

claude --resume

小提醒：如果你已經在 Claude 裡面（不是在終端機外面），想挑舊對話接續，直接打 /resume 也可以。

最後補一個進階小撇步，看過知道有這回事就好、現在不用記。如果你想直接把某個檔案的內容餵給一段新對話來處理，可以用「管線」一行搞定：

# 把 error.log 的內容直接餵給 Claude 處理
cat error.log | claude

這行的意思是「把 error.log 這個檔案的內容，直接交給 Claude」——跟 4.6 表格裡那招是同一個道理，只是這次是在終端機一行打完。看不懂沒關係，需要的時候再回來查。