所以不是“9.8 的商业神器”，也绝对不是普通 8 分 ...

所以不是“9.8 的商业神器”，也绝对不是普通 8 分 Skill。

现在真实定位：一个 9 分上下、已经有操作系统雏形的 IP 创作生产系统，但还有几处底层工程问题阻止它封神。

我认为最强的地方

第一，是它已经解决了很多创作 Skill 最恶心的问题：

“模型把自己刚编的东西当成用户设定。”

这里用：

confirmed / candidate / open_question

再配：

Change Impact → explicit_user_confirmation → SHA → settlement

这个思路非常正确。

尤其：

draft → reviewed → approved → final

之后还不是直接污染长期状态，而是：

Final → proposed settlement → 用户确认 → applied → ProjectState

这个设计真的值钱。

它让“写完一章”与“这章新产生的事实进入宇宙 Canon”变成两件不同的事。

很多所谓小说 Skill 根本没有这个意识。

第二个特别好的，是 Information Permission。

作者知道真相，不代表：

角色知道；
读者应该知道；
叙述者现在可以说。

把：

Truth / Character Knowledge / Reader Release

分开，能直接防掉大量悬疑、权谋、智斗、反转类长篇后期的“角色突然开天眼”。

这一层我基本不建议动。

第三，是 4.3.4 新加的拆书防污染。

它没有做最危险的事情：

“26 篇拆书都出现了某结构，所以爆款就必须这么写。”

而是把它降格成：

这个分析维度在样本中反复出现。

然后进一步区分：

“模板分析师爱写这个字段”

和

“原作品真的具有这个故事机制”

和

“这个机制真的能提升商业数据”。

这是三个完全不同的问题。

这一层已经很接近正确的研究方法。

第四，商业大方向没有跑偏。

2026 年番茄官方确实在持续强化“作品→版权/IP→短剧等改编”路径，包括番茄小说与短剧版权中心的短剧向 IP 联合征文，以及改编向中篇 IP 扶持计划。

而且截至 2026 年 8 月 17 日，番茄作家专区还在持续更新短故事课程、低质治理、短故事专项活动等内容，所以你这里专门设计 Dynamic Platform Intelligence Gateway 是对的——平台信息确实变化得很快，不应该永久写死。

但是，我打出来了 5 个真问题

这几个不是“可以更优雅”。

是真正应该修的。

P0-1：项目搬家后，运行时会坏

这是我实际复现出来的。

Finalisation 过程中，chapter_status.json 会记录：

reviewed_file
approved_file
final_file
contract_file
settlement_file

但目前存的是绝对路径。

我完整跑通 CH001 后，把整个小说工程复制到另一个目录，然后把原目录删除。

再跑 Handoff。

直接报：

BLOCK-FINALISATION: final chapter integrity failure

原因非常明确：

它还在找原来的：

/tmp/旧项目路径/.../CH001.md

而不是当前工程里的文件。

这对真正的长期小说项目非常危险。

用户以后：

换电脑；
改文件夹名；
从 D 盘搬 E 盘；
ZIP 备份恢复；
Git clone；
云盘同步；
交给另一个 Agent；

都有可能炸。

正确修法

所有项目内部引用必须改成：

project-relative path

例如：

07_正文/final/CH001.md

运行时再：

root / relative_path

恢复成当前绝对路径。

并增加一个真正的 release regression：

创建项目 → 跑完一章 → 整个项目 relocate → 删除旧目录 → validate/final/handoff/context 全跑一遍

这应该变成发布硬 Gate。

这是目前我认为第一优先级的问题。

P0-2：Settlement 的 Change Impact 校验存在一个真实洞

这个问题更隐蔽。

正常 change_impact.verify_file() 是支持校验：

target_section
current_version
proposed_value

的。

所以旧批准不能随便复用。

我故意造了一个 approved Change Impact：

原来基于 version 0。

然后把目标 state 改到了 version 7，并且准备应用完全不同的 proposed value。

正常完整校验会正确报：

stale_review_version
+
proposed_value_mismatch

很好。

但是——

Finalisation 在 apply Settlement 时，只调用：

“这个 review 是不是 approved，而且 section 对不对？”

没有把当前 version 和实际 proposed mutation 一起交给验证器。

所以我又实测了一次。

结果：

完整验证：FAIL，正确挡住。

