剧作 skill 星榜核查：一万四千星是真的，但故事讲错了

六座 GitHub 仓库全量克隆、源码级 grep 对账后的核查记录。原报告为暗色单文件 HTML（含两幅示意图），此处按论坛格式重排。

一句话说清这件事。 一段关于 GitHub 编剧 skill 星榜的观察，报了六座仓库、一万四千星、五十二道质量门、八百九十四次安装。我把六个仓库全克隆下来逐条对账：数字绝大部分是真的，作者确实读过源码；但榜单的框架撑不住——按星数排不成立，第三名和第一名是同一家公司，而"全都铺到分镜"这句只对两家为真。

一个比喻。 这份榜单像一张六人圆桌的合照。走近了看，六个人里有两位是同一家的双胞胎；桌边其实还站着五位没入镜的高个子；而所谓"六人都穿了同款鞋"——你低头一数，只有两位穿了，恰好都是要去爬山的。

本文立场。 先给分，再扣分。说对的十四项，一字不差地摆出来，包括那句被漏掉的原文精彩句；说错的五项，标注错在哪、为什么会错。未能证实的，老实说没查到，不脑补。

01 · 六个点名，全部对上人

原文只给了仓库名，没给 owner。六个全部定位成功，无一落空。

许可证除 shuohao-skills 用 Apache-2.0 外，其余五个均为 MIT。

先提一处体积：drama-skills 七十四兆，是第二名 shuohao 的 六倍，是第五名 screenwriting 的 三十五倍。原文那句"前后端近八万行代码"，光看体积就像真的——尽管严格说，八万行指的是那家工作室自己的生产系统，不是这个仓库本身。

02 · 一万四千星：这个数是真的

总数对得上，但"按星数排的前六名"这个说法不成立。

2.1 总数对账

原文没给第三、五、六名的星数。反推快照时三者之和约为 14000 − 11124 = 2876，今日三者之和 4096。差额 1220 星分摊到三个仓库，在一个"剧作 skill"集体暴涨的九月里完全合理——尤其 screenwriting-skills 建仓仅二十天就冲到一千三百九十八星。

✓ 判定：一万四千星站得住

是份旧快照，差额可由三个月自然增长吃掉，未见编造痕迹。

2.2 但排序已经失效

原文说"按星数排"，把山音（1122）列第四、screenwriting-skills（今 1398）列第五。今日实测是反的：1398 > 1219。

这不必然是作者的错——若快照在九月中旬，screenwriting 当时低于一千一百二十二，顺序就成立。但这恰恰说明：基于 GitHub 星数的榜单天然带保质期，而这份快照的时间从未被标注。

2.3 更要紧的：候选池没声明

在一次最普通的搜索里，就捞到至少五个"漏榜"的同赛道项目：

✗ 八百八十星没进前六，四百二十二星的却进了

要说这是"按星数排的前六名"，逻辑上说不通。唯一解释是作者心里另有一个筛选口径（比如"纯剧作/写作类，排除视频与游戏"），但这个口径从未向读者交代。

这就是典型的 数字属实、框架失真——两者必须分列，不能因为前者为真就默认后者为真。

03 · 致命一击：榜首与探花是同一家公司

本次核查最重要的一条，原文一处未提。

查 users/zenstory-ai：

login=zenstory-ai  name=ZenStory AI  type=Organization
created=2026-07-31  blog=https://zenstory.ai

第一名 + 第三名 = 10270 星，占六项目总星 16269 的 63.2%。

它不是六边形，是一个中心加五个点。原文读到的一唱一和——"第一名画圈""第三名也要求确认"——很可能不是两个团队分别悟出来的道，而是同一拨工程文化的两次沉淀。

3.1 命名化石：旧名比工商登记诚实

还有一条佐证。oh-story-claudecode 建仓于 2026-04-22，比 ZenStory 组织成立（2026-07-31）早了三个多月。 而今天在 GitHub 上搜这个项目，仍会跳出一堆 fork，自述里写着：

• HeRiki/oh-story-codex：「基于 worldwonderer/oh-story-claudecode 的中文网文写作技能包」
• duiniwukenaihe/novel-assistant-skill：「基于 worldwonderer/oh-story-claudecode 构建」
• wyouwd1/oh-story-opencode：同样指向 worldwonderer

