Codex + Excalidraw 白板视频工作流：一句话生成不露脸手绘成片

本文根据 Simon聊AI（@HanZhang415188）在 X 发布的短帖与关联长文整理。短帖入口是《Codex + Excalidraw，一句话出一条手绘白板视频》，长文入口是关联 X Article，原文页面显示作者为 Simon聊AI，发布于 2026 年 9 月 25 日。由于 X 长文页面存在抓取不稳定的情况，本文同时对照了公开整理页面的正文、图片顺序和项目入口；正文是结构化改写，不是逐字转载。

原文中关于账号表现、制作耗时、渲染速度、工具体验和成本的内容都属于作者自述。本文保留这些经验的上下文，但不把它们写成 Codex、Claude Code、Excalidraw、火山引擎或视频平台的官方保证。工具版本、服务价格、模型能力、平台规则和开源仓库内容应以实际运行结果和当前官方资料为准。

很多人刷到过这种视频：一块白板、一支铅笔，字和图跟着旁白一笔一笔出现，两三分钟讲清一个知识点，全程不需要真人出镜。

这篇实践的重点不是“让 AI 自动画一张图”，而是把一整期白板视频拆成一条可以反复执行的生产线：输入一句选题，先做资料查证和旁白，再生成贴纸、场景图、配音、字幕、封面、成片和发布稿。作者希望通过一个 Skill 把最耗时的制作工作交给 Codex 或 Claude Code，自己保留选题判断、画面审查和发布决策。

先看结论：一句话出片不等于无人审核

原文所描述的交付物不是一段自动生成的视频，而是一整套发布包：

• 一条 1080p 白板风格成片；
• 横版和竖版封面；
• 五个候选标题以及各个平台的发布文案；
• 一份记录事实来源、数字口径和核对日期的资料文件；
• 一期视频的旁白、场景、贴纸、字幕和封面源文件。

可以把这条链路写成：

一句选题
  → 立题与查证
  → 旁白与分镜
  → Logo、人物和道具贴纸
  → Excalidraw 场景图
  → TTS 配音与字幕时间轴
  → 封面与品牌卡
  → 渲染、抽帧和音画验收
  → 标题、平台文案与来源说明

真正可复用的部分，是每个阶段都留下中间产物，并且把容易出错的规则写成 Skill 中的硬约束。工具可以接管重复劳动，但不能替你决定一个题目是否值得讲，也不能替你为错误的数字承担后果。

一、为什么选择白板视频

1. “还没画完”本身就是留人机制

白板视频的画面不会一开始就全部完成。一个框刚画了三条边、一行字只写到一半、箭头正准备连到下一个节点，观众会自然地等待它完成。

这是一种形式自带的悬念，不需要额外堆叠复杂转场。作者给出的实践节奏是：一条片子控制在两分钟到两分半，拆成约 6 到 8 个场景，每个场景再按旁白切成几个小段，让观众每隔几秒就看到新元素开始出现。画面长时间静止，白板视频的优势就会消失。

2. 把抽象知识变成可见结构

白板适合讲有结构的内容：

• 三栏卡片可以表示三个组成部分；
• 左右两列可以表达方案或公司对比；
• 一条时间线可以解释前因后果；
• 中心节点加若干箭头可以展示上下游关系；
• 一张参数卡可以把数字、门槛和计算口径放在一起。

当眼睛和耳朵接收到同一套结构时，观众更容易跟上抽象概念。相反，纯情绪、纯观点、没有可视化关系的主题，不一定适合白板形式。

3. 不露脸之后，统一风格就是识别度

不出镜降低了拍摄门槛，但也拿走了真人账号最直接的人设记忆点。观众需要通过手绘线条、配色、封面、片尾、角标和字幕习惯认出这是同一个账号。

因此白板账号不能只追求“每一期能生成”，还要尽早固定：

• 手绘线条和填色方式；
• 封面比例、标题位置和高亮色；
• 右上角水印或系列标签；
• 片尾品牌卡和固定口号；
• 字幕区、Logo 区和安全边界。

4. 不是所有题目都适合画

需要现场画面作为证据的突发事件、实地调查和视觉冲击型新闻，白板图可能会削弱说服力。热点题也有生命周期问题：如果从查证到制作要花时间，热点已经过去，成片的投入可能无法回收。

作者更推荐用白板讲常青型问题，例如“某个概念是什么”“为什么会发生”“一笔钱怎么算”“一个流程由哪几部分组成”。这类内容的搜索窗口更长，也更容易形成可复用的系列。

