把真实边界逼出来的一天

这一天真正往前推进的，不是哪条线又多做了一点，而是我开始更强硬地要求每个系统把自己的真实边界露出来。凌晨先收完前一天 scaffold 和公开日志，但我没有把它当成例行流水线结束，而是顺手把发布自动化的一个老毛病说破: 它的问题不是“偶发 push 失败”，而是默认定时任务启动时远端已经就绪。于是这一天一开始，动作就已经从“继续用”变成了“先把隐藏前提改掉”。

上午在 lvshe-be 里，paper-form 先还是按“现有要素式自动填写到底质量如何”来推进，可越往下做，越发现真正的问题不在样本有没有跑通，而在评估本身一直允许自己偷懒。只要还接受总评、概述、阶段性结论来代替字段级核对，质量判断就会不断滑回“看起来差不多”。同一时段又撞上文书起草里的 JSON 解析失败，最后落成了 jsonrepair 那笔修补，把“模型输出不稳”从抱怨变成了基础设施问题。到了下午，这条线干脆彻底重开，不再接受“差不多够了”的节奏，而是把 paper-form 全部样本改写成字段全量对照、带审计、带进度监督、带问题归因的硬结构。那 11 份字段级文件和配套审计文档，真正说明的是我开始拒绝再用摘要把问题混过去。

下午另一条同样重要的线是 redactor。混排 PDF 的问题最后被说得很清楚: 旧流程一开始就把整份文档判成电子页或扫描页，所以现实里一旦混排，就会在入口处走错。后面一整串动作，其实都是在逼这个偷懒前提现形: 把处理方式改成逐页判断、逐页取文本、统一映射；把日期脱敏从一刀切的 **** 改成按可见粒度输出；把 PDF 和 DOCX 的高亮行为重新拆开。再往后，又一路追到“代码已经改了、tag 也打了、workflow 也确认构建了正确 commit，为什么线上看起来还是旧效果”。这让问题从实现一路拖到部署链路核验，也提醒我真实边界从来不只在代码里，还在工作区、依赖、镜像、缓存和实际部署上。

到了深夜，注意力切到 bsclaw，但问法已经不是“能不能连上 app-server”这么窄了。先是追问复用连接和新起 app-server 各自会带来什么后果，再往后直接在真机上安装、启动，然后又把产品、设计、服务端、Android 和 QA 这些角色全部拉进来，逼这个项目回答一个更难的问题: 手机上的 Codex 到底是不是一个真的能继续工作的工作台，而不是一个把 bridge、thread、tailnet、workspace 拼起来的演示品。现有证据里，这条线更多落在 session 侧而不是 repo 侧，但方向已经很明确了: 我不再满足于“桥接没报错”，而是要它面对安全、阻塞请求、协议闭环和真机使用体验这些更真实的验收条件。

所以这一天和前一天其实是一前一后。前一天我开始识别代理目标，今天则开始逼这些代理目标在每条具体工作线上失效: 自动化不能只求会跑，评估不能只求有总评，PDF 不能只求一条路径走通，手机端也不能只求能连上。没完全收住的口同样很清楚: paper-form 现在只是终于拥有了更难糊弄的评估形态，不等于业务质量已经过关；redactor 的构建正确也不等于部署正确；bsclaw 还没有完成所有真机闭环。但比起“又做了很多事”，这一天更重要的是，我开始更持续地把“真实需求到底卡在哪一层”这个问题压回系统本身，而不是继续让它被摘要、默认值和表面成功带走。