企业官网建设流程全解析

• 音视频
• 直播
• 移动开发

Pure Live 是跨 Android / Windows / Linux / macOS / iOS 的直播聚合客户端，3.2.0 版本已于 2026-09-25 从claude分支发布（Android arm64、Windows x64、Linux x64，未推送应用内更新），但发布并不意味着验收结束——本文基于 验收状态快照 这一权威文档，系统讲解该版本"发布后继续补齐真机验收缺口"的完整状态机：62 个编号验收行如何计数、PASS / RUN / NR 的真实语义、六项主要阻塞、下一批执行顺序，以及背后由验收入口、编号矩阵、工作流路由和质量门禁构成的证据驱动开发体系。读完本文，你将能准确读懂 Pure Live 仓库里任意验收文档的"当前状态"表格，并能按本文给出的顺序与门禁理解 3.2.0 后续收口工作的推进方式。

一、验收状态快照：一份只保留"当前结论"的权威文档

docs/ACCEPTANCE_STATUS_3_2_0.md是 3.2.0 版本验收的"当前状态"所有者，其文档职责在 AGENT_WORKFLOW.md 的"文档所有权"表中被明确限定：

当前总数和主要发布阻塞由本文件维护；状态快照变化时才更新，不追加常规 Issue 叙述。

这意味着它不是流水账，而是只有当前快照和主要阻塞的收敛页。与之配套的四份文档各有分工：

这种"当前页 + 归档页 + 矩阵 + 入口"的四层结构，正是为了避免历史增量日志被误读为当前完成度——原文档明确警告："本页用于回答剩余范围，避免从大量历史增量日志推测完成度。"

1.1 当前可证明的状态：每一项都必须有证据

快照中的"当前可证明的状态"表格不是一份空洞的项目进度表，每一行都绑定具体的证据类型与边界。核心条目如下：

• 功能源码基线：依赖配置至060420f7，Flutter 3.47.5、AGP 9.3.3、Gradle 9.7.1、FFmpeg 9.0.2 覆盖 Android/Windows/Linux/macOS/iOS；最新本地 Full 记录为20260924T033341958Z-quality-full.json（b6033234，Analyze 与5334/5334测试通过），公开接口探测42/42。文档明确强调"这仍不代替双端客户端完整验收"。
• Android 最新本机构建：e4532d77arm64 Debug 已通过构建门禁，FFmpeg 9.0.2 AAR、18 个原生库及 16 KB ELF 门禁由本机构建验证；但手机上安装的仍是较早31a3c964候选，A0～A8 矩阵待按设备轮转窗口执行。
• 五平台原生升级：Linux / macOS / iOS 的 GitHub Actions 构建通过，Apple 两端均核对实际打包的 FFmpeg 9.0.2 架构和版本——但文档注明"这是构建证据，不等于设备/GUI 功能验收"。
• 手机快照：192.168.1.2:5555已核对 25102RKBEC / myron，su -c id为 root；覆盖安装前无运行进程或录制服务，安装后前台是另一应用，本批未启动 Pure Live。
• 平台范围：当前33 个直播站点 + IPTV，0 组未注册，即源码共 34 个适配器（见 平台兼容性 开头说明；3.2.8 下线 11 个难维护平台、3.2.11 下线 Kick）。

贯穿全表的边界纪律是："旧包证据不自动覆盖当前源码"——每一行都只对应当前提交 SHA、当前构建、当前设备，历史上通过过不代表现在通过。

1.2 编号统计：62 行、20 PASS / 42 RUN / 0 NR 的真实含义

快照中的编号统计是本文最容易被误读的数字，原文档特别澄清了三点：

正确读法：

1. RUN 是"待补证或部分完成"，不等于 42 个当前 Bug——一行通常包含多个动作和平台组合，RUN 只覆盖其中某个子场景。
2. 42 不是整个目标的全部剩余量——它只是编号账本的未闭环行数；账本之外还有平台能力表、长时验证和发布门禁。
3. 不能由此推导完成百分比——部分 PASS 属于旧版本/旧设备，不能自动覆盖当前候选；旧包、旧设备、单次探针或源码测试都不自动覆盖当前候选的整行。

这一语义与 验收矩阵 中定义的NR（未执行）、RUN（执行中）、PASS（通过）、FAIL（失败）、BLOCKED（缺少当前外部条件）一致，且矩阵明确要求："PASS必须附日志、截图、命令记录或确定性测试路径；构建成功不等于功能通过。"

二、六项主要阻塞：发布后的真机验收缺口

