Day 5｜規矩回嘴要多久，量完才知道會不會被拔掉

到 Day 4 為止，我們已經陸續做出幾種可執行的檢查：Day 1 的誰靠誰地圖、Day 3 的稅率缺陷重現測試，以及 Day 4 接上的 ESLint、冪等合約與空殼測試掃描。這些檢查現在會跑，但另一個問題才剛浮出來：它們回嘴要等多久？又有沒有被接到不跑就過不了的關卡？

這次對照的概念來自 Peter Isberg 的 《Vibe Coding Architecture at Scale》（Packt，第一版，2026）：第 1 章 1.3 談 JPMS 把模組邊界放在編譯時期強制的代價；第 5 章 5.2、5.7 談回饋速度。書只提供思考框架。vibe-order 的程式、計時腳本和下列數字，都是這個系列自建實驗的結果。

開賽前的基準實驗（專案內叫 day0，不計入鐵人賽正式發文）故意沒有這些紀律。Day 4 雖然補上檢查，還沒有回答它們是否會拖慢工作，或只是要靠人自己想起來執行。

今天不加新規矩，只替既有護欄計時並確認觸發方式。護欄清單再長，也不能代替回饋速度與強制性。

把回饋速度攤開來看

Isberg 在第 5 章 5.7 用微秒、毫秒、秒、秒到分鐘區分回饋速度。我在腳本裡自訂切點：小於 1ms、1000ms 與 60000ms；這不是作者訂下的精確門檻。第 5 章 5.2 的約 400 毫秒與 10 分鐘只是示範算式，也不是本專案的量測。

這次產出 scripts/diagnose/time-guardrails.mjs 和 reports/day5-guardrail-speed-map.md。原本骨架量三支；為了對齊任務單，加入空殼掃描、稅率回歸與 npm test，共 6 支。每支跑 3 次取平均，時間包含 Node／npm 啟動開銷。報告產生於 2026-09-12T16:04:18.869Z；冪等合約測試需要先啟動伺服器，才能呼叫 POST /orders。

重跑結果：快，卻都還得靠人記得

執行指令是 npm run diagnose:speed。

6 支裡有 5 支在毫秒級，只有誰靠誰地圖是秒級，平均 1147ms，剛超過自訂的 1000ms 切點。第一次跑比較慢：ESLint 是 801ms，冪等合約是 1278ms；沒有只留下後兩次較快的結果。

稅率回歸與 npm test 的結束碼都是 1，因為 Day 3 那盞紅燈仍在，不是 Day 5 新造成的失敗。這張表量的是等待時間，不替紅綠燈下結論。

真正刺眼的是強制性：6 支全都只能手動跑。沒有 pre-commit、CI 或存檔前的攔截；npm test 即使寫在 package.json，仍要有人記得輸入它。最快的空殼掃描平均 100ms，也沒有變成必要關卡。

Isberg 在第 4b 章 4b.3、4b.6 提到他稽核自己的 5 個專案時，護欄零強制。這和這次實驗的方向相近，但那是作者的小樣本自我稽核，不能推成業界通則。

手動檢查的限制

第 1 章 1.3 對 JPMS 的提醒很實際：規矩若放在不合適的時間點，就會打斷心流，團隊可能選擇拿掉它。反方看法也成立：手動檢查在早期實驗裡較容易調整，太早接進關卡，可能把尚未穩定的規則變成阻礙。

不過目前的證據很清楚：這 6 支護欄都有碼表和分層，卻沒有一支是必要關卡。今天證明不了改寫後會快多少，也證明不了接進關卡後 AI 一定會被攔；只能確認 day0 之後補上的規矩，暫時仍要靠人記得執行。

來源與 AI 使用揭露

引用：Peter Isberg，《Vibe Coding Architecture at Scale》（Packt，第一版，2026）第 1 章 1.3、第 4b 章 4b.3、4b.6，以及第 5 章 5.2、5.7。書提供概念與作者舉例；vibe-order 的計時腳本、額外 3 支檢查和所有毫秒數均為自建實驗。AI 協助依寫作卡生成計時腳本，CHECKS 多出的 3 支是為了對齊任務單。

下一篇預告

明天回頭看進場說明 CLAUDE.md。這幾天加上的規矩，會不會把它養成一份誰都不想重讀的長文件？下一篇用三層分派拆開看。