2026-04-03-ai-handoff
Yomiya Next AI Handoff
Section titled “Yomiya Next AI Handoff”文档状态:历史证据 当前替代文档:
../../../README.md为什么保留:保留单次 session 的完整交接上下文,便于需要时追溯当时的判断和接力点。
用途:给下一位 AI 直接接续当前 Yomiya 工作
当前目标:从文档结构重构,进入“继续探讨并收敛整个内容数据库方案”的阶段
最后更新:2026-04-03
1. 这次 Session 已经完成了什么
Section titled “1. 这次 Session 已经完成了什么”这次 Session 的核心工作,不是继续扩写内容策略,而是先把 ../ 这一层的文档结构重构掉,避免后续执行阶段继续被大量分散文档拖慢。
已经完成:
-
把旧的
01-05目录结构,重构为新的 6 层结构:00-Start-Here/10-Current-System/20-Execution-Spec/30-Research-and-Evidence/40-History-and-Decisions/50-Future-Questions/
-
新建了 3 份默认执行主文档:
00-Start-Here/yomiya-action-plan.md10-Current-System/yomiya-system-source-of-truth.md20-Execution-Spec/yomiya-spec.md
-
把研究、样本、推理、旧规格、历史 review、未来问题全部保留下来,迁移到了
30 / 40 / 50层,没有随意丢弃推理过程。 -
根 README 已重写为新的总导航:
../README.md
-
设计文档和实施计划已经写入:
../../plans/2026-04-03-yomiya-docs-restructure-design.md../../plans/2026-04-03-yomiya-docs-restructure.md
-
这次重构已经形成待合并提交链,后续需要把它并入
main后再继续下一阶段工作。
2. 当前文档体系应该怎么理解
Section titled “2. 当前文档体系应该怎么理解”默认执行入口
Section titled “默认执行入口”后续任何 AI,不要再从历史长文档开始读。默认从这 3 份开始:
./yomiya-action-plan.md../10-Current-System/yomiya-system-source-of-truth.md../20-Execution-Spec/yomiya-spec.md
-
00-Start-Here/负责当前轮次行动总账、阅读顺序、里程碑、角色分工 -
10-Current-System/负责当前系统现实、正式已存在对象 / 字段 / 关系 / 差距动作 -
20-Execution-Spec/负责当前目标规格、命名、页面职责、边界、冻结规则 -
30-Research-and-Evidence/负责竞品研究、推理、样本、映射方法、基础策略与工程差距分析 -
40-History-and-Decisions/负责旧规格、历史拆分、review 记录 -
50-Future-Questions/负责未来能力和开放问题
当前权威关系
Section titled “当前权威关系”后续如果出现冲突,按这个顺序判断:
- 当前行动怎么做 → 看
00-Start-Here/ - 当前系统现实是什么 → 看
10-Current-System/ - 当前目标规格是什么 → 看
20-Execution-Spec/ - 为什么这么判断、证据是什么 → 看
30-Research-and-Evidence/ - 历史上为什么会这样演变 → 看
40-History-and-Decisions/
3. 当前已经收敛出来的关键产品结论
Section titled “3. 当前已经收敛出来的关键产品结论”这些结论已经明确,不要在下一轮重新发散:
-
当前 Phase 1 的目标不是做完整学习系统,而是先建立内容平台主链路。
-
当前主链路固定为:
内容进入系统 -> 内容结构化 -> 内容被组织 -> 首页完成发现 -> 用户开始消费 -> 用户继续消费 -> 用户第二天再回来 -
首页是内容平台首页,不是学习任务首页。
-
当前对象边界已经收敛:
Channel管长期归属Collection管前台发现Series管连续更新Topic管短期运营Tag管描述,不负责承载
-
当前系统现实已经明确:
- 正式主内容对象仍是
news - 长期归属仍是
channel scene仍是关系层能力- 当前还没有正式
collections / series / topic表
- 正式主内容对象仍是
-
当前执行优先级已经收敛:
- 先把内容结构化和内容数据库打磨出来
- 再让 Collection 层成立
- 再让首页真正承接这些内容
- 不是先做复杂推荐、复杂搜索、复杂学习机制
4. 下一位 AI 的真正任务目标
Section titled “4. 下一位 AI 的真正任务目标”后续工作的重点已经从“整理文档”切换到:
继续探讨并收敛整个内容数据库方案。
更具体地说,后续任务的主目标应该是:
-
明确内容数据库当前现实和目标模型之间的差距
-
把
news为核心的现有内容数据层,打磨到能稳定支撑:- 图文
- 视频
- 音频
- 标签
- 可分发资格
- Collection 组织
-
把“可入库”“可结构化”“可分发”“可首页推荐”的准入墙,从文档规则继续收敛成更明确的数据库与接口方案
-
为后续 Collection 层、首页分发层、内容运营层准备一个足够清晰、足够稳定、足够可讨论的内容数据库方案基础
但这里的“内容数据库方案”,不只是数据库表结构讨论,还包括:
- 外部内容源如何继续调研与采集
- 多媒介内容如何按现有框架分类
- 这些内容最终应如何沉淀为 Yomiya 可复用的数据层
一句话说:
下一阶段不是再做文档治理,也不是直接开干实施,而是先把内容数据库这一层的目标模型、边界、约束和演进路径讨论收敛清楚。
5. 下一轮讨论的 3 个核心方向
Section titled “5. 下一轮讨论的 3 个核心方向”下一位 AI 不应该只围绕“表结构”空谈,而应围绕下面 3 条线继续讨论。
方向 A:从播客数据源继续按统一框架做分类采集
Section titled “方向 A:从播客数据源继续按统一框架做分类采集”这件事已经有基础,但还远没完成。
下一轮要继续做的是:
- 以
30-Research-and-Evidence/mapping-notes/播客与视频内容统一分析标准.md为统一框架 - 以
30-Research-and-Evidence/samples/播客与视频竞品统一样本清单.md作为默认样本模板,沿用当前已经重组好的四层字段 - 从原有播客数据源继续按统一字段采样,而不是零散记录
- 优先补齐:
source_brandseries_unitsample_leveltypeupdate_patterntranscript_availabilitytranscript_sourcetranscript_quality_expectationlevelscenecontent_structurephase1_fitrecommended_channelrecommended_collection_directionitem_derivation_valueitem_derivation_form
- 不要只做“识别节目名”,而要继续判断:
- 它适合进入哪个内容方向
- 它更像
Collection候选,还是Series候选 - 它是首页主路径素材,还是只适合作为补充层
一句话说:
播客这条线还没有收完,下一轮要继续做的是“按统一框架补样本”,而不是只看零散节目。
方向 B:扩展到 YouTube 方向,并研究搜索关键词与发现工具
Section titled “方向 B:扩展到 YouTube 方向,并研究搜索关键词与发现工具”下一轮不应只停在“播客怎么收”,还应开始认真研究:
- YouTube 上有哪些适合 Yomiya 的内容类型
- 这些类型分别能用什么关键词搜索出来
- 有哪些工具、平台、技能,适合用来发现和沉淀优质来源
这里的任务不是马上给出一组唯一正确的关键词,而是要形成:
- 一套关键词搜索框架
- 一套发现优质来源的工具清单
- 一套把发现结果纳入样本框架的方法
建议下轮至少从这些关键词簇开始讨论,而不是直接搜单个频道名:
YouTube 关键词簇建议
Section titled “YouTube 关键词簇建议”japanese listening practicecomprehensible japaneseslow japaneseeasy japanesejapanese shadowingjapanese conversationdaily japanesejapanese vloglearn japanese through animejapanese news easyjlpt listeningjapanese travel phrasesjapanese culturejapanese podcastnihongo podcast日本語 聞き流し日本語 会話日本語 シャドーイング日本語 初級日本語 中級日本語 上級やさしい日本語日本語 ポッドキャスト日本語 ニュース日本語 旅行日本語 アニメ
下一轮不应只讨论“哪些词能搜到结果”,而应讨论:
- 哪些词更容易搜到可理解输入
- 哪些词更容易搜到真实生活会话
- 哪些词更容易搜到动漫/兴趣向内容
- 哪些词更偏考试工具型,可能不适合作为主路径
可继续探索的工具与方法
Section titled “可继续探索的工具与方法”当前仓库里没有“专门做 YouTube 内容搜集”的现成 skill。
但下一轮可以围绕这几类工具继续讨论:
-
YouTube 搜索 + 播放列表人工框架采样 最直接,但需要定义好关键词簇和筛选标准
-
YouTube Data API 适合系统化拉取频道、视频、播放列表、标题、描述、发布时间、时长等元信息
-
播客平台目录 / 排行工具 例如 Apple Podcasts、Spotify、Listen Notes 一类目录工具,用于继续补播客源
-
手工样本表 + 统一字段模板 当前最稳妥,适合在判断框架仍未完全稳定前继续使用
-
浏览器自动化 / 搜索辅助 用于批量查看频道、节目、播放列表、描述和评论区风格,但前提仍是先定义字段模板
如果下一个 AI 要继续接这一块,建议明确回答:
- 仓库里当前没有专门的“优质内容搜集 skill”
- 但已经有用于统一研究判断的框架文档
- 下一轮的重点是把“搜索关键词框架 + 来源筛选方法 + 样本表字段”三件事配起来
方向 C:这些内容最终该如何沉淀进 Yomiya 框架
Section titled “方向 C:这些内容最终该如何沉淀进 Yomiya 框架”这是下一轮最值得质疑和继续讨论的点。
你当前的设想是:
先把外部内容转成文字,再由 AI 把这些最小
item沉淀进系统
这个方向有价值,但现在还不能直接当成最终答案。
下一轮必须继续质疑至少 4 个问题:
质疑 1:文字是不是唯一正确的中间层?
Section titled “质疑 1:文字是不是唯一正确的中间层?”不是一定。
原因:
- 视频和音频的价值不只在文本,还在语速、语气、说话人结构、情绪、剪辑节奏
- 纯文本会丢掉一部分对
level / scene / content_structure很重要的信息
更稳的理解应该是:
- 文字转写是重要中间层
- 但不应被误当成唯一事实层
- 原始媒体、元信息、转写文本、AI 结构化结果,可能是四层不同资产
质疑 2:最小 item 到底是什么?
Section titled “质疑 2:最小 item 到底是什么?”这件事当前还没定死。
可能的层级至少有:
-
外部原始内容单元
例如一集播客、一条视频、一篇图文 -
Yomiya 内容条目
当前更接近news这一层 -
可继续切分的更小文本 / 片段单元
例如句子、片段、片段主题、知识点
下一轮要继续讨论的是:
- “最小 item” 是不是等于外部单条内容
- 还是应允许从单条内容继续切出更小的可消费 / 可索引 / 可推荐单元
质疑 3:Collection 应该组织原始内容,还是组织 AI 提炼后的 item?
Section titled “质疑 3:Collection 应该组织原始内容,还是组织 AI 提炼后的 item?”这件事也不能先拍死。
可能有两种路径:
Collection组织原始内容条目Collection组织 AI 提炼后的二级单元或混合单元
下一轮要继续判断:
- 首页和详情页真正承接的,应该主要是原始内容,还是 AI 切分后的二级 item
- 不同类型内容是否需要不同沉淀策略
质疑 4:AI 结构化应该落在哪一层?
Section titled “质疑 4:AI 结构化应该落在哪一层?”AI 可能参与至少三层:
-
内容分类层
判断scene / level / content_structure / phase1_fit -
内容切分层
判断是否拆出更小 item、片段、金句、可复用单元 -
内容组织层
判断归入哪个Collection / Series / Channel
下一轮不应先默认三层都做,而应先讨论:
- 哪一层对当前最有价值
- 哪一层最值得先打磨
- 哪一层最容易做重
一句话说:
“转文字 + AI 生成最小 item” 是一个值得继续讨论的方向,但现在仍然是候选框架,不应直接跳成定案。
6. 下一位 AI 应该先读什么
Section titled “6. 下一位 AI 应该先读什么”./yomiya-action-plan.md../10-Current-System/yomiya-system-source-of-truth.md../20-Execution-Spec/yomiya-spec.md
然后重点补读
Section titled “然后重点补读”../30-Research-and-Evidence/foundations/yomiya-engineering-gap-analysis.md../30-Research-and-Evidence/foundations/yomiya-content-asset-layering.md../30-Research-and-Evidence/foundations/yomiya-content-research-workflow.md
原因:
这份文档最接近“数据库现实、API 现实、工程差距、最小工程方案”。 如果下一步要继续打磨内容数据库,它是最直接的桥梁文档。
新增的 yomiya-content-asset-layering.md 则用于保存这轮关于
“原始内容 / 转写文本 / AI 结构化 / 最小 item” 之间关系的 reasoning,
避免后续 AI 只记住结论,不知道为什么当前不应该直接走“先转文字再把最小 item 当主对象”的路线。
新增的 yomiya-content-research-workflow.md 则用于把
“为什么先跑 Mirra 播客池、四层样本模板怎么走、何时扩到 YouTube、何时再进入数据库方案讨论”
这整套流程可视化下来。
../30-Research-and-Evidence/foundations/yomiya-content-strategy.md../30-Research-and-Evidence/mapping-notes/播客与视频内容统一分析标准.md../30-Research-and-Evidence/competitive-analysis/Mirra播客排查与运用.md
这些文档主要用于理解:
- 为什么内容对象会这样设计
- 多媒介内容未来会怎么进入数据库
- 播客 / 视频样本如何映射为 Collection / Tag / Channel
7. 下一位 AI 应该补充回答的问题
Section titled “7. 下一位 AI 应该补充回答的问题”下一轮不是直接下结论,而是建议继续围绕下面这些问题展开:
- 播客样本补齐时,当前统一字段模板是否还缺关键列?
- YouTube 关键词簇是否应该按内容取向分层,而不是按平台散搜?
- 是否需要建立一份“优质来源判定标准”?
- 转写文本在整个沉淀框架里是“唯一事实层”还是“重要中间层”?
- Yomiya 最小 item 到底应该定义在“原始内容层”还是“AI 切分后的片段层”?
Collection当前应先组织什么:原始内容、AI 切片,还是两者混合?- 数据库方案是否应先服务“原始内容可组织”,再考虑“细粒度 item 沉淀”?
8. 下一位 AI 不应该做什么
Section titled “8. 下一位 AI 不应该做什么”- 不要重新回到旧
01-05结构思考问题 - 不要跳过
00 / 10 / 20直接从研究长文开始 - 不要重新发散首页主叙事
- 不要把未来能力提前混进当前数据库打磨任务
- 不要把“研究层理想形态”直接写成“当前系统现实”
9. 推荐的下一步切入点
Section titled “9. 推荐的下一步切入点”如果下一位 AI 要立刻继续推进,我建议直接从这个问题开始:
“基于 10-Current-System/yomiya-system-source-of-truth.md 和 30-Research-and-Evidence/foundations/yomiya-engineering-gap-analysis.md,继续探讨并收敛一份面向 Backend 的内容数据库方案:当前表结构、必须补齐的字段 / 关系 / 约束、Collection 层可能的落库方案、准入墙应该如何表达、以及对应 API 和后台能力应如何演进。”
这会把后续讨论收敛到真正有价值的方向:
- 数据模型
- 唯一性约束
- 内容结构化要求
- Collection 落库
- 分发资格状态
- API 设计
- 后台运营控制能力
10. 推荐的下一轮 session 开场方式
Section titled “10. 推荐的下一轮 session 开场方式”建议下一个 AI 不要一上来就写数据库表,而是按这个顺序开场:
- 先确认当前讨论目标是“继续调研 + 收敛方案”,不是直接实施
- 先读
00 / 10 / 20三份执行文档,避免重新发散 - 然后进入 3 条讨论主线:
- 播客样本继续分类采集
- YouTube 关键词簇与优质来源发现方法
- 内容沉淀框架:原始内容、转写文本、AI 结构化、最小 item 之间的关系
- 最后再讨论数据库方案应该如何承接这些东西
11. 一句话交接
Section titled “11. 一句话交接”这次 Session 已经把 Yomiya 文档体系从混乱的大量散文档,重构成了“执行层 + 证据层”的结构;下一位 AI 不需要再做文档治理,而应该基于新的入口,继续和你一起探讨并收敛内容数据库方案。