快照列出了六项阻塞，每一项都对应具体的"当前证据缺口"，而非模糊的"待完善"：

1. 当前原生闭环缺失：升级版 Android Debug 已本机构建，但手机仍装较早候选；A0～A8 与当前 Windows Native Assets 的 GUI/录制复验待按轮转窗口执行，两端均无 3.2.0 Release 候选。
2. Windows GUI/性能批次未完成：e4532d77Debug 已构建，但旧版 1+3 多画面帧停滞复验不能代替升级版；多 DPI、主副屏、PiP/全屏/多窗口、WebView2、Issue #767 的 4K GPU 对照、音频与帧进度及严格退出计时仍需集中执行。
3. Android 组合矩阵未闭合：锁屏/后台、横屏/系统返回、PiP、实体音量键、自动录制和累计数据迁移仍需在当前候选上覆盖，设备在线时优先合并执行。
4. 平台与录制范围较大：每个平台的目录、播放、弹幕、录制、断流恢复和资源释放尚未全部在当前双端候选上完成；OPENREC 当前官网/公共接口 CloudFront 403，需在可访问窗口复核；长录和严格解码仍是发布门禁。
5. 平台扩展继续推进：战旗与浪 Live 等待当前生产媒体证据后注册；DLive、一直播与企鹅电竞已完成生命周期归档；十余个平台已进入源码能力表，双端原生与录制证据并入集中验收。
6. 发布链未开始：版本冻结、正式签名、全平台串行产物、README/更新日志、资产复验和 GitHub 发布均等待前述门禁。

可以看出，这套阻塞体系的共同特征是**"构建证据 ≠ 功能验收"**：每一条都严格区分了"代码已修/已构建"与"真机上已验证"，这正是 Pure Live 验收哲学的核心。

三、下一批执行顺序：按证据链而非按页面推进

快照给出的下一批顺序，与 完整验收入口 中"一次只走一条最短证据链"的原则完全一致：

1. 继续按战旗、浪 Live 的生产证据门槛与 C2/C3 活跃平台顺序扩展源码；同时完成仍可确定复现的 Issue/所有权缺口，已经修复或证据不足的条目停止重复调查。
2. Android 与 Windows 以e4532d77原生升级 Debug 作为下一批候选；Windows 批量复验多格画面、音频与退出；Android 按轮转规则保留数据覆盖安装升级版后集中收口 A0～A8。
3. 同一候选集中完成平台播放/弹幕/录制、资源与性能证据，失败项回源码修订后只重跑受影响组。
4. 42 个编号组和发布范围实际闭合后，固定 3.2.0 提交并执行完整发布门禁。

这一顺序体现了三个工程原则：

• 同候选集中验证：不为每个小改动单独构建、安装或启动 GUI（来自验收入口第 5 条"批量做原生验收"）；
• 失败只重跑受影响组：避免为小改动重复支付全仓门禁成本；
• 确定性复现优先：验收入口第 2 条要求"找到首个错误状态，写最小红测或固定夹具，不要用反复 GUI 点击、任意延时、整库分析或重新构建代替定位"。

四、支撑体系：这份快照背后的证据驱动开发机制

ACCEPTANCE_STATUS_3_2_0.md之所以能保持简洁，是因为它依赖一整套可执行的支撑机制。理解这些机制，才能真正读透快照里的每一行。

4.1 验收入口的六个执行批次

完整验收入口 定义了六个执行批次：

1. Issue 与源码审查：使用 AGENT_WORKFLOW.md 的 Rapid Issue lane，只在 中央台账 维护分类、证据和再开条件；already-fixed直接停止。
2. UI、操作与数据：按页面族批量审查（首页、设置与数据、交互共同合同、UI 修订只更新受影响的测试目录）。
3. 播放、弹幕与平台：对每个已注册平台统一检查目录/搜索、房间身份、画质、线路、请求头与 Cookie、播放、弹幕、多画面、全屏/PiP/后台和退出清理。
4. 录制：手动/自动开始、轮询、暂停/停止、短录/长录、HLS/FLV、续签与断流恢复、代理、后台、存储不足、缓存回收、合并、最终大小/时长、严格解码和进程/文件清理——"状态机源码通过不等于媒体文件完整；最终文件必须由ffprobe/严格解码和字节账本验证"。
5. Android 原生批次：仅在网络 ADB 当前可见且需要原生证据时开始；先核对型号/代号/系统；只覆盖安装当前候选；保留"不重启手机/adbd、不切 Wi-Fi、不撤销授权、不改 ADB 端口"的设备边界。
6. Windows 原生批次：先生成一次当前 x64 Release/便携候选，再复用同一实例完成 W0～W4（安装/启动、全部页面、100%/150%/200% DPI、主副屏、播放/弹幕、全屏/PiP/多窗口、录制、资源与退出回落）。

