返回 Skill 列表
extension
分类: 数据与分析无需 API Key

post-publish-review

发布后 24h 复盘引擎 v2.13。F4.5 反馈回流重定向至 review-calibration.md,creation-state.json 降为历史镜像。D段硬阻断+E段专属阈值+F段原子写回流。F5.7预测对账+F6自动刷新预测模型。🆕 H段决策校准:读 creation_trace → 渲染决策复盘卡 → 校准人类判断力。仅接收复盘向导调用。

person作者: user_d68814aehubcommunity

post-publish-review — 复盘执行引擎

定位:唯一复盘执行方 v2.7,仅接收 复盘向导 委托,执行 D+E+F 全流程,不响应任何用户触发词。

🔒 核心铁律(强制执行,无协商)

  1. <12h / >48h 禁止进入 E/F 段,无人工绕过通道
  2. reviewed 状态必须关联有效 tracking 数据 + 审计字段
  3. MEMORY 验证基数 = 发布总数(含失败/黑洞样本)
  4. 脏数据(data_failed / data_timeout / status_anomaly)禁止写入 triggers
  5. publish_log.json 写操作强制走 publish_log_cli.py patch(统一写入入口:结构校验+版本校验+原子写+备份),禁止 cat >> / Edit 工具 / 直调 atomic_write.py 写 publish_log;其他文件(MEMORY.md / usage / review-calibration.md)仍用 atomic_write.py
  6. 复盘阈值完全来自 复盘向导 传递的 thresholds 参数,不硬编码

⚠️ 前置:路径自动探测

按优先级取首个存在的路径:

  1. publish_log.json:当前工作区 → .workbuddy/data/<workspace>/ 历史兼容
  2. video-performance.json唯一权威 tracking 文件,由视频数据追踪写入):.workbuddy/data/tracking/video-performance.json<workspace>/.workbuddy/data/tracking/video-performance.json(历史兼容路径)
    • ⚠️ 旧 tracking.json 已废弃(视频数据追踪自 v2.x 起改写 video-performance.json),禁止解析/回退到 tracking.json,否则 E1 读陈旧数据
    • ${tracking_path} 运行时变量 必须解析到此处发现的 video-performance.json 绝对路径(不解析目录、不解析 tracking.json
  3. scripts/:当前工作区 → <workspace> 历史路径
  4. review-calibration.md.workbuddy/memory/<workspace> 历史路径 .workbuddy/memory/ → 两个都不存在则在当前工作区 .workbuddy/memory/ 新建

探测失败 → 终止,输出「⚠️ 未找到核心文件,请检查工作区配置」


D段 · 数据回收(硬阻断,无妥协)

D1 确认发布记录

  • 接收 skip_d1_confirmation: true → 跳过确认,直接用 target_video_id 匹配记录
  • 否则读取 publish_log,取 milestones.video_published != nullmilestones.review_completed == null 的最新记录,确认后继续

D2 时间窗口闸刀

| 发布时长 | 处置 | |----------|------| | <12h | ⛔ 终止,输出「数据未成熟」 | | 12~48h | ✅ 继续 | | >48h | ⚠️ 标记 meta.data_status: "timeout",禁入 E/F 段 |

结果写入 publish_log.meta.time_window_check(走统一入口:python .workbuddy/tools/publish_log_cli.py patch --id <target_video_id> --merge '{"meta":{"time_window_check":"<D2结果>","data_status":"<timeout|pass|immature>"}}')。

D3 解析零容忍

接收 Excel 后执行解析脚本,任一失败直接终止:

  1. 脚本 exit code ≠ 0 → meta.data_status: "failed"
  2. tracking 中对应视频 platforms 数组为空 → meta.data_status: "failed"
  3. 所有平台播放量 = 0 → meta.data_status: "corrupted"

D3.5 完整性门禁(含首次运行豁免)

  • video-performance.json 不存在 → 首次运行豁免,直接进入 D4,报告标注「首次运行豁免 D3.5」
  • 非首次:需满足 ≥1 个平台播放量 > 0 + ≥1 个平台完播率存在,否则 meta.data_status: "corrupted",禁入 D4

D4 状态可审计

milestones.review_completed 写入必须满足三条件:✅ D3.5 通过 ✅ tracking 有有效数据 ✅ 非 data_status: "failed" / "corrupted" / "timeout"

写入时强制追加审计字段到 publish_log 记录(走统一入口,一次性 merge):

python .workbuddy/tools/publish_log_cli.py patch --id <target_video_id> --merge '{
  "milestones": {"review_completed": "${ISO时间戳}"},
  "meta": {
    "time_window_check": "${D2结果}",
    "reviewed_by": "post-publish-review-v2.7",
    "reviewed_at": "${ISO时间戳}",
    "data_source": "excel_parse",
    "threshold_version": "${threshold_meta.version}"
  }
}'