Settlement 当前调用方式：PASS。

也就是说，理论上一个旧的、已经过时的 Change Impact Review，可以在某些 Settlement 场景被拿来给新的修改背书。

必须修成

每个 requires_change_impact 至少绑定：

target section；
base_version；
proposed mutation canonical hash；
review SHA；
impact_id；
mutation ID。

真正 apply 时重新对：

current ProjectState version + 当前 mutation payload

做校验。

不是只验证：

“以前确实有人批准过改 characters。”

这个问题修掉，Canon 防污染才算彻底闭合。

P0-3：方法卡真实自然语言召回还不够强

这个我也不是凭感觉。

它现在的 select_cards.py 本质是中文 2/3/4-gram + 英文 token overlap。

自己那 123 个 contract 测试，大量属于：

原 trigger；
card 名；
一个完全无关 boundary 词。

所以测试很稳定，但有点“考试题已经见过”。

我额外自己写了 16 个更像真人会说的话。

预期卡命中 12/16。

漏掉了这类：

“这一场看完什么都没发生，人物关系和局势都没变。”

没有召回 NARRATIVE_VALUE。

“每章结尾都很钩，但中间没有持续让我想看下去。”

没有召回 HOOK_CHAIN。

“很多段删掉也不影响剧情，像在灌水。”

没有召回 LOW_QUALITY。

“这个金手指第一次很爽，但后面只能重复升级数值。”

没有召回 SETTING_REUSE。

反过来有些查询还会多召回无关卡。

所以现在是：

路由架构 9.4，底层候选召回器大约 8 分。

最值得的升级方式

不要直接堆 500 个关键词。

给每张方法卡增加：

semantic_examples_positive
semantic_examples_hard_negative
symptom_aliases
confusable_with
disambiguation_signal

然后测试不再用原 trigger。

每张卡做至少：

8 个自然改写；
5 个近邻混淆；
5 个反例；
3 个口语/残句；
2 个多问题混合场景。

41 张卡下来就是一套真正的 routing gold set。

然后才算“实战触发验收”。

P0-4：Handoff 文档设计和真正运行时没有完全对上

你的 templates/session-handoff.md 明确有：

“关键人物状态”

Serial Runtime 文档也明确要求 Handoff 保存：

关键人物状态。

但是现在 runtime/handoff.py 真正生成出来的 Handoff 只有：

needs_review
Reader Promise
禁止提前释放
下一章目标
已知问题
作者裁决

没有关键人物状态。

我跑出来的真实 Handoff 就是这样。

这是一个标准的：

规范正确，Runtime 少实现了一项。

应该直接从当前 applied Settlement + ProjectState 中提炼：

本章变化过的核心人物
+
下一章 Contract 涉及的人物

各保留最小状态。

例如：

林默｜位置：仓库外｜掌握：K001｜目标：追回账本｜暴露状态：对手已察觉

不要手工让用户再输。

P0-5：ProjectState 长期会越来越胖，而 Context Compiler 的裁剪方式不够可靠

这是长期 100 章、300 章之后才容易爆的问题。

Settlement 当前不断往：

characters
relationships
knowledge_permissions
resources
timeline
promises
……

里面 append 历史记录。

这是账本思路，本身没错。

问题在于 Context Compiler 对 ProjectState 是：

取最后约 9000 字符。

不是：

“按本章相关实体读取当前有效状态”。

这意味着项目足够长以后：

ProjectState 可能几十万字符；
characters 又处在 sections 前半段；
尾部 9000 字符可能根本没有人物当前状态。

更麻烦的是 Settlement 并不会自动把人物的最新状态同步进人物实体文件。

于是可能出现：

人物实体文件是旧状态

ProjectState 最新人物状态被 tail clip 掉

= 下一章上下文没拿到关键状态。

正确架构

不要让 ProjectState 同时承担：

“当前状态”

和

“完整历史账”。

拆成：

Current State

character_id → current state
relationship_id → current state
prop_id → current state

以及：

State Ledger

append-only event history

Settlement 做：

append ledger + materialize current view

Context Compiler 永远读：

当前章节涉及实体的 Current State

历史只有需要追溯时才调 Ledger。

这一下会把长期可扩展性明显提升。

另外几个 P1，我也建议修

