Skyward 研发团队 2026S2 研发复盘

编制日期：2026-07-07 覆盖周期：2026年4月 - 6月 编制部门：Skyward 万成平台 - 产研组 数据来源：飞书多维表格（SKYward 项目规划清单 2026）、飞书 Wiki 项目文档（35 份）、team-claude-marketplace 仓库 git 记录 对标基线：S2 多维表格计划清单（34 项）+ 2026Q1 复盘之 Q2 行动计划（8 项）

---

第一部分：总览

1.1 执行摘要

2026 S2，Skyward 产研组 合计执行约 47 个项目（计划内 34 个，其中 3 个未启动；计划外约 13 个）。以下是本季度六项核心结论：

1. 季度规划可预测性显著改善。计划外项目占比从 Q1 的 50% 降至约 28%（13/47），达成 Q1 复盘设定的 "<30%" 目标。新站与画质增强类需求基本纳入了季度初预判。

2. "基建先行"策略实质落地，但普遍超期且缺正式结项。CMake 构建体系实现 Windows/macOS 四平台贯通 + CI 打包链路真跑（Windows MVP 验证 + macOS 全流程），arm64 移植全流程完成并发布论坛 Beta 包，CEF148 升级（含 CDM 3050、cpp17→cpp20）主体完成，打包发布流程自动化持续推进。但 CMake 超 S2 计划约 1 个月，打包优化超期约 1 个月仍进行中，基建项目无一正式结项。

3. CoApp 插件进入流水线化阶段。S2 交付 OnlyFans、Fanza、MyFans、TVer、Hulu、Fandango 6 个新 CoApp，收尾 UNEXT、M3U8 两个 Q1 延续项；"七角色" StreamDownloader 架构 + Skill 工厂使标准站点可在 1-2 周内完成迁移。但复杂多区域站点估算仍大幅失准：Hulu（JP/US 双区 + 4K）计划 1.5 周、实际 6 周以上才完成；Fandango 延后完成。

4. 画质增强战线全线告捷。Peacock UHD（4KSDR/HDR10/DolbyVision）随 StreamFab 7024 发布，SkyShowTime UHD V3 端到端两天打通，HuluJP 4K（DV/HDR10+）、NOW FHD 、WOW FHD 均完成交付，短周期项目按期率高。

5. AI 提效体系跨代升级。team-claude-marketplace 从 9 插件/15 Skills 增长到 25 插件/42 Skills（S2 新增 110 次提交）；自动化错误分析流水线（ELK 按服务/错误码拉取日志 → 自动建 worktree → AI 根因分析 → 人工 review）已在多个服务投入使用；appDriver 自动化采集累计交付 33 个流媒体服务。AI 应用从"辅助编码"演进为"工程流水线"。

6. 管理改进喜忧参半。Q1 定下的行动计划中：计划外占比达标（达成），基建落地与 CI 闭环取得实质进展（部分达成），但复杂站点估算校准、测试覆盖率与 Skill 维护机制（未建立度量）等 3 项未达成或无法核验。详见 3.1 节逐项核对。

---

1.2 目标达成分析

1.2.1 计划项目达成情况

以飞书多维表格 2026S2 计划清单为基线（34 项），按维度汇总：

CoApp 浏览器插件（计划 9 个）

新站下载与画质增强（计划 8 个）

基础设施（计划 7 个）

MusicFab（计划 3 个）

工程效率与调研（计划 4 个）

长期项目（3 个，贯穿 S2）

1.2.2 Q1 遗留项目收尾

Q1 复盘附录 C 列出的跨季度延续项目，均已在 S2 初完成收尾（未在 S2 多维表格中单独立项，据确认补记）：

1.2.3 计划外项目分析

S2 实际执行中约有 13 个计划外项目（有 Wiki 项目文档、但多维表格无对应条目），占总执行量约 28%：

解读：

• 计划外占比 28%，相比 Q1 的 50% 明显改善，达成 Q1 行动计划"计划外项目占比 <30%"的目标。
• 计划外项目的构成也在变化：Q1 以被动响应（欧洲站点批量接入、攻关）为主；S2 计划外项目中约一半是主动发起的基建/自动化补强（arm64、自动化测试、ytdlp 架构简化），说明产能缓冲被用于偿还技术债而非救火。
• 遗留问题：这批项目未回填到多维表格，导致管理视图不完整（详见 3.1 第 6 项）。

