跑第一個真實任務:讓 Claude Code 在你的 repo 修一個 bug

學新工具最容易卡在「讀完文件才敢動」。這一課不這樣。我們挑一個你本來就要處理、又夠小的東西，直接讓 Claude Code 在你的 repo 跑一次完整迴圈。

第一步：挑對第一個任務

好的第一個任務有三個特徵：範圍小、有明確驗收、做錯容易回退。

適合的：修一個有重現步驟的 bug、補一段缺的測試、照現有 pattern 加一個小端點、把一個過時的 API 用法換掉。

先不要挑這種：橫跨半個系統的大重構、你自己都還沒想清楚怎麼做的設計、或會碰到 migration／部署的東西。第一次，要的是走完一圈，不是挑戰它的極限。

第二步：先把工作區弄乾淨

這是工程師專屬、但很多人第一次會忘的一步：在乾淨的 git 工作區開始。

先 commit 或 stash 你手邊的改動，最好開一個新分支。理由很簡單：Claude Code 會直接改你的檔案，你要能用 git diff 清楚看到它改了什麼、用 git checkout 一秒回退。乾淨的起點，讓「審查」和「反悔」都變便宜。

第三步：把任務講清楚

第一次別只丟一句「修一下登入的 bug」。把它講成它能照著做的樣子：

「使用者在 token 過期後按『重新整理』會白畫面。重現：登入 → 等 token 過期 → 點重新整理。我猜問題在 auth/session.ts 的 refresh 流程。幫我定位、修掉，並補一個涵蓋『過期後重新整理』的測試。改完跑 npm test 確認綠的。」

注意它包含了：現象、重現步驟、你的猜測(給它起點)、預期結果、怎麼驗(跑測試)。 講得清楚不清楚，結果差很多——這是下一階段「寫好任務」會深講的。

第四步：看著它跑，別走開

交出去後，Claude Code 會開始動：讀相關檔、提出改動、跑指令。第一次，留下來看——你會看到它怎麼定位、改了哪些檔、跑了什麼。

它要跑指令或改檔時，可能會停下來請你核准。第一次就一個個看過再放行，別急著全開自動。如果它要做你沒預期的事(例如改到不相關的檔、要跑破壞性指令)，喊停。為什麼這樣設、怎麼設，是「權限與 hooks」那一課的主題。

第五步：審 diff，別直接收

它說「好了、測試綠了」，你先別 merge。這一步是整條路線的核心習慣：

• git diff 從頭讀一遍它改了什麼——每一行都該是你看得懂、同意的。
• 自己再跑一次測試，別只信它說「綠了」。
• 想一下它沒改到的：有沒有漏掉的邊界情況、有沒有順手改壞別的地方。

AI 寫的 code 可能看起來很合理卻有 bug，或用一個其實不存在的 API 講得很篤定。讀 diff 不是不信任它，是你本來對任何 PR 都會做的事——code review。怎麼審得快又準，後面有一整課。

不滿意？直接告訴它哪裡不對、讓它改;或 git checkout 回退、把任務講得更清楚再來一次。反悔很便宜，這就是第二步弄乾淨工作區的回報。

你剛剛完成了什麼

你讓 Claude Code 在真實 repo 跑完了一圈：乾淨起點 → 講清楚 → 看它讀改跑 → 審 diff → 收或重來。這就是用 coding agent 工作的完整節奏，後面所有課都只是把這一圈做得更大、更可信。

下一課：第一次你靠猜告訴它「問題大概在哪個檔」。接下來學會讓它自己讀懂你的專案脈絡——你會發現，它越懂你的 codebase，你越不用手把手指路。

林子睿（編輯：廖玄同），《跑第一個真實任務:讓 Claude Code 在你的 repo 修一個 bug》，矽基前沿 [Si]gnals，2026-06-19。https://signals.tw/articles/claude-code-first-task/