把黑箱拆成可控系统

这一天真正贯穿下来的，不是哪一个单点功能终于上线，而是我在不断逼自己和手头这些系统停止依赖“只有懂内部细节的人才知道现在发生了什么”的工作方式。可用证据主要来自本地 Codex 会话，以及仓库和 /tmp 里留下的产物；Claude、remote Codex 和 ChatGPT 这几路没有补出更多正文，但现有材料已经足够一致地说明主线: 从上午的 codex-mobile，到下午和深夜的 WPS doc_viewupdater，再到最后给调试链路本身补 skill 和补 session watcher，我一直在做同一件事，就是把黑箱拆成可见、可验证、可自动续上的结构。

上午的注意力还牢牢压在 codex-mobile 上。问题已经不再只是“它能不能偶尔连上”，而是超过一段时间后为什么会出现 The secure link on the phone has stopped，为什么同一个二维码再扫一次会走到错误路径，扫码没反应时到底是 Android 端没接住，还是 bridge 侧回归了，以及后台切回、冷启动、手动退出工作区这几种状态到底该怎样区分。当天留下的 /private/tmp/codex-mobile-*.txt 很能说明这条线的真实摩擦: On this phone、Couldn’t open workspace、embedded tsnet runtime failed to start、Retry、Opening your workspace 这些状态变化都指向同一个目标，就是把保存、重连、失败、恢复各自变成用户看得懂的承诺，而不是一次次重试后的偶然成功。

中午前后还插入了一条看似岔开、其实很关键的思考线。我在 lvshe-fe 里追问 pretext 这类非 DOM 文本计算能力，能不能把网页里的 Word/PDF 能力降本，甚至变成一种底层突破；接着在 openword 里又把问题改写得更扎实: 现有开源 web Word 或 docx 编辑器到底卡在哪里，ONLYOFFICE 这种复杂度本质上在解决什么。这里真正起作用的，不是某个现成答案，而是方向被逐渐说清楚了: 不应该把现有办公运行时直接当作最后归宿，更像是把它们当作参考实现、对照组或 golden output，然后逼自己提炼出真正可控的排版与增量更新能力。

所以到了下午后半段，注意力就很自然地从“WPS 到底是前端排版还是后端排版”转成了“如何把它的行为系统化地拆开”。openword 这条线之所以站得住，是因为当天留下了非常扎实的落地痕迹: a02d8b1、22288d0、6f822d9、47dabcc、0aee3f8、53a7277 这些提交，把 doc_viewupdater 的逆向脚手架、canonical model、runtime hook 方案、日志 schema、回放与差分基线，一路推进到 paragraph break、字号变化这些真实样本的正式回归。重点已经不是“我大概知道它在浏览器里做了什么”，而是开始把 WPS 的行为翻译成一整套之后还能继续复用的研究设施: 有索引、有样本、有脚本、有任务板，下一次再回来就不是重新猜，而是沿着一条已经铺好的轨道继续逼近实现。

晚上的两个小尾巴，反而把这一天的方向说得更彻底。一个是新建 chrome-devtools-auto-allow skill，专门处理 Chrome 在 autoConnect 时跳原生 Allow 弹窗、而人又未必守在电脑前的问题；另一个是开始做 bun 的 Codex session watcher，想根据会话内容判断任务是不是中断在半路，如果是就自动发出“继续”。它们都还带着明显的在途感，尤其 session watcher 更完整的落地已经跨到 2026-03-31，但这已经足够说明我当天在修正什么: 不只是让产品或研究对象可观察，也要让自己的工作流本身不再被偶发的阻塞、弹窗和中断轻易打断。

回头看，2026-03-30 并不是一个“做了很多项目”的日子，而是一个把工作方式往前推了一步的日子。上午还在为 codex-mobile 的恢复语义和错误状态清路，下午逐渐把对文档编辑器的兴趣从产品外观转向可控内核，晚上则进一步开始给调查和续作本身装上辅助轮。真正还没彻底收口的，也正是这条主线留下的开放端口: codex-mobile 的恢复契约是否已经稳定到足够放心，doc_viewupdater 离从逆向骨架走向真实实现还有多远，以及这些新补上的自动化小工具，能不能把接下来每天的摩擦再往下压一层。