企业官网建设流程全解析

• AI 技能
• AI 应用

本文以仓库中 skills/cheat-publish/SKILL.md 为主体，结合 shared-references/cadence-protocol.md、shared-references/state-management.md、hooks/prediction-immutability.sh 等配套文档与源码，完整拆解 cheat-publish 的动作边界、四阶段工作流、state 字段契约与拒绝策略。读完你将掌握：如何在「预测段一字不改」的硬约束下完成发布登记、如何解析平台与 platform-specific ID、如何维持 buffer 队列与 pending_retros 的准确性，以及为什么这个轻量动作是整条校准循环中不可跳过的一环。

cheat-on-content 是一套把内容创作变成「可校准实验」的工作流：cheat-predict盲写预测 →cheat-shoot登记拍摄 →cheat-publish登记发布 →cheat-retro回收数据复盘。其中cheat-publish是全链路中唯一的「发布元数据登记点」——它只做一件事：把作品的 URL、发布时间、平台写入预测文件 header 和.cheat-state.json，为 T+3d 后的复盘提供关键上下文。

一、cheat-publish 是什么：一个「轻量登记动作」而非数据回收

从 SKILL.md 的定义看，cheat-publish 的定位极其克制：

• 只更新元数据——把 URL / 平台 ID / 发布时间写入预测文件 header 与 state file；
• 不动预测段任何字符——即使修复笔误也不允许，hook 会拦截；
• 不抓数据——发布登记不是数据回收，那是cheat-retro的活；
• 不写预测内容——与 cheat-shoot 一样，所有预测落盘逻辑都在 cheat-predict，shoot 只负责检测改稿并派发 v2 重判。

它的触发词覆盖中英文日常表达：「已发布」「I shipped」「发布链接是 X」「刚发完 [url]」「publish registered」。默认参数形态为<prediction-file-or-url> [— platform: youtube|bilibili|douyin|...]，允许的工具集为 Bash(*)、Read、Edit、Glob——注意这里没有 Write，因为对已有预测文件的任何覆盖式重写都是被禁止的。

整体流程一览

