前言：Day 21 的問題，證據優先解決不了

Day 25 的「證據優先」規則，解決的是「有沒有做過驗證」；但 Day 21 那個新語法在舊環境悄悄失效的案例，問題不在於沒有驗證——測試確實跑過、確實顯示綠燈，問題在於驗證的環境本身，跟真正該符合的限制不一致。這需要一條不一樣的規則。

今日目標

• 認識「驗證方式對」但「驗證環境錯」這種獨立的問題類型
• 看一組「限制留在心裡 vs 限制寫成檢查項」的對照
• 理解這條規則跟證據優先規則怎麼互補

❌ vs ✅：限制留在心裡 vs 限制寫成檢查項

❌ 反例：相容性限制只存在授權者的記憶裡

（沒有明講，AI 用手邊環境支援的最新語法寫測試，本機測試通過）

✅ 正例：把限制寫成專案文件裡明確的檢查項

這個專案的測試需要同時在兩個版本的執行環境下通過：
最新版本，以及維持相容性的舊版本。
撰寫測試時避免使用只有新版本才支援的語法（例如某類新式標記寫法），
提交前務必確認兩個版本的檢查都顯示通過，不能只看其中一個。

這條規則跟證據優先規則的分工

證據優先規則要求「附上驗證證據」；限制外顯化規則要求「驗證要涵蓋正確的環境/限制範圍」。兩者是互補關係：如果只有證據優先、沒有限制外顯化，驗證的證據可能只涵蓋了錯誤或不完整的環境（就像 Day 21 案例裡本機測試通過的證據），看起來像是有證據，實際上證據本身就是有缺陷的。

為什麼限制容易被留在心裡而不是寫下來

環境限制、版本相容性這類資訊，往往是專案累積下來的歷史包袱——授權者自己因為長期接觸這個專案而記得，但這種記憶不會自動傳遞給每一次的協作。把限制寫進專案文件，是把「只有少數人知道的隱性知識」轉換成「任何人接手都看得到的外顯資訊」，這個轉換的價值不只是給 AI 用，對任何新加入的協作者都一樣重要。

今日思考題

你的專案裡有沒有類似的環境/版本限制，目前是寫在文件裡，還是只存在某個人的記憶中？

今日重點回顧

• Day 21 的問題不是沒驗證，是驗證的環境本身跟真正該符合的限制不一致
• 限制外顯化要求把環境/版本限制寫成專案文件裡明確的檢查項
• 這條規則跟證據優先互補：證據優先確保有驗證，限制外顯化確保驗證涵蓋對的範圍

明日預告

明天驗證：這套「證據優先」的要求，有沒有真的減少事後補救的次數。