lmj-tech-short-video-workflow

name	lmj-tech-short-video-workflow
description	Use this skill whenever the user asks to create, remake, polish, batch-produce, diagnose, synchronize, render, or deliver a Chinese vertical technology, AI-tool, open-source-project, research-project, or knowledge-explainer short video for Douyin/TikTok/Reels, especially when they mention “之前那种视频”, Remotion, 主卡片, 上下留白, 一行字幕, 词群字幕, 字幕贴近卡片, 音画同步, 配音杂音, 可视化动画, 暗红重点, 竖屏成片, or multiple version cleanup. It turns a topic list and optional voice assets into a verified 1080×1920 video while preserving factual provenance, readable visual hierarchy, phrase-level captions, audio-first timing, and final-media QA.
compatibility	Codex desktop or CLI with filesystem access; Remotion is preferred for code-native video production. FFmpeg/ffprobe is required for final media verification.

LMJ 科技类竖屏短视频工作流

把用户给出的主题、项目清单、资料和配音变成可复用、可修改、可验证的竖屏科技短视频。默认风格是克制的学术科技感：中央信息卡、明显上下留白、可视化优先、一行词群字幕、少量暗红色重点。

1. 先恢复任务状态

1. 检查当前对话、已有工程、成片、样片、文案、音频和用户最近一次纠正。
2. 复用已经确认的尺寸、风格、字幕位置、音色和时间轴；不要因局部视觉修改重做已验收的音频同步。
3. 检查 Git 状态或文件清单，保护用户已有改动。旧版本、失败样片和源音频属于用户材料，不自行清理。
4. 只询问会改变交付路线且无法从材料判断的问题。可安全恢复的信息先查，不把文件名、尺寸或已有风格重新问给用户。

2. 选择需要调用的能力

• 创建或修改 Remotion 视频时，读取可用的 remotion-best-practices，再按任务读取其 create、markup、captions、multimedia 或 render 路由。
• 内容包含实时热度、Star、版本、趋势、产品能力或其他会变化的事实时，以 research-project-orchestrator 为入口，使用科研侦察能力核验官方来源，并保存快照日期。
• 需要理解既有多文件视频工程时，先用 rg 和定点读取；只有跨文件调用关系确实复杂且代码图已可用时，才使用 research-code-context。
• 最终交付前执行最低充分的确定性质量检查；高影响事实或公开发布风险再使用科研质量门。

3. 锁定内容合同

开始写代码前整理一个紧凑合同：

• 目标平台、画布、帧率和期望时长；
• 视频是纯项目介绍、观点解读、榜单还是教程；
• 每个对象允许出现的事实、用途、亮点和一句核心收益；
• 配音是否已经提供，是否具有发布授权；
• 用户明确要求保留的风格与不能出现的问题；
• 最终成片、样片和工程源文件的保存位置。

科技项目介绍默认采用“是什么 → 最亮能力 → 能用来做什么 → 为什么省事”的顺序。除非用户要求，不把项目强行关联到用户自己的科研体系，也不把 README 的宣传语当作已验证结论。

4. 建立事实与素材来源

1. 为项目名称、owner/repository、核心能力、数据快照和素材 URL 保留来源定位。
2. Star、趋势和版本必须标注核验日期；无法稳定核验时弱化或删除，不在画面中伪造精确数字。
3. 记录 Logo、仓库预览、图片、字体、音乐和音色的许可边界。第三方仓库许可证不自动覆盖商标、README 图片或配音模型商业权利。
4. 把来源写入项目级 PROVENANCE.md 或等价文件；不要把单一项目的数据写进本 Skill。

5. 先完成口播，再做时间轴

文案

• 开头先给具体痛点或直接收益，不用空泛的“今天给大家分享”。
• 每个项目优先用 1–2 句：第一句说能力，第二句说用途或收益。
• 纯项目介绍不夹带对用户现有系统的定向建议，除非用户明确要求。
• 读起来像口语，避免连续堆名词、参数和 Star。

音频优先

