繁星媒合體股份有限公司 Vpin AI 落地計劃書
持續修訂版(每月 review 觸發) / Plan of Record。主章節隨執行修訂或取代;月度里程碑 review 觸發版本演進。本文件為 Vpin 與 Arion 共讀的執行依據。
#§0前言
繁星媒合體 Vpin 於 2026 Q2 啟動為期 6 個月的 AI 落地顧問計劃、由馬在飛科技有限公司(以下簡稱 Arion)主導。計劃涵蓋三條業務軸線(產品開發 / 行銷業務 / 公司運營)、目標是讓 AI 進入 Vpin 日常運作、產出可衡量結果、並在計劃結束後 Vpin 內部仍持續使用。
進行方式概述
6 個月內以類 Sprint 節奏推進、每月有 retro 對齊「實際 vs 目標」、計劃書本身為持續修訂版(本文件)、月 retro 觸發改版;若 Review 節點主指標未達或 ROI 不達預期、即觸發退場條件(後段詳述)。
#§1目標
6 個月內、Vpin 在三條軸線上達到可衡量、可持續的 AI 落地狀態。三軸第 6 個月終態如下:
產品開發軸
AI 進入產品發布週期常規流程、節奏縮短、品質不下降。
- Claude-driven 代碼生成 + CI/CD + QA + 反饋迴圈、終態前已穩定 ≥ 1 個月
- 發布節奏縮短 30–50%、bug 比率不上升
- 內部 ≥ 1 位產品工程師能獨立操作 Claude-driven 工作流
- 常規功能開發 ≥ 60% 流程有 AI 介入點
行銷業務軸
漏斗自動化覆蓋、線索與 CAC 雙向改善、業務聚焦高互動段。
- 線索生成 + 初篩 + 培育序列 + CRM 自動更新 全鏈覆蓋
- 月線索量 +30–100%、CAC 下降 ≥ 20%
- 媒合類專屬流程自動化覆蓋 ≥ 50%
- 內部 ≥ 1 位負責人能獨立操作 + 調整自動化規則
公司運營軸
釋出產能轉入高價值業務、Sprint + retro 內生常規化。
- ≥ 5–10 個核心內部流程已導入 AI 自動化
- 每月人時節省可量化、釋出產能投入高價值業務
- 持續修訂文件 + Sprint 循環在 Vpin 內成為常規
- 新進員工可在 1 週內上手此 ops 模式
分析:三軸終態彼此支撐 — 產品節奏提升驅動使用者回饋更快、行銷漏斗自動化推動營收、運營釋出產能注回新業務,構成可持續的內生循環。
#§2執行計劃
6 個月分階段推進、Scrum-like 漸進迭代。三軸(產品 / 行銷 / 運營)共用同一套模式:
度量先行
三軸 baseline 同步量測,作為一切 ROI 比較的錨點。
- 產品:Story point、bug、發布速度
- 行銷:線索量、轉換、CAC、漏斗
- 運營:流程清單、月人時、錯誤率
角色培訓 + 自建 Harness
先讓角色掌握方法、再由該角色主導 Harness 建構。主責歸 Vpin。
- QA / 前端 / 後端 → 品質、規格、CICD Harness
- 行銷 / 數據 / CRM → 線索、分析、整合 Harness
- 流程負責人 / 文件維護者 → Ops Harness
運營 retro
每週 Sprint retro 微調 + 月度里程碑 review 戰略層校正。
- Sprint:1 週、30–45 分、三軸代表 + Nat
- 里程碑:每月、90 分、Chris 必到
- 數據先 / 感覺後 — 無客觀數字不調整
注意:以下內容(baseline 流程 / 角色 ↔ Harness 配對 / 角色分工 / Review 節點等)為預排框架,實際執行依現況調整,所有調整先與 Chris 討論共識後執行。
#§2.1度量先行 — baseline 建立
為什麼先量、不先建工具
AI 工具的價值來自「相對於 baseline 的差距」。無 baseline → 無法判斷工具是否有效、ROI 無法計算、retro 流於主觀。三軸第一個動作均為量化現況。
三軸 baseline 指標
| 軸 | 基礎指標 | AI 介入後追蹤 |
|---|---|---|
| 產品開發 | Story point、品質、bug 數量、發布速度、發布成本 | AI 代碼生成比例、AI 代碼生成速度 / 時間 |
| 行銷業務 | 月線索量、轉換、CAC、漏斗各階段數字 | 自動化覆蓋率、AI 介入後 線索量 / CAC 變化 |
| 公司運營 | 流程清單、月人時 / 流程、錯誤率、上手時間 | 自動化覆蓋率、ops 文件完整度 |
第 1 個月 baseline 建立流程
- Arion(Nat 帶團隊)主導建立 baseline 框架與量測方法
- Chris 提供 Vpin 現況資料當參考(過往數據、員工配置、流程清單)
- 三軸並行:Vpin 三軸指標同時量測、互不阻塞
Baseline 完成的標準
每軸有可重複量測的指標定義 + 至少 1 個月的歷史數字 / 估算值、能與第 3 個月 / 第 6 個月數字比較。
#§2.2角色培訓 → 角色建 Harness
為什麼人先、不是工具先
Harness 是工具 / 流程的組合(自動化、retro 機制、品質檢查等)、不是現成 SaaS。若先導入工具而角色尚未理解使用邏輯、工具利用率低、AI 產出無人審查、問題出現時無主責接續。順序為:先讓角色掌握方法、再由該角色主導 Harness 建構與日常整合。Arion 提供方法、Vpin 角色執行、Harness 主責歸 Vpin 角色。
三軸角色 ↔ Harness 配對
| 軸 | 角色 | 對應 Harness |
|---|---|---|
| 產品開發 | QA | 品質 Harness(自動化測試覆蓋、bug 追蹤回饋) |
| 產品開發 | 前端 | 產品規格 Harness(規格 → AI 生成 → 審查流程) |
| 產品開發 | 後端 | CICD + DevOps Harness(自動建構 / 部署 / 監控) |
| 行銷業務 | 行銷負責人 | 線索生成 Harness(SEO / 社群 / 拓展 自動化串接) |
| 行銷業務 | 數據分析 | 行銷分析 Harness(線索 → 轉換 → CAC 一條鏈量化) |
| 行銷業務 | CRM 負責人 | CRM 整合 Harness(進線派發 + 培育序列) |
| 公司運營 | 各流程負責人 | 該流程的自動化 Harness(報表 / 客服 / 會議摘要 / 對帳等) |
| 公司運營 | 文件維護者 | Ops 持續修訂文件 Harness(流程文件化 + Vpin 內部 retro 機制) |
「保持原本 vs 一次切換 AI 生成」取捨
- 一次切換 AI 生成:快但風險高、問題發生時無 fallback、員工接受度低
- 保持原本 + 漸進切換:慢但穩、員工有漸進切入、不影響業務
- 默認 = 保持原本 + 漸進切換、依角色由該角色評估速度
- 觸發條件:若漸進切換第 3 個月仍未見 AI 生成比例提升 → retro 評估該角色是否加速 / 換方法 / 替換
三軸並行推進(三軸 ≠ 團隊隔離)
三軸是指標 / 分析切面、不是團隊隔離分隔。Vpin 公司整體漸進切入:不同角色(QA / 前端 / 後端 / 行銷 / 數據分析 / 流程負責人...)同時培訓、同時建各自的 Harness、互不阻塞。三軸並行 = 不同角色同時上手、retro 時用三軸檢視指標、規劃全公司的下個 Sprint 任務。
#§2.3運營 retro 機制 — 目標階層 + Sprint 持續調整
為什麼有這層
baseline 量測完成、Harness 建立後、若無定期 retro 用數據檢視、AI 落地會偏離。運營 retro 機制是計劃書(本文件)持續修訂的引擎、用客觀數據持續微調、不等大階段才檢視。
目標階層(由上而下錨點)
→ Product Goal
→ 反推上層
目標的性質 — 不是空泛口號、是運營內客觀情境
- 可衡量(measurable):每個目標都有對應指標(連到 §2.1 baseline)
- 可計算(computable):進度由數據自動算出、不靠主觀判斷
- 可比對(comparable):實際 vs 目標的差距隨時可見、retro 用此差距作依據
- 由上而下錨點:Sprint Goal 服務 Product Goal、Product Goal 對齊 Company Goal — 上層錨點不明確 → 下層 Sprint Goal 失去依據
每週 Sprint retro(營運微調)
- 頻率:每 Sprint(1 週)結束、30–45 分鐘
- 參與:Vpin 三軸代表 + Nat(Chris 視情況、不必每週)
- 輸入:§2.1 baseline 對照本 Sprint 數字、Sprint Goal 完成度、§1 進度
- 輸出:下個 Sprint Goal、是否提報議題至月度里程碑 review
- 原則:數據先 / 感覺後 — 無客觀數字支撐的調整、延至下一輪
- 持續微調:每 Sprint 都是調整時點、不等大階段才行調整
月度里程碑 review(戰略層)
- 頻率:每月一次、90 分鐘
- 參與:Chris + Nat + 三軸代表
- 輸入:§3.1 KPI 月度數字、§3.2 ROI 月度數字、§4.1 Review 節點狀態
- 輸出:是否觸發退場條件(§3.3)、是否調整 Product Goal、計劃書下版需修訂哪些章節
Product Goal 形成機制
不預設固定 Product Goal — Sprint retro 累積結果反推。約 1–3 月(4–12 Sprint)對齊某方向 → 構成下一個 Product Goal、納入計劃書。Scrum 「漸進迭代」精神、非預先規劃中期。
計劃書修訂連動
月度里程碑 review 結論 → Nat 7 日內更新本計劃書版本、儲存歸檔、寄 Chris 確認。Sprint retro 維護在 ops 文件 / Sprint 紀錄、不每週更新計劃書。
#§3成功標準
#§3.1KPI(三軸各自可衡量 + 永續使用證據)
三軸 KPI 對齊 Vision「客戶長期在用、可衡量結果」 — 候選指標、第 1 個月 baseline 後與 Chris 定錨。
| 軸 | KPI 候選 | 第 1 個月 | 第 3 個月 | 第 6 個月 | 永續使用證據 |
|---|---|---|---|---|---|
| 產品開發 | 發布週期時長 + AI 介入覆蓋率 | baseline 建立、首個 PoC 啟動 | 週期縮短 ≥ 20%、覆蓋率 ≥ 40% | 週期縮短 ≥ 30%、覆蓋率 ≥ 60% | ≥ 1 位工程師獨立操作 AI 工作流 |
| 行銷業務 | 月線索量 + CAC | baseline 建立、自動化漏斗啟用 | 線索量 +30%、CAC −10% | 線索量 +50–100%、CAC −20%+ | 行銷負責人獨立調整自動化規則 |
| 公司運營 | 自動化流程數 + 釋出產能投入新業務量 | 試點 1–2 個流程 | ≥ 5 流程、釋出產能可量化 | ≥ 8–10 流程、產出可量化 | 持續修訂文件 + Sprint 循環常規化、新人 1 週上手 |
月度 review:每月 retro 對「實際 vs 目標」、缺口若 ≥ 30% 觸發 §3.3 退場討論。實際數字待第 1 個月 baseline 釐清與 Chris 定錨後填入。
#§3.2ROI 計算框架(效率提升為主軸、非人力成本節省)
本章不寫具體數字的原因
§2.1 baseline 於第 1 個月量測完成、目前無資料、寫數字屬主觀推測。具體數字於 baseline 完成後填入。本章只定方法 + 公式 + 變數定義。
效率主軸的選擇理由
對齊 §5 風險(員工抗拒)、§1 運營軸「釋出產能 → 高價值業務」、Vision「客戶長期在用 + 推介」。「替代人力」邏輯與「員工日常使用 AI」衝突。Vpin 的價值來自同人數產出更高。
計算公式
變數來源
| 變數 | 來源 |
|---|---|
| baseline 月產出量(各軸) | 第 1 個月量測(§2.1) |
| 平均單位產出價值(各軸) | Chris 提供 |
| baseline 月外包費 | Chris 提供 |
| baseline 工具訂閱費 | Chris 提供 |
| AI 介入後對應成本 | Sprint retro 累積 |
預測節奏
- 第 1 個月:baseline 完成、ROI 模型校準首次預估
- 第 2 個月 retro:首次「實際 vs 預估」對照、調整模型
- 之後每月 retro 對照 + 調整
- 預估誤差 ≥ 50%、連續兩月(per §3.3 條件 3、第 2 個月起適用)→ 觸發 ROI 模型修訂
#§3.3退場條件(計劃面、KPI 未達成的判斷邏輯)
計劃面觸發條件
- Review 1(~ 第 2 個月)主指標未達 + 二週緩解對策仍未補回 → 繼續 / 暫停 / 終止三選討論。
- Review 2(~ 第 3–4 個月)主指標未達 + 已替換至少一個原方法 + 新方法下個 Sprint 週期仍未見效 → 繼續 / 暫停 / 終止討論。
- 任一月 ROI 實際 < 預估 50% + 連兩月 → 觸發 ROI 模型修訂 + 三選討論。(第 2 個月起適用、首次預估在第 1 個月 baseline 完成後)
- Chris 主動提出退場 → 即時啟動商業面結算(報價單 §4 結算規則)。
三選定義
- 繼續:修訂主章節、繼續 6 月計劃
- 暫停:暫停 1 個月、雙方審視是否續行
- 終止:啟動報價單 §4 退場付款處理
對齊 Mission:退場條件存在的本身就是「避免 PoC 結案」的機制 — 若永續使用目標未達、即早終止避免延後、避免空耗 6 個月。
#§4時程 里程碑 + RACI
#§4.1Review 節點(對齊 Product Goal 週期)
不預設絕對里程碑 — 持續迭代修正、每 1–2 月一個 review 節點、節點上決定 繼續 / 暫停 / 終止。
| 節點 | 大約時間(以簽約 5/15 為基準) | 動作 |
|---|---|---|
| Review 1 | ~ 第 2 個月(2026-07-15 左右) | 首次「實際 vs 預估」對照(per §3.2)、首次 Product Goal 釐清 |
| Review 2 | ~ 第 3–4 個月(2026-08-15 ~ 09-15) | 退場條件 2 適用時點(per §3.3)、Product Goal 校正 |
| Review 3 | ~ 第 5–6 個月(2026-10-15 ~ 11-15) | 6 個月終態評估、續約 / 退場決定 |
節點時長:1–2 月、Product Goal 週期決定(per §2.3)。Sprint retro 累積結果 → Product Goal 收斂 → review 節點檢視。
節點 = 決策點:繼續(修訂主章節繼續)/ 暫停(暫停 1 月雙方審視)/ 終止(啟動報價單 §4 結算)。決策邏輯 per §3.3 退場條件。
動態調整:節點數與時間依 Product Goal 週期浮動;若連續 2 Sprint 對齊新方向、可提前觸發節點(不必等固定時間)。
#§4.2角色分工(RACI 矩陣)會變 · 視第 1 個月 review 調整
高層 RACI(初版、Vpin 10+ 人小公司情境):
| 工作項 | Arion · Nat | Vpin · Chris | Vpin · 產品軸代表 | Vpin · 行銷軸代表 | Vpin · 運營軸代表 |
|---|---|---|---|---|---|
| 整體計劃書修訂 | R/A | C | C | C | C |
| 三軸進度監督 | R | A | R | R | R |
| AI 工具導入 — 產品 | R/A | I | R | — | — |
| AI 工具導入 — 行銷 | R/A | I | — | R | — |
| AI 工具導入 — 運營 | R/A | I | — | — | R |
| 月度里程碑 review 主持 | R/A | A | C | C | C |
| Sprint 細節執行 | C | I | R | R | R |
| 員工培訓 | R | I | C | C | C |
| Vpin 內部接受度 / 變革管理 | C | R/A | C | C | C |
設計原則
- 軸代表 ≠ 團隊主管:該軸指標的協調者、不是排他主導者。Vpin 任何相關人員都可參與 Sprint retro / 討論。
- Chris 戰略層主責、Sprint 細節留空間:Chris 在月度里程碑 review / 三軸進度層級 A(老闆主責成果)、Sprint 細節執行不介入(I)、讓軸代表與團隊自主執行。
- Arion 主交付 + Vpin 內生主責:AI 工具導入由 Arion-Nat 主交付(R/A)、Vpin 軸代表 R(實際操作)、長期主責在 Vpin。
注意:Vpin 側角色由 Chris 指派、首次 Sprint retro 確認;之後視實際協作微調。
#§5前置注意項 + 動態緩解對策會變 · 月 retro 觸發補入新項
此節列 Vpin 案常見的前置注意項與 Arion 的預備緩解對策;不是合約免責聲明、是月度里程碑 review 動態追蹤的錨點。
| 注意項 | 影響 | 可能性 | 緩解對策 | 負責人 |
|---|---|---|---|---|
| 員工抗拒導 AI | 三軸採納率低、KPI 卡 | 中 | 推動者優先、漸進切換、不一次推翻、§2.1 工作流框架、§3.2 效率框架(非替代人力) | Chris(R) / Nat(C) |
| Chris 內部利害關係人接受度不足 | 工作流調整推不動 | 視內部利害關係人圖譜(初次 Sprint retro 釐清) | 月 retro Chris 親自跑、利害關係人圖譜透明、推動者多點 | Chris(R) |
| 技術可行性誤判(某軸 AI 工具不成熟) | 第 3 個月後 ROI 跑不出來 | 低–中 | 第 1 個月 PoC + 第 3 個月重新評估 + 方法替換機制 | Nat(R) |
| Chris 時間投入不夠 | 月 retro 流於形式 | 中 | 報價單 §4 退場條件 + 月 retro Chris 必到、不能委派 | Chris(R) / Nat(C) |
新項由月度里程碑 review 補入。