旧版-新资源轻量入库流程

Yomiya 新资源轻量入库流程

文档状态：历史证据 当前替代文档：../../03-新资源入库流程.md 为什么保留：保留轻量入库规则旧稿，便于核对“人工预筛选 -> 转文字 -> 归类”是如何收敛出来的。

文档性质：研究阶段轻量入库规则
用途：约束新播客、YouTube 等资源在人工已筛选前提下，如何进入“转文字 -> 归类 -> 后续入库讨论”流程
适用范围：人工挑选的新资源、播客补样本、YouTube 来源扩展、正式工程入库前的研究处理
边界说明：

• 本文档定义的是“人工预筛选后的系统处理流程”，不是完整数据库实施流程
• 当前系统现实仍以 ../../02-当前系统现实.md 为准
• 当前执行边界仍以 ../../01-当前目标与范围.md 为准
• 系统默认不再重复判断“这是不是好资源”，那一步已经由人工完成 最后更新：2026-04-03

---

1. 这份文档要解决的问题

前一版逻辑的问题，不是判断本身完全错误，而是把系统侧的责任放得太重了。

真实工作流里，当前更接近的是：

1. 人工已经先挑过一层资源
2. 进入系统的，默认都是“值得试着入库”的候选
3. 系统只需要解决：
   • 能不能拿到可用文字
   • 拿到文字后属于哪一类

因此，系统侧不该继续承担这些前置判断：

• 它是不是值得研究
• 它是不是高价值资源
• 它是不是 Phase 1 候选
• 它是不是内容型资源

这些判断当前都默认由人工前置完成。

系统侧当前应该只负责：

• 文字路径判定
• 归类
• 失败回退

一句话冻结：

人工先挑，系统不重复判值；系统只负责转文字、做归类、处理失败回退。

---

2. 当前建议采用的最简模型

当前最稳的处理方式只保留三步：

1. 人工预筛选
2. 转文字
3. 归类

系统只保留一个很轻的兜底，不做复杂 gate：

• 如果明显拿不到可用文字，就进入失败或暂挂
• 如果文字可用，就直接归类

2.1 系统输出状态

当前只保留 4 个处理状态：

• queued
  • 人工已挑选，等待处理
• transcript_ready
  • 已拿到可用文字
• transcript_failed
  • 当前无法拿到可用文字，需人工补充或暂挂
• classified
  • 已完成归类，可进入后续样本沉淀或正式入库讨论

这 4 个状态描述的是处理进度，不是资源价值等级。

---

3. 系统到底负责什么

3.1 步骤 A：登记最小元信息

这一层只负责让资源进入处理队列，不做复杂判断。

最小必填建议只保留：

• platform
• source_brand
• sample_name
• sample_level
• type
• url 或来源定位信息
• notes

如果是播客，优先登记：

• 节目名
• 单集名或节目名
• 平台链接

如果是 YouTube，优先登记：

• 频道名
• 视频名或播放列表名
• 视频 / 播放列表链接

---

3.2 步骤 B：判定文字路径

这一步是系统侧最重要的判断。

当前只问一个问题：

这条资源有没有办法拿到可用文字。

统一只分三类来源：

• native
  • 平台原生 transcript、caption、subtitle、article、description
• generated
  • 没有现成文字，但可以用 ASR 生成
• failed
  • 当前既没有现成文字，也无法得到可用 ASR

音频怎么判

优先级：

1. 平台原生 transcript / show notes / description
2. RSS description 或附带文字
3. ASR

视频怎么判

优先级：

1. 原生 captions / subtitle
2. 视频 description 或配套 article
3. 抽音轨做 ASR

这一层的原则

• 不去讨论这资源值不值
• 只讨论“文字现在拿不拿得到”
• 能拿到就继续，拿不到就先挂起

---

3.3 步骤 C：归类

只要文字可用，就直接进入归类。

当前归类输出建议只保留这些字段：

• type
• transcript_availability
• transcript_source
• transcript_quality_expectation
• level
• scene
• content_structure
• recommended_channel
• recommended_collection_direction
• series_candidate

如果是当前研究阶段，还可以顺手保留：

• cross_media_expandability
• item_derivation_value
• item_derivation_form

