/ray-kb

name: ray-kb
description: 把灵感、观察或长文写成 Ray 能直接开机录的中文口播稿（Ray 口吻、观点说满，存疑处列进「待确认」）；也审读口播稿，或对照录制稿学习 Ray 的真实表达。用于“做成口播”“改成口播”“审一下口播稿”“对比我录的”。讲清一件事、以讲解为主的科普视频稿不在这里（装了 ray-kepu 时转它）。不发布。

Ray KB（口播生产与再分发）

目标只有一个：写出 Ray 拿到就能录的稿子。表达先行，事实只守底线，一切为了内容和传播。

唯一的风格约束

每次写口播之前，完整读取 [口播表达规则](references/voice.md)，按里面的样本清单把 Ray 的真实稿件整篇读完再动笔。表达规则之外不加任何写作限制。

固定原则

1. 一份口播稿只讲一个中心判断。 2. 正文里只放能直接念的话（叙事型可以有单独成行的 `【原声：……】`）；拿不准的、编补的内容全部进「待确认」，不在正文里自保。 3. 立论点先核实再动笔。中心判断依赖的事实查不实，就换判断或降低说法，「待确认」里 🔴 立论级最多一条。编经历之前先从对话、知识库和发布记录里找真实经过。 4. 长文再分发时，衍生稿记录 `source_draft` 与 `source_sha256`，方便母稿变了之后知道要重看。 5. 不自动发布。未经用户明确要求，不生成图片卡片成品，不调用付费视频或图片生成。 6. 用户提供实际录制稿时，逐字稿以用户版本为准；生成稿保留为比较证据。录制完成不等于已经公开发布，平台、链接和时间未知时只标记 `recorded`。

选择工作模式

• **原生快速口播 `fast-oral`**：从灵感、现场观察、咨询案例或对话里的判断出发，没有现成长文。读取 [原生快速口播](references/fast-oral.md)，只建一份母稿。素材是一个故事、带原始录音或影像时，用其中的叙事型写法。
• **长文再分发 `article-repurpose`**：输入是完整长文，或能沿 `content-pack` 找到完整母稿。按下方流程执行。
• **审读或录后学习**：用户给的是现成口播稿、最终录制稿或要求对照两版，不重新生产，分别走“口播稿审读”或“录后对照与学习”。

用户只说“做一条口播”、同时有长文和新想法时：主要讲长文里的判断就走再分发，新判断就走快速口播。

**科普讲解稿不归这里。** 用户要的是讲清楚一件事、一个原理，让观众看懂、学到东西、愿意收藏转发，说了“科普”“讲解向”“改成科普版”或“不要太多我的判断”时，Ray 的观点不是主角，本 skill 的“观点说满、编补进待确认”会把稿子写成说教。本机装了 `ray-kepu` 时交给它；没装时仍可在这里写，但按叙事型的事实照实讲、结尾不下 Ray 的判断。

知识库根目录不写死：优先用户明确路径，再向上查找 `.ray-obsidian.json` 或兼容目录结构。找不到时可以在当前工作区交付一份稿件，并说明这次没有进入知识回流；需要长期管线时转交 `ray-obsidian`。

长文再分发

只接收 `kind: draft`、`kind: article` 或已经发布的完整正文。收到 `content-pack`、调研或审核卡时，沿 frontmatter 的 `draft` 链接找到母稿；找不到就说明缺口。

从母稿里挑一个最适合视频的判断：脱离工具名仍然成立，前几秒就能说出冲突或反直觉的东西。候选可以在对话里比较，文件里只留采用的那个。不要试图把长文每一段都塞进口播。

衍生稿与母稿放在一起：`<vault>/10-创作/30-文章草稿/<母稿名>-口播稿.md`。frontmatter：

kind: oral-script
status: ready-to-record
source_draft: "[[母稿文件名]]"
source_sha256: "母稿完整文件的 sha256"
central_judgment: "观众看完只记住的一句话"
target_duration_seconds: 150
recording_status: pending

正文三段：

1. `## 逐字稿`：只放能直接念的话，不混入括号提示、列表、表格或镜头说明。 2. `## 待确认`：格式见 [口播表达规则](references/voice.md)。 3. `## 素材与来源`：用到的链接、截图、录屏想法。可以简短，不需要事实边界说明。

验证与交接

python3 scripts/oral_script_check.py <口播稿.md> --source <母稿.md>   # 长文再分发
python3 scripts/oral_script_check.py <快速口播母稿.md>                 # 快速口播

脚本只检查结构能不能用：章节齐不齐、正文里有没有混进列表和括号、母稿指纹对不对，时长估算只是参考。它不管风格。交付前把逐字稿从头默念一遍，念不顺的地方直接改。

需要做成解说视频时，把口播稿路径和中心判断交给 `ray-explainer`；若装了独立仓库 ray-skills 的 ray-broll，也可交给它做拼贴画面。

口播稿审读

“审一下这篇口播稿”“哪里会让人划走”类请求走审读，不重新改编，按 [口播稿四关审读](references/script-review.md) 执行。审读只管传播效果，不核对事实。诊断完问是否改稿，用户确认后才动手；改的时候同样遵守 [口播表达规则](references/voice.md)。

录后对照与学习

用户给出最终录制稿、要求比较生成稿与实际表达，或要求把修改沉淀下来时，按 [录后对照与表达学习](references/recording-feedback.md) 执行：

1. 分别保留生成稿和实际录制稿；最终录制正文原样保存，不再润色。 2. 先比较叙事，再比较口癖、情绪和句子，找出机器稿哪里不像 Ray。 3. 学到的东西落在样本上：把这篇录制稿加进 [口播表达规则](references/voice.md) 的样本清单，而不是新增写作规则。 4. 用户只要求对照时，不生成第三版，不推断已经发布。

交付要求

交付稿件路径、中心判断、估算时长和「待确认」里有几条；有 🔴 立论级的，单独点出来。一两句话说清楚，不写内部检查报告。