身為一位接觸不到原始碼的 QA 工程師，我從能夠觀察到的行為著手——透過前端與後端。這通常給了我足夠的證據去重現缺陷、檢查請求與回應、比對環境、驗證修復。但 AI 功能讓這件事變得令人不安：當我對一個看起來一模一樣的版本重跑同一組測試，助理的行為卻突然不一樣了，怎麼辦？

這種差異未必代表模型換了或程式碼重新部署了。一條系統提示詞可以在不產生任何明顯前端變化的情況下改變行為，而從黑盒測試的角度，我可能沒有任何直接的方式看見那筆編輯。如果沒有人能告訴 QA：是哪個提示詞版本產出了這段回覆、它何時改變、為什麼改變、由誰核准，那麼好幾週的量測結果，可能被一個從我這一側幾乎完全不可見的變更整筆作廢。如果提示詞控制著產品行為，它就應該被當成一個有自己的變更歷史的行為相依。

1. 決定行為的提示詞需要版本號

一條提示詞決定了助理可以說什麼、該怎麼回應、該優先考量哪些資訊、何時應該拒絕——它實際上就是產品行為規格的一部分。下面的範例很好地捕捉了這個原則：提示詞有了識別碼、版本、內容雜湊、負責人與核准者。如果版本 1.4.0 的行為和 1.3.0 不一樣，QA 現在有具體的東西可以附在觀察記錄上，而不是寫著「回覆變了，但我不知道底層改了什麼」。

prompt_id: support_assistant.system
version: 1.4.0
content_hash: <hash>
owner: cx-qa
approved_by: <role>

當 QA 無法直接檢視實作時，這一點尤其重要。我不需要取得修改提示詞或原始碼的權限，也能從它透過發行說明、測試中繼資料、日誌或其他可追溯紀錄所公布的版本號中獲益。想像 Aurora Shop 在應用程式版本 v2.8.4 上通過了同一組迴歸測試，但它的助理突然開始給出更簡短的退貨政策說明。知道應用程式版本維持不變、而提示詞從 1.3.0 移動到 1.4.0，立刻就能縮小調查範圍。版本控管把一個不可見的行為變化，變成一個可測試的變數。

2. 變更說明要寫出理由與預期影響

版本號告訴我「有東西變了」；變更說明告訴我「因此我該測什麼」。每一次提示詞變更都應該記錄四項實用的資訊：改了什麼、為什麼改、預期會影響哪些行為或案例，以及評測集中哪個切面應該重跑。「改善助理的語氣」太含糊。「要求助理用更溫暖、更簡潔的方式回答；預期影響只給結論的回覆；重跑語氣、政策與短答案案例」才給了 QA 一個真正的測試方向。

理由本身也應該描述一個可以被檢查的結果，而不只是一個意圖。如果 Aurora Shop 因為客戶抱怨回覆太囉嗦而修改支援提示詞，QA 就能驗證回覆長度是否下降——同時沒有丟掉退款條件、保固限制或必要的下一步。這正是變更說明對黑盒 QA 的價值所在：變更不是我做的，但我知道它宣稱的目的與預期的爆炸半徑。我可以測試觀察到的行為是否吻合這個宣稱——以及宣稱範圍之外的東西，是否意外地跟著一起動了。

3. 迴歸卡如何擋下「只是調一下語氣」

像**「只是調一下語氣」**這樣的說法，能把一次提示詞變更講得雲淡風輕、彷彿無害。假設 Aurora Shop 在系統提示詞裡加入「溫暖且簡潔地回答」。助理可能真的變得更親切、更簡短，一切正如預期；但「簡潔」也可能害它漏掉一條保固條件，或把「商品於 14 天內可退貨」縮短成一句語義含糊的話。提示詞在技術上只改了風格；產出的行為卻改變了資訊。這就是為什麼即使是純措辭導向的變更，也應該先過相關的迴歸案例，才談核准。

因此，核准者的責任，不是判斷新的措辭讀起來是否更順眼。問題是：預期的行為改變了，而本來應該維持穩定的行為，有沒有跟著受損。語氣就用語氣的方式評，而正確性、合規、安全性與必要內容，各自保留自己的斷言。這種區分讓審查不至於流於個人品味：一句措辭的變更之所以通過，是因為它的行為後果可被接受，而不是因為核准者恰好喜歡新答案讀起來的感覺。

提示詞變更迴歸卡

上面的工件把一次提示詞編輯，變成一個小型的、可稽核的發行決策。這張卡記錄了從 1.3.0 → 1.4.0 的版本過渡、變更的確切內容與理由、受影響的評測案例、迴歸結果，以及核准的職務。更重要的是，這個範例本身示範了這套流程為何存在：一句看似簡單的「溫暖且簡潔地回答」指示，讓三篇只給結論的回覆變長，害一篇法規回覆漏掉了一個數字——於是迴歸未通過。對沒有程式碼權限的 QA 而言，這張卡補上了缺失的那一環：把觀察到的行為變化，與造成它的設定連結起來。我不需要親自編輯提示詞，也能驗證它的變更確實產生了後果。

紀錄的強度，取決於紀錄周圍的流程

這仍然有一個重要的極限。**迴歸卡能擋下的，是確實走過這張卡的危險變更；它擋不走繞過它的變更。**它也無法證明評測集具有代表性——如果整個情境類別根本缺席，一份乾淨的迴歸結果反而會製造虛假的信心。而且這套流程假設版本號的跳升是誠實的：如果有人直接對線上提示詞施展熱修，不開新版本，可追溯性就消失了。從 QA 的角度看，那是時間軸上最危險的一段空白：輸出動了，紀錄中的版本沒動，而我沒有程式碼權限去解釋中間發生了什麼。