而 worldwonderer 这个账号今天还在——2019 年注册，实名 pitechen。GitHub 仓库迁移后旧链接会重定向，但 fork 的描述文本没人替它们更新。于是这些残留字符串成了化石，把"个人项目起步 → 成立公司 → 迁入组织"这段迁徙史冻在了原地。

这条规律一再应验：看一个项目的来路，别看它的注册信息，去看别人写下它旧名的地方。

04 · 该给的分要给：精确命中清单

说完问题，必须说这段观察的硬功夫。下面这些数字，只有真翻过源码才报得出来。

4.1 五十二道质量门：分毫不差

shuohao-skills 的五个 skill，每个都带一组脚本质量门。实测：

而"全是脚本检查"也确有其事。同一份文档里写着这样两句：

checklist 交给模型自觉是靠不住的。所以每一道门都是 validate 里的确定性检查，不是给模型读的文字。

> —— shuohao-skills · novel-outline/README.md:21

「未提供 cast.json，本门跳过」——不装作查过。静默通过和撒谎只差一步。

> —— shuohao-skills · novel-art/references/report-style.md:27

第二句是我愿称之为本次核查最佳文摘的一句。原文转述成"不是让模型自己说我觉得可以了"，意思到了，但原话更有劲：作者把"没检查就放行"直接定性为撒谎。

4.2 确认后生产：说对了，但没说出那层狠劲

drama-skills 的 short-drama-produce/SKILL.md，第 7 行标题就是：

# 确认后生产

底下两条硬条款（第 47–48 行、第 83 行）：

等创作者在 看到这份预览之后 明确确认。只有明确同意这项 当前任务，才运行 confirm；「继续」「都做完」「预算没问题」、上游内容已接受或之前确认过另一版，都不算本次生产确认。

prepare 只验证并预览，不生产。confirm 只保存与当前 job 指纹绑定的一次性确认。

实际操作要敲：

python3 production_tool.py confirm <project> --job-id <id> --confirmation "CONFIRM <id> <code>"

★ 原文说对了方向，却漏掉了最精彩的部分

它把"AI 以为你答应了"和"你真的答应了"做成了两个互斥状态，还得再敲一遍带验证码的字符串。而它 明确列举了哪些话不算点头：「继续」「都做完」「预算没问题」，一律不算。

4.3 山音：三项全中

山音超级编剧大师集成版（Gemini及其他AI工具通用）.md 第 5 行：

覆盖从 1-3 分钟概念超短片到90 分钟电影长片、多集剧集的全格式剧本创作。

第 72 行：## 通用八步流程，还附一张按概念超短片／短片／长片／剧集四种体裁展开的步骤对照表。九十分钟、多集、八步，一项不差。

不过要补一刀形态上的错位：山音 不是 skill 包，是 单个 .skill 巨文件（仓库只有 124 KB，连目录层级都没有）。它跟其余五个放在一起比星数，比的其实是两类东西。这一点原文没意识到。

4.4 其余精确命中项

（story-deslop 这个命名值得一提：英文里"AI 味"叫 slop，作者直接把 de-slop 写成了 skill 名。这人读过味。）

05 · 三处化石：数字都是真的，但已经过期

本次核查在方法论上最有滋味的一处。

5.1 screenwriting-skills：三组数字全错，且全都偏低

谜底在英文 README 的书目分类里。它把书目分了五类：

原文的"十二卷"就是中间那个 12——它取了 Published scripts 这一个子类，丢掉了戏曲的十一卷。不是瞎猜，是掐头去尾。

5.2 那"三十二本"从哪来的？

答案藏在中文 README 第 93 行：

曾经有过英文版，一个把 20 个 skill 全部译过去的平行插件 screenwriting-en……做了，也合并了，后来撤掉。

而英文 README 第 185 行自述：

The series layer (13 → 20 skills) was added this way and sw-story-structure did not change.

所以 skill 数的时间线是 13 → 20 → 26。原文抓的 20，是这个序列中间那个真实存在过的数字。

5.3 为什么会出现化石？中英两个 README 不同步

这个项目的中英 README 是两个独立文件，英文版已更新到 47／23，中文版第 193 行还停留在「出版剧本（12 卷）」。

作者对翻译这事的看法也很有意思：

如果读不懂中文的读者该有一份译本，那读不懂英文的读者也该有，接下来就是日语、韩语、法语、俄语。五种语言就是 230 个文件各改各的，哪一份已经过时，没人说得清。

