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。门禁该核的不是检查数量，是"人打开页面会不会脸红"。**