---

1.3 关键成果与里程碑

4 月

• Fanza CoApp 交付集成包（拦截改主动获取 + 分析下载解耦），正式结项
• AppleTV iTunes 购买视频下载：4 天完成核心开发（bmad 可行性分析 + CEF 请求组件化）
• Fansly 下载器提测（MPD/MP4 双路径 + 付费视频适配）
• UNEXT CoApp 解耦收尾；M3U8 CoApp 收尾
• MyFans CoApp 启动即完成架构 Skill 抽离与"七角色"配置——CoApp Skill 工厂起点
• Peacock UHD：4KSDR/HDR10/DolbyVision 解密新流程跑通
• 日志重构：streamfab 集成 libotel，hyperdx 平台可查日志；add-logs Skill 形成并迭代
• appDriver：netflix downloader 自动采集落地，解决 CEF 管理员模式崩溃
• 打包发布流程优化启动：新增 2 台自动化升级机器 + Jenkins 升级逻辑优化
• StreamFab 新 UI：3 种技术方案对比完成，CEF+Web demo 产出
• CMake：Conan Recipe 标准化规范 + 运行时资源外置规范制定

5 月

• Peacock UHD 随 win StreamFab 7024 发布
• SkyShowTime UHD：V3 端到端两天打通（HMAC-SHA1 本地签名 + Android CDM L1 + 12-capability 多色彩空间），多 master 聚合 + multi-license retry
• NOW/WOW FHD 完成开发与测试修复；WOW 项目同步沉淀站点迁移 Skill
• Hulu CoApp：JP meta 调用链主动请求化重构 + US 从零搭建 7-role StreamDownloader
• TVer CoApp 交付并正式结项（基本按期）
• MyFans CoApp 出包、OnlyFans CoApp 发布
• CMake：StreamFab macOS 构建完成（4 种 preset 含 arm64）；Windows 全流程 MVP 验证通过（bump→build→package，VMProtect 4 二进制/signtool 47 文件）；沉淀 ci-windows-package Skill
• appDriver：单季峰值周交付 12 个服务的自动采集适配
• musicfab 界面改版：UI Revamp v2 一日立项 → DAG 拆条 → 11 提交落码；AI 样式生成探索（实测效果不佳，结论沉淀）
• 打包优化：Jenkins 批量升级逻辑 + StreamFab 产品配置 ini 化提测（AI 多轮筛选排查配置遗漏）
• MusicFab ytdlp 去 service 进程完成（直调 ytdlp.exe）

6 月

• Coursera Downloader 发布：Skill 脚手架生成 + API 链分析 + full-HLS + 多语言音轨，基本按期
• U-NEXT Codeshop 演唱会下载：3 天跑通（cbcs Widevine + 基类 CDecryptor），按期提测
• ReelShort 下载支持：ytdlp 分析下载 + Playlist，按期
• HuluJP 4K（DV/HDR10+）：AndroidTV 链路 + 4K 失败分类 + H265 动态范围统一分类，正式结项
• CEF148 升级：Windows x64/x86 + macOS x64/arm64 编译集成，CDM 3050，cpp17→cpp20，沉淀 8 个 CEF Skill
• arm64 移植：流水线构建 + 加壳 + 公证打通，发布论坛 Beta 包；三态运行检测；独立站与缓存服务器 arm64 支持（7 月初收尾）
• CMake：macOS 出包三大真跑问题根治（VMProtect 加壳 noinline、codesign 验证替代 spctl、POST_BUILD 幂等拷贝）
• 自动化测试流程拓展：netflix/amazon/disney 三站点测试通过，支持参数模糊匹配与 fallback 原因显示
• MusicFab Podcast 服务端：测试域部署 + 全量数据导入 + 客户端按集成文档完成集成
• StreamFab 产品线统一代码分支完成
• S3 项目提前启动：MusicFab 录制方案调研、多服务并行下载小步重构

