Claude Code 工作流程指南

你說想要什麼 → 它先理解 + 必要時反問 → 給你選項(優缺點)→ 你決定 → 它做
                                                                    ↓
                                                              你看結果 → 給回饋 → 它修

你不需要會寫程式。你需要的是:

會描述問題(不要只說「這個壞了」,要說「我點下載按鈕,結果寬度比下面的按鈕還寬」)
會做決定(它給你 A/B/C,你選一個並說為什麼)
會給回饋(看到結果,直接說「這段太硬」「這個沒對齊」)

二、從「能動」開始迭代,不是「完美」才上線

ChompPDF 的版本歷史:

v1.0  (2026-04-24) 最簡版,能壓就好
v1.1  加觀看解析度模式
v1.2  自動最佳化
v1.3  修 macOS Preview 顯示問題
v1.4  整體 UI 重做(Soft Candy 主題)
v1.4.1~1.4.9  各種小修(掃描檔誤判、文字遮色片、JPX 編碼...)
v1.5.0  大改:整個搬進 Web Worker(UI 不卡)
v1.5.1  Worker pool 並行(壓更快)
v1.5.2~1.5.4  效能調校 + bug 修

重點:每個版本只動一兩件事。這樣壞了能退回、好處看得到。

三、大改之前先談、別讓它直接動手

任務類型	做法
小修(改文字、對齊按鈕、修 typo)	直接說、它直接改
中修(加新功能、改邏輯)	先描述清楚目標,給它一兩個重點檔案
大改(架構重構、整段重寫)	先進 Plan mode 討論,確定方向再動

Plan mode 是 Claude Code 的功能 — 在這個模式下它只會討論不會動手。等你 OK 才開始實作。

真實對話案例(從 ChompPDF 故事抓的)

案例 1:模糊需求 → 清楚規格

我說(三個字):

壓更快

它沒有直接動手。它回:

「『更快』有 4 種做法,各有取捨,你要選哪個?」

A. 加 worker pool 並行(中等複雜、整體 2-3x) B. 整個搬進 worker(低複雜、UI 不卡但不一定快) C. WebGPU 加速(高複雜、不確定收益) D. WASM threading(高複雜、需特殊伺服器設定)

我推薦 A+B 一起做(B 是 A 的前置)。

我選了 B(優先「不卡」)+ 之後再做 A。它再寫一份分階段計劃(8-11 天、4 個 phase),每個 phase 上線一個版本。

這段對話的價值:

我只丟三個字,但它逼我想清楚「什麼叫更快」(整體跑得快?還是 UI 不卡?)
給優缺點(SWOT),我做決定
自己拆計劃、估時間

案例 2:bug 回報的最高效寫法

我說(配截圖 + 一句話):

鯊魚恐龍不見了

它直接看截圖、抓出問題:

找到了。shrinkViaWorker(worker 模式)只 call setProgressDisplay(只更新 % 文字),沒接到 mascot 的 startRace / setProgress / declareWinner。所以 worker 模式下 mascot CSS 變數從沒被設過,動畫永遠不啟動。

修完推 v1.5.3,告訴我重載瀏覽器測試。從報問題到修好不到 5 分鐘。

為什麼這麼快?

截圖讓它直接看到「沒有恐龍 / 鯊魚」
它有完整對話脈絡(知道我們剛做完 worker 化)
我沒花時間「整理問題描述」,就一句話 + 圖

案例 3:它做錯事時怎麼處理

實作 Phase 2 重構時,它幫我把一堆程式碼搬進 worker,但搬漏了 _newCanvas、applyTiffPredictor、validateMaskRefs 等函式。

我跑起來看 console:

Error: _newCanvas is not defined

我把錯誤訊息直接貼給它(不需要解讀)。它先補上,推新版。

但又跳新錯:applyTiffPredictor is not defined。

第三次後我留下教訓,它寫了一個 audit script 主動掃「被呼叫但沒定義」的東西,一次抓完。

心得:它會犯錯,但你不用幫它擦屁股 — 直接把錯誤訊息丟回去,它自己會抓根因。

過程中要小心的事

1. 它會自信地犯錯

它寫程式很快,但有時抓錯方向
解法:大事用 sub-agent 先研究(像派個小幫手調查),再動手
我自己跟它的踩坑紀錄裡有條規則:「派 sub-agent 研究再動手」— 防它自作主張

2. 它看不到你看到的

它沒有眼睛,看不到你的瀏覽器、檔案
解法:截圖(它能看圖)+ 貼 console log(原始就好不用整理)+ 講具體位置

3. 它有時會修錯地方

你說 A 壞了,它可能順便動 B(以為你想改進整體)
解法:每改一件事就 commit(存檔)。壞了能退回。我們專案 100+ 次 commit,每次只動 1-2 件小事

4. 不要等它「自己想到」

它沒有主動 review 的習慣
你要明說:「請 review 一下」、「請寫測試」、「請查一下這個怎麼做才對」

5. 截圖 + console log 是最強回饋

看到什麼貼什麼,越原始越好,不用整理
這次專案最有效率的修 bug 都是「貼 log → 它指路」

用 ChompPDF 為例,從零到上線的全紀錄

TL;DR(三句話版)

核心觀念

一、Claude Code 是「合作對象」不是「下單系統」