轉念學 – 敏捷三叔公的學習之旅

網路上有一篇 PerfMatrix 的文章《Prompt Engineering for Performance Testing》，列出了六個 prompt 技巧。這六個技巧本身不新——它們是 prompt engineering 領域的共識。但對效能測試人員來說，這六個技巧如果只停留在「通用建議」的層次，幫不上忙。

舉個例子，文章說「Be explicit（明確指定）」，並給了一個例子：「Write three bullet points about solar power in 50 words.」這個例子寫文章夠用，但你拿去寫 k6 腳本是完全不夠的。

這篇文章把每個技巧拆解成三層：它真正在解決什麼問題、效能測試情境的具體做法、以及容易踩的坑。每個技巧都配一組「差版本 vs 好版本」的對照，讓差異看得見。

技巧 1：Be Explicit（明確指定）

它在解決什麼問題

AI 拿到模糊的需求時，會用「最常見的解法」當答案。但效能測試的「最常見」往往不是「你要的」。

例如你說「幫我寫一個 k6 腳本測試登入 API」，AI 會給你最常見的版本——10 個 VU、跑 30 秒、用 vus + duration、沒有 threshold。這個腳本能跑，但跟你要做的「驗收測試」、「容量規劃」、「尖峰負載模擬」完全不是同一件事。

效能測試情境的明確要素

一個合格的效能測試 prompt 必須講清楚這幾件事：

• 負載模式： constant load、ramping、spike、soak、stress 哪一種
• 負載量： 多少 VU、多少 TPS、多少 RPS
• 時間長度： ramp up、steady state、ramp down 各多久
• 及格線： p95、p99、錯誤率、throughput 的目標
• 執行環境： 本機跑、CI 跑、還是分散式跑
• 資料來源： 寫死、CSV、API 取得、隨機產生

✗ 模糊版本 幫我寫一個 k6 腳本測試登入 API

✓ 明確版本 幫我寫一個 k6 腳本，用 ramping-vus 從 0 升到 100 VUs 花 2 分鐘，維持 100 VUs 持續 5 分鐘，再降到 0 花 1 分鐘。測試 POST /api/login，p95 < 800ms，錯誤率 < 1%。

容易踩的坑

有些人覺得「明確 = 把所有細節都寫出來」，於是 prompt 寫了三頁。這反而會稀釋 AI 的注意力。

明確的真正意思是：把『會影響輸出結果的關鍵決策』寫清楚，不會影響結果的細節（例如變數命名、註解風格）就放手讓 AI 決定。

一個檢查法是：如果你把 prompt 中某一句拿掉，AI 給你的腳本結構會明顯不同嗎？如果不會，那句話就是廢話。

技巧 2：Give Context（提供脈絡）

它在解決什麼問題

AI 不知道你的系統長什麼樣。沒有脈絡，它只能用「教科書範例」回答。教科書範例的問題不在於它錯，而在於它「無關」——它沒對準你的真實場景。

效能測試特別需要脈絡，因為「同樣的 API、不同的脈絡，要寫完全不同的測試」。例如測試一個搜尋 API：

• 如果是內部後台用：10 個並行就夠了
• 如果是面對 C 端用戶：可能要模擬 5000 個並行
• 如果是黑五尖峰：要模擬瞬間 50000 個並行

少了脈絡，AI 沒辦法幫你選對的測試模型。

效能測試該餵的脈絡有哪些

• 系統現況： 目前生產環境的 RPS、響應時間分佈、錯誤率
• 使用者行為： 平均 session 長度、每個 session 多少 transaction、think time
• 技術選型： 後端語言、資料庫、是否有 cache layer、是否有 CDN
• NFR： 業務同仁要求的目標效能、SLA
• 既有資產： 既有的測試腳本、access log、APM 數據

✗ 沒脈絡 幫我設計一個電商網站的負載測試方案

✓ 有脈絡 我們電商目前日 PV 50 萬，尖峰時段（晚上 8-10 點）佔 40%，平均 session 8 分鐘做 12 個動作，2 個動作會打到資料庫，後端是 Java + MySQL，目標尖峰時段 p95 < 1.5 秒。請設計負載測試方案。

一個常被忽略的脈絡：你的程度

如果你正在學 k6，把這件事也當成脈絡告訴 AI。例如：「我剛開始學 k6，請避免使用 scenarios、Httpx 等進階功能，先用最基本的 options + default function 寫法」。

AI 預設會用「最佳實踐」回答，但最佳實踐對新手來說常常太進階。把你的程度寫進去，AI 才會幫你選對的抽象層級。

技巧 3：Use Step-by-Step Cues（步驟化引導）

它在解決什麼問題

AI 有一個傾向：直接跳到「最終答案」。對簡單問題這沒問題，但效能測試常常需要「設計決策」，不是「複製範本」。

