AI 副业 Playbook 版本管理：SOP、变更记录、复盘标准

📖 本篇术语速查表

英文 / 缩写	中文	一句话解释
version	版本	某一阶段 Playbook 的固定状态。
changelog	变更记录	记录本次改了什么、为什么改、结果如何。
SOP	标准作业流程	可以重复执行、交接和复盘的步骤。
owner	负责人	对某个流程或字段负责的人。
rollback	回退	新版本不合适时恢复到旧版本。
review cycle	复查周期	定期检查流程是否仍然有效。

读完你能交付：一张《[动作]》Playbook v0.1 卡（版本号 + 5 项适用 + 5 项失效 + 变更记录 + SOP + 回退规则）。一句话锚点：Playbook 没失效条件等于没维护——版本号、适用、失效，三件全有才算资产。

不想读完？把下面这段提示词丢给 AI 帮你跑完——复制提示词，喂给 Codex / Claude Code / Cursor / DeepSeek，把变量改成你的实验结果，AI 会按本文 H2 输出 Playbook 版本草案。

# 角色：副业案例研究 Playbook 版本管理顾问

你是我副业案例研究方向的 Playbook 版本管理顾问。我会把 7 天实验记录 + 原始案例动作 + 当前流程文档交给你，你的工作不是替我执行流程，而是把实验沉淀成 v0.1 Playbook：版本边界 + 适用条件 + 失效条件 + 变更记录 + SOP 检查表 + 复查回退规则。你只做版本管理，不替我执行 SOP、不编实验没发生的结果、不替我决定 Playbook 是否值得长期投入；不允许把"一次性结果"当作通用 Playbook；不允许写没有失效条件的 SOP。

## 核心任务

把 7 天实验记录翻译成一份 v0.1 Playbook：版本号 + 适用条件 + 失效条件 + 变更记录（vs 案例原版）+ SOP 步骤检查表 + 复查时间 + 回退标准 + 下次复查前要收集的字段。


**成功标准**：交付的结果必须同时满足——是否给版本号；适用条件是否 5 项；失效条件是否 5 项（这是关键！）；SOP 检查表是否每步都有动词 + 时长 + 成功标志；有没有把"一次性结果"当通用 Playbook；有没有省略失效条件。 任意一条没满足即视为未达标，需补料后重跑。
## 信息输入

整理之前先看材料齐不齐。

如果原始案例动作和来源 / 7 天实验记录 / 基线 / 改动 / 用户反馈 / 结果、当前流程文档 / 页面 / 模板 / 表格 / 自动化脚本、我的项目阶段 / 适用条件 / 下次复查时间这三件事我能填出 60% 以上，你就直接整理。如果"7 天实验结果"是空的，强制先回 03 子页。

访谈时你要问的就是这五件事：

1. 7 天实验的最终结果是继续 / 调整 / 停止 / 样本不足中的哪一个？（决定 Playbook 该不该建）
2. 实验后我的基线指标变化是多少？（具体数字）
3. 我打算把 Playbook 用在哪些场景？（决定适用条件）
4. 复查频率是每周 / 每月 / 每季度？
5. 如果指标下降到什么程度，我会主动回退？（决定回退标准）

如果 7 天实验结果是"样本不足 / 停止"，强制提醒"不要急着建 Playbook，先补 1 轮实验"；如果指标变化是负的或没差异，强制提醒"实验失败，写 Playbook 是浪费时间"。

## 工作流程

第一步是定义版本边界。在 `<thinking>` 里判断：这次实验是"动作级 SOP（如某个标题模板）"还是"流程级 Playbook（如完整询单到付费 SOP）"？版本号格式 v0.X 表示动作级，v1.X 表示流程级。

第二步是写适用条件（5 项）：

| 条件项 | 写什么 |
|---|---|
| 适用阶段 | 验证 / 增长 / 稳态 |
| 适用平台 | Stripe / Etsy / Twitter 等 |
| 适用价格档位 | 低 / 中 / 高 |
| 适用受众 | 0 受众 / 有受众 |
| 适用类型 | 数字 / 实体 / 订阅 / 服务 |

不满足条件就不该用这版 Playbook。

第三步是写失效条件（5 项 - 这是关键！）：

| 失效信号 | 触发后该做 |
|---|---|
| 指标下降 ≥ 20% | 回退到上一版 |
| 平台规则调整 | 立即复查 + 标记 |
| 工具不可用 | 找替代或重建 |
| 用户反馈 3+ 条负面 | 暂停 + 调研 |
| 复购率连续 2 期低于阈值 | 重新看需求 |

没写失效条件的 SOP 等于没维护。

第四步是写变更记录（vs 案例原版）：

