一、先承認現實：第一次不會動，是常態

Day 10 結尾預告過：QuickPizza 一次就通，是因為它為教學而生。真實系統的登入流程，AI 生成的腳本第一次執行幾乎都會失敗。原因不是 AI 不夠聰明，而是結構性的：AI 依你的描述寫腳本，但你的描述來自文件或印象——而文件會過時、回應結構跟想像不同、token 可能藏在 cookie 而非 JSON、中間可能多一層 CSRF 或一次跳轉。描述與現實的落差，就是腳本與現實的落差。

所以請把心態調到正確的頻道：腳本第一次失敗不是意外，是除錯流程的正式開始。會不會除錯，才是「用 AI 寫腳本的人」之間真正的分水嶺——而除錯是可以學的方法，不是天分。

二、核心心法：讓看不見的變看得見

效能腳本除錯和功能測試最大的差別：沒有畫面。瀏覽器上你看得到錯誤訊息、載入狀態，腳本裡只有一片沉默的數字。所以除錯的第一原則就是把看不見的印出來。三層透視工具，由淺入深：

圖 1：三層透視——checks 先看、console.log 主力、http-debug 最後手段

進入除錯前，先把腳本切到「除錯模式」——這是每次除錯的固定起手式：

export const options = {
  vus: 1,          // 除錯用一個人就好
  iterations: 1,   // 只跑一輪——問題會重現一次,輸出乾淨
};

然後在可疑的位置加上觀察點，印出狀態碼與回應的前兩百個字：

const login = http.post(/* ... */);
console.log('登入狀態碼:', login.status);
console.log('登入回應:', String(login.body).substring(0, 200));

第三層的 --http-debug 會印出完整的請求與回應往來，威力最大、資訊也最氾濫（而且會把 token 全裸印出），留到前兩層都看不出所以然時再用，見第六節。

三、帶著 AI 除錯：四步循環

圖 2：縮小、看見、描述、只改一處——循環的燃料是看見的事實，不是猜測

• 縮小：1 VU、1 輪。用 50 個 VU 除錯只會得到 50 份重複的噪音，還順便轟炸目標系統
• 看見：console.log 印出關鍵位置的實際值。猜十次，不如印一次
• 描述：把「我在做什麼、預期什麼、實際看到什麼（原文照貼）、已試過什麼」四件事講給 Claude Code。描述的品質決定假設的品質
• 只改一處：AI 可能一次給三個建議——挑一個最可能的，改一個地方，重跑。同時改三處，好了也不知道是哪個治好的，下次遇到還是不會

第三步的描述有固定樣板，值得存起來每次套用：

除錯 prompt 樣板（可存成 debug-template.md 重複使用）
我的 k6 腳本出了問題，請幫我分析：
1. 我在做什麼：（例：登入後帶 token 呼叫 /api/ratings）
2. 我預期：（例：check 全過、狀態碼 200）
3. 實際情況：（貼上 k6 輸出的相關段落＋console.log 的原文）
4. 我已經試過：（例：確認過網址沒錯）
請先列出可能原因的排序，再建議「第一個該檢查什麼」——
先不要直接改我的檔案。

最後那句「先不要直接改」和 Day 4 必問三的設計相同：讓 AI 當顧問而非駕駛，你保有每一步的理解與掌控。等你確認了方向，再讓它動手也不遲。

四、實戰演練：兩個典型故障，完整走一遍循環

真實系統的故障沒辦法搬進教材，但故障的「型」可以。我們把 Day 10 好好的 login-flow.js 依序弄壞成兩種最常見的症狀，各走一次四步循環——修過的故障型，實戰遇到就認得。

故障一：401——撈錯欄位的經典案

動手製造：把 setup 裡撈 token 的那行改掉（模擬「以為欄位叫 access_token」的常見誤會）：

// 原本:const token = login.json('token');
const token = login.json('access_token');   // 弄壞:撈一個不存在的欄位

跑起來 checks 顯示「帶 token 可以進門」全滅。走循環：已經是單 VU 了（縮小），加上觀察點（看見）：

console.log('撈到的 token:', token);
console.log('登入回應原文:', String(login.body).substring(0, 200));
INFO[0001] 撈到的 token: undefined
INFO[0001] 登入回應原文: {"token":"eyJhbGciOi..."}

兩行輸出，真相大白：撈到的是 undefined，而回應原文裡欄位明明叫 token。這條因果鏈值得完整看一次，因為它是關聯除錯裡最高頻的一型：

