它真正做得好的地方

它真正做得好的地方

最强的一层，是00_运行系统里的治理逻辑。

它明确提出“一个正文只有一个主笔”“创作器不能自己审核自己通过”“政策数据不能常驻创作上下文”“每轮只选一个方法、一个模式”“审核只出问题单，退回原主笔修改”。这些不是花架子，确实击中了多 Skill 系统最容易犯的病：多个作者轮流改稿、每个人都往里塞自己的方法，最后剧本没人负责，逻辑和声口全部漂掉。

故事事实与因果合同也有价值。它不仅登记人物目标，还登记证据等级、权限来源、人物什么时候知道什么、爽点有没有真实改变局势。这一套尤其适合系统、重生、身份反转、末世据点、隐藏证据之类短剧，能够防止“主角突然获得最高权限”“角色突然知道秘密”“一条可疑线索直接把大反派判死刑”这种 AI 常见硬伤。

Q1连续性机械检查 → Q2真人盲读 → 必要时R1专项审核的顺序也对。很多系统上来就评节奏、爽点、金句，却没先确认普通观众能不能看懂，这套系统至少知道：逻辑和可理解性是地板，爽点是在地板之上加速，不是拿爽点掩盖地板塌了。

所以它不是没水平。准确说，它像一个不错的制片管理层和编剧室章程，问题是下面雇来的几个编剧还拿着各自的旧手册，根本没统一。

最大的致命 Bug：上层宣布废除，底层继续执行

在00_迭代总方案与不可突破边界.md里，系统明确废止了：

冲突烈度 > 逻辑严密
情绪冲击 > 信息完整

也明确反对把“500—700字、固定卡点、矛盾前置不铺垫”作为所有项目的默认规则。

但在M01_商业爽剧写作/03_增强版/module/SKILL.md和它的references/script-workflow.md里，依然写着：

冲突烈度 > 逻辑严密
情绪冲击 > 信息完整
矛盾前置，不铺垫
单集500—700字
每8—10集一个付费卡点

这不是轻微措辞冲突，而是发动机和交通法规相反。上层要求“必要信息不能缺”，底层却会主动把铺垫判成拖沓；上层要求按媒介决定体量，底层却会强行压到固定字数；上层说不能自己审核自己通过，底层又设置“八分质量闸”，由创作器自己打分，低于8分自己改，达到8分自己放行。

真实运行结果会是：同一个任务，有时模型遵守系统宪法，写得连贯但没那么暴躁；有时被底层 Skill 拉走，开始前三秒羞辱、十句以内打脸、身份反转、卡点截断。最终风格和质量不稳定。

修法不是再加一条“请优先遵守上层规则”，那样没用。必须在00_运行系统增加一份机器可识别的优先级合同：

SYSTEM_CONSTITUTION
> ROUTE_ADAPTER
> METHOD_ARTIFACT
> OUTPUT_TEMPLATE
> REFERENCE_MATERIAL

任何方法模块进入运行前，必须经过ROUTE_ADAPTER裁剪。发现模块内部存在与宪法冲突的条款，就不能整份加载，只提取批准过的能力片段。

M01增强版目前应该直接标记为：

runtime_status: QUARANTINED
reason:
  - conflicts_with_system_constitution
  - embeds_time_sensitive_policy
  - self_approval_gate
  - fixed_format_overgeneralization

不是删除，而是拆成“爽点与冲突技法库”“短剧节奏候选规则”“合规研究材料”三个部分，不能再整包当主笔运行。

第二个大问题：它是一套管理说明，不是一套可执行系统

外层定义了G0、G1、C0、W1、Q1、Q2、R1、L1、F1、A1、S1、Q3十几个工作站，但真正提供的只是一些空白 Markdown/YAML 模板，没有验证器、状态机、调度入口，也没有完成条件的机械判断。

例如单任务运行卡里有：

one_method_only:
one_mode_only:
no_self_review:
no_auto_handoff:

但这些字段全靠人手填。即使同时加载了三个方法，系统也不会真的报错；即使主笔越权改了锁定事实，也没有diff检查；即使场景连续性台账漏掉关键字段，也没有 schema 阻止它进入下一站。

因此它现在更准确的名字应该是：

短剧剧本分岗运行规范与方法资料库