1. 用户已提供配音时，把音频当作时间轴权威来源，先检查时长、采样率、声道、响度、峰值、异常静音和可闻杂音。
2. 用句间停顿、实际发音或转写结果建立边界，不按估算字数平均分配镜头。
3. 新项目卡或关键视觉通常比对应发音提前 8–12 帧进入，让观众先看到再听到。
4. 音频快于画面时，调整镜头边界、视觉提前量或旁白片段；不要用全局拉伸掩盖局部不同步。
5. 只有某一段存在杂音或文案错误时，优先替换该段并重新计算受影响的后续边界，不重生成已经干净的整条音频。
6. 替换片段后重新核对字幕、场景、总帧数和音轨结尾，不假设旧偏移仍然成立。

6. 使用 LMJ 默认视觉合同

除非用户给出新的参考，采用以下默认值：

• 1080×1920、30 fps；主内容集中在中部，上下保留明显呼吸空间，不铺满竖屏。
• 主卡片靠中上区域；字幕紧贴主卡片下方，视觉间距约 48–72 px，避免字幕漂在屏幕底部。
• 冷白、浅蓝灰为底色，深蓝灰承载正文；暗红 #8D3342 只用于真正的关键词、结果或核心收益。
• 小字必须能在手机上直接读清。1080 宽画布的辅助标签通常不低于约 19–22 px；标题和项目名按可读层级显著放大。
• 重点色保持稀少。不要把整段标题、所有数字和全部标签同时变红。

7. 主卡片以可视化为主

主卡片不要复述全部旁白。优先保留：

1. 项目 owner/repository 与类别；
2. 一句核心标题；
3. 一个项目特定的流程、网络、结构图、输入输出或扫描动画；
4. 两个短用途标签；
5. 一句核心收益。

将三段以上说明文字改成结构图、节点、流向、扫描、文件堆叠、调用图或前后对照。动画必须帮助理解项目机制，而不是只做装饰。长项目名、长收益和中英文混排要单独渲染检查。

8. 字幕必须是一行词群

• 任意时刻只显示一行字幕；禁止自动换成两行。
• 按自然词群和呼吸点切分，例如“Word、PPT、Excel、PDF”与“都能统一转成 Markdown”分开出现。
• 不留下只有一个字、单个标点或失去语义的尾巴。
• 使用 white-space: nowrap 或等价约束，并在渲染前测量宽度。内容过长时先重新切词群，再适度缩小字号，不能直接允许换行。
• 字幕字号随长度在可读区间内调整，但不让长句变成难以阅读的小字。
• 字幕出现和消失跟随真实音频边界，使用短淡入淡出，不做逐字乱跳。

9. 用分帧预览驱动修改

完整渲染前至少检查：

• 开场钩子；
• 普通项目卡；
• 最长项目名和最长收益；
• 信息最密集的卡片；
• 双项目或特殊布局；
• 结尾总结。

把关键帧渲染成 still 或联系表，检查留白、卡片位置、字幕距离、暗红重点、单字掉行、遮挡和小字可读性。只调整视觉时保持已验收时间轴不变；只修音频时限制视觉改动范围。

10. 最终质量门

按风险从小到大执行：

1. eslint 与 TypeScript；
2. 关键帧 still 与长文本视觉核验；
3. 完整渲染；
4. ffprobe 核对编码、1080×1920、30 fps、帧数、总时长、AAC 音轨、48 kHz 与声道；
5. 核对音频结尾与视频结尾，通常不应存在明显可感知的空尾；
6. 抽查开场、音频替换点、项目切换点和结尾的音画同步；
7. 检查杂音、爆音、削波和异常静音；工具结果与实际听感冲突时，以人工听感复核并记录限制。

失败时只修改受影响的 canonical 数据、组件或边界，重新运行最小相关检查，再决定是否重渲完整成片。

11. 交付与版本清理

• 成片文件名表达主题和最终特征，避免把“最终版”写进多个并存文件。
• 交付时给出绝对路径、媒体预览和关键媒体参数。
• 用户要求“只保留最终版”时，先精确列出保留文件和拟删除版本；不同命名系列可能是不同项目，未经确认不要合并删除。
• 删除前核对绝对路径、目标数量、文件类型和链接属性。优先可恢复删除；永久删除只对用户明确确认的精确清单执行。
• 工程、源音频、来源记录和用户未提交改动不属于“旧成片”，除非用户明确把它们纳入清理范围。

12. 输出摘要

最终答复只保留用户需要的结果：

• 成片或样片路径；
• 本轮最重要的视觉、文案或同步改动；
• 已执行的验证；
• 仍需用户决定的发布授权或版本清理事项。

更具体的执行检查表见 references/workflow-and-qa.md。