例如「幫我為 checkout API 設計負載測試」，AI 會直接給你一個 k6 腳本。但腳本背後該有的思考是：尖峰流量怎麼推算？要用 open model 還是 closed model？要不要做 spike test？這些決策被跳過了，你拿到的是「答案」不是「設計」。

Step-by-step 的價值在於：強迫 AI 把思考過程攤開。你看到它怎麼想，才有辦法判斷它想得對不對。

效能測試的標準思考步驟

你可以把這個步驟內建進 prompt：

1. 先分析 NFR 和業務目標，推算需要模擬的負載量
2. 選擇對應的 workload model（constant、ramping、spike、soak）
3. 設計 think time 和 pacing
4. 設計 threshold（pass/fail 標準）
5. 寫 code
6. 列出測試前要確認的事項

✗ 直接要答案 幫我為 checkout API 寫負載測試腳本

✓ 步驟化思考 為 checkout API 設計負載測試。請依序： (1) 從以下 NFR 推算目標 TPS； (2) 說明你選擇哪種 workload model 及理由； (3) 設計 threshold； (4) 寫 k6 腳本； (5) 列出執行前要確認的事項。

步驟化的副作用：可以中途換手

還有一個少人提的好處：當 AI 把步驟攤開，你可以在「某一步」介入修改。

例如 AI 在 Step 2 選了 constant load，但你知道實際場景應該用 ramping。你只要說「Step 2 改成 ramping，其他重做」，AI 會把後續步驟調整一致。

這比「整個重寫」省力很多，也減少 AI 在重寫時引入新錯誤的機會。

技巧 4：Show a Sample Answer（給範例）

它在解決什麼問題

用文字描述「風格」很難。例如「請用乾淨的程式碼風格」——什麼叫乾淨？每個 AI 模型、甚至同一個模型不同次回答，對「乾淨」的詮釋都不一樣。

最快的方法是直接給範例。AI 看到範例後會「模仿」結構、命名、註解習慣、抽象層級。這在中文圈有個更白話的說法：「示範勝過解釋」。

效能測試情境下，範例最有用的地方

• 腳本骨架： group 怎麼切、check 寫多細、註解風格
• 命名慣例： 變數、threshold 名稱、tag 名稱
• 報告格式： 結果分析報告該包含哪些段落、用什麼語氣
• 錯誤處理風格： 用 fail、throw、還是只記 metric

login_test.js實際的做法是這樣——假設你已經有一個寫得不錯的腳本叫

我有一個既有的 k6 腳本當風格範本：   [貼整個 login_test.js 的內容]   請依照同樣的風格（包括 group 的切法、check 的寫法、threshold 的命名） 幫我寫一個測試 checkout 流程的腳本。

不到 2 秒鐘的複製貼上，AI 給你的腳本就會跟你的既有風格高度一致，省下你後續格式化的時間。

一個進階用法：給「反例」

除了給好範例，給壞範例也很有用。例如：

請寫一個 k6 腳本。注意不要寫成下面這種我不喜歡的風格：   [貼一個沒有 group、沒有 check 的爛腳本]   我希望腳本必須有 group 區隔、每個請求都有 check。

這個技巧叫「contrastive prompting」（對比提示）。它在「你說不出你要什麼，但你說得出你不要什麼」的情境特別有效。

技巧 5：Ask for Reflection（要求自我檢查）

它在解決什麼問題

這是六個技巧裡「對效能測試人員最重要」的一個，但也最常被忽略。

AI 最危險的特性是：它用同樣自信的語氣講「對的事」和「錯的事」。沒有反思的 prompt，你拿到的回答看起來都對。等到實際跑腳本，才發現裡面藏了 AI 自己也沒把握的部分。

反思要求 AI 主動「攤開不確定性」。它不再是給你一個「答案」，而是給你一個「答案 + 警告」。

效能測試該要求 AI 反思什麼

• 假設清單： 「你做了哪些假設？例如 think time、pacing、token TTL」
• 不確定的地方： 「哪些 API 或寫法你不完全確定？建議我查哪個文件？」
• 風險點： 「這個腳本實際跑起來，最可能在哪裡出問題？」
• 替代方案： 「你選了 SharedArray 而不是別的，為什麼？另一種做法是什麼？」

✗ 沒要求反思 幫我寫腳本測試 checkout 流程

✓ 要求反思 幫我寫腳本測試 checkout 流程。寫完後額外列出： (1) 你做了哪些假設？ (2) 哪些寫法你不完全確定，建議我查哪個官方文件？ (3) 實際跑起來最可能在哪裡出問題？

這個技巧為什麼特別重要

文章原本說 reflection 是「讓 AI 檢查自己的答案」。但對效能測試人員來說，它的價值不只是「檢查」，而是「揭露 AI 的盲點」。

這跟你做 AI 生成測試案例品質管控的核心精神是一樣的——AI 的輸出永遠要過一道驗證關卡。反思就是把這道關卡內建到 prompt 裡，讓 AI 自己先做第一輪 self-review。