而不是完整“系统”。

要真正成为系统，至少要补四样东西。

第一，增加module_registry.yaml，把每一个模块真实登记到路径，而不是只写抽象ID。现在文档里写着WRITE-READABLE-v4、REVIEW-CAUSAL、WRITE-SCREEN-PRO，但实际文件的frontmatter名字分别是tomato-novel-body-writing、wired-for-story-methodology、screenwriting-master，没有一份正式映射。操作者根本无法稳定知道哪个ID对应哪个文件。

第二，增加 JSON Schema 或 YAML Schema，机械验证项目卡、故事合同、运行卡、问题单。关键字段为空时直接阻塞，而不是允许模型继续脑补。

第三，增加handoff_manifest，每轮只把批准内容交给下一站：

from_stage: C0
to_stage: W1
approved_artifacts:
  - story_contract_v1.2
  - continuity_ledger_v1.0
excluded_artifacts:
  - raw_method_notes
  - rejected_branches
  - policy_research
locked_hashes: []

第四，增加真正的状态机。当前阶段没有通过exit_gate，下一站不得启动；不是靠提醒模型“请不要跳步”。

第三个问题：资料库分类严重错位

M02_可读正文与审核/01_正文写作.md表面放在“可读正文”下面，实际是一个番茄网文正文 Skill，里面写的是10万字长篇、黄金三章、章节钩子、番茄算法、标题公式、对话流比例，并不是短剧剧本主笔。

它里面还有大量未经证据链支持的数字，比如：

“基于440本番茄爆款”
“2026年算法验证，追读率+47%”
“前三行无钩子则80%划走”
“悬疑灵异+194%”
“长篇顶流304本”

这些数字可能来自某些内部统计，也可能只是蒸馏过程中的二手陈述，但包里没有数据集、计算方法、样本名单或报告哈希。把它们写成确定事实，会让模型产生虚假的权威感。

这个文件还存在明显清洁问题：开头出现> 。核心目标的残句，末尾多出一个孤立的#。这说明它没有经过最基本的 Markdown lint。

正确做法是把它移到：

RESEARCH_ONLY/
└─ WEB_NOVEL/

并明确：

applicable_medium:
  - web_novel
forbidden_medium:
  - screenplay
  - vertical_short_drama
  - storyboard
evidence_status: unverified_claims_present

它可以给短剧主笔提供“期待感、爽点、信息释放”的窄技法，但绝不能整份充当短剧正文发动机。

02_网文写作说明.md也是同样的问题。它是网文方法，不是短剧剧本方法。现在这种目录摆法很容易诱导操作者把小说写法直接灌进剧本。

第四个问题：原始资料压倒了真正系统

整个压缩包约21.24MB，其中03_网文知识资料.rar约21.01MB，占约98.9%。

这个 RAR 里有519个条目，包括308个DOCX、106个XLSX、53个旧DOC、榜单数据、写作教程、拆书材料、设定素材和重复文件。也就是说，这个包九成九的体积，不是运行系统，而是一座未经治理的原始资料仓库。

它带来四个问题：

一是没有检索索引。系统强调“不得把整个资料库放进上下文”，但没有提供“根据当前任务应取哪三张知识卡”的检索机制，结果只能靠人翻文件。

二是重复和过期数据很多。比如榜单按2026年7月7日、9日、13日分目录，短时间数据很快失效。

三是许可证不完整。包里只为M03和M04保留了许可证，而这个大型网文资料库包含大量第三方文章、DOC/DOCX和榜单文件，没有逐项来源、许可状态、可否再分发的说明。

四是供应链风险。大量旧DOC、DOCX、XLSX嵌在RAR里，即使不运行宏，也不应该直接放进正式生产包。

正确处理方式是：把整个RAR移出运行包，放进独立SOURCE_VAULT；从中蒸馏出少量经过审阅的知识卡，每张卡必须带来源范围、适用边界、证据等级和禁止外推项。生产包只保留蒸馏结果，不携带519份原始材料。

第五个问题：审核器太大，必然越权

AI短剧综合审核Skill/SKILL.md本身写得不差，能区分负面行为的出现和作品是否认同负面行为，也知道不能把扇耳光、下跪、羞辱自动当爽点。这部分判断水平在线。

