插件开始被别人使用以后，兼容问题才真正浮出水面。 今天的工作主要围绕 MovieClaw 展开。映屿、映迹和寻映终于进入了官方插件仓库，之前等待审核的阶段有了结果。但源码合并并不是结束：插件能否正式下载、别人部署时能否顺利配对、Windows 客户端能否找到这些功能，仍是几件不同的事。下午，一位使用者反馈映迹首次配对失败，让我们看到了开发环境没有暴露的部署差异。另一条工作线则从 Windows 版的功能核对转入实际开发。两件事的共同点很具体：不能只看代码里有没有功能，还要检查入口、协议和运行环境是否接得上。三个插件合并，发布进度仍要分别确认上午查看 GitHub 时，最初看到的仍是等待维护者处理的状态。随后再次核对，映屿、映迹和寻映的三个投稿都已合并，发生在北京时间 11:29 至 11:30。此前关于“是不是还要继续等审核”的判断，也随这个新结果更新了。截至这次核对，映屿已发布 0.11.0；映迹和寻映确认的是源码合并，后续 Release 与商店上架仍需关注。不能因为三个 PR 都合并，就把三个插件都写成已经完成正式发布。这也解释了为什么发布状态需要拆开记录。源码进入主分支，说明维护者接受了这次提交；生成发布包、更新商店索引，以及使用者实际安装，是后面的步骤。今天不需要重复投稿，接下来应跟进尚未确认的发布环节。映迹的首次配对，暴露了地址回连问题映迹收到的报错原本只有一句“本人接口不可用”。检查后发现，连接超时、证书校验失败和响应格式异常，都被归入了同一句提示。仅凭这张截图，无法判断究竟是哪一层出了问题。进一步复现时，找到了一个确定的缺陷：没有配置外部访问地址，插件仍会尝试访问占位地址。浏览器能打开页面，也不代表服务器自身能完成配对流程所需的回连；反向代理、公网回环和证书差异，都可能让这两条访问路径表现不同。这次修改让缺少地址时直接给出配置提示，同时增加可选的本机接口地址。配对和后台同步可以走服务器内部的访问路径，交互页面仍从浏览器当前页面打开。连接错误也被细分，后续排查不必再从一句笼统提示开始猜测。修复已提交为 PR #23，624 项测试和 GitHub CI 均通过。但它尚待维护者合并、发布，市场现有版本还没有包含这次修改。已复现的缺陷得到修复，并不等于已经确认那位使用者的全部故障原因；对方的服务端版本和访问方式仍需补充核对。Windows 的插件入口，不能只放一个固定按钮Windows 版的核对先纠正了开发基线：本地保留着较早的 0.2.112 分支，远端已经发布 1.0.3。审查因此以最新发布版和当前开发分支为主，避免把后来已经补齐的发现、订阅和字幕生成功能重新列入待办。真正的缺口出在客户端与服务端的衔接。Windows 原有“正在观看”功能固定使用旧插件协议，而映迹采用另一套接口，对应请求实测返回 404。服务端已经提供插件导航接口，客户端却还没有读取它。这不是单纯少一个菜单，而是客户端仍在假定服务器安装了某个特定插件。后续开发改为识别服务端实际可用的插件，并区分映迹与旧版观看动态插件。旧按钮只看本地开关、卸载后可能仍然出现的问题，也加入了服务端可用性检查和返回应用时刷新。界面测试覆盖了未安装、安装后出现、卸载后清理以及可见性变化等情况。插件页面计划在独立窗口中打开，保持与主窗口的功能边界。相关界面回归已通过；原生插件窗口的关闭行为和隔离效果还要交给 Windows 托管构建中的测试验证，不能用浏览器界面测试替代这一步。自动跳过接上偏好，设备登录仍有服务端前提播放方面，服务端已经下发自动跳过偏好，Windows 仍主要提供手动跳过按钮。今天的开发补入自动执行、撤回和偏好衔接，也补测了设置保存失败后恢复原值的情况，避免界面显示已经开启，实际却没有保存成功。完整界面回归通过了 128 项，浏览性能测试通过了 4 项。过程中还发现一处旧测试过早读取播放结果：请求尚未发出，测试就开始核对。修正后先等待实际请求，再检查季数和集数，避免把测试时序问题误当成业务错误。设备登录和地址自动切换也在推进。地址切换加入了服务器身份核验，防止把不同服务器当成同一个目标。Windows 设备登录的服务端测试覆盖了登录、配对、重复登录替换及改密后下线等场景，但当前运行的服务端尚未声明支持 Windows 原生设备登录，因此测试包仍需保留现有登录方式，并提供配套服务端补丁说明。截至整理时，Windows 托管构建已经启动，这一轮仍在执行中；尚无新测试包完成发布的结论。安装流程、原生窗口和实际播放效果，也不能由本地回归通过来代替验收。留下的判断和下一步今天有三点值得记住。第一，源码合并、正式发布和实际可用必须分别确认。第二，浏览器可访问不等于服务器能够回连，错误提示应尽量说明失败发生在哪一层。第三，客户端功能要跟随服务端能力发现，不能把某个插件的存在写成固定前提。接下来，映迹要等待修复合并发布，并结合使用者的环境确认首次配对问题；Windows 要继续完成托管构建、原生窗口与安装验证，再报告测试包结果。自动化测试已经给出一部分证据，真机播放和实际部署仍需单独验收。隐私说明本文仅保留当天对话中可核实的公开项目进展与技术机制。个人身份、私人观影内容、部署地址和其他可定位个人环境的信息均已省略；测试、发布与尚未验证的结果分别表述。
2026-10-23｜自然语言编程日记
今天的工作主要围绕 MovieClaw 展开。映屿、映迹和寻映终于进入了官方插件仓库，之前等待审核的阶段有了结果。但源码合并并不是结束：插件能否正式下载、别人部署时能否顺利配对、Windows 客户端能否找到这些功能，仍是几件不同的事。
下午，一位使用者反馈映迹首次配对失败，让我们看到了开发环境没有暴露的部署差异。另一条工作线则从 Windows 版的功能核对转入实际开发。两件事的共同点很具体：不能只看代码里有没有功能，还要检查入口、协议和运行环境是否接得上。
三个插件合并，发布进度仍要分别确认
上午查看 GitHub 时，最初看到的仍是等待维护者处理的状态。随后再次核对，映屿、映迹和寻映的三个投稿都已合并，发生在北京时间 11:29 至 11:30。此前关于“是不是还要继续等审核”的判断，也随这个新结果更新了。
截至这次核对，映屿已发布 0.11.0；映迹和寻映确认的是源码合并，后续 Release 与商店上架仍需关注。不能因为三个 PR 都合并，就把三个插件都写成已经完成正式发布。
这也解释了为什么发布状态需要拆开记录。源码进入主分支，说明维护者接受了这次提交；生成发布包、更新商店索引，以及使用者实际安装，是后面的步骤。今天不需要重复投稿，接下来应跟进尚未确认的发布环节。
映迹的首次配对，暴露了地址回连问题
映迹收到的报错原本只有一句“本人接口不可用”。检查后发现，连接超时、证书校验失败和响应格式异常，都被归入了同一句提示。仅凭这张截图，无法判断究竟是哪一层出了问题。
进一步复现时，找到了一个确定的缺陷：没有配置外部访问地址，插件仍会尝试访问占位地址。浏览器能打开页面，也不代表服务器自身能完成配对流程所需的回连；反向代理、公网回环和证书差异，都可能让这两条访问路径表现不同。
这次修改让缺少地址时直接给出配置提示，同时增加可选的本机接口地址。配对和后台同步可以走服务器内部的访问路径，交互页面仍从浏览器当前页面打开。连接错误也被细分，后续排查不必再从一句笼统提示开始猜测。
修复已提交为 PR #23，624 项测试和 GitHub CI 均通过。但它尚待维护者合并、发布，市场现有版本还没有包含这次修改。已复现的缺陷得到修复，并不等于已经确认那位使用者的全部故障原因；对方的服务端版本和访问方式仍需补充核对。
Windows 的插件入口，不能只放一个固定按钮
Windows 版的核对先纠正了开发基线：本地保留着较早的 0.2.112 分支，远端已经发布 1.0.3。审查因此以最新发布版和当前开发分支为主，避免把后来已经补齐的发现、订阅和字幕生成功能重新列入待办。
真正的缺口出在客户端与服务端的衔接。Windows 原有“正在观看”功能固定使用旧插件协议，而映迹采用另一套接口，对应请求实测返回 404。服务端已经提供插件导航接口，客户端却还没有读取它。这不是单纯少一个菜单，而是客户端仍在假定服务器安装了某个特定插件。
后续开发改为识别服务端实际可用的插件，并区分映迹与旧版观看动态插件。旧按钮只看本地开关、卸载后可能仍然出现的问题，也加入了服务端可用性检查和返回应用时刷新。界面测试覆盖了未安装、安装后出现、卸载后清理以及可见性变化等情况。
插件页面计划在独立窗口中打开，保持与主窗口的功能边界。相关界面回归已通过；原生插件窗口的关闭行为和隔离效果还要交给 Windows 托管构建中的测试验证，不能用浏览器界面测试替代这一步。
自动跳过接上偏好，设备登录仍有服务端前提
播放方面，服务端已经下发自动跳过偏好，Windows 仍主要提供手动跳过按钮。今天的开发补入自动执行、撤回和偏好衔接，也补测了设置保存失败后恢复原值的情况，避免界面显示已经开启，实际却没有保存成功。
完整界面回归通过了 128 项，浏览性能测试通过了 4 项。过程中还发现一处旧测试过早读取播放结果：请求尚未发出，测试就开始核对。修正后先等待实际请求，再检查季数和集数，避免把测试时序问题误当成业务错误。
设备登录和地址自动切换也在推进。地址切换加入了服务器身份核验，防止把不同服务器当成同一个目标。Windows 设备登录的服务端测试覆盖了登录、配对、重复登录替换及改密后下线等场景，但当前运行的服务端尚未声明支持 Windows 原生设备登录，因此测试包仍需保留现有登录方式，并提供配套服务端补丁说明。
截至整理时，Windows 托管构建已经启动，这一轮仍在执行中；尚无新测试包完成发布的结论。安装流程、原生窗口和实际播放效果，也不能由本地回归通过来代替验收。
留下的判断和下一步
今天有三点值得记住。第一，源码合并、正式发布和实际可用必须分别确认。第二，浏览器可访问不等于服务器能够回连，错误提示应尽量说明失败发生在哪一层。第三，客户端功能要跟随服务端能力发现，不能把某个插件的存在写成固定前提。
接下来，映迹要等待修复合并发布，并结合使用者的环境确认首次配对问题；Windows 要继续完成托管构建、原生窗口与安装验证，再报告测试包结果。自动化测试已经给出一部分证据，真机播放和实际部署仍需单独验收。
隐私说明
本文仅保留当天对话中可核实的公开项目进展与技术机制。个人身份、私人观影内容、部署地址和其他可定位个人环境的信息均已省略；测试、发布与尚未验证的结果分别表述。