二、先做账号判断，再搭工具

工具只能解决“怎么做出来”，不能解决“为什么有人要看”。原文给出的运营判断可以整理成下面八条。

1. 先写一句定位

定位需要同时说清楚三件事：给谁看、讲什么、用什么形式讲。

例如：

给刚毕业的职场新人，每期用两分钟画清一个职场规则。

“用 AI 做知识科普”就太宽泛，观众无法判断自己为什么要关注。定位确定后，账号名、简介、封面系列标签和选题范围都应该围绕这句话收敛。

2. 一期只回答一个问题

开始写旁白前，先把最终结论写成一句话。如果一句话结论都写不出来，说明选题本身还没有想清楚。

选题可以从真实问题里找：搜索框的下拉联想、同行评论区被反复点赞的问题、用户在社群里重复询问的困惑，通常比“自己觉得有意思”的题更接近需求。

3. 开头不能是一张空白白板

白板天然从空画布开始，但平台用户可能在前两秒看到白屏就滑走。因此开场需要优先出现：

• 一个足够大的主题标题；
• 一句反差、定义或问题；
• 两三个能够说明范围的小图标或贴纸。

标题先出现，主体随后进入，观众才能在等待画面完成前知道这条视频要讲什么。

4. 数字、日期和价格先查再写

知识内容最容易在数字上失去信任。来源台账至少应记录：

字段	作用
结论或数字	具体写进旁白的内容
来源	官方文件、原始报道或公开页面
支持的句子	这条来源证明了哪句话
核对日期	什么时候确认过
口径	例如总额、估算值、税前还是税后

旁白、字幕、封面和发布文案里的数字都从同一个口径区取值。比如一个“倍数”必须同时记录计算式，否则改了旁白却忘记改封面，最终会出现前后不一致。

5. 标题一次写五个候选

原文建议每期固定生成五种标题，再放在一起比较：

1. 数字反差：小数字对大数字，后半句点破；
2. 事件或公司做主语，叠加一个反常识判断；
3. 结论先行，再补充理由；
4. 把大数字换成观众有体感的生活单位；
5. 用一个观众愿意回答的问题收尾。

主标题优先从数字反差和反常识两类中选择，提问式标题更适合放在简介末尾或评论区。

6. 同一条视频，为每个平台单独写文案

不同平台的流量来源不同：搜索流量重视关键词，社交推荐更依赖互动，长视频平台则能容纳更完整的背景和章节。因此同一条片子不应只复制一份标题和正文。

发布稿应该至少包含：

• 主标题和备用标题；
• 小红书、视频号、B 站、YouTube 等平台的独立文案；
• 评论区置顶内容；
• 数字来源和必要的免责声明；
• 需要标注的 AI 生成内容说明。

7. 置顶评论同时处理来源和互动

一个简单做法是把置顶评论分成两句：第一句解释关键数字来自哪里、是否为估算；第二句重复片尾的问题，引导读者讨论。这样既不会把来源说明写成一段生硬的免责声明，也能让评论区有明确入口。

8. 设定内容红线

原文建议：

• 公众人物只讲可核对的公开商业事实，不碰私德和八卦；
• 未核实的说法使用“据报道”“被质疑”等限定语；
• 不写“稳赚”“抄作业”“建议买入”等投资承诺；
• 对政治、宗教、民族、未决案件、灾难伤亡和未成年人内容保持谨慎；
• AI 生成的画面只能作为示意，不应冒充现场证据；
• 平台要求标注 AI 生成内容时，按平台规则如实标注。

这些不是 Excalidraw 的技术限制，而是内容发布环节的风险边界。

三、工具分工：Excalidraw 管风格，Codex 管难画的部分

这套工作流把工具分成几层：

工具	在流程中的角色	适合交给它的工作
Claude Code 或 Codex	Agent 编排层	读资料、写旁白、生成代码、调用脚本、整理发布包
Excalidraw	手绘画布与视觉语言	线条、文字、框、箭头、场景图和逐笔绘制效果
Codex 图像生成	贴纸生成层	人物、器械、道具和统一风格的透明素材
Obsidian	项目资料层	集中保存旁白、场景、贴纸、字幕、封面和来源
火山引擎 TTS	配音层	声音合成、声音复刻、逐字时间戳
Node.js、Playwright、FFmpeg	本地执行层	浏览器渲染、抽帧、混音、格式转换和清理

