KanBox 的实况照片、媒体交互与 App Store 发布准备 今天的工作几乎都围绕 KanBox 展开。这个项目在很短时间内完成了密集迭代，功能已经从多平台内容收藏扩展到实况照片、离线视频、小组件、分享图和备份恢复。速度带来了明显成果，也让一些只有在真实使用中才会暴露的问题集中出现：首次解析与重新解析的结果不一致，后台任务缺少并发边界，媒体手势互相抢占，分享图导出方向错误，以及“本机可用”和“符合 App Store 发布要求”之间仍有距离。因此，今天没有单纯增加功能，主要处理两件事：逐项修正实际使用中发现的交互和数据问题，开始梳理发布所需的隐私声明、授权和素材使用范围。当天产生了多个连续构建，但每个版本的状态都单独记录，避免把“代码已实现”“自动测试通过”“已安装到设备”和“已经完成真机验收”混为一谈。小红书实况照片与统一媒体模型KanBox 原来已经能处理 Instagram 的 Live Photo，但这条能力仍然带有明显的平台专用痕迹。遇到小红书图文内容时，解析器能得到静态图片，却不会把每张图片附带的短动态片段识别成实况照片，最终只能按普通图集展示。今天用一条真实样本定位了小红书页面中的媒体结构：一组十张图片里，有八张带独立动态片段，另外两张是普通照片。修改没有把整篇内容粗暴地判定成视频，而是在 XiaohongshuState 的解析结果中保留每张图片的实况标记和对应媒体地址，再映射到 KanBox 的通用收藏模型。展示层继续按照原始顺序渲染，实况项显示 LIVE 标识，打开后可以长按播放；保存环节则复用已有的实况照片写入能力，并根据来源选择正确的请求上下文。这一版作为 KanBox 1.30.0（build 81）完成构建、测试和启动检查，并已覆盖安装。它明确支持 Instagram 与小红书的静态图—动态片段配对。其他平台暂时没有被笼统纳入支持范围，因为仍需先确认各平台是否提供可靠的一一对应数据，不能把普通短视频误判成 Live Photo。后台任务并发与数据清理随着收藏数量和媒体类型增加，一次整体代码审计找出了四个会随数据规模放大的问题。原来的离线视频补偿逻辑会在 App 回到前台时扫描大量收藏，而下载器缺少明确的总并发上限；小组件刷新会先清理不在新快照中的封面，再异步准备网络资源，断网时可能短暂退回占位图；备份导出会把图片和 ZIP 数据集中放在内存里，导入也会一次读取整个文件；“清空全部数据”则没有等待离线下载停止和文件删除结束，清理失败也可能被界面误报为成功。这四处分别做了修改：离线下载限制为最多两项并行，其余任务排队，并把前台补偿限制到近期内容和最小检查间隔；小组件刷新保留仍可使用的本地封面缓存；备份与恢复改为后台分块读写；清空流程会先停止下载、等待文件清理完成，并把失败明确反馈给界面。验证包括 915 条测试、解析样本检查、Release 编译，以及 128 MB 备份往返测试；独立测试进程的峰值内存约为 8 MB。随后这些修改进入 1.30.3（build 84），已覆盖安装且没有清除原有数据。同一阶段还修正了 Instagram 快拍首次自动收藏失败的问题。原来的第一次解析没有优先复用 KanBox 内已有的登录会话，导致条目初次入库失败、手动“重新解析”后才成功。新流程在首次收藏时就使用有效会话；视频角标也从模糊的“离线中”细分为在线播放、排队或下载中、已离线，在服务端提供文件大小时还能显示真实进度。小组件则会为旧收藏补建快照，并尽量保留长图和横向视频的原始画幅。这组改动进入 1.30.2（build 83），通过 906 条测试、解析金样本和 Release 构建后安装到设备；但快拍是否可见仍取决于登录状态和账号本身的访问权限。媒体播放与手势冲突媒体查看页随后暴露出另一类问题：手机处于静音模式时，视频也没有声音；边缘返回手势与左右翻图、图片缩放和视频进度条可能互相抢占；长按卡片缺少明确的选中反馈；首页与详情页的分享按钮还打开不同界面。这次重新划分了手势的触发区域和优先级，没有继续叠加手势。媒体播放采用独立的播放型音频会话，使系统静音开关不再直接压掉媒体声音，同时保留播放器自己的静音控制。返回只在边缘起步并满足方向、位移条件时成立，中间区域继续交给翻图、缩放、拖动和进度条。卡片长按先随按住时长逐渐下压，确认触发后再上浮、加阴影并给出触觉反馈；这利用的是 Haptic Touch 的持续时间与震动反馈，并未宣称设备能读取真实压力。首页第四个操作也统一到详情页的分享面板。第一轮修改进入 1.30.4（build 85），通过 923 条单元测试、四项模拟器交互检查和正式包检查后安装。根据真机反馈，媒体返回的起步判定仍然过严，随后在 1.30.5（build 86）中再次修正，并增加详情页图片、原生视频、滚动和手势冲突检查；这一版通过 926 条单元测试与七项交互检查后覆盖安装。这里的自动化结果证明逻辑与模拟交互通过，但静音模式下的听感和不同握持方式仍属于真机体验验收范围。分享图渲染与入库动画分享图生成今天经历了三轮连续修正。首先，导出的长图出现上下翻转，原因是屏幕坐标与离屏渲染坐标方向没有正确统一。校正渲染坐标后，1.30.6（build 87）通过 928 条测试和发布检查，并完成覆盖安装；旧的错误图片不会自动修复，需要重新生成。随后，详情卡片里的海报和内容图片增加了“正方形”与“原比例”两种独立选择：前者居中裁切，后者完整保留画幅，并可保存为默认样式。这项能力进入 1.30.7（build 88）。分享图的作者标识也调整为更稳定的回退链：有头像时显示头像并保留平台标识；头像缺失或加载失败时使用平台图标，不再生成姓名首字占位。该修改进入 1.30.8（build 89），已核对实际导出结果并安装到设备。入库动画则从“解析成功立即撒花”改成等待对应卡片已经出现、图片加载结束且布局稳定后再触发，持续时间延长到约六秒。撒花和删除消散同时减少了绘制负担，避免把卡顿简单归因于设备性能。KanBox 1.30.9（build 90）已完成打包，943 条单元测试和两项界面测试通过；截至当天最后一次明确记录，这一版尚未安装，因此动画流畅度仍需要后续真机验收。当天最后一个可确认已安装版本是 1.30.8（build 89）。App Store 发布前的隐私与授权检查当天后半段的重点从功能实现转向发布准备。审查结论很明确：能在手机上运行，不等于已经适合直接提交 App Store。当前最大的未决风险仍是第三方媒体解析、自动离线和保存功能的授权边界；“仅供个人使用”的说明不能代替平台许可，这一部分今天没有修改，也不能标为已解决。代码中先补齐了能够确定的事项。主 App、分享扩展和小组件分别配置隐私清单，并按各自实际使用的偏好存储、App Group、文件元数据和计时 API 选择用途声明。设置页“关于”增加了可离线阅读的隐私政策和“开源许可与署名”入口，字体版权信息与 MingCute 的完整许可证也被纳入资源。相关构建已经通过，后续又在 1.30.9 的产物中确认三个 target 的隐私清单都被正确打包。素材核查也把“开源代码”和“可用于商业品牌宣传”区分开来。Noto 字体与 MingCute 通用图标已经有较清晰的许可证资料；平台彩色标识仍涉及商标使用边界，从系统字体轮廓生成的 App 图标也缺少足以覆盖独立品牌用途的明确证据。现有宣传截图中的第三方摄影、电影海报、播客封面和演示视频，在没有权利证明前不宜直接用于商店宣传。今天生成的十张界面截图、三张海报、开屏引导短片和冷启动录屏可以作为内部挑选素材，但其中模拟器画面与第三方内容都已被标记，不能直接等同于最终商店物料。公开隐私政策尚缺稳定网页、对外运营者名称和长期有效的公开联系渠道，因此发布准备还没有完成。设置页的下一版只形成了实施方案：保留现有温暖、圆润的视觉语言，用原生 SwiftUI 重组信息层级，继续使用来源明确的实心图标，并以点击或状态变化时的短动画代替整页循环 GIF。这个方案今天仅完成审查和规划，没有实施。今天形成的认识第一，快速连续发版时，必须把“源码已修改、自动测试通过、安装包已生成、已经安装、真机体验已验收”分开记录。今天最后安装的是 build 89，而 build 90 只完成了打包和自动化验证，这个边界比版本号本身更重要。第二，解析型应用的稳定性不只取决于解析规则。登录会话、下载并发、缓存保留、文件生命周期、手势仲裁和离屏渲染坐标，都会直接决定用户看到的结果是否可靠。第三，测试数量可以证明回归覆盖，却不能替代商店合规、素材权利和真机体验。下一步需要优先完成 build 90 的真机动画验收，确定公开隐私政策的发布信息，并单独决定第三方媒体下载能力在上架版中的保留范围。隐私说明本文仅保留理解工作所需的公开项目名、公开框架、版本号、构建号与测试结果。设备唯一标识、账户与身份信息、联系方式、绝对文件路径、私人内容链接、第三方样本正文、登录数据、凭据以及个人基础设施信息均已删除或泛化。对尚未确认的名称或联系信息没有作任何推断。
2026-10-01｜自然语言编程日记
今天的工作几乎都围绕 KanBox 展开。这个项目在很短时间内完成了密集迭代，功能已经从多平台内容收藏扩展到实况照片、离线视频、小组件、分享图和备份恢复。速度带来了明显成果，也让一些只有在真实使用中才会暴露的问题集中出现：首次解析与重新解析的结果不一致，后台任务缺少并发边界，媒体手势互相抢占，分享图导出方向错误，以及“本机可用”和“符合 App Store 发布要求”之间仍有距离。
因此，今天没有单纯增加功能，主要处理两件事：逐项修正实际使用中发现的交互和数据问题，开始梳理发布所需的隐私声明、授权和素材使用范围。当天产生了多个连续构建，但每个版本的状态都单独记录，避免把“代码已实现”“自动测试通过”“已安装到设备”和“已经完成真机验收”混为一谈。
小红书实况照片与统一媒体模型
KanBox 原来已经能处理 Instagram 的 Live Photo，但这条能力仍然带有明显的平台专用痕迹。遇到小红书图文内容时，解析器能得到静态图片，却不会把每张图片附带的短动态片段识别成实况照片，最终只能按普通图集展示。
今天用一条真实样本定位了小红书页面中的媒体结构：一组十张图片里，有八张带独立动态片段，另外两张是普通照片。修改没有把整篇内容粗暴地判定成视频，而是在
XiaohongshuState的解析结果中保留每张图片的实况标记和对应媒体地址，再映射到 KanBox 的通用收藏模型。展示层继续按照原始顺序渲染，实况项显示 LIVE 标识，打开后可以长按播放；保存环节则复用已有的实况照片写入能力，并根据来源选择正确的请求上下文。这一版作为 KanBox 1.30.0（build 81）完成构建、测试和启动检查，并已覆盖安装。它明确支持 Instagram 与小红书的静态图—动态片段配对。其他平台暂时没有被笼统纳入支持范围，因为仍需先确认各平台是否提供可靠的一一对应数据，不能把普通短视频误判成 Live Photo。
后台任务并发与数据清理
随着收藏数量和媒体类型增加，一次整体代码审计找出了四个会随数据规模放大的问题。
原来的离线视频补偿逻辑会在 App 回到前台时扫描大量收藏，而下载器缺少明确的总并发上限；小组件刷新会先清理不在新快照中的封面，再异步准备网络资源，断网时可能短暂退回占位图；备份导出会把图片和 ZIP 数据集中放在内存里，导入也会一次读取整个文件；“清空全部数据”则没有等待离线下载停止和文件删除结束，清理失败也可能被界面误报为成功。
这四处分别做了修改：离线下载限制为最多两项并行，其余任务排队，并把前台补偿限制到近期内容和最小检查间隔；小组件刷新保留仍可使用的本地封面缓存；备份与恢复改为后台分块读写；清空流程会先停止下载、等待文件清理完成，并把失败明确反馈给界面。验证包括 915 条测试、解析样本检查、Release 编译，以及 128 MB 备份往返测试；独立测试进程的峰值内存约为 8 MB。随后这些修改进入 1.30.3（build 84），已覆盖安装且没有清除原有数据。
同一阶段还修正了 Instagram 快拍首次自动收藏失败的问题。原来的第一次解析没有优先复用 KanBox 内已有的登录会话，导致条目初次入库失败、手动“重新解析”后才成功。新流程在首次收藏时就使用有效会话；视频角标也从模糊的“离线中”细分为在线播放、排队或下载中、已离线，在服务端提供文件大小时还能显示真实进度。小组件则会为旧收藏补建快照，并尽量保留长图和横向视频的原始画幅。这组改动进入 1.30.2（build 83），通过 906 条测试、解析金样本和 Release 构建后安装到设备；但快拍是否可见仍取决于登录状态和账号本身的访问权限。
媒体播放与手势冲突
媒体查看页随后暴露出另一类问题：手机处于静音模式时，视频也没有声音；边缘返回手势与左右翻图、图片缩放和视频进度条可能互相抢占；长按卡片缺少明确的选中反馈；首页与详情页的分享按钮还打开不同界面。
这次重新划分了手势的触发区域和优先级，没有继续叠加手势。媒体播放采用独立的播放型音频会话，使系统静音开关不再直接压掉媒体声音，同时保留播放器自己的静音控制。返回只在边缘起步并满足方向、位移条件时成立，中间区域继续交给翻图、缩放、拖动和进度条。卡片长按先随按住时长逐渐下压，确认触发后再上浮、加阴影并给出触觉反馈；这利用的是 Haptic Touch 的持续时间与震动反馈，并未宣称设备能读取真实压力。首页第四个操作也统一到详情页的分享面板。
第一轮修改进入 1.30.4（build 85），通过 923 条单元测试、四项模拟器交互检查和正式包检查后安装。根据真机反馈，媒体返回的起步判定仍然过严，随后在 1.30.5（build 86）中再次修正，并增加详情页图片、原生视频、滚动和手势冲突检查；这一版通过 926 条单元测试与七项交互检查后覆盖安装。这里的自动化结果证明逻辑与模拟交互通过，但静音模式下的听感和不同握持方式仍属于真机体验验收范围。
分享图渲染与入库动画
分享图生成今天经历了三轮连续修正。首先，导出的长图出现上下翻转，原因是屏幕坐标与离屏渲染坐标方向没有正确统一。校正渲染坐标后，1.30.6（build 87）通过 928 条测试和发布检查，并完成覆盖安装；旧的错误图片不会自动修复，需要重新生成。
随后，详情卡片里的海报和内容图片增加了“正方形”与“原比例”两种独立选择：前者居中裁切，后者完整保留画幅，并可保存为默认样式。这项能力进入 1.30.7（build 88）。分享图的作者标识也调整为更稳定的回退链：有头像时显示头像并保留平台标识；头像缺失或加载失败时使用平台图标，不再生成姓名首字占位。该修改进入 1.30.8（build 89），已核对实际导出结果并安装到设备。
入库动画则从“解析成功立即撒花”改成等待对应卡片已经出现、图片加载结束且布局稳定后再触发，持续时间延长到约六秒。撒花和删除消散同时减少了绘制负担，避免把卡顿简单归因于设备性能。KanBox 1.30.9（build 90）已完成打包，943 条单元测试和两项界面测试通过；截至当天最后一次明确记录，这一版尚未安装，因此动画流畅度仍需要后续真机验收。当天最后一个可确认已安装版本是 1.30.8（build 89）。
App Store 发布前的隐私与授权检查
当天后半段的重点从功能实现转向发布准备。审查结论很明确：能在手机上运行，不等于已经适合直接提交 App Store。当前最大的未决风险仍是第三方媒体解析、自动离线和保存功能的授权边界；“仅供个人使用”的说明不能代替平台许可，这一部分今天没有修改，也不能标为已解决。
代码中先补齐了能够确定的事项。主 App、分享扩展和小组件分别配置隐私清单，并按各自实际使用的偏好存储、App Group、文件元数据和计时 API 选择用途声明。设置页“关于”增加了可离线阅读的隐私政策和“开源许可与署名”入口，字体版权信息与 MingCute 的完整许可证也被纳入资源。相关构建已经通过，后续又在 1.30.9 的产物中确认三个 target 的隐私清单都被正确打包。
素材核查也把“开源代码”和“可用于商业品牌宣传”区分开来。Noto 字体与 MingCute 通用图标已经有较清晰的许可证资料；平台彩色标识仍涉及商标使用边界，从系统字体轮廓生成的 App 图标也缺少足以覆盖独立品牌用途的明确证据。现有宣传截图中的第三方摄影、电影海报、播客封面和演示视频，在没有权利证明前不宜直接用于商店宣传。今天生成的十张界面截图、三张海报、开屏引导短片和冷启动录屏可以作为内部挑选素材，但其中模拟器画面与第三方内容都已被标记，不能直接等同于最终商店物料。
公开隐私政策尚缺稳定网页、对外运营者名称和长期有效的公开联系渠道，因此发布准备还没有完成。设置页的下一版只形成了实施方案：保留现有温暖、圆润的视觉语言，用原生 SwiftUI 重组信息层级，继续使用来源明确的实心图标，并以点击或状态变化时的短动画代替整页循环 GIF。这个方案今天仅完成审查和规划，没有实施。
今天形成的认识
第一，快速连续发版时，必须把“源码已修改、自动测试通过、安装包已生成、已经安装、真机体验已验收”分开记录。今天最后安装的是 build 89，而 build 90 只完成了打包和自动化验证，这个边界比版本号本身更重要。
第二，解析型应用的稳定性不只取决于解析规则。登录会话、下载并发、缓存保留、文件生命周期、手势仲裁和离屏渲染坐标，都会直接决定用户看到的结果是否可靠。
第三，测试数量可以证明回归覆盖，却不能替代商店合规、素材权利和真机体验。下一步需要优先完成 build 90 的真机动画验收，确定公开隐私政策的发布信息，并单独决定第三方媒体下载能力在上架版中的保留范围。
隐私说明
本文仅保留理解工作所需的公开项目名、公开框架、版本号、构建号与测试结果。设备唯一标识、账户与身份信息、联系方式、绝对文件路径、私人内容链接、第三方样本正文、登录数据、凭据以及个人基础设施信息均已删除或泛化。对尚未确认的名称或联系信息没有作任何推断。