---

第二部分：深度分析

2.1 项目维度复盘

2.1.1 StreamFab CoApp 插件（9 个计划项 + Q1 收尾）

总体评价：S2 是 CoApp 从"探索期"进入"流水线期"的季度。Q1 沉淀的 StreamDownloader 架构与接口文档标准，在 S2 演化为可复制的"七角色"配置 + Skill 工厂模式，标准站点的迁移周期压缩到 1-2 周。但复杂站点的估算和执行仍是显著短板。

项目回顾

S2 CoApp 战线涉及：Fanza、TVer、UNEXT（Q1 延续）、OnlyFans、MyFans、Hulu、Fandango、M3U8（Q1 收尾）8 项交付，另有 MPD 未启动。各项目达成情况见 1.2.1。

亮点

• "七角色"标准架构 + Skill 工厂：MyFans 项目将 CoApp 迁移过程抽离为架构 Skill，形成"七角色"配置模式；后续站点（TVer 等）直接复用，TVer 从迁移到交付仅 2 周内完成并正式结项。CoApp 迁移从"手工重构"变为"按 Skill 走流程"。
• 模式高度同构：Fanza/TVer/UNEXT/Fandango 的执行路径完全一致（类结构改造 → 拦截改主动获取 → CoApp 消息适配 → 分析下载解耦），方法论已可复制，为后续站点批量接入奠定基础。
• 协议能力扩展：Hulu 项目落地重定向协议（OnResourceRedirect + redirect_data 链路）与 show_message_box 弹窗下推协议，丰富了 CoApp 通用协议栈。

问题

• 复杂站点估算失准依旧：Hulu 这类多区域 + 高画质（JP/US 双区、DV/HDR10+）的复合项目，实际工期显著超出立项估算。Q1 建立的估算基线未覆盖"多区域、多协议、高画质"复合复杂度。
• 收尾记录滞后于实际：Hulu、Fandango 实际均已完成，但项目文档停留在完成前的状态；OnlyFans 遗留"下载次数减少逻辑待查明"无闭环记录；UNEXT"等待集成"后无下文。项目进入尾声后的记录质量普遍下降，复盘状态需逐一向负责人核实。

2.1.2 StreamFab 新站下载与画质增强（12 个）

总体评价：本季度效率最高、确定性最强的战线。短平快项目（3 天-2 周）按期率高，UHD/FHD 画质增强全线交付，团队在 DRM 解密链路上的技术纵深进一步加强。

项目回顾

亮点

• SkyShowTime V3 两天端到端打通是本季度效率标杆：HMAC-SHA1 本地签名、Token 拉取、VOD/License 本地签、Android CDM L1 切换、UHD 12-capability 多色彩空间一次贯通。
• 架构收敛与复用：U-NEXT Codeshop 删除自包含 FabCDM 解密器改走基类 CDecryptor；NOW/WOW 抽离 Utils 并沉淀迁移 Skill（nowtv-migration-example），同类站点可直接套用。
• 画质能力升级：HDR10+/DolbyVision 解密与 H265 动态范围统一分类（classifyH265DynamicRange）沉淀为通用能力。

问题

• U-NEXT Codeshop 前后端共 5 笔提交仅在 add_unext_new 分支，尚未合入 dev_vs2019 主干，存在遗失风险。
• NOW/WOW 两项目已发布，但文档均无结项记录（发布状态经确认补记），属收尾记录缺口。

2.1.3 基础设施（7 个计划项 + 计划外 3 个）

总体评价：S2 是基建投入兑现的季度——Q1 复盘确立的"基建先行、质量筑底"策略在 S2 得到执行，构建体系、CEF 升级、打包自动化、日志可观测四条线同时推进并全部取得实质进展。代价是普遍超期约 1 个月、无一正式结项，且两个计划项（CoApp CMake 合并、macOS CDM Hook）未实质启动。

CMake 构建体系（Q1 延续，S2 收尾）

Q1 完成 Windows x64/x86 迁移后，S2 完成了从"能编译"到"能出包发布"的关键跨越：

