发布后复盘引擎

要解决什么问题

复盘环节最容易出的三类故障：数据没等够就分析、脏数据污染经验库、复盘结论写完没人读。这个技能把发布后的复盘做成一条不可协商的执行流水线：只有拿到有效 tracking 数据才进入分析，任何脏数据都无法写入触发器和校准文件，所有结论强制落到下次创作前会被读取的位置。

核心能力与工作方式

技能只接收复盘向导的委托，自身不响应用户触发词。前置阶段先做路径探测，定位 publish_log.json、权威 tracking 文件 video-performance.json（旧 tracking.json 已废弃，禁止回退）、脚本目录和校准文件；探测失败直接终止。

D 段是硬阻断的数据回收：D2 的 48 小时闸刀会拦下发布未满 48 小时的视频；D3 对 Excel 解析零容忍，脚本退出码非零、平台数据为空、播放量全零都会判定 data_status 异常并终止；D3.5 的完整性门禁在首次运行时豁免，之后要求至少一个平台播放量大于零且存在完播率；D4 只有在门禁全部通过后才写入 milestones.review_completed，并强制追加审计字段。

E 段做动态阈值诊断：阈值完全来自向导传入的 thresholds 参数，代码里没有任何硬编码。有效记录不足 3 条时保留漏斗诊断但跳过经验蒸馏；红线检查只覆盖视频号和抖音两个平台。

F 段是反馈回流，全部走原子写：publish_log.json 只允许通过 publish_log_cli.py patch 写入（结构校验 + 版本校验 + 原子写 + 备份），其余文件用 atomic_write.py。评论按痛点/质疑/补充观点分类投喂；高价值评论若视频绑定了子画像，会回写到画像库的验证记录；触发器回写后重建索引；表现评价写入 usage/YYYY-MM.md；最关键的一步是把蒸馏结论落到 review-calibration.md——这是下次创作前置扫描唯一会读的决策来源，creation-state.json 只作为历史镜像。v2.13 新增的 H 段还会读取创作 trace，渲染决策复盘卡，把「当时怎么判断的」与「实际表现如何」对齐。

适用边界

它是执行方不是调度方，不能直接被用户触发；复盘必须在发布满 48 小时后进行；依赖工作区里完整的文件结构和脚本；任何环节失败都会顶置「本次复盘无效」，并阻断全部资产写入，不存在部分成功。