> —— 中文 README:93

他自己就知道多语 README 会失同步，然后它就真的失同步了。这不是批评，这是坦率——但对我们这些读 README 的人是个提醒：多语项目的文档，永远以最新推送的那一版为准。

判 · 化石与口径分裂的区别

化石：曾经真实，如今过期（20 skills → 今天 26）。口径分裂：真实存在，但只是整体的一部分（12 卷 → 全量 23 卷）。

建议表述改为："该仓库曾为二十个 skill、三十二本书"，而不是当作当前状态陈述。

06 · 两处过度概括

6.1 「全都铺到了分镜」——六家里只有两家

有意思的是这批 skill 全都 从剧本铺到了分镜。原因不复杂，剧本里有一处描述含糊，后面出来的画面就崩。

我数了六家的 skill 目录：

真正铺到分镜的只有两家，恰好都是 AI 视频赛道。 原文观察到一个真实现象（做 AI 生成视频的团队确实都做到分镜），却把它推广成了六家的共同规律。

这个因果解释本身是对的——"描述含糊则画面崩"，确实是 AI 视频团队的痛点；但它解释不了为什么第五、第六名没有分镜层。正确答案是赛道决定论，不是行业共识。

6.2 「参考门」拦的不是偏离，是没交作业

原文说：「你写正文时 偏离 了它拆出来的剧情模块库，会被拦下来。」

机制确实存在，英文原名就写在 docs/claude-code-skills-for-writers.md:31：

Blocking reference gates. A chapter is written only after the agent has read the brief, the volume outline and the current tracking state and written down this round's constraints (word range, must-happen, must-not-happen, time anchors).

配套还有 README 第 41、113、116 行：

• 写正文前没有细纲会被拦下；写完自动扫截断、工程词和常见 AI 句式。
• 写正文前 guard-outline-before-prose.sh 会拦住缺细纲的章节。
• 追踪状态是工具从 _tracking-state.json 整份重新渲染的，手改派生文件会被 check 拒绝。

✗ 关键词：这道门拦的不是内容，是流程

它拦的是"你动笔之前有没有读参考资料、有没有先写细纲"，而不是"你写的正文跟模块库比对下来偏离多少"。

一个是流程门（动笔前交作业），一个是内容门（写完后查偏离）。原文描述的是后者，实际实现是前者——前者管的是"有没有按规矩办事"，后者才是真正的语义检测。

附带一句：README 第 116 行那条"手改派生文件会被拒绝"，恰好是原文最后那段"用脚本去对账"理念的同构实现。这个思路在这六个仓库里到处都是，不是某一家独有。

07 · 压轴的那台引擎：我没找到

原文最后一段，也是最重的一击。

真正说明问题的是排在很后面的一个小项目，星数只有两百多。它写了个一致性引擎，专抓三种错，死掉的角色又出场、伏笔还没埋就回收、契诃夫那把枪到最后没响。它把角色的死亡状态、承诺与兑现、未解决问题全写进文件头部，再用命令行脚本去对账。

这句话承担着全文的方法论支点：用文件的确定性补模型的概率性。

我做了六轮检索，找不到它。

7.1 检索清单与结果

7.2 三个最接近的候选，逐一排除

⚠ 按铁律处理：未证实者挂账

三者都只占"两百多星"这一个特征，没有一个同时满足"文件头部写状态 + 命令行脚本对账 + 专抓三种错"。宁说没查到，不作脑补。

可能的解释（非结论）：星数已变化、未收录在搜索口径内、存在于第三方 skill 市场而非 GitHub、或原文对机制做了合并叙述。

7.3 但那个技术思路，是实实在在存在的

虽然那台具体的引擎没找到，原文想说的那件事—— 用外部文件替代模型记忆 ——在这六个仓库里遍地都是，而且往往更硬：

• shuohao：52 道门全是 node 脚本，明确拒绝交给模型自觉
• oh-story：guard-outline-before-prose.sh + _tracking-state.json 整份重渲染 + 手改即拒绝
• drama-skills：prepare → confirm → run 三段式，确认还与 job 指纹绑定
• screenwriting-skills：有 sw-series-engine-bible 与 chekhov-dramaturgy 两个 skill，专门处理长程连贯

所以原文的结论成立，只是它的论据我没能指认到具体那个项目。