• [已完成] macOS 构建落地：4 种 CMake preset（arm64/x64 × release/relwithdebinfo），05-05 周完成
• [已完成] Windows CI 全流程 MVP：bump→build→package 贯通（VMProtect 加壳 4 二进制、signtool 签名 47 文件），05-18 周验证通过
• [已完成] macOS CI 全流程真跑 + 三大问题根治（06-01 周）：
  1. 加壳失败——clang 内联导致 VMProtect 地址冲突，改 noinline
  2. 签名判定死锁——spctl 验 Gatekeeper 要求已公证，改 codesign --verify
  3. 公证 Invalid——CMake POST_BUILD file(COPY) 只增不删致增量残留，改"拷前先清"幂等
• [进行中] 多品牌流程测试与 Windows 回归测试（06-08 周）

对照 S2 计划（4/1 ~ 5/10），实际延续至 6 月上旬仍在收尾，超期约 1 个月。该项目自 2025 年 12 月启动，横跨两个季度，是团队最大的单项基建投入。

CEF148 版本升级（含 CDM 3050）

• Windows x64/x86 编译 + StreamFab 集成测试完成；macOS x64/arm64 编译集成完成；cpp17→cpp20 升级
• 沉淀 8 个 CEF 编译/部署 Skill（cef-builder、cef-pipeline、fetch-cef、cef-upgrade、build-cef、cef-deploy、deploy-cef、adapt-qcef）——CEF 升级这一"高频高危"操作首次实现知识资产化
• 遗留：libcefcomm/libcefbase/MusicFab 集成未开始；打包机 MacPro6.1 需升级系统和 Xcode；计划 6/8-6/17，实际超期约 1 周仍进行中

StreamFab arm64 移植（计划外，6 月集中攻坚）

• 排期 7 项里程碑全部完成：arm64 流水线构建 + 加壳 + 公证、论坛 Beta 包发布、macOS 三态运行检测（m1 原生/m1 翻译/intel）、升级接口 OS 参数、独立站全流程、缓存服务器 arm64 支持
• 攻坚记录：VMProtect 加壳导致运行时 crash（single-exit 问题），一周内定位修复并出报告
• Q1 复盘遗留的"arm64 构建"目标就此关闭

打包发布流程优化（P0）

• 已落地：2 台自动化升级机器 + Jenkins 批量升级、build-free pipeline（预编译 updateClient.pyd）、StreamFab 产品配置 ini 化提测、单元测试
• 遗留风险（文档明确记载）：分发服务器频繁失败[高，最大系统性瓶颈]、打包机资源冲突[高，延长发布约 1 天]、自动化升级测试机器不足[中]、增量升级曾回退
• 计划 4/13 ~ 5/31，6 月底仍在梳理各产品发布流程并整理 Skill，超期约 1 个月

日志重构集成可观测平台

• 已落地：streamfab 集成 libotel，日志上传 hyperdx 可观测平台可查（注：Q1 规划写的是 ELK 方案，实际选型为 hyperdx，属方案调整）；FABDIAG 失败调用栈（含 file:line 栈帧与变量 dump）在开发分支落地；add-logs 日志 Skill 形成并经 braceless-if 插入 bug 迭代
• 未闭环：分析流程/下载流程 span 整理进行中；05-11 周后无进展记录
• 计划止于 4 月底，实际超期 2 周以上未闭环

其余

• 统一代码分支：完成，Windows/macOS 主站/多品牌等代码分支完全统一（无过程文档）
• QTDownloader 性能优化：6 月底刚启动（延长 QNAM 生命周期复用连接池），正文无实质进展
• macOS CDM Hook：文档为空模板，未实质启动（计划 6/1-8/31，顺延 S3）
• CoApp 与 StreamFab CMakeBuild 环境合并：未启动（Q1 复盘规划的"CoApp 工程统一"阶段目标顺延）

2.1.4 自动化与质量工程（4 个）

总体评价：S2 新开辟的战线，也是本季度 AI 应用最具"体系化"特征的领域。三个方向（采集自动化、测试自动化、错误分析自动化）同时起步，均已产出可用能力，但均未完结。

appDriver 自动化采集