Excalidraw 的价值在于它提供了统一的手绘线条和场景格式。人物与复杂道具如果直接用手绘元素搭建，容易出现造型不稳定或视觉质量不足的问题，因此作者把这部分交给图像生成，再将结果处理成透明贴纸。

Obsidian 不是硬性依赖。装上 Excalidraw 插件后，每期文件夹里的场景图可以直接打开、移动元素和修改文字；不用 Obsidian，也可以用普通文件夹保存同样的文件结构。

四、七步生产流程

第一步：立题与查证

输入一句选题后，Agent 先查资料，而不是直接开始画画。来源优先级应当是：

1. 官方网站、发布会材料、财报、监管文件和原始公告；
2. 原始报道和一手采访；
3. 二手文章、评论和社交平台讨论，作为线索而不是最终证据。

关键转折至少用两个来源交叉核对。每个数字写入本期 README 或来源台账，记录出处、支持的句子和核对日期。

这一步仍然需要本人查看：选题角度是否成立，资料能否撑起两分钟，哪些结论必须降低语气，哪些部分应该删除。Agent 可以帮忙整理材料，但不应自行决定事实强度。

第二步：先写旁白，再想画什么

这是整套 Skill 的关键顺序。旁白先定稿，画面再服务于旁白，避免为了填满画面而堆无关插图。

原文把旁白放在 scenes.js 中，用竖线把文本切成一小段一小段。每段大约三四句话，对应一组场景元素；一条片子控制在 6 到 8 个场景。

写稿时要注意：

• 用口语和短句，一句话只推进一个信息点；
• 数字尽量写成适合配音的读法；
• 避免 @ 等容易被 TTS 读错的符号；
• 每一段都要有可画的内容；
• 画不出来的纯抽象句子，合并进前后有具体结构的段落；
• 结尾包含一句话总结和一个评论区问题。

一个稳定的叙事骨架是：定义或反差开场，拆解三要素或两列对比，解释做法或计算过程，给出数字和门槛，补充限制条件，最后总结并提问。

第三步：Logo、人物和道具分别处理

公司、产品和模型使用官方 Logo

讲到具体公司、产品或模型时，优先使用官方 Logo，而不是让图像模型把它们画成模糊的卡通角色。观众需要在很短时间内认出主体，官方标志通常比“画一个像某公司”的机器人更可靠。

下载或使用 Logo 前，应记录来源和许可证，尤其是准备商业发布时。Logo 的使用规范、商标边界和平台要求也要单独检查。

人物、器械和道具生成透明贴纸

Excalidraw 适合写字、画框和连接关系，但人物和复杂物件不一定适合手工绘制。一个更稳定的做法是一次生成 2×2 四宫格，再自动抠白底、去杂点、裁边，得到四张风格一致的透明贴纸。

风格提示词可以固定为以下结构，只有主体描述变化：

Excalidraw hand-drawn whiteboard sticker,
thick slightly wobbly black marker outlines,
flat pastel fills limited to pale yellow, blue, green, red and light grey,
simple readable chibi proportions,
pure white background, isolated subject, no text, no logo, no watermark,
no gradient, no shadow, no photorealism, no 3D.

主体描述只写体型、姿势、衣服颜色、表情、视角和主色，不把背景、文字、数字或 Logo 交给生图模型画。统一的颜色范围能让贴纸放回 Excalidraw 场景后不显得突兀。

如果需要表现公众人物，原文的做法是参考公开照片，只借用可识别的外形特征，画风仍然保持白板贴纸风格，不做丑化。人物贴纸建议排队生成，每张生成后立即检查，避免并行任务互相抓错最新文件。

第四步：画场景并逐张检查静帧

场景由 scenes.js 描述：一行代码负责一行文字、一个框、一张贴纸或一条箭头。作者使用 1920×1080 画布，并预留两个禁区：

• 底部字幕区；
• 右上角水印区。

如果元素压入禁区，Skill 应该发出警告；警告清零后再进入渲染。一个画面不要塞太多元素，宁可删减，也不要让笔画在同一段旁白里赶不完。

常用版式可以预先做成模板：

• 大标题加三个对比物；
• 左右两列比较；
• 三栏卡片；
• 中心节点连接三个下游；
• 清单与步骤；
• 参数、价格和门槛卡片；
• 总结页。

渲染前先输出每个小段“画完时”的静帧，逐张看：

