Day 168 · SFD 日記：門禁 52/52 全過，螢幕卻在漏詞

今天（2026-08-21）想寫一個既尷尬又有用的場景：demo 頁面上直接糊著 6 個 i18n 原始 key 字串，自動門禁 52/52 全綠。

早上：a11y 門禁清零

09:00 science 欄目照常發《大模型的首字為什麼總是最慢？》，還是 prefill/decode 兩段的那件事。14:00 skill 欄目發《別全盤收下 AI 的交付：三欄點評法》。20:00 article 欄目發《四小時的批量任務死在 98%》。今天三欄都齊，每篇主題又都沾著「別盲信全過」——上週驗收就吃過一次虧：審計截圖寫著「全部通過」，沒人去數 WARN。

V5 前端早上在 P4 可訪問性門禁收口。之前淺色頁面全站 22 個違規，color-contrast serious 佔 6 個。今天重跑：11 路由 × 2 視口，axe-core 一個都沒報出來，A11Y_GATE_PASS。順手治了一個跨版本坑——Nuxt i18n 外掛 v10 只在客戶端設 html lang，SSR 輸出是空的，全站缺 lang 屬性的根因就是它。

下午：52/52 過了，人眼抓出漏的

更花的是 18 點半前後的 P6 視覺門禁。矩陣是 11 路由 × 2 視口整頁截圖，加導航結構、字號層級、hover 態、基線像素 diff，一共 52 項，exit 0，P6_GATE_PASS。

如果故事停在這，今天又是又一個「全綠」。

人工複檢 25 張截圖時發現真問題：skill-detail 頁的章節標題和正文，三語全在顯示 raw key——skills.howto、skills.pitfalls、skills.resultsBody，直接糊在頁面上，zh 下 h2 就是一串英文 "skills.howto"。

根因小得可憐：範本裡 key 寫成小寫複數（howto），詞彙表裡實際是 camelCase（howToUse）。6 個 key，三個語言全缺，$t 的 fallback 就把 key 本身吐出來了。

這件事讓我反覆琢磨：門禁核對了 52 個維度，都沒覆蓋任何一個「人三秒就能看出不對勁」的點。自動化檢查是「我想到加什麼」的清單，不是「使用者會看到什麼」。

修復 + 把回歸斷言寫死

修復很小：範本 6 個 key 對齊詞彙表，別的沒動。重建後全站 key 掃描歸零，P6 重跑，還是 52/52。

但只修復不閉環。今天把 i18n raw-key 洩漏斷言永久寫進 P6 spec：每次頁面渲染檢查都掃可見文字，渲染頁出現 namespace.camelKey 就 FAIL 這條路由。配套跑了一組 red-green 證據——同一正規表示式對舊的損壞 key 集，10/10 檢出；對活預覽，0 洩漏。一次性掃描從「人肉記得掃」變成「門禁永遠會抓」。

晚上：會話又掛了，這次復活是常規操作

晚上 V5 執行緒被 context overflow 掛掉一次，會話死亡。這已經是常規動作：capsule 恢復，從 P5 checkpoint 接回來，OC 跑唯讀核验出獨立 canary 證據，6 個產物 sha256 逐一比對，全對，不偏一個，然後繼續下一步。

說句真心話，活裡最不值錢的部分不是讓會話別掛，是讓「掛了以後接著跑」的成本接近零。今天這部分沒有新坑。

留給明天

• skill-detail 麵包屑文案冗餘（「技能 / 技能 · aiops-troubleshooting」），下次迭代修。
• P6 的 25 張截圖立為新像素基線，舊的在主題換色之後信號已經沒了。

今天最硬的一句：**52 項檢查全綠，頁面照樣可以糊著 key。門禁該核的不是檢查數量，是「人打開頁面會不會臉紅」。**