CLI 在落盘前强制结构校验:review_completed 须为合法 ISO 或 null;校验不过直接 [REJECT] 拒绝落盘。


E段 · 复盘分析(动态阈值)

E1 分析引擎

🔒 前置守卫(R4 修复):调 analyze_tracking.py 前,必须先确认 ${tracking_path} 指向的 tracking 文件存在

  • 若 D3.5 已判定「首次运行豁免」(tracking 不存在)→ 跳过 E1,报告顶标注「⚠️ 首次运行·无数据可分析(tracking 缺失,跳过 E1)」,不调用脚本(避免脚本 sys.exit(1) 中断链路)。
  • 若 tracking 存在 → 正常调用下方脚本。
python ${scripts路径}/analyze_tracking.py ${tracking_path} ${--latest 3(有效记录≥3时)}

有效记录 < 3 → 报告顶标注「⚠️ 样本不足(${N}条有效记录),以下诊断仅供参考,不作为复判决准」

⚠️ v2.1 样本不足保护

  • 有效记录 < 3 时,E2 红线检查保留但标注「样本少,仅供参考」
  • E3 推流漏斗保留但标注「样本<3,仅供参考」
  • ⏭️ 跳过 E4 经验蒸馏(不写入 MEMORY,不新增规律)
  • 有效记录 ≥ 3 时,完整执行 E2/E3/E4

E2 报告生成 + 红线检查

动态生成红线表(从 thresholds 参数读取阈值):

| 平台 | 关卡 | 黄金阈值 | 未达标后果 | 触发动作 | |------|------|----------|------------|----------| | 抖音 | 冷启第一关 | 2s跳出 < ${thresholds.douyin.golden_threshold.2s_drop.value}% | 播放压至 1000 以下 | 🔴 报告顶 + 前 3s 重做 | | 抖音 | 冷启第二关 | 5s完播 > ${thresholds.douyin.golden_threshold.5s_complete.value}% | 无法进入三级流量池 | ⚠️ 报告内提醒 | | 视频号 | 公域破冰关 | 完播 > ${thresholds.wechat_channels.golden_threshold.completion.value}% | 卡在私域 | 🔴 报告顶 + 前 3s 钩子重做 | | 视频号 | 裂变关 | 分享 > ${thresholds.wechat_channels.golden_threshold.share_count.value} 次 | 播放上限 ~3000 | ⚠️ 报告内提醒 |

⚠️ v2.2 变更:头条/小红书已退出复盘体系(2026-07-03)。复盘仅覆盖视频号+抖音。头条标题规则保留在 review-calibration.md 作为发布规则。

命中红线 → 报告顶置告警,未命中 → 静默通过。

E3 推流漏斗诊断(自动生成)

抖音:2s跳出 ${实测}% → 冷启【${通过/未过}】 | 5s完播 ${实测}% → 【${二级池/卡壳}】
视频号:完播 ${实测}% → 【${破公域/卡私域}】 | 分享 ${实测} 次 → 【${裂变潜力高/一般}】

