背景
当前 cheat-predict 的 Phase 0 将“用户已看过发布后数据”直接视为盲预测失效，即使：
- 模型和 blind-scoring sub-agent 都没看过任何实绩；
- 用户没有向模型透露播放、点赞、评论、转发等数字或截图；
- 预测仍可以在复盘前由模型独立生成并锁定。
这会把两种不同的校准目标混在一起：
- 人机联合盲测：用户和模型都未见数据，用户可以在落盘前 review / override。
- 模型独立盲测：用户可能已见数据，但模型未见；目标是校准模型本身的预测能力。
对于创作者，“发布后绝对不能看自己后台”不太符合真实运营流程。只要能保证数据没有进入模型上下文，这类样本仍然有价值，但应与联合盲测分开标记。
当前行为
skills/cheat-predict/SKILL.md Phase 0 会询问用户是否看过后续数据；用户已看过时，strict 模式拒绝写预测，只能记为 reconstructed。
这个规则能防止用户在 Phase 2.5 / Phase 5.5 根据已知实绩修改分数、bucket 或决定是否收录预测，但同时也丢掉了合法的“模型盲、用户非盲”样本。
建议：拆分 blind status
建议至少区分三种状态：
| 状态 |
用户是否见数据 |
模型是否见数据 |
落盘前用户 review / override |
校准用途 |
joint_blind |
否 |
否 |
允许 |
人机联合校准 |
model_blind_user_seen |
是 |
否 |
禁止 |
模型独立校准 |
reconstructed |
任意 |
是 |
不适用 |
仅作复盘参考，不进盲测校准池 |
为兼容旧数据，可将当前 confirmed_no_data_seen 视为 joint_blind 的 legacy alias。
model_blind_user_seen 的工作流程
这个状态不应成为绕过 blind check 的宽松开关，而应采用更严格的落盘顺序：
- 自检主对话与 sub-agent 输入中不含该作品的任何发布后数字、评论内容、截图或榜单信息。
- 保留 blind-scoring sub-agent 隔离打分。
- 跳过 Phase 2.5 的用户裁定和 Phase 5.5 的落盘前 review。
- 模型一次性生成完整预测并立即写入 immutable 段；用户不得根据实绩修改，也不得通过“接受 / 拒绝落盘”筛选样本。
- 落盘后再向用户展示预测，之后才允许进入 retro。
- header 明确记录
Blind Status: model_blind_user_seen、User Override: prohibited 和 Review Timing: post_lock。
这样可以同时防住两种污染：
- 内容泄漏：用户把实绩透露给模型；
- 选择偏差：用户根据已知实绩，只保留“看起来准”的预测。
建议字段
可以优先做最小 schema 扩展：
blind_status: joint_blind | model_blind_user_seen | reconstructed | integrity_warning
user_seen_post_publish_data: true | false
model_seen_post_publish_data: true | false
post_publish_data_disclosed_to_model: true | false
review_timing: pre_lock | post_lock
SQL template 中 blind_status 的 CHECK constraint 也需同步扩展。
验收场景
-
用户已看数据，但未透露任何数字
允许生成 model_blind_user_seen；预测在用户 review 前已锁定。
-
用户在落盘前透露任何播放 / 点赞 / 评论等实绩
拒绝盲预测，标记 reconstructed。
-
用户已见数据，并尝试在落盘前 override 分数或 bucket
拒绝 override；不改动模型原始预测。
-
预测锁定后用户提供实绩
允许正常 retro，不降级已锁定的 model-blind 状态。
-
用户和模型都未见数据
保持现有 review / override 流程，记为 joint_blind。
为什么值得做
校准价值取决于“预测者是否见过答案”。当我们要测量的对象是模型时，用户已经看过数据并不会自动污染模型；真正需要防的是数据泄漏、用户 override 和样本选择偏差。
把这三者明确编码，比一律拒绝更符合真实创作者的发布后工作流程，也不会牺牲 blind-channel integrity。
如果维护者认可这个 threat model，我愿意继续补 PR，覆盖 cheat-predict、blind protocol、prediction anatomy、SQL schema 和相关测试。
背景
当前
cheat-predict的 Phase 0 将“用户已看过发布后数据”直接视为盲预测失效，即使：这会把两种不同的校准目标混在一起：
对于创作者，“发布后绝对不能看自己后台”不太符合真实运营流程。只要能保证数据没有进入模型上下文，这类样本仍然有价值，但应与联合盲测分开标记。
当前行为
skills/cheat-predict/SKILL.mdPhase 0 会询问用户是否看过后续数据；用户已看过时，strict 模式拒绝写预测，只能记为 reconstructed。这个规则能防止用户在 Phase 2.5 / Phase 5.5 根据已知实绩修改分数、bucket 或决定是否收录预测，但同时也丢掉了合法的“模型盲、用户非盲”样本。
建议：拆分 blind status
建议至少区分三种状态：
joint_blindmodel_blind_user_seenreconstructed为兼容旧数据，可将当前
confirmed_no_data_seen视为joint_blind的 legacy alias。model_blind_user_seen的工作流程这个状态不应成为绕过 blind check 的宽松开关，而应采用更严格的落盘顺序：
Blind Status: model_blind_user_seen、User Override: prohibited和Review Timing: post_lock。这样可以同时防住两种污染：
建议字段
可以优先做最小 schema 扩展：
SQL template 中
blind_status的 CHECK constraint 也需同步扩展。验收场景
用户已看数据，但未透露任何数字
允许生成
model_blind_user_seen；预测在用户 review 前已锁定。用户在落盘前透露任何播放 / 点赞 / 评论等实绩
拒绝盲预测，标记
reconstructed。用户已见数据，并尝试在落盘前 override 分数或 bucket
拒绝 override；不改动模型原始预测。
预测锁定后用户提供实绩
允许正常 retro，不降级已锁定的 model-blind 状态。
用户和模型都未见数据
保持现有 review / override 流程，记为
joint_blind。为什么值得做
校准价值取决于“预测者是否见过答案”。当我们要测量的对象是模型时，用户已经看过数据并不会自动污染模型；真正需要防的是数据泄漏、用户 override 和样本选择偏差。
把这三者明确编码，比一律拒绝更符合真实创作者的发布后工作流程，也不会牺牲 blind-channel integrity。
如果维护者认可这个 threat model，我愿意继续补 PR，覆盖
cheat-predict、blind protocol、prediction anatomy、SQL schema 和相关测试。