• 从 netflix 单点（计划 5 天）扩展为全站点覆盖工程，累计交付 33 个流媒体服务的自动采集适配 + youtube single/playlist 模式
• 交付节奏：5 服务（05-18 周）→ 12 服务（05-25 周）→ 8 服务（06-01 周）→ 8 服务（06-08 周），单周峰值 12 个
• 关键改造：点位逻辑灵活化，使"剩余几十个网站大多数可以复用适配"——采集适配从逐站开发变为配置化复用
• 遗留：Youtube movie downloader 因 streamfab 功能问题搁置；问题服务回归处理未见完成记录
• 工期口径说明：计划 5 天仅对应目标一（netflix），实际 8-9 周包含范围扩展（目标二"市场后期更新的其他流媒体服务"未单独排期），属范围膨胀而非单纯延期，但暴露了未对扩展范围重新立项排期的管理问题

自动化测试流程拓展

• netflix/amazon/disney 三站点测试通过；支持下载参数自由配置与模糊匹配、下载结果与预期参数对比、fallback 原因显示
• 产出测试用例模板（autotest-config-reference.md），"后续可根据模板生成自动测试用例"

自动化测试系统优化

• 梳理完成自动化系统完整流程文档；toolset v142/vs2019 编译迁移完成
• 逐项修复阻碍自动化的问题：日志 2MB 循环（放大至 8M）、VPN 自动切换内置、取消每 case 卸载/安装（改首次版本检测）、空间自动清理、watchdog 日志补全
• 未完成：Jenkins 页面动态生成 FabDebugConfig.ini、StreamFab 模态弹窗阻塞自动化（计划至 7/31，S3 继续）

自动化错误分析（P0）

• 已建成流水线：从 ELK 按服务/错误码拉取下载失败日志 → 自动创建代码 worktree → AI 根因分析（RCA）→ 分析结果接人工 review
• 已在多个服务的错误分析中实际应用
• 该项目将 AI 应用从"开发环节"延伸到"运维诊断环节"，与日志可观测平台（FABDIAG 调用栈）形成"日志上报 → 错误聚合 → AI 根因分析"的诊断链路雏形
• 状态：进行中；配套 Skill（kibana-es-query 等）已沉淀入 marketplace

2.1.5 MusicFab（5 个 + 架构演进 2 个）

MusicFab 方向从 Q1 的"纯预研"进入"产品化"阶段：播客有了服务端和客户端集成，录制有了产品化排期（S3 北极星：DRM 失效时的严格串行 fallback 录制），界面改版实际动工。遗留风险：Podcast 数据库导入过慢、正式域与鉴权未完成。

2.1.6 长期项目（3 个）

注：三个长期项目 S2 未单独记档（表格文档索引仍指向 S1 文档），过程细节不可追溯，属文档管理缺口。

2.1.7 UI 方向（2 个）

• StreamFab 新 UI 方案调研：完成 3 种技术方案对比（ui-stack-comparison-requirements），基于 CEF + Web（Html/JS/CSS）完成 demo 与架构图。04 月末后无周记更新，分析界面/下载界面两大目标未开始。方向已明确（CEF+Web），但投入被其他 P0 项目挤压。
• musicfab 界面改版：见 2.1.5。值得注意的是其工程方法：弃自建 .qss 预处理器、复用 fabcommon 现成机制的"机制选型反转"，以及"旧值基线 → 等价替换 → 切新值"三阶段安全迁移——体现了低风险重构的成熟打法。

---

2.2 技术维度

2.2.1 技术架构演进

CoApp"七角色"标准架构定型。Q1 完成 ResponseFilter → StreamDownloader 的方向性转变；S2 通过 MyFans/Fanza/TVer 等项目将其固化为"七角色"标准配置，并封装为 Skill（sd-pipeline 系列 + refactor-to-streamdownloader 扩充），架构迁移从"专家手艺"变为"流程作业"。

构建与发布体系现代化收官在即。CMake + Conan 四平台（Win x64/x86、macOS x64/arm64）贯通，CI 打包链路真跑（含加壳、签名、公证全流程）；arm64 产品线打通；CEF148 + cpp20 升级。StreamFab 的工程底座完成代际更替，旧 .sln 体系退役进入倒计时。

