GitHub 趋势 · 第 96 期
从小说到成片这条链，五家开源方案各占一段
#开源横评#写小说#短剧成片#GitHub趋势
这条链子上真正被切开的地方不在写，也不在拍，在两者之间。把五家开源方案按它们各自站的位置摆好之后，一个反向的分布浮了出来：star 的 68.0% 压在成片那一端（21,955★），而那一端恰好是唯一要你自己起前端、后端、MySQL、Redis 和对象存储的一条路；写作那一端三家合计 10,340★（32.0%），安装全部是一行 npx skills add 或者下载一个可执行文件。
需要先说明口径：这五家里有一家（Toonflow-app）是上一期写过的，本期只做横向对照，不再展开。如果只算本期新核实的四家，两端比例会翻成 61.8% 对 38.2% —— 一家的 star 数就能决定哪一端看起来更重，这件事本身值得先记下。
如果你只想让 AI 帮你把一部长篇写完，装一个技能包就够了。但只要你打算把小说真的变成片子，撞上来的第一批问题全跟写作无关：分镜要不要锁定、人物的脸该怎么保持一致、道具不能在镜头之间换样。Jellyfish 把这些当成一等公民 —— 它在人物、场景、道具、服装四个维度上维护共享实体模型；代价是它不再是一个能塞进 agent 的技能包，而是一套要你自己运维的服务。
这条链上，五家各站一段
这条链子大概长这样：
script / novel ──► storyboard ──► shot prep ──► video gen ──► export
▲ ▲ ▲ ▲ ▲
three novel writers
(leftmost cell only) Jellyfish covers this whole stretch, export included
Toonflow goes novel -> animated short drama五家里有三家只做最左边一格，把小说写出来，剩下的交给别人。另外两家从剧本一路走到视频：Toonflow-app 是桌面端，走小说到动画短剧这条路；Jellyfish 走的是一条更工程化的路，从剧本输入到分镜、镜头准备、视频生成、导出。
五家横向核对：六列硬字段
下面六列全部取自本轮 GitHub API 实测（size 是仓库体量，单位 KB）：
| 仓库 | Star | 许可 | 语言 | 主安装通道 | 体量 |
|---|---|---|---|---|---|
| HBAI-Ltd/Toonflow-app | 15,560 | Apache-2.0 | TypeScript | 桌面安装包（上一期已写） | 282,777 KB |
| zenstory-ai/oh-story-claudecode | 6,844 | MIT | JavaScript | npx skills add 或插件市场 | 8,272 KB |
| Forget-C/Jellyfish | 6,395 | Apache-2.0 | Python | docker compose | 8,929 KB |
| PenglongHuang/chinese-novelist-skill | 2,914 | MIT | Python | npx skills add | 902 KB |
| Nigh/show-me-the-story | 582 | MIT | Go | Release 单文件可执行 | 8,073 KB |
许可这一列在这条链上正好沿着写作端和成片端切开：写小说那三家全是 MIT，成片两家全是 Apache-2.0。也就是说，唯一带明确专利授权条款的是成片端。要把它们嵌进自己的商业产品，Apache-2.0 多一层专利保护；反过来，MIT 更省事。五家都没有非商用限制。
再补一个归一化指标：未关闭 issue 除以 star。oh-story 是 0.16%、chinese-novelist 0.48%、show-me-the-story 0.34%；Jellyfish 0.14%、Toonflow 0.03%。绝对值都很低，说明五家都还没进入 issue 堆积的阶段 —— 这条比 star 更能说明现在有没有人在回你。
错位一：star 压在成片那一端，门槛也压在这一端
按端分组算一遍：
| 端 | 仓库数 | 合计 star | 占比 |
|---|---|---|---|
| 写作端（小说生成） | 3 | 10,340 | 32.0% |
| 成片端（短剧制作） | 2 | 21,955 | 68.0% |
| 合计 | 5 | 32,295 | 100% |
10,340 + 21,955 = 32,295，和上面的总数对得上。
两端的安装方式完全是两种量级。写作端最省事的一条是一行命令或者一个可执行文件；成片端里 Jellyfish 的 compose 一上来就要五个端口：前端 7788、后端 8000、MySQL 3306、Redis 6379、对象存储 9000。Toonflow 走的是桌面安装包，但它另有三条必填的外部模型服务（上一期已详细写过，这里不重复）。
换句话说，收藏量最多的那一段，也是你要付前置条件最多的那一段。这不是巧合 —— 视频这条链上，一致性、任务编排、素材复用这些问题本来就没办法塞进一个提示词里。
错位二：活跃度与 star 正好反过来
按最近一次提交排序，画风变了。写作端三家分别在 1 天前、3 天前、8 天前动过；成片两家分别是 19 天前和 46 天前。五家里最久没动的正是 star 第三高的 Jellyfish —— 6,395★、1,108 fork，最后一次提交停在 2026-07-30。
这条值得单独记：star 记录的是这个方向有多少人想收藏，最近一次提交才决定你今天能不能装上。选链子上的工具时，先按提交时间筛一遍，再看 star 排序。
错位三：仓库越薄，交给你签的字越少
写作端三家做的是同一件事，但仓库体量差了 9.2 倍（8,272 KB 对 902 KB），实现语言也各不相同：JavaScript、Python、Go 各一家。更值得看的是，体量和人在哪一步签字的方向反着走。
- ▪oh-story-claudecode（8,272 KB，最厚）：13 个技能 + 7 个专业 agent + 100+ 份方法论文件 + 8 个自动化 hook；写作、拆文、扫榜、去 AI 味、审查、封面各自是一个可以单独调用的动作。你想写哪一步，就调哪个技能。
- ▪chinese-novelist-skill（902 KB，最薄）：官方 README 第一句就是「写小说最难的是坚持写完」。Phase 2 确认一次规划之后进入全自动创作，每章 3000–5000 字，写完自动校验，不合格最多重写 3 轮。签字只在开头一次。
- ▪show-me-the-story（8,073 KB）：反过来把签字放在每一章。第一次运行的指南里明确要求你先用小批量、先关掉自动确认，检查语气、人物和模型行为；章节按批规划，一批 1–36 章。
薄的那家把流程压成了一条线，厚的两家把它摊成了可干预的环节。仓库厚度在这里不是功能多少的问题，是你打算插手多少次的问题。
上手：四家官方原文命令
以下命令全部逐字取自各仓库 README，未做改写。oh-story-claudecode 有两种装法：
npx skills add zenstory-ai/oh-story-claudecode -y -g
Claude Code 用户走插件市场：
claude plugin marketplace add https://github.com/zenstory-ai/oh-story-claudecode claude plugin install oh-story@oh-story-skills
chinese-novelist-skill 只有一条：
npx skills add PenglongHuang/chinese-novelist-skill
装完直接给指令（这句是 README 里的示例）：
使用 chinese-novelist 帮我写一部小说
show-me-the-story 是下载 Release 里的单文件可执行程序，然后指定数据目录：
./show-me-the-story /path/to/existing/novels
Windows 上双击运行，或在命令行里给路径：
.\show-me-the-story.exe "D:\Novels"
默认端口 48090，用环境变量 PORT 可以改。
Jellyfish 走 Docker Compose：
cp deploy/compose/.env.example deploy/compose/.env docker compose --env-file deploy/compose/.env -f deploy/compose/docker-compose.yml up --build
我的判断：适合谁 / 不适合谁 / 坑
适合谁。只想让 agent 帮你把长篇写完、而且希望中途能随时插手的，选 oh-story-claudecode（它的技能粒度最细，写作之外的扫榜、拆文、去 AI 味、封面也都在里面）。只想给一句话就等成品、不在乎中途不参与的，选 chinese-novelist-skill。想把生成过程拿在自己手里、一章一章过稿的，选 show-me-the-story —— 单文件、本地端口、数据留在自己机器上。手上已经有小说、要找一条把它推成片子的工程路径的，才去看 Jellyfish 或 Toonflow。
不适合谁。想零运维把小说拍成片子的，这一族暂时没有答案 —— 成片端的两个选择，一个要自建整套服务，一个要装桌面端再配三条外部模型服务。另外，写作端这三家都不带模型：两家技能包靠你已有的 agent，show-me-the-story 要你自己填一个 OpenAI 兼容接口。指望自带模型、离线出稿的，这五家都不满足。
坑。
1. oh-story-claudecode 的 README 自己点名：agy 1.1.22 -p 暂不在支持面内（会在鉴权完成前扫 workspace，导致 skill 回退、subagent not found）。它的去 AI 味模块里写明本地检查只是写作 lint，外部检测服务只作自测参考，并且明确不承诺通过任何 AI 检测。
2. 它的文件不只在项目里 —— OpenClaw / Reasonix / 通用路径的 skill 副本在项目 skills/ 下，重跑 /story-setup 清不掉，要手动删；Windows 上 git 要开 core.symlinks=true，否则会看到 ENOENT ... mkdir 报错却仍显示 Done!，那是技能没装全。
3. chinese-novelist-skill 每章 3000–5000 字、最高 3 轮自动重写，意味着一次出全本是几百次连续调用，跑之前先把额度想清楚。
4. show-me-the-story 只打开 v4 项目格式，不能手改格式号；API Key 明文存在 api.json；Windows 上未签名，会提示未知发布者。它的回滚日志那一节特意说明：不是版本历史、也不能替代定期备份，并且不要用多个写入端同时打开同一个项目。
5. Jellyfish 停更 46 天、未关 issue 只有 9 条，社区验证量还很少 —— 想上生产的话，先把它当一套可读可改的脚手架，而不是成熟产品。
数据来源：GitHub REST API 实测 + 各仓库 README 原文 · 抓取时间：2026-09-14 · 期号：第 96 期
zenstory-ai/oh-story-claudecode — 6,844★ / 977 fork / 11 未关 issue / 8,272 KB / MIT / JavaScript / main / 最近提交 2026-09-13 / 创建 2026-04-22 / README 标注最新版本 v0.7.10（2026-09-09）
Forget-C/Jellyfish — 6,395★ / 1,108 fork / 9 未关 issue / 8,929 KB / Apache-2.0 / Python / main / 最近提交 2026-07-30 / 创建 2026-03-06
PenglongHuang/chinese-novelist-skill — 2,914★ / 429 fork / 14 未关 issue / 902 KB / MIT / Python / master / 最近提交 2026-09-06 / 创建 2026-01-25
Nigh/show-me-the-story — 582★ / 69 fork / 2 未关 issue / 8,073 KB / MIT / Go / main / 最近提交 2026-09-11 / 创建 2026-06-03
HBAI-Ltd/Toonflow-app — 15,560★ / 2,795 fork / 5 未关 issue / 282,777 KB / Apache-2.0 / TypeScript / master / 最近提交 2026-08-26 / 创建 2026-01-29（上一期已写，本期仅作对照）
选题依据：本轮全语言三榜（日 20 / 周 25 / 月 18）机械去重后零可用新面孔，仅剩合规排除项与离题项；因选题范围限定在数字人 / 短视频 / 克隆语音 / 写文章 / 写剧本 / 漫剧 / 写小说 / 写歌词 / 写诗歌 / 本地模型十个方向，改用方向检索（带 created:>2026-01-01 时间过滤）补覆盖。方向检索拿不到周期内新增 star，故以总 star 加最近提交时间作为替代判据。
未纳入核实范围：五家调用的第三方模型服务与权重各自独立于代码许可（例如 Jellyfish 的图像与视频模型、Toonflow 的三条外部服务），本文一律未下结论。
你更愿意让哪一段自动化？一句话写完就等成片，还是宁可一章一章过稿？欢迎在评论区聊聊。
下期：写歌 / 写词 / 写诗这一族，或者出现高动量干净新面孔就回到单项目精读。（上上期预告的开源替代 SaaS 合集不在给定的十个方向内，继续欠着。）
#开源横评#从小说到成片