video-data-tracker — 双平台数据燃料供应商

> 定位：仅负责 Excel 解析、数据落盘、移交门禁，不直接调用复盘引擎。
> v2.2 变更：头条/小红书已退出复盘体系，仅解析视频号+抖音。

⚙️ 工作区路径

默认工作区：<workspace>
若当前工作区不同，优先使用当前工作区路径下的 .workbuddy/data/ 目录。
以下所有路径引用 ${WORKDIR} 表示：当前工作区 → 默认工作区（fallback）

触发条件

1. 用户提供 .xlsx 文件，且列头匹配以下平台特征：
   - 视频号：含「完播率」「推荐」「关注」
   - 抖音：含「完播率」「5s 完播率」「主页访问量」
2. 用户明确指令：「把这个数据落盘到 tracking」「更新追踪数据」

执行流程

1. 确定文件路径

默认 tracking.json 路径：<workspace>/.workbuddy/data/tracking/video-performance.json，支持用户自定义。

2. 运行解析脚本

执行边界测试 → 解析合并 → 增量追加：

python3 <workspace>/.workbuddy/skills/video-data-tracker/scripts/test_boundary.py
python3 <workspace>/.workbuddy/skills/video-data-tracker/scripts/parse_and_merge.py ${tracking_path} ${excel_paths}

边界测试未全通过 → 终止，输出失败项，不追加数据。

3. 微型健康检查（读阈值文件）

解析成功后，读取 account-thresholds.json 执行快速校验：
- 抖音：2s 跳出 ≥ 阈值文件 douyin.alarm_threshold.2s_drop → 标记 health_alert: "douyin_2s_high"
- 视频号：完播 ≤ 阈值文件 wechat_channels.alarm_threshold.completion → 标记 health_alert: "wechat_completion_low"
- 阈值文件不存在 → fallback 到内置告警默认值（与 alarm_threshold 对齐）：抖音 2s跳出≥35% / 视频号完播≤10%。阈值文件存在时优先使用 alarm_threshold 字段。

> 📝 阈值语义区分（R11 修复）：健康告警用 alarm_threshold（某项超标即标 health_alert）；复盘红线用 golden_threshold（见发布后复盘 E2 红线检查）。二者字段不同、用途不同，勿混用。

4. 匹配发布记录，移交 复盘向导

匹配前预处理（v2.1 新增）：
1. 去除双方标题的「徐州」「君启」「小张哥说房」等品牌前缀
2. 保留核心关键词（板块名/数据词/动词）
3. 模糊匹配阈值：≥ 0.4（v2.1 放宽，原≥0.5）

> 📝 阈值语义区分（R10 修复）：此处 0.4 是「tracking↔publish_log 发布记录匹配」阈值；脚本内 SIMILARITY_THRESHOLD=0.5 是「视频号↔抖音跨平台合并」阈值。二者语义不同，勿混用。
4. 日期窗口辅助：发布日 ±1 天内的记录优先匹配

1. 读取 ${WORKDIR}/.workbuddy/data/publish_log.json
2. 标题模糊匹配（含预处理）milestones.video_published != null 的记录：

✅ 匹配成功：

