核心平台稳定性与热修通道 北极星（North Star）¶
| 文档版本 | v1.0 / 2026-07-20 |
| 项目 DRI | 王双勇（产品）、李勇（技术） |
| 状态 | 生效中 |
| 上级对齐 | StreamFab 产品级北极星（09_north_star_v2.md，不在本仓库，需与产品侧确认最新版本） |
背景¶
VIP 平台（Netflix / Amazon / Disney+ / Hulu / YouTube）一旦改接口或改参数，StreamFab 的下载就会失败。用户点下载、等待、拿到失败提示——而他为这个功能付过钱。
今天修复这类故障只有一条路：改 C++ 代码 → 重新编译 → 走完整版本发布流程 → 用户升级。这条路以周计。 Windows 用户至少还能通过升级程序收到新版本；macOS 客户端甚至不会自己下载，只是弹窗把用户丢到浏览器下载页，让他自己下 dmg 重装。
这段等待期里用户不知道我们已经在修了，他看到的只是"这个软件不能用了"。于是退款，于是差评。VIP 平台故障直接吃掉收入与用户信任，而我们的响应速度被版本发布节奏锁死。
紧迫性来自三处：VIP 平台是 Tier 0，收入影响最直接；故障恢复周期是当前最大的技术债；北极星文档已明确 Tier 0 平台应获得最高 SLO 和资源优先级。
北极星¶
VIP 平台的站点故障不再需要用户等待版本发布——故障确认后，修复在次日之内静默送达全部在网用户；而这条通道自身从不制造新的故障。
前提是不付出以下代价：不牺牲安全性（每个热修包可验签、可灰度、可回滚）、不扩大适用范围（仅限 P0/P1 站点故障）、不让用户承担额外操作（无需重装、无需去官网）。
这是理想态。它回答的是"我们最终要做成什么样"，而不是"我们要做哪些功能"。
判断任何决策是否偏离北极星，问三个问题：它是否缩短了故障到恢复的时间？它是否让通道更不容易制造新故障？它是否让用户少做一件事？ 三个都不是的工作，就是偏离主线。
目标¶
目标一：建成独立于完整版本发布的热修下发通道。 通道与版本发布流程在权限、审批、节奏三个层面隔离；具备内容签名、灰度下发、快速回滚三项能力。交付时间：2026 年 8 月底（自 7 月 16 日起 6 周）。
目标二：完成至少 1 次真实 P0/P1 站点故障的端到端热修修复。 不是演练，是真实故障。从故障确认到全量恢复的完整链路跑通，且未引入新的 P0/P1 故障。
目标三：建立热修效果的可衡量机制。 崩溃率、下载成功率、QOS 能按"热修版本"维度聚合，且能对比命中与未命中人群——没有这个，回滚决策就只能靠感觉。
成功指标¶
核心价值指标
| 指标 | 现状 | 目标 |
|---|---|---|
| P0/P1 站点故障恢复时间 | 等完整版本，周级 | 故障确认后 D+1 全量 |
| VIP 平台下载成功率 | 待基线测量 | ≥95%，热修后快速恢复至正常水平 |
| 画质/音质规格兑现率 | 待基线测量 | ≥98% |
质量护栏（任一项失守即视为通道不合格）
| 指标 | 阈值 |
|---|---|
| 热修引入的 P0/P1 故障数 | 每季度 0 |
| 热修回滚率 | ≤10% |
| 热修下发的内容签名覆盖率 | 100%（无签名不下发） |
| 跳过 canary 直接放量的次数 | 0 |
通过/失败判定
- 通过：通道上线，完成至少 1 次真实 P0/P1 故障修复，未引入新问题。
- 失败：通道无法稳定下发、修复无效，或热修本身引入新的 P0/P1 故障。
边界¶
以下事项明确不做。每一条都有对应的决策记录，不因排期压力临时翻案。
| 不做什么 | 为什么 | 依据 |
|---|---|---|
| 站点适配规则外置化（把硬编码的 C++ 适配逻辑抽成可下发数据） | 四个 Tier 0 平台的适配逻辑硬编码且静态链接，外置化是大型重构，需独立立项 | ADR-0001 |
| 拆分 libstreameta 为动态库 | 同上，代码结构不支持，工作量巨大 | ADR-0001 |
| 原生动态库形式的代码补丁下发 | 双平台签名与加载复杂度高，且非故障修复的必要手段 | ADR-0001 |
| 覆盖历史版本的多基线热修 | 需维护多条热修分支，排期内做不好；旧版本用户走升级路径 | ADR-0002 |
| 主 exe 的二进制差分下发 | 加壳签名的二进制做差分会触发杀软误报，根因未解决前不碰 | ADR-0008 |
| 基于指标阈值的自动回滚 | 阈值难调、误触发风险高，业界无公开成熟规范；首版人工决策 | ADR-0004 |
| 热修管理后台 UI | 低频操作，人工改清单 + 流水线发布已够用 | ADR-0004 |
| 站点维护开关之外的其他配置开关 | 防止通道功能膨胀 | ADR-0006 |
| 用热修通道下发非紧急的功能更新 | 通道滥用会毁掉它的可靠性，这是通道存在的前提 | PRD 核心原则 |
| 现有下载链路的整体 TLS 安全加固 | 热修链路强制严格校验，但不在本项目范围内修历史问题 | 技术方案 §7 |
当前优先级¶
P0¶
P0-B1：热修通道技术调研与方案 — ✅ 已完成，待评审
产出：技术方案（含代码证据）、产品规格、业界调研、8 份决策记录、开放问题跟踪。 完成标准全部达成：可行性结论、客户端加载机制、通道隔离方案、签名与完整性校验方案、快速回滚机制均已明确。
P0-B2：热修通道建设与首次真实修复 — 进行中
阻塞项一件：下发服务的接口形态与缓存行为未确认（开放问题 Q1）。灰度参数最终落在该服务上，若其响应经小时级 CDN 缓存，则"分钟级截断扩散"的回滚设计不成立，需重新设计。该问题解决前，服务端与灰度相关工单无法定稿。
不依赖下发服务、可立即启动的三条线：
- 跨平台决策引擎（验签、版本校验、灰度分桶、回退判定）——其余各线的共同前置
- Windows 替换事务改造（备份、失败回滚、替换后复核、成败返回值）
- CI 流水线扩展（热修类型、Ed25519 签名阶段、双人审批、失败通知）
P1¶
- 找到下发服务归属人，确认 7 个接口问题（开放问题 Q1）
- PRD 表述修订：将"站点适配规则更新"对齐为实际形态"整 exe 替换"（开放问题 Q2）
- macOS 热修模块开发（协议与服务端共用，仅平台相关部分新建）
- 双平台主 exe 体积实测；macOS 替换粒度与公证细节验证（开放问题 Q3、Q4）
- Ed25519 密钥的生成、备份与轮换操作规程（开放问题 Q7）
时间窗¶
| 阶段 | 周期 | 状态 |
|---|---|---|
| 技术调研 | Week 1（2026-07-16 起） | ✅ 完成 |
| 技术方案 | Week 2 | ✅ 完成，待评审 |
| 开发实现 | Week 3–4 | 待启动 |
| 测试验证 | Week 5 | — |
| 上线运行 | Week 6+（约 2026-08 底） | — |
上线后转入长期运营：持续优化下发效率、沉淀热修案例库、定期演练热修与回滚流程。
配套管理约定¶
- 周报回溯：每项"本周完成"的工作都应能链接到本文档的 P0 或 P1。链接不上的，判断是隐式 P0（则更新本文档）还是偏离主线（标记
[UNALIGNED]）。 - 汇报逻辑：北极星是什么 → P0 是什么 → 上周 P0 达成情况 → 再展开细节。
- 变更管理：北极星保持稳定，不因单次挫折调整。确需演进时，在本文档记录变化内容、原因与影响，并同步相关方。
变更记录¶
| 版本 | 日期 | 变更 | 记录人 |
|---|---|---|---|
| v1.0 | 2026-07-20 | 初版。基于 PRD 与 P0-B1 技术调研结论建立；边界部分依据 ADR-0001~0008 明确化 | 李勇 |