但它同时覆盖合规、剧情逻辑、节奏、人物、爽点、商业、制作、台词，又提供快速审核、完整审核、合规审核、商业审核、逐集审核、台词审核六种模式。完整报告足足十四大部分，还要给“最小改动版、强化商业版、结构重构版”三条路径。

这和外层的“R1一次只审一个明确问题域”直接冲突。即便它声称不重写，长报告本身也会制造大量假问题，最后逼着主笔全盘改稿。

建议保留这个模块，但生产时禁用FULL_REVIEW。默认必须显式传入：

single_review_mode: DIALOGUE_REVIEW
reviewed_scope: EP03_SC02-EP03_SC05
max_issues: 5
allowed_issue_types:
  - dialogue
forbidden_issue_types:
  - plot_reconstruction
  - new_character
  - new_twist

它的输出也不应该再用十四章大报告，而是直接转换成系统已有的连续性与审核问题单格式。严重问题最多3—5个，按证据排序，别让审核器为了显得专业硬凑几十条。

第六个问题：所谓“真人盲读”没有可执行方案

Q2要求至少两名真人盲读者，这是正确的质量思想，但当前系统没有解决现实问题：操作者没有两名读者时怎么办？让同一个AI模拟两个真人，不叫真人盲读，只是同模型换两个口吻。

应该建立三级制度：

Q2-HUMAN：真实的两名独立读者，最高可信。
Q2-MODEL-BLIND：新上下文、只给匿名正文，不得冒充真人，作为低成本预筛。
Q2-PANEL：不同模型或不同供应商独立盲读，作为中等可信替代。

锁稿规则也要区分。模型盲读通过，只能进入“候选锁稿”，不能冒充真人验证通过。

第七个问题：长篇短剧缺少“分集级控制层”

现在有故事合同和场景台账，但中间缺了一个关键层：分集合同。

50—100集项目不能直接从全剧合同跳到每场戏，否则主笔很容易出现前十集疯狂推进、中段重复打脸、后段临时加反派。至少要新增：

episode_id:
episode_goal:
entry_state:
audience_known_information:
character_known_information:
main_obstacle:
protagonist_strategy:
payoff_promised:
payoff_delivered:
state_change:
new_question:
hook_type:
hook_depends_on_delivered_result:
carry_to_next_episode:
forbidden_repetition:

还需要四本账：

人物声口账：每个人常用策略、句长、回避方式、禁用表达。
信息揭示账：观众、主角、对手分别何时知道什么。
爽点兑现账：同一种打脸或身份碾压不能连续复用。
对手升级账：对手不能只换名字，必须升级资源、策略或制度力量。

这四样补上，系统才有资格处理几十集，而不是只擅长写一集样稿。

文件级修正顺序

第一轮不要再扩能力，只做止血。

先修改00_迭代总方案与不可突破边界.md，加入明确的规则优先级和冲突裁决机制；再修改03_模块接入矩阵与调用规则.md，建立真实模块路径、版本、哈希、允许模式和隔离状态；随后把M01增强版、综合候选工作包和两个网文模块全部标记为隔离或研究材料。

第二轮做运行化。

补module_registry.yaml、route_adapter.md、episode_contract.yaml、character_voice_ledger.yaml、revelation_ledger.yaml、handoff_manifest.yaml、lockfile.json和retest_report.yaml。同时给现有模板增加必填字段、字段类型和进入下一阶段的机械条件。

第三轮才做试点。

用一个全新10集项目，不要一上来跑80集。故意植入五类错误：角色知道不该知道的信息、证据等级跳跃、权限无来源、场景因果断裂、爽点没有改变局势。先看Q1能不能全部抓到，再看W1修稿是否破坏已通过项。之后做两轮独立盲读和一次窄域台词审核。

通过这三轮后，它才适合升到v1.0。预计修完静态冲突和运行层，整体能到 7.5—8.0分；再经过真实项目闭环、建立金例和回归测试，才可能稳定到 8.3分以上。

所以我的最终判断很直接：**保留外层架构，别推倒重做；底层模块必须大清洗，尤其是M01增强版、网文正文模块、综合审核器和原始资料RAR。**现在直接拿去写，强操作员可以勉强控制住，普通用户大概率会被那些互相矛盾的旧规则带偏。