进程架构简化。MusicFab ytdlp 去除 service 进程改直调 ytdlp.exe（StreamFab 同项进行中），减少进程间通信层级；U-NEXT Codeshop 删除自包含 FabCDM 解密器统一走基类 CDecryptor——两者共同指向"减少特例、收敛路径"的架构治理方向。

可观测性从日志走向调用栈。libotel + hyperdx 平台接入，FABDIAG 失败调用栈（file:line 栈帧 + 变量 dump）落地，为自动化错误分析流水线提供了数据底座。

2.2.2 技术债务变化

新增/存续技术债

减少的技术债

• ytdlp service 进程移除（MusicFab 已完成）——进程模型简化
• FabCDM 自包含解密器删除，解密统一走基类 CDecryptor
• StreamFab 产品线统一代码分支——分支分叉维护负担消除
• cpp17→cpp20、CEF148——运行时与工具链现代化
• arm64 支持落地——平台覆盖债务关闭（Q1 遗留目标）

---

2.3 AI 应用与创新提效（专题）

S2 是团队 AI 工程化的分水岭：Q1 建立了资产载体（marketplace），S2 则让 AI 深入到研发流程的四个层面——资产沉淀、流水线工厂、运维诊断、探索试错。

2.3.1 AI 资产规模：marketplace 高速增长

S2 新增资产按用途分类（数据来源：marketplace git log 2026-04-01 ~ 2026-06-30）：

2.3.2 自动化错误分析：AI 进入运维诊断闭环

S2 立项的 P0 基础项目，已建成如下流水线并在多个服务的错误分析中实际应用：

ELK（按服务 + 错误码检索下载失败日志）
  → 自动拉取/解压日志，自动创建对应代码仓库 worktree
  → AI 结合源码 + 真实日志做根因分析（RCA）
  → 分析结果输出，接人工 review 确认

意义：此前用户反馈的下载错误依赖开发者手工查日志、翻代码定位，跨服务经验难以复用；现在"拉日志 + 建环境 + 初步根因"三步被自动化，开发者角色从"侦探"变为"审核者"。这是团队第一个把 AI 嵌入运维诊断主流程的项目，与 FABDIAG 调用栈日志（2.2.1）互为上下游。当前分析结果仍需人工 review，全自动闭环（如告警联动、结论直接派单）是后续方向。

2.3.3 项目内 AI 辅助实践（Wiki 文档记载摘录）

2.3.4 失败探索的诚实记录

musicfab 界面改版项目尝试"AI 样式生成"：以产品提供的网页与提示词为输入，让 AI 分析"项目 + 网页 + 提示词"产出 Qt 可用样式约束再改 UI——实测效果不佳，结论是约束需进一步细化后再交 AI 修改。该探索连同结论一并记入项目文档。

把不奏效的 AI 用法与奏效的一起沉淀，避免团队在同一处重复试错，这本身是 AI 工程化成熟度的标志。

2.3.5 采集自动化：appDriver 33 服务

见 2.1.4。补充效率视角：三周连续目标"预计自测支持 10 个左右网站"，实际每周交付 5-12 个，配合点位逻辑复用改造，采集适配的边际成本持续下降。该能力已交付中台使用。

2.3.6 小结与判断

• AI 应用的记载率：35 份项目文档中约 11 份有明确 AI 实践记载。头部项目（基建、CoApp、新站）AI 已是默认工作方式；但仍有约 2/3 文档未记载 AI 应用（未用或用了未记，无法区分），AI 实践的显性化记录有待加强。
• 从 Q1 到 S2 的质变：Q1 是"项目中用 AI + 建仓库"；S2 是"Skill 工厂支撑交付流水线（CoApp/新站）+ AI 进入运维诊断（RCA）+ 失败探索留档"。AI 提效从个体效率工具升级为团队工程体系。

---

2.4 效能维度

2.4.1 交付效率分析

按项目类型看 S2 的交付节奏（口径：以 Wiki 文档记载的计划与实际里程碑定性评估）：