E4 经验蒸馏

  1. 已有规律:支持则加验证计数,推翻则标 ⚠️ 冲突
  2. 新规律:首次出现记当日日志,≥2 次出现才写入 MEMORY
  3. 验证基数 = publish_log 中该选题总发布数(含 meta.data_status: "missing" / "timeout"
  4. 连续 3 次低于均值的选题 → 标记「需调整角度」

F段 · 反馈回流(原子写)

F0 数据质量黑名单

禁止写入 triggers / usage / review-calibration.md 的状态:data_status: "failed" / "corrupted" / "timeout" / "status_anomaly" 仅允许:milestones.data_collected != null ✅ / milestones.review_completed != null

F1-F5 回流逻辑

  1. 评论投喂:按 🔥痛点 / 🔥质疑 / ⭐补充观点分类,高价值评论写入 triggers/active/07-用户评论.md(追加模式,不覆盖已有内容) 1.5. 🔗 画像验证回流(v3 新增 · 闭环收口):对每条进入 07-用户评论.md 的高价值评论,若 creation-state.json 存在 sub_persona_id(即本条视频瞄准的 L2 子画像),将其追加至 正推构思/references/persona-library.md 中对应 ### [P-XXX] 小节的 📥 验证记录 表:
    • 列:日期 / 来源(复盘·视频ID) / 验证字段(印证反驳) / 客户原话/信号
    • 印证:评论与该子画像痛点/主张一致(如"月供压垮我"→印证 P-GX-001 预算敏感型)
    • 反驳:评论与该子画像冲突(如"我卖房一周就出手了"→反驳 P-MF-001 流动性陷阱)→ 标 ⚠️冲突,供蒸馏时复核
    • 同一子画像累计 ≥5 条 → 输出 🔔 该画像验证记录达5条,建议蒸馏升 L3
    • 若该视频未绑定 sub_persona_id(热搜轻量版等)→ 跳过本步,不阻断
  2. 触发器回写:直接 Write 到 triggers/active/ 对应触发器文件,然后运行 python junqi-vault/scripts/rebuild_index.py --root D:/Users/87800/Documents/Claw;≥3 次使用标「⚠️ 疲劳」
  3. 表现评价:按完播/互动率对比均值,标记「🔥爆款/✅好用/➖一般/❌踩雷」写入 usage/YYYY-MM.md
  4. 刷新复判决准:覆盖更新 ${探测到的路径}/review-calibration.md(路径探测见前置 §4),下次创作前强制读取 4.5. 🔒 反馈回流通道(v2.11 修正 · 生产端方向 · F2 修复)

    ⚠️ 链路修正(F2 根因):创作-前置扫描 实际从 review-calibration.md + publish_log 重建 feedback_influence(见其 Step 2.2/2.4),并不读取 creation-state.jsonfeedback_influence。因此复盘结论的「决策面」必须落在 review-calibration.md(F4 step 4 的职责,pre-scan 强制读取的唯一来源),creation-state.json 仅作状态历史镜像。

    • ① 权威通道 · review-calibration.md(下次创作前被强制读取,决策以此为准):将 E4 蒸馏结果落实到对应表——
      • verified_methods → 铁律速查表对应行 验证次数 +1(新方法论则新增铁律行)
      • corrected_methods → 更新对应铁律 描述
      • refuted_methods → 对应铁律标 🔴冲突/废弃
      • new_hypothesis → 追加到「新假设(待验证)」表
      • 该写入由 F4 step 4 执行;本步负责核对确认 review-calibration.md 已包含本轮结论,缺则补写(杜绝"复盘做完但下次创作读不到"的断链,如 20260723-1 曾发生)。
    • ② 状态历史镜像 · creation-state.json(仅跨会话追溯用,pre-scan 不消费):将紧凑 feedback_influence 写入 current.feedback_influence
      • verified_methods / corrected_methods / refuted_methods / new_hypothesis / last_updated + source(复盘来源视频ID)
      • 写入后显式标注:此镜像不被 创作-前置扫描 读取,决策以 review-calibration.md 为准。
    • 目的:消除"复盘后到下次创作前"的链路断裂——决策闭环走 review-calibration.md(pre-scan 真读),状态连续性走 creation-state.json(历史镜像)。

📝 字段写入约定(R9 修复):corrected_methods / new_hypothesis / last_updated / source可选字段——本轮若无对应内容,不强制创建空结构;写入时与 feedback_influence 既有值做合并写(仅更新有变化的字段,不覆盖未变更字段)。实际存储中假设池以 new_hypothesis_pool 承载,写入时映射到该键即可。

  1. 复盘问题入库:提取 🔴硬伤 / 🟡软伤 / 🟢可延展,写入 deliverables/复盘问题/YYYY-MM-DD_{video_id}.md(格式:日期+视频ID,确保同天多期不覆盖)

F5.5 复盘→铁律转化提示 🔒 🆕 v2.4

复盘问题库长期积累但无人转化为铁律。本步在 F5 入库后自动执行。

操作

  1. 扫描 deliverables/复盘问题/ 最近 5 个文件
  2. 统计各 🔴硬伤的重复出现次数
  3. 同一硬伤关键词 ≥ 2 次 → 输出 🔔 建议晋升为铁律:[硬伤摘要](已出现{N}次)
  4. 同一硬伤关键词 ≥ 3 次 → 输出 🔴 强制建议:立即写入 review-calibration.md §铁律速查表

输出格式

🔔 复盘→铁律转化建议
─────────────────────
≥2次硬伤(建议晋升):
  - "开头数据陈述→抖音2s跳出高" · 出现{N}次 · 对应铁律#9
≥3次硬伤(强制建议):
  (无)
─────────────────────

降级:复盘文件 < 3 个 → 跳过本步,标注「样本不足,跳过铁律转化」。

F5.6 review-signal.md 刷新 🔒 🆕 v2.4

源4 统一信号文件。每次复盘后必须刷新,供下次创作前置扫描读取。 ⚠️ 路径固定.workbuddy/data/review-signal.md —— 与前置扫描源4 只读路径一致。 不可用 {探测到的路径}(该变量指向 review-calibration.md 所在的 .workbuddy/memory/ 目录,与 review-signal.md 所在的 data/ 目录不同,误用会写错地方、信号链断裂)。

操作

  1. 定位路径:${工作区}/.workbuddy/data/review-signal.md(固定,不沿用 memory 探测路径)。
  2. 🔒 降级:若该文件不存在(如全新环境)→ 以骨架新建(含「📍 最近复盘硬伤」「🔒 铁律速查」「🧪 待验证假设」三段),避免 F5.6 必失败断链。
  3. Read 文件 → 更新「📍 最近复盘硬伤」段:追加本次复盘硬伤/软伤到表格顶部,超3期的最旧条目移入「历史归档」。
  4. 更新「🔒 铁律速查」段:若 F4 更新了 review-calibration.md,同步刷新铁律表。
  5. 更新「🧪 待验证假设」段:若有新假设或假设到期,同步状态。
  6. Write back review-signal.md

输出✅ review-signal.md 已刷新 · 最近{N}期硬伤 · {M}条铁律 · {K}个假设

F5.7 预测 vs 实际对账 🔒 🆕 阶段4

闭环终点:每篇已发布视频,比对发布前预测(meta.pred_qa)与发布后真实表现(performance), 让用户看到"我预测的和实际差多少",模型在 F6 用真实值自校正。 🔒 前提:milestones.video_published 有值(PUB-GATE)且 performance 非空。

操作

  1. 读取本条 meta.pred_qa(若不存在 → 跳过本步,标注「本视频发布前未跑质检预测,跳过对账」)。
  2. performance.shipinhao.views / performance.douyin.views 为实际值(整数)。
  3. 解析 pred_qa.shipinhao_views / douyin_views 区间(形如 "2499-4641"):
    • lo, hi = map(int, s.split("-"))mid = (lo + hi) / 2
    • in_range:实际值是否 ∈ [lo, hi]
    • deviation_pct = round((实际 - mid) / mid * 100, 1)
  4. publish_log_cli.py patch 写回 meta.prediction_reconciliation(走统一入口,深合并 meta 子字段):
python .workbuddy/tools/publish_log_cli.py patch --id <target_video_id> --merge '{"meta":{"prediction_reconciliation":{
  "shipinhao_actual":<int>,"shipinhao_in_range":<bool>,"shipinhao_deviation_pct":<float>,
  "douyin_actual":<int>,"douyin_in_range":<bool>,"douyin_deviation_pct":<float>,
  "verdict":"<区间命中→中性;偏离→指出偏向上/下限方向,供 F6 吸收偏差>"
}}}'
5. 输出:`✅ 预测对账完成 · 视频号{in_range?命中:偏离 dev%} · 抖音{in_range?命中:偏离 dev%}`。

