我这次面对的问题很具体：现在已经有一套免界面自动化，原本在 Mac 上工作，能不能迁到 Windows？如果只是把问题理解成“把几条命令换成另一种写法”，答案似乎很快就能给出来。换路径、换启动方式、换进程管理工具，仿佛就完成了一半。
但我很快意识到，真正要迁移的不是一组命令，而是一条能力链。它可能同时依赖浏览器协议、宿主进程、本地文件、登录状态，最后才是必要时的界面兜底。每一层的跨平台程度都不一样。迁移前最重要的动作，不是复制脚本，而是先确认每一项能力到底依赖什么。
先把“能不能”拆成几个问题
用户当时问的是现有免界面自动化能不能在 Windows 上实现，以及登录之前要做什么准备。这其实包含了 3 个不同问题：原来的核心能力能不能保留，Windows 端需要补哪些环境，登录后怎样接入既有流程。
如果把这 3 个问题混在一起，很容易得到一个含糊的结论：理论上可以，实际还要再试。这个结论既没有错，也没有帮助。因为“可以”可能只代表浏览器部分能跑；也可能代表文件读取能跑，但宿主进程接口完全不同；还可能只是当前机器已经登录，所以看起来一切正常。
我更愿意先画出一条能力边界：哪些能力是协议本身提供的，哪些能力依赖宿主程序，哪些能力依赖这台机器上的登录态，哪些动作只有在界面兜底时才存在。边界画清以后，准备工作才有对象，验证也才知道该验证什么。
这件事让我重新意识到，跨操作系统迁移通常不是“同一件事换个地方运行”，而是“同一个目标由几层不同的条件共同支撑”。只看最终效果，会把这些条件全部藏起来。
协议层通常最值得先保留
第一层是协议层。比如浏览器自动化如果通过标准的调试协议、远程控制协议或网页本身的请求完成，那么它关注的主要是浏览器版本、启动参数、端口和权限，而不是桌面上的按钮坐标。只要 Windows 端具备对应的浏览器和协议入口，这一层往往最接近跨平台。
这里的重点不是断言“协议层一定没问题”，而是先把它和操作系统分开。一个协议能否工作，取决于两端是否提供相同的能力；一个命令能否直接执行，才更多取决于操作系统的路径、进程和调用方式。把二者混为一谈，后面就会把本来可以复用的部分也重写掉。
我会先问 3 个问题：连接的是哪一种协议，协议入口由谁启动，验证协议成功是否需要打开界面。如果只是建立连接并读取一个无副作用的页面状态，通常可以作为第一项最小测试。它不会触发登录、发送消息或改动远端数据，却能快速证明迁移有没有从最底层开始走通。
能跨平台复用的，往往是目标和协议；不能直接复用的，通常是宿主、路径和运行环境。
宿主层决定了迁移的真实成本
第二层是宿主层，也就是承载自动化能力的桌面程序、后台进程、动态库和进程间通信方式。很多“免界面”方案表面上没有点击窗口，实际上仍然需要宿主程序启动、加载某些组件，或者在进程里完成特定的数据处理。
这部分最容易被低估。开发者看到 Mac 端已经能读到数据，就会自然地认为 Windows 端只缺一份配置。可是宿主程序的版本、安装位置、进程权限、组件格式和启动时机，可能全部不同。即使业务目标相同，底层入口也可能换了。
这次我没有选择先把整个目录复制过去，是因为这种错误捷径会把“代码能否运行”和“环境是否具备”混成一个大故障。遇到问题时，你不知道是路径错了、进程没启动、权限不足、版本不兼容，还是登录状态没有准备好。最后只好逐个补错，越补越难判断原来的设计到底依赖了什么。
更稳妥的做法是把宿主层单独列出来：需要安装什么，哪个进程必须存在，运行时是否需要相同版本，读写数据是否受权限影响，异常时能否只读检查而不改变状态。这里不急着做完整功能，而是先做环境体检。体检的目的不是证明成功，而是把缺少的条件分开报出来。
如果不处理这一层，最直接的后果是把一个平台差异误判成业务逻辑错误。后续可能为了修复一个启动问题，去修改已经正确的协议调用，反而让两端的代码都失去清晰边界。
文件、凭据与登录态不能混成一件事
第三层是本地状态。路径和文件格式属于迁移材料，凭据属于敏感配置，登录态则是当前机器、当前用户和当前客户端共同留下的状态。这 3 类东西都可能影响“能不能跑”，但处理方式完全不同。
文件路径可以重新映射，目录结构可以按 Windows 的习惯重建；凭据应该重新配置并控制权限；登录态则不能简单理解为“把旧机器上的东西复制过来”。尤其是涉及本地数据库、缓存或加密材料时，复制出来的文件未必能在另一台机器直接使用，也未必符合安全边界。
我会把准备工作分成两张表。一张只记录公开的运行条件：系统版本、浏览器、宿主程序、运行时、工作目录和读写权限。另一张只记录登录前需要用户完成的动作：在目标设备上安装必要程序，确认账号由本人登录，完成一次正常启动，并在不产生外部副作用的前提下确认自动化能看到预期入口。
这样做的好处是，不会把“已经登录”误当成“自动化已经接入”。登录只证明身份状态存在，不能证明后台接口、数据目录和权限都可用。相反，如果把登录态当成迁移包的一部分，既可能泄露不该搬运的内容，也可能在目标环境里留下无法解释的旧状态。
真正难的不是让目标机器看起来和源机器一样，而是明确哪些状态必须重新产生，哪些材料可以公开重建，哪些东西根本不应该离开原来的边界。
浏览器层与 UI 兜底层要分开验证
第四层是浏览器和界面兜底。浏览器协议能完成的动作，应该尽量留在协议层；只有协议无法提供的能力，才考虑使用界面操作。界面兜底不是不能跨平台，而是它对窗口位置、控件名称、焦点、缩放、登录弹窗和版本变化更敏感。
我会先验证无界面的主路径，再验证兜底路径。主路径可以是启动浏览器、建立连接、读取一个不会改变数据的状态；兜底路径则只验证能否识别一个公开、低风险的界面元素。两者分开以后，失败就有了含义：主路径失败，多半是协议或宿主问题；兜底失败，才去看界面适配。
这不是为了追求测试数量，而是为了保留判断顺序。一个流程是否真的跨平台，不看它能不能在新机器上偶尔跑通，而看每一层失败时能不能指出责任边界。
这里还有一个容易忽略的边缘情况：浏览器或宿主程序升级后，原来的入口可能仍然存在，但加载时机、权限或返回结构发生变化。若只有一次端到端成功记录，就很难判断变化发生在哪一层。只读 doctor 检查和最小能力测试的价值，正在于把这种变化提前暴露出来。
我选择先做只读体检，是因为它可逆
在真正登录、接入数据或执行写操作前，我会安排一个最小的准备顺序：先检查系统和运行时，再检查浏览器及宿主是否存在，接着确认工作目录和权限，最后只做一次不产生外部副作用的能力测试。
我选择这个顺序，是因为每一步都可观察、可回退。系统检查回答“有没有基本条件”，宿主检查回答“承载能力是否存在”，路径和权限检查回答“程序能不能正常读写”，最小测试才回答“这些条件组合起来是否真的能建立连接”。如果一开始就登录并跑完整流程，任何失败都会带着一大串未知条件。
最容易误判的地方，是把“没有弹出错误”当成成功。后台进程可能悄悄退出，浏览器可能连到了错误的实例，目标目录也可能只是能读不能写。所以每个只读检查都应该有明确的成功标志：能识别正确的运行时，能找到目标宿主，能建立协议连接，能读取一个预期状态，并且没有发送、修改或删除动作。
这套方法也给出了后续接入方式。协议层和业务逻辑尽量保持不变；宿主层用平台适配处理启动、路径和权限；登录态在目标设备重新建立；界面兜底作为最后一层单独维护。这样迁移不是复制一堆混合脚本，而是把每层的责任重新摆回原位。
下次我会怎么做
下次再遇到“现有免界面自动化能不能迁到 Windows”这类问题，我不会先估算改多少命令，也不会先要求把整套目录搬过去。我会先列出 5 层：协议、宿主、文件路径、凭据与登录态、浏览器及 UI 兜底。每一层都写清跨平台部分、平台专属部分和验证方式。
然后，我会先做只读的环境体检，记录缺少的条件；再做一个不触发外部副作用的最小测试，确认最底层能力；最后才决定是接入现有业务，还是先补平台适配。若某一层仍然依赖未知版本或未确认的权限，就把它标成风险，不用一句“理论上可以”把风险盖过去。
一个流程成熟的标志，不是它能在另一台机器上跑通一次，而是下一次迁移时，别人不必重新猜它依赖了什么。
这件事让我更愿意把跨平台迁移看成一次边界盘点，而不是一次命令翻译。工具可以换，系统可以换，登录地点也可以换，但判断链必须留下来。只有这样，自动化才不会依赖某一台机器的偶然状态，而会逐渐变成一套能够被重新准备、重新验证、重新接入的工作方法。