集真实试点协议

未来应该怎样迭代？
总原则

未来不要再以“收集更多包、增加更多规则、增加更多岗位”为主线。

接下来唯一正确的迭代逻辑是：

先补真实工程漏洞，再进行生产试点，再根据重复失败迭代。

不是继续造一座更大的图书馆。

第一阶段：v0.15.1——只做工程热修，不增加创作能力

这个版本应该非常克制，只修确定性问题。

必须完成：

修复状态机跨项目和假文件绕过
强制校验运行卡版本和来源层级
把人工批准改为独立批准回执
增加依赖清单和环境Doctor
建立统一测试入口
正式验证 RELEASE_MANIFEST
将清单改名为 .sha256
生成外层ZIP哈希文件
从最终ZIP解压后运行发行测试
明确包版本与协议版本矩阵
增加缓存、临时文件和运行残留检查
增加我刚才构造的两个负面回归案例

这个版本不应该：

新增模块
新增脑洞规则
新增知识库
新增来源作者
新增更多生产路线

修完以后就停止工程层预防性扩建。

第二阶段：v0.16-PILOT——真实跑一个十集项目

现有《10集真实试点协议》方向是对的。

但试点不能只是“成功写完十集”，还要记录过程成本。

建议每集记录：

内容结果
陌生读者能否复述主因果
主角目标是否清楚
本集状态是否真实改变
钩子是不是建立在已兑现结果上
人物声口是否能区分
是否出现无来源信息、权限或能力
有没有重复上一集的施压结构
系统结果
运行了哪些岗位
每集修了几轮
哪个模块触发最多
哪些规则经常拦住正确创作
哪些规则没拦住真实问题
人工操作花了多少时间
模型调用和上下文成本
中途有多少次人为绕过系统
哪些表格基本没人愿意填

最后一项特别重要：

如果操作者经常绕过某个流程，未必是操作者不守规矩，也可能是流程本身设计错了。

第三阶段：做对照，而不是只看成品是否“还不错”

至少选3集做对照：

A版

直接由当前主力模型按正常专业提示写。

B版

完整经过该系统分岗流程。

C版

使用精简流程，只保留：

故事合同
单一主笔
连续性检查
真人盲读

让匿名读者不知道版本来源，比较：

可理解性
追读欲
人物感
情绪兑现
AI味
阅读疲劳
最想继续看的版本

如果完整版只比精简版好一点，却多耗三四倍时间，就说明系统过重。

如果完整版明显更稳定，再证明这些岗位值得保留。

第四阶段：根据失败分三类处理

未来所有问题必须先分类，不能看到失败就改核心协议。

1. 工程失败

例如：

哈希验证漏检
状态机错误放行
路径不存在仍通过
安装失败
版本错配

直接修代码和测试。

2. 路由失败

例如：

应该调用对白模块却没有调用
不该使用T2却误触发
找不到已有知识卡
阶段判断错误

修路由、触发条件和检索，不改创作理论。

3. 方法失败

例如：

正确调用后，输出仍持续因果混乱
连续多个独立案例中，同一规则稳定产生僵硬结果
某个方法在目标媒介上明显不适用

只有这类才允许修改方法正文或升级知识卡。

这个分类非常重要，否则一次模型随机失败就会引发整个系统再次膨胀。

第五阶段：v0.17才考虑证据化路由

到那时再把模块从“身份层级”升级成“任务能力档案”。

每个模块记录：

适用任务
已测试媒介
成功案例
失败案例
触发前提
平均修订轮数
人工接受率
副作用
禁止使用场景
最后验证日期

模块推荐逻辑从：

T1优先

逐渐变成：

符合硬边界
→ 任务匹配
→ 实证表现
→ 来源优先级
→ 成本与副作用

但没有真实数据之前，不要提前做复杂评分器。那只是在给猜测穿西装。

v1.0应该满足什么条件？

我认为仅跑完一个十集项目，还不足以叫生产v1.0。

比较合理的最低门槛是：

至少一个完整十集主试点
再有两个不同题材的小型保留集测试
至少两名真人盲读者
对照组证明系统相对精简流程有实际增益
关键工程绕过全部封死
全新Python环境可一键安装
最终ZIP解压复验全部通过
外层哈希、内部清单与版本矩阵齐全
Runtime包和Archive包完成分离
权利安全分享包可以自动生成
同一真实失败至少跨两个独立案例复现，才修改核心规则
记录系统带来的时间和调用成本，而不只记录质量

达到这些，再叫：

production_candidate

经过第二个真实项目验证以后，再叫正式v1.0更稳。