叙事漂移监测

问题：叙事漂移如何悄然发生

品牌官网、定价页、销售 deck、社交简介等叙事载体在多次迭代后，常出现与官方叙事规范（canon）不一致的情况。这种漂移可能源于文案调整、竞品动作或内部优先级变化，但缺乏系统化监控会导致以下风险：

• 关键页面与核心叙事脱节，用户看到的信息与品牌主张矛盾。
• 竞品调整定位后，团队无法快速识别是否需要跟进，盲目跟风或反应迟缓。
• 缺乏明确的再定位触发条件，决策者容易陷入「凭感觉改文案」的陷阱，甚至出现叙事反复横跳（whiplash）。

Narrative Drift Monitor 针对这些问题，通过时间维度的漂移检测，为叙事一致性提供可落地的监控与决策依据。

核心能力与工作流

1. 自漂移检测

• 加载 memory/narrative-registry/ 中的叙事规范与版本历史（只读）。
• 对每个旗舰载体（首页、定价页、商店列表等）生成当前文案快照，并通过 scripts/connectors/wayback.py 获取历史版本。
• 对比当前文案与规范中的核心元素（标语、支柱论点、声明措辞），输出 matches / drifted / contradicts 三级判定。
• 每个快照标注 Measured 及 as-of 日期，无历史记录时明确标注「no history available」，拒绝猜测。

2. 竞品再定位监控

• 复用 category-narrative-mapper 中的竞品叙事地图，对比当前竞品文案与历史版本。
• 生成再定位警报：记录竞品从何种框架转向何种框架，附带日期证据。
• 不评判竞品新声明的真实性，只标记其动作。

3. 再定位触发条件

• 定义具体信号：持续漂移信号、消息测试失败、竞品抢占唯一卖点、品类框架变化等。
• 明确反规则：无触发信号的再定位属于「叙事 whiplash」，标记为高严重性护栏。
• 触发集作为事实基础，提交给 message-system-architect 用于重新定位。

4. D1/W1/M1 消息回溯

• 在日/周/月周期对比预期叙事与实际落地效果（载体文案、共鸣信号）。
• 每条回溯线标注 Measured / User-provided / Estimated，代理数据（如 GDELT/Tavily）仅标记 proxy。
• 识别「测试失败但被重复强化」的消息，标记而非通过。

适用边界与注意事项

• 依赖现有规范：无 memory/narrative-registry/canon.md 时直接终止，要求先通过 narrative-registry 建立规范。
• 不做首次一致性检查：新载体发布前的一致性检查由 narrative-cascade-planner 负责，本技能只监控已发布内容。
• 不评判声明真伪：发现不可验证声明时，仅提交 [needs source] 标记至 memory/events/claims.ndjson，不进行仲裁。
• 数据来源约束：优先使用无密钥的 Wayback CDX 数据，封闭平台仅接受用户导出的分析数据（标注 Measured 及日期）。
• 输出即交接：生成漂移报告后，根据是否触发再定位条件，分别交接给 narrative-quality-auditor（重新审计）或 message-system-architect（重新定位）。