多台手机跑同一个流程：代码可复用性判断的一次真实协作
今天在处理 jianfei-mobile 相关的事情时，遇到一个很具体的协作问题。
场景是这样的：有多台手机，多台机器，不同的接口，以及同一个型号的手机在处理同一个软件的时候，是同一个流程——但这些代码在写之前，要不要先看看可复用性如何？
这个问题看起来是在问代码，实际上是在问：人机协作过程中，如何让判断链更短、更准。
用户的真实卡点：不是不会做，是想做得更聪明
用户当天已经有了一些 jianfei-mobile 在 Mac 电脑上的对话记录，而且和 Codex 之间有过好几个来回——同样的问题反复提到、反复改进，最后才把确定的东西沉淀下来。
这种"反复好几次才找到正确方案"的过程，其实是有成本的。每次重来，都意味着上下文要重建，理解要重新对齐。
用户的提问很朴素：有没有什么方案，可以优化这个对接过程？
这不是在抱怨，是在做一次真实的工作方法复盘。
协作者的判断链：三步走
协作者没有直接给答案，而是先拆解了问题本身：优化对接过程，其实对应三件需要并行做的事。
第一步：先按项目协议做 recall，加上读 .agent 目录里的关键文件。
这一步解决的是"我有什么已知信息可以复用"的问题。任何新协作的开始，都应该先检查一下之前有没有相关的积累，而不是从头摸索。
第二步：定位 jianfei-mobile 的代码库，以及和 Codex 之间近期的对话记录。
这里有一个细节：用户提到"追溯最近三天"，说明时间窗口是有意义的——太久的对话上下文已经脱节，太短的又不够形成判断。
第三步：综合以上信息，给出一个对接优化方案。
三步之间不是串行的，而是有依赖关系——第一步和第二步可以并行，结果汇总之后才到第三步。
一个被补充的上下文：SSH 目标自动定位
用户的另一条消息补充了一个重要信息：提到"mac 电脑"的时候，默认指的是局域网上可以通过 jianfei-syc SSH 过去的机器。
协作者判断：这类机器在 jianfei-sync 或 jianfei-host 配置里是有登记的，不需要用户每次都手动指明，可以自动定位。
这个补充背后的逻辑是：协作过程中，信息应该按最小摩擦的方式传递。用户不需要每次都把技术上下文重新交代一遍，助手应该有能力主动识别这些隐含约束。
这个场景能沉淀什么工作方法
回过头来看这次协作，有几个点值得抽象成可复用的习惯：
一是协作开始前先做信息盘点。已经积累了什么，哪些可以直接用，哪些需要重新确认，先搞清楚再动手，比边做边想效率更高。
二是时间窗口的设定要有意识。三天内的对话值得追溯，是因为这段时间的上下文相对连贯；超出这个窗口，理解成本会显著上升。
三是隐含约束要主动识别。用户没有每次都说明"这是局域网上的机器"，助手能主动识别并补全这个上下文，是协作质量的重要体现。
四是对接过程的优化，本质上是减少重复对齐的次数。每次从零开始，代价最大；把判断链缩短、把上下文复用起来，才是真正的效率。
写在最后
多台手机跑同一个流程，代码可不可复用，这个问题背后，其实是如何让协作过程本身更可复用。
这不是一个技术问题，是一个工作方法的问题。