企业官网建设流程全解析

有了一段小说，直接让工具“生成短视频”往往会跳过很多事：角色有没有认错、场景是不是凭空补的、开头与第一镜是否重复。novel-promo-storyboard 做的是先整理文字素材：把输入拆成标题、人物卡、口播和分镜，再交给创作者核对。

这是“我的 100 个开源项目”系列。本文核验公开仓库1.0.1、MIT许可证和当前Python源码，运行自检及仓库样例构建。样例来自仓库，不是一次真实小说推广；没有生成或发布视频。

可以直接跑一个文字整理脚本

仓库提供确定性的Python构建命令，不用先接第三方模型API。克隆后在项目目录执行：

gitclone https://github.com/xxjrq/novel-promo-storyboard.gitcdnovel-promo-storyboard python3 scripts/self_test.py self-test python3 scripts/self_test.py build--inputexamples/success-input.md--output./out

本次自检通过，构建生成 promo-package.json 和 promo-package.md。内容包括三个标题候选、开场钩子、人物卡、场景卡、口播、3至5条正文分镜、结尾引导和来源说明。输出是文字文件，没有图像、配音、剪辑或渲染视频。

Agent 可以根据 Skill 继续编辑这些内容，但不能把后续创作能力算进这个Python脚本的实测结果。

先分清输入建议和脚本参数

Skill 建议准备章节或概要、平台、受众、时长与叙述方式，正文建议300至5000字。当前CLI实际只接 --input 和 --output，并没有平台、受众或目标时长参数。

源码校验正文至少30字，并含中文句号、问号或叹号；这只是基础结构检查，不能证明故事已经有完整冲突。输入太短时会输出 needs_more_source 失败结果，构建进程以退出码2结束。素材长一些，也仍可能缺人物身份和背景。

要使用自己有权使用的原文或概要。本文只拿仓库附带片段演示，不把开源代码的许可当成任意小说改编的授权。

仓库样例实际输出了什么

样例《借来的伞》讲苏棠遗留一把伞，伞柄藏着旧车票；车票日期与失踪哥哥离开的日期相同，伞主人又留下一个地址。脚本把三句素材整理成三条正文分镜，每条都有 source_anchor 可以回看原句。

本次结果中，人物卡有苏棠，场景卡只有一张。地点和时间仍写成“从原文确认的当前地点/时间”，不是自动找到咖啡馆里的准确场景时刻。人物名字依靠动作词前的中文短串匹配，也可能识别错。目标和画面描述有通用句式，不能直接当完整创作方案。

这份输出里：开场0至3秒；正文镜头依次3至7秒、7至11秒、11至16秒；结尾16至19秒。三个正文镜头共13秒，连开场和结尾才是19秒。shots 列表不包含开场与结尾，不能只读它就算整片时长。

脚本用固定时长安排，3至5条正文镜头对应整段约19至27秒；它不会按你在 Skill 请求中写的“60秒”自动扩成一分钟。

拿到分镜后，先检查四处

第一，回看来源锚点。每个画面、角色关系和台词都应能对照原文；自动说明里的未知项没有覆盖所有可能缺项，需要再读全文。

第二，核对人物和场景。短名字规则容易误识别；地点、时间占位句要换成原文可确认的信息。原文没有的内容不要悄悄补成事实。

第三，去掉重复。本次样例的开头钩子与第一条正文口播重复了同一句。可以保留一次、调整后续衔接；脚本输出不是已经打磨好的旁白。

第四，重新计时。按实际口播读一遍，检查信息量、停顿和镜头长度。固定四五秒的段落安排不等于真实朗读时长，字幕与剪辑还要继续做。

它适合放在哪一步

novel-promo-storyboard 适合在剪辑前，把短段文字整理成一份能核对的素材清单。脚本先做句子拆分与结构化，Agent 或创作者再判断故事重点、改写口播、完善画面，并检查素材使用范围。

如果想要完整视频，还需要图像或拍摄素材、配音、字幕与剪辑工具。这个仓库没有完成那些环节，也没有推广效果数据。先用仓库样例跑一遍、对照 source_anchor 和未知项，就能看清它当前适合帮到哪一步。

项目入口：https://github.com/xxjrq/novel-promo-storyboard