| 版本 | 改了什么 | 为什么 | 证据 |
|---|---|---|---|
| v0.1（我）| 标题改为"具体场景描述" | 案例 30k 受众我 0 受众，原标题不适合 | 7 天点击率 3% → 4.5% |

第五步是沉淀 SOP 检查表（≥ 5 步）：每步都要写"具体动词 + 时长 + 成功标志"。例如"Step 1：用 30 分钟改写标题（标志：标题 < 30 字 + 含 1 个具体场景）"。

第六步是复查和回退规则：

| 项目 | 标准 |
|---|---|
| 复查频率 | 每 2 周 / 每月 / 每季度 |
| 复查指标 | 列 1-3 个核心指标 |
| 回退条件 | 任 1 个失效条件触发 |
| 回退方式 | 用 Day 0 截图恢复 + 通知用户 |

第七步是下次复查前要收集的字段：3-5 项指标 + 用户原话 5 条 + 平台规则变化扫描。

## 示例 / 样板

输入是"7 天实验结果 = 标题改后点击率 3.1% → 4.6%（+1.5pp），样本 230 > 50，结论继续；想用在 Twitter / Substack 落地页；每月复查"。

期望输出：版本号 v0.1（动作级 SOP）。适用条件：阶段验证或早期增长 / 平台 Twitter + Substack 落地页 / 价格档位低-中（$5-50）/ 受众 0-1k / 类型一次性数字产品。失效条件：① 复查时点击率 < 3.7%（-20%）→ 回退；② Twitter 算法调整公告 → 立即扫描；③ Substack 编辑器去掉自定义页面 → 重建；④ 3+ 用户说"标题骗人"→ 暂停；⑤ 复购率连续 2 期 < 10% → 重看需求。变更记录：v0.1 vs 案例 = 标题改为具体场景 + 不用主理人的 emoji（我目标人群是 B 端不爱 emoji）。SOP 检查表 6 步：① 写 3 版候选标题（30 分钟，含具体场景）→ ② 用 5 个目标用户做小测试（24 小时收集偏好）→ ③ 选 1 版上线（30 分钟）→ ④ Day 0 截图基线（5 项）→ ⑤ 7 天观察期不动 → ⑥ Day 7 复盘 + 决定。复查每月 1 次：看点击率 + 询单数 + 收集 5 条用户原话。下次复查前要收集：30 天点击均值 + Twitter 算法公告 + 5 条用户提到标题的原话。

反面例子：写 Playbook 没写失效条件（违反"没维护就是空 SOP"）；把 7 天结果当作长期通用 SOP（违反"先写小版本"）；用"继续优化"代替具体回退方式（违反"具体动词"）；样本不足还要写 Playbook（违反"先补实验"）。

## 输出规范

直接输出《[动作名]》v0.1 Playbook 单正文，不要前言后语，总字数 900 到 1300 字，按以下顺序：

1. **版本号 + 边界**：动作级 v0.X / 流程级 v1.X
2. **适用条件 5 项**：阶段 / 平台 / 价格 / 受众 / 类型
3. **失效条件 5 项**：每项标"触发后该做"
4. **变更记录**：vs 案例原版改了什么 + 为什么 + 证据
5. **SOP 检查表**：≥ 5 步，每步含动词 + 时长 + 成功标志
6. **复查回退规则**：频率 / 指标 / 回退条件 / 回退方式
7. **下次复查前要收集的字段**：3-5 项

输出前自检：是否给版本号；适用条件是否 5 项；失效条件是否 5 项（这是关键！）；SOP 检查表是否每步都有动词 + 时长 + 成功标志；有没有把"一次性结果"当通用 Playbook；有没有省略失效条件。

## 硬约束 · 拒绝场景
- 7 天实验是"样本不足 / 停止"还要建 Playbook → 拒绝
- 不写失效条件的 SOP → 拒绝
- SOP 检查表 < 5 步 → 不合格
- 用模糊动词（如"持续优化"）替代具体动作 → 拒绝
- 占位符 `___` 未替换 → 拒绝

先给结论

Playbook 版本要包含六个字段：

字段	作用
版本号	知道当前用的是哪版
来源	知道来自哪个案例和实验
条件	知道什么时候适用
步骤	知道怎么执行
证据	知道为什么这样做
复查	知道什么时候重新判断

没有版本号，流程会混乱；没有条件，流程会乱用；没有复查，流程会过期。

流程图加载中

Playbook 不是一次性笔记

很多人做案例库，只是把案例看完、整理一页笔记，然后就不再维护。这样的问题是，笔记会越来越多，真正能执行的流程却很少。

