繁星媒合體股份有限公司 Vpin AI 落地計劃書

持續修訂版(每月 review 觸發) / Plan of Record。主章節隨執行修訂或取代;月度里程碑 review 觸發版本演進。本文件為 Vpin 與 Arion 共讀的執行依據。

版本 v0.1· 2026-05-15 初版· 最後更新 2026-05-15· 本次變更 — 初版

#§0前言

繁星媒合體 Vpin 於 2026 Q2 啟動為期 6 個月的 AI 落地顧問計劃、由馬在飛科技有限公司(以下簡稱 Arion)主導。計劃涵蓋三條業務軸線(產品開發 / 行銷業務 / 公司運營)、目標是讓 AI 進入 Vpin 日常運作、產出可衡量結果、並在計劃結束後 Vpin 內部仍持續使用。

進行方式概述

6 個月內以類 Sprint 節奏推進、每月有 retro 對齊「實際 vs 目標」、計劃書本身為持續修訂版(本文件)、月 retro 觸發改版;若 Review 節點主指標未達或 ROI 不達預期、即觸發退場條件(後段詳述)。

#§1目標

6 個月內、Vpin 在三條軸線上達到可衡量、可持續的 AI 落地狀態。三軸第 6 個月終態如下:

Axis 1

產品開發軸

AI 進入產品發布週期常規流程、節奏縮短、品質不下降。

  • Claude-driven 代碼生成 + CI/CD + QA + 反饋迴圈、終態前已穩定 ≥ 1 個月
  • 發布節奏縮短 30–50%、bug 比率不上升
  • 內部 ≥ 1 位產品工程師能獨立操作 Claude-driven 工作流
  • 常規功能開發 ≥ 60% 流程有 AI 介入點
Axis 2

行銷業務軸

漏斗自動化覆蓋、線索與 CAC 雙向改善、業務聚焦高互動段。

  • 線索生成 + 初篩 + 培育序列 + CRM 自動更新 全鏈覆蓋
  • 月線索量 +30–100%、CAC 下降 ≥ 20%
  • 媒合類專屬流程自動化覆蓋 ≥ 50%
  • 內部 ≥ 1 位負責人能獨立操作 + 調整自動化規則
Axis 3

公司運營軸

釋出產能轉入高價值業務、Sprint + retro 內生常規化。

  • 5–10 個核心內部流程已導入 AI 自動化
  • 每月人時節省可量化、釋出產能投入高價值業務
  • 持續修訂文件 + Sprint 循環在 Vpin 內成為常規
  • 新進員工可在 1 週內上手此 ops 模式

分析:三軸終態彼此支撐 — 產品節奏提升驅動使用者回饋更快、行銷漏斗自動化推動營收、運營釋出產能注回新業務,構成可持續的內生循環。

#§2執行計劃

6 個月分階段推進、Scrum-like 漸進迭代。三軸(產品 / 行銷 / 運營)共用同一套模式:

PHASE 01

度量先行

三軸 baseline 同步量測,作為一切 ROI 比較的錨點。

  • 產品:Story point、bug、發布速度
  • 行銷:線索量、轉換、CAC、漏斗
  • 運營:流程清單、月人時、錯誤率
PHASE 02

角色培訓 + 自建 Harness

先讓角色掌握方法、再由該角色主導 Harness 建構。主責歸 Vpin。

  • QA / 前端 / 後端 → 品質、規格、CICD Harness
  • 行銷 / 數據 / CRM → 線索、分析、整合 Harness
  • 流程負責人 / 文件維護者 → Ops Harness
PHASE 03

運營 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 機制是計劃書(本文件)持續修訂的引擎、用客觀數據持續微調、不等大階段才檢視。

目標階層(由上而下錨點)

Company Goal Vpin 整體商業目標、三軸方向
半年 – 1 年
負責 Chris
Product Goal Sprint retro 累積反推、隨數據演進
1–3 個月(預設 2)
負責 Chris × Nat × 三軸代表
Sprint Goal 三軸任務並列、Vpin 全公司一個 Sprint
1 週
負責 三軸代表 × 團隊
FEEDBACK
Sprint 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 的價值來自同人數產出更高。

計算公式

ROI 月產值 = 效率提升產值 + 直接成本節省 效率提升產值(主軸) = (AI 後月產出量 − baseline 月產出量) × 平均單位產出價值 產出量定義 依軸: · 產品開發 · 月功能 / 發布數、週期縮短帶來的迭代頻次 · 行銷業務 · 月線索量 + 轉換量 · 公司運營 · 自動化覆蓋流程數、釋出產能投入新業務量 直接成本節省(次軸、非人力) = baseline 月外包費 + baseline 工具 / 訂閱費 − AI 介入後對應月成本(新工具訂閱 + Arion 顧問費等) (員工人時 / 薪資不入此項) 釋出產能(支撐效率提升的中間量) = AI 後員工人時 − 等量工作完成所需 baseline 人時 → 釋出產能轉用於高價值業務、產出在「效率提升產值」內計 投資回收期 = 累計月產值放大 ÷ 78w(投入) 回收月 = 累計月產值放大首次達 78w 的月份

變數來源

變數來源
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 未達成的判斷邏輯)

計劃面觸發條件

  1. Review 1(~ 第 2 個月)主指標未達 + 二週緩解對策仍未補回 → 繼續 / 暫停 / 終止三選討論。
  2. Review 2(~ 第 3–4 個月)主指標未達 + 已替換至少一個原方法 + 新方法下個 Sprint 週期仍未見效 → 繼續 / 暫停 / 終止討論。
  3. 任一月 ROI 實際 < 預估 50% + 連兩月 → 觸發 ROI 模型修訂 + 三選討論。(第 2 個月起適用、首次預估在第 1 個月 baseline 完成後)
  4. Chris 主動提出退場 → 即時啟動商業面結算(報價單 §4 結算規則)。

三選定義

  • 繼續:修訂主章節、繼續 6 月計劃
  • 暫停:暫停 1 個月、雙方審視是否續行
  • 終止:啟動報價單 §4 退場付款處理

對齊 Mission:退場條件存在的本身就是「避免 PoC 結案」的機制 — 若永續使用目標未達、即早終止避免延後、避免空耗 6 個月。

#§4時程 里程碑 + RACI

#§4.1Review 節點(對齊 Product Goal 週期)

不預設絕對里程碑 — 持續迭代修正、每 1–2 月一個 review 節點、節點上決定 繼續 / 暫停 / 終止。

簽約Kickoff 5/15
M1baseline 6/15
Review 1首次對照 7/15
Review 2Product Goal 校正 8/15 – 9/15
M5持續迭代 10/15
Review 3終態評估 10/15 – 11/15
終態續約 / 退場 11/15
產品開發 baseline → Claude-driven 流程 → 內生獨立操作
行銷業務 baseline → 漏斗自動化 → 規則內部調整
公司運營 baseline → 5–10 流程自動化 → 文件 + Sprint 常規化
節點大約時間(以簽約 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
RResponsible 執行者 AAccountable 負責人(框線) CConsulted 諮詢 IInformed 知會(虛線) 不適用

設計原則

  • 軸代表 ≠ 團隊主管:該軸指標的協調者、不是排他主導者。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 補入。