4.2 62 个编号行如何对齐与验证

编号账本不是手工维护的文本，仓库提供了自动化对齐校验：tool/tests/test_acceptance_status_alignment.py（可经python -m unittest discover -s tool/tests -p test_acceptance_status_alignment.py运行），它会校验：

• 62 个唯一 A/W 编号行的完整性；
• 当前 PASS/RUN/NR 总数；
• 已注册站点数与平台扩展头的对齐。

这意味着快照表格的每一次数字变更都必须与矩阵账本、平台注册表保持机械一致，防止"文档漂移"。

4.3 质量门禁：Focused 与 Full 两档

验收快照反复提到的"Full 门禁""Analyze""定向回归"，其实际执行入口是 tool/local_ci.ps1：

• -Scope Focused -TestPath <paths> [-Analyze]：受影响代码验证，同时格式化改动的 Dart 文件；
• -Scope Full：正式交付质量门禁，必然解析锁定依赖图并运行全仓 Analyze、完整测试与接口核验。

验收入口还明确了文档/流程门禁（链接、语法、git diff --check）、行为修订门禁（受影响测试 + 一次 Analyze）、候选批次门禁（Full 后按 BUILD_POLICY.md 串行构建单一平台）。Android 侧核对包名、版本、签名、ABI、16 KB、资源、哈希、覆盖安装和数据保留；Windows 侧核对 Release EXE、便携 ZIP、安装器、运行库、独立目录启动、哈希和卸载/退出清理。"失败、取消或来源 SHA 不一致会阻断后续平台和发布；旧包证据只保留其历史边界。"

4.4 平台范围的演进依据

快照中"34 个适配器"的来龙去脉由 平台兼容性 文档支撑：3.2.8 起下线 11 个难维护平台（花椒、OPENREC、TTingLive、PopkonTV、GoodGame、VK Video Live、Dailymotion、Rumble、NimoTV、Shopee Live、淘宝直播，依据为 2026-09-26 全平台探针、近两个月维护记录与真机实测），3.2.11 下线 Kick（Cloudflare 按 TLS 指纹拦截，仅 Android 系统 TLS 与 Windows WinHTTP 两条原生通道可用）。这一决策模式体现了"没有稳定数据源的能力保持明确缺口，不以缓存或其他会话数据伪装实现"的诚实原则。

五、发布门禁：六项条件全部满足才进入发布

快照第六项阻塞指向"发布链未开始"，而 完整验收入口 给出了 3.2.0 发布门禁的完整定义：

1. 当前编号矩阵没有未处置的 P0/P1FAIL；外部条件缺失有明确范围和证据。
2. 当前提交的完整质量门禁通过，工作树干净，本地与origin/masterSHA 一致。
3. Android 与 Windows 当前候选完成各自原生矩阵；发布范围内其他平台从同一提交串行构建并核验。
4. 所有安装包/压缩包/安装器绑定版本、提交、签名、SHA-256 和构建记录。
5. README、更新日志、已知限制、回滚说明与实际产物一致。
6. 发布后重新下载资产，独立核对哈希、内容和启动，再更新发布索引。

这与 BUILD_POLICY.md 的"修复列车收敛点"模型（每项修复独立提交同步源码、但一次 Analyze/Full/版本递增/原生构建只在收敛点统一执行）互相印证，保证不会为小改动重复支付全仓门禁和打包成本。

结语：如何持续跟踪 3.2.0 收口

若要跟踪 3.2.0 后续进度，正确的阅读顺序是：

1. 先读 验收状态 获取当前数字与阻塞（本文主题）；
2. 数字变动需交叉核对 验收矩阵 的 62 个编号行与tool/tests/test_acceptance_status_alignment.py的自动校验；
3. 具体批次证据回溯 完整验收入口 与对应专项审计文档；
4. 历史阶段记录只读 状态时间线归档，不再视为当前状态。

这套"当前页 + 归档 + 矩阵 + 入口 + 自动化校验"的组合，让一份看似简单的状态表格具备了可审计、可追溯、可复现的工程属性——这正是大型开源客户端在"多平台、多适配器、多验收维度"下管理发布质量的关键实践。

• 音视频
• 直播
• 移动开发