让收藏真正留下来，让播放器真正用起来。 今天的工作集中在 KanBox 和 MovieClaw Windows 客户端。两者都已经有界面和功能入口，但实际使用继续暴露出缺口：收藏文章能取得标题，却未必取得全文；播放器有字幕和音轨选项，却未必真正驱动播放引擎。今天先核对这些链路，再修改代码、运行测试，最后进入发布与真机检查。KanBox 的工作跨过了午夜。上一晚开始的公众号解析与图片归档改造，在今天完成 170 构建；随后，新的样本暴露出正文内的推广图片和另一种短图文结构，继续修到 171，并开放内部 TestFlight 测试。两个构建解决的问题有先后关系，不能只把它们写成一次“解析优化”。MovieClaw 则从 Windows 0.2.111 的源码审计开始，沿用 Tauri、WebView2 和 mpv，先通过托管 Windows CI 修通功能，再转到 Windows 真机修界面与播放交互。下午发布了 1.0.0，之后又在同一版本号下更新安装包。普通播放和部分界面已有实际验证，但双端性能一致、HDR、音频直通和完整原盘能力仍不能算完成。KanBox 170：图片从临时缓存进入独立归档最初检查的公众号文章只解析出标题、作者和一张封面，正文为空。原页面有正文，问题在解析器只读取了分享摘要，没有走到全文和正文图片。与此同时，普通收藏图片主要依赖临时缓存，备份与同步主要保存图片地址；缓存清理或容量淘汰后，不能保证图片还在。这轮修改补上公众号正文和图片提取，并为收藏图片增加独立原件保存、下载进度和失败重试。已归档的原图不再随临时缓存清理而删除，原件也接入 ZIP 备份和 iCloud 恢复流程。文字已经保存到本机，与图片原件下载完成是不同的状态，界面需要分别说明。跨夜完成的 170 对样本实际解析到 944 字、7 张图片，标题和作者正确；2149 条测试无失败，1 条可选联网测试跳过，浅色和深色界面检查通过。随后安装包上传成功，Apple 接收并开始处理，但这一轮没有确认 170 已进入内部测试组。旧条目需要重新解析，图片取得后才能形成离线副本。尚未下载到的图片，不能因为保存过网址就保证恢复。这也是本轮归档改造的边界：保住已经取得的内容，而不是承诺找回已经无法访问的原图。KanBox 171：正文容器里的图片也可能是噪音170 能读全文后，真实文章里又出现了关注横幅、点赞动图和互动提示。这些图片就在正文容器内，单靠页面结构过滤无法排除。后续修复结合关注、点赞提示、关联图片和尾部结构清理明确噪音，同时保留正常教程截图、表格和章节图片。重新解析也不能简单覆盖旧收藏。机器抓入的噪音应当可以清掉，用户手改的正文和额外添加的图片则要保留。图片比例读取也作了补充，避免宽图在阅读界面占据大块留白。一篇样本的正文图片从 7 张变为 5 张，对应关注条、点赞动图及提示文字被移除。新增的 5 个链接全部完成实际联网解析检查，其中一种公众号短图文模板原来未读全，这次补上读取路径，取得 412 字和 9 张正文信息卡。判断不足的图片仍保留，不能据此宣称所有广告都能自动识别。171 最终通过 2184 项测试，0 失败、1 项原有可选测试跳过，浅色和深色阅读检查通过。之后上传、等待处理，并加入内部 TestFlight 组，确认状态为“正在测试”。这证明新版已可进入内部验收；旧收藏重新解析后的真机效果，仍由用户继续检查。MovieClaw：先修请求与播放生命周期，再谈双端一致Windows 0.2.111 的审计找到了 24 项具体问题。搜索接口返回合法结果，客户端仍可能显示为空；大库首次只显示前 200 项，后续加载没有接通；播放进度没有持续上报，关闭时还可能把位置报成零。字幕、音轨和倍速控件存在，也不代表命令已经传给 mpv。修改先从接口合同、服务端分页、排序和请求竞态入手，加入请求取消及旧请求防覆盖。播放部分让 mpv 与 HLS 共用文件时间轴，补上进度上报、最终快照和会话释放，处理自然结束、关闭、换画质与自动下一集之间的竞态。轨道选择使用真实音轨和字幕 ID，持久 mpv IPC 配合有界重连与降级，连接界面操作和引擎行为。开发开始时只有 macOS 环境，Windows 原生构建与测试交给 GitHub Actions。托管 CI 后续通过 90 条 JavaScript 单测、40 条浏览器回归、48 条 Windows Rust 测试，以及构建、安装和启动退出检查。这些结果让候选包可以进入真机验收，但不能证明硬解、音频输出或两端性能已经相同。过程中也纠正了“代码与 CI 已收尾”的笼统说法。完整 QoE 诊断仍缺服务端分段耗时与播放尝试的统一关联、详细卡顿原因和上报结果记录；未加密原盘主标题降级已有实现，但光盘菜单、解密、多角度导航等没有实现。这些是明确的代码或能力缺口，不能全部归为等待真机测试。Windows 真机把界面问题变成了可复现的修复0.2.112 RC 1 发布后，工作转到 Windows，同步源码并启动客户端。用户确认基本播放没有问题，但首页媒体库图标仍缺失，逐页检查又发现封面、分集布局、深色下拉菜单和图标遮挡等问题。Mac 端这轮主要作源码对照，没有完成双机同条件运行比较。修复让封面加载成功时显示封面，失败时保留类型图标；补齐首页、详情、人物页和返回导航。菜单改为清晰的深色样式，常用图标统一为 SVG 线条样式，并处理文字和箭头遮挡。设置页则统一卡片宽度与间距，播放选项成对排列，窄窗口自动转为单列。全屏原来还受到控制条挤压，视频没有使用完整屏幕区域。修复后加入保持原比例和填满屏幕两种画幅，填满通过等比例放大裁掉边缘，并保存选择。这里不能混淆窗口留白和片源内编码的黑边：后者仍没有自动裁除。最后一次播放反馈指出，控制组件一直盖在画面上。新的处理让控件静止约 3 秒后隐藏，移动鼠标恢复；暂停或打开菜单时保持显示。这个改动完成了真实播放验证，并随更新包安装。侧栏收缩、播放信息面板、实时速度显示、双击或 F 键全屏切换也进入了 1.0.0。1.0.0 的交付还包括运行组件与更新校验用户希望新设备安装后不必再补解码器或开发环境。因此安装版打包了 mpv 与 WebView2 离线组件。最初的构建脚本还引用已删除文件，发布流程也需要一起修复，不能只确认开发目录中的程序能够启动。今天先发布 0.2.112 RC 1，再发布并安装 1.0.0。后续界面和播放修复继续使用 1.0.0 版本号，因此更新检查需要辨认同一版本号下的新构建。对应检测、下载和 SHA-256 校验已有实测，最后的控制条修复也重新发布并更新到测试中的 Windows 客户端。发布并不代表原计划全部验收。安装包仍未签名，Windows 设备扫码配对需要服务端对应支持，今天准备了说明与补丁但未部署；HDR、音频直通、原盘实机、长时间稳定性及同条件 Mac 性能比较仍待完成。Mac 的统一跨服务器账号面板也尚未补齐。向上游提交时，把客户端与服务端扩展拆开独立 Windows 客户端准备提交给 MovieClaw 原作者时，先整理了贡献方案：保留上游 README 和版本体系，将客户端、测试、打包与 Windows CI 放进贡献分支，调整写死的更新仓库配置；扫码配对、搜索范围和原盘相关服务端扩展另行拆分。在用户授权后，贡献整理继续执行，最终创建了上游 Draft PR #793。Draft 表示已经提交供讨论，不表示原作者认可或已经合并。记录结束时，Fork CI 正在运行，上游 CI 还需要维护者批准。今天完成的是投稿入口和修改交付，后续仍需等待检查结果与审阅意见。ArtCraft 安装包按软件、平台和版本归类另一个较独立的任务是整理 ArtCraft 软件安装包。页面列出了图片编辑、矢量绘图、视频编辑、照片管理、PDF、特效和排版等工具，用户要求把不同平台版本下载后分类保存。最终按软件、平台、版本归类，另存校验文件，保留不同架构、安装与便携格式，以及 CLI 和 Web 版本。下载结果共 185 个文件、约 9.5 GB，均通过官方 SHA-256 校验。这一步完成了文件取得、分类与完整性核对，没有逐个安装测试。网站对技术架构和能力的介绍，也没有因为下载成功就变成已验证的产品结论。接下来要验证什么今天留下三点认识。内容保存必须区分地址、缓存和原件；只有原件真正取得并归档，才有可靠的离线基础。界面一致必须落实到接口和引擎行为，控件存在不等于功能接通。发布、校验和真机验收各有作用，任何一项都不能替代另外两项。接下来，KanBox 需要在 171 中重新解析旧公众号收藏，检查去噪、手工编辑保护及离线图片恢复。MovieClaw 要补齐诊断链路与服务端配对条件，继续 HDR、音频、原盘和长稳测试，并等待上游 Draft PR 的检查与反馈。双端功能和性能一致仍是验收目标，不是今天已经证明的结果。隐私说明本文仅使用当天有记录支持的进展，省略账户与身份信息、私人媒体内容、收藏链接、服务器地址、设备标识、本地路径及凭据相关细节。保留公开项目名、技术术语和理解版本演进所需的测试数字，不包含完整代码或原始日志。
2026-10-11｜自然语言编程日记
今天的工作集中在 KanBox 和 MovieClaw Windows 客户端。两者都已经有界面和功能入口，但实际使用继续暴露出缺口：收藏文章能取得标题，却未必取得全文；播放器有字幕和音轨选项，却未必真正驱动播放引擎。今天先核对这些链路，再修改代码、运行测试，最后进入发布与真机检查。
KanBox 的工作跨过了午夜。上一晚开始的公众号解析与图片归档改造，在今天完成 170 构建；随后，新的样本暴露出正文内的推广图片和另一种短图文结构，继续修到 171，并开放内部 TestFlight 测试。两个构建解决的问题有先后关系，不能只把它们写成一次“解析优化”。
MovieClaw 则从 Windows 0.2.111 的源码审计开始，沿用 Tauri、WebView2 和 mpv，先通过托管 Windows CI 修通功能，再转到 Windows 真机修界面与播放交互。下午发布了 1.0.0，之后又在同一版本号下更新安装包。普通播放和部分界面已有实际验证，但双端性能一致、HDR、音频直通和完整原盘能力仍不能算完成。
KanBox 170：图片从临时缓存进入独立归档
最初检查的公众号文章只解析出标题、作者和一张封面，正文为空。原页面有正文，问题在解析器只读取了分享摘要，没有走到全文和正文图片。与此同时，普通收藏图片主要依赖临时缓存，备份与同步主要保存图片地址；缓存清理或容量淘汰后，不能保证图片还在。
这轮修改补上公众号正文和图片提取，并为收藏图片增加独立原件保存、下载进度和失败重试。已归档的原图不再随临时缓存清理而删除，原件也接入 ZIP 备份和 iCloud 恢复流程。文字已经保存到本机，与图片原件下载完成是不同的状态，界面需要分别说明。
跨夜完成的 170 对样本实际解析到 944 字、7 张图片，标题和作者正确；2149 条测试无失败，1 条可选联网测试跳过，浅色和深色界面检查通过。随后安装包上传成功，Apple 接收并开始处理，但这一轮没有确认 170 已进入内部测试组。
旧条目需要重新解析，图片取得后才能形成离线副本。尚未下载到的图片，不能因为保存过网址就保证恢复。这也是本轮归档改造的边界：保住已经取得的内容，而不是承诺找回已经无法访问的原图。
KanBox 171：正文容器里的图片也可能是噪音
170 能读全文后，真实文章里又出现了关注横幅、点赞动图和互动提示。这些图片就在正文容器内，单靠页面结构过滤无法排除。后续修复结合关注、点赞提示、关联图片和尾部结构清理明确噪音，同时保留正常教程截图、表格和章节图片。
重新解析也不能简单覆盖旧收藏。机器抓入的噪音应当可以清掉，用户手改的正文和额外添加的图片则要保留。图片比例读取也作了补充，避免宽图在阅读界面占据大块留白。
一篇样本的正文图片从 7 张变为 5 张，对应关注条、点赞动图及提示文字被移除。新增的 5 个链接全部完成实际联网解析检查，其中一种公众号短图文模板原来未读全，这次补上读取路径，取得 412 字和 9 张正文信息卡。判断不足的图片仍保留，不能据此宣称所有广告都能自动识别。
171 最终通过 2184 项测试，0 失败、1 项原有可选测试跳过，浅色和深色阅读检查通过。之后上传、等待处理，并加入内部 TestFlight 组，确认状态为“正在测试”。这证明新版已可进入内部验收；旧收藏重新解析后的真机效果，仍由用户继续检查。
MovieClaw：先修请求与播放生命周期，再谈双端一致
Windows 0.2.111 的审计找到了 24 项具体问题。搜索接口返回合法结果，客户端仍可能显示为空；大库首次只显示前 200 项，后续加载没有接通；播放进度没有持续上报，关闭时还可能把位置报成零。字幕、音轨和倍速控件存在，也不代表命令已经传给 mpv。
修改先从接口合同、服务端分页、排序和请求竞态入手，加入请求取消及旧请求防覆盖。播放部分让 mpv 与 HLS 共用文件时间轴，补上进度上报、最终快照和会话释放，处理自然结束、关闭、换画质与自动下一集之间的竞态。轨道选择使用真实音轨和字幕 ID，持久 mpv IPC 配合有界重连与降级，连接界面操作和引擎行为。
开发开始时只有 macOS 环境，Windows 原生构建与测试交给 GitHub Actions。托管 CI 后续通过 90 条 JavaScript 单测、40 条浏览器回归、48 条 Windows Rust 测试，以及构建、安装和启动退出检查。这些结果让候选包可以进入真机验收，但不能证明硬解、音频输出或两端性能已经相同。
过程中也纠正了“代码与 CI 已收尾”的笼统说法。完整 QoE 诊断仍缺服务端分段耗时与播放尝试的统一关联、详细卡顿原因和上报结果记录；未加密原盘主标题降级已有实现，但光盘菜单、解密、多角度导航等没有实现。这些是明确的代码或能力缺口，不能全部归为等待真机测试。
Windows 真机把界面问题变成了可复现的修复
0.2.112 RC 1 发布后，工作转到 Windows，同步源码并启动客户端。用户确认基本播放没有问题，但首页媒体库图标仍缺失，逐页检查又发现封面、分集布局、深色下拉菜单和图标遮挡等问题。Mac 端这轮主要作源码对照，没有完成双机同条件运行比较。
修复让封面加载成功时显示封面，失败时保留类型图标；补齐首页、详情、人物页和返回导航。菜单改为清晰的深色样式，常用图标统一为 SVG 线条样式，并处理文字和箭头遮挡。设置页则统一卡片宽度与间距，播放选项成对排列，窄窗口自动转为单列。
全屏原来还受到控制条挤压，视频没有使用完整屏幕区域。修复后加入保持原比例和填满屏幕两种画幅，填满通过等比例放大裁掉边缘，并保存选择。这里不能混淆窗口留白和片源内编码的黑边：后者仍没有自动裁除。
最后一次播放反馈指出，控制组件一直盖在画面上。新的处理让控件静止约 3 秒后隐藏，移动鼠标恢复；暂停或打开菜单时保持显示。这个改动完成了真实播放验证，并随更新包安装。侧栏收缩、播放信息面板、实时速度显示、双击或 F 键全屏切换也进入了 1.0.0。
1.0.0 的交付还包括运行组件与更新校验
用户希望新设备安装后不必再补解码器或开发环境。因此安装版打包了 mpv 与 WebView2 离线组件。最初的构建脚本还引用已删除文件，发布流程也需要一起修复，不能只确认开发目录中的程序能够启动。
今天先发布 0.2.112 RC 1，再发布并安装 1.0.0。后续界面和播放修复继续使用 1.0.0 版本号，因此更新检查需要辨认同一版本号下的新构建。对应检测、下载和 SHA-256 校验已有实测，最后的控制条修复也重新发布并更新到测试中的 Windows 客户端。
发布并不代表原计划全部验收。安装包仍未签名，Windows 设备扫码配对需要服务端对应支持，今天准备了说明与补丁但未部署；HDR、音频直通、原盘实机、长时间稳定性及同条件 Mac 性能比较仍待完成。Mac 的统一跨服务器账号面板也尚未补齐。
向上游提交时，把客户端与服务端扩展拆开
独立 Windows 客户端准备提交给 MovieClaw 原作者时，先整理了贡献方案：保留上游 README 和版本体系，将客户端、测试、打包与 Windows CI 放进贡献分支，调整写死的更新仓库配置；扫码配对、搜索范围和原盘相关服务端扩展另行拆分。
在用户授权后，贡献整理继续执行，最终创建了上游 Draft PR #793。Draft 表示已经提交供讨论，不表示原作者认可或已经合并。记录结束时，Fork CI 正在运行，上游 CI 还需要维护者批准。今天完成的是投稿入口和修改交付，后续仍需等待检查结果与审阅意见。
ArtCraft 安装包按软件、平台和版本归类
另一个较独立的任务是整理 ArtCraft 软件安装包。页面列出了图片编辑、矢量绘图、视频编辑、照片管理、PDF、特效和排版等工具，用户要求把不同平台版本下载后分类保存。
最终按软件、平台、版本归类，另存校验文件，保留不同架构、安装与便携格式，以及 CLI 和 Web 版本。下载结果共 185 个文件、约 9.5 GB，均通过官方 SHA-256 校验。
这一步完成了文件取得、分类与完整性核对，没有逐个安装测试。网站对技术架构和能力的介绍，也没有因为下载成功就变成已验证的产品结论。
接下来要验证什么
今天留下三点认识。内容保存必须区分地址、缓存和原件；只有原件真正取得并归档，才有可靠的离线基础。界面一致必须落实到接口和引擎行为，控件存在不等于功能接通。发布、校验和真机验收各有作用，任何一项都不能替代另外两项。
接下来，KanBox 需要在 171 中重新解析旧公众号收藏，检查去噪、手工编辑保护及离线图片恢复。MovieClaw 要补齐诊断链路与服务端配对条件，继续 HDR、音频、原盘和长稳测试，并等待上游 Draft PR 的检查与反馈。双端功能和性能一致仍是验收目标，不是今天已经证明的结果。
隐私说明
本文仅使用当天有记录支持的进展，省略账户与身份信息、私人媒体内容、收藏链接、服务器地址、设备标识、本地路径及凭据相关细节。保留公开项目名、技术术语和理解版本演进所需的测试数字，不包含完整代码或原始日志。