[用户：已发布 https://...] ↓ [Phase 0: 找到对应的预测文件] ← 通过 in_progress_session 或匹配 ↓ [Phase 1: 解析 URL → 平台/发布时间] ↓ [Phase 2: 更新 prediction 文件 header（仅 metadata 段）] ↓ [Phase 3: 更新 .cheat-state.json，清除 in_progress_session]

两个核心常量

二、Phase 0：找到对应的预测文件

登记前必须先锁定「这篇发布对应哪份预测」。SKILL.md 给出的优先级：

1. 用户参数明确给了 prediction 文件路径 → 直接用；
2. 用户参数只给了 URL → 读.cheat-state.json的in_progress_session.file；
3. 两者都没有 → 列出predictions/*.md中 header 没填published_at的文件，让用户选。

这里依赖的in_progress_session由 [cheat-predict] 在写完预测文件时创建，结构如下（见 state-management.md）：

{ "type": "prediction", "file": "predictions/2026-05-04_a3f2c1d4e5b6_停止期待.md", "started_at": "2026-05-04T14:00:00+08:00", "rubric_version": "v2" }

警告路径：若in_progress_session.file与用户给出的 URL 时间差超过 14 天 → 提示「这个预测写于很久之前，确认是这篇？」，防止把旧预测误登记到新发布上。

从源码结构看，这一阶段的背后逻辑是「state 是各子 skill 共享上下文的单一来源」——state-management.md 明确in_progress_session的唯一写入者是 cheat-predict（创建）、唯一清除者是 cheat-publish（登记时清除）。这保证了「最近一篇预测」与「当前这次发布」的对应关系不会二义。

三、Phase 1：解析平台与发布时间

3.1 平台自动识别表

AUTO_DETECT_PLATFORM=true时按 URL 模式匹配：

注意短链域（b23.tv、xhslink.com、v.douyin.com）也被覆盖——分享场景下用户给的往往是短链。识别不出时不强报（Key Rules #4），询问用户并允许platform: other兜底。

3.2 发布时间获取

• 不强求自动抓——绝大多数平台需要登录态，publish 阶段不引入抓取复杂度；
• 询问用户：「发布时间是？（默认：现在）」→ 接受 ISO 8601 或自然语言（「今天 14:30」/「20 分钟前」）；
• 解析失败 → 用now()。

3.3 platform-specific ID 的提取规则

平台字段不只是给人看的标签——它直接决定复盘时用哪个 perf-data adapter 抓数据，而 ID 是 adapter 的入参。SKILL.md 规定各平台从 URL 提取 ID 的方式：

如果用户给的是分享短链且无法立刻 resolve → 标Aweme ID: pending，下次/cheat-retro时由 adapter 解析。douyin-session adapter 的 README 印证了这一设计：cheat-publish会在登记发布时把 aweme_id 存到 prediction header（如能 resolve），cheat-retro启动时直接读这个字段调用bash run.sh <aweme_id> <video_folder>。

3.4 video folder 的前置检查

到 publish 这一步，对应的videos/<id>/目录应该已经由 cheat-shoot 创建（内含 script.md）。如果不存在，说明用户跳过了拍摄登记：

• 警告「你跳过了 cheat-shoot？建议先跑 cheat-shoot 把拍摄稿登记进 video folder 再发」；
• 询问是否跳过登记直接发：
  • 是→ 自动建一个 video folder（fallback），但不询问稿子一致性，标ad_hoc_publish: true；
  • 否→ 让用户先跑 cheat-shoot 再回来 publish。

从 cheat-shoot 的角度看，这一检查保证了state.shoots[]队列的语义完整——拍了进队列（buffer +1）、发了出队列（buffer -1），两个事件分开使 buffer 跟踪准确（见 cadence-protocol.md）。

四、Phase 2：更新 prediction 文件 header（只动 metadata 块）

4.1 定位 metadata 块

绝不触碰## 预测段及之后。只动文件最顶部的 metadata 块——即第一个##之前的所有行。

读文件后：检查是否已有这些字段——有则警告「已登记过」并询问是否覆盖；无则追加：

**Published at**: 2026-05-04T14:32:00+08:00 **Platform**: douyin **URL**: https://v.douyin.com/abc123 **Video Folder**: videos/2026-05-04_a3f2c1d4_停止期待/ **Aweme ID**: 7234567890123456789 (douyin / 视频号 等需要的 platform-specific ID)

对照 prediction.template.md 的 header 结构可以看到，预测文件顶部本身就是一组**Key**: value的 metadata 块（Article ID / Title / Rubric Version / 预测时间 / Script Path 等），publish 追加的四个字段与它们处于同一段位——这解释了为什么 hook 只保护## 预测之后的区域，而放行顶部编辑。

4.2 用 Edit 而非 Write

SKILL.md 明确要求用 Edit 工具（不是 Write 重写整个文件）。这一约束在 hook 层有硬保障——hooks/prediction-immutability.sh 的拦截逻辑是：

• 只拦截Edit/Write且路径匹配*/predictions/*.md的操作；
• Write一个已存在的预测文件 → 直接 BLOCKED（覆盖式重写必然触碰预测段）；
• Edit则用 awk 定位## 预测/## Prediction（含## 预测 v1、## 预测 v2等版本后缀）到下一个非预测 H2 之间的字节区间，再检查old_string是否落在该区间内，命中则 BLOCKED；
• 该 hook 由 hooks/prediction-immutability.json 注册为 PreToolUse 钩子（cheat-init时合并进用户项目的.claude/settings.json）。

SKILL.md 的预期行为：因为只动 metadata 段（在## 预测之前），immutability hook 应放行。如果 hook 误拦 →报告 bug，不要绕过 hook。（hook 提供CHEAT_BYPASS_IMMUTABILITY=1单次放行通道，但仅限纯 markdown 格式修复，且会写入 stderr 与 git history，属于极罕见例外。）

4.3 为什么预测段必须不可变

这一点从 prediction.template.md 的模板注释可以看得很清楚：## 预测段是 blind prediction（盲预测）的档案，写完即锁死；如要重做，走<本文件名>_redo.md新文件路径，原文件保留。publish 阶段禁止「顺手改预测段」并非保守主义，而是校准实验的数据完整性要求——复盘时对比的是发布时刻冻结的预测，任何事后修改都会让「预测 vs 实绩」的偏差信号失真。

五、Phase 3：更新 state file——字段契约与队列维护

5.1 写回的状态形状

{ "in_progress_session": null, "last_published_at": "<ISO timestamp>", "last_published_file": "predictions/<filename>", "last_published_video_folder": "videos/<...>/", "last_published_platform_id": "<aweme_id 或 BV 号 等>", "pending_retros": [ "predictions/<filename>" ], "shoots": [ // 移除 video_folder 匹配本次发布的项；buffer -1 ] }

对照 state-management.md 的「字段写入责任表」，「谁写谁读」是完全确定的：

这是刻意设计的单一写入者纪律——绝不允许多个 skill 写同一字段，否则状态语义破碎。

5.2shoots队列处理（buffer 跟踪关键）

1. 读state.shoots[]；
2. 找video_folder == 本次发布的 video_folder的项 → 移除；
3. 如果没找到 → 警告「buffer 队列里没有这条视频。是直接发布没经过 /cheat-shoot 吗？」——不阻塞，但提示用户下次走 /cheat-shoot 让 buffer 跟踪准确。

5.3 三个字段的语义

• last_published_platform_id：cheat-retro调 adapter 时的输入——如 douyin-session 需要 aweme_id 直接抓数据；B 站需要 BV 号。它把「publish 时解析的 ID」与「retro 时抓数据」串成一条无重复劳动的链路。
• pending_retros：待复盘列表——cheat-status基于这个列表 +RETRO_WINDOW_DAYS显示「今天该复盘哪些」。
• in_progress_session清除：publish 是这条会话的终点，清空后下一次 predict 才能创建新会话。

5.4 state 写入的工程纪律

state-management.md 定义了所有 skill 共用的写协议，publish 同样遵守：

def write_state(state): state_path = os.path.join(os.getcwd(), ".cheat-state.json") tmp_path = state_path + ".tmp" with open(tmp_path, "w") as f: json.dump(state, f, indent=2, ensure_ascii=False) os.replace(tmp_path, state_path) # atomic rename

三条关键纪律：原子写（写到 .tmp → rename，避免半写损坏）、永远 indent=2（人类可读，便于手改 + git diff）、ensure_ascii=False（保留中文字符）。.cheat-state.json应被纳入 git——它是配置 + 累计指标的快照，多设备同步靠 git push/pull；而.cheat-cache/（usage.jsonl、趋势缓存、adapter 调试文件）与.cheat-secrets.json（cookie / API key）不应入库。

六、Phase 4：登记完成提醒 + 盲度警戒 + buffer 状态

发布登记不是结束，SKILL.md 要求在收尾时输出三块信息：

✅ 登记完成：predictions/2026-05-04_a3f2c1d4e5b6_停止期待.md - Published at: 2026-05-04 14:32 - Platform: douyin - URL: https://v.douyin.com/abc123 📦 Buffer：N 篇（颜色 + 含义） 按你的 cadence（X）= N×X 天 buffer [如颜色变了，提示"现在该去拍/暂停拍"] ⚠️ 从此刻起，你看到任何关于这条作品的播放/点赞/评论数据 都会破坏盲度声明的诚信。如果不小心看到，告诉我—— 我会在文件里追加一个 integrity warning。 📅 计划复盘：T+3d，约 2026-05-07 到时间说："复盘 predictions/2026-05-04_..."

6.1 Buffer 颜色由 cadence-protocol 派生

Buffer 颜色的计算规则固化在 cadence-protocol.md：buffer = state.shoots 数组长度（已拍未发的视频数），buffer_days = buffer_count × target_publish_cadence_days，阈值如下：

示例：用户 cadence=1（日更），buffer count=0 → buffer_days=0 → 🔴；cadence=7（周更），buffer=1 → buffer_days=7 → 🔵。若用户初始化为「灵活节奏」（target_publish_cadence_days = null）→ buffer 监控关闭，只显示「已拍未发：N 条」不显示颜色。

如本次发布让 buffer 跌入红色 → 高亮警告「今天必须再拍 ≥1 条」。这条提醒与 cheat-status 的看板逻辑（buffer_days派生颜色）是同一算法在不同入口的复用。

6.2 盲度警戒是核心不变量

「从此刻起看到任何后续数据都会破坏盲度声明的诚信」——这是 cheat-on-content 区别于普通发布记录的核心设计。盲预测（blind prediction）的价值在于：预测写于数据可见之前，复盘对比才有统计意义。若用户无意中看到了数据，SKILL.md 要求在文件里追加一个integrity warning，而不是静默忽略——这保持了档案的诚实性。

七、Key Rules：五条不可违背的铁律

1. 不动预测段。即使是修复笔误，也不允许在 publish 时改预测段；
2. 不抓数据。publish 是登记动作，不是数据回收（那是 cheat-retro 的活）；
3. state 字段名固定。pending_retros/last_published_at是其他子 skill（特别是 cheat-status / cheat-retro）依赖的契约；
4. 平台未知不强报。无法识别 → 询问用户，允许platform: other作为兜底；
5. 重复登记需明示。已有published_at→ 询问「覆盖？」，绝不静默覆盖。

八、Refusals：三句典型拒绝话术及理由

SKILL.md 为高频诱惑场景预设了明确拒绝路径：

注意第二项并非拒绝——它体现了「必填字段最小化」的务实设计：发布登记最迟可延的只有 URL，发布时间与平台是复盘路由的硬依赖。

九、Integration：publish 在整条校准循环中的位置

• 上游：/cheat-predict（写出 prediction 文件并设 in_progress_session）→ 用户拍摄 →/cheat-shoot（buffer +1）→ 发布 →/cheat-publish（buffer -1、登记元数据）；
• 下游：T+RETRO_WINDOW_DAYS（默认 3 天）后 →/cheat-retro（读 header 的 Platform + Aweme ID / BV 号 等字段，路由到对应 perf-data adapter 抓数据）；
• cheat-status用pending_retros字段计算「今天该复盘哪些」；
• 平台字段被 cheat-retro 用来路由到对应的 perf-data adapter（manual-paste / youtube-data-api / 等）。

从 cheat-retro 的 Phase 0 校验可以看到 publish 的下游依赖：校验文件 header 有Published at→ 没登记的不能复盘，提示用户先/cheat-publish。反过来，如果 publish 时省掉了元数据登记，retro 将无从校验时间窗口、无法路由 adapter——这正是 SKILL.md 拒绝「跳过 metadata 直接清 in_progress_session」的深层原因。

在 cadence-protocol.md 的子 skill 责任表中，cheat-publish 的职责被一句话概括：「从 state.shoots 移除对应项，buffer -1」。与 cheat-shoot 的「把 video folder 加 state.shoots，buffer +1」严格配对——这两个轻量动作共同维护了 buffer 警戒系统的真值来源。

十、实战小结

cheat-publish 看起来只是「写几行元数据」，但在 cheat-on-content 的实验架构里，它是盲度诚信与复盘数据链路的接缝处：

• 对预测档案：它只允许在第一个##之前的 metadata 块追加字段，其余区域由 prediction-immutability hook 硬性保护；
• 对状态文件：它按「单一写入者」纪律清除in_progress_session、pushpending_retros、从shoots移除对应项，并落last_published_*四个字段；
• 对复盘链路：它解析出的 Platform 与 platform-specific ID 是 retro 选择 adapter 的入参，缺失会导致整条数据回收链路断掉。

正确使用姿势可以归纳为三句话：先确认预测文件（走 in_progress_session 或让用户选）→ 只 Edit 顶部 metadata 块并提取平台与 ID → 按契约更新 state 并输出 buffer / 盲度 / 复盘计划提醒。遇到任何「改预测段」的请求，一律引导到_redo.md路径——这不是流程繁琐，而是校准实验的数据完整性要求。

• AI 技能
• AI 应用