1. 🔒 强制执行 Read publish_log.json
2. 🔒 data_collected 原子写（与发布后复盘铁律 #5 一致，不再裸 Edit）：用 atomic_write.py 的 update_json_atomic 定位 "id": "${video_id}" 写入 "milestones.data_collected": "${当前ISO时间}"：
   python import sys sys.path.insert(0, r"C:/Users/87800/.workbuddy/skills/post-publish-review/scripts") import atomic_write PLOG = r"<workspace>/.workbuddy/data/publish_log.json" def patch(doc): for e in doc["entries"]: if e.get("id") == video_id: e.setdefault("milestones", {})["data_collected"] = data_collected_at return True return False atomic_write.update_json_atomic(PLOG, patch)
   2.5 🔒 performance 原子写回（P0-2 闭环命脉 · 仅对有效发布样本）：
   • 取本批匹配到的视频在 tracking/video-performance.json 中解析出的表现数据（视频号+抖音：views/likes/comments/shares/completion_rate/avg_watch_sec/follows）。
   • 🔒 写回铁律：仅对 milestones.video_published 有值（或本步同步置位，见下）的条目执行；绝不为创作稿/定稿稿写 performance（否则污染 F6 训练集，违反 PUB-GATE）。
   • 定位 "id": "${video_id}" → 用 atomic_write.update_json_atomic 原子写 performance，结构对齐 model_weights 消费格式：
     json "performance": { "shipinhao": {"views":, "likes":, "comments":, "shares":, "completion_rate":, "avg_watch_sec":, "follows":}, "douyin": {"views":, "likes":, "comments":, "shares":, "completion_rate":, "avg_watch_sec":, "follows":} }
   • 🔒 PUB-GATE 边界 case（"复盘数据了"=真发布信号）：若写 performance 时 milestones.video_published 为 null，视为用户已确认发布（等价于"已发布"），在 2.5 的同一 update_json_atomic 调用里同步将 milestones.video_published 置为 ${data_collected时间}（或用户提供的发布时间），再写 performance。→ 确保"已发布"/"复盘数据了"两种表述都落到 video_published=True ∧ performance≠∅，F6 才能吃到。
   • ⚠️ 写回机制：performance 为结构化数据，必须走 atomic_write.py（与发布后复盘铁律 #5 一致）；调用示例：
     python import sys sys.path.insert(0, r"C:/Users/87800/.workbuddy/skills/post-publish-review/scripts") import atomic_write PLOG = r"<workspace>/.workbuddy/data/publish_log.json" def patch(doc): for e in doc["entries"]: if e.get("id") == video_id: e["performance"] = {"shipinhao": {...从 tracking 取...}, "douyin": {...}} if not e.get("milestones", {}).get("video_published"): e.setdefault("milestones", {})["video_published"] = data_collected_at return True return False atomic_write.update_json_atomic(PLOG, patch)
   • 验证：再次 Read 确认 performance 非空且 video_published 符合 PUB-GATE。
3. 验证：再次 Read 确认 data_collected ≠ null（步骤 2）且 performance 非空（步骤 2.5，若执行）。
4. 输出：「✅ 数据已入库 + data_collected 时间戳已写入，匹配到发布记录 ${video_id}：${title}，正在移交复盘门禁...」
5. 调用 复盘向导，传递参数：
   • trigger_source: "video-data-tracker"
   • video_id: "${video_id}"
   • title: "${title}"
   • health_snapshot: "${health_alert || 'normal'}"
6. 若 publish_log 中存在 reminder_id → 调用 automation_update mode="delete" 取消提醒

❌ 匹配失败（v2.1 候选列表 + 部分标记）：

1. 列出前 3 个候选记录（按标题相似度排序 + 日期窗口 ±1 天优先）
2. 输出候选列表格式：
   ✅ 数据已入库（+${新增条数}条） ⚠️ 未自动匹配到发布记录。以下是发布时间接近的候选记录： 1. ${video_id} | ${title} | 相似度 ${score} | 发布日 ${date} 2. ... 3. ... 请选择匹配的记录编号，或输入「跳过」：
3. 用户选择 → 走 ✅ 匹配成功分支
4. 用户跳过/无法确定 → 写入 milestones.data_collected: "partial_${时间}" + meta.match_status: "manual_confirm_needed"
5. 输出：「数据已标记为待确认。稍后说「复盘 ${标题}」可手动触发」

示例（Few-Shot）

例1 · 标准正向（落盘 + 匹配 + 移交）
> 用户拖入抖音 xlsx。
> 执行：test_boundary → parse_and_merge 写入 tracking/video-performance.json → 读阈值做微型健康检查 → 标题预处理(去品牌前缀)+模糊匹配(≥0.4) publish_log → 写 milestones.data_collected(ISO) → 调用 复盘向导(trigger_source:"视频数据追踪" + video_id + title + health_snapshot) → 若有 reminder_id 则取消提醒。

例2 · 边界（匹配失败）
> 模糊匹配无高置信记录 → 列前 3 候选(相似度+日期窗口) → 用户选/跳过 → 跳过则写 data_collected:"partial_时间" + meta.match_status:"manual_confirm_needed"。

例3 · 禁止项
> ❌ 绝不直接调用 发布后复盘，所有复盘请求必须移交 复盘向导。
> ❌ 不得修改复盘阈值，仅读取 account-thresholds.json 做健康检查。
> ❌ 增量追加必须去重，不得覆盖已有数据。

🚨 联动说明

• ❌ 不直接调用 发布后复盘，所有复盘请求必须移交 复盘向导
• ❌ 不修改复盘阈值，仅读取阈值文件做健康检查
• ✅ 仅负责数据落盘和移交，不做任何复盘逻辑
• ✅ 增量追加时严格去重，不覆盖已有数据

版本记录