企业官网建设流程全解析

• AI 技能
• AI 应用

本篇技术指南以 cadence-protocol.md（节奏协议）为核心，讲解 cheat-on-content 项目如何把"哪天该拍、该发、该复盘"固化为可执行协议：SessionStart hook 自动渲染每日状态报告、基于target_publish_cadence_days派生 Buffer 颜色警戒、/cheat-recommend按颜色动态切换选题策略。读完你不仅能理解这套节奏系统的三层结构与五类标准工作流模板，还能结合仓库源码（hook 脚本、state 字段契约、各子 skill 实现）掌握它的底层运行原理与可复制的落地方法。

一、协议定位：为什么需要一套"节奏协议"

cheat-on-content 是一个把"每条内容发布变成一次校准实验"的工作流：打分、盲预测、复盘、进化（rubric 升级）。cadence-protocol.md 在其中承担一个核心职责——固化"哪天该做什么"，避免用户驱动每一步。它让 Claude 在每次会话开场就能回答"我现在该拍 / 该发 / 该复盘"，而不是等用户逐个下发指令。

该协议被多个子 skill 引用：/cheat-status、/cheat-recommend、/cheat-shoot、/cheat-publish，以及 SessionStart hook。也就是说，节奏不是某一个功能模块，而是贯穿整个项目日常运转的"调度层"。

二、三层节奏：日级、事件级、周级

1. 日级（每天 / 每次会话开场）

每次新会话启动时，SessionStart hook 自动渲染一份 4-6 行的状态报告，包含：

• 📦 Buffer 状态（颜色 + 数量）
• ⏰ 待复盘到期项
• 🎯 候选池 top 3（粗排）
• 📅 上次抓热点时间
• ⚠️ 关键 to-do

关键纪律是：hook 只报告，不主动开始任何动作——等用户决定。

这份报告并非"口头约束"，而是由真实 hook 脚本强制执行。查看 hooks/session-start.sh 的实现：它读取.cheat-state.json后依次输出buffer_label（Buffer 行）、retro_label（待复盘行）、candidates_label（候选 top 3 行）、trends_label（上次抓热点行）、calibration_samples与 confidence 等级，最后一行明确写着"（不要主动开始任何动作——等用户决定）"。hook 的注册配置见 hooks/session-start.json——它是同步（async: false）执行的，确保报告在 Claude 第一次回复之前就进入系统上下文。

2. 事件级（T+RETRO_WINDOW_DAYS天到期）

• 任何"已发未复盘 + 时间到"的内容 → SessionStart 报告顶部高亮
• 用户给出数据（粘贴数据 / URL）→/cheat-retro自动跑

RETRO_WINDOW_DAYS的默认值是 3（T+3d），在 cheat-retro/SKILL.md 的 Constants 中定义：短视频快平台可设 1，长文可设 7，可在调用时通过— window: 3|5|7覆盖。hook 脚本中也硬编码了retro_window=3作为兜底默认值（见 hooks/session-start.sh 第 129 行附近），它会逐个读取pending_retros列表中的预测文件、解析**Published at**字段、计算是否已超过复盘窗口，从而得出"待复盘 N 篇（最早：日期）"。

3. 周级（用户决定的"集中处理日"）

用户主动触发的周期性任务：

• 抓热点（/cheat-trends）刷新候选池
• 检查 rubric bump 触发条件
• 清理 STATUS.md / rubric_notes.md 是否需要清算

/cheat-trends的多源抓取机制见 cheat-trends/SKILL.md：默认TREND_SOURCES = ["manual-paste"]，可按— sources: manual-paste,aihot,weibo-hot — max-per: 10覆盖；抓回的热点经过去重 + 粗打分（MIN_COMPOSITE_TO_SUGGEST = 6.0以下不推荐入池）后写入candidates.md，并把last_trends_run_at写回 state。

三、Buffer 警戒规则：颜色背后的数学

1. Buffer 的定义与数据源

Buffer =state.shoots数组长度 = 已拍但未发布的视频数。