• 元素是否互相遮挡；
• 文字是否超出画布；
• 字体宽度估算是否失准；
• 一屏是否太拥挤；
• 贴纸是否仍然透明；
• 字幕区和水印区是否干净。

静帧审查的价值在于提前发现布局问题，不必等整条视频渲染完才从头返工。

第五步：生成封面

封面函数放在 scenes.js 末尾，一次生成横版 4:3 和竖版 3:4 两张。

一个可复用的封面结构是：

• 标题最多两行，每行控制在可快速阅读的长度；
• 第一行说明对象，第二行放钩子；
• 钩子使用品牌色和马克笔高亮；
• 主角使用贴纸或官方 Logo；
• 外围保留手绘粗边框和固定品牌标识；
• 数字放在副标题，避免主标题塞入过多信息。

封面验收只需要先检查三项：标题是否撞到贴纸，高亮是否覆盖正确的钩子行，品牌标识是否保持固定位置。封面不是一张独立海报，而是系列识别系统的一部分。

第六步：配音、字幕、渲染与成片验收

作者使用火山引擎的声音复刻和原生语速参数生成配音。原文强调的是流程原则，而不是固定服务：

1. 先获得最终旁白，再生成整段音频；
2. 让 TTS 返回逐字或逐句时间戳；
3. 字幕文字使用稿件原文，时间使用真实配音时间；
4. 用 Excalidraw 场景逐笔绘制并输出视频帧；
5. 混入背景音乐并自动压低人声期间的音乐音量；
6. 加入片尾品牌卡和固定水印；
7. 通过机器检查与人工抽帧后，才进入发布环节。

字幕的基本原则是：文字来自定稿，时间来自真实音频。不要按字数平均推算时间，也不要因为 TTS 把某个符号读错，就把屏幕文字改成错误的口语结果。

画面验收重点包括：

• 视频尺寸、帧率和时长；
• 音轨是否存在、是否与画面同时结束；
• 开头、中段和结尾是否有黑帧或空白；
• 字幕是否落在安全区；
• 水印是否在固定位置；
• 贴纸是否出现白边、黑底或错误文件；
• 片尾品牌卡是否完整；
• 字幕前几条是否有错字、数字拆分或专有名词错误。

作者还提到配乐使用侧链闪避：说话时降低音乐，停顿时恢复一点，片尾再淡出。工程上最好把配乐音量、字幕字号、水印位置、语速和片尾时长都放进统一配置文件，这样调整时只需修改一个参数。

第七步：生成发布稿

发布稿和视频一起交付，而不是等发帖时临时编一段。至少包含：

• 五个候选标题；
• 主用标题和备用标题；
• 每个平台单独的正文；
• 评论区置顶内容；
• 关键数字的来源提示；
• AI 生成画面和素材来源说明。

每个数字都应该可以回溯到本期 README 的资料来源。这样发布稿不只是文案，也是发布前的事实检查清单。

五、把“修改”设计成小改动

一个 Skill 好不好用，不只看第一次能不能跑通，更要看不满意时能不能快速修正。

原文的核心做法是把每期都一样的内容写进配置文件，把每期不同的内容交给 Agent 生成：

固定配置	每期内容
画布尺寸	选题和旁白
字幕字号和安全区	场景元素
水印位置	本期贴纸
账号名和强调色	本期 Logo 与资料
配乐音量和片尾卡	标题和发布文案

例如：

• 字幕太大，只改字幕配置；
• 水印遮挡，只改水印坐标；
• 配乐太吵，只改混音参数；
• 画面拥挤，只删减当前场景元素；
• 标题不够有力，只重新生成发布稿，不必重渲染视频。

这种“固定部分配置化、变化部分数据化”的结构，比每次重新对 Agent 描述全部风格更可靠，也更容易审查和回滚。

六、推荐的项目目录

原文建议一期内容集中在一个文件夹里，知识文件和中间产物清晰分开。可以采用下面的结构：

whiteboard-video/
├── README.md          # 选题、来源、数字口径、核对日期
├── scenes.js          # 本期唯一需要手写或重点修改的源文件
├── narration.md       # 定稿旁白
├── assets/            # Logo、贴纸、截图和场景资源
├── subtitles.json     # 根据最终音频生成的字幕时间轴
├── cover-4x3.jpg      # 横版封面
├── cover-3x4.jpg      # 竖版封面
├── publish.md         # 标题、平台文案和置顶评论
└── preview/           # 静帧、样片和验收结果