一个很小但能看出静态 QA 还有空间的问题：SKILL.md 里 BLOCK-PROMISE-DEBT 写了两遍。功能不受影响，但应该增加 semantic duplicate lint。

还有一个外发风险：虽然 4.3.4 确实没有保存拆书正文，但 deconstruction_corpus_registry.json 目前保留了源文件 display_name、作品名、SHA，以及 source_archive 信息。

例如它实际上能看到具体拆书作品标题。

所以：

内部母包没问题。

如果以后要公开/给客户：

建议生成 external registry：

S001 / female / docx / template-family-X

不保存原始文件名和源 archive 名。

内部再单独保存 provenance mapping。

这样才是真正 metadata 最小暴露。

还有一点：根 SKILL.md 已经大约 48KB / 1044 行，Fanqie 子 Skill 又约 38KB。

架构很强，但现在开始接近“规则太多，本身成为执行噪声”的临界线了。

我不会建议删能力。

我建议进一步把根 Skill 收缩成：

Authority → Router → Stage graph → Blockers → Output contract

具体执行全部继续放 reference。

也就是说：

功能不减，常驻认知负担减。

现在最不该做的是继续往根 SKILL.md 里加第 42、43、44 套系统。

“商业闭环”到底是不是真的闭环？

这里我要给一个比较准确的判断：

工程闭环：已经基本成立。

商业实证闭环：还没有完全成立。

现在已经有：

版本冻结
→ 真实数据记录
→ 指标定义
→ 同口径比较
→ Observation/Correlation/Causal 分级
→ Confounder
→ Claim Gate
→ 最小改版
→ 人工批准
→ 重新发布
→ 再观察

这个逻辑非常正确。

甚至比很多所谓“数据驱动写作系统”靠谱得多，因为它明确知道：

改了标题然后数据涨了 ≠ 标题导致数据涨了。

这点很好。

但它自己的 MATERIALS-NEEDED.md 其实也很诚实：

现在缺的正是真实作品长期数据。

所以不能因为 500 多条 Python assertions 全绿，就说：

这套系统已经证明能提高番茄完读率、签约率、稿费或版权转化。

不能这么说。

那些测试证明的是：

规则没有互相打架，状态机大体按照设计运行。

不是：

写出来的东西商业上一定赢。

这两个必须分开。

我会怎么做 v4.4

如果这是我现在负责封版，我不会再加大功能。

v4.4 我就干六件事：

RELATIVE-PATH RUNTIME：根治工程搬家。
SETTLEMENT IMPACT BINDING：Change Impact 强绑定当前 version + mutation hash。
SEMANTIC ROUTING GOLDSET：真人口语路由回归，而不是 trigger 自测。
MATERIALIZED CURRENT STATE：当前状态与历史 Ledger 分离。
AUTO-HANDOFF STATE EXTRACTION：自动带关键人物状态。
REAL-SCENARIO REGRESSION：不再只测程序，开始测“完整创作任务”。

最后这个尤其重要。

我建议建立约 30–50 个完整黄金场景：

新建男频短篇；
新建女频短篇；
长篇开书；
旧稿导入；
第 37 章续写；
角色突然降智；
伏笔提前泄露；
章末重复；
标题承诺不兑现；
人物工具化；
需要改已确认人物关系；
后台数据涨了但多个变量同时改变；
拆书模板出现高频字段；
小说转短剧；
等等。

每个案例不只检查“有没有选到卡”，而检查：

触发正确 → 没越权 → 用对上下文 → 给出正确修复 → 没污染 Canon → 输出满足任务。

这才是下一阶段真正值钱的测试。

所以最后的判定我给得很明确：

v4.3.4 已经是“能正式进入实战”的版本。不是试验品。

但是我目前不会给它盖“终极最终版”。

因为我实际已经打出了两个明确的底层工程缺陷：

项目搬家失效和Settlement Change Impact 绑定不够严；

再加上一个真实性能问题：

自然语言方法卡召回还有约一档提升空间。

把这几处修完之后，不需要再堆几十个模块。

那时候它反而会从现在这种：

“极其完整的 8.9 分系统”

变成：

“底层非常稳、功能又完整的 9.4–9.6 分生产系统”。

真正往 9.7+ 走，靠的已经不是继续写规则，而是拿一批真实番茄作品和后台数据把它锤几轮。