Playbook 的价值在于复用。复用需要稳定结构，也需要持续更新。你今天从案例里学到一个页面动作，跑完 7 天实验后，可能得到三种结果：保留、调整、停止。无论哪一种，都应该写进版本。

的核心提醒之一，是小业务不能永远靠主理人临场发挥。你需要把有效动作写成系统，让未来的自己、助理或合作方能重复执行。

对 AI 副业尤其如此。工具变化快，平台入口会变，用户预期也会变。没有版本管理，几周前的“经验”可能很快变成错误动作。

版本管理还有一个现实好处：减少自我怀疑。你不是每次从零判断，而是看上一版为什么这样写、当时证据是什么、这次变化在哪。长期做下来，你会积累一套自己的判断历史。

案例库和 Playbook 的区别也在这里。案例库负责记录别人发生了什么，Playbook 负责记录你打算怎么做、做过后发生了什么、下一版怎么改（实验流程参考 7 天复现实验）。

第 1 步：先定一版只管一件事的边界

版本边界回答：这一版到底管什么。

版本对象	例子
页面	落地页首屏、价格页、FAQ
内容	样品帖、邮件序列、短视频脚本
交付	服务流程、修改边界、客服话术
数据	周复盘表、订单表、退款表
自动化	表单、脚本、提醒、Agent 检查

边界不要太大。不要写“AI 服务获客 Playbook”，先写“AI 内容服务样品页 v0.1”。范围越小，越容易执行和复查。

一个版本只处理一个流程片段。等多个片段稳定后，再组合成更大的 Playbook。

版本边界要写在文件开头。比如“本版本只负责样品页，不负责定价、不负责广告、不负责售后”。边界清楚后，复盘时就不会把无关结果都算到这一版头上。

边界也能保护执行者。别人接手时知道自己只需要维护哪个环节，不会把一个小流程误解成整套业务方案。

第 2 步：用 5 项适用条件圈出可复用场景

适用条件决定流程能不能迁移。

条件	写法
目标人群	适用于有明确内容需求的小团队
产品阶段	适用于已有样品但未稳定报价
流量来源	适用于搜索和私信入口，不适用于冷广告
交付能力	适用于一周能交付少量样品
风险边界	不适用于高合规、高承诺项目

条件写清后，Playbook 才不会被滥用。比如一个样品页流程适用于低风险数字产品，不一定适用于企业咨询；一个低价模板流程适用于轻交付，不一定适用于复杂服务。

强调场景和受众。版本管理就是把场景写进流程，避免你把一个场景下有效的动作迁到另一个场景。

不适用条件同样重要。很多流程失败，不是因为流程差，而是被用在错误场景。比如“样品先行”适合可展示交付的产品，不一定适合高保密咨询；“公开构建”适合能展示过程的项目，不一定适合客户隐私强的服务。

适用条件越清楚，未来复用越安全。

第 3 步：用变更记录留下"为什么改"

每次改动都要回答三件事：

问题	例子
改了什么	在价格页前增加样品入口
为什么改	用户购买前反复问交付质量
结果如何	样品点击增加，咨询问题更具体，但付款仍待观察

变更记录不用长，但必须具体。不要写“优化页面”，要写“把首屏从功能列表改成适用人群、样品和行动按钮”。不要写“效果不错”，要写“用户问题从泛泛咨询变成价格和交付细节”。

变更记录还要记录失败。失败版本很有价值，因为它能阻止未来重复踩坑。

变更记录最好包含用户原话。比如“用户说不知道适不适合自己”，比“用户理解不足”更有用。原话能帮助你下次重写页面，也能避免团队把问题解释得太抽象。

如果变更来自平台规则或工具变化，要写清核验入口。否则下次复查时只知道“改过”，不知道为什么改。

第 4 步：把动作沉淀成 SOP + 检查表

实验有效后，才值得写 SOP。

SOP 字段	写什么
输入	需要哪些资料、页面、用户反馈
步骤	按什么顺序执行
检查	每一步完成标准
输出	最终产物是什么
责任	谁执行、谁复查
风险	哪些情况必须停止

SOP 不是越详细越好，而是让关键动作不丢。新手写 SOP 容易把常识写满，却漏掉真正会出错的地方：适用人群、交付边界、核验入口、退款风险、版本日期。

如果一个流程还没被验证，不要急着写成 SOP。先写成实验记录。稳定之后再固化。

检查表要抓关键风险。比如发布前是否确认适用人群、是否保留旧版本、是否记录基线、是否写清回退规则。不要把检查表写成几十条琐碎事项，真正会影响结果和风险的点要放前面。

对一人项目来说，SOP 的目标不是官僚化，而是减少重复犯错。

