KanBox 的媒体解析、博客后端升级与 MovieClaw 的任务排查 今天主要改进 KanBox 的内容收藏体验，维护 Mix Space 与 Yohaku，并处理 MovieClaw 的媒体管理链路。这些项目反复遇到同一个问题：界面上的成功提示只能说明某一层走通，未必说明用户最终需要的结果已经实现。KanBox 的起点是实际使用反馈：视频能播放，却仍有水印；收藏能生成，却混入推荐图片，丢失正文层次；卡片信息齐全，却拥挤得难以阅读。博客维护则从配置和版本检查走向正式升级，需要证明必要修复没有被官方新版本冲掉。MovieClaw 需要把下载、入库和后台任务衔接起来，同时处理代理路由与数据库并发带来的阻碍。因此，今天最有价值的工作是逐层验证结果，而不是增加功能数量：检查真实文件、走应用自身的保存路径、核对公开接口数据、验证隔离恢复，再把已实现、已测试、已安装和仍待验收的部分分别记清楚。本文只记录当天截至本次运行时已有的对话证据。KanBox 的无水印视频识别KanBox 今天经历了多轮媒体能力升级。1.8.0 已让抖音、微博的真实样本进入原生播放器，支持暂停、退出重开和部分进度拖动；小红书也能播放，但拿到的文件仍含水印。1.8.1 随后增加完整下载和真实视频轨道校验，拒绝空文件、片段以及伪装成 MP4 的错误页面。三个平台的样本在专用模拟器中实际保存到了系统相册，保存文件与下载源逐字节一致，但这时的小红书无水印问题仍没有解决。到了 1.8.3，抖音增加了官方播放器 Resource Timing 兜底，从公开播放器实际加载的资源中寻找视频，同时继续限制视频标识、官方媒体来源和文件格式。微博则补上多清晰度列表解析，结合质量、分辨率和码率选择来源，再回退旧字段。这一版后来完成真机安装和启动，但安装成功本身仍不能代替所有平台的真机播放与相册验收。继续追查原文件，才找到小红书视频带水印的原因。页面中的 originVideoKey 能指向原始视频，然而该端点使用通用二进制 MIME，地址也没有 MP4 扩展名。原来的探测条件只接受 video/mp4，于是拒绝了实际有效的原文件，退回带水印的转码流。新的识别逻辑检查 MP4 的 ftyp 文件签名，让响应头与真实容器格式相互验证。播放器还有第二道障碍：AVPlayer 对“无扩展名加通用 MIME”的资源报格式不支持。修复复用了现有分段资源加载器，只对限定的官方原文件来源声明 MP4 容器，继续按段在线播放。保存链路则保留完整长度和视频轨道检查，避免把“识别为视频”误当成“已经完整下载”。最终，一条约一分钟的公开测试样本通过了应用内播放和保存路径验证，保存文件与原始 CDN 文件的 SHA-256 一致；抽帧对照显示，原文件没有转码副本中的平台水印。这是该样本的验证结果，不能扩大成所有小红书视频都能无水印。1.8.4 完成了 735 条单测、解析金样本与工程检查，并已安装到真机、成功启动；用户日常使用中的全面复验仍需要继续。KanBox 的正文解析与历史收藏修复微博图文的错误来自另一个过宽的成功条件。现代网页外壳包含导航头像和推荐图片，解析器看到图片便判断内容已经取得，没有继续请求具体状态的公开 JSON。结果是收藏里混入大量无关图片，正文和作者信息却不完整。修复收紧了状态链接的解析判据，让这类链接优先采用公开状态数据。真实样本从此前的 39 张杂图收敛为 18 张按接口顺序排列的原图；头像进入作者区域，正文保留段落。另一处修复处理了旧逻辑把换行压成空格、把整段文案同时写入标题和正文的问题，减少内容重复和阅读拥挤。历史收藏的修复也需要边界。重新收藏同一链接时，新版可以识别旧版错误或空壳记录并原地补全，避免新增重复项；常规“重新解析”则更新作者、头像、图片、视频来源和解析状态，保留可能经过用户编辑的标题、正文、标签与星标。当前还没有强制覆盖全文的按钮，这意味着媒体刷新和正文重写仍是不同操作。抖音的作者资料从官方播放器公开页面补齐，只填空缺字段。首页黄色解析提醒移入详情页，问题依然可见，却不再抢占卡片的主要视觉位置。网格采用封面、平台标签、圆头像与用户名的层级，单列增加留白和正文行距；借鉴 PicSeed 的呈现方式时，调整的是信息顺序，而不是直接复制内容。界面截图和回归已完成，最终观感仍要结合真机使用反馈判断。Mix Space 官方版本升级与补丁复核博客维护先核对了当前补丁与官方 Core 的差异。此前运行的 14.14.4 包含必要维护修复，而官方 14.15.0 尚不能直接等价替代这些行为。因此，最初的检查阶段只是整理复用记录，没有马上升级；后续方案获得确认后，才进入“官方新版本基底加必要修复”的实施阶段。维护内容分成四组：MiMo 兼容、S3 地址与删除及读者图片清理保护、PostgreSQL 16 备份工具、配置存储加密。各组需要分别审查和验证，不能把旧编译包整体复制到新版。对象存储部分还保留了新版本自身的同名文件防覆盖逻辑，避免补旧问题时倒退官方已经增加的保护。备份工具的匹配尤其具体。新官方镜像中的 PostgreSQL 18 工具与现有 PostgreSQL 16 数据库不一致，因此仍需保留 PG16 工具修复。上线前完成备份、隔离恢复和加密字段解密验证，并比较迁移文件、应用迁移代码与迁移记录，确认本次无需改变数据库结构。存储与配置加密的回归分别通过后，才构建并切换新镜像。最终 Core 已升级到 14.15.0 基底，四组必要补丁重新移植，公开 API 和页面访问检查正常，上线后的新备份也通过隔离恢复。这是已发布的后端升级；主站前端、数据库和 Redis 没有随之升级。后台管理界面的静态资源更新同样不能代表 Core 或 Yohaku 整站更新。这里仍有明确的未完成项：DeepSeek 翻译问题没有因升级自动解决，本轮没有重试；旧留言图片和邮件实际收件也待分别验证。补丁资料已经归档，未来应逐组检查上游是否提供等价修复，验证成立后再退役，而不是永久冻结在今天的维护版本。Yohaku 状态展示的配对入口关于桌面状态展示的讨论，厘清了旧 activity 与 Live Desk 的关系。旧方案依赖进程上报与云函数，新方案由 Yohaku Companion 把经过隐私规则处理的状态发送给 Core。两者用途相近，但并不是同一个开关，也不应同时凭名字猜测配置效果。配对时需要注意前后端分离部署的地址区别。客户端需要完整后端 API 地址，不会自动补齐 API 路径；把站点首页当作服务入口会在配对前检查阶段失败。对话中的请求验证表明，错误入口返回 404，正确 API 入口返回 200。这只证明检查入口已经定位并更正，整个公开状态展示尚未完成验证。后续仍需完成配对、检查脱敏预览、确认分享范围，再验证页面展示、更新与停止共享后的清除行为。实现讨论中的样式和功能基础，也不能提前写成访客已经可用的上线结果。MovieClaw 的入库链路与 MCP 代理MovieClaw 的自动入库配置把电影、剧集和其他内容分开路由，并采用硬链接保留下载源供做种。实际文件测试核对了源和目标的底层文件标识，确认在当时的存储挂载上可以创建硬链接；自动链路体检也显示正常。现有混合下载目录没有被直接纳入批量整理，避免把存量资源误分流。目录名本身不能保证入库正确，下载器、容器可见路径与入库规则必须指向同一批真实文件。硬链接能减少重复占用，但需要在实际文件系统上验证是否可行，不能只凭配置界面推断。当天完成的是配置和文件级测试，后续新下载的完整入库行为仍应持续观察。MCP 接入又遇到了代理层问题：官方镜像的 Nginx 缺少 MCP 路由转发，导致服务能力存在却无法经入口访问。补齐运行配置与容器内模板后，客户端连接成功，普通容器重启后的复测也通过。不过，重建容器可能覆盖镜像外的修补；今天证明的是连接与重启行为，尚未证明未来镜像升级能够自动保留它。MovieClaw 的写锁冲突与排队重试章节生成期间，多个媒体库同时扫描、写入进度并生成附属文件，引发 SQLite 的短暂写锁冲突。数据库完整性检查正常，因此对话中将问题定位为并发写入竞争，而非媒体损坏或数据库损坏。处理时保留了已完成进度，并确认失败任务已有重试排队，避免重复创建。活动页中的旧失败记录被忽略后显示当前无需处理，但执行槽当时仍被其他任务占用，重试尚未开始。因此不能把它记为“已修复完成”：当天完成了定位和队列处理，剩余章节生成仍在等待执行，没有证据表明底层并发写锁问题已得到代码层面的彻底修复。留给后续工作的认识今天留下了三点可以跨项目复用的认识。第一，协议元数据需要与真实内容相互验证：MIME、网页图片数量和代理入口都可能给出不完整信号，文件签名、结构化正文与实际请求才能把判断收紧。第二，回归测试、模拟器操作、真机安装和线上验收各有范围，版本号更新不能把这些范围合并。第三，维护需要保留恢复能力和用户内容边界，补丁逐组移植、隔离恢复以及安全重新解析都服务于这个目标。后续重点是 KanBox 的更多真实样本与真机播放保存复验，Mix Space 的翻译、旧图和邮件收件验证，以及 MovieClaw 排队任务的最终执行结果。Yohaku Live Desk 则继续按配对、分享确认和展示验收的顺序推进。隐私说明本文仅根据当天有活动的有效技术对话整理，合并了重复工作线，未纳入自动化运行与日记生成发布相关对话。已删除或泛化账号信息、私人内容、个人基础设施、设备标识和部署地址；保留公开项目名、版本及必要的验证方法。文中的样本结论仅对应已记录的验证范围，不代表所有平台内容或所有运行环境均已验收。
2026-09-29｜自然语言编程日记
今天主要改进 KanBox 的内容收藏体验，维护 Mix Space 与 Yohaku，并处理 MovieClaw 的媒体管理链路。这些项目反复遇到同一个问题：界面上的成功提示只能说明某一层走通，未必说明用户最终需要的结果已经实现。
KanBox 的起点是实际使用反馈：视频能播放，却仍有水印；收藏能生成，却混入推荐图片，丢失正文层次；卡片信息齐全，却拥挤得难以阅读。博客维护则从配置和版本检查走向正式升级，需要证明必要修复没有被官方新版本冲掉。MovieClaw 需要把下载、入库和后台任务衔接起来，同时处理代理路由与数据库并发带来的阻碍。
因此，今天最有价值的工作是逐层验证结果，而不是增加功能数量：检查真实文件、走应用自身的保存路径、核对公开接口数据、验证隔离恢复，再把已实现、已测试、已安装和仍待验收的部分分别记清楚。本文只记录当天截至本次运行时已有的对话证据。
KanBox 的无水印视频识别
KanBox 今天经历了多轮媒体能力升级。1.8.0 已让抖音、微博的真实样本进入原生播放器，支持暂停、退出重开和部分进度拖动；小红书也能播放，但拿到的文件仍含水印。1.8.1 随后增加完整下载和真实视频轨道校验，拒绝空文件、片段以及伪装成 MP4 的错误页面。三个平台的样本在专用模拟器中实际保存到了系统相册，保存文件与下载源逐字节一致，但这时的小红书无水印问题仍没有解决。
到了 1.8.3，抖音增加了官方播放器 Resource Timing 兜底，从公开播放器实际加载的资源中寻找视频，同时继续限制视频标识、官方媒体来源和文件格式。微博则补上多清晰度列表解析，结合质量、分辨率和码率选择来源，再回退旧字段。这一版后来完成真机安装和启动，但安装成功本身仍不能代替所有平台的真机播放与相册验收。
继续追查原文件，才找到小红书视频带水印的原因。页面中的 originVideoKey 能指向原始视频，然而该端点使用通用二进制 MIME，地址也没有 MP4 扩展名。原来的探测条件只接受 video/mp4，于是拒绝了实际有效的原文件，退回带水印的转码流。新的识别逻辑检查 MP4 的 ftyp 文件签名，让响应头与真实容器格式相互验证。
播放器还有第二道障碍：AVPlayer 对“无扩展名加通用 MIME”的资源报格式不支持。修复复用了现有分段资源加载器，只对限定的官方原文件来源声明 MP4 容器，继续按段在线播放。保存链路则保留完整长度和视频轨道检查，避免把“识别为视频”误当成“已经完整下载”。
最终，一条约一分钟的公开测试样本通过了应用内播放和保存路径验证，保存文件与原始 CDN 文件的 SHA-256 一致；抽帧对照显示，原文件没有转码副本中的平台水印。这是该样本的验证结果，不能扩大成所有小红书视频都能无水印。1.8.4 完成了 735 条单测、解析金样本与工程检查，并已安装到真机、成功启动；用户日常使用中的全面复验仍需要继续。
KanBox 的正文解析与历史收藏修复
微博图文的错误来自另一个过宽的成功条件。现代网页外壳包含导航头像和推荐图片，解析器看到图片便判断内容已经取得，没有继续请求具体状态的公开 JSON。结果是收藏里混入大量无关图片，正文和作者信息却不完整。
修复收紧了状态链接的解析判据，让这类链接优先采用公开状态数据。真实样本从此前的 39 张杂图收敛为 18 张按接口顺序排列的原图；头像进入作者区域，正文保留段落。另一处修复处理了旧逻辑把换行压成空格、把整段文案同时写入标题和正文的问题，减少内容重复和阅读拥挤。
历史收藏的修复也需要边界。重新收藏同一链接时，新版可以识别旧版错误或空壳记录并原地补全，避免新增重复项；常规“重新解析”则更新作者、头像、图片、视频来源和解析状态，保留可能经过用户编辑的标题、正文、标签与星标。当前还没有强制覆盖全文的按钮，这意味着媒体刷新和正文重写仍是不同操作。
抖音的作者资料从官方播放器公开页面补齐，只填空缺字段。首页黄色解析提醒移入详情页，问题依然可见，却不再抢占卡片的主要视觉位置。网格采用封面、平台标签、圆头像与用户名的层级，单列增加留白和正文行距；借鉴 PicSeed 的呈现方式时，调整的是信息顺序，而不是直接复制内容。界面截图和回归已完成，最终观感仍要结合真机使用反馈判断。
Mix Space 官方版本升级与补丁复核
博客维护先核对了当前补丁与官方 Core 的差异。此前运行的 14.14.4 包含必要维护修复，而官方 14.15.0 尚不能直接等价替代这些行为。因此，最初的检查阶段只是整理复用记录，没有马上升级；后续方案获得确认后，才进入“官方新版本基底加必要修复”的实施阶段。
维护内容分成四组：MiMo 兼容、S3 地址与删除及读者图片清理保护、PostgreSQL 16 备份工具、配置存储加密。各组需要分别审查和验证，不能把旧编译包整体复制到新版。对象存储部分还保留了新版本自身的同名文件防覆盖逻辑，避免补旧问题时倒退官方已经增加的保护。
备份工具的匹配尤其具体。新官方镜像中的 PostgreSQL 18 工具与现有 PostgreSQL 16 数据库不一致，因此仍需保留 PG16 工具修复。上线前完成备份、隔离恢复和加密字段解密验证，并比较迁移文件、应用迁移代码与迁移记录，确认本次无需改变数据库结构。存储与配置加密的回归分别通过后，才构建并切换新镜像。
最终 Core 已升级到 14.15.0 基底，四组必要补丁重新移植，公开 API 和页面访问检查正常，上线后的新备份也通过隔离恢复。这是已发布的后端升级；主站前端、数据库和 Redis 没有随之升级。后台管理界面的静态资源更新同样不能代表 Core 或 Yohaku 整站更新。
这里仍有明确的未完成项：DeepSeek 翻译问题没有因升级自动解决，本轮没有重试；旧留言图片和邮件实际收件也待分别验证。补丁资料已经归档，未来应逐组检查上游是否提供等价修复，验证成立后再退役，而不是永久冻结在今天的维护版本。
Yohaku 状态展示的配对入口
关于桌面状态展示的讨论，厘清了旧 activity 与 Live Desk 的关系。旧方案依赖进程上报与云函数，新方案由 Yohaku Companion 把经过隐私规则处理的状态发送给 Core。两者用途相近，但并不是同一个开关，也不应同时凭名字猜测配置效果。
配对时需要注意前后端分离部署的地址区别。客户端需要完整后端 API 地址，不会自动补齐 API 路径；把站点首页当作服务入口会在配对前检查阶段失败。对话中的请求验证表明，错误入口返回 404，正确 API 入口返回 200。这只证明检查入口已经定位并更正，整个公开状态展示尚未完成验证。
后续仍需完成配对、检查脱敏预览、确认分享范围，再验证页面展示、更新与停止共享后的清除行为。实现讨论中的样式和功能基础，也不能提前写成访客已经可用的上线结果。
MovieClaw 的入库链路与 MCP 代理
MovieClaw 的自动入库配置把电影、剧集和其他内容分开路由，并采用硬链接保留下载源供做种。实际文件测试核对了源和目标的底层文件标识，确认在当时的存储挂载上可以创建硬链接；自动链路体检也显示正常。现有混合下载目录没有被直接纳入批量整理，避免把存量资源误分流。
目录名本身不能保证入库正确，下载器、容器可见路径与入库规则必须指向同一批真实文件。硬链接能减少重复占用，但需要在实际文件系统上验证是否可行，不能只凭配置界面推断。当天完成的是配置和文件级测试，后续新下载的完整入库行为仍应持续观察。
MCP 接入又遇到了代理层问题：官方镜像的 Nginx 缺少 MCP 路由转发，导致服务能力存在却无法经入口访问。补齐运行配置与容器内模板后，客户端连接成功，普通容器重启后的复测也通过。不过，重建容器可能覆盖镜像外的修补；今天证明的是连接与重启行为，尚未证明未来镜像升级能够自动保留它。
MovieClaw 的写锁冲突与排队重试
章节生成期间，多个媒体库同时扫描、写入进度并生成附属文件，引发 SQLite 的短暂写锁冲突。数据库完整性检查正常，因此对话中将问题定位为并发写入竞争，而非媒体损坏或数据库损坏。
处理时保留了已完成进度，并确认失败任务已有重试排队，避免重复创建。活动页中的旧失败记录被忽略后显示当前无需处理，但执行槽当时仍被其他任务占用，重试尚未开始。因此不能把它记为“已修复完成”：当天完成了定位和队列处理，剩余章节生成仍在等待执行，没有证据表明底层并发写锁问题已得到代码层面的彻底修复。
留给后续工作的认识
今天留下了三点可以跨项目复用的认识。第一，协议元数据需要与真实内容相互验证：MIME、网页图片数量和代理入口都可能给出不完整信号，文件签名、结构化正文与实际请求才能把判断收紧。第二，回归测试、模拟器操作、真机安装和线上验收各有范围，版本号更新不能把这些范围合并。第三，维护需要保留恢复能力和用户内容边界，补丁逐组移植、隔离恢复以及安全重新解析都服务于这个目标。
后续重点是 KanBox 的更多真实样本与真机播放保存复验，Mix Space 的翻译、旧图和邮件收件验证，以及 MovieClaw 排队任务的最终执行结果。Yohaku Live Desk 则继续按配对、分享确认和展示验收的顺序推进。
隐私说明
本文仅根据当天有活动的有效技术对话整理，合并了重复工作线，未纳入自动化运行与日记生成发布相关对话。已删除或泛化账号信息、私人内容、个人基础设施、设备标识和部署地址；保留公开项目名、版本及必要的验证方法。文中的样本结论仅对应已记录的验证范围，不代表所有平台内容或所有运行环境均已验收。