10-跨端桥梁与研发节奏总图
10-跨端桥梁与研发节奏总图
Section titled “10-跨端桥梁与研发节奏总图”文档性质:跨端桥梁总图
用途:把当前几端为什么像孤岛、真正缺的桥梁层是什么、应该按什么研发节奏补齐,一次讲清楚
适用范围:产品 / Backend / Admin / iOS / Web / Design 的跨端协作与节奏对齐
边界说明:
- 这份文档不替代
./01-当前目标与范围.md,不重新定义阶段目标 - 这份文档不替代
./02-当前系统现实.md,当前现实仍以那份为准 - 这份文档不替代
./06-首页分发与合集字段要求.md,字段细节仍以那份为准 - 这份文档不替代
./08-前端实验分支交接与调试说明.md,iOS 分支接力细节仍看那份 - 这份文档也不替代执行计划;它回答的是“地图是什么、桥梁缺在哪、先补哪一段”
默认读者:产品 / 研发 / 设计
最后更新:2026-04-16
1. 这份文档解决什么问题
Section titled “1. 这份文档解决什么问题”当前几端的状态不是“完全没做”,而是:
- 文档已经把目标模型讲清楚了
- 服务端 / 数据库已经有正式入库和处理主链
- admin 已经有内容运营和资源接入基础
- iOS 已经做出了一套前台实验壳
- web 也已经有一套现行前台
但这些东西现在还不是同一套产品模型。
最直白地说,现在像是:
- 后端和 admin 像仓库与进货系统
- iOS 和 web 像前台门面
- 文档像蓝图
- 中间真正把几端接起来的“货架规则、分发位、合集关系、准入墙”还没有正式落地
这份文档就是专门回答三件事:
- 当前孤岛分别在哪里
- 真正缺失的桥梁层是什么
- 应该按什么顺序补,才能让几端最终汇到一条主链上
2. 当前孤岛图
Section titled “2. 当前孤岛图”flowchart LR A[01 / 06 / 07 文档目标模型] --> X[缺失的共享中间层] B[DB / Service 当前现实<br/>news + channels + scenes] --> X C[Admin 当前运营能力<br/>news / channels / scenes / youtube / podcast] --> X D[iOS Demo 当前模型<br/>fixture collection shell] --> X E[Web 当前模型<br/>featured / news / channel] --> X X --> F[统一契约<br/>Collection / CollectionItem / HomepageSlot / Eligibility]
这张图要表达的不是“谁做错了”,而是:
- 每一端都有自己已经成立的局部
- 但几端还没有通过同一套中间层连接起来
- 所以现在的问题不是继续堆页面,而是先把桥梁建出来
3. 真正缺失的桥梁层是什么
Section titled “3. 真正缺失的桥梁层是什么”当前真正缺的是下面这条链:
flowchart TD A[Content Item] --> B[Eligibility Rule] B --> C[CollectionItem] C --> D[Collection] D --> E[HomepageSlot]
每一层分别解决不同问题:
| 层 | 回答什么问题 | 当前状态 |
|---|---|---|
Content Item | 一条内容有没有进入正式内容主链 | 已有现实基础 |
Eligibility Rule | 这条内容能不能进分发层、能不能进首页层 | 文档已定义,后端未正式化 |
CollectionItem | 这条内容属于哪个合集、在合集里排第几、如何外露 | 文档已定义,未正式落库 |
Collection | 哪一个方向能成为稳定发现单元 | 文档和 iOS fixture 中存在,服务端未正式化 |
HomepageSlot | 首页模块怎么由运营配置、排序和控制,而不是写死在前端里 | 文档已定义,前后端都未正式化 |
这里最容易混掉的 3 个点是:
visibility不等于distribution_eligibilitychannel / scene不等于collection- 首页模块名不等于内容的长期属性
4. 目标桥梁总图
Section titled “4. 目标桥梁总图”flowchart TD A[外部内容源<br/>Web / YouTube / Podcast / RSS] --> B[入库与结构化] B --> C[ContentItem<br/>Phase 1 现实里主要还是 news] C --> D[Eligibility Rule<br/>visibility / distribution / homepage] D --> E[CollectionItem] E --> F[Collection] F --> G[HomepageSlot] H[Admin 运营配置] --> D H --> F H --> G G --> I[iOS 首页 / 列表 / 详情] G --> J[Web 首页 / 列表 / 详情] F --> K[Collection List / Collection Detail] C --> L[Content Detail] L --> M[下一步继续消费]
这张图对应的产品含义很简单:
- 内容先进入正式主链
- 不是所有入库内容都自动可分发
- 被判定可分发的内容,先进入合集关系层
- 合集再进入首页分发位
- 前台读取的是“被组织好的发现结构”,不是裸内容堆
5. 当前缺口热力表与责任归位
Section titled “5. 当前缺口热力表与责任归位”| 能力块 | Docs | DB / Service | Admin | iOS | Web | Metrics | 当前主责 |
|---|---|---|---|---|---|---|---|
Content Item | 已有 | 已有 | 已有 | 部分接入 | 已有旧读取 | 缺 | Backend |
Eligibility Rule | 已定义 | 缺正式能力 | 缺运营解释 | 无感知 | 无感知 | 缺 | Product + Backend |
Collection | 已定义 | 缺正式建模 | 缺 CRUD | 仅 fixture | 缺 | 缺 | Product + Backend + Admin |
CollectionItem | 已定义 | 缺正式落库 | 缺排序操作 | 仅 fixture | 缺 | 缺 | Backend + Admin |
HomepageSlot | 已定义 | 缺正式建模 | 缺运营配置 | 前端写死 | 前端写死 | 缺 | Product + Backend + Admin |
Content Detail Continuation | 已定义 | 仅部分可算 | 无 | 路由有、UI 无 | 缺 | 缺 | Backend + iOS |
跨端统一读模型 | 部分 | 缺 | 缺 | 缺 | 缺 | 无 | Backend |
这张表的作用不是分锅,而是让大家对一件事达成共识:
当前最大缺口不在页面细节,而在共享中间层。
6. 当前已知问题怎么并入地图
Section titled “6. 当前已知问题怎么并入地图”下面这些不是散落 bug,而是会直接影响桥梁是否能建起来的缺口:
| 问题 | 本质 | 应该并入哪一段 |
|---|---|---|
iOS 首页 tab 当前只 inline 刷新,不经过 Collection List | 页面层故事不一致 | Phase 0 先定故事,Phase 4 再落代码 |
| iOS 内容详情已算出 continuation,但没渲染出来 | “继续消费”只停在路由层 | Phase 2 定接口,Phase 4 补 UI |
| 首页模块仍写死在前端 | 没有 HomepageSlot 运营层 | Phase 1-3 |
web 仍在旧 featured / news / channel 语义里 | 前台模型分叉 | Phase 0 先定是否在本轮纳入,Phase 5 再处理 |
distribution_eligibility / homepage_eligibility 只在文档里 | 准入墙没正式进入系统 | Phase 0-2 |
scene 唯一性和 primary 治理不够硬 | 底层方向治理不稳定 | Phase 1 |
| iOS demo 没有正式埋点 | 无法验证“连续消费”是否成立 | Phase 4-6 |
| PR #352 描述仍是 docs-only | 文档口径和分支现实不一致 | 文档治理项,尽快修正但不阻塞主链设计 |
7. 研发节奏总图
Section titled “7. 研发节奏总图”flowchart LR P0[Phase 0<br/>冻结跨端契约] --> P1[Phase 1<br/>建中间层表与治理规则] P1 --> P2[Phase 2<br/>补 Service 读写与 continuation 接口] P2 --> P3[Phase 3<br/>补 Admin 运营配置层] P3 --> P4[Phase 4<br/>iOS 接真实数据并补 continuation / analytics] P4 --> P5[Phase 5<br/>Web 迁移或明确 legacy 边界] P5 --> P6[Phase 6<br/>指标 / QA / 上线门槛]
顺序不能乱的原因很简单:
- 先没有契约,后面每一端都会继续自造模型
- 先没有表和接口,admin 和前台都只能继续写死
- 先没有运营层,首页就永远不能算真正成立
- 先没有 continuation 和指标,就无法证明“能继续消费”
8. 当前 Phase 1 推进节奏
Section titled “8. 当前 Phase 1 推进节奏”这一节只服务当前轮次,不承担长期导航职责。
8.1 当前推荐推进顺序
Section titled “8.1 当前推荐推进顺序”- 冻结
ContentItem / Collection / CollectionItem / HomepageSlot / Eligibility统一定义 - 把
visibility / distribution_eligibility / homepage_eligibility的边界写硬 - 在服务端补
collections / collection_items / homepage_slots及其 read/write 能力 - 在 admin 补合集和首页分发位配置能力
- 让 iOS 从 fixture 语义切到真实后端契约
- 决定 web 是一起迁移还是明确标为 legacy
- 补 continuation、埋点、QA 和上线门槛
8.2 当前阶段的完成标准
Section titled “8.2 当前阶段的完成标准”当前这轮不是“所有内容系统都做完”,而是至少同时成立 5 件事:
- 内容能稳定进入系统
- 内容能被结构化
- 内容能被组织成合集
- 首页能通过分发位稳定组织出来
- 用户消费第一条后有明确下一步
9. 这份文档和其他文档怎么配合
Section titled “9. 这份文档和其他文档怎么配合”如果你要回答的是不同类型的问题,应该去不同文档:
- 看“这轮到底做什么、做到什么算成立”
去./01-当前目标与范围.md - 看“当前系统现实里正式已经有什么、没有什么”
去./02-当前系统现实.md - 看“首页和合集最少需要什么字段与承接对象”
去./06-首页分发与合集字段要求.md - 看“iOS 实验分支怎么接力”
去./08-前端实验分支交接与调试说明.md - 看“YouTube 自动扩源怎么接回入库主链”
去./09-YouTube主动发现、候选确认与入库衔接.md
而这份 10 只回答:
几端为什么现在还像孤岛、桥梁缺在哪里、应该按什么节奏把这座桥搭起来。