第 5 步：用失效条件 + 回退动作保护未来的自己

Playbook 必须能停（具体停止规则参考失败预案和停止规则）。

规则	例子
复查周期	每两周复查一次页面和用户问题
触发复查	平台规则变化、退款增加、入口变化
回退条件	咨询质量变差、支持压力增加、误买增加
保留条件	目标用户问题更具体，交付压力可控

回退不是失败，而是版本管理的一部分。没有回退规则，团队会在错误版本上越走越远。

AI 工具相关流程尤其要定期复查。模型能力、价格、接口、审核和输出风格都可能变化。你不能把一次测试当成长期事实。

复查可以按触发条件走，不一定按固定日历。比如支付入口改了、平台后台变了、退款问题增加、用户问题重复、工具输出质量变化，都应该触发复查。触发式复查比机械复查更贴近业务。

回退后不要立刻删新版本。先保留为失败记录，写清不适用原因。

版本文件也要写负责人。即使是一人项目，也要知道谁负责更新页面、谁负责看数据、谁负责核验平台入口。一个人可以承担多个角色，但角色写清后，复查时不会遗漏关键动作。

如果未来有助理、外包或 Agent 参与，版本管理会更重要。你不能只说“按之前那套做”，要能指向具体版本、具体检查表、具体停止规则。这样协作才不会依赖口头记忆。

版本管理还适合沉淀素材。每次改动留下的用户原话、旧页面、实验截图、失败原因，都会成为后续文章、课程、咨询和内部 SOP 的素材。它不是额外负担，而是把做事过程变成资产。

版本文件要放在固定位置，不要散在聊天记录、临时文档和截图文件夹里。位置固定，后续复查、交接、写文章和做课程时才能找得到。

固定位置本身也是一种流程护栏，能减少后续混乱。

Playbook 版本模板

字段	填写
版本号	v0.1
来源案例	___
实验链接	___
适用条件	___
不适用条件	___
SOP 步骤	___
检查表	___
证据	___
回退规则	___
下次复查	___

每次复查后，版本号可以从 v0.1 到 v0.2。不是所有改动都需要变成 v1.0。只有流程稳定、被多次验证、能交接给别人，才适合升为正式版本。

AI 怎么辅助

AI 适合做版本整理：

把实验记录改成结构化版本说明。
提取适用条件和不适用条件。
生成 SOP 草案和检查表。
从用户反馈里找回退信号。
对比两个版本的变更差异。

AI 不适合替你维护事实。版本日期、后台数据、用户反馈、平台入口和工具表现，需要你提供真实记录。

让 AI 输出时，要要求它保留“未确认”和“需复查”。这样 Playbook 不会被写成过度确定的固定套路。

官方资料与核验口径

平台规则、算法动向、报价规则、政策口径都会变化。本文保留的是可迁移的判断框架，具体数字一律给区间。

跨平台核验入口：

Indie Hackers — 看独立开发者真实营收和复盘
Reddit · r/Entrepreneur — 看副业 / 自雇者的真实问题与反例
Wayback Machine — 回溯案例方在不同时间点的承诺与定价

涉及具体数据、比例、报价区间的部分，以执行当天后台为准。

常见问题

7 天实验结果是“样本不足”，还要不要建 v0.1 Playbook？

不要建。样本不足说明你还没拿到有效信号，写 Playbook 等于把噪声当事实固化。先回去补 1 轮实验（换渠道扩样本或延长观察期），有了信号再建版本。

版本号该写 v0.1 还是 v1.0？怎么区分？

v0.X = 动作级 SOP（如某个标题模板、某段邮件文案）。v1.X = 流程级 Playbook（如完整询单到付费 SOP）。新建一律 v0.1，等同一流程被 2+ 次验证、边界清楚、能交接给别人，才升到 v1.0。

失效条件难写，最容易漏哪几项？

最容易漏 3 项：① 平台规则变化（比如 Twitter 算法调整）② 工具不可用（比如 Stripe 停服或 AI 模型涨价）③ 用户反馈连续 3 条负面。这三项不写，Playbook 会带着旧前提一直跑下去。

Playbook 跑半年都没触发回退，要不要主动升级？

要。即便没触发，也要在复查周期（每月 / 每季度）做一次“还能跑吗”自检，看：基础数据是否还在合理区间 / 适用场景是否还在 / 工具是否还能用。三项有变化就要升版本号，不要硬撑。

执行前至少核验:

Stripe 官方文档 → 海外订阅与支付规则
Shopify 帮助中心 → 电商运营与店铺合规
Buy Me a Coffee → 创作者付费墙参考

AI 副业 Playbook 版本管理：把案例实验沉淀成流程