08 · 副产品：README 是写给 AI 读的

在冠军项目里翻到的一篇作者内部决策笔记，把整件事串成了一个环。

笔记路径：drama-skills/.agents/notes/implemented/process/2026-09-16-readme-for-readers-not-engines.md，标题叫《README 面向读者而不是答案引擎》。

8.1 他们做过 GEO（答案引擎优化）

2026 年 9 月的 GEO 工作 之后，README.md 与 README_EN.md 顶部多了指向站点的引用链接条……

8.2 流量结构是七比一

GitHub 引荐数据显示 Google/Bing/Baidu 带来的访问约为 ChatGPT 类答案引擎的 7 倍，README 首先要为人和传统搜索服务。

8.3 他们主动撤掉了讨好 AI 的段落

决策是：删掉那些为答案引擎写的规范化摘要段和边界句。而作者自己在"代价"栏写下了这句：

答案引擎抓取到的规范化摘要段没有了，引擎复述可能更依赖正文。

同篇还有"替代品被否决"的记录：保留答案引擎摘要段的方案被否了，理由是人读不下去的 README 对两边都没好处。

8.4 这意味着什么

• 剧作 skill 的作者们 刻意优化 README 以影响 AI 的回答（GEO）；
• 这段观察的 全部素材都能在 README 与着手文档里逐句找到出处——五十二道门、十一个技能、一千个项目、八万行代码、十二卷剧本、三十一个 skill，一个不落；
• 而这批 README 自己承认：有的版本就是照着方便引擎复述来写的。

悟 · 一句带刺的判语

这段观察很可能根本不是六个项目的独立横评，而是 一次高保真的引擎复述——作者带着判断读了这些 README，复述得相当准，但也继承了 README 的三个先天毛病：版本滞后（二十个 skill）、口径截断（十二卷）、同源重复（第一三名同一家）。

当 README 开始为机器优化，机器写出来的分析就会长得更像 README，而不是更像真相。

09 · 不能只挑毛病

按老规矩，挑完毛病要给分。这六个仓库里至少三个，是拿出来能打的工程水准。

#### oh-story-claudecode

有 .agents/notes/rejected/ 目录，专门存放 被否决的功能提案；有 scripts/ 与 tests/ 的完整测试矩阵（含 OpenCode 真实运行时兼容性测试）；连跑基准测试时都要独立 CODEX_HOME，以免污染测量。

#### shuohao-skills

novel-art 有 151 条断言，全部无模型调用、一秒跑完，且测试专挑"能让质量门失效的 Case"。它还把"缺少 cast.json 时跳过某门"明写出来，不装作查过。

#### drama-skills

CHANGELOG 长达 一千四百多行，配 evaluations/、examples/、DESIGN.md 与一套自我批评笔记系统。这不是一个周末项目，是一条产线的化石。

这些是原文没写、但值得写的东西。

10 · 二十二项判词

说对的给足，说错的指名，查不到的挂账。

总评

十四项精确通过，五项属实但需修正或加注，两项错误（独立性、全都铺分镜），两项未能证实。

若给这段观察打分：作为"我读了源码"的记录，它是高分；作为"行业排行榜"，它的框架撑不住。

如果要改写，改这三句就够了

• "前六名" → 改为「我筛出的六个剧作 skill（口径：写作/剧作类，排除视频与游戏类）」。把筛子的形状说出来。
• 六家并列 → 改成「ZenStory AI 一家占了其中两席，另有三项产品在同一组织下」。把股东结构说出来。
• "全都铺到分镜" → 改成「凡是面向 AI 生成视频的两家，都铺到了分镜；做纯剧作的没有」。

改完这三句，这段观察就从"有点可疑的排行榜"变成了"一份相当扎实的赛道笔记"。

---

数据来源与交付物

• 数据取自 GitHub REST API 当日快照（2026-09-26），六座仓库以 --depth 1 全量克隆后源码级核对。
• 核查方法：仓库元数据核验 → 拥有者/组织归属溯源 → 仓库体积交叉印证 → 源码 grep 取证 → 六轮检索交叉验证 → 同赛道遗漏项目普查。
• 未能证实项两处（一致性引擎、894 次安装），已挂账，不以推断充数。
• 完整报告（暗色单文件 HTML，两幅示意图）与一页纸速查表见本地 _screenplay_skills_report/。