使用 AI 協作寫程式時，功能通常增加得很快。前一天完成否定句，隔天加入空白處理，再往後加入未回應、狀態分流與人工接手。每一次修改看起來都合理，但真正令人擔心的是：今天修好的功能，會不會在明天的修改中悄悄壞掉？

CareCall AI 從 Day 11 到 Day 15 已經累積多個測試腳本。它們分別保護否定句、缺漏、再次未回應、不適與求助分流，以及人工處理流程。這些測試有價值，但每天一個指令也帶來新的問題：如果未來只記得執行最新測試，就可能漏掉前面的案例。

因此 Day 16 沒有增加新畫面，而是建立一個統一的核心安全網。現在只要執行 npm run test:core，就能一次檢查十一類案例，包括正常完整回答、否定句、部分空白、完全未回應、不確定、無法回答、一般不適資訊不足、明確不適、明確求助、再次未回應，以及人工處理與防止重複提交。標準的 npm test 也會執行同一套測試，降低記錯指令的機會。

測試最重要的不是數量，而是它是否真的能在錯誤發生時停止流程。為了驗證這件事，我暫時把正常完成規則中的「沒有不適」條件改成相反的值。再次執行測試時，第一個正常案例立刻失敗，清楚指出預期是「已完成」，實際卻變成「待人工確認」。

這個錯誤沒有被提交。我立刻還原正確條件，再執行一次核心測試，十一個案例全部恢復通過，正式建置也成功。這段失敗與修正紀錄證明：安全網不是為了在文章中展示一排綠色結果，而是能在規則被改壞時給出具體警告。

今天也刻意沒有追求完整覆蓋率。CareCall AI 現在最需要保護的是會影響照護工作順序的核心行為，而不是為每個 CSS 樣式或靜態文字建立大量測試。有限的時間應先放在錯誤代價較高、又會持續被修改的部分。

這套測試也為未來的語音與 AI 功能建立邊界。無論回答最初來自文字、瀏覽器語音或 AI 整理，最後仍必須進入相同的結構與狀態規則。只要核心測試保持通過，就能降低更換輸入方式時破壞原本安全分流的風險。

今日反思

AI 可以幫忙快速改程式，但測試負責保存我們已經確認過的決定。真正可靠的速度，不是改得最快，而是知道哪些舊成果沒有在修改中消失。