这条规则由两个子 skill 配合维护，二者是严格配对的事件：

• /cheat-shoot把视频加进state.shoots（buffer +1），其 Phase 4 的 state 更新 JSON 结构见 cheat-shoot/SKILL.md，每个 entry 包含video_folder、prediction_file、shot_at、script_consistency、script_diff_pct、v2_prediction_written等字段，按shot_at升序排列
• /cheat-publish发布时把对应项从state.shoots移除（buffer -1），其队列处理逻辑见 cheat-publish/SKILL.md：按video_folder匹配本次发布项并移除；若没找到则警告"buffer 队列里没有这条视频"，但不阻塞

两个事件分开处理，使 buffer 跟踪准确——因为视频可以批量拍（一天拍 5 条）、分散发（每天发 1 条），"拍了"和"发了"必须作为独立事件计数。

2. 颜色阈值（按target_publish_cadence_days派生）

核心公式：

buffer_days = buffer_count × target_publish_cadence_days

示例：

• 用户 cadence = 1（日更），buffer count = 0 → buffer_days = 0 → 🔴
• 用户 cadence = 7（周更），buffer count = 1 → buffer_days = 7 → 🔵（一篇够发七天）
• 用户 cadence = 1，buffer count = 4 → buffer_days = 4 → 🟢

这套颜色计算在代码中有两个互为佐证的实现：

一是 hooks/session-start.sh 第 106-126 行的 Bash 实现：当target_cadence为 null 或空时走"灵活节奏"分支（只显示数量不显示颜色）；否则计算buffer_days = buffer_count × target_cadence_int，按<1 红 / ≤2 橙 / ≤5 绿 / 其余蓝四档生成标签，并附带对应的buffer_warning（红色提示"今天必须拍 ≥1 条稳分"，蓝色提示"暂停拍摄，先发存货 + 复盘"）。

二是 cheat-status/SKILL.md 的派生指标描述：Buffer 颜色 = buffer_days = buffer_count × target_publish_cadence_days，<1 红 / 1-2 橙 / 3-5 绿 / >5 蓝，且同样声明"如target_publish_cadence_days=null→ 颜色禁用"。

3. 灵活节奏（target_publish_cadence_days = null）

用户在/cheat-init时若选择"灵活 / 不固定"，则target_publish_cadence_days写入null，此时：

• buffer 监控关闭
• SessionStart 报告只显示"已拍未发：N 条"，不显示颜色，不警戒

hook 脚本对应的分支是if [[ "$target_cadence" == "null" ]] || [[ -z "$target_cadence" ]]→ 输出"📦 Buffer: N 篇 (灵活节奏，无警戒)"（见 hooks/session-start.sh 第 109-111 行）。这个字段的取值来源是/cheat-init的 Q1.6（发布频率问题：日更 1 / 隔日 2 / 每周 7 / 灵活 null），见 cheat-init/SKILL.md，字段语义与读写方契约记录在 state-management.md。

四、选题策略：1 稳分 + 1 实验性

当/cheat-recommend每次推荐 ≥ 2 条时，遵循1 稳分 + 1 实验性原则。

第 1 条（稳分）

• 排序 top 1-3
• 类目与最近 N 条已发不重复，N =max(3, target_publish_cadence_days × 3)——避免审美疲劳
• composite 高 + 议题安全（非 risky）

第 2 条（实验性）

• 候选池里能验证某个待验证假设的样本（如新维度的 A/B 对照）
• 或验证某个新 pattern（script_patterns.template.md 的 Pattern N 格式）
• composite 不一定 top，但有"信息价值"——复盘后能让 rubric / pattern 库前进

在源码层，cheat-recommend/SKILL.md 的 Phase 3 给出了完整排序逻辑：稳分条按composite降序、过滤tier=risky、过滤与最近DUPLICATE_CATEGORY_LOOKBACK（max(3, cadence_days × 3)）天已发/已推过的类目重复后取 top 1；实验性条则寻找"维度组合与最近已发样本差异最大"或"含明确 pattern/dimension hypothesis"的候选，若池中没有合适的实验性样本则回"给你 2 条稳分"。

