一人團隊的殘酷算術

沒有 QA、沒有 code review 的同事、沒有值班輪替——一人維運的服務，所有品質防線只剩一道：測試。我的專案累積了 1200+ 個測試，全套跑一輪 7-8 分鐘，而且是 CI 部署的硬關卡（不過就不上線，Day 27 細講）。

但今天想講的不是「測試很重要」這種正確廢話，是兩條具體的紀律——它們是這個測試庫真正的骨架。

紀律一：修 bug 永遠從紅燈開始

流程是死的，順序絕不妥協：

1. 先寫一個能重現這個 bug 的測試
2. 跑它，親眼看著它紅
3. 然後才准動手改邏輯
4. 改到那個測試轉綠，且其他測試沒有變紅

第 2 步「親眼看著它紅」是整個流程的靈魂，也是最常被省略的一步。為什麼它不可省？因為沒紅過的測試，你不知道它測的是不是你以為的東西。太多測試寫出來就是綠的——因為 mock 設錯了、斷言太鬆了、測試根本沒走到出事的那條路徑。這種測試是安全網上的破洞，比沒有測試更糟,因為它給你虛假的安全感。

先紅再綠還有一個附帶價值：紅燈測試是 bug 的可執行描述。半年後回看，這個測試告訴你「當初壞的是什麼、什麼輸入觸發、正確行為是什麼」——比任何 commit message 都精確。

這條紀律也完整地約束著 agent：交給它修的 bug，它同樣先寫紅燈測試、跑給我看，再修。這在 AI 協作裡甚至更重要——紅燈測試是我驗收「它真的理解這個 bug」的證據。它寫的測試如果紅得不對（紅的原因不是那個 bug），代表它對問題的理解偏了,這時候攔下來，成本遠低於讓它帶著錯誤理解去改邏輯。

紀律二：用測試釘住「不該漂移的東西」

測試庫裡有一類特殊的測試，它們不測邏輯,測承諾：

• 對外顯示的定價數字、方案內容文案——釘住，防止任何改動讓網頁上的價格跟實際扣款不一致
• 錯誤回應欄位的型別（Day 11 的教訓）——釘住，保護已上架的舊版 App
• AI 生成內容的固定框架文字（免責聲明這類）——釘住，這是合規承諾，一個字都不能被「順手優化」掉
• 付費旗標關閉時的 403 行為（Day 15）——釘住兩種狀態

這類測試防的不是「寫錯程式」,是跨模組的字串耦合在無數次改動中被不知不覺蹭掉。它們單獨看都瑣碎，但每一支背後都是一次真實的「咦，這段文字什麼時候被改掉的？」。

在 AI 協作的時代，這類測試有了新的意義：agent 改碼又快又大方，它完全可能在重構時「順手」把一段它以為只是普通字串的免責聲明改得更通順——而那段文字的每個字都有存在的理由。釘住測試就是把「這裡不准動」翻譯成機器聽得懂的語言。 文件裡寫「請勿修改」會被忽略，紅燈不會。

測試是一人團隊的槓桿，不是成本

1200 個測試聽起來是巨大的維護負擔——實際上恰恰相反,它是整個「一人 + agent」模式的成立前提。因為測試夠密，我才敢讓 agent 大範圍重構;因為 CI 關卡夠硬，我才敢讓 push 直接觸發部署;因為行為被釘住，我才敢在半夜合併程式碼然後去睡覺。測試不是在幫你抓 bug，是在幫你買「敢放手」的資格。