• 新站/画质增强延续 Q1 优势，绝大多数项目按期或轻微延期，依然是团队的效率基石。
• CoApp 插件呈两极分化：套用 Skill 工厂的标准站点已可按期交付（TVer、M3U8），但复合复杂度站点（Hulu）延期显著，Q1 的估算收敛趋势在复杂站点上没有延续。估算模型需要引入"区域数 × 协议数 × 画质等级"的复杂度因子。
• 基础设施整体仍超期，但与 Q1 的"被挤压停滞"有本质区别：S2 是"超期但持续推进"，四条基建线全部产出实质成果。
• 自动化/质量暴露新问题：范围膨胀不重新立项（appDriver 从单站点验证扩展为全站点覆盖，仍挂在原始小计划下），使工期数据失去管理意义。

2.4.2 计划外工作影响

• 计划外占比 28%（Q1 为 50%），达成 <30% 目标。
• 结构变化：Q1 计划外以被动救火为主；S2 计划外一半以上是主动基建补强（arm64、自动化测试、ytdlp 架构简化），说明缓冲产能的使用质量在提升。
• 负面影响仍存：计划外项目未回填表格，且部分挤占了计划项（新 UI 调研 4 月末停滞、QTDownloader 6 月底才启动，均与 P0 计划外攻坚期重叠）；云上录制调研则因需求未明确主动顺延 S3，属正常决策而非挤压。

---

2.5 团队维度

2.5.1 能力建设

• DRM/画质纵深：HDR10+/DolbyVision 解密、Android CDM L1、cbcs Widevine 等能力在多个站点交付中固化，形成 UHD 支持的标准打法。
• 工程效率能力从个体到平台：CI/CD（CMake + Jenkins 真跑）、自动化测试（三站点冒烟 + 用例模板）、自动化采集（appDriver 33 服务）、自动化错误分析（RCA 流水线）——四个"自动化"在同一季度成型，团队的工程效率栈初具规模。
• AI 工程化能力：Skill 工厂化（架构迁移、新站接入、CEF 升级、发布流程均有对应 Skill 链）；AI 探索的成败经验均有留档。

2.5.2 协作与文档纪律

• CoApp 接口文档标准延续并升级（Fanza 产出接口文档仓库规范 coapp-interface-repo-spec）。
• 但文档纪律整体仍是短板：正式填写结项说明的项目仍是少数；多份文档周记中途断更（Fandango、新 UI、可观测平台——其中 Fandango 实际已完成但文档未反映）；个别文档接近空模板或缺进展记录。复盘数据的可得性完全依赖文档质量，这直接抬高了每季度复盘的核验成本。

---

第三部分：反思与行动

3.1 Q1 行动计划逐项核对

Q1 复盘定下 8 项行动计划，本节对其中 7 项逐项验收（另 1 项属团队内部管理事项，在团队内部另行跟进，不在本报告展开）；无数据支撑的项如实标注：

总评：验收的 7 项中 1 项达成、2 项部分达成、2 项未达成、2 项未建立度量。达成的项（规划覆盖度、基建落地）恰恰是"做事"层面的；未达成或未度量的项（结项、Skill 维护、状态同步）集中在"管理机制"层面——团队执行力对目标的兑现远好于管理动作对承诺的兑现，这是本次复盘最需要正视的结构性问题。

3.2 做得好的（Keep）

1. 基建攻坚的兑现力

Q1 说"基建先行"，S2 真金白银投入并拿到结果：构建体系四平台 + CI 真跑、arm64 全流程、CEF148、四条自动化线。特别是 CMake 项目在跨越 6 个月后逼近终点，三大真跑问题（加壳/签名/公证）的根治体现了深水区问题的攻坚能力。

2. Skill 工厂驱动的交付流水线

"项目实践 → Skill 沉淀 → 下一项目提速"的飞轮在 S2 高速转动：MyFans 抽离架构 Skill → TVer 按期交付；WOW 沉淀迁移 Skill；Coursera 用脚手架 Skill 按期发布；CEF148 把升级过程变成 8 个 Skill。marketplace 资产翻近三倍且伴随 110 次提交的活跃维护。