更進階一點，你甚至可以要求 AI 用「對抗思維」反思：「假設你是這個腳本的 reviewer，你會挑出哪三個問題？」這個角度比「列假設」更尖銳，能逼出更多隱藏問題。

技巧 6：Iterate and Refine（迭代精煉）

它在解決什麼問題

一次寫對 prompt 是不可能的。原文說「測試輸出、檢視、調整 prompt 直到結果對」——這句話對，但太抽象。實際做的時候，多數人會犯兩個錯：

• 錯誤一： 整個 prompt 砍掉重寫。這樣每次都是賭一把，你不知道是哪個改動造成輸出變好或變壞。
• 錯誤二： 只看「滿不滿意」這種模糊的標準。「不滿意」沒有可操作性，下一步該改什麼說不出來。

用效能測試的紀律做迭代

這是六個技巧裡，效能測試人員最有優勢的一個——因為效能測試的核心紀律就是「控制變因」，這個紀律可以直接搬到 prompt 設計。

做法一：一次只改一個變數

如果腳本太長，只加「請精簡到 30 行」。如果 check 不夠多，只加「每個請求至少要有兩個 check」。不要一次改五件事，否則你不知道是哪一改動造成差異。

做法二：定義可量化的評分

把「滿不滿意」變成 checklist。例如：

• 腳本能不能不改任何東西就跑起來？
• 有沒有完整的 check？
• 有沒有 threshold？
• 有沒有處理 token / cookie / correlation？
• 有沒有 sleep / think time？

每次迭代後逐項打勾。哪一項沒過，下一輪只針對那一項改 prompt。

做法三：把成功的 prompt 存起來

好的 prompt 跟好的測試腳本一樣，是資產。建議放進 Git，跟測試腳本一起做版控。久了你會有一個「prompt 庫」，下次寫類似測試直接套用。

✗ 整個重寫 AI 給的腳本不滿意，重新打一個更長更詳細的 prompt 從頭開始

✓ 控制變因 AI 給的腳本可以跑但 check 不夠，只加一句「請每個請求加上至少兩個 check：status 和 response body 欄位」，重跑

一個被忽略的迭代維度：跨模型測試

同樣的 prompt 餵給 ChatGPT、Claude、Gemini，結果會不一樣。如果你發現某個 prompt 在 A 模型上效果差，先別急著改 prompt——試試 B 模型。

這跟效能測試「同樣的測試在不同環境跑、結果不同」是一樣的道理。把模型當成另一個變因納入控制。

把六個技巧串成一個完整 Prompt

最後，這六個技巧不是六選一。一個成熟的效能測試 prompt 會同時用到大部分，甚至全部。下面是一個整合範例：

[Context – 技巧 2] 我們電商系統，目前 PV 50 萬/日，尖峰時段 8-10 點佔 40%， 後端 Java + MySQL，使用者平均 session 8 分鐘 12 個動作。 我學 k6 兩個月，會基本語法但沒寫過 scenarios。   [Sample – 技巧 4] 我有一個既有腳本 login_test.js 當風格範本： [貼程式碼]   [Task – 技巧 1 明確指定] 寫一個 k6 腳本測試 checkout 流程，使用 ramping-vus， 0→300 VUs 用 5 分鐘，維持 300 VUs 持續 10 分鐘， 降到 0 用 5 分鐘，p95 < 1500ms，錯誤率 < 0.5%。   [Steps – 技巧 3 步驟化] 請依序： 1. 從 NFR 推算 TPS（用 Little’s Law） 2. 說明你選擇的 workload model 及理由 3. 設計 threshold（包含對單一 endpoint 的 threshold） 4. 寫腳本 5. 列出執行前要確認的事項   [Reflection – 技巧 5 反思] 寫完後請額外輸出： – 你做了哪些假設？ – 哪些 k6 API 寫法你不完全確定，建議我查哪個官方文件？ – 這個腳本實際跑起來最可能在哪裡出問題？   （技巧 6 迭代精煉發生在拿到回答之後， 依 checklist 評分，只改不足的部分重跑）

結語

這六個技巧的共同精神，可以用一句話總結：把『隱性的期待』變成『顯性的指令』。

AI 不會讀心。你期待它寫出符合你風格的腳本？告訴它（技巧 4）。你期待它考慮你的系統現況？告訴它（技巧 2）。你期待它先思考再寫 code？告訴它（技巧 3）。你期待它誠實面對不確定性？告訴它（技巧 5）。

這個過程剛開始會覺得很囉嗦——「為什麼我要寫這麼多」。但你會發現，囉嗦的不是 prompt，是「平常你對自己也沒講清楚的需求」。Prompt engineering 真正在訓練的，是把模糊的工作需求拆解清楚的能力。這個能力對效能測試人員特別有用，因為效能測試本身就是一個「需求模糊就會做歪」的領域。

六個技巧不必一次全用，但建議從技巧 1（明確指定）和技巧 5（反思）開始。這兩個對輸出品質的提升最直接，也最容易看到差別。