2026-03-14 日志

这一天更像是在把边界看清，而不是急着宣布“又做完了什么”。如果只看仓库动作，会觉得上午在 ffly-travel、中午以后在 homoscale，项目切得很开；但把会话和少量 artifact 放在一起看，真正贯穿全天的动作其实很一致：我在把问题从症状层往下压，直到它们变成可解释、可判断的东西。Claude 和 remote Codex 这天都没有正文，所以叙事主要建立在本机 Codex、ChatGPT 和少量产物锚点上。

早上承接的还是前一晚 ffly-travel 那条线。最初的问题很简单，甚至有点粗糙：手机 RPA 遍历太慢，怎么才能更快。但这天一开头就已经不满足于继续在表面提速了，而是顺着海航 App 的原生搜索调用链一路往里钻。service/interface 在哪里，HnairAppBridge.js 的 getCode / getCodeMs / verifyToken 究竟怎么连起来，verifySign 和 captchaToken 这条链到底卡在哪，这些问题一旦被放到桌面上，原来的“慢”就不再只是执行速度问题，而开始显出更像风控窗口和验证码机制的问题底色。

这也是为什么我更愿意把 3 月 14 日看成一次“把模糊问题拆到底层”的日子。它没有给出一个漂亮的成功截图，却比前一天更明确地知道自己现在到底被什么拦着。app-verify-sign-live.json 这种小锚点也说明，这不是纯读代码的空转，而是已经把理解往真实链路上压过一轮。只是它的意义不在于“现在已经成了”，而在于原来模糊的一团东西，开始被切成了接口、bridge、验证码、签名机制这些可继续追的块。

中午之后切到 homoscale，做的事情表面上完全不同：不再是航班 App，而是 Android 端启动逻辑。但本质上仍然是同一个动作。我没有继续往上面堆功能，而是回头处理“启动时自动导入订阅 URL”这种很容易被忽略、却会长期磨人的行为，把它改回只有手动导入才触发，否则复用上次状态的方式。这里真正被修的不是一个崩溃或报错，而是产品语义本身：谁来做决定，什么时候应该自动，什么时候应该把控制权还给用户。到 12:52，app-debug.apk 重新产出，这条线至少已经到了可以继续在设备上验证的程度。

ChatGPT 这天虽然没直接写进工程现场，但它补的几块外围判断也恰好说明了我脑子里在想什么：Office 兼容、替代 WPS Web Editor、测试文档来源、tmux 自动化、小米 root。这些话题放在一起看，并不杂，反而像一圈包围层：一边是以后 openword / editor 这种长期线究竟该怎么定义难度和对标对象，一边是以后移动工作流、设备控制和远程会话该怎么更顺手。它们都不是当天主轴，却解释了为什么我愿意花一天时间，把“能不能快一点”“能不能自动一点”这种问题继续往根上挖。

所以如果要给 3 月 14 日下判断，我会说：这不是一个做出很多成品的日子，而是一个把问题真正拆到底层的日子。ffly-travel 没有立刻迎来查票链路的大突破，但至少比前一天更清楚自己卡在什么机制上；homoscale 也不是靠再加一层功能去显得更完整，而是开始回头修那些以后会反复磨人的产品行为。真正还没收住的口，也都还是这些边界上的口：ffly-travel 当天有没有立刻换来明显收益，证据还不够硬；openword / editor 这条线则还停在问题定义和方案比较，没有进入真正实现。但正因为这样，这天反而更像一次必要的收缩：先别急着说自己做到了什么，先把边界看清。