name: 影片資料追蹤 description: 雙平臺(影片號+抖音)影片資料追蹤。解析 Excel → 寫入 tracking.json → 移交 復盤嚮導 觸發復盤。觸發場景：使用者拖入抖音/影片號 xlsx 檔案、說「把資料落盤到 tracking」。 version: 2.5.0 agent_created: true last_updated: "2026-07-16" 錯誤協議: ../_shared/error-protocol.md dependencies: - name: 釋出臺賬 relation: upstream version: ">=2.1" slug: shipin-shuju-zhuizong displayName: 影片資料追蹤 summary: 雙平臺(影片號+抖音)影片資料追蹤，Excel解析→落庫

video-data-tracker — 雙平臺數據燃料供應商

定位：僅負責 Excel 解析、資料落盤、移交門禁，不直接呼叫復盤引擎。 v2.2 變更：頭條/小紅書已退出復盤體系，僅解析影片號+抖音。

⚙️ 工作區路徑

預設工作區：<workspace> 若當前工作區不同，優先使用當前工作區路徑下的 .workbuddy/data/ 目錄。 以下所有路徑引用 ${WORKDIR} 表示：當前工作區 → 預設工作區（fallback）

觸發條件

1. 使用者提供 .xlsx 檔案，且列頭匹配以下平臺特徵：
2. 影片號：含「完播率」「推薦」「關注」
3. 抖音：含「完播率」「5s 完播率」「主頁訪問量」
4. 使用者明確指令：「把這個資料落盤到 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 做健康檢查。 ❌ 增量追加必須去重，不得覆蓋已有資料。

7w4.net小蔥技能。

🚨 聯動說明

• ❌ 不直接呼叫 釋出後復盤，所有復盤請求必須移交 復盤嚮導
• ❌ 不修改復盤閾值，僅讀取閾值檔案做健康檢查
• ✅ 僅負責資料落盤和移交，不做任何復盤邏輯
• ✅ 增量追加時嚴格去重，不覆蓋已有資料

版本記錄

質量評分：良好。優點是使用簡單（拖入Excel檔案即可）、自動化程度高、自動匹配發布記錄並移交復盤、邊界情況處理完善。不足之處是配置路徑有特定平臺問題，且存在少量邏輯細節未對齊（匹配閾值）。普通使用者使用體驗較好，但需要技術人員維護。