6. **偏差趋势扫描(I-1 · bump 信号)**:读取 publish_log 全部 `entries`,取含 `meta.prediction_reconciliation` 的记录,按 `milestones.video_published` 时间升序,提取 `shipinhao_deviation_pct`(缺失则回退 `douyin_deviation_pct`)。
   - 统计**最近连续≥3篇**同向偏离(全部 >0 记为 over / 全部 <0 记为 under)。
   - 命中 → 走统一入口写回本条 `meta.pred_bias`:`python .workbuddy/tools/publish_log_cli.py patch --id <target_video_id> --merge '{"meta":{"pred_bias":{"same_direction_count":<N>,"direction":"over"|"under","bump_hint":"连续≥3篇预测同向偏差,建议复核预测系统性偏移(rubric/model bump)"}}}'`
   - 未命中 → 同上写法:`... --merge '{"meta":{"pred_bias":{"same_direction_count":<N>,"bump_hint":false}}}'`
   - 输出追加:`✅ 偏差趋势:{N}篇连续同向偏离 → {bump_hint?🔔建议bump:正常}`。

**联动**:本步骤数据为 F6 提供"预测准不准"的闭环信号;F6 用真实 performance 重训,间接吸收偏差。

### F6 自动刷新预测模型 🔒 🆕 v2.5

