Ivor-NCUT 课程内容审美对齐
只管理反馈学习与安全演化，不代替逐字稿写作或课程审校。
先区分两个信号
- 作品满意：当前版本已经可以使用。
- 规则可沉淀：这次反馈体现跨任务稳定偏好，未来也应改变输出。
用户说“这版可以”时可以记录作品满意，但不得直接修改任何主 SKILL.md。若用户只要求改当前稿，完成当前修改即可；在写入偏好档案或迭代 Skill 前，确认用户是否要启动内容审美对齐流程。
项目偏好目录
默认把偏好保存在当前课程项目，不把客户或单项目审美写进通用仓库：
.course-producer/preferences/
├── learning-log.md
├── customer-preference.md
├── examples/
│ ├── positive.md
│ ├── negative.md
│ └── edit-traces.md
└── eval/
├── test-prompts.json
├── preference-pairs.json
└── judge-rubric.md
缺少目录时从 assets/preference-profile/ 复制模板。原稿、反馈原话、用户改后稿或选择结果至少保留两者；只有含糊反馈时只写 learning log。
提取候选偏好
每条偏好必须可验证，并记录：
preference_id与具体生成指令；status:candidate、validated、rejected、deprecated；confidence:low、medium、high；- 适用与不适用场景；
- 正向证据、反向证据和可能误判；
- 对生成与审校的实际影响；
- 最近验证日期。
“自然一点”“不要 AI 味”“更高级”不能直接成为偏好。把它落到可观察差异，例如“连续解释一个动作时保留 2–5 个短句的自然句群，避免一行一句”。证据不足则保持 candidate。
验证门
偏好进入 validated 必须同时满足：
- 至少两条来自不同内容样本的正向证据；或一条带完整原稿→用户改稿的强证据，加一条用户明确原话/选择；
- 能解释至少一个历史满意样本，并避开至少一个反例；
- 不与既有 validated 偏好冲突；有冲突时写清场景边界；
- 能转成明确生成指令或 Judge 判断项；
- 不是一次性选题、平台活动、事实修正或临时情绪；
- 回测没有明显破坏课程任务完成度、事实保真与其他内容类型。
同一次生成过程的自评分不能算用户证据，也不能由它自己宣布进化成功。没有独立用户选择或历史反馈时，只能形成候选。
三类评测
- 单次满意：只验证当前作品可用，默认写 learning log 与正例，不单独验证长期规则。
- A/B 选择：记录相同任务下用户选中的版本、被拒版本与具体理由，形成 preference pair。
- 跨样本稳定修改：在至少两个不同主题/章节上应用候选偏好，用 judge rubric 检查审美一致性、反例避让、任务完成度和事实边界。
更新顺序
按证据强度依次选择写入位置：learning log → customer preference candidate → examples / preference pairs → judge rubric → 主 Skill。只有 validated 且确实需要改变通用生成行为时，才提出 Skill 更新；用户明确要求沉淀到 Skill 后，调用仓库既有的 Skill 迭代工作流并保留 git diff 与回滚点。
每次学习输出本轮满意信号、候选偏好、证据、置信度、更新文件、回测结果和下次需要验证的样本。