Buffer 颜色对推荐的覆盖

这套覆盖逻辑在 cheat-recommend/SKILL.md 的 Phase 2.5 中被标为最高优先级：读取state.shoots+state.target_publish_cadence_days算颜色后直接改写推荐行为；蓝色时甚至拒绝推荐（用户可显式说"我就要拍"来覆盖）；灵活模式（target_publish_cadence_days=null）不应用覆盖，走标准策略。

关键约束（任何颜色都遵守）

• 同一 category 连发 ≤ 2 条
• 已发过的 candidate（标 done）不推
• 用户主动跳过的 candidate（标 skip）6 个月内不推

五、节奏元规则：四条优先级

按优先级（高→低）：

1. Buffer 优先于评分：红色警戒时不要因为"等更好的选题"而断更——拍 composite 7.5 的稳分比"等明天的 9.0"安全
2. 复盘优先于新拍：T+RETRO_WINDOW_DAYS到期当天先复盘再考虑拍新的——否则数据信号丢失，rubric 校准受损
3. 同步优先于积压：buffer 满（蓝色）时不要再拍，先发掉再说——已拍议题的时效性会衰减
4. 实验性最多 1/天：每天拍 2 条时至少 1 条是稳分。不要全实验——冷启动期实验失败率太高，伤校准节奏

这四条元规则在cheat-status的触发检测里也有呼应——比如 Buffer 颜色为红或蓝时，cheat-status/SKILL.md 的 Phase 3 会把它列为第一优先级的高优先级警告（红色："buffer 已 0/1 篇，下个发布日可能断更——今天必须拍 ≥1 条。说'推荐选题'我只推 top 1 稳分"；蓝色："buffer 已 N 篇积压。暂停拍摄，先发存货 + 复盘"）。"复盘优先于新拍"同样体现在状态看板中：待复盘项被排在待办区最顶部，并给出"已过 T+3d"的时间提示。

六、标准化"今日工作流"模板

协议将日常决策固化为五个标准场景，每个场景都有明确的入口与分支：

情况 1：buffer 充足 + 没到 T+3d 复盘

SessionStart 报告 → user 决定拍/不拍 ├─ 拍 → "推荐选题" → cheat-recommend 推 2 个 → │ user 选 → /cheat-seed 写 draft (cold-start) 或 user 自己写 → │ user 改写 → script.md → user 拍 → "拍了 videos/<...>/" → cheat-shoot └─ 不拍 → 等

情况 2：buffer 充足 + 到 T+3d 复盘

SessionStart 报告含 ⏰ 复盘提醒 → user 给 video URL 或粘数据 → cheat-retro 自动跑 → 写复盘段 → 检查 bump 触发条件 ├─ 触发 → 提议 /cheat-bump（不强制，用户决定） └─ 未触发 → 等下个验证样本

复盘流程在 cheat-retro/SKILL.md 中完整展开：Phase 7 依据consecutive_directional_errors判定是否提议 bump——默认参考是连续 ≥3 次同向偏差，但 Claude 可以更早（1 次极端偏差 ≥10x）或更晚（3 次同向但每次幅度 <25% 可能只是噪声），提议时显式标注是[default-aligned]还是[judgment-driven]。

情况 3：buffer 红色警戒

🔴 SessionStart 第一行警戒 → user 决定 ├─ 拍 → cheat-recommend 只推 v 当前 top 1 稳分 → 立即拍 └─ 接受断更风险 → user 自负，cheat-status 持续提示

情况 4：buffer 蓝色积压

🔵 SessionStart 报告"积压" → user 决定 ├─ 发 → "已发布 https://..." → cheat-publish → buffer -1 ├─ 复盘 → 见情况 2 └─ 拍新 → cheat-recommend 拒绝："你 buffer 已 N 条，先发掉 ≤3 条再来"

情况 5：周期性集中处理日（用户主动触发）

