ray-kb

# Ray KB（口播再分发） 把已经核验的图文母稿改编成可直接录制的口播内容包。改编不是缩写：不要试图把长文每一段都塞进口播；从母稿中只选一个最适合视频的判断，重新安排问题、证据、节奏和结尾动作。 ## 固定原则 1. 母稿是事实、判断和来源的唯一真源。衍生稿必须记录 `source_draft` 与 `source_sha256`，不能自行增加事实、经历或效果数字；母稿变化后先重新核对，再改口播。 2. 不写“亲测”“实测”或具体效果，除非母稿和事实清单能证明用户真的做过。来源作者的实践保持归属，不改写成 Ray 的第一人称。 3. 一份口播稿只承载一个中心判断，只保留一个结尾动作。 4. 母稿的写作与修改属于 `ray-writer`。改编中发现母稿事实有问题时停下来交回，不在口播稿里就地修事实。 5. 不自动发布。未经用户明确要求，不生成图片卡片成品，不调用付费视频或图片生成。 ## 输入门 只接收 `kind: draft`、`kind: article` 或已经发布的完整正文。收到 `content-pack`、调研或审核卡时，沿 frontmatter 的 `draft` 链接找到母稿；找不到就停止并说明缺口，不把任务说明当文章。 知识库根目录不写死：优先使用用户明确路径，再向上查找 `.ray-obsidian.json` 或兼容目录结构。找不到兼容知识库、用户只要一次性口播稿时，可在当前工作区交付内容包，并说明这次没有进入知识回流；需要长期管线时先转交 `ray-obsidian`。 读取母稿、成稿包和事实清单，确认： 1. 哪些是已核对事实。 2. 哪些是来源作者的观点。 3. 哪些是 Ray 愿意署名承担的判断。 4. 哪些个人经历已被用户确认可以使用。 5. 哪些数字、产品状态和限制需要录制前再核对。 ## 先选视频角度 从母稿提取最多三个候选，每个候选写清：目标观众、一个中心判断、开场冲突、最强证据、能拍出来的画面，以及删掉后会失去什么。 选择标准按顺序执行： 1. 脱离工具名后，判断仍然成立。 2. 现有事实足以支撑，不需要编故事。 3. 前 8–10 秒能出现变化、矛盾或反直觉判断。 4. 中段有一个能被截图、录屏或真实操作证明的重心。 5. 结尾能给一个低摩擦动作。 用户未指定时长时，默认做 2–3 分钟、真人出镜加录屏或截图的混合口播。60–90 秒只保留一个反转和一个动作；5 分钟以上的教程必须把演示步骤与口播解释分层。 ## 重写为口播 采用这条推进线： ```text 判断或冲突 → 观众熟悉的挫败 → 事实或真实演示 → 再判断 → 一个动作 ``` 写作时遵守： - 第一句直接给判断、变化或冲突，不从背景和自我介绍开始。 - 一段只说一个动作；一句超过约 45 个汉字时优先拆开。 - 关键判断单独成句。连续三个术语时，插入人话解释、类比或画面。 - 口播只放观众必须听懂的内容。完整链接、命令、数字口径和补充步骤放在来源与说明栏。 - 画面必须证明一句口播，不能只做装饰。每个镜头标为 A-roll、录屏、截图、字卡或后续 B-roll。 - 只保留一个结尾动作。不要同时要求点赞、关注、评论、转发、进群和买课。 ## 口播语气 - 像一个做过事情、愿意给出判断的人对朋友讲话：平视观众，不装导师，不念稿。 - 技术名词要落回真实动作、结果或代价；网感来自观众熟悉的场景和口语节奏，不靠热梗、感叹号和表情。 - 情绪来自主题的真实矛盾，可以用反问、停顿、短句和局部加速；不虚构愤怒、震惊、眼泪或现场对话。 - 删除署名后，观众仍能听出这是 Ray 的判断，而不是一段通用 AI 解说。 ## 输出文件 从长文改出的衍生稿与母稿一起放在 `<vault>/10-创作/30-文章草稿/`，文件名增加 `-口播稿`；以口播起稿、没有图文母稿的内容才放 `<vault>/10-创作/20-口播草稿/`，它自己就是母稿。衍生稿不是第二份母稿，frontmatter 至少包含： ```yaml kind: oral-script status: ready-to-record source_draft: "[[母稿文件名]]" source_sha256: "母稿完整文件的 sha256" content_pack: "[[对应成稿包]]" target_platform: "视频号 / 抖音 / B站" target_duration_seconds: 150 video_format: "A-roll + 屏幕录制" central_judgment: "观众看完只记住的一句话" image_card_status: not-started ``` 正文固定包含： 1. `## 选题卡`：观众、原有认知、中心判断、证据、主目标和唯一动作。 2. `## 三个开场`：反直觉、变化结果和具体场景各一个，明确最终采用项。 3. `## 逐字稿`：只放能直接念的文字，不混入括号提示、表格或镜头说明。 4. `## 拍摄节奏`：时间、口播关键词、画面、字幕重点和素材状态。 5. `## 素材清单`：已有、待录、待做、可删除四种状态。 6. `## 图片长文接口`：只记录视觉命题、建议页数和母稿来源，默认状态为 `not-started`。 7. `## 来源与录前核对`：原始链接、易变信息和录前检查项。 ## 图片长文接口 本轮不把图片长文做成完整生产流程，只保留三个稳定输入： - 一句话视觉命题。 - 6–10 页建议叙事顺序。 - 母稿路径、内容指纹与允许使用的图片来源。 后续建立独立视觉能力时，从这三个输入开始，不重新从长文猜判断，也不复制第三方公众号的可识别排版。 ## 验证与交接 完成后运行： ```bash python3 scripts/oral_script_check.py <口播稿.md> --source <母稿.md> ``` 检查失败就修改并重跑。脚本通过只证明结构、来源指纹和估算时长成立，仍要人工确认只有一个中心判断、画面能证明口播、结尾只有一个动作，并完整朗读一次；无法真实朗读时，必须明确时长只是字数估算，不能冒充录制时长已经实测。 需要做画面时，把口播稿路径、中心判断、拍摄节奏和素材清单交给 `ray-broll`；它只补适合的视觉隐喻或讲解片，不反向修改事实和口播判断。真人出镜与录屏由拍摄计划承担。 ## 交付要求 向用户交付母稿路径、口播内容包、估算时长和录前核对项，并明确是否完成真实朗读；简要说明选了哪个角度、放弃了哪些候选。不把内部检查过程写成长报告。