Yomiya Implementation Review Log
Yomiya Implementation Review Log
Section titled “Yomiya Implementation Review Log”文档性质：实施规格审查与修复记录
用途：保留 implementation spec 演进过程中发现的问题、漏洞、卡点与修复思路，避免历史痕迹继续污染主规格文档
状态：持续补充
最后更新：2026-03-28
1. 本文档的角色
Section titled “1. 本文档的角色”本文件不是当前执行规格，也不是未来阶段规划。
它只负责一件事：
把 Yomiya 内容系统实施规格在演进过程中发现过的问题、形成过的修复思路、以及曾经发生过的重要争议单独保存下来。
它的存在价值是：
- 给后续 review 提供上下文
- 避免团队反复踩相同的坑
- 保留“为什么后来这么改”的历史依据
但它不再承担“当前规则”定义职责。
当前有效规格，请优先阅读：
yomiya-phase1-execution-spec.mdyomiya-canonical-naming.mdyomiya-phase1-scope-boundary.mdyomiya-implementation-spec-core.md
2. 为什么需要单独的 review log
Section titled “2. 为什么需要单独的 review log”原始 yomiya-implementation-spec.md 在不断迭代过程中，逐渐混入了多类信息：
- 当前有效规则
- 漏洞清单
- 自查结论
- 修复补丁记录
- 产品运营层卡点排查
- 工程实现卡点排查
这些内容本身都很有价值，但当它们和主规格混在一起时，会产生一个严重问题：
读文档的人很难判断，自己看到的是“现在应该执行的规则”，还是“之前有人发现过的问题”。
因此，本文件承担“历史问题与修复痕迹容器”的角色。
3. 第一轮总体审查结论（抽象总结）
Section titled “3. 第一轮总体审查结论（抽象总结）”在对 Yomiya 的研究、策略、工程差距和实施规格进行通读后，得出的第一轮总体结论如下：
3.1 优点
Section titled “3.1 优点”- 产品方向是清楚的，已经明确“内容平台”而非“课程工具”方向
- 研究、策略、工程差距、实施规格四层之间大体一致
- 已经把内容容器（Channel / Collection / Series / Topic）的问题意识到位
- 工程文档不是幻想式重构，而是建立在现有系统调查基础上
3.2 主要问题
Section titled “3.2 主要问题”- 文档体系开始膨胀，规格、审查、修复、未来阶段混杂
- 实施规格逐步变成“主规格 + 讨论串 + bug backlog + 未来草案”的混合体
- Phase 1 容易被后续阶段需求不断侵入
- 自动化策略推进得很快，但质量与分发准入墙还未明确独立
3.3 核心判断
Section titled “3.3 核心判断”Yomiya 当前最大风险已经不是“想不清楚做什么”，而是：
想得太多、写得太多、但没有把当前阶段真正要做的部分明确收口。
4. 第一轮关键质疑与审查点（结构化保留）
Section titled “4. 第一轮关键质疑与审查点（结构化保留）”以下是第一轮 review 中形成的重点质疑，保留为历史依据。
4.1 关于研究文档的质疑
Section titled “4.1 关于研究文档的质疑”质疑 1：视频优先的证据链还不够硬
Section titled “质疑 1：视频优先的证据链还不够硬”虽然已有：
- 竞品首页比例
- 用户体验对比
- B站生态观察
但依然需要持续验证：
- 视频是不是所有内容形态中的真正最优
- 还是仅仅因为视频更适合作为首页入口
- 视频在完播率、收藏率、分享率上是否持续优于其他形态
质疑 2：对用户真实消费时段与消费场景分析还不够
Section titled “质疑 2：对用户真实消费时段与消费场景分析还不够”例如：
- 通勤听音频
- 夜间刷视频
- 白天看资讯
这些将直接影响首页模块、推送时间、内容长度策略。
4.2 关于 content strategy 的质疑
Section titled “4.2 关于 content strategy 的质疑”质疑 3：部分栏目责任仍偏重
Section titled “质疑 3：部分栏目责任仍偏重”例如：日本文化栏目容易持续吞掉：
- 社会观察
- 历史人文
- 饮食文化
- 城市生活
- 节日风俗
这会造成栏目边界再次变宽。
质疑 4：传播职责已经被提出，但还未真正成为分发系统的一部分
Section titled “质疑 4：传播职责已经被提出，但还未真正成为分发系统的一部分”文档已经提出：
- 可截图截面
- 可引用截面
- 可推荐截面
- 可分享截面
但这些仍主要停留在内容设计语言中，尚未系统化接入产品分发逻辑。
质疑 5：全自动内容处理引擎的野心大于当前品牌安全机制
Section titled “质疑 5：全自动内容处理引擎的野心大于当前品牌安全机制”文档提出默认自动发布、人工只处理例外，这有增长逻辑，但风险是：
- 低质量内容可能快速进入用户面前
- 打标错误会污染首页或合集
- “发布”和“分发”尚未明确分层
4.3 关于 engineering gap analysis 的质疑
Section titled “4.3 关于 engineering gap analysis 的质疑”质疑 6：虽然写出了 MVP，但整体上下文仍然容易诱导范围继续扩大
Section titled “质疑 6：虽然写出了 MVP，但整体上下文仍然容易诱导范围继续扩大”文档中除了 MVP，还同时讨论了大量后续能力，容易造成执行面重新膨胀。
质疑 7：iOS / Admin / Backend 的依赖关系图还不够硬
Section titled “质疑 7：iOS / Admin / Backend 的依赖关系图还不够硬”例如：
- 没有 Collection 时首页能做到什么程度
- 没有 progress 时合集详情怎么退化
- 没有 podcast 时首页模块如何处理
这些“缺一块还能怎么跑”的降级逻辑需要更明确。
质疑 8：需要一张命名冻结表来阻止术语继续漂移
Section titled “质疑 8：需要一张命名冻结表来阻止术语继续漂移”已经存在大量概念：
- channel
- collection
- topic
- series
- item
- featured
- scene
- tab
不冻结会导致后续接口命名和页面文案越来越乱。
4.4 关于 implementation spec 的质疑
Section titled “4.4 关于 implementation spec 的质疑”质疑 9：主规格过载
Section titled “质疑 9：主规格过载”原始 implementation spec 已同时承担：
- 主规格
- 自查报告
- 修复记录
- 深度排查
- 运营补充
- API 补丁
- 未来阶段说明
这已经超出单一规格文档的合理负载。
质疑 10：P0 / P1 / P2 虽有区分，但整体仍持续引诱扩大范围
Section titled “质疑 10：P0 / P1 / P2 虽有区分，但整体仍持续引诱扩大范围”文档里同时存在：
- 首页
- Collection
- Streak
- Push
- 分享
- 搜索
- 播放模式
- 回流体验
- 会员设计
这会不断诱导团队认为“既然都定义了，不如顺手做掉”。
质疑 11：自动化链路推进快于质检机制建设
Section titled “质疑 11：自动化链路推进快于质检机制建设”已经提出：
- 自动入库
- 自动打标
- 自动进合集
- 自动专题建议
- 自动降权 / 下架
但质量真相层仍偏弱：
- 抽检机制
- 标题质量保障
- 发现层污染后的回退
- 低质内容的批量纠正
5. 第一轮优化建议（已转化为收口文档）
Section titled “5. 第一轮优化建议（已转化为收口文档）”在第一轮 review 后，形成了几个高优先级优化动作，后来已经被正式落为独立文档。
5.1 优化动作 1：抽出 Phase 1 单页执行规格
Section titled “5.1 优化动作 1：抽出 Phase 1 单页执行规格”已产出：
yomiya-phase1-execution-spec.md
目的：
- 把当前阶段真正要做的事从大量上下文中抽出来
- 明确目标、指标、平台定位、核心合集优先级
5.2 优化动作 2：冻结名词
Section titled “5.2 优化动作 2：冻结名词”已产出：
yomiya-canonical-naming.md
目的：
- 一次性钉死 Channel / Collection / Series / Topic / Tag / Featured / Tab 等概念
- 阻止文档和工程命名继续漂移
5.3 优化动作 3：补范围边界清单
Section titled “5.3 优化动作 3：补范围边界清单”已产出：
yomiya-phase1-scope-boundary.md
目的：
- 防止未来阶段能力继续混入 Phase 1
- 明确必做、可延后、明确不做
5.4 优化动作 4：产出 implementation spec 拆分方案
Section titled “5.4 优化动作 4：产出 implementation spec 拆分方案”已产出：
yomiya-implementation-spec-split-plan.md
目的：
- 让 implementation spec 从“过重单体”转为分层体系
5.5 优化动作 5：抽出当前有效主规格
Section titled “5.5 优化动作 5：抽出当前有效主规格”已产出：
yomiya-implementation-spec-core.md
目的：
- 把当前有效、真正会影响执行的规格从历史痕迹中抽离出来
6. 从 implementation spec 中识别出的关键工程与产品卡点
Section titled “6. 从 implementation spec 中识别出的关键工程与产品卡点”以下卡点来自此前的深度排查，应作为历史记录保存。
6.1 卡点：Tab 分类逻辑曾经前后不一致
Section titled “6.1 卡点：Tab 分类逻辑曾经前后不一致”曾经同时存在：
- topic_tag → Tab 映射
- scene_id 范围 → Tab 映射
这类并存会直接导致实现冲突。
6.2 卡点：rolling_feed 自动追加机制未定义
Section titled “6.2 卡点：rolling_feed 自动追加机制未定义”在早期规格中，NHK 今日要闻这类日更合集被定义为自动追加，但未明确：
- 规则存在哪里
- 何时触发
- 由哪一层服务执行
6.3 卡点：Podcast 采集链路最初没有完整工程路径
Section titled “6.3 卡点：Podcast 采集链路最初没有完整工程路径”虽然播客在产品层很重要，但早期规格中：
- RSS 解析
- 音频入库
- 文字稿获取
- audio 存储字段映射 都未彻底定义。
6.4 卡点：news 表缺失多个被规格引用的字段
Section titled “6.4 卡点：news 表缺失多个被规格引用的字段”例如早期规格多次引用：
duration_sectitle_zhpriority_score
但这些字段并未完全在最初工程差距分析中被落实成统一执行口径。
6.5 卡点：Admin 能力一度没有被单独定义
Section titled “6.5 卡点：Admin 能力一度没有被单独定义”早期更偏重前台规格，但后台操作层的重要性后来逐渐被发现，尤其是：
- 合集管理
- 分发控制
- 今日推荐覆盖
- 建议队列处理
- 异常队列处理
6.6 卡点：内容看完之后的“下一步”曾经是空的
Section titled “6.6 卡点：内容看完之后的“下一步”曾经是空的”这是最关键的平台链路问题之一。如果消费后没有下一步，平台感很难成立。后来已上升为 Phase 1 必做项。
6.7 卡点：Visibility 与 Distribution Eligibility 曾长期没有被清晰分层
Section titled “6.7 卡点：Visibility 与 Distribution Eligibility 曾长期没有被清晰分层”也就是：
- “用户能看见”
- “内容能被分发”
- “内容能首页推荐”
这三件事最开始没有彻底拆开，后来才逐步明确。
7. 当前 review 形成的几个核心长期原则
Section titled “7. 当前 review 形成的几个核心长期原则”这些原则虽然已被转入其他文档，但作为审查结论，值得在本 log 中长期保留。
首页第一版必须是内容平台首页，不是学习任务首页。
自动入库不等于自动首页分发。
Collection 是 Phase 1 成立的必要层，不是可选增强层。
Phase 1 的真正验证对象不是“功能做了多少”，而是“平台感是否成立”。
当前阶段最该看的是 D1 回访、首页内容消费率、连续消费率，而不是单纯内容总量。
总内容量不是北极星，可分发内容池才是当前更真实的供给侧目标。
8. 这份 review log 以后怎么用
Section titled “8. 这份 review log 以后怎么用”用法 1：当有人问“为什么后面文档结构要拆这么细”
Section titled “用法 1：当有人问“为什么后面文档结构要拆这么细””看这里。
用法 2：当有人想把未来阶段能力重新混入 Phase 1
Section titled “用法 2：当有人想把未来阶段能力重新混入 Phase 1”先来这里看历史上为什么要强行设边界。
用法 3：当后续 review 发现类似问题
Section titled “用法 3：当后续 review 发现类似问题”直接对照这里，确认是不是历史重复问题。
用法 4：当需要向新加入成员解释“为什么我们后来这么改”
Section titled “用法 4：当需要向新加入成员解释“为什么我们后来这么改””这里是最好的上下文来源。
9. 本文档不负责什么
Section titled “9. 本文档不负责什么”为了防止本文件再次膨胀，这里明确：
不定义当前有效规格
不替代 open questions
不承接未来阶段详细设计
不变成新的大而全主文档
它只保留：
- 问题
- 风险
- 审查结论
- 修复思路历史
10. 一句话总括
Section titled “10. 一句话总括”Implementation Review Log 的任务不是告诉团队“现在该怎么做”，而是保存团队在把 Yomiya 文档体系从发散状态拉回可执行状态的过程中，发现了哪些坑、形成了哪些关键判断，以及为什么后续必须坚持这些边界。