但这些是补充输出，不再作为前置 gate。

当前归类依赖关系

最重要的依赖很简单：

• 没有文字，不做稳定归类
• 有文字，再结合标题 / 简介 / 元信息做归类

也就是说：

归类依赖文字成功，不依赖复杂 intake benchmark。

---

3.4 步骤 D：失败回退

如果文字失败，不要硬做分类。

当前只保留两种处理：

1. 待人工补充
   • 例如人工补标题说明、补 transcript 来源、补外部文字稿
2. 暂挂
   • 先不继续处理，等后续再看

失败时至少要记录：

• 为什么失败
• 是无字幕、无 transcript、ASR 不可用，还是噪音太高

---

4. 轻量兜底，而不是复杂 gate

虽然系统不再负责“资源值不值得入”，但仍然可以保留一个很轻的异常拦截：

• 文字结果明显不是日语主体
• ASR 结果噪音极高，无法支撑归类
• 视频几乎没有可解析语音

这类情况不叫“内容不值得入”，而叫：

当前无法完成稳定转文字与归类。

这时进入 transcript_failed 或人工补充，不再展开复杂评分。

---

5. 音频 / 视频的最小处理方式

5.1 音频

默认流程：

1. 人工挑中音频资源
2. 登记最小元信息
3. 找原生 transcript / description
4. 没有就做 ASR
5. 成功后归类
6. 失败则人工补充或暂挂

音频此时不需要系统先判断：

• 是不是高价值播客
• 是不是 Phase 1 候选
• 是不是某个研究优先级分层

这些都已经默认包含在人工前置选择里。

5.2 视频

默认流程：

1. 人工挑中视频资源
2. 登记最小元信息
3. 优先取原字幕
4. 没字幕就抽音轨做 ASR
5. 成功后归类
6. 如果极度依赖画面导致文字不足，再人工补方向备注

视频此时也不需要系统再先做多层价值判断。

---

6. 依赖关系冻结表

处理结果	依赖什么	不应怎么做
transcript_ready	原字幕 / 原文 / ASR 任一成功	不要还没拿到文字就先做完整归类
transcript_failed	原字幕缺失且 ASR 失败	不要硬把失败样本归类进方向
level / scene / content_structure	标题 / 简介 / 文字稿 / 基础元信息	不要重新发明前置 value gate
recommended_collection_direction	归类结果	不要先想 Collection 再倒推内容
后续正式入库讨论	文字成功 + 归类完成	不要让系统重复判“值不值得看”

---

7. 全流程图

flowchart TD
  A[人工挑选新资源] --> B[登记最小元信息<br/>platform source_brand sample_name type url]
  B --> C{是否有现成文字稿或字幕}

  C -->|有| D[直接取文字]
  C -->|无| E[走 ASR 转文字]

  E --> F{ASR 是否成功}
  F -->|否| G[标记 transcript_failed<br/>待人工补充或暂挂]
  F -->|是| H[得到文字稿]

  D --> H
  H --> I[AI 归类]
  I --> J[输出结构化结果<br/>transcript_source level scene content_structure collection_direction]
  J --> K[状态更新为 classified]
  K --> L[进入样本沉淀<br/>或后续正式入库讨论]

---

8. 当前建议的实际用法

8.1 新资源进来时

不要先问：

• 它是不是某个研究池状态
• 它是不是某个候选等级
• 它是不是高优先级

先问：

• 有没有现成文字
• 没有的话能不能 ASR
• 拿到文字后属于哪一类

8.2 样本表怎么用

样本表现在更适合承接：

• 已经拿到文字并完成初步归类的资源
• 或者文字失败、但人工仍想保留观察的资源

8.3 后续什么时候再讨论复杂判断

只有当你们开始进入正式工程落库、批量化自动入库、或者首页分发资格控制时，才需要重新引入更复杂的 gate。

当前阶段不需要。

---

9. 一句话总结

Yomiya 当前更合理的新资源处理逻辑，不是让系统重复判断“值不值得入”，而是默认人工已经做过这层筛选；系统只负责判断文字路径、完成转文字、输出归类结果，以及在文字失败时进入人工补充或暂挂。