user 说"抓热点" → cheat-trends → 候选池更新 + user 说"看看 rubric 是不是该升了" → cheat-status 检查同向偏差累计 + user 说"看看 rubric_notes 行数" → cheat-status 健康度检查

/cheat-status的健康度检查阈值定义在其 Constants 中：SQLITE_UPGRADE_THRESHOLD = 30（calibration_samples 达到 N 时建议升级 SQLite）、CLEANUP_LINE_THRESHOLD = 600（rubric_notes.md 行数超 N 时建议清算）、STALE_PREDICTION_DAYS = 30（in_progress prediction 超 N 天未发布提示清理）。状态看板的输出样式可参考 status.template.md 与 cheat-status/SKILL.md 的完整示例。

七、兜底：流程偏离时怎么办

如果某天违反节奏，SessionStart 报告显式标注，而不是静默放过：

❌ 你已 N 天没发新内容（最后一次发布：YYYY-MM-DD）， buffer = 0，你的频道目前处于"事实断更"状态

或：

❌ 你 buffer 已 N 条但还在新拍， 过去 N 条里有 N 条已超过 X 天未发——存在时效性流失风险

系统不会自动尝试补救——只显式报告，由 user 决定如何回到节奏。这与整个项目的"用户驱动"哲学一致：hook 与 skill 提供信息与建议，但从不越权替用户做决定。

从源码看，cheat-status的 Phase 3 检测清单中还有一条与此呼应：state.shoots中最早一项shot_at > 14 天→ "你有视频拍了 N 天还没发——议题时效流失风险，建议尽快发或弃稿"（见 cheat-status/SKILL.md）。

八、子 skill 责任表

节奏协议的正确运转依赖各子 skill 各司其职：

每项责任都能在对应源码中找到落点：/cheat-shoot的 Phase 4append state.shoots（见 cheat-shoot/SKILL.md）、/cheat-publish的 Phase 3shoots队列移除（见 cheat-publish/SKILL.md）、/cheat-status的Buffer 数 = len(state.shoots)派生（见 cheat-status/SKILL.md）。

九、关键差异：cheat-on-content vs 视频分析

协议的末尾给出了与早期"视频分析"类工具的对比，解释了为什么这套设计更适配创作者的真实节奏：

核心差异在于两点：一是 cadence 从"硬编码日更"进化为"用户自填、按发布频率派生阈值"（日更用户 0 篇就红，周更用户 1 篇即蓝，同一颜色在不同 cadence 下含义不同）；二是报告从"自觉遵守的文字约束"升级为"hook 强制渲染"——hooks/session-start.json 中的async: false同步执行保证了每次会话开场报告必然出现。

十、落地路径：如何在自己的项目里启用节奏系统

要把这套节奏协议跑起来，最小路径是：

1. 初始化：运行/cheat-init，在 Q1.6 中回答你的发布频率（日更 1 / 隔日 2 / 每周 7 / 灵活 null），协议据此写入target_publish_cadence_days并安装 SessionStart hook（Q5 默认安装预测锁 + SessionStart 自动报告 + 静默使用日志三个 hook）
2. 日常运转：每次开会话，hook 自动渲染 buffer / 待复盘 / 候选 top 3 / 上次抓热点 / 待办；用户按状态报告决定拍、发或复盘
3. 状态查询：任何时候说"状态"调/cheat-status看完整看板，含 buffer 颜色与进度条
4. 动态调整：发布频率改变时重新 init 或手动修改.cheat-state.json的target_publish_cadence_days字段——颜色阈值会随之自动重算

state.shoots是 buffer 的单一真值来源，其完整字段契约见 state-management.md（v1.2 起shoots[]项扩展了scripts_path、script_consistency、script_diff_pct、v2_prediction_written、script_hash_at_shoot字段，语义见 cheat-shoot/SKILL.md）。整个节奏协议作为共享引用文档，持续被各子 skill 和 hook 引用，是这套内容实验系统能够"自主运转"的调度中枢。

• AI 技能
• AI 应用