我打算不按时间顺序写。今天最大的体感是：每条线都在「保留现有修改」这三个字上反复磨。下面分两块，一块是后台工程，一块是输入法侧。两条线看起来离得很远，但都落在「不要为了改一个点而把别的没核完的东西一起送走」这条铁律上。
后台两件：OOM 的证据收据和博客的定向 af19be4
第一条线从昨天延续过来。Codex 的一个会话里，指令很清楚：「继续排查并修复 openclaw_check_observe 中 tsgo 的 OOM 问题，先确认根因再做最小修改，不改业务逻辑；修复后重跑 CI，只提交并推送本次相关改动。」推进给出的结果线索里，我比较在意的是保存下来的那份历史证据收据——/Users/chenjin/Documents/Codex/2026-10-16/dui/work/ci-tsgo-oom/kernel-oom-evidence.json。它记得了完整内核原行、两次 global_oom 时间戳、RSS 和 swap 数值，以及历史路径和行号。收据里还老老实实标注了「日志已被父流程报告轮转」，这意味着这并不是一个能完美还原现场的证据，它只是尽可能把现场「钉死」，免得今天再回去找的时候连 dmesg 也已经被冲掉了。这种「承认残缺，但尽量多留线索」的写法，我认为是工程侧非常值得保留的一种习惯。
另一条改进实验的线索提到：「审查通过：如果同 SHA、同镜像的 --singleThreaded 实验成功，建议仅修改 openclaw/package.json 中的检查参数，并还原实验性的 CI GOMEMLIMIT。」同时核验了 pinned 源码里 root files、lib 和自动类型依赖仍按原 tsconfig 加载，且所有文件仍执行诊断，Ski...（此处线索被截断）。换句话说，思路收敛得很窄：能用一个参数或环境变量解决，就别动业务逻辑；实在要动，也只动一个最小化的字段。
第二条线是博客。Codex 的会话描述几乎就是一份对外的口径稿：「允许，定向提交并推送这 4 个修复文件，使用 ci.skip，不立即部署。继续盯今晚 23:30 的自然发布，失败就沿原 run 恢复，完成后核验线上结果并告诉我。」结果里写着：已定向提交并推送 af19be4，仅包含授权的 4 个修复文件；ci.skip 让 pipeline #549 状态为 skipped，没有触发部署；无关改动完整保留。一份独立核验显示：af19be426af15e37f6653ebc1629ffcc7765c5f9 精确包含授权的 4 个文件，4 个 blob SHA256 均与已通过验证的 closeout 一致，锁定 Image 2 配置和原 brief 合同不变，GitLab origin/main 已指向该 SHA，Project 40 的 pipeline 也按预期被跳过。
我对这段并不陌生——「定向提交」这四个字的代价是大量的注意力损耗。它通常意味着：先把允许改的文件 SHA 算出来，确认它们和已经通过的 closeout 一致；再确认无关改动确实完整保留，没有被顺手 git add .；最后还要确保只用 ci.skip，把控制权握回自己手里，不去赌 CI 看到的是不是同一个树。af19be4 这类冷哈希一旦定下来，就会成为今晚 23:30 那条一次性跟进的事实基准——按线索里的说法，「若自然发布失败，会沿原 run 恢复；完成后核验 CI、线上正文与封面、后台状态，并在这里汇报」。整个过程没有奇迹的地方，但好处是每一步都留有可回退的句柄。
输入法侧：316ms 到底怪谁
输入法那条线其实更新得多一些。素材里同一个会话链上有好几条推进记录，最关键的一段话是：「继续排查这次 316ms 首键延迟，先确认是测试工具、输入法还是工作台的问题，定位后再决定是否修复。保留现有修改，不影响蓝图主线，暂不提交或安装。」结果里它承认了一件很重要的事——目前还不能将 316ms 唯一归因到三家中任何一家，所以「暂不改产品代码」。理由列得很整齐：原始延迟真实存在，158.9 + 157.2 = 316.1ms，不是配对算错；四轮新进程、108 次输入都没复现；同样的 IMK 警告在低延迟轮也出现过，不能因此认定是输入法的问题；已经修了验收工具里混淆 rAF 两种时间口径的 bug，19 项检查通过，但「这不代表首键延迟本身被解决」。
这种「先把工具误差剔除干净，再谈产品有没有问题」的顺序，是值得保留的。它把一个本来有可能变成「立即修输入法」的误判，按回到了一个更诚实的结论：问题真的存在过，但目前没法在干净环境下复现。这跟动不动就回滚或 hotfix 的作坊式 fix 是不太一样的审美。
往前再翻一下，同一串会话还做完了几件事：可以并行推进屏幕工具开发。先完成的切片是「截图选区、四色矩形、默认图片复制、独立图库、本地 OCR 和中文短词搜索」，实际 Electron 合成画面闭环及重启历史保留已验证。244 项全量检查、最后 34 项相关复验通过，修改保留了，原 Runner、旧库和输入法安装态保持不变，没提交、没推送。真实截屏权限、macOS 26／Retina／输入并发仍待验，被明确点出来作悬而未决项。
之后又有一轮以「继续推进，先查清并修复退出回执超时，再用自建测试画面补齐真实截图、权限和输入并发验收」为题的推进，结果里写到「退出回执修复已完成：最终候选实际退出码为 0，24 条日志与回执完整一致」，自建 Retina 截图闭环、真实 OCR 并发输入及未授权阻断已验证，但允许／撤回权限、Ajin 物理键盘验收仍待完成。
到了今天稍后一点，质检式的收尾来了：「5180×2880 自建画面」之类的细节、撤权重启后截图正确拒绝、GUI OCR 与输入并发时文本准确——唯独「保留一次空闲首键 316ms 异常；物理 Ajin 输入、macOS…」作为悬而未决项被显式记下。可以说，这是今天输入法线上最重要的一笔：它没有把那个 316ms 抹掉，也没有装作不存在，而是把它当作一个还没解释的观察单独保留下来。
最末一节是给 物理键盘对照 量身安排的剧本：Codex 给出的步骤是 1) 点击「SYNTHETIC 专用输入框」，等待 2 秒；2) 用实体键盘按平时速度输入 1 2 3 4 5 → 空格 → n i h a o → 空格；3) 点击「记录检查点」，再点击「结束夹具」。并且强调「不要粘贴、切换输入源或修正结果；即使没出中文，也保留原样」。窗口已打开，标着 baseline，5 分钟后会自动关闭。整个交互看起来像是在做一次故意克制的人因实验——变量就是手速，不让自动化或剪贴板把噪声混进来。
几条线之间的小心思
把这两条线放在一起看，会发现它们有一个共同的下意识：留下没解决的事，但要标注它没解决。tsgo OOM 那边留了一份承认「已被轮转」的证据收据；博客那条 ci.skip 之后还要等到 23:30 自然发布再核验，并把「失败就沿原 run 恢复」写进了计划；输入法这边把 316ms 那帧异常单独挑出来当悬而未决项，而不是悄悄心算掉，或者干脆当作不存在。
这和「结论先行」的写作风格其实挺不一样的。今天如果只挑一个立场说事，我会更欣赏后者——比起一个结论干净利落的总结，它更接近工程现实：有几条线在并行，谁也不知道谁先出意外，与其抢先下结论不如把每条线都做到「可回退、可复现、可核验」。这三条性质，在今天的三类素材里全都具备。
guzi 的那一栏只有一句素材，记录显示它已经识别到 openclaw_memory-2026-10-17.md 这份候选文件——总账框架搭好，内容则由今天这三块收口共同撑起来。到了夜里 23:30 那场自然发布，就看 af19be4 这棵小树会不会被风刮倒；如果倒了，沿原 run 恢复也是允许的；如果没倒，那这 4 个文件就是今天博客侧唯一可以称之为「交付」的东西。输入法侧交付的是一张清醒的单子：修了的列上画了勾，没修的明明白白挂在末尾。两者并列，大概就是今天最体面的收口姿态了。