> 闭环供给方:每次复盘完成后,用真实表现回写 `君启-视频流量预测` SKILL 依赖的 `model_weights.json`,让下次发布前预测随真实数据迭代(消除"复盘→预测模型"断点)。
> ⚠️ **路径固定**:`<workspace>/.workbuddy\recompute_model.py`(数据层重算脚本,纯 stdlib,固定路径,不沿用 memory 探测变量)。

**操作**:
1. 用托管 Python 运行重算脚本:
```bash
C:/Users/87800/.workbuddy/binaries/python/versions/3.13.12/python.exe "<workspace>/.workbuddy/recompute_model.py"
  1. 脚本内置样本量守卫:有效样本 <3 时跳过刷新、保留当前模型并输出 ⚠️ 有效样本仅 N 条 (<3),跳过刷新,不写入(防止无数据时版本空转)。
  2. 样本充足时:脚本从 publish_log.json 真实表现重算,版本号 v(N) → v(N+1) 递增写回 studio-data/model_weights.json,并追加 calibration_log 审计。

输出✅ 预测模型已刷新 → v(N+1) · 样本 {M} 条⚠️ 样本不足,跳过刷新(保留 vN)

联动君启-视频流量预测 SKILL 步骤 1 读取该模型;其 --calibrate 亦调同一脚本。两侧同源,避免双份模型漂移。


示例(Few-Shot)

例1 · 标准正向(数据回收 → 复盘)

前置:用户已通过 视频数据追踪 把 Excel 落盘,publish_log 中 milestones.data_collected != null,发布时长落在 12~48h。 执行:D 段确认记录 → D2 时间窗口闸刀通过 → D3 解析零容忍通过 → D3.5 完整性通过 → E 段动态阈值红线检查 + 推流漏斗 → F 段原子写回流 → 输出「复盘全流程交付报告」。

例2 · 边界 / 终止(时间窗口闸刀)

发布 <12h → D2 直接 ⛔ 终止,输出「数据未成熟」,不进 E/F。 发布 >48h → 标记 meta.data_status: "timeout",禁入 E/F 段,转「存量黑洞视频 SOP」。

例3 · 禁止项

❌ 脏数据(data_failed / data_timeout / status_anomaly)严禁写入 triggers / usage / review-calibration.md。 ❌ 严禁用 cat >> / Edit 工具 / 直调 atomic_write.py 写 publish_log,必须走 publish_log_cli.py patch(统一写入入口,落盘前强制结构校验,校验不过直接拒绝)。 ❌ 复盘阈值不得硬编码,必须来自 复盘向导 传递的 thresholds 参数。


🕳️ 存量黑洞视频 SOP

适用于发布 >48h、tracking 无数据的记录:

  1. 冻结:标记 meta.data_status: "missing_${N}d",禁止写入 milestones.review_completed
  2. 溯源:24h 内查 Excel / 平台后台补导(视频号保留 7 天,其余 ≈30 天)
  3. 终结:补数成功 → 走 D3→D4;无法补数 → 标记 meta.lost_reason: excel_not_found,永久隔离,不参与 MEMORY 验证
  4. 原则:宁可承认丢失,不伪造复盘

H段 · 决策校准 🔒 🆕 v2.13

依赖.workbuddy/skills/_shared/h_segment.py + publish_log[{video_id}].creation_trace 定位:复盘不验证"规则灵不灵"——只校准"你当时怎么判断的、实际差了多少" 旧视频无 trace → 静默跳过(不报错不阻塞)

执行

import sys
from pathlib import Path
sys.path.insert(0, str(Path("C:/Users/87800/.workbuddy/skills/_shared")))
from h_segment import run_h_segment, render_decision_card, run_batch_summary

card = run_h_segment(video_id, E_diagnosis)
if card:
    md_card = render_decision_card(card)

不变量

  1. H段只读——不修改 clue-library.json / tracking / publish_log
  2. 判定用"方向"而非"因果"(方向对≠杠杆对,方向错≠完全错)
  3. 校准建议只给"调整决策方式",不给"必须用某线索"
  4. 每5支触发 batch_summary

跨视频校准摘要(每5支)

if len(cards_buffer) >= 5:
    valid = [c for c in cards_buffer[-5:] if c is not None]
    if valid:
        summary_md = run_batch_summary(valid)

✅ 复盘全流程交付报告(自动生成)

# 📮 复盘全流程交付报告
触发来源:□ 手动复盘 □ Excel 自动触发
核验码:RP-${YYYYMMDD}-${序号}
阈值版本:${threshold_meta.version}(${threshold_meta.calibration_date} 校准,样本量 ${threshold_meta.sample_size})

### ✅ 流程完整性核验
| 环节 | 状态 | 说明 |
|------|------|------|
| 门禁校验 | ✅ | 工作区路径匹配 |
| 数据落盘 | ✅ | 新增 ${X} 条,无解析失败 |
| D 段硬阻断 | ✅ | 无 <12h / 超时 / 数据损坏 |
| E 段分析 | ✅ | 基于账号专属阈值诊断 |
| F 段回流 | ✅ | triggers/校准文件/MEMORY 已更新 |
| 状态更新 | ✅ | milestones.review_completed 已写入,审计字段完整 |

### 🎯 核心推流诊断
${自动生成的 E3 推流漏斗内容}

### 📦 资产更新记录
| 资产类型 | 更新内容 | 状态 |
|----------|----------|------|
| triggers 07 | 投喂 ${X} 条 🔥 评论 | ✅ |
| 画像验证回流 | 绑定 sub_persona_id 时回写 ${Y} 条至 persona-library 📥验证记录 | ✅ |
| 触发器记录 | ${X} 个触发器追加表现评价 | ✅ |
| 复判决准 | 新增 ${X} 条强制约束(已落 review-calibration.md 铁律/新假设表,pre-scan 真读) | ✅ |
| creation-state.json | feedback_influence 历史镜像已同步(决策以 review-calibration.md 为准) | ✅ |
| 预测对账 | meta.prediction_reconciliation 已写 | ✅ |
| 预测模型 | F6 刷新 model_weights v(N+1) / 样本不足跳过 | ✅ |
| MEMORY | 验证「${规律}」至 ${X}/${total} | ✅ |
| 复盘问题库 | 新增 ${X} 条 🔴 硬伤 | ✅ |
| 决策校准 | 🆕 H段决策复盘卡已生成(有trace时) | ✅ |

### 🧭 决策复盘卡
${H段渲染的决策复盘卡——无 trace 时本段不出现}

### ⚠️ 遗留待办
| 优先级 | 事项 | 截止时间 |
|--------|------|----------|
| 🔴 高 | ${data_missing 视频处理} | 今日 |
| 🟢 低 | ${未匹配发布记录处理} | 24h 内 |

### 📱 微信速报(推送至微信小程序)🆕 v2.4

{简洁的复盘摘要——3-5条必看信息}

示例:
📮 复盘速报 · 20260701-1
✅ D段通过 · E段诊断完成
🔴 红线:抖音2s跳出32.85%→开头重做
✅ 视频号完播12.9%→破公域
📦 回写:review-calibration更新 / creation-state同步 / 复盘问题入库
💡 采纳建议:M-012(抖音开头情绪化)·M-001(分人群建议)

🚨 任意环节 ❌ → 报告顶置「⚠️ 本次复盘无效,未标记 reviewed」,终止资产写入。


联动说明

  • 仅接收 复盘向导 调用,不直接响应用户或 视频数据追踪
  • 阈值完全来自 复盘向导 传递的 thresholds 参数,无硬编码
  • 触发器回写:直接 Write 到 triggers/active/ 对应文件,然后运行 python junqi-vault/scripts/rebuild_index.py --root D:/Users/87800/Documents/Claw
  • F1 评论投喂写入 triggers/active/07-用户评论.md

版本记录

| 版本 | 日期 | 核心变更 | |------|------|----------| | v2.13 | 2026-07-29 | H段决策校准:新增 H段——读 creation_trace + E段诊断 → 渲染决策复盘卡 · 无 trace 静默跳过 · 每 5 支触发 batch_summary。定位:复盘不验证"规则灵不灵",只校准"你当时怎么判断的" | | v2.12 | 2026-07-27 | 单库收口:删除灵感田Skill依赖声明;F0脏数据黑名单/F1评论投喂/F2触发器回写/复查模板/联动说明全改 junqi-vault 直写;旧"调用灵感田流程三"替换为直 Write+rebuild_index | | v2.11 | 2026-07-25 | F2 修复:F4.5 反馈回流重定向至 review-calibration.md | | v2.7 | 2026-07-16 | F5.7 增偏差趋势扫描(I-1 · bump 信号):对账后统计最近连续≥3篇同向偏离 → 写 meta.pred_bias + bump 提示,让预测系统性偏移可观测(供 rubric/model bump 决策) | | v2.6 | 2026-07-16 | 阶段4:F5.7 预测 vs 实际对账(meta.prediction_reconciliation);P0-2 闭环由 video-data-tracker 写回 performance | | v2.5 | 2026-07-13 | 新增 F6 自动刷新预测模型:复盘后调用 recompute_model.py 从 publish_log 真实表现重算 model_weights.json,版本 v(N)→v(N+1) 递增,内置样本量守卫(<3跳过);闭合"复盘→预测模型"断点 | | v2.4 | 2026-07-11 | R2修复 F5.6 路径固定为 .workbuddy/data/(与前置扫描源4一致)+ 缺失降级;版本号三处统一(头/审计/段标) | | v2.3 | 2026-07-03 | F4.5 新增 creation-state.json 即时同步:每次复盘完成后必须写入 current.feedback_influence,消除复盘到下次创作间的链路断裂 | | v2.1 | 2026-06-28 | preamble增加review-calibration.md路径探测;F5命名统一为日期+视频ID;E段样本不足保护扩展至E2/E3/E4 | | v2.0 | 2026-06-24 | publish_log v2.0 适配 — milestones 对象替代单 status 字段,meta.data_status 替代数据异常标记 | | v1.9 | 2026-06-24 | E5 红线和交付报告阈值改为动态读取,完全对接 account-thresholds.json | | v1.8.1 | 2026-06-24 | 联动对齐,明确仅接收 复盘向导 调用 | | v1.8 | 2026-06-24 | D 段硬阻断 / D3.5 豁免 / 验证基数修复 / 黑洞 SOP / 精简 74% | | v1.7 | 2026-06-19 | 时间窗口强制 / D3 数据校验 / F 段原子写 |