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 版本管理：把案例實驗沉澱成流程