大体积成片可以放在独立的输出目录，知识库里保留可阅读、可修改、可追溯的文件。

如果使用 Obsidian，可以在每期文件夹安装 Excalidraw 插件，直接打开场景图修改元素。关键不在于必须使用某个知识库软件，而在于让旁白、场景、来源和发布稿处于同一个可追溯单元中。

七、从零开始的最短成功路径

第一次不要一上来做复杂主题。可以按下面顺序跑通：

1. 先写一句账号定位；
2. 从搜索框或评论区找一个真实问题；
3. 把场景控制在 6 个以内；
4. 先完成旁白和来源台账；
5. 生成少量贴纸，逐张检查文件是否正确；
6. 逐张检查静帧，确认文字和安全区；
7. 只做一条完整成片，不追求第一期就足够漂亮；
8. 抽查开头、中间和结尾，再检查字幕和数字；
9. 发布前重新阅读内容红线和来源说明；
10. 跑通后固定字号、配色、封面和片尾，把精力转回选题。

本地环境至少需要 Agent 工具、Node.js、Playwright、FFmpeg，以及用于配音的服务账号。是否需要声音复刻取决于账号形态；第一期可以先用普通 TTS 验证流程，不必先解决所有高级能力。

八、最有价值的几条硬规则

把原文的方法压缩成工程约束，大致是下面这些：

• 先旁白，后画面；每段旁白都应该有可以画出来的内容；
• 字幕区和水印区是禁区，出现越界就停止渲染；
• 公司、产品和模型优先使用官方 Logo；人物和道具使用风格统一的贴纸；
• 数字先查再写，来源、口径和日期进入 README；
• 旁白、字幕、封面和发布文案使用同一份数字来源；
• 固定内容写进配置，Agent 只生成每期变化的内容；
• 每一期只保留一个清晰的源文件，其余由脚本生成；
• 静帧先验收，整片后再做机器检查和人工抽帧；
• 成片、封面、发布稿和来源台账一起交付。

这些规则看起来像工程洁癖，但它们解决的是最常见的返工问题：数字改了一处却漏了另一处、字幕压住水印、贴纸抓错文件、封面和正片风格不一致，以及视频完成后才发现画面根本读不完。

九、这套方法的边界

“一句话出片”容易让人误以为全流程可以无人值守。实际情况更接近：Agent 负责执行和整理，人负责选择、核对和签字。

以下内容不应直接从作者自述推导为普遍保证：

• 一条片子的固定渲染时长；
• 某个 TTS 服务的声音质量或成本；
• 某种模型在所有主题上的图像一致性；
• 某个平台的播放、涨粉或变现结果；
• 某个 Skill 在当前版本中仍然能直接运行。

还要额外注意版权和隐私：官方 Logo 有商标边界，公开人物照片涉及肖像与素材使用边界，截图可能包含账号、邮箱或内部数据，新闻画面和音乐也有各自的授权问题。来源台账能帮助你说明内容来源，但不会自动替代许可证、合理使用判断或平台审核。

写在最后：工具接管制作，选题仍然属于人

这套白板视频 Skill 最值得借鉴的地方，不是“Codex 会画图”，而是把内容生产中的判断点显式化：什么时候查资料，什么时候停下来让人看，哪些元素用官方素材，哪些元素用贴纸，数字从哪里来，字幕留出多少阅读时间，成片什么状态才算完成。

当制作被压缩成一条稳定流水线后，账号真正的竞争就会回到选题和判断：

• 能不能连续积累二三十个值得回答的问题；
• 能不能把每个问题收敛成一句明确结论；
• 能不能对标题、封面和数字亲自签字；
• 能不能在自动化之外保留必要的人类审查。

项目入口：simon-skills/skills/whiteboard-video。仓库内容、依赖版本和脚本接口可能继续变化，复现前应先查看当前 README 和实际运行结果。

原始来源与相关阅读

• 原始短帖：hanzhang415188/status/2103030353174630574
• 关联长文：2103003514033307648
• 开源 Skill：trustfuture/simon-skills/tree/master/skills/whiteboard-video
• 相关教程：用 Codex 和 HyperFrames 自动生成视频：从文章到口播、分镜与成片的完整教程
• 相关教程：Codex 自动剪辑知识类视频：从 A/B-roll 到视觉编排表的完整工作流

本文配图按公开原文顺序整理到站内，原作者观点与媒体版权归原作者及相应权利人所有。