前言
昨天我們組裝出了第一版完整範本。今天要做的事,是這 30 天裡最關鍵的「見真章」時刻——拿真實的一週資料,實際測試這份範本到底撐不撐得住。
在動手測試之前,有一件事必須先確認清楚,而且順序不能顛倒。

一、測試前的必要檢查:機敏資料規則有沒有落實
回顧 Day 13,我們特別強調機敏資料的處理原則,必須在使用真實資料之前就先確立。今天就是那個「使用真實資料」的時刻,所以在丟出第一筆真實資料之前,請先重新確認:

• 資料裡是否包含個資、內部系統帳號、實際 IP 位址等機敏欄位?
• 這些欄位是否已經按照 Day 13 訂下的規則,做了遮蔽或替換處理?
• 你所使用的公司 AI 工具,本身的資料使用與保存政策是否符合公司規範?(這一點如果還沒確認過,建議先跟資安規範或主管確認清楚,而不是假設「應該沒問題」)
  這一步花的時間不會太長,但它是這整個系列文章裡,唯一一項「做錯了無法挽回」的環節——格式跑掉可以重寫,語氣不對可以調整,但機敏資料一旦外流,是無法收回的。確認過這一步,才進入下面的測試流程。
  二、壓力測試該怎麼設計:不要只測「正常情況」
  很多人測試時,直覺會用「一份看起來乾淨、正常的資料」去跑一次,看結果順不順眼就結束了。但這種測試方式,只驗證了範本在「最理想狀況」下能不能運作——沒辦法告訴你,範本在真實世界裡遇到意外狀況時,會不會出包。
  建議至少設計以下幾種測試情境:

1. 正常情境:資料完整、量級適中的典型一週,確認基本格式與內容是否符合預期
2. 資料量偏多的情境:如果剛好有一週事件特別多,測試看看 Day 14 談的 Token 額度問題會不會出現,以及 Day 15 的預處理是否有效發揮作用
3. 資料缺漏的情境:刻意拿掉某個欄位或某幾筆資料,驗證 Day 11、12 的防呆規則是否真的生效,而不是被 AI 忽略
4. 無歷史比較資料的情境:如果本週沒有提供上週的比較數據,驗證 Day 17 的趨勢判斷規則,是否誠實回報「無法判斷」,而不是硬猜一個方向
   三、測試時該怎麼記錄,而不是「看過就算」
   壓力測試最容易失敗的地方,不是測試本身,而是測試完就結束了,沒有留下紀錄。建議每次測試,至少記下以下資訊:

• 這次用的是哪種測試情境(對照上面四種分類)
• AI 的實際輸出結果(截圖或存檔)
• 輸出跟 Day 5 品質檢查清單相比,哪裡符合、哪裡不符合
• 如果不符合,具體是哪一句規則沒有生效,或是規則本身有漏洞
  這份紀錄,會直接成為明天 Day 21 除錯階段的第一手資料——沒有具體紀錄,除錯就只能憑印象猜,這正是我們整個系列一直在避免的「憑感覺」做法。
  四、遇到問題時,先別急著大改範本
  如果測試發現輸出不符合預期,先忍住「乾脆整份重寫」的衝動。回顧 Day 24 會更完整談這個心法,但這裡先提前預告一個原則:先定位問題出在哪一條具體規則,只調整那一條,再重新測試同一個情境,確認問題有沒有解決。 一次改動太多地方,你會搞不清楚到底是哪個改動真正解決了問題,也可能不小心改壞了原本運作正常的部分。
  五、今天的行動練習
  依照今天的四種測試情境,實際準備對應的測試資料(可以用真實資料,搭配人工修改製造出缺漏或異常的版本),完整跑過一輪測試,並依照上面的紀錄格式,把每次的結果記下來,準備進入明天的除錯階段。

小結
今天是理論碰撞現實的一天。前 19 天建立的所有規則,終於要拿到真實世界裡接受考驗。記得測試前先確認機敏資料規則已經落實,測試時不要只測正常情況,更要包含 Day 14 到 Day 17 談過的各種例外情境,並且確實留下紀錄——這份紀錄,就是明天除錯工作最重要的基礎。
明天,我們會針對今天測試中發現的問題,逐一拆解「格式跑掉」「內容遺漏」「語氣不對」這三類最常見的狀況,該怎麼具體修正。