把锅压回真正出错的那一层

4 月 13 日真正把几条线拧在一起的，不是项目很多，也不是某个仓库突然冲出一个整块成果，而是反复在做同一件事: 不接受停留在表层的归因，非要把问题压回真正出错的那一层。当天能用的主证据主要来自本地 Claude、本地 Codex 和几个工作仓库；remote Codex 虽然检查过，但没有拿到会话，ChatGPT 导出也先后卡在 SSL EOF 和 401 Unauthorized。外部补充不多，反而更清楚地暴露了当天注意力真正被什么牵着走。

最吃时间的还是 openword。但这一天的推进方式，已经不只是“继续把对齐率往前推一点”，而是在不断把一个笼统的渲染问题拆成更具体的责任点: 行范围和 row accounting 怎么进入 text-stream-assembler，header/footer 的 pack 和 spacer 为什么会把页面挤歪，floating table 和 wrap-table 在分页时到底谁该负责，最后又收束到 gov-005 这种 textbox 包 table 的路径判断。中间有试验、有回退，也有几次能留下来的窄修复，但真正重要的是方法本身变紧了: 先测、再证、再决定补丁值不值得留下，而不是继续在“布局不对”这种大而模糊的说法里打转。

白天另一条更像“认错锅”的线出现在 lvshe-be。起点看上去像是在问，为什么案件分析最后的总结切到 DeepSeek V3.2 之后会引用错法条；但随着 case-chat、case-analyze、matched law documents、prompt-debug 和具体 LLM 配置一层层被拆开，问题很快就不再像“总结模型不够聪明”。当天真正厘清的是，对话型最终回复和案件分析总结并不是同一个模型面，summary 走的是 dailyLLM，主要是 DouBao Seek 1.6；更可疑的故障点，其实是法条匹配、ES 生效日期过滤、逐条关键词校验，以及最后塞进上下文的法条集合本身。下午对 debug 文件的复核把这种判断坐实了: 上下文里仍然混着噪声法条，最终回答却落到了 公司法第49条。比起继续把责任推给“模型瞎说”，这一天更像是在把锅重新压回检索和上下文装配这一层。

到了傍晚，这种倾向又在别的事上重复了一遍。lvshe_infra 没有停留在腾讯云控制台里手抄几组访问数据，而是把 RUM 查询整理成了一个可复用的 dashboard，随后又接上了 lvshe-be 的镜像 tag 推进。本地 Codex 这边还穿插排查了 easyvoice.fun 不可访问和 staging 文书起草异常，但这些更像不断插进来的运维性中断，不足以改写当天的主线。回头看，4 月 13 日真正往前走的一步，并不是哪个问题彻底解决，而是几个本来很容易被扣错帽子的故障，都被往下压回了真正的 owning layer。后面的活仍然很多，但至少不再是在错的地方用力。