Day 3｜測試全綠，為什麼未列地區的稅卻是 0？

Day 2 把同一批提示詞的改動量攤開來看。第 7 句「加一個地區稅率規則，台灣 5%，其他地區照表」只改了 12 行、1 個檔案，看起來是很小的一次變更。

先補一個容易誤會的地方：這批提示詞來自開賽前的基準實驗，專案資料夾叫 day0。它不是漏發的第 0 篇文章，也不計入鐵人賽正式發文；Day 1 到 Day 3 都是在回頭檢查這份基準版本。

今天就沿著 Day 2 留下來的問題，打開那 12 行。存檔 82b767a 為結帳套件加了 TW、JP、US、SG 四個地區稅率。函式名稱清楚，也有 Math.round 處理計算結果；既有測試連未列在表內的 XX 都測了，而且整排綠燈。

但那支測試期待的答案，正好是 0。

程式乾淨、測試通過，不等於ㄌ需求真的被說清楚。今天我不修稅率，先讓原本無聲的缺口亮起紅燈。

延續 Day 2 的同一本書

Day 2 第一次介紹 Peter Isberg 的 《Vibe Coding Architecture at Scale》（Packt，第一版，2026）。今天沿用同一本書，但往後讀到第 2 章〈Shift Left, Guide Right〉，尤其是第 2.4 節談的「看起來很乾淨、其實是錯的」。

作者提醒，AI 產生的錯誤程式和正確程式，常有一樣流暢的命名、格式與註解。以前人工審查會特別留意看起來可疑的段落，現在卻可能找不到那個「可疑的樣子」。所以檢查重點要從「這段寫得漂不漂亮」移到「邊界條件有沒有被可執行的檢查釘住」。

原書的例子包括競態條件、差一錯誤和邊界違規；vibe-order 並不是原書範例。我把同一個觀點帶回自己的小實驗：重讀 Day 2 指出的那 12 行，找出正常流程以外、既有綠燈沒有真正回答的問題。

缺口藏在哪裡？

關鍵邏輯只有一行：

return Math.round(subtotal * (taxTable[region] ?? 0));

region 在稅率表裡就照表計算；找不到時，?? 0 會直接套用零稅率。這不是程式當掉，而是默默把未知地區當成免稅。

同一個結帳流程還有另一個預設：呼叫端沒有提供地區時，會改用 TW。也就是說，「沒填地區」走台灣稅率，「填了表外地區」卻走零稅率。兩個相近的邊界，採用不同政策；原始提示詞沒有說這是不是刻意設計。

既有 packages/day0.test.ts 又寫了 XX → 0，所以那盞綠燈只能證明「程式符合這條測試」，不能證明「這條測試符合業務規則」。

我加了什麼檢查？

我留下兩份實驗產物：

• reports/day3-deceptive-diff.md：記錄是哪一段程式、為什麼看起來合理，以及缺口如何觸發。
• packages/checkout/__tests__/tax-rate.regression.test.ts：用 XX 與小計 1000 重現表外地區的行為。

測試先採用「和預設地區一致，暫按台灣 5% 計算」當成待確認的規格，因此預期稅額是 50；現行程式算出 0。執行 npx vitest run tax-rate.regression 後，得到：

AssertionError: expected +0 to be 50 // Object.is equality
- Expected
+ Received
- 50
+ 0
 Test Files  1 failed (1)
      Tests  1 failed (1)
EXIT:1

這個紅燈證明的是「目前程式和這個候選規格互相衝突」，不是「台灣 5% 一定是唯一正解」。真正修正前，還要決定表外地區應該拒絕結帳、補進稅率表，還是採用明確的預設稅率。這三種都可能合理，但不能由 ?? 0 默默代替人做決定。

為什麼今天只讓它變紅？

Day 3 要驗證的不是我能不能立刻寫出修正，而是「漂亮的程式與綠燈，會不會一起掩蓋規格缺口」。如果順手把產品碼改掉，反而會把「哪一條規則才正確」這個尚未回答的問題藏起來。

因此今天不重構、不修改稅率表，也沒有為了得到綠燈而跑第二輪。從紅到綠的輪數是 0。檔名雖然用了 regression，嚴格來說，它目前仍是缺陷重現與合約確認測試；等業務規則確認、產品碼修好之後，才會成為防止舊問題再出現的回歸測試。

反方問題：XX 本來就是假地區，回傳 0 有什麼不行？

可以。如果產品決定「不支援的地區視為免稅」，並以文件和測試明白寫下來，回傳 0 就合理。現在的證據只能看到程式和既有測試都接受 0，看不到這項政策從哪裡來。

另一個反方意見是：既然今天故意保留失敗測試，就不該合併進主要分支。這點我同意。紅燈適合當診斷證據，不適合長期留在持續整合流程中；下一步應先確認規格，再讓產品碼與測試一起轉綠。

這次方法做不到什麼？

這個缺口不是掃描工具自動找到的，而是我重讀 git show 82b767a、原始提示詞與既有測試後才看見。它只釘住一個地區稅率邊界，不能證明其他程式都正確，也不能證明原書描述的現象普遍存在。

紅燈也沒有替我們回答業務規則。它的價值是阻止「不知道」繼續偽裝成「測試都過了」。

來源與 AI 使用揭露

概念來源：Peter Isberg，《Vibe Coding Architecture at Scale》（Packt，第一版，2026），第 2 章〈Shift Left, Guide Right〉。本文主要對照第 2.4 節：AI 產生的錯誤程式也可能命名清楚、格式漂亮，因此流暢不能當成正確證據；自動化檢查比單靠逐行閱讀可靠。出版社的書籍介紹與書目資料可供核對。

AI 使用揭露：測試骨架由 AI 依寫作卡產生，我重讀賽前基準實驗的提示詞（day0/prompts.md）、存檔與測試後填入真實函式和輸入；失敗輸出為實際執行結果。vibe-order、測試與報告都是本系列的實驗產物，不是原書附的範例碼。產品程式今天沒有修改。

下一篇預告

明天把鏡頭拉遠：不再只挑一個稅率缺口，而是把「誰不准依賴誰」寫成會讓建置失敗的檢查，看看沒有人記得時，架構規矩是否仍會自己攔下違規。