圖 3：401 的因果鏈——JavaScript 撈不到欄位不會報錯，undefined 一路默默走到伺服器門口才被拒

把觀察結果套進樣板描述給 Claude Code（實際情況欄貼上那兩行輸出），它幾乎必然指出「欄位名不符，應撈 token」。改回正確欄位、重跑、全綠——然後把 console.log 移除。一次完整的循環結束。

故障二：404——最笨的可能，最常是真相

動手製造：把登入網址結尾少打一個字母（login 改成 logi）。跑起來換「登入成功(200)」失敗了。觀察點印出來：

INFO[0001] 登入狀態碼: 404
INFO[0001] 登入回應原文: 404 page not found

404 的意思是「這個地址不存在」。此時最有效率的除錯動作平凡得令人失望：把腳本裡的網址和文件裡的逐字元對照一次。網址錯字、多一個斜線、環境網域貼錯——這類「最笨的可能」在實戰裡的破案率高得驚人。給 AI 之前先自查三十秒，很多循環根本不用開始。修好、重跑、移除觀察點。

兩個故障演練完，你會發現循環的節奏是一樣的——變的只是症狀與線索。這就是「型」的價值：方法固定，見招拆招。

五、症狀速查：實戰常見變化型

以下把登入與關聯除錯最常見的症狀整理成速查表。用法：對照症狀找到可能原因，把對應的線索補進除錯 prompt 的「實際情況」欄：

表裡最後兩列就是 Day 10 提過的「真實系統更複雜」的具體樣貌：形態誤判（以為是 JSON API 其實是表單）與多步驟關聯（CSRF）。它們不需要你會寫——需要你認得出症狀、講得出流程，實作交給 AI，驗證交給循環。

六、終極透視：--http-debug

前兩層看不出所以然時，開最後一層——讓 k6 印出每一次請求與回應的完整內容：

# 基本版:印 headers
k6 run --http-debug login-flow.js
 
# 完整版:連 body 一起印(資訊量更大)
k6 run --http-debug="full" login-flow.js

兩個鐵則。第一，務必在單 VU 單輪模式下用，否則輸出會多到淹沒一切。第二，它會把 Authorization、Cookie 等機密 headers 原文全裸印出——這份輸出貼給 AI 或截圖回報前，先把機密抹掉。它最擅長回答的問題是「我以為我送了什麼」與「我實際送了什麼」的差距——例如 header 到底有沒有帶上、跳轉之後請求變成了什麼樣子。

七、注意事項：除錯的紀律

給 RD 的一句話：QA 帶著「四步循環的紀錄」來求助時——做了什麼、看到什麼、試過什麼——請把這視為高品質的求助，值得優先處理。反過來，這個循環也完全適用於你收到的任何 bug 回報格式要求；兩邊用同一套語言，來回次數會少一半。

八、觀念驗證：三個問題確認你有帶走今天的重點

• 為什麼「撈不到的欄位」不會當場報錯，而是變成 401 才被發現？沿著因果鏈說一次。（第四節故障一）
• AI 一口氣給了三個修改建議，同事想全部一起改「比較快」——你會怎麼勸？賭注是什麼？（第三節、第七節）
• 要把 http-debug 的輸出貼給 AI 分析之前，必須先做什麼？為什麼這一步不能省？（第六節、第七節）

九、小結

今天拿到的是整個系列最保值的元技能：四步除錯循環——縮小、看見、描述、只改一處。兩個親手修過的故障型（撈錯欄位的 401、錯字的 404）給了你實戰的手感，症狀速查表則涵蓋了 403、400、表單跳轉與 CSRF 這些之後會遇見的臉孔。記住循環的燃料是看見的事實：猜十次不如印一次，而 AI 拿到的事實越具體，給你的假設就越準。這套方法不只修 k6 腳本——它修一切。

附錄：除錯速查

// 除錯模式起手式
export const options = { vus: 1, iterations: 1 };
 
// 觀察點:狀態碼+回應前 200 字
console.log('狀態碼:', res.status);
console.log('回應:', String(res.body).substring(0, 200));
 
// 觀察 token 但不外洩:只印長度
console.log('token 長度:', token ? token.length : 'undefined!');
 
# 終極透視(單 VU 單輪+注意機密)
k6 run --http-debug login-flow.js
k6 run --http-debug="full" login-flow.js

除錯 prompt 四要素：我在做什麼、我預期什麼、實際看到什麼（原文照貼）、我已試過什麼——外加一句「先不要直接改」。