3. 新站/画质战线的稳定输出

10 个可核验项目 7 个按期或轻微延期，SkyShowTime V3 两天打通、U-NEXT Codeshop 3 天交付、AppleTV 4 天核心完成。短平快项目的工程确定性已成团队招牌。

4. AI 进入运维诊断闭环

自动化错误分析流水线（ELK → worktree → RCA → 人工 review）投入多服务使用，配合 FABDIAG 调用栈日志，错误诊断从"手艺活"走向"流水线 + 审核"。

5. 主动型产能缓冲使用

计划外占比降至 28% 达标，且计划外项目从 Q1 的被动救火转为主动补强（arm64、自动化测试、ytdlp 简化），缓冲产能的使用质量提升。

3.3 需改进的（Improve）

1. 管理机制承诺的兑现率（最高优先级）

• 问题：3.1 所示，行动计划中管理机制类（结项、Skill owner、状态同步）几乎全部未达成或未度量，且部分是连续两个季度的同类问题。
• 根因：行动项定了标准但没定"由谁在什么节奏检查"的执行机制；季度中无检查点，季度末才在复盘时对账。
• 建议：S3 只保留 3-4 项行动，每项明确 owner 和月度检查节奏（如月度例会固定 10 分钟过行动项）；宁可少而兑现，不要多而落空。

2. 结项与文档纪律

• 问题：正式结项比例仍处低位；周记断更、空模板、零记录文档并存；计划外项目不回填表格；已完成项目（Hulu、Fandango）文档停留在完成前状态。
• 影响：复盘核验成本高；经验（尤其失败经验）随项目结束流失；管理层无法从工具获得真实状态。
• 建议：把"结项文档 + 表格回填"做成发布流程的卡点（不结项不进发布队列），从"要求人自觉"改为"流程强制"；结项模板压缩到 10 分钟可填完。

3. 复杂项目的估算与拆分

• 问题：Hulu（双区域 + 4K）计划 1.5 周实际 6 周+；appDriver 范围从 1 站点膨胀到 33 服务不重新立项。
• 根因：估算基线只覆盖"标准站点"，缺复杂度因子；范围变化无变更管理动作。
• 建议：CoApp/站点类项目估算引入复杂度检查表（区域数、协议改造、画质等级、双端）；项目范围扩大超 50% 时强制重新立项拆分。

4. 基建栈单点依赖

• 问题：构建、CI、打包、服务端等基建专业栈集中于少数成员，Q1 已识别的单点依赖问题在基建攻坚季进一步凸显。
• 根因：攻坚期职责天然向熟手集中；交叉培训与知识移交无机制保障。
• 建议：构建/打包体系收尾后立即安排文档化移交与结对开发；S3 新基建项目采用双人制。

5. 测试体系的路线澄清与度量建立

• 问题：Q1 定的"单元测试覆盖率 50%"既未执行也未正式放弃，实际资源投向了 E2E 自动化测试（这一选择本身可能是对的——对下载类产品，端到端验证性价比更高），造成目标与实际两张皮。
• 建议：S3 正式修订测试策略：以 E2E 自动化为主线（明确站点覆盖数、用例数指标），单元测试聚焦可测的纯逻辑模块（如 Meta 解析），不再空挂覆盖率目标。

6. 收尾质量与合入纪律

• 问题：U-NEXT Codeshop 5 笔提交未合入主干；NOW/WOW 无明确结项；OnlyFans 遗留问题无闭环；多项目"最后一公里"记录失真。
• 建议：定义"完成"= 代码合入主干 + 结项文档 + 表格回填三件套；周会检查"已发布但未合入/未结项"清单。

3.4 S3 行动计划

吸取 3.1 教训，S3 只设 4 项，每项带 owner 与月度检查：

---

第四部分：S3 规划

4.1 延续收尾项目（S2 未完带入）

4.2 S3 新项目

[待补充]

4.3 团队能力建设方向

---

附录

附录 A：S2 计划项目清单（多维表格基线，34 项）

附录 B：S2 计划外项目清单（约 13 项）

附录 C：技术风险清单

附录 D：跨季度延续项目（S2 → S3）