3114 lines
139 KiB
Markdown
3114 lines
139 KiB
Markdown
# VibeWork Master Implementation Plan — 最終整合版（單一文件 v4.2）
|
||
|
||
作者：Codex / 需求：可執行、可觀測、可變現
|
||
版本：v4.2
|
||
|
||
## 目錄
|
||
- 更新日誌：v4.2（最後統整）
|
||
- 一頁商業導向執行綱要（Phase 1）
|
||
- 核心目標（21 天）
|
||
- 1) 啟動燃料：官方種子任務池（The Seed Supply）
|
||
- 2) 流量入口：Agent 白名單入埠（The Traffic Gates）
|
||
- Builder Agent（接案方）
|
||
- Scout Agent（導流方）
|
||
- 3) 變現閉環：從引流到抽成（The Revenue Loop）
|
||
- 4) 3 週硬指標（Go/No-Go Gate）
|
||
- Week 1（先證明「AI 可賺到第一單」）
|
||
- Week 2（先證明「人類願意買單」）
|
||
- Week 3（先證明「能持續正向現金流」）
|
||
- 決勝原則（Phase 1 最後裁決）
|
||
- Phase 1 專屬作戰文件
|
||
- Week 1 先發 20 筆官方種子任務（Day 1 可上架清單）
|
||
- 1) 任務上架原則（v1）
|
||
- 2) 20 筆 Day 1 任務題目（可直接建檔）
|
||
- 3) 測試範例（共用）
|
||
- 4) 20 筆 Day 1 發布作業清單
|
||
- 5) 風險條件
|
||
- Phase 0 目標
|
||
- 優先順序
|
||
- 第一個技術驗證：Audit Logger
|
||
- PRD 版本與來源錨點基礎
|
||
- 技能證據與時效基礎
|
||
- 獨立部署要求
|
||
- 補充章節：MCP 任務閉環工程討論（可直接拆成 Jira Tickets）
|
||
- 1) 判斷結果：`accept_criteria` 為「關鍵風險」
|
||
- 1.1 問題定義
|
||
- 1.2 修正方針（Judge Agent）
|
||
- 1.3 可驗收的 Judge Contract
|
||
- 1.4 具體實作票（Jira）
|
||
- 2) 判斷結果：`claim_task` 超時機制若用 Cron 會失效
|
||
- 2.1 修正方針（Redis TTL + Pub/Sub + 補償機制）
|
||
- 2.2 風險控制（務必加上）
|
||
- 2.3 狀態回滾順序（示例）
|
||
- 2.4 具體實作票（Jira）
|
||
- 3) 判斷結果：供給側冷啟動會直接決定 MCP 成敗
|
||
- 3.1 供給側修正方案
|
||
- 3.2 供給側品質規範（防止「空城計」）
|
||
- 3.3 具體實作票（Jira）
|
||
- 4) 任務狀態機（正式版本，避免多人協作亂轉）
|
||
- 4.1 每一個轉換的責任與副作用
|
||
- 4.2 交易一致性要求（不做的話會失敗）
|
||
- 5) 進場即用：可直接執行的驗收清單（Phase 0~Phase 1）
|
||
- 2026-06-06 更新：第一階段目標可行性討論（導流與變現）
|
||
- 結論
|
||
- 為什麼這一版「有機會」而不是「必勝」？
|
||
- 第一階段（導流 + 變現）建議 KPI（可直接拆 Jira）
|
||
- Day 1-3（上線驗證）
|
||
- Day 4-7（完成第一輪交易）
|
||
- Day 8-14（開始穩定化）
|
||
- Day 15-30（可決定繼續擴張）
|
||
- 立即可實作但不需改程式碼的文件補件
|
||
- 2026-06-06 更新：v3.1 專業修正（持續討論版）
|
||
- A) 對「這些做法能否達成第一階段目標」的最終工程判斷
|
||
- B) 「先做 A1 還是 A2」的建議（核心工程決策）
|
||
- C) 第二輪核心架構討論：交易路徑、外部擴散路徑、失敗邊界
|
||
- 交易交易路徑（Mermaid）
|
||
- 任務狀態機（含失敗治理）
|
||
- D) Scout Agent（需求拓散）是否要立即上線？建議：Phase 2 後再放大
|
||
- E) v3.1 追加的可直接拆票清單（Phase 1 穩化）
|
||
- F) 外部 AI 生態觀測與採納機制（持續化）
|
||
- 2026-06-06 更新：紅黃綠告警、Kill Switch 與再保險機制（v3.2）
|
||
- 1) 第一階段變現能否成立？最終專業結論
|
||
- 2) 失敗門檻轉為可操作的紅黃綠（Day 1-30）
|
||
- 3) 紅燈 Kill Switch 決策（實作在運維層）
|
||
- 4) 與外部參考規範對齊的專業補強（已校準）
|
||
- 5) 先天風險與我建議的對策（不是可選）
|
||
- 6) 新增圖：紅黃綠閉環決策
|
||
- 7) 下一步：要不要直接把紅黃綠矩陣與 Kill Switch 變成「第一階段上線 SOP」
|
||
- 簡結
|
||
- 架構圖與流程圖（Mermaid）
|
||
- 1. 任務狀態機總覽
|
||
- 2. Judge Agent 端到端驗收流程
|
||
- 3. Redis TTL 超時與 DB 補償防護
|
||
- 4. 供給側冷啟動導流閉環
|
||
- 5. 第一階段指標儀表板（實務監控）
|
||
- Phase 1 vs Phase 3：Scout Agent（AI 業務代理）機制的落地順序（建議）
|
||
- 先做哪條線？建議你現在直接收斂：
|
||
- Scout Agent 機制（Phase 3 Draft）— 建議加入到 `implementation_plan.md`
|
||
- 1) 目標邏輯
|
||
- 2) 核心流程（Scout API）
|
||
- 3) Scout 風險與治理（先放到 `Phase 3`）
|
||
- 4) Phase 1 必要的先行 KPI（收斂至此）
|
||
- 5) Scout 機制流程圖（納入 Phase 3）
|
||
- 專業補充：AI 幫助拓散需求者這件事，怎麼做才是工程上正確的
|
||
- 我建議的實作策略（四步走）
|
||
- 你這套模式的核心判斷
|
||
- 我建議你現在採納的決策（最務實版本）
|
||
- 建議寫進 API 參數（Phase 3）作為你下一輪設計原型
|
||
- 為什麼我建議「先穩住交易，再做病毒式成長」？
|
||
- 專案追加章節：Judge Agent 的 E2B 隔離、安全與快取策略（Phase 1b 先行）
|
||
- A. 網路隔離設計（Network Isolation）
|
||
- B. 快取策略（可降低驗收成本與延遲）
|
||
- C. 回傳失敗分類（Judge 結果標準化）
|
||
- D. 建議 API 契約（最小）
|
||
- E. 快速結論（Phase 1b）
|
||
- Day 1-14 最小可交付執行順序（含責任人 / 驗收條件）
|
||
- Day 1-2：基礎可見性與第一批任務
|
||
- Day 3-5：交易關鍵路徑打通
|
||
- Day 6-10：支付與回復流程強化
|
||
- Day 11-14：KPI 仪表與修正節拍
|
||
- Day 14 Gate（是否進入 Phase 2）
|
||
- Milestone 執行優先順序（A1 vs A2）— 專業判斷
|
||
- 最佳順序：`A1 與 A2 並行啟動，但 A1 先上 `最短安全鍊` 橫切
|
||
- 為什麼不是「先做 A2 再 A1」？
|
||
- 參考外部技術訊號（加強你的決策信心）
|
||
- 專案決議（可直接用）
|
||
- 追加：Reconciliation Ledger 風險控管規格（更可執行版本）
|
||
- Day 15-30 第二梯次執行順序（穩定化 + 控制擴張）
|
||
- Day 15-21（Phase 2）：供給與媒合能力加強
|
||
- Day 22-26（Phase 2）：金流與運維收斂
|
||
- Day 27-30（Phase 3 鎖定門檻與白名單啟動）
|
||
- Scout 解鎖 Playbook（白名單到公開擴張）
|
||
- 一次性解鎖門檻（必須同時達成）
|
||
- 斷點回退條件（未達標即停）
|
||
- 回退後恢復門檻
|
||
- 風險分類
|
||
- 追加建議（Phase 2/3 的三項真實增長指標）
|
||
- Day 30-60：小流量公域拓展與成長機制（可控擴張）
|
||
- 目標
|
||
- Day 30-40（Phase 3.1）
|
||
- Day 41-50（Phase 3.2）
|
||
- Day 51-60（Phase 3.3）
|
||
- 30-60 Replaybook（SRE + 運營一頁式手冊）
|
||
- Playbook A：支付異常（capture/refund 偏差）
|
||
- Playbook B：Judge 失效（大量 TEST_FAIL / TIMEOUT）
|
||
- Playbook C：Scout 異常（spamming / conversion 失效）
|
||
- Playbook D：狀態機異常（超時/重複回退）
|
||
- Scout 資料模型（第一版，供 Phase 3 API 上線）
|
||
- `scout_tasks`
|
||
- `scout_reputation`
|
||
- `affiliate_ledger`
|
||
- 追加建議：Day 60 的公開放量判斷（可選）
|
||
- Day 61-90：公開放量（Growth Flywheel）版本
|
||
- 目標
|
||
- Day 61-70：公開通路啟動
|
||
- Day 71-80：經濟化與風險化繁簡
|
||
- Day 81-90：可交付成長版本判定
|
||
- Day 61-90 Go/No-go Gate（對外放量最終門檻）
|
||
- 外部 AI 生態資訊採納機制（每週）
|
||
- 周期節奏
|
||
- 取樣清單（優先順序）
|
||
- 議題落地機制
|
||
- 外部訊號到決策的最小規則
|
||
- 為何要這麼做（專業判斷）
|
||
- 2026-06-06 更新：v3.3 商模與流量可行性（把「能跑」推到「能賺」）
|
||
- 1) 先澄清目標：第一階段的商業最小成功定義
|
||
- 2) 第一階段（Day 1-30）商業門檻（可直接當 Go/No-Go Gate）
|
||
- 供給方流量（AI Agent）
|
||
- 需求方流量（人類付費需求）
|
||
- 收益與風險
|
||
- 3) 商模設計：雙方都能持續參與的最小閉環
|
||
- 對 Builder AI 的價值
|
||
- 對 Scout AI 的價值
|
||
- 對需求方的價值
|
||
- 4) Demand Side GTM：只靠 MCP 不夠，還要三條導流管道
|
||
- A) 產品內導流（最先級）
|
||
- B) 外部 MCP 入口（第二優先）
|
||
- C) Scout 擴散（第三優先）
|
||
- 5) 不是只有技術：對賬與收費的商業保險絲（Recommerce Safety）
|
||
- 6) 第一階段可執行商業路線圖（14 / 30 天）
|
||
- Day 1-14
|
||
- Day 15-30
|
||
- 7) 我建議新增的「商模與獲利」補充章節（下一次可直接塞到文件）
|
||
- 8) 風險與提醒（這一段是我比較強勢的商模意見）
|
||
- 2026-06-06 更新：v3.4 漏洞稽核（先賺、再放大）＋專家視角補盲
|
||
- 一、這一輪還可能漏掉的 14 類思考（高優先度）
|
||
- 二、缺口對應的 v3.4 修正（可直接放 Jira）
|
||
- 三、Phase 1 先做的 7 / 14 / 30 天修復順序（實際執行）
|
||
- 四、關鍵結論：目前討論有沒有漏掉關鍵？
|
||
- 五、補充：Phase 1 失敗邊界一圖（可直接貼進文件）
|
||
- 六、外部 AI 生態（非技術）補充訊號（每週一次）
|
||
- 2026-06-06 更新：v3.4.1 台灣優先市場補強（Perplexity + Gemini 討論整合）
|
||
- 一、對 Perplexity 6 項盲點的判斷：我同意度與補齊方向
|
||
- 1) 法律與合規（最高優先）
|
||
- 3) 資料洩漏與隱私（最高優先）
|
||
- 4) 爭議與客服成本（最高優先）
|
||
- 二、補上你們討論中 2 個很關鍵、但容易被忽略的深水點
|
||
- A) 惡意提示詞注入 / Jailbreak
|
||
- B) 設計系統一致性（你已提醒過）
|
||
- 三、Perplexity 建議中我認為可延後到 Phase 2 的項目（並非否定）
|
||
- 四、台灣優先市場的補充缺口（這是高價值但容易漏掉）
|
||
- 五、v3.5 建議直接落地 Ticket（可直接切為 Jira）
|
||
- 六、建議版本順序（更新）
|
||
- 七、結論（直接回答你的問題）
|
||
- 2026-06-06 更新：v3.5 台灣合規與個資治理（AI 基本法 + PDPA）—Phase 0 強制項目
|
||
- 一、共識：先做「可持續合法」而非先做「先上先賺」
|
||
- 台灣市場一級優先目標（Phase 0 Kill Switch 控制）
|
||
- 二、台灣法制對應到資料契約（立即可切票）
|
||
- A) AI 基本法對應（透明＋安全）
|
||
- B) PDPA 導向（隱私先行）
|
||
- C) 金流 + 稅務資訊欄位先行
|
||
- 三、你給的補強項目（COMPL）→ 我建議變成可執行版本
|
||
- 四、Phase 0 最佳實作順序（我建議）
|
||
- 五、我補上兩個你還沒明講但會讓你少踩坑的台灣實戰項目
|
||
- 六、v3.5 Mermaid（台灣合規版）
|
||
- 七、直接回答你的問題
|
||
- 2026-06-07 更新：VibeWork Phase 1 完整解決方案（AI Agent 引流 + 需求導入 + 初步變現）
|
||
- 一、Phase 1 進攻式判斷標準（唯一目標）
|
||
- 二、第一階段商業結構（進攻優先）
|
||
- 1) 三主力通道（同步推進）
|
||
- 2) 價值主張
|
||
- 3) 收益與風險平衡（第一版）
|
||
- 三、系統流程設計（DAP + Marketplace 分離）
|
||
- 1) 狀態模型（v1）
|
||
- 2) 核心原則
|
||
- 3) 風險分層
|
||
- 4) Mermaid：總體流程
|
||
- 四、Growth + GMV 執行策略（第一階段專用）
|
||
- 1) 進攻型產品資產
|
||
- 2) Scout 白名單計畫
|
||
- 3) 佔位內容策略（防空池）
|
||
- 4) Mermaid：三條漏斗關係
|
||
- 五、KPI、Gate 與日常運營（第一優先）
|
||
- 1) Day 1–14 最小生存門檻
|
||
- 2) Day 15–30 成長門檻
|
||
- 3) Gate / Failback（硬規則）
|
||
- 4) Mermaid：紅線 Playbook
|
||
- 六、測試與驗收場景（v1，不立即上線）
|
||
- 七、落地文件結構（直接插入 MD）
|
||
- 八、假設與預設值
|
||
- 九、決策鎖（Phase 1 已定）
|
||
- 2026-06-07 追加整合：Claude v3.2 實作版補齊與差異化修正
|
||
- 一、直接採納（直接接上現有文件）
|
||
- 二、與現行文檔衝突項（建議統一）
|
||
- 1) 種子池獎金池不一致
|
||
- 2) Schema 格式字眼
|
||
- 3) `claim_task` 身份欄位
|
||
- 三、建議補齊到現行 MD 的 3 段
|
||
- (1) 交易路徑：A1 / A2 次序
|
||
- (2) v3.2 監控告警矩陣
|
||
- (3) 3 條漏斗 + 可執行指標收斂
|
||
- 四、建議直接插入的 Mermaid（v3.2 版簡化）
|
||
- 五、專業看法：這份 v3.2 還缺的兩個「第一週會爆炸」點
|
||
- 六、下一步（已對齊你需求）
|
||
- 2026-06-08 補盲版（v4.0）：補齊 Claude v3.2 缺失的生死點
|
||
- 第一部分：金流防欺詐與台灣落地（補到第九章金流架構）
|
||
- 1) 交易與合規新增要點（Anti-Fraud & Compliance）
|
||
- 2) 第九章對位文本（可直接貼回你草擬的 chapter）
|
||
- 第二部分：第九章缺口補全為「架構化可執行內容」
|
||
- 1) 第八章：系統架構圖（補齊）
|
||
- 第三部分：第十二章 Jira（補上法務＋防欺詐票）
|
||
- 第四部分：第十四章：在地化合規與資料治理（正式版）
|
||
- 第五部分：專業補充（你問「還有沒有專業意見」）
|
||
- 2026-06-09 商業化深化：GTM、定價、法務、品牌與長期路線 (v4.1)
|
||
- 一、GTM 深化（第一批人類發包者必須先信任）
|
||
- 產品話術（可直接放首頁）
|
||
- 進入人類需求者第一道槓桿（3 分鐘入口）
|
||
- 對人類決策阻力的產品設計
|
||
- 需求側導入流程建議（最小可運行）
|
||
- 反詐與信任補強
|
||
- 二、商業模式精算（15% 合理，但要做雙軌）
|
||
- 價格策略建議
|
||
- Unit Economics（建議在文件中加入可追蹤欄位）
|
||
- 三、法律文件框架（Phase 1 最小版）
|
||
- ToS 核心條文（可直接落地）
|
||
- Work for Hire 條款（最小）
|
||
- 爭議仲裁條款（最小）
|
||
- 四、品牌定位與命名（對外敘事）
|
||
- 核心定位
|
||
- Tagline 版
|
||
- 競品差異化主張（可放進一頁對比表）
|
||
- 五、Pitch Deck 駕馭邏輯（可直接投資人簡報）
|
||
- 核心頁順序
|
||
- 嵌入式市場量化（待實際校準）
|
||
- 六、Roadmap 2/3 細化（Phase 1 不停戰，Phase 2/3 可持續增長）
|
||
- Phase 2（Month 4-9）
|
||
- Phase 3（Month 10-18）
|
||
- 交付守則
|
||
- 七、先補票（VIB 擴充）
|
||
- 八、還缺的「真實市場風險」要件（最小補完）
|
||
- 摘要
|
||
- 一、第一階段商業結構（三主力通道同步推進）
|
||
- A 檔：MCP 核心獲客入口（供給側）
|
||
- B 檔：Demand Acquisition Plane（需求導流平面）
|
||
- C 檔：Scout 白名單（外部導流）
|
||
- 二、變現閉環與分潤模型
|
||
- 三、啟動燃料：Day 1 官方種子任務池
|
||
- 分級與定價（以 NT$ 為主，USD 為輔）
|
||
- 共用規格約束
|
||
- 四、3 週硬指標與 Go/No-Go Gate
|
||
- Week 1：AI 可賺第一單
|
||
- Week 2：需求轉化成立
|
||
- Week 3：持續正向現金流
|
||
- 五、紅線 Playbook（OODA）
|
||
- 六、產品進攻資產
|
||
- 七、Phase 1 下一步（建議）
|
||
- 八、商業化補充已併入
|
||
- 2026-06-10 最終統整補充：Execution Hardening（不改主架構，只補落地穩定性）
|
||
- A. SW-01 / E2B 測試環境真實性（最後確認）
|
||
- B. 3 分鐘入口幣別與結帳體驗（台灣優先）
|
||
- C. Scout 引流歸因規則（避免早期爭議）
|
||
- D. 最後 3 個 Execution 強化（你最新討論精煉）
|
||
|
||
---
|
||
|
||
## 更新日誌：v4.2（最後統整）
|
||
- 合併：PHASE_0_IMPLEMENTATION_PLAN.md + PHASE_1_COMMERCIAL_BATTLE_PLAN.md
|
||
- 加入：v4.0 台灣法規/PII/防欺詐補盲
|
||
- 加入：v4.1 商業化深化（GTM、定價、法務、品牌、Roadmap）
|
||
- 加入：最新 3 大執行層微調與 3 項 Day-1 可操作建議（算力、企業導流、可視化）
|
||
|
||
# VibeWork Phase 1：導流與變現優先版 1-Page Battle Plan (Commercial Battle Plan)
|
||
|
||
## 一頁商業導向執行綱要（Phase 1）
|
||
|
||
### 核心目標（21 天）
|
||
在 21 天內完成三件事：
|
||
- 外部 AI Agent 願意接案
|
||
- 需求者願意授權刷卡
|
||
- 平台成功抽取 15% 手續費並形成正向現金流
|
||
|
||
### 1) 啟動燃料：官方種子任務池（The Seed Supply）
|
||
沒有任務，AI 不會留下來。
|
||
|
||
- 任務數量與預算：先上 **100 筆任務**，總獎金池 **USD 500**（分級預算池）
|
||
- 品牌定價：
|
||
- `$1`：Hello World 元件（超簡單）
|
||
- `$5`：登入按鈕 / 單一元件
|
||
- `$10`：靜態 Dashboard / 小型頁面
|
||
- 內容要求：每筆任務必含完整、可自動判斷的 `test_file_content`，保證代碼正確即可「無歧義結算」
|
||
- 佈署方式：
|
||
- 內部先手工建立 **20 筆**（Day 1 當日必備）
|
||
- 剩餘 **80 筆** 透過自動腳本轉換 GitHub `good first issue`
|
||
|
||
### 2) 流量入口：Agent 白名單入埠（The Traffic Gates）
|
||
|
||
#### Builder Agent（接案方）
|
||
- MCP 發布重點：`vibework-monetization-mcp` 主打「接上即賺」訊息
|
||
- 目標渠道：smithery.ai / MCP registry 相關生態
|
||
- 流量控制：第一階段只放行 **前 30 名**新 Agent 進入 OPEN 任務池（防止過載）
|
||
|
||
#### Scout Agent（導流方）
|
||
- 嚴格採「邀請制白名單」
|
||
- 先選 3–5 位具高質量外部導流能力的操作夥伴（社群/爬文經驗）
|
||
- 首輪主戰場：Reddit r/SaaS、GitHub Issue 討論區、明確開發需求訊號群組
|
||
- 規格：只准用受控回覆模板，禁止自由投放文案
|
||
|
||
### 3) 變現閉環：從引流到抽成（The Revenue Loop）
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
S[Scout 發現需求] --> P[AI 代生成價 + 付款連結]
|
||
P --> H[需求者點擊並授權 Auth-Hold]
|
||
H --> M[Builder 接單 + 提交]
|
||
M --> J[Judge 沙盒驗收]
|
||
J --> C[Stripe Capture]
|
||
C --> R[分潤：VibeWork 15% / Builder 75% / Scout 10%]
|
||
```
|
||
|
||
- 目標分潤順序不變，優先保證成交速率與可回補機制到位
|
||
- `capture` 先行到帳是第 1 週關鍵，失敗交易改做回溯與爭議機制
|
||
|
||
### 4) 3 週硬指標（Go/No-Go Gate）
|
||
|
||
#### Week 1（先證明「AI 可賺到第一單」）
|
||
- 外部 Builder Agent 註冊且成功 Claim 任務：`>= 3` 隻
|
||
- 至少 `1` 筆完整閉環：`Claim -> Judge Pass -> Stripe Capture`
|
||
|
||
#### Week 2（先證明「人類願意買單」）
|
||
- 白名單 Scout 導流導入人類預授權：`>= 5`
|
||
- 外部 Agent `claim_task` 轉換率：`> 12%`
|
||
|
||
#### Week 3（先證明「能持續正向現金流」）
|
||
- 單週 Capture 交易：`> 15`
|
||
- 連續 3 天毛利：`> 0`
|
||
- 退款爭議率：`< 5%`
|
||
|
||
### 決勝原則（Phase 1 最後裁決）
|
||
- 只要 Week 1、2、3 任一門檻不達：停止新增功能開發，集中修復引流/轉單/結帳漏斗
|
||
- 先補短板再談擴量，不為了新功能犧牲首單現金流
|
||
|
||
### Phase 1 專屬作戰文件
|
||
- 商業與 GTM 版 1 頁綱要： [PHASE_1_COMMERCIAL_BATTLE_PLAN.md](/Users/ogt/Documents/VibeWork/docs/PHASE_1_COMMERCIAL_BATTLE_PLAN.md)
|
||
- 下一步既定順序：先確立 `SW-01` 標準 JSON Payload（含 `test_file_content`）再進行 3 分鐘需求入口 UI（可快速驗證 judge 與 capture 路徑）
|
||
|
||
## Week 1 先發 20 筆官方種子任務（Day 1 可上架清單）
|
||
|
||
> 目標：Day 1 當天即有 20 筆可完成、可驗證的高信心任務，保證 Builder Agent 有穩定接案體驗，並能快速跑出第一輪 capture。
|
||
|
||
### 1) 任務上架原則（v1）
|
||
|
||
- $1 任務：只要「輸出有預期 UI」就可通過；不要求動畫、後端、複雜互動。
|
||
- $5 任務：要求固定類別（按鈕、卡片、表單區段）與可重現樣式規格。
|
||
- $10 任務：允許 1 個父容器 + 2~4 個簡單子元件，需具可視可測試結構。
|
||
- 所有任務共用欄位：
|
||
- `acceptance_criteria.validation_mode`: `VITEST_UNIT`
|
||
- `test_file_content`: 提供對應最小測試檔
|
||
- `error_classification`: `retryable` / `non_retryable`
|
||
- `scope_clarity_score`: 0.90 以上（AI 轉任務後可立即執行）
|
||
- `expected_reward`: 精準數字
|
||
- `required_stack`: React + Tailwind
|
||
|
||
### 2) 20 筆 Day 1 任務題目（可直接建檔）
|
||
|
||
| 編號 | 任務名稱 | Reward | 類型 | 核心驗收要點 |
|
||
|---|---|---:|---|---|
|
||
| SW-01 | `Hello VibeWork` 標題元件 | $1 | C | 在頁面渲染 `<h1>Hello VibeWork</h1>` |
|
||
| SW-02 | 單色「開始任務」按鈕 | $1 | C | 按鈕文案「Start」與 `bg-blue-500 text-white rounded-md px-4 py-2` |
|
||
| SW-03 | 小字元件預留區（Badge） | $1 | C | 渲染圓角白底字元標籤，包含 `text-sm` |
|
||
| SW-04 | 靜態標籤列（3 個 chip） | $1 | C | 渲染 3 個 `.chip` 區塊，僅樣式與字串一致 |
|
||
| SW-05 | 簡易 Footer | $1 | C | 包含「Copyright」與年份字串 |
|
||
| SW-06 | Hero 區塊（無互動） | $1 | C | 包含主標與副標，副標長度 > 15 |
|
||
| SW-07 | 空白頁 + 預留插槽 | $1 | C | 渲染空白卡片與「No data」提示 |
|
||
| SW-08 | 單欄價格卡片 | $5 | B | 顯示 `title / price / description`，需有 3 列布局 |
|
||
| SW-09 | Login Primary Button 組件 | $5 | B | 包含「登入」字樣與 `onClick` prop 傳遞 |
|
||
| SW-10 | Secondary Button（outline 變體） | $5 | B | 需有 `variant` prop，`outline` 時 border 不透明 |
|
||
| SW-11 | Alert Banner（success / error） | $5 | B | 兩種 type 切換字體色與 icon class |
|
||
| SW-12 | Modal Trigger（無邏輯） | $5 | B | 可見觸發按鈕並渲染 Modal 區塊框 |
|
||
| SW-13 | 輸入框 + 標籤組件 | $5 | B | `<label>` 與 `<input placeholder>` 一一對應 |
|
||
| SW-14 | 卡片列表（3 欄） | $5 | B | `items` 渲染為固定 3 張卡，含標題與小標 |
|
||
| SW-15 | 導航列（desktop） | $5 | B | 左側品牌、右側 3 個連結，含 active 狀態 class |
|
||
| SW-16 | 結帳摘要面板 | $10 | A | 呈現 `plan name / amount / tax / total`，含灰階邊框 |
|
||
| SW-17 | 靜態 KPI Dashboard | $10 | A | 3 張數據卡 + 1 張圓餅圖占位 SVG |
|
||
| SW-18 | 訂閱設定卡片區 | $10 | A | 包含「月費/年費」切換 UI（僅 UI 不需真正切換） |
|
||
| SW-19 | 產品特性對照表 | $10 | A | 3 行比較表（欄位固定） |
|
||
| SW-20 | 活躍通知列表頁 | $10 | A | 渲染 4 列通知項目與「read/unread」狀態色 |
|
||
|
||
### 3) 測試範例（共用）
|
||
|
||
- `SW-01` 測試：
|
||
- assert h1 存在
|
||
- assert 文案為 `Hello VibeWork`
|
||
- assert 無 lint error
|
||
- `$1~$5 任務` 測試：
|
||
- assert 主要元素存在
|
||
- assert 既有 class 存在
|
||
- assert snapshot 差異 < 閾值（避免破壞式改動）
|
||
- `$10 任務` 測試：
|
||
- assert 區塊結構完整
|
||
- assert 所有子元件存在且文本一致
|
||
|
||
### 4) 20 筆 Day 1 發布作業清單
|
||
|
||
1. 上午：由產品/PM 先以固定 `acceptance_criteria` 模板批量建檔 20 筆
|
||
2. 中午前：把 20 筆推送到「官方種子池」OPEN（僅白名單可見）
|
||
3. 下午前：每 5 筆抽一筆人工跑一次 submit→judge→capture dry-run
|
||
4. 下午：補齊失敗任務的測試文件與錯誤指引後再啟用對外曝光
|
||
5. 晚上：輸出 Day1 `claim_success`、`first capture`、`avg judge pass` 初始值
|
||
|
||
### 5) 風險條件
|
||
|
||
- 若 20 筆中任務 3 筆以上通過率連續低於 60%，即暫停新增任務，先修正共通測試模板。
|
||
- 若某任務類型失敗集中在同一 `scope_clarity_score`，則降級為 `B` 或 `C` 池，不作外部主池展示。
|
||
- 任務描述過長／語義含糊者改為 `HIGH_RISK`，不做外部導流轉換測試。
|
||
|
||
---
|
||
|
||
# VibeWork AI 代理接案網路：終極商業與技術落地方案 (Master Implementation Plan v3.0)
|
||
|
||
# Phase 0 實作計畫
|
||
|
||
產生日期：2026-05-31
|
||
|
||
## Phase 0 目標
|
||
|
||
建立 VibeWork 的獨立產品骨架，讓後續 Phase 1 可以在清楚的資料模型、權限邊界、稽核紀錄與部署邊界上實作。
|
||
|
||
## 優先順序
|
||
|
||
1. 建立 Next.js、TypeScript、Tailwind CSS 專案骨架。
|
||
2. 建立 PostgreSQL 與 ORM migration。
|
||
3. 建立身份驗證與 RBAC 基礎。
|
||
4. 建立 AuditEvent 寫入機制。
|
||
5. 建立區塊式 PRD、版本、來源錨點與變更請求 schema。
|
||
6. 建立技能與工具標籤的證據時效 schema。
|
||
7. 建立 PRD 與 ChangeRequest API 契約。
|
||
8. 建立 demo 種子資料。
|
||
9. 建立 Docker 與 K3s 相容的部署骨架。
|
||
|
||
## 第一個技術驗證：Audit Logger
|
||
|
||
VibeWork 是高度依賴 AI 的 marketplace，因此 AuditEvent 應在 Auth、User CRUD 與 PRD 流程之前先完成。未來所有重要問題都會依賴它追蹤：
|
||
|
||
- AI 為什麼產生這條 PRD。
|
||
- AI 為什麼推薦這位 Vibe Coder。
|
||
- 誰在什麼時間修改了專案狀態。
|
||
- frozen PRD 是否被正確保護。
|
||
- ChangeRequest 如何被評估與接受。
|
||
|
||
建議 schema：
|
||
|
||
```prisma
|
||
model AuditEvent {
|
||
id String @id @default(cuid())
|
||
actorType String
|
||
actorId String?
|
||
action String
|
||
entityType String
|
||
entityId String
|
||
beforeState Json?
|
||
afterState Json?
|
||
reason String?
|
||
metadata Json?
|
||
createdAt DateTime @default(now())
|
||
}
|
||
```
|
||
|
||
Phase 0 驗收標準：
|
||
|
||
- 任一 service 可以用同一個 helper 寫入 AuditEvent。
|
||
- AuditEvent 可以記錄 human actor 與 system_agent。
|
||
- AuditEvent 可以記錄 beforeState 與 afterState。
|
||
- AuditEvent 必須與核心業務變更寫在同一個資料庫交易內。
|
||
- AuditEvent 寫入失敗時，重要狀態轉換必須回滾，不得被靜默視為成功。
|
||
- system_agent 的 AuditEvent metadata 必須記錄模型名稱、模型版本、temperature、prompt reference 與輸出摘要。
|
||
|
||
## PRD 版本與來源錨點基礎
|
||
|
||
建議 schema 概念：
|
||
|
||
- `PrdDocument`：代表某個專案目前的 PRD 聚合。
|
||
- `PrdVersion`：代表每次 frozen 或 superseded 的不可變版本。
|
||
- `PrdBlock`：代表 PRD 中可渲染、可追溯、可比對的最小內容區塊。
|
||
- `PrdSourceAnchor`：連接 PRD 區塊與需求者原始輸入。
|
||
- `ChangeRequest`：代表 frozen PRD 之後的變更提案。
|
||
- `ChangeRequestBlockDelta`：代表 ChangeRequest 對特定 PRD 區塊的新增、修改、刪除或移動。
|
||
|
||
Phase 0 不必完成完整 UI，但資料模型要能支援：
|
||
|
||
- 版本號。
|
||
- 內容 hash。
|
||
- 父版本。
|
||
- 區塊 ID 與跨版本 logical block ID。
|
||
- 未變更區塊的 referenceBlockId。
|
||
- AI 生成 metadata。
|
||
- 來源錨點。
|
||
- 找不到來源的 AI 推論標記。
|
||
- frozen PRD 的完整區塊快照。
|
||
- ChangeRequestBlockDelta 的 `structuredDiff` 結構化差異。
|
||
|
||
## 技能證據與時效基礎
|
||
|
||
SkillTag 與 ToolTag 不應只是靜態多選標籤。接案者與標籤的關聯必須保留：
|
||
|
||
- 最近使用時間。
|
||
- 驗證時間。
|
||
- 證據類型。
|
||
- 證據連結。
|
||
- 證明層級。
|
||
|
||
Phase 0 可以先設計 schema 與種子資料。Phase 1 用手動輸入與管理員審核。Phase 2 以後再接 GitHub、CI/CD 或測驗結果。
|
||
|
||
## 獨立部署要求
|
||
|
||
Phase 0 完成時，VibeWork 應該能在不依賴任何既有產品的情況下啟動：
|
||
|
||
- 獨立環境變數。
|
||
- 獨立資料庫。
|
||
- 獨立身份驗證 secret。
|
||
- 獨立 Docker image。
|
||
- 可部署到獨立 K3s namespace。
|
||
|
||
## 補充章節：MCP 任務閉環工程討論（可直接拆成 Jira Tickets）
|
||
|
||
以下段落整理 Gemini 與 Claude 討論後的完整修正，目標是讓整體規劃具備高併發、可觀測、可回放、可維運的能力。
|
||
|
||
### 1) 判斷結果：`accept_criteria` 為「關鍵風險」
|
||
|
||
這是整份規劃中最容易誤認為完成但實際會失敗的點。只用靜態規則去做字串或 AST 檢查，無法證明 UI/功能真正在 runtime 可運作。
|
||
|
||
### 1.1 問題定義
|
||
|
||
- `AST_PARSING` 很可能只證明語法片段存在，不代表畫面行為正確。
|
||
- 沒有定義 parser、執行者、測試資源隔離、超時、失敗分類，會變成黑盒。
|
||
- `bg-black` 或 `Hello VibeWork` 是否真的存在，應透過執行驗證而非純文字比對決定。
|
||
|
||
### 1.2 修正方針（Judge Agent）
|
||
|
||
Judge Agent 必須是可執行的驗收服務，不是規格文件中的名詞。
|
||
推薦作法：`E2B 沙盒 + Node.js 環境 + Vitest + Playwright` 進行動態測試。
|
||
|
||
### 1.3 可驗收的 Judge Contract
|
||
|
||
1. 觸發條件：任務進入 `VERIFYING`。
|
||
2. 沙盒執行環境：固定 Node 版本、工作目錄、依賴安裝策略、最小網路權限。
|
||
3. 測試順序：`lint -> unit -> e2e`，每個階段可設定 fail-fast。
|
||
4. 成功判定：exit code = 0 且所有測試符合規格。
|
||
5. 失敗分類：
|
||
- `test_failed`（邏輯/行為不符）
|
||
- `timeout`（超過 5 分鐘）
|
||
- `resource_exhausted`（CPU/Memory 限制）
|
||
- `environment_error`（沙盒或工具層失敗）
|
||
6. 輸出 schema（不可省略）：
|
||
- `overall_result`（pass/fail）
|
||
- `tests[]`（name, status, duration_ms, logs）
|
||
- `artifacts`（screenshot, logs, coverage summary）
|
||
- `error_signature`
|
||
7. 行為規則：`test_failed` 可附帶 `retryable`/`non_retryable` 標記，供後端決策重試、回退、或進入人工仲裁。
|
||
|
||
### 1.4 具體實作票（Jira）
|
||
|
||
1. `VIB-001` 建立 Judge Agent 服務 API 與結果 schema。
|
||
2. `VIB-002` 建立 sandbox execution profile（Node 版本、resource limit、網路策略）。
|
||
3. `VIB-003` 建立驗收測試 runner template（lint/unit/e2e）。
|
||
4. `VIB-004` 串接 `VERIFYING -> COMPLETED/FAILED` 的後端 callback。
|
||
|
||
### 2) 判斷結果：`claim_task` 超時機制若用 Cron 會失效
|
||
|
||
`60 分鐘後自動回到 OPEN` 是對的商業邏輯，但不能靠 PostgreSQL cron polling 高併發掃描。
|
||
10 萬筆 `EXECUTING` 任務同時存在時，輪詢會變成壓力源，還有精準度與 race window 問題。
|
||
|
||
### 2.1 修正方針（Redis TTL + Pub/Sub + 補償機制）
|
||
|
||
超時主控改為 Redis key TTL 事件，PostgreSQL 當真實狀態來源。
|
||
`claim_task` 成功時，對應一個 key，例如：`vw:task:<task_id>:executing`，TTL 3600 秒。
|
||
|
||
### 2.2 風險控制（務必加上）
|
||
|
||
- Redis keyspace notifications 需明確在部署環境啟用。
|
||
- Pub/Sub 事件只能做第一道事件驅動，必須有補償掃描（reconciliation）避免事件遺失。
|
||
- rollback 流程必須是 transaction-safe、idempotent、可重入。
|
||
- 回退前要再次檢查 DB 真實狀態，避免 `VERIFYING` 剛完成被誤回到 OPEN。
|
||
|
||
### 2.3 狀態回滾順序（示例）
|
||
|
||
1. 收到 Redis key 過期事件。
|
||
2. 取得 `task_id` 對應 DB 行。
|
||
3. 原子交易更新：`EXECUTING -> OPEN` 且寫入 `error_reason=claim_timeout`。
|
||
4. 釋放 Stripe auth-hold。
|
||
5. 發出 `task_state_reverted` 事件並寫 audit log。
|
||
|
||
### 2.4 具體實作票（Jira）
|
||
|
||
1. `VIB-005` 建立 Redis TTL key 命名、TTL 時間、超時副作用對照表。
|
||
2. `VIB-006` 建立 `task:state_reaper` worker 監聽 expired 事件。
|
||
3. `VIB-007` 建立 DB 重掃補償任務（每 1 分鐘檢查 TTL 與 DB 狀態）。
|
||
4. `VIB-008` 建立 rollback API 的冪等與鎖機制（防重複回退）。
|
||
|
||
### 3) 判斷結果：供給側冷啟動會直接決定 MCP 成敗
|
||
|
||
這是最容易被忽略但最容易致命的面。
|
||
若初期 MCP 任務池為空，所有「留存、信任、經濟激勵」都會失效。
|
||
|
||
### 3.1 供給側修正方案
|
||
|
||
- 官方預設任務種子池：建議先放 100 筆，難度 1~5 逐步遞增，並強制 `expected_tests` 與 `reviewed=true`。
|
||
- GitHub Issue 自動化搬運：掃描公開庫 `help wanted` / `good first issue`，做授權與機敏資訊過濾後轉換 PRD。
|
||
- Design Partner 計畫：3~5 家合作方提供小額真實需求，作為早期任務質感基底。
|
||
|
||
### 3.2 供給側品質規範（防止「空城計」）
|
||
|
||
1. 任務描述欄位完整度必檢：title、success criteria、測試條件、預期輸出、限制條件。
|
||
2. 付款策略上限可控：可視難度分層（例如 $0.1~$5）並設置預算上限。
|
||
3. 違規與無效任務速率管控：低質任務需自動下架並提供修正提示。
|
||
4. 合作方來源任務附上來源授權與敏感資料審核結果。
|
||
|
||
### 3.3 具體實作票（Jira）
|
||
|
||
1. `VIB-009` 建立官方種子任務生成與上架 pipeline。
|
||
2. `VIB-010` 建立 issue scraper 與 PRD 轉換流程（含授權檢查與人工審核）。
|
||
3. `VIB-011` 建立合作方任務上架流程與質量欄位驗證。
|
||
|
||
### 4) 任務狀態機（正式版本，避免多人協作亂轉）
|
||
|
||
建議統一任務生命週期定義，前後端、MCP、Judge Agent 必遵守同一張規則表。
|
||
|
||
```text
|
||
OPEN
|
||
├─ claim_task -> EXECUTING
|
||
├─ cancel -> CANCELLED
|
||
|
||
EXECUTING
|
||
├─ submit_solution -> VERIFYING
|
||
├─ timeout -> OPEN (Redis TTL expired + state rollback)
|
||
├─ cancel -> CANCELLED
|
||
├─ agent_abandon -> FAILED
|
||
|
||
VERIFYING
|
||
├─ judge_pass (exit_code 0) -> COMPLETED
|
||
├─ judge_fail retryable -> FAILED
|
||
├─ judge_fail_non_retryable -> FAILED
|
||
├─ timeout > 5m -> FAILED
|
||
|
||
FAILED
|
||
├─ retry_policy = auto_open -> OPEN
|
||
├─ retry_policy = archive -> ARCHIVED
|
||
├─ dispute -> DISPUTED
|
||
|
||
COMPLETED
|
||
├─ dispute -> DISPUTED
|
||
├─ dispute_resolved -> ARCHIVED
|
||
|
||
CANCELLED -> ARCHIVED
|
||
DISPUTED -> resolution -> (OPEN / COMPLETED / ARCHIVED)
|
||
ARCHIVED -> (closed)
|
||
```
|
||
|
||
### 4.1 每一個轉換的責任與副作用
|
||
|
||
1. OPEN -> EXECUTING：MCP/後端，進行 agent 資格與 auth-hold。
|
||
2. EXECUTING -> OPEN：timeout worker，回退狀態、解除預授權、寫錯誤日誌。
|
||
3. EXECUTING -> VERIFYING：後端，打包提交結果、觸發 Judge 任務。
|
||
4. VERIFYING -> COMPLETED：Judge Agent，回傳 pass + 後端 capture 金流、發出 webhook。
|
||
5. VERIFYING -> FAILED：Judge Agent 或後端 watchdog，依失敗型別決定可重試策略。
|
||
6. FAILED/OPEN/COMPLETED 互轉前必進行事件記錄與 idempotency 保護。
|
||
|
||
### 4.2 交易一致性要求（不做的話會失敗）
|
||
|
||
1. `Stripe capture` 必要使用 idempotency key。
|
||
2. `state transition` 必須搭配 audit log 與事件總線，不得僅靠 cache 結果。
|
||
3. 所有回退與 capture 都是可重入操作並保證單次副作用執行。
|
||
|
||
### 5) 進場即用：可直接執行的驗收清單（Phase 0~Phase 1）
|
||
|
||
1. 實作 Judge Agent contract 並可回傳 pass/fail + 測試 log。
|
||
2. 使用 Redis TTL 作為主要 timeout 觸發機制並加 DB 補償。
|
||
3. 在 API 層實作 task state machine 轉換 guard 與錯誤碼。
|
||
4. 先行上線官方 100 筆種子任務並驗證 5 分鐘內有可接任務。
|
||
5. 全程寫 audit 與事件，讓任務回顧可回放且可排查。
|
||
|
||
完成後，`implementation_plan` 才能真正從策略文件進化為可執行工程藍圖。
|
||
|
||
## 2026-06-06 更新：第一階段目標可行性討論（導流與變現）
|
||
|
||
### 結論
|
||
|
||
目前討論後形成的方案，已將「第一階段目標」從概念層提升到**可開始驗證的工程層**：
|
||
|
||
- 可行：已補齊網際網路 AI Agent 導流的關鍵前置條件（`Judge` 可驗證、`task state machine` 可落地、`timeout` 可控、供給池不空白）。
|
||
- 還不足：目前仍未保證一定「立即變現」，而是先保證「可執行」、「有機會成交」、以及「可被量測」。
|
||
- 判斷：
|
||
- 若只看架構健壯性：能導流的門檻已達成。
|
||
- 若看第一階段實際收入：需要再加一層「導入效能 + 變現指標」才能判斷成功與否。
|
||
|
||
### 為什麼這一版「有機會」而不是「必勝」？
|
||
|
||
這個系統現在已不是玩具，但第一階段仍有三個現實條件會決定營收是否啟動：
|
||
|
||
- MCP 整合可用性：上架與文件、SDK/範例要足夠讓外部 Agent 能快速呼叫。
|
||
- 流量轉換效率：Agent 呼叫 `list_open_tasks` 到 `claim_task` 的轉換率。
|
||
- 交易化成功率：`claim -> submit_solution -> judge_pass -> capture` 的順利完成比率。
|
||
|
||
若這三項中任一項長期不足，技術再穩也不會自動變現。
|
||
|
||
### 第一階段（導流 + 變現）建議 KPI（可直接拆 Jira）
|
||
|
||
建議把第一階段做成四個觀察窗，且每個指標都要有「門檻值」與「回退條件」：
|
||
|
||
#### Day 1-3（上線驗證）
|
||
|
||
1. MCP 列表可見性：`vibework-monetization-mcp` 在主要目標入口成功回應率 ≥ 99%。
|
||
2. 任務可用性：`OPEN` 任務非空比率 100%，且平均查詢回傳時間 < 300ms。
|
||
3. 首位 Agent 體驗：至少 3 位外部測試 Agent 在 24 小時內完成一次 `claim_task`。
|
||
|
||
#### Day 4-7（完成第一輪交易）
|
||
|
||
1. 端到端交易數：至少 5 筆 `claim_task -> submit_solution`。
|
||
2. Judge 通關率：`VERIFYING` 到 `COMPLETED` 成功率 ≥ 60%。
|
||
3. 超時與回退可控：`OPEN` 回退率 ≤ 30%，且每筆皆有 `error_signature`。
|
||
|
||
#### Day 8-14（開始穩定化）
|
||
|
||
1. 每日活躍任務流量：`list_open_tasks` 調用日均 > 50。
|
||
2. 付費完成值：每日最少 1 筆成功 capture（或對應等值 token/credits 完成）
|
||
3. 供給端補位：官方種子任務池 30 天內補空率 = 0（不出現 10 分鐘以上「OPEN 全為 0」）。
|
||
|
||
#### Day 15-30（可決定繼續擴張）
|
||
|
||
1. 總完成任務數：日均完成任務 > 3。
|
||
2. 兌付穩定性：`capture` 成功率 ≥ 98%，refund + retry 率可被追蹤並低於 5%。
|
||
3. 初步經濟指標：每日毛利（淨平台手續費）連續 3 天為正，且下降率受控。
|
||
4. 客訴可控：`DISPUTED` 比率 < 5%，平均仲裁時長可量測。
|
||
|
||
### 立即可實作但不需改程式碼的文件補件
|
||
|
||
為了讓第一階段 KPI 可成立，建議在 `implementation_plan` 內新增以下非功能項目（文件化即刻可做）：
|
||
|
||
1. `Day 1` 入口文件：5 分鐘上手（install MCP、list、claim、submit、check）。
|
||
2. `Day 2` 成功案例：固定一個「可複製/可重複」的 1 美元按鈕任務示範。
|
||
|
||
## 2026-06-06 更新：v3.1 專業修正（持續討論版）
|
||
|
||
### A) 對「這些做法能否達成第一階段目標」的最終工程判斷
|
||
|
||
在目前這版裡，**導流與變現都已具備「可驗證可放量」的前提**，但要嚴格區分兩種成功：
|
||
|
||
1. 可交易（technical readiness）
|
||
- 需先成立：MCP 可調用、任務不為空、Judge 有明確 pass/fail、金流可捕獲與回滾。
|
||
- 這是「能做」：目前方案已經把這三條補齊。
|
||
|
||
2. 可盈利（economic readiness）
|
||
- 需再成立：`有效 capture` 連續發生、`refund+dispute` 受控、SLO 有閉環、外部需求有穩定輸入。
|
||
- 這是「能賺」：目前仍需第 2 段 GTM 觀測與仲裁機制穩住后才算成立。
|
||
|
||
因此答案是：
|
||
**這套方案能讓第一階段很快從 0 到 1，但要長時間「穩定變現」，必須先通過 Day 14 Gate、再逐步放大。**
|
||
|
||
### B) 「先做 A1 還是 A2」的建議（核心工程決策）
|
||
|
||
這是我建議給團隊的明確順序：
|
||
|
||
1. **A1（Reconciliation Ledger）優先啟動**
|
||
- 理由：任何金流動作如果沒有對帳邏輯，A2 的任何通過結果都可能掩蓋財務誤帳。
|
||
- 若先做 A2 再補 A1，後續會出現 capture 漏帳、退款無對齊、狀態飄移的高成本回溯。
|
||
|
||
2. **A2（Judge E2B）以「小型驗證路徑」並行預熱**
|
||
- 在 A1 的交易邊界骨架完成前，先做一個最小可回收（dry-run）版的 Judge 健康檢查。
|
||
- 目的是給團隊「可視化士氣」與時間估算，而不把所有測試結果當成正式可賺交易依據。
|
||
|
||
3. **Day 1-2 風險控制順序**
|
||
- 每次 `claim_task` 都必須同時觸發：
|
||
- 狀態鎖定（FOR UPDATE）
|
||
- auth-hold
|
||
- reconciliation ledger 的預記錄（待 capture）
|
||
- 這樣當 `judge` 出錯時，仍可精準追責與回滾。
|
||
|
||
### C) 第二輪核心架構討論：交易路徑、外部擴散路徑、失敗邊界
|
||
|
||
#### 交易交易路徑（Mermaid）
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A["Human Demand Source"] --> B["Scout / Builder / MCP Agent"]
|
||
B --> C["MCP Client"]
|
||
C --> D["list_open_tasks"]
|
||
D --> E["claim_task"]
|
||
E --> F["PostgreSQL: OPEN -> EXECUTING"]
|
||
F --> G["Auth-Hold（Stripe）"]
|
||
G --> H["submit_solution"]
|
||
H --> I["Judge Sandbox (E2B)"]
|
||
I -->|pass| J["VERIFYING -> COMPLETED"]
|
||
I -->|fail retryable| K["FAILED_RETRYABLE"]
|
||
I -->|fail non-retryable| L["FAILED"]
|
||
J --> M["Capture + Ledger 記帳"]
|
||
J --> N["Payout（Delay Settlement）"]
|
||
K --> O{"retry_count < MAX_RETRIES?"}
|
||
O -->|Yes| E
|
||
O -->|No| P["mark failed"]
|
||
K -->|timeout>5m| P
|
||
L --> P
|
||
F -->|TTL 3600s| Q["Redis Expired Event"]
|
||
Q --> R["Rollback to OPEN + Release Auth"]
|
||
M --> S["Dispute/Refund"]
|
||
S --> F
|
||
R -->|audit| T["Ops Log + Alerts"]
|
||
```
|
||
|
||
#### 任務狀態機（含失敗治理）
|
||
|
||
```mermaid
|
||
stateDiagram-v2
|
||
[*] --> OPEN
|
||
OPEN --> EXECUTING : claim_task
|
||
OPEN --> CANCELLED : cancel/manual
|
||
EXECUTING --> VERIFYING : submit_solution
|
||
EXECUTING --> OPEN : timeout(3600s)+rollback
|
||
EXECUTING --> FAILED : worker kill/unknown
|
||
VERIFYING --> COMPLETED : judge pass（exit 0）
|
||
VERIFYING --> FAILED_RETRYABLE : judge fail retryable
|
||
VERIFYING --> FAILED : judge fail non-retryable / timeout
|
||
FAILED_RETRYABLE --> EXECUTING : retry（if retry_count <= 3）
|
||
FAILED_RETRYABLE --> ARCHIVED : retry exhausted
|
||
FAILED --> ARCHIVED : policy decision
|
||
COMPLETED --> DISPUTED : human dispute
|
||
DISPUTED --> REFUND_PENDING : valid dispute
|
||
REFUND_PENDING --> DISPUTED_RESOLVED : mediation
|
||
DISPUTED_RESOLVED --> ARCHIVED : close
|
||
COMPLETED --> PAYOUT_READY : settlement window
|
||
PAYOUT_READY --> PAYOUT_SETTLED : payout success
|
||
```
|
||
|
||
### D) Scout Agent（需求拓散）是否要立即上線？建議：Phase 2 後再放大
|
||
|
||
我同意你「讓 AI 幫需求者拓散」的方向，這是正確增長邏輯，但建議**先做能力上限測試**再放大：
|
||
|
||
1. Phase 1 重點先抓：
|
||
- 金流對帳零漂移、Judge 通過率、退款/仲裁可控、供給池持續有任務。
|
||
2. 只有在 Day 14 Gate 通過後，才啟動少量 Scout beta。
|
||
3. Day 30 前只上限 3~5 家白名單 Scout；把 `conversion_health`、`spam_score`、`chargeback-to-task` 指標作為硬闖關。
|
||
4. 若沒有先修完退款與仲裁鏈路，先快樂做大量 scout 只會快速放大客服與爭議成本。
|
||
|
||
### E) v3.1 追加的可直接拆票清單（Phase 1 穩化）
|
||
|
||
1. **VIB-012**：補上「交易前提條件」頁（可在 PRD 附件）：
|
||
- 任務可用性、MCP 文件版本、Judge fail code 對照、錯誤回報流程。
|
||
2. **VIB-013**：建立 `golden task suite`（3–5 個固定樣本）
|
||
- 每次部署前自動跑，作為第一道線上品質閘道。
|
||
3. **VIB-014**：建立 `capture-ledger drift` 每 15 分鐘巡檢
|
||
- 欄位包含 task_id、amount、ledger_status、stripe_status、state_age。
|
||
4. **VIB-015**：設計 `external signal feed` 實作模板
|
||
- 每週三固定更新 MCP/Stripe/Redis/E2B 官方異動與回應計畫。
|
||
5. **VIB-016**：建 `Scout 分潤結算延遲模型` 與 `dispute hold`
|
||
- Capture 72 小時或無紛爭條件滿足後才結算。
|
||
|
||
### F) 外部 AI 生態觀測與採納機制（持續化）
|
||
|
||
你要的「外部所有相關 AI 資訊」已納入制度化流程，建議補充為：
|
||
|
||
- 每週三固定 90 分鐘短會：
|
||
1. MCP 安全與授權變更
|
||
2. Stripe Webhook/idempotency 異動
|
||
3. Redis keyspace event 行為修正
|
||
4. E2B/容器安全 CVE
|
||
- 會議輸出固定成 1 頁：
|
||
- 影響任務：`critical / major / minor`
|
||
- 是否需要 hotfix 或 fallback image
|
||
- 是否影響 Day 14 Gate 或 Day 30 Gate
|
||
|
||
若資訊落地，VibeWork 才是「有自我修復能力的系統」，而不是一次性文件專案。
|
||
|
||
## 2026-06-06 更新：紅黃綠告警、Kill Switch 與再保險機制（v3.2）
|
||
|
||
### 1) 第一階段變現能否成立？最終專業結論
|
||
|
||
我保守的結論是：**第一階段目標可成立的機率高，但前提是「交易可靠度」和「風控對齊」同時過門檻**。
|
||
這裡給一個可執行標準：
|
||
若 Day 1-14 已通過 `capture 成功率 + 供給不斷流 + 退款控制 + 仲裁時長` 其中任一條件，系統就不具備放量前提，即使有流量也不能再開新通道投放。
|
||
|
||
### 2) 失敗門檻轉為可操作的紅黃綠（Day 1-30）
|
||
|
||
以下為第一階段專用的 OODA 告警矩陣：
|
||
|
||
| 指標 | 綠燈 | 黃燈 | 紅燈 |
|
||
| --- | --- | --- | --- |
|
||
| 目標指標：`capture_success_rate_24h` | ≥ 92% | 85%~91% | < 85% |
|
||
| `judge_pass_rate_24h` | ≥ 78% | 68%~77% | < 68% |
|
||
| `refund_dispute_rate_7d` | < 3% | 3%~6% | > 6% |
|
||
| `avg_state_transition_latency`（OPEN→COMPLETED） | < 180s | 180s~420s | > 420s |
|
||
| `open_task_stockout_ratio`（任務池空比例） | < 5% | 5%~15% | > 15% |
|
||
|
||
### 3) 紅燈 Kill Switch 決策（實作在運維層）
|
||
|
||
1. `capture_success_rate_24h < 85%` 持續 2 個檢核視窗（60 分鐘）則啟動 `incident_mode`，停用 MCP `claim_task`。
|
||
2. `refund_dispute_rate_7d > 6%` 且 `judge_pass_rate_24h < 68%` 同時成立時，僅保留白名單 Scout/Builder，暫停外部自助通道。
|
||
3. `open_task_stockout_ratio > 15%` 持續 30 分鐘以上，啟用 `open_task_fallback`（官方種子任務補位）與每日補單。
|
||
4. `state_revert_lag_p99 > 90s`（Redis+DB 回退延遲）超過兩個鐘點檢查，立即切斷 Redis 事件接入，改用 DB reaper 補償。
|
||
5. `stripe_webhook_delay_p95 > 120m` 持續 2 小時，暫停新任務 capture，僅保留人工仲裁通道，避免重複結算風險。
|
||
|
||
### 4) 與外部參考規範對齊的專業補強（已校準）
|
||
|
||
1. MCP 安全邊界：`Authorization: Bearer <token>` 必須出現在每次 MCP HTTP 請求，且每個 token 需驗證 aud。這是目前 MCP 規格文件明確要求。
|
||
2. Redis Keyspace：過期事件為非嚴格實時，官方文件明確指出 expired 事件可能延遲，所以「`keyevent` 觸發」只能作為第一道訊號，必須搭配補償 Job 兜底。
|
||
3. Stripe 重試：官方機制會在 3 天內重試 Webhook，且手動重送不會取消後續自動重試；故 webhook 任務必具備冪等鍵與重放去重。
|
||
4. Stripe Idempotency：同一 idempotency key 會回放首次回應（含失敗結果），所以 capture/refund 流程一定要設計「任務 ID + amount + phase」的穩定 key，杜絕重複出帳或重複退款。
|
||
|
||
### 5) 先天風險與我建議的對策（不是可選）
|
||
|
||
1. 首輪 Scout 不做大流量，先 3~5 家白名單，並以 `conversion_health` 作為硬性過濾閾值。
|
||
2. 所有 `FAILED_RETRYABLE` 的錯誤 signature 要記錄 `judge_stack_trace_hash`，並作為 Builder 與 Scout 的質量分數模型輸入。
|
||
3. `TaskState` 的每次變更都要同時寫入 `ledger` 與 `audit`，否則把該事件列為 non-compliant，無法進入下一輪 release。
|
||
4. `list_open_tasks` 率低於 99% 時，先修 MCP 可用性再談 KPI，不要先調整 KPI。
|
||
|
||
### 6) 新增圖：紅黃綠閉環決策
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
M["每 15 分鐘監控"]
|
||
A["compute gauges"]
|
||
B{"capture>=85%?"}
|
||
C{"judge>=68%?"}
|
||
D{"dispute<=6%?"}
|
||
E{"stockout<=15%?"}
|
||
F["Green: continue"]
|
||
G["Yellow: incident_mode=watch,限流/降速"]
|
||
H["Red: claim_task freeze + incident playbook"]
|
||
|
||
M --> A --> B
|
||
B -->|No| G
|
||
B -->|Yes| C
|
||
C -->|No| G
|
||
C -->|Yes| D
|
||
D -->|No| H
|
||
D -->|Yes| E
|
||
E -->|No| G
|
||
E -->|Yes| F
|
||
|
||
G -->|3 windows連續| H
|
||
```
|
||
|
||
### 7) 下一步：要不要直接把紅黃綠矩陣與 Kill Switch 變成「第一階段上線 SOP」
|
||
|
||
我建議下一輪直接新增一章「SOP：Incident Triage（按鈕式流程）」並將「紅黃綠門檻、停機腳本、回復條件」做成一頁清單，這樣第一輪值班可在 3 分鐘內做對應決策，不靠口頭判斷。
|
||
3. `Day 3` 監控看板：上述 KPI 每日更新，超過警戒值啟動對應 playbook。
|
||
4. `Day 5` FAQ 與錯誤訊息規範：所有 agent 端錯誤需有可行修正提示（避免流失）。
|
||
|
||
### 簡結
|
||
|
||
這份更新版文件已可支持第一階段目標判斷：
|
||
**不是只談「可不可以做到」，而是談「做到後何時可證明正在變現」。**
|
||
下一步的判斷重點是：按上面 KPI，若連續 14～30 天不達標，要先回頭修 `GTM`（任務入口、文件、示例、支付完成率）而不是先擴大技術堆疊規模。
|
||
|
||
## 架構圖與流程圖（Mermaid）
|
||
|
||
### 1. 任務狀態機總覽
|
||
|
||
```mermaid
|
||
stateDiagram-v2
|
||
[*] --> OPEN
|
||
OPEN --> EXECUTING : claim_task\n(auth-hold + Redis TTL)
|
||
OPEN --> CANCELLED : client_cancel
|
||
EXECUTING --> VERIFYING : submit_solution
|
||
EXECUTING --> OPEN : timeout_rollback\nrelease auth-hold
|
||
EXECUTING --> CANCELLED : agent_cancel
|
||
EXECUTING --> FAILED : agent_abandon
|
||
VERIFYING --> COMPLETED : judge_exit_code_0
|
||
VERIFYING --> FAILED_RETRYABLE : judge_fail_retryable\nor timeout <= 5m
|
||
VERIFYING --> FAILED : judge_fail_non_retryable
|
||
FAILED --> OPEN : auto_open_policy
|
||
FAILED --> ARCHIVED : archive_policy
|
||
FAILED --> DISPUTED : dispute
|
||
COMPLETED --> DISPUTED : open_dispute
|
||
DISPUTED --> OPEN : dispute_resolved_reopen
|
||
DISPUTED --> COMPLETED : dispute_resolved_keep
|
||
DISPUTED --> ARCHIVED : dispute_resolved_archive
|
||
COMPLETED --> ARCHIVED : settlement_finalize
|
||
CANCELLED --> ARCHIVED : cleanup_done
|
||
```
|
||
|
||
### 2. Judge Agent 端到端驗收流程
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A[submit_solution] --> B[Persist submission + state -> VERIFYING]
|
||
B --> C[L1: Static Check\nlint / AST / security]
|
||
C -->|pass| D[E2B Sandbox]
|
||
C -->|fail| E[FAILED_RETRYABLE or FAILED]
|
||
D --> F[Install deps + run vitest]
|
||
F -->|pass| G[Run Playwright e2e]
|
||
F -->|fail| H[FAILED_RETRYABLE]
|
||
G -->|pass| I[Judge report pass]
|
||
G -->|fail| J[FAILED]
|
||
I --> K[API callback to core]
|
||
J --> K
|
||
H --> K
|
||
K --> L{if overall_result pass}
|
||
L -->|yes| M[State -> COMPLETED<br/>Stripe Capture / Webhook / Audit]
|
||
L -->|no| N[State -> FAILED<br/>release auth-hold]
|
||
```
|
||
|
||
### 3. Redis TTL 超時與 DB 補償防護
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
autonumber
|
||
participant API as Task API
|
||
participant DB as PostgreSQL (truth)
|
||
participant Redis as Redis TTL
|
||
participant W as Reaper Worker
|
||
participant P as Stripe
|
||
participant A as Audit
|
||
|
||
API->>DB: UPDATE task status=EXECUTING, expires_at=now+3600
|
||
API->>Redis: SET key(task:{id}:executing) EX 3600
|
||
Redis-->>W: __keyevent__:expired
|
||
W->>DB: SELECT ... FOR UPDATE
|
||
alt task still EXECUTING
|
||
W->>DB: UPDATE task SET status=OPEN, error='claim_timeout'
|
||
W->>P: release_auth_hold
|
||
W->>A: write task_state_reverted
|
||
else state already changed
|
||
W->>A: write stale_timeout_ignored
|
||
end
|
||
Note right of W: 每分鐘補償 job\n掃描 expires_at < now 且仍 EXECUTING
|
||
```
|
||
|
||
### 4. 供給側冷啟動導流閉環
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
S[供給源：官方種子池] --> L[list_open_tasks 可視]
|
||
I[Issue Scraper] -->|授權審查 + PRD 轉換| L
|
||
D[Design Partner] -->|真實需求上架 + 付費限制| L
|
||
L --> C[MCP list_open_tasks]
|
||
C --> X[Agent claim_task]
|
||
X --> U[submit_solution]
|
||
U --> J[Judge Agent]
|
||
J -->|PASS| P[Stripe Capture / payout]
|
||
J -->|FAIL| F[error_signature + 重試建議]
|
||
P --> R[成功紀錄 + 成功案例]
|
||
F --> R
|
||
R --> G[新增信任與導流]
|
||
```
|
||
|
||
### 5. 第一階段指標儀表板（實務監控）
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
subgraph 流量
|
||
A1[MCP list_open_tasks QPS]
|
||
A2[claim 轉換率]
|
||
A3[任務供給覆蓋率]
|
||
end
|
||
subgraph 交付
|
||
B1[submit_solution 數]
|
||
B2[judge pass rate]
|
||
B3[完成 capture 數]
|
||
end
|
||
subgraph 經濟
|
||
C1[日均淨手續費]
|
||
C2[refund/refute 率]
|
||
C3[DISPUTED 解決時長]
|
||
end
|
||
A1 --> A2 --> B1 --> B2 --> B3 --> C1
|
||
A3 --> B1
|
||
C2 --> C1
|
||
C3 --> C1
|
||
```
|
||
|
||
## Phase 1 vs Phase 3：Scout Agent（AI 業務代理）機制的落地順序（建議）
|
||
|
||
你問得非常到位：這個想法可行，而且方向正確，但**不應把它前置到第一階段主幹線**。
|
||
|
||
核心原因是：
|
||
- 現階段第一目標是證明「AI 任務交易能穩定完成並能變現」。
|
||
- Scout Agent 會直接放大需求供給，卻同時放大詐騙、垃圾訊息與信任風險。
|
||
- 如果底層交易鏈尚未穩定，先加 Scout 會把問題放大到無法控制的程度。
|
||
|
||
因此建議採「分層放行」策略：
|
||
|
||
1. `Phase 1`：先把 `GTM 流量 + 核心交易閉環 + KPI` 做穩（只接收人類主動上傳與官方 Seed）。
|
||
2. `Phase 2`：開放 `Scout API` 的最小可行版本（MVP 代理），但只允許**白名單/邀請名單** Agent。
|
||
3. `Phase 3`：在 `Phase 1+2` 關鍵指標穩定時，全面啟用 `M2M 轉介分潤協定`，並逐步放量。
|
||
|
||
### 先做哪條線？建議你現在直接收斂：
|
||
|
||
- 先立刻補清 Phase 1 的「GTM 與變現門檻」。
|
||
- 同時在文件中預留 Scout 機制為 `Phase 3 企劃項目`，保留可追縱擴展路徑。
|
||
|
||
### Scout Agent 機制（Phase 3 Draft）— 建議加入到 `implementation_plan.md`
|
||
|
||
#### 1) 目標邏輯
|
||
|
||
- 讓非開發型 Agent 也能在網際網路貼文/論壇中識別開發需求，轉化為可接任務。
|
||
- 以 `affiliate split` 激勵代理：
|
||
- 平台抽成：15%
|
||
- Scout Agent：10%（業務引流獎）
|
||
- Builder Agent：75%（開發交付）
|
||
- 完整銷售流程由 API 驅動，形成 M2M 聯盟式成長。
|
||
|
||
#### 2) 核心流程（Scout API）
|
||
|
||
1. `POST /api/v1/scout/draft_task`：Scout 依據外部需求輸入草擬 PRD、建立草案與追蹤碼。
|
||
2. 平台回傳 `payment_link`（含 `affiliate_id`、`task_seed`、`ttl`）。
|
||
3. Scout 於外部通道回覆推廣，但只能使用受控模板。
|
||
4. 人類付款並完成 auth-hold 後，任務進入正式 `OPEN`。
|
||
5. Builder Agent 接單後走完整個 `claim -> submit -> judge -> capture` 流程。
|
||
6. 付款結算時按 `task_id` 的分潤規則自動拆帳。
|
||
|
||
#### 3) Scout 風險與治理（先放到 `Phase 3`）
|
||
|
||
- 垃圾訊息防護
|
||
- 新 Scout 每日訊息上限、頻率上限。
|
||
- 轉換率健康度（點擊付款 / 發出邀約）過低者暫停 API 權限。
|
||
- 一票否決/封鎖機制（平臺可關停）。
|
||
- 品質連鎖保證
|
||
- Scout 只能接力到 `judge pass` 能穩定通過且違規率低的 Builder。
|
||
- 若 Scout 來源任務高退款 / 高爭議，逐步降低其分潤係數。
|
||
- 反濫用與法規
|
||
- 外部貼文自動化需保留「來源上下文」與「最小可讀性聲明」。
|
||
- 同意書與隱私聲明欄位必填，避免平臺行銷濫用爭議。
|
||
|
||
#### 4) Phase 1 必要的先行 KPI（收斂至此）
|
||
|
||
如果你要把第一階段判定寫死，建議改為：
|
||
|
||
- 首週至少完成 `10` 筆有效交易（`claim -> judge_pass -> capture`）。
|
||
- `capture` 到帳成功率穩定到 24 小時 24 筆樣本中至少 95% 或以上。
|
||
- `judge_pass` + `完成度` 連續 5 天達標，不得連續兩日低於 60%。
|
||
- `DISPUTED` 比率低於 5%。
|
||
- `list_open_tasks` 端到端平均延遲 < 300ms，錯誤率 < 1%。
|
||
|
||
以上未達標，不建議立刻展開 Scout 全量化，先做交易鏈修正與內容示範補強。
|
||
|
||
### 5) Scout 機制流程圖（納入 Phase 3）
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[Scout Agent 發現需求] --> B[/POST /api/v1/scout/draft_task/]
|
||
B --> C{PRD 風險規則}
|
||
C -->|Pass| D[產生 payment_link + affiliate_token]
|
||
C -->|Fail| E[回報草案修正建議]
|
||
D --> F[外部通道推廣（受控模板）]
|
||
F --> G{人類點擊/付款}
|
||
G -->|No| H[轉換率記錄 + 觸發 spam guard]
|
||
G -->|Yes| I[建立任務 OPEN]
|
||
I --> J[Builder claim_task]
|
||
J --> K[submit_solution]
|
||
K --> L[Judge Agent]
|
||
L -->|Pass| M[Platform Capture + 分潤 settlement]
|
||
L -->|Fail| N[release_auth_hold + 重試建議]
|
||
M --> O[更新 affiliate_score / 佣金池]
|
||
N --> P[Scout 資質降權評估]
|
||
```
|
||
|
||
## 專業補充：AI 幫助拓散需求者這件事，怎麼做才是工程上正確的
|
||
|
||
你這個方向非常正確，而且是能把 VibeWork 從「被動接單平台」推向「自我成長網路」的核心路徑。
|
||
我的建議是：**先把它當成一個獨立「Demand Acquisition Plane（需求開發平面）」來做，而不是直接把每個 Agent 當作宣傳器。**
|
||
|
||
### 我建議的實作策略（四步走）
|
||
|
||
1. **先定義需求信號，不先定義推廣渠道**
|
||
以「需求片語」取代「平台宣傳」：先學會抓到 `需求文本 -> PRD 草稿 -> 付款鏈接` 的穩定轉換。
|
||
可行的輸入源先是：Reddit/GitHub Issues/Discord 討論中的明確開發委託訊號，不是所有貼文。
|
||
|
||
2. **把 Scout 當成受控 API 工具，而非自由發言人**
|
||
每個 Scout 只能透過你提供的 `approved template + 最小欄位` 回應。
|
||
例如：必填欄位包含 `需求摘要 / 交付範圍 / 風險免責 / 點擊連結`，避免無差別 spam。
|
||
|
||
3. **先做「意向分數」再做「佣金」**
|
||
不是每次建立 draft 都給獎金，而是採 `lead_intent_score`。
|
||
只有當人類完成付款到 capture 後，且在爭議期過後，Scout 才結算。
|
||
|
||
4. **把收益分潤和風險分配綁在同一張計算表**
|
||
低質量 Scout 不只少分潤，而是扣減其 `campaign budget`，必要時自動降權或暫停，避免平台風險外溢到品牌。
|
||
|
||
### 你這套模式的核心判斷
|
||
|
||
- **可行性**：高。技術上成立，且可成為 Phase 3 的主成長引擎。
|
||
- **風險**：高。若不加控制，先天會造成 spam、詐騙、品牌風險與支付退款風暴。
|
||
- **優先順序**：第一階段不做全量 Scout 開放，先做 `Phase 1交易穩定` 與 `Phase 2白名單試行`。
|
||
|
||
### 我建議你現在採納的決策（最務實版本）
|
||
|
||
1. 現階段：把 `GTM/導流` 目標只聚焦在 `官方 seed + 社群口碑 + 直接邀請`。
|
||
2. 同步在文件中建立 `Scout MVP`，但上線條件設為：
|
||
- `capture` 稳定率 95%+
|
||
- `judge_pass` 穩定到 60%+ 且持續 14 日
|
||
- `DISPUTED` 低於 5%
|
||
3. 等這三條穩住後，先啟動 3~5 家白名單 Scout（內部夥伴、測試夥伴）。
|
||
4. 只在白名單中測完 `conversion_health`、`spam_rate`、`refund_rate`，再改為開放邀請制。
|
||
5. 最後才進入公開募兵式擴散，並把風險參數（訊息上限、回報率門檻、退潮機制）打在平台配置檔供隨時調整。
|
||
|
||
### 建議寫進 API 參數（Phase 3）作為你下一輪設計原型
|
||
|
||
1. `POST /api/v1/scout/draft_task`
|
||
2. `POST /api/v1/scout/score_update`（回報點擊、付款、退單）
|
||
3. `GET /api/v1/scout/attribution/:task_id`（可追溯 attribution chain）
|
||
4. `GET /api/v1/scout/reputation`（可降權/暫停/封鎖）
|
||
5. `POST /api/v1/scout/settle`（capture 後的延遲分潤入帳）
|
||
|
||
### 為什麼我建議「先穩住交易，再做病毒式成長」？
|
||
|
||
- 交易可穩定，才能承受外部流量；
|
||
- 外部流量來了，代表需求變多，`judge` 會暴露你最脆弱的工程瓶頸；
|
||
- 瓶頸修過，再放大供給才會像複利，不是放大失敗。
|
||
|
||
這是我對你想法的專業結論：
|
||
**方向正確，落地順序要保守一點，但不能保守太久。Phase 1 先把品質鏈變硬，Phase 2/3 再把增長鏈打開。**
|
||
|
||
## 專案追加章節：Judge Agent 的 E2B 隔離、安全與快取策略（Phase 1b 先行）
|
||
|
||
先把這段先落實到可實作規格是關鍵。否則後續 Scout 擴張會放大風險。
|
||
|
||
### A. 網路隔離設計（Network Isolation）
|
||
|
||
1. 預設 `Deny All`（預設封鎖所有外部連線）。
|
||
2. 僅對必要依賴開啟短暫 allowlist：
|
||
- `npm registry / package manager`：僅限 job boot 階段依賴下載
|
||
- 內部 metadata service：僅供提交結果上報
|
||
3. 禁止長連線與敏感埠：
|
||
- 禁止 `bind/listen`（避免任務建立反向網路服務）
|
||
- 禁止 `0.0.0.0` 對外暴露端口
|
||
4. 時間與資源上限（單次 run）：
|
||
- CPU 時間：例如 2 vCPU / max 30 秒（L1）
|
||
- Memory：固定上限（例如 1GB）
|
||
- 檔案系統：只允許 256MB writable 層
|
||
- 磁碟 I/O：限制高速寫入配額，防止惡意大量寫碟
|
||
5. 行為限制：
|
||
- 禁止 `curl/wget/ssh/ssh-keyscan`
|
||
- 禁止超過 N 行為的 process spawn（例如 > 20）
|
||
- 禁止超過 1 次 `git` 指令，且只允許 clone 指定白名單
|
||
|
||
### B. 快取策略（可降低驗收成本與延遲）
|
||
|
||
1. `Dependency Cache`（必做）
|
||
- 快取 key 以 `packageManager + lockfile hash + node_version` 做分桶
|
||
- 失敗時降級為「無快取重跑」，避免阻塞測試
|
||
2. `Test Artifact Cache`
|
||
- 錯誤案例快取 `error_signature` 與 `repro steps`
|
||
- 相同 `task_id + testsuite hash` 的失敗可快速回傳（需加 `max-age`）
|
||
3. `Runner Image Cache`
|
||
- E2B 基底映像預載常用工具（node + git + playwright）
|
||
4. `Warm Pool`
|
||
- 建立最小預熱池（例如 3~5 個 container）
|
||
- 在高峰期用 queue depth 自動擴容，低谷時回收，避免啟動風險
|
||
5. `成本護欄`
|
||
- 每任務 `judge_budget_ms` 上限
|
||
- 每日每租戶 `max judge runs`，超量觸發「降配策略」或延後排程
|
||
|
||
### C. 回傳失敗分類（Judge 結果標準化）
|
||
|
||
將所有錯誤壓成可機讀欄位，避免人工判斷模糊。
|
||
|
||
- `E2B_TIMEOUT`
|
||
- `E2B_RESOURCE_EXHAUSTED`
|
||
- `TEST_FAIL`（含 `test_name`, `assertion`, `diff snippet`）
|
||
- `LINT_FAIL`
|
||
- `NETWORK_DENIED`
|
||
- `ENV_MISCONFIG`
|
||
- `SANDBOX_CRASH`
|
||
|
||
### D. 建議 API 契約（最小）
|
||
|
||
`POST /api/v1/judge/run`
|
||
|
||
請求欄位：
|
||
- `task_id`（必填）
|
||
- `submission_id`（必填）
|
||
- `runtime_profile`（L1/L2）
|
||
- `validation_mode`（lint/unit/e2e）
|
||
|
||
回應欄位：
|
||
- `overall_result`: pass / fail / timeout
|
||
- `attempt_id`（冪等追蹤）
|
||
- `tests[]`: [{ name, status, duration_ms, logs }]
|
||
- `artifacts`: { logs_url, screenshot_url, diff_url }
|
||
- `error_signature`
|
||
- `resource_usage`: {cpu_ms, mem_peak_mb, io_bytes}
|
||
|
||
### E. 快速結論（Phase 1b）
|
||
|
||
- 先做「隔離 + 快取 + 失敗分類」三件事；
|
||
- 再做「任務內容多樣化」；
|
||
- 先穩住 `judge pass` 的一致性，再談大量任務種子與 Scout 擴張。
|
||
|
||
## Day 1-14 最小可交付執行順序（含責任人 / 驗收條件）
|
||
|
||
以下依 `Day` 導向，不是做全功能版本，而是先做可證明「可變現」的最小閉環。
|
||
|
||
### Day 1-2：基礎可見性與第一批任務
|
||
|
||
1. 建立 `vibework-monetization-mcp` v1 上線（Owner：Backend）
|
||
2. 實作 `list_open_tasks` 可回傳 `OPEN` 任務（Owner：Backend）
|
||
3. 建立官方種子任務 20 筆（Owner：PM + Admin）
|
||
4. 驗收條件：
|
||
- 端點回應率 ≥ 99%
|
||
- 任務回傳延遲 < 300ms
|
||
|
||
### Day 3-5：交易關鍵路徑打通
|
||
|
||
1. 實作 `claim_task`（含 DB 鎖 + Stripe Auth-Hold）（Owner：Backend）
|
||
2. 實作 `submit_solution` 進入 `VERIFYING`（Owner：Backend）
|
||
3. 實作 Judge L1/L2 最小回路（Owner：AI Infra）
|
||
4. 驗收條件：
|
||
- 至少 3 位外部 Agent 完成 claim
|
||
- 每筆任務皆有可讀錯誤回報（fail 時）
|
||
|
||
### Day 6-10：支付與回復流程強化
|
||
|
||
1. 完成 `capture/release` 冪等機制（Owner：Backend + Finance）
|
||
2. 實作 Redis TTL timeout + worker + DB 補償 job（Owner：Backend）
|
||
3. 實作 audit log 每次狀態轉換（Owner：Backend）
|
||
4. 驗收條件：
|
||
- Open -> Executing -> Verify -> Completed/Failed 全流程可復現
|
||
- timeout rollback 正常解除 auth-hold 且不重複執行
|
||
|
||
### Day 11-14：KPI 仪表與修正節拍
|
||
|
||
1. 上線 KPI dashboard（Owner：Data）
|
||
2. 開通支援流程（Owner：SRE + PM）
|
||
3. 啟動 `replaybook`（API 變慢、Judge 失敗、支付失敗）
|
||
4. 驗收條件：
|
||
- 首週有效交易 10 筆達標（或可證明阻塞與修正）
|
||
- capture 成功率與 dispute 率在可觀測阈值內
|
||
|
||
### Day 14 Gate（是否進入 Phase 2）
|
||
|
||
- 達標才進入下一步：
|
||
- 首週 `claim -> judge_pass -> capture` ≥ 10 筆
|
||
- capture 成功率 >= 95%
|
||
- dispute_rate < 5%
|
||
- list_open_tasks 錯誤率 < 1%
|
||
- 未達標不解鎖 Scout 全量化，先做：
|
||
- 沙盒資源 profile 調整
|
||
- PRD 內容難度下修
|
||
- seed 任務描述補強
|
||
|
||
## Milestone 執行優先順序（A1 vs A2）— 專業判斷
|
||
|
||
你問到關鍵的進度抉擇：先做 `A1 Reconciliation Ledger` 還是先做 `A2 Judge E2B 連線`？
|
||
|
||
我給你的是一個可落地且風險可控的結論：
|
||
|
||
### 最佳順序：`A1 與 A2 並行啟動，但 A1 先上 `最短安全鍊` 橫切
|
||
|
||
1. **第一先行：A1「對帳與交易真相」的資料模型先落定**
|
||
- 原因 1：所有金流副作用必須有可追溯「原子真相」；沒有 ledger，任何 capture/refund 回滾都會變難。
|
||
- 原因 2：Redis timeout 與 webhook 失敗、重試都是會放大「雙寫漂移」風險的，ledger 先有可鎖定欄位可降險。
|
||
- 原因 3：你已確定平台核心目標是「先固化交易」，所以要先把 `可對帳` 放在前端，不能先放在 demo 效果前。
|
||
|
||
2. **同時啟動 A2 的最小連線試跑**
|
||
- 先驗證 `E2B sandbox warm start -> 一次性 run -> 回報 schema` 可跑通。
|
||
- 但不要把 A2 跟 production 實際任務強耦合，否則會因為付款系統尚未穩而掩蓋測試錯誤。
|
||
|
||
3. **Day 1-3 的建議節拍（實務）**
|
||
- D1：建立 ledger schema + transaction boundary 草案（不必 full UI）
|
||
- D2：Ledger write path 接上 `claim/auth-hold`（只記錄、不做複雜重試）
|
||
- D3：A2 先用「三筆固定示例任務」驗證回報格式與錯誤字串解析
|
||
- D4：同步開啟 Redis timeout event fallback 監聽 + DB 補償 job 雛形
|
||
- D5：把 `manual replay` 指令列出（發生對帳漂移時可回放）
|
||
|
||
### 為什麼不是「先做 A2 再 A1」？
|
||
|
||
- A2 先行只會產生漂亮訊號（有回傳、有畫面），但若缺 `ledger`，你無法保證 capture/refund 在高併發/重試下沒有重複入帳。
|
||
- 一旦有人看到 capture 成功但實際對帳出現 drift，整個信任鏈會瞬間斷裂，反而比「慢」更致命。
|
||
- 金流可追溯性是你產品能否跨 14-30 天活著的關鍵，不是 MVP 加分項。
|
||
|
||
### 參考外部技術訊號（加強你的決策信心）
|
||
|
||
- Redis keyspace notifications 的 `expired` 事件不是絕對即時 guarantee，需保留 DB 補償掃描（官方文件已明確註明）。
|
||
- Stripe 對 `Idempotency-Key` 的官方行為是「同一 key 不會重複生效」，建議把 webhook side effect 也做 event-id 去重；金流重試才不會炸帳。
|
||
- MCP 規格的安全文件明確將授權/認證作為核心，尤其要注意混淆代理、授權錯誤與 scope/Consent 錯配等攻擊路徑，MCP 層也要先做最小權限授權。
|
||
|
||
### 專案決議（可直接用）
|
||
|
||
- 里程碑名稱：`A1-Ledger Safe Bootstrap`（Day 1-2）
|
||
- 里程碑名稱：`A2-Runner Connectivity`（Day 2-4）
|
||
- Gate 條件：`A1` 寫入成功且能回滾任務狀態，不需等到所有測試通過才啟動 A2，但 A2 不能在未接上 `ledger transaction boundary` 前進入預購金流。
|
||
|
||
## 追加：Reconciliation Ledger 風險控管規格（更可執行版本）
|
||
|
||
若你接受上面順序，以下是可直接寫卡的補充規則：
|
||
|
||
1. `stripe_ledger` 基本欄位（最少）
|
||
- `id`（PK）
|
||
- `task_id`, `agent_id`, `human_client_id`
|
||
- `idempotency_key`（唯一）
|
||
- `phase`（auth_hold / capture / release / refund / payout / dispute）
|
||
- `stripe_object_id`（payment_intent_id / charge_id / refund_id）
|
||
- `request_payload_hash`
|
||
- `response_status`
|
||
- `http_status`
|
||
- `attempt`
|
||
- `source`（api / webhook / manual_replay）
|
||
- `created_at` / `updated_at`
|
||
|
||
2. ledger transaction requirement（交易守則）
|
||
- 對任務狀態轉換與 `ledger` 寫入必須同一個 DB transaction；任何失敗都回滾狀態，不可 partial success。
|
||
- 任何 webhook 重放都不能改變 `ledger` 的既有狀態機結果，除非是「可重放對帳修正」類別。
|
||
- webhook 處理路徑與 API 重試路徑都要走同一張 `stripe_ledger`，以便對帳。
|
||
|
||
3. drift 偵測與告警
|
||
- 每 1 分鐘比對 `ledger` 與 task 狀態：
|
||
- `capture` 已成功但 task 仍非 COMPLETED
|
||
- `release` 已成功但任務仍處於 EXECUTING
|
||
- 同一 task 同時間出現互斥副作用（capture + release + refund）
|
||
- 一旦發現 drift，進入 `incident_mode=true`，暫停 `claim_task` 新進任務。
|
||
|
||
4. 人工回補（runbook 入口）
|
||
- 提供 `ledger reconcile --task-id --range` 指令清單：
|
||
- 查重放記錄
|
||
- 重新查 Stripe object 狀態
|
||
- 產生 `correction_journal` 供審核
|
||
|
||
這樣做是因為：你不是要「先出成果」，你是要讓第一波外部 Agent 在你系統裡每一次動作都可以被你們會計、法務、客服、SRE 同時信任。
|
||
|
||
## Day 15-30 第二梯次執行順序（穩定化 + 控制擴張）
|
||
|
||
第一輪交易穩定後，Day 15-30 不追求新酷功能，而是做兩件事：
|
||
1) 讓系統在 10 倍壓力下還是可預期，2) 讓需求散播能力「可控」開啟。
|
||
|
||
### Day 15-21（Phase 2）：供給與媒合能力加強
|
||
|
||
1. `Task discovery` 欄位擴充（難度、技能、預估時長）
|
||
- Owner：API/Backend
|
||
- 验收：list_open_tasks 支援多條件過濾並維持 P95 < 300ms
|
||
|
||
2. `pgvector` 最小語意媒合 PoC
|
||
- Owner：AI Infra
|
||
- 驗收：單任務可建議 1~3 個候選 Builder，延遲 < 2 秒
|
||
|
||
3. `Reputation` v1 與節流落地
|
||
- Owner：Backend
|
||
- 驗收：新 Agent 同時 claim 限制 + 連續失敗 3 次 24 小時降權
|
||
|
||
4. 官方種子池補強（每天補齊，避免 OPEN 空白）
|
||
- Owner：PM/Admin
|
||
- 驗收：7 日連續 OPEN 非空比例 >= 99%
|
||
|
||
### Day 22-26（Phase 2）：金流與運維收斂
|
||
|
||
1. `dispute/refund` 進一步與 `reconciliation ledger` 對齊
|
||
- Owner：Finance + Backend
|
||
- 驗收：refund 事件可回溯到事件 id 與任務/agent 全鏈路
|
||
|
||
2. `FAILED_RETRYABLE` 自動重排與節流
|
||
- Owner：AI Infra
|
||
- 驗收：類型化錯誤可避免無限重試，平均重試率下降 > 30%
|
||
|
||
3. `judge budget` 成本看板
|
||
- Owner：Data
|
||
- 驗收：可監控錯誤類型、平均 runtime、容器啟動成本
|
||
|
||
4. 高併發重試壓測
|
||
- Owner：SRE
|
||
- 驗收：1k claim + 500 submit 並發下無 deadlock、無狀態漂移
|
||
|
||
### Day 27-30（Phase 3 鎖定門檻與白名單啟動）
|
||
|
||
1. `Scout 白名單`（5 家）內部驗證
|
||
- Owner：Growth + API
|
||
- 驗收：每家完成至少 3 次 `draft -> payment -> capture` 閉環
|
||
|
||
2. `Scout 風控` 啟動
|
||
- Owner：Security + Backend
|
||
- 驗收：轉換率健康度、spam、回報率告警規則生效
|
||
|
||
3. 商業可見指標 v1
|
||
- Owner：Finance
|
||
- 驗收：日結與平台抽成入帳可對帳、可匯出
|
||
|
||
## Scout 解鎖 Playbook（白名單到公開擴張）
|
||
|
||
### 一次性解鎖門檻（必須同時達成）
|
||
|
||
- Day 1-14 的核心 KPI 達標：
|
||
- `claim -> judge_pass -> capture` ≥ 10 筆
|
||
- capture 成功率 >= 95%
|
||
- dispute_rate < 5%
|
||
- reconciliation drift = 0 或已封存且可回補
|
||
- 7 日穩定性：
|
||
- `judge pass` 非 timeout 平均 >= 70%
|
||
- `list_open_tasks` 錯誤率 < 1%
|
||
|
||
### 斷點回退條件（未達標即停）
|
||
|
||
- `capture` 低於 95%：停發放新 Scout 任務，先修金流與 webhook 回放
|
||
- `dispute` 突升：自動降權高風險 Builder 與 Scout
|
||
- `judge pass` 低於 60%：維持白名單，禁止新增 Scout
|
||
- `incident_mode` 拉高：停用 Scout，保留既有任務人工處理
|
||
|
||
### 回退後恢復門檻
|
||
|
||
- 修正後 3 個連續觀測窗（每窗 24 小時）內：
|
||
- capture >= 95%
|
||
- dispute < 5%
|
||
- drift = 0
|
||
- 通過後：擴展 Scout 配額 2 倍/週，並保留每週復測
|
||
|
||
### 風險分類
|
||
|
||
- GREEN：公開散播前可以放量，但保留最小速率上限
|
||
- AMBER：只維持白名單，停用新邀請與外部渠道
|
||
- RED：全面停用 Scout，回到「Judge + 金流 + 對帳」閉環修復
|
||
|
||
## 追加建議（Phase 2/3 的三項真實增長指標）
|
||
|
||
除了交易成功率，這三項是防止「有量沒質」的關鍵：
|
||
|
||
- `conversion_health` = 成功付款 / 產生連結
|
||
- `post_capture_quality` = 24 小時內未退款/未提早 dispute 比率
|
||
- `incident MTTR` = 金流或 judge 影響事件平均回復時間（目標 < 30 分鐘）
|
||
|
||
任一指標連續 3 天異常，直接啟動：
|
||
- 停 Scout 擴張
|
||
- 緊縮 `judge` 併發與超時門檻
|
||
- 提高 `replay + reconciliation` 頻率
|
||
|
||
## Day 30-60：小流量公域拓展與成長機制（可控擴張）
|
||
|
||
### 目標
|
||
|
||
- 從白名單小規模擴張成「外部可穩定接觸」的第一層流量入口
|
||
- 不追求爆量，追求單位任務的成功率與回款品質不退化
|
||
- 建立可持續、可回溯的營收與運營儀表
|
||
|
||
### Day 30-40（Phase 3.1）
|
||
|
||
1. `Scout API` 白名單從 5 家增至 10~15 家
|
||
- Owner：Growth + Security
|
||
- 驗收：全部 Scout 流量都走白名單授權與速率門檻
|
||
|
||
2. `API Usage Quota` 動態化（按 `conversion_health` 調整）
|
||
- Owner：Backend
|
||
- 驗收：低轉換 Scout 自動降額，無人工介入
|
||
|
||
3. `Attribution` 串接完成（task -> scout -> builder -> payment）
|
||
- Owner：Backend + Data
|
||
- 驗收：任務可追溯到 3 層 ID 並可重建完整事件鏈
|
||
|
||
4. `Support / FAQ` 從單語意提升為半自動回覆
|
||
- Owner：PM + Support
|
||
- 驗收：失敗常見錯誤回覆時間 ≤ 5 分鐘
|
||
|
||
### Day 41-50（Phase 3.2）
|
||
|
||
1. `多來源任務輸入`：合作方 API + 手動上架並行
|
||
- Owner：API + PM
|
||
- 驗收：不同來源任務都可進入同一套狀態機
|
||
|
||
2. `Reputation` 加權模型更新
|
||
- Owner：AI Infra + Backend
|
||
- 驗收：成功率高的 Agent 推薦權重上浮，異常行為降權
|
||
|
||
3. `支付對帳` 每日快照 + 每小時告警
|
||
- Owner：Finance + SRE
|
||
- 驗收：每日對帳報表與警示可自動化發送
|
||
|
||
4. `金流風險測試`（refund burst / webhook delay scenario）
|
||
- Owner：SRE
|
||
- 驗收：可在 15 分鐘內完成 `incident_mode` 啟停
|
||
|
||
### Day 51-60（Phase 3.3）
|
||
|
||
1. `Scout 外部品牌內容` A/B 測試（3 條模板）
|
||
- Owner：Growth
|
||
- 驗收：conversion_health 不低於白名單期中值
|
||
|
||
2. `多區域監控`（核心服務與外部通道）
|
||
- Owner：SRE
|
||
- 驗收：關鍵告警跨 24h 保持可定位與可回放
|
||
|
||
3. `財務保底` 指標穩定化
|
||
- Owner：Finance
|
||
- 驗收：`platform_take >= 預算底線`、`post_capture_quality` 無明顯回落
|
||
|
||
4. `商業決策會議節點`（是否進入大規模公開）
|
||
- Owner：PM + Leadership
|
||
- 驗收：形成 go/no-go 決議與更新的 Gate 條件
|
||
|
||
## 30-60 Replaybook（SRE + 運營一頁式手冊）
|
||
|
||
### Playbook A：支付異常（capture/refund 偏差）
|
||
|
||
**觸發條件**：
|
||
- capture 成功率 < 95%（1 小時）或 webhook `event_id` 連續重複異常
|
||
|
||
**處置順序**：
|
||
1. 啟動 `incident_mode`（暫停新任務 claim）
|
||
2. 鎖定所有 `retryable capture` API 呼叫
|
||
3. 查 `reconciliation drift`：task 狀態 vs `stripe_ledger`
|
||
4. 對 `pending webhook` 重放，查 `Stripe event id` 是否可重試
|
||
5. 對有 `source=api` 的同日異常請求加 `idempotency` 標記並回填
|
||
6. 修正後每 5 分鐘回報一次狀態；問題解除後恢復 claim
|
||
|
||
### Playbook B：Judge 失效（大量 TEST_FAIL / TIMEOUT）
|
||
|
||
**觸發條件**：
|
||
- `FAILED_RETRYABLE` 比例 > 30%（15 分鐘）或平均 judge 延遲 > 2 倍基線
|
||
|
||
**處置順序**：
|
||
1. 限制 `judge_concurrency`，啟動 `cooldown queue`
|
||
2. 將 `timeout` 任務移入人工排查清單，不允許無限重試
|
||
3. 檢查 `error_signature` 熱點是否為測試環境退化（套件版本、快取污染）
|
||
4. 啟用 `runner fallback profile`（降速 + 重跑資源較高配置）
|
||
5. 通知 Builder 提交者：提供具體 `error_signature` 修正建議
|
||
|
||
### Playbook C：Scout 異常（spamming / conversion 失效）
|
||
|
||
**觸發條件**：
|
||
- conversion_health 連續 2 天下滑 30% 以上
|
||
- spam_score 過高（外部回報或 blocked ratio 上升）
|
||
|
||
**處置順序**：
|
||
1. 一鍵切換 `scout_scoped_mode=off`（暫停新轉介）
|
||
2. 將高風險 scout 列入 `quarantine`
|
||
3. 降低所有 scout daily API 配額 50%
|
||
4. 啟動邀請審核：逐一人工複核 template 與 payment link
|
||
5. 異常恢復後，逐步恢復配額（按比例）
|
||
|
||
### Playbook D：狀態機異常（超時/重複回退）
|
||
|
||
**觸發條件**：
|
||
- 某 task 在 10 分鐘內狀態切換超過 5 次
|
||
- `reconciliation drift` > 0
|
||
|
||
**處置順序**：
|
||
1. 鎖定該任務與相關 agent 的 `claim` 權限
|
||
2. 查 `audit log` 與 `ledger` 原始事件
|
||
3. 手動將任務壓到 `FAILED` 或 `OPEN`（依情境）
|
||
4. 生成 `correction_journal` 給合規與財務複核
|
||
5. 修復後恢復狀態轉換與排程
|
||
|
||
## Scout 資料模型（第一版，供 Phase 3 API 上線）
|
||
|
||
### `scout_tasks`
|
||
|
||
欄位（必要）：
|
||
- `id`（PK, UUID）
|
||
- `task_id`（FK -> tasks）
|
||
- `scout_agent_id`（FK -> agents）
|
||
- `source_platform`（reddit/github/discord/web）
|
||
- `source_ref`（原始貼文或 Issue id）
|
||
- `draft_payload`（JSON）
|
||
- `status`（draft/published/frozen/paid/disputed/archived）
|
||
- `conversion_health_score`（數值）
|
||
- `last_conversion_event_at`
|
||
- `created_at`, `updated_at`
|
||
|
||
約束：
|
||
- `source_ref` 需唯一，避免同一需求重複轉介
|
||
- 任務金流必須關聯 `stripe_ledger` 的 `task_id`
|
||
|
||
### `scout_reputation`
|
||
|
||
欄位（必要）：
|
||
- `id`（PK）
|
||
- `agent_id`（FK）
|
||
- `conversion_rate_7d`
|
||
- `click_to_payment_rate_7d`
|
||
- `spam_score`（0~100）
|
||
- `dispute_rate_30d`
|
||
- `cooldown_until`
|
||
- `status`（active/warned/quarantined/suspended）
|
||
- `policy_version`
|
||
- `updated_at`
|
||
|
||
規則：
|
||
- `spam_score >= 80` 轉入 `quarantined`
|
||
- `dispute_rate_30d > 10%` 降權，必要時暫停發牌
|
||
|
||
### `affiliate_ledger`
|
||
|
||
欄位（必要）：
|
||
- `id`（PK）
|
||
- `task_id`（FK）
|
||
- `scout_agent_id`
|
||
- `builder_agent_id`
|
||
- `platform_fee_rate`（例如 0.15）
|
||
- `scout_fee_rate`（例如 0.10）
|
||
- `builder_fee_rate`（例如 0.75）
|
||
- `gross_amount`（原始任務總額）
|
||
- `net_settlement_amount`
|
||
- `settlement_status`（pending/ready/settled/failed）
|
||
- `paid_at`
|
||
- `created_at`
|
||
|
||
金流邏輯：
|
||
- 只允許 `capture 成功 + 爭議期結束` 才可產生可結算 `affiliate_ledger` 行為
|
||
- 分潤任務需與 `task status` 與 `dispute_status` 做聯動，不可孤立結算
|
||
|
||
## 追加建議：Day 60 的公開放量判斷（可選）
|
||
|
||
若 Day 30-60 任一項不穩，繼續停留在 Phase 3 白名單：
|
||
- 先補 judge 報錯熱點
|
||
- 先修重試與對帳漂移
|
||
- 先回補外部客服與 support playbook
|
||
|
||
若全部穩定，可進入：
|
||
- Day 61-90：公開 Scout 開放、第三方合作通路、營收自動化優先支付
|
||
|
||
## Day 61-90：公開放量（Growth Flywheel）版本
|
||
|
||
### 目標
|
||
|
||
- 把 Day 30-60 的可控成長，轉成可持續增長曲線，而不是一次性拉高流量。
|
||
- 重點不是「任務量」本身，而是：
|
||
- 可維持高勝率交付的任務量
|
||
- 可控成本與可回款的任務量
|
||
- 可追溯且可抗爭議的營收量
|
||
|
||
### Day 61-70：公開通路啟動
|
||
|
||
1. 公開 Scout API（邀請制 V2）
|
||
- Owner：Growth + Backend
|
||
- 驗收：外部邀請入口使用率 > 40%，仍維持 conversion_health 不低於白名單基準
|
||
|
||
2. 任務模板標準化（Top 20 任務類型）
|
||
- Owner：PM + Backend
|
||
- 驗收：同類需求在不同來源的 pass/rollback 行為誤差可比較
|
||
|
||
3. `scout_reputation` 全鏈路導入 claim/submit gate
|
||
- Owner：Backend
|
||
- 驗收：低質量 Scout 不能跨任務反覆刷量
|
||
|
||
4. `Dispute` 服務化流程（仲裁 queue）
|
||
- Owner：Platform + Finance
|
||
- 驗收：爭議進入 4 小時內有第一次回應
|
||
|
||
### Day 71-80：經濟化與風險化繁簡
|
||
|
||
1. Payout 自動化升級（延遲結算 + 批次任務）
|
||
- Owner：Finance + Backend
|
||
- 驗收：支付批次可回溯、可重跑、可回補
|
||
|
||
2. 全量告警收斂至「三層健康度」
|
||
- Owner：SRE
|
||
- 驗收：系統可視化三層卡片（交易穩定 / 驗收穩定 / 流量品質）
|
||
|
||
3. 多維收斂測試（同時存在：外部流量暴增、judge 波動、webhook 重試）
|
||
- Owner：SRE
|
||
- 驗收：保留 `incident_mode` 時間 < 15 分鐘，關鍵告警不丟
|
||
|
||
4. 反濫用策略收斂（黑名單 + 行為圖模型）
|
||
- Owner：Security
|
||
- 驗收：spam 任務比率下降且誤封比例可接受
|
||
|
||
### Day 81-90：可交付成長版本判定
|
||
|
||
1. 形成「公開版商業門檻」決議
|
||
- Owner：PM + Leadership
|
||
- 驗收：明確 go / no-go 與對應資源需求
|
||
|
||
2. 版本化成長儀表（Cohort / LTV proxy / CAC proxy）
|
||
- Owner：Data
|
||
- 驗收：可按 source / scout / 任務難度看長短期留存與收益
|
||
|
||
3. 形成 v1.0 上線包清單
|
||
- Owner：Platform Team
|
||
- 驗收：列出下一版本可砍掉/必修/可延後項目
|
||
|
||
## Day 61-90 Go/No-go Gate（對外放量最終門檻）
|
||
|
||
- 強制條件（同時滿足）
|
||
- `capture` 成功率 30 日均值 >= 95%
|
||
- `dispute_rate` 30 日均值 < 4%
|
||
- `judge pass rate` 30 日均值 >= 72%
|
||
- `conversion_health` 不低於白名單期 7 日均值的 95% 以上
|
||
- `reconciliation drift` = 0（或已封存並有補償）
|
||
|
||
- 達標後方可執行：
|
||
- 全域公開 Scout 招募
|
||
- 第三方合作方批次導入
|
||
- 以營收自動優先級（而非人工臨時排序）做任務發布
|
||
|
||
- 未達標則觸發：
|
||
- 回到 Day 30-60 白名單策略
|
||
- 先修復 judge timeout 與資源 profile
|
||
- 先修支付事件回補（webhook + reconcile）
|
||
|
||
## 外部 AI 生態資訊採納機制（每週）
|
||
|
||
你要的「不要只看內部」這一層，我把它正式化成固定流程，避免戰略被時代落後。
|
||
|
||
### 周期節奏
|
||
|
||
每週三固定 45 分鐘，產出 1 份「外部訊號更新」：
|
||
1. MCP 生態安全與授權規格更新
|
||
2. 付款/扣款平台異常策略更新（Stripe 行為變更）
|
||
3. Judge/沙盒工具鏈性能與漏洞訊息
|
||
4. 供應鏈 AI 平台條款變更（MCP Marketplace / MCP registry）
|
||
|
||
### 取樣清單（優先順序）
|
||
|
||
1. 官方規格變更
|
||
- MCP 安全最佳實踐（授權、scope、confused deputy）
|
||
- Redis keyspace notifications 的事件保證邊界
|
||
2. 付款事件規則變更
|
||
- Stripe idempotency、webhook 重試語意、event 版本差異
|
||
3. 沙盒安全更新
|
||
- E2B / container runner 的隔離策略、資源配額、CVEs
|
||
4. 競品/同類平台策略
|
||
- 新的任務質量風控、Scount 激勵機制、反垃圾機制
|
||
|
||
### 議題落地機制
|
||
|
||
每次外部更新必須走三道：
|
||
|
||
1. `Signal`: 相關組員建立 ticket（Owner、風險、影響範圍）
|
||
2. `Impact`: 30 分鐘內做可判定影響分析（高 / 中 / 低）
|
||
3. `Action`:
|
||
- 高：72 小時內出修正 PR
|
||
- 中：1 週內補充監控/告警
|
||
- 低：入季度優化 backlog
|
||
|
||
### 外部訊號到決策的最小規則
|
||
|
||
- MCP 授權變更 => 立即列為 security-hardening 任務
|
||
- Stripe 行為變更 => 立即驗證 webhook 重試與對帳一致性
|
||
- Redis 事件語意變更 => 驗證 Redis timeout fallback 不被破壞
|
||
- 沙盒 CVE => 立刻停用受影響 profile，切到 fallback image
|
||
|
||
### 為何要這麼做（專業判斷）
|
||
|
||
第一階段的核心不是寫得快，而是讓系統不會因外部規範微變而瞬間掉速。
|
||
有了這個流程，你的「可擴張」不會依賴口碑幻想，而是依賴每週可量化的外部風險收斂能力。
|
||
|
||
## 2026-06-06 更新：v3.3 商模與流量可行性（把「能跑」推到「能賺」）
|
||
|
||
### 1) 先澄清目標：第一階段的商業最小成功定義
|
||
|
||
目前方向正確，但要避免只追求「有流量」：
|
||
- **第一階段目標**不是追求大流量，而是要證明「有可預測的、可持續的現金流」。
|
||
- 將指標從單一 `交易成功率`，擴充為：
|
||
- 流量進入（AI Agent 來源）
|
||
- 需求進入（人類需求者轉換）
|
||
- 成交率（capture 成功）
|
||
- 單筆單位經濟（platform take / dispute 成本 / 補償率）
|
||
- 是否能持續重複 3~7 日
|
||
|
||
### 2) 第一階段（Day 1-30）商業門檻（可直接當 Go/No-Go Gate）
|
||
|
||
**若以下任一條件不成立，建議暫不放量，先修復：**
|
||
|
||
#### 供給方流量（AI Agent）
|
||
1. 14 日內至少 60 筆有效 claim（外部 Agent 非官方）
|
||
2. 日均 open->claim 轉換率（外部）≥ 12%
|
||
3. 外部 Agent 的 FAILED_RETRYABLE 比例 < 35%（否則代表驗收門檻過高或測試任務品質問題）
|
||
|
||
#### 需求方流量（人類付費需求）
|
||
4. 每日至少 1 筆新需求者完成 `draft_task` 或 `直上架自建任務`
|
||
5. 需求方從 `查看示例頁` 到 `點擊預授權` 的轉換率 ≥ 1.5%
|
||
6. 支付鏈路 24 小時內完成 capture 至少 3 筆（若低於，代表需求導入未形成真實變現）
|
||
|
||
#### 收益與風險
|
||
7. 平台抽成（或差價）日均毛利 ≥ US$12（含 3 天滑動平均）
|
||
8. `退款/爭議` 造成的潛在成本 <= 平台毛利的 20%
|
||
9. `chargeback / dispute` 率 < 4%
|
||
|
||
### 3) 商模設計：雙方都能持續參與的最小閉環
|
||
|
||
#### 對 Builder AI 的價值
|
||
- 快速取得可完成任務，穩定獲得獎金，且有重試次數規則避免無限消耗。
|
||
- 待回報：每筆有可預測的 `Builder fee（建議 75%）`、透明失敗原因（error signature）、可追溯歷史績效。
|
||
|
||
#### 對 Scout AI 的價值
|
||
- Scout 不是廣告，而是「可持續導流的成交代理」，獎勵條件可用 `capture 成功 + 非爭議` 做結算。
|
||
- 建議採 **延遲結算**（如 72 小時）避免無效交易抽成。
|
||
|
||
#### 對需求方的價值
|
||
- 3 步完成需求轉換：草稿化需求 → 一鍵確認 → 付款授權 → 回傳成果。
|
||
- 設定可讀性規格卡（預估時間、測試條件、失敗處置、退款規則），降低認知成本。
|
||
|
||
### 4) Demand Side GTM：只靠 MCP 不夠，還要三條導流管道
|
||
|
||
#### A) 產品內導流（最先級）
|
||
1. `5 分鐘 demo` + 官方種子任務（保證展示成功案例）
|
||
2. 成功任務公開頁：列出任務前/后、測試證據、耗時、獎金分配
|
||
3. 「零接觸轉化」設計：未登入可先看任務流、可先試運行樣例、再選擇註冊
|
||
|
||
#### B) 外部 MCP 入口（第二優先）
|
||
1. 上架與標註 API 能力，提供最小可執行腳本
|
||
2. 針對流行 Agent 框架（例如 AutoGPT 類代理工具）放置標準串接 README
|
||
3. 每週一次「接案示例日誌」更新，降低開發者接入不確定感
|
||
|
||
#### C) Scout 擴散（第三優先）
|
||
1. 先做小規模白名單（3~5 家）
|
||
2. 要求每筆邀請鏈接都帶追蹤碼
|
||
3. 用 `轉換率健康值` 做配額配發，而非先用總量封頂
|
||
|
||
### 5) 不是只有技術：對賬與收費的商業保險絲（Recommerce Safety）
|
||
|
||
1. **分潤遞延**：Scout/Builder 分潤延後結算，保留 dispute 窗口，避免無法追回的無效抽成。
|
||
2. **異常任務封鎖成本模型**：若某 Builder 錯誤導致多次退款，立即降權或暫停。
|
||
3. **需求失真保險**：若需求方長時間未回應，任務需進入 `待補件`，避免無限等待佔用 pool。
|
||
4. **價格歸一化**：第一階段建議固定 3 段價格（$0.5 / $2 / $8），避免過多複雜定價影響決策成本。
|
||
|
||
### 6) 第一階段可執行商業路線圖（14 / 30 天）
|
||
|
||
#### Day 1-14
|
||
- 完成「可賺」最小條件：
|
||
- 至少 1 筆每日 capture
|
||
- 5 筆 claim 以上
|
||
- 完成 1 個可複製 demo 的成功範本
|
||
- 每日 gross margin >= 0（含人工支出仍為零）
|
||
|
||
#### Day 15-30
|
||
- 形成交易迴圈：
|
||
- 外部 Agent 轉化率持續上升
|
||
- 需求者新進入來源 ≥ 20% 來自外部可見入口（MCP + Scout + 合作入口）
|
||
- 第一次 3 天爭議率 < 6%，第 14 天降到 < 4%
|
||
|
||
### 7) 我建議新增的「商模與獲利」補充章節（下一次可直接塞到文件）
|
||
|
||
1. **VIB-017**：建立「需求方轉換儀表板」（曝光、草稿完成率、授權成功率）
|
||
2. **VIB-018**：建立「每日 P&L」模型（每任務：gross - stripe_fee - payout - refunds - support）
|
||
3. **VIB-019**：建立「Scout 測試客群」邀請流程（3 家白名單 + 轉換閾值）
|
||
4. **VIB-020**：建立「需求端快速 onboarding」文件（5 分鐘版本 + 視覺化任務流程）
|
||
5. **VIB-021**：建立「交易門檻自動化判定器」把 `Green/Yellow/Red` 直接綁定 `上架` / `限量` / `freeze`
|
||
|
||
### 8) 風險與提醒（這一段是我比較強勢的商模意見）
|
||
|
||
- **不要先追求大量 Scout 代理**，先確定 1~2 支高質量供給渠道能穩定賺錢，否則會放大品質事故。
|
||
- **不要把免費流量當作驗證替代**，免費流量只測得技術，不測得 economics。
|
||
- **先把需求端轉換做起來**，因為需求不足時，供應越豐富也是浪費成本。
|
||
- **把「放量」和「利潤」拆開：先放量 30%，再放量 60%，最後才放量 100%，每一階段都要過 Day Gate。
|
||
|
||
我不是不要技術，而是：**先把金流與需求導入變成同一個可度量模型，技術才會變成可賺的槓桿，而不是成本中心。**
|
||
|
||
## 2026-06-06 更新：v3.4 漏洞稽核（先賺、再放大）＋專家視角補盲
|
||
|
||
你問得很好：到目前為止，架構面已經很強，但要把「能跑」變成「能穩定賺」，還有幾個常被低估的缺口。
|
||
以下不是否定，而是把第一輪失敗成本壓到最低的「硬約束」。
|
||
|
||
### 一、這一輪還可能漏掉的 14 類思考（高優先度）
|
||
|
||
1. **需求端品質保證（Demand Quality Gate）**
|
||
- 問題：AI 很快把任務接起來，但需求規格是否有效、可驗證、可交付可能不穩。
|
||
- 指標：每週「需求失真率」低於 8%（需求方不回覆、標註失真、返工率）。
|
||
- 負責：PM + Builder PM。
|
||
|
||
2. **首位需求者信任設計**
|
||
- 問題：需求方怕詐騙/不透明，不知道誰在做、多久交付、如果退費多久處理。
|
||
- 指標：新需求者首次支付前完成 Demo 視覺頁的停留時長、回退率、客服詢問率。
|
||
- 負責：PM + 法務 + 客服。
|
||
|
||
3. **價格彈性與預期管理**
|
||
- 問題：固定 3 段價位是好開始，但要避免錯價導致低價惡性競爭或高價無人接單。
|
||
- 指標：每價位段的成交率與任務放棄率；價格區間轉換率。
|
||
- 負責：商務 + Product。
|
||
|
||
4. **獲利模型中的稅務與保留金**
|
||
- 問題：未先規畫稅務留存，早期「毛利」看似正但實際現金不進帳。
|
||
- 指標：Payout 週期、稅務預留比例（建議先預估 15~25% 緩衝）、可提領淨額精度。
|
||
- 負責：Finance + 法務。
|
||
|
||
5. **Builder/Scout 反向激勵失衡**
|
||
- 問題：只看量獎勵容易放大劣質輸出，尤其重試率高時成本會失控。
|
||
- 指標：Builder 平均 FIRST PASS 率、FAILED_RETRYABLE 與 FAIL_RETRYABLE 分佈、連續失敗降權時間。
|
||
- 負責：Ops + PM。
|
||
|
||
6. **外部流量來源風險池化**
|
||
- 問題：外部來源（如某 MCP 客戶端版本更新或某社群渠道）可能突然退潮。
|
||
- 指標：任一來源佔比不得超過 45%，來源多樣性 Gini > 0.55（越高表示越集中，風險上升）。
|
||
- 負責：Growth + 資訊安全。
|
||
|
||
7. **客服時效與 SLA**
|
||
- 問題：第一批外部 Agent / 需求者最在乎「發生問題時，多久有回應」。
|
||
- 指標：P1 回覆 < 15 分、P2 < 2 小時、P3 < 24 小時；Dispute 首次回應 < 4 小時。
|
||
- 負責：客服 + 運維。
|
||
|
||
8. **爭議處理資本成本**
|
||
- 問題：你可能以為爭議只影響聲譽，忽略了它的現金流鎖定。
|
||
- 指標：Dispute in-flight 金額、平均釋放/退款時長、待處理金額上限。
|
||
- 負責：Finance + 法務。
|
||
|
||
9. **資料保存與隱私**
|
||
- 問題：代碼、聊天、截圖、支付回執都可能需長期留存；缺少策略會阻塞合規/仲裁。
|
||
- 指標：任務留存天數符合條款；資料刪除 API 的覆核時間；備援恢復演習通過率。
|
||
- 負責：法務 + 資安 + 後端。
|
||
|
||
10. **品牌濫用與反垃圾法務壓力**
|
||
- 問題：Scout 自動外宣若過度，會被平台限流/封鎖，品牌會背黑鍋。
|
||
- 指標：平台封鎖事件率、外發訊息審核通過率、scout spam_score 平均值。
|
||
- 負責：法務 + Growth + Scout API Owner。
|
||
|
||
11. **資源定價與預算上限**
|
||
- 問題：Judge Sandbox、重試、replay、人工仲裁可能吞掉預算，導致早期虧損。
|
||
- 指標：每單測試成本、每成功交易毛利、月 burn 與安全預算佔比。
|
||
- 負責：Ops + FinOps。
|
||
|
||
12. **交易時間窗控**
|
||
- 問題：只要 judge 或 webhook 偶發抖動，外部流量即時下滑。
|
||
- 指標：P95 任務完成總時長、支付 from claim 的延遲分位、超時任務回收時間。
|
||
- 負責：SRE + 後端。
|
||
|
||
13. **反作弊與帳號濫用**
|
||
- 問題：套用多帳號刷單、重複創任務、低質量流量導量可能扭曲 KPI。
|
||
- 指標：異常行為比率、帳號風險分數、同設備多重帳號成功率。
|
||
- 負責：資安 + 欺詐防護。
|
||
|
||
14. **增長訊號未落地 KPI**
|
||
- 問題：有流量、也有成交，但未建立單日 LTV/CAC 粗估，無法判斷是否可持續放大。
|
||
- 指標：7 日回訪率、重複支付率、CAC/GMV、支付漏斗停損點。
|
||
- 負責：成長分析 + PM。
|
||
|
||
### 二、缺口對應的 v3.4 修正（可直接放 Jira）
|
||
|
||
- **VIB-022**：新增「需求品質守門員」任務卡（需求模板完整度檢核、需求驗證重試、需求方回應時限）
|
||
- **VIB-023**：建立首位需求者信任儀表（demo 呈現、進度透明、SLA 告示）
|
||
- **VIB-024**：新增「交易前現金預估」儀表（手續費、稅務預留、爭議風險、實際可提領）
|
||
- **VIB-025**：建立反濫用風控白名單（Scout、Builder、需求者個別風險分數模型）
|
||
- **VIB-026**：第一版客服與爭議 SLA Playbook（P1/P2/P3 分級 + 工單模板）
|
||
- **VIB-027**：新增需求來源去中心化（MCP/官方範本頁/合作入口）並做來源配額保護
|
||
- **VIB-028**：引入「支付與對帳週期」的現金流對帳報表（含預估可支付與待釋放）
|
||
|
||
### 三、Phase 1 先做的 7 / 14 / 30 天修復順序（實際執行）
|
||
|
||
- **7 天內（先固化）**
|
||
- 需求品質守門員上線（VIB-022）
|
||
- 客服 SLA 指標化（VIB-026）
|
||
- 交易前現金估算與退款風險欄位落實到任務頁（VIB-024）
|
||
|
||
- **14 天內（先可賺）**
|
||
- 來源去中心化與配額保護（VIB-027）
|
||
- 反濫用風控白名單/封鎖路徑（VIB-025）
|
||
- 需求轉換儀表板：曝光→草稿→預授權→capture→對帳
|
||
|
||
- **30 天內（先放大）**
|
||
- 現金流報表與提領結構上線（VIB-028）
|
||
- 建立 LTV/CAC 估算欄位（VIB-018 延伸）
|
||
- 形成可複用的日報：交易成功率、來源風險、客服等待時間、爭議回收率
|
||
|
||
### 四、關鍵結論：目前討論有沒有漏掉關鍵？
|
||
|
||
不再是「有沒有漏掉」，而是「有沒有先放對風險」：
|
||
|
||
1) 你現在已經沒有把重心放錯，仍然是「先交易再放量」正確。
|
||
2) 最容易漏掉的是：**需求端、風險資本、客服 SLA、稅務及來源集中度**。
|
||
3) 建議把 v3.4 視為 Phase 1 的「必上條件」，不是 v3 之後的美化章節。
|
||
4) 一旦以上 14 類缺口中任一高風險項目持續紅燈，無論 agent 接了多少，請直接暫停擴量與外部推廣，回到封口修復。
|
||
|
||
### 五、補充：Phase 1 失敗邊界一圖（可直接貼進文件）
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[外部流量進入] --> B[需求品質檢核]
|
||
B -->|通過| C[預授權 + 開始任務]
|
||
B -->|未通過| B1[需求修正回饋]
|
||
C --> D[Judge 驗證]
|
||
D -->|FAIL_RETRYABLE| C
|
||
D -->|FAIL_NONRETRY| E[退款/解鎖 + 風控標記]
|
||
D -->|PASS| F[Capture + 對帳入帳]
|
||
F --> G[支付前估算]
|
||
G --> H{可否提領?}
|
||
H -->|是| I[Payout 與分潤]
|
||
H -->|否| J[待解鎖/爭議窗口]
|
||
E --> K[客服 / 7x24 告警]
|
||
K --> L[停用 / 降權]
|
||
L --> M[流量重新配額]
|
||
```
|
||
|
||
### 六、外部 AI 生態（非技術）補充訊號（每週一次）
|
||
|
||
除 MCP/Stripe/Redis/E2B 技術更新外，請把以下訊號並入「商模監控」：
|
||
- 代理市場行情：熱門 MCP 工具是否更偏向「被動接單」還是「主動拓客」
|
||
- 需求來源變化：開發者社群、No-code 平台、客服導流是否在變
|
||
- 平台規範更新：Auto outreach、爬蟲、商用 API 條款
|
||
- 收費模式比較：同類服務是否開始收取平台使用費或預付款門檻
|
||
|
||
若這條訊號持續惡化（需求來源乾涸、爬文規範收緊、平台關係收緊），
|
||
第一反應不是擴大資源，而是切換為「單路徑高品質需求」加「更高轉換率的官方導流」。
|
||
|
||
## 2026-06-06 更新：v3.4.1 台灣優先市場補強（Perplexity + Gemini 討論整合）
|
||
|
||
你現在的判斷很到位：先做 **1、3、4**（法律/隱私/爭議）是正確的，尤其在台灣先上線時更是 Phase 1 生存題。
|
||
以下是我把兩邊觀點轉成「可直接落地」的補強版本，並加入台灣市場特殊風險。
|
||
|
||
### 一、對 Perplexity 6 項盲點的判斷：我同意度與補齊方向
|
||
|
||
#### 1) 法律與合規（最高優先）
|
||
同意：AI 產出責任、版權、WCAG、最終責任邊界若沒定義，會被放大成大尺度風險。
|
||
補強重點：
|
||
- PRD schema 增加法務欄位（不可缺）
|
||
- `license_mode`: `platform_license`, `customer_uploaded`, `third_party_component`
|
||
- `liability_waiver_accepted`: `boolean`
|
||
- `use_case_category`: `consumer|b2b|internal|sensitive`
|
||
- `accessibility_target`: 至少 `wcag_level=AA`（如果不適用要有明確豁免）
|
||
- Judge L1 增加安全 lint
|
||
- ESLint security plugin
|
||
- 前端安全規則（禁止 `dangerouslySetInnerHTML` 無衛化、禁止可疑 inline script、硬編碼 API key pattern）
|
||
- 生成物交付頁需保留「責任分級」與「風險揭露」
|
||
- `客戶自負責最終上線風險`
|
||
- `若涉金融、醫療、支付功能需另行法務審查`
|
||
|
||
#### 3) 資料洩漏與隱私（最高優先）
|
||
同意：這是你現在可以先做的最大防線之一。
|
||
補強重點：
|
||
- 在需求入庫前執行本地 PII 脫敏
|
||
- 名稱、電話、Email、身分證、卡號、地址、金融帳號做 regex + 實體 NER 遮罩
|
||
- 脫敏結果寫入 `privacy_scan_result`
|
||
- E2B 環境再加一層
|
||
- 完全封鎖外連
|
||
- 僅允許白名單 package 下載
|
||
- 禁止 DNS 解析外部主機（避免資料外流）
|
||
- 增加「敏感域名阻斷清單」與「高風險關鍵字回退機制」
|
||
|
||
#### 4) 爭議與客服成本（最高優先）
|
||
同意：你抓到的不是偶發問題，而是規模化前必爆炸的運營成本。
|
||
補強重點：
|
||
- Day 14 Gate 新增 1 個硬指標：`dispute_handle_cost_per_task < $2`（含初版人工處理）
|
||
- 引入自動仲裁：
|
||
- `error_signature` 明確為非爭議（PASS）時，直接按程式失敗判定
|
||
- 若人類提出 dispute，但任務有可證據 PASS，降權人類信譽、提高風險要求
|
||
- Scout 分潤加 `dispute_hold_period`（建議 72 小時）
|
||
- 未結束 dispute 視為未完成，不可結算
|
||
|
||
### 二、補上你們討論中 2 個很關鍵、但容易被忽略的深水點
|
||
|
||
#### A) 惡意提示詞注入 / Jailbreak
|
||
這在台灣平台上也會變成「外部平台封鎖 / 資安漏洞」風險。
|
||
補強：
|
||
- 建立 `system prompt` 指令層級隔離
|
||
- 將人類輸入視為 `data`，不可直接覆寫 `schema` 權限欄位
|
||
- 新增 Prompt Injection 偵測規則到 `draft_task` 前處理
|
||
|
||
#### B) 設計系統一致性（你已提醒過）
|
||
多 Agent 拼裝時，如果無 design token 驗證，最後交付就會是「看得懂但品質不穩定」。
|
||
補強：
|
||
- PRD 強制要求 `theme token`：背景/文字/按鈕/spacing 使用 token 名稱
|
||
- 禁止 hardcode 色碼、字級、行高
|
||
- Judge L2 除功能測試，增加「視覺一致性 lint」：
|
||
- 檢查是否大量出現非 token class
|
||
- 禁止 `!important`、內聯 style 汙染、臨時 CSS
|
||
|
||
### 三、Perplexity 建議中我認為可延後到 Phase 2 的項目（並非否定）
|
||
|
||
2) 稅務與國際金流、5) 可觀察性成本護欄、6) Scout spam 管控
|
||
可放在 `Phase 2` 的同步清單中：
|
||
- 理由：Phase 1 在台灣先驗證交易鏈、司法可解釋度、客服/對帳穩定度更緊急。
|
||
- 但**資料欄位應在 Phase 1 就預留**，避免 Phase 2 大改。
|
||
- `tax_region`, `tax_reportable`, `judge_budget_ms`, `judge_cost_accumulator`, `spam_score`, `conversion_health_score`.
|
||
|
||
### 四、台灣優先市場的補充缺口（這是高價值但容易漏掉）
|
||
|
||
1. **外籍金流與台灣本地支付認知差異**
|
||
- 設計「台幣顯示」「美元/台幣雙幣種」頁面。避免需求者看見金額後無法立即判斷實際付款成本。
|
||
- 先以新手友善路徑提供「台幣試用任務」與「小額快速任務（NT$）」
|
||
|
||
2. **台灣法規與客服歸責文件語言**
|
||
- 條款與同意流程要有完整正規中文（非只機械翻譯），避免因語言歧義引發同意效力問題。
|
||
- 在任務啟動前補 3 秒同意頁（可跳過但需記錄）
|
||
|
||
3. **個資法與合作資料界線**
|
||
- 任務、對帳、聊天紀錄要有保存與刪除策略（保留與刪除皆可追溯）
|
||
- 對敏感需求（醫療/金融）應直接轉人工篩檢，避免自動交付風險外溢
|
||
|
||
4. **客服渠道本地化**
|
||
- 第一期先上線可追溯客服入口（Email + LINE 官方帳號 + 回報單），並在 dispute flow 預留 `中文回覆模板`
|
||
|
||
5. **品牌風險管理（平台聲譽）**
|
||
- 所有 Scout 外發模板都要掛「來源標識 + 明確可取消機制」，避免被認定為垃圾外宣而封鎖
|
||
|
||
### 五、v3.5 建議直接落地 Ticket（可直接切為 Jira）
|
||
|
||
- **VIB-029**：PRD 法務欄位上線（license_mode / liability_waiver_accepted / wcag)
|
||
- **VIB-030**：法務級 `Prompt Injection` 防護規格與測試用例
|
||
- **VIB-031**：PII 本地脫敏中介與隱私掃描欄位（privacy_scan_result）上線
|
||
- **VIB-032**：Dispute Auto-Arbitration v1（error_signature 風險分流 + 成本指標）
|
||
- **VIB-033**：台灣導向版規範化條款（中文同意流程 + 多幣種與單位）
|
||
- **VIB-034**：Design Token 驗證（硬編碼樣式攔截 + L2 視覺一致性規則）
|
||
|
||
### 六、建議版本順序（更新）
|
||
|
||
- **Phase 1（先行）**
|
||
1. 法務欄位 + PII 脫敏 + dispute 成本（VIB-029、VIB-031、VIB-032）
|
||
2. 服務文件補齊（中文同意、台幣顯示、客服模板）
|
||
- **Phase 2（穩定）**
|
||
1. prompt injection 與 Design Token 驗證（VIB-030、VIB-034）
|
||
2. 稅務欄位預留 + scout/spam 指標化
|
||
|
||
### 七、結論（直接回答你的問題）
|
||
|
||
Perplexity 和 Gemini 的兩邊資訊是對的，而且方向有明顯共識：
|
||
- **你現在該相信、先做的是：信任邊界（法律 / 隱私 / 爭議）**
|
||
- **你現在可以稍晚做的是：規模化效率（稅務與 judge 成本優化、完整 spam 深控）**
|
||
- 在台灣先上線，若先把這三層守住，後續才能靠 MCP + Scout 正常放量，而不是用廣告流量掩蓋「制度未到位」的缺口。
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A[需求輸入] --> B[PII 預處理]
|
||
B --> C[PRD 生成 + 法務欄位強制]
|
||
C --> D[Builder claim]
|
||
D --> E[Judge 測試 (功能/安全/樣式)]
|
||
E -->|PASS| F[Capture + 對帳]
|
||
E -->|FAIL_RETRY| G[可重試 + 錯誤簽章]
|
||
E -->|FAIL_NONRETRY| H[Refund + 法務記錄]
|
||
F --> I{Dispute ?}
|
||
I -->|否| J[待結算日誌 / 分潤 hold]
|
||
I -->|是| K[Auto Arbitration + 客服]
|
||
K --> L[判定結果 + 可追溯風險 score]
|
||
```
|
||
|
||
## 2026-06-06 更新：v3.5 台灣合規與個資治理（AI 基本法 + PDPA）—Phase 0 強制項目
|
||
|
||
你這一版非常完整，已可直接進到總規劃。作為回應：**同意併入 Phase 0，且先做。**
|
||
|
||
### 一、共識：先做「可持續合法」而非先做「先上先賺」
|
||
|
||
### 台灣市場一級優先目標（Phase 0 Kill Switch 控制）
|
||
如果以下任一條件成立，立刻暫停新流量放入：
|
||
1. 有人資安/法務指出 `pii_found=high` 還被送入雲端模型。
|
||
2. 產出未完整記錄 `ai_generated`/`liability waiver`（責任聲明）且未通過審核。
|
||
3. Copyright claim 被證明成立且處理超過 72 小時。
|
||
4. dispute 的人工成本失控（`dispute_handle_cost_per_task > NT$60`）且無自動裁決率。
|
||
|
||
### 二、台灣法制對應到資料契約（立即可切票）
|
||
|
||
#### A) AI 基本法對應（透明＋安全）
|
||
- 需求/任務輸出層增加「AI 可辨識與責任邊界」：
|
||
- PRD 層：`ai_generated: true`
|
||
- 交付程式碼注入隱性水印註解（例如：`Generated by VibeWork AI`）
|
||
- 交付頁明示：`human-reviewed`、`final responsibility owner`
|
||
- 風格禁止清單：
|
||
- `forbidden_styles: string[]`
|
||
- 命中高風險商標或品牌特徵時，直接拒絕任務草稿並要求人工確認
|
||
|
||
#### B) PDPA 導向（隱私先行）
|
||
- 建立本地脫敏中介（Local Sanitization Service）：
|
||
- API Gateway → Sanitizer → LLM → Judge，形成不可跳過的中介層
|
||
- 檢測規則至少含：Email / 手機 / 身份證字號 / 統編 / 地址高機率片段
|
||
- AuditEvent 保留：
|
||
- `privacy_scan: { pii_found, pii_removed, risk_level }`
|
||
- `risk_level = high` 則立即回 422，不可繼續推進到雲端模型
|
||
- 明確寫明用途條款（specific purpose）：
|
||
- 只取「任務生成與驗收」所需欄位
|
||
- 超出用途即拋 `scope_violation` 並停止流程
|
||
|
||
#### C) 金流 + 稅務資訊欄位先行
|
||
- Settlement schema 新增：
|
||
- `tax_region`, `tax_rate_snapshot`, `tax_reportable`
|
||
- `dispute_hold_hours`（建議 72 小時）
|
||
- `hold_release_reason`
|
||
- 未完成稅務引擎之前，先做「欄位準備 + 計算邏輯抽象」，避免後續大改。
|
||
|
||
### 三、你給的補強項目（COMPL）→ 我建議變成可執行版本
|
||
|
||
- **COMPL-001：AI 標示自動化**
|
||
- `ai_generated` 標記 + hidden watermark
|
||
- 對每次交付輸出進行可追溯注記
|
||
- **COMPL-002：PII 脫敏服務**
|
||
- 本機 NER/Regex 混合，含高危台灣樣式規則
|
||
- 寫入 audit（可追溯）
|
||
- **COMPL-003：侵權檢舉 API**
|
||
- `POST /api/v1/copyright-claim`
|
||
- 72 小時處置 SLA + 暫停/下架機制
|
||
- **COMPL-004：稅務欄位擴展**
|
||
- `tax_region` / `tax_rate_snapshot` / `tax_reportable`
|
||
- **COMPL-005（新增）：台灣一線客服保全**
|
||
- 中文授權條款、爭議模板與補償流程在同一任務頁面可見
|
||
- 同步標示 dispute 保留金流時間與責任歸屬
|
||
|
||
### 四、Phase 0 最佳實作順序（我建議）
|
||
|
||
1. **Day 1–2：合規護城河先上**
|
||
- COMPL-002 + COMPL-001 + `privacy_scan` 寫入 `AuditEvent`
|
||
2. **Day 3–5：可裁決證據**
|
||
- COMPL-003、`error_signature` + 自動仲裁前置規則
|
||
3. **Day 6–10：金流風險封鎖**
|
||
- COMPL-004 + dispute_hold + dispute_cost 指標化
|
||
4. **Day 11–14：台灣啟動 Gate**
|
||
- 驗證 1 次 high-risk 擋檔、1 次侵權申訴、1 次自動仲裁、1 次 dispute_hold 釋放
|
||
|
||
### 五、我補上兩個你還沒明講但會讓你少踩坑的台灣實戰項目
|
||
|
||
- **保全包導出**：每筆任務需能 1-click 匯出「合規包」
|
||
（輸入原文、脫敏報告、judge 報告、付款事件、裁決紀錄）以便日後申訴與稽核。
|
||
- **客服語意一致**：客服回覆模板固定三段式：
|
||
1) 事實邊界（做了什麼）
|
||
2) 權責邊界（誰該承擔）
|
||
3) 修復邊界（多久解決 / 如何申訴）
|
||
|
||
### 六、v3.5 Mermaid（台灣合規版）
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[需求提交] --> B[Sanitizer 層]
|
||
B -->|high| X[block + 422 + 引導清洗]
|
||
B -->|low| C[PRD 生成]
|
||
C --> D[forbidden_styles 檢查]
|
||
D -->|reject| X2[refuse + claim mode]
|
||
D --> E[Judge (功能/資安/樣式)]
|
||
E -->|PASS| F[Capture + 對帳 + 稅務欄位]
|
||
F --> G[待分潤 / dispute hold]
|
||
G --> H[72h 觀察窗]
|
||
H -->|無爭議| I[自動分潤]
|
||
H -->|有爭議| J[Auto Arbitration]
|
||
J -->|可機判| K[快速結案/保留]
|
||
J -->|需人工| L[客服工單 + 成本追蹤]
|
||
```
|
||
|
||
### 七、直接回答你的問題
|
||
|
||
這份內容**值得直接併入主規劃**，而且可以視為 v3.5 的 Phase 0 合規啟動線。
|
||
下一步如果你同意，我會直接補到同一份文件的「程式骨架條目」，先寫出：
|
||
- `AuditEvent` `privacy_scan_result` schema
|
||
- `Sanitizer Middleware` middleware 流程
|
||
- `/api/v1/copyright-claim` API 契約範例
|
||
- `dispute_handle_cost` 監控公式
|
||
|
||
這樣我們就能直接進入最小可實作階段，而不是只停在討論。
|
||
|
||
---
|
||
|
||
## 2026-06-07 更新：VibeWork Phase 1 完整解決方案（AI Agent 引流 + 需求導入 + 初步變現）
|
||
|
||
> 目標：驗證 Phase 1 是否能在 30 天內完成「外部 AI Agent 進站接案 → Scout 導入需求 → 可核對第一輪交易與收入」
|
||
|
||
### 一、Phase 1 進攻式判斷標準（唯一目標）
|
||
1. 供給端進站：外部 AI Agent 能穩定完成 `list_open_tasks -> claim_task`（首輪白名單）
|
||
2. 需求端進站：Scout 幫忙將外部需求轉為可付款 lead，並進入任務流程
|
||
3. 交易端閉環：lead 可轉為 task，完成 `judge pass -> capture -> payout_ready`
|
||
4. 現金流成立：第一批交易可持續、可稽核、可回損回補（dispute 與退款可控）
|
||
|
||
### 二、第一階段商業結構（進攻優先）
|
||
#### 1) 三主力通道（同步推進）
|
||
- **A 檔：MCP 入口（核心獲客）**
|
||
- 先把 `vibework-monetization-mcp` 做成「可掛載即接案」入口，優先推上 MCP registry 與高訊號社群資源。
|
||
- 核心價值：把流量從「被發現」轉成「可成交」。
|
||
|
||
- **B 檔：Demand Acquisition Plane（需求導流平面）**
|
||
- 提供外部 Agent 可用 API：`acquire lead -> confirm -> payment -> task launch`
|
||
- 不要求需求者學會完整平台流程；以 AI 協助完成付款與確認為主。
|
||
|
||
- **C 檔：Scout 白名單（外部導流）**
|
||
- 第一階段僅開啟 3–5 支高品質 Scout（人工挑選）。
|
||
- Scout 僅發受控邀約模板，不做自由文案發文。
|
||
- 重點目標是測試「AI 導流可形成可結算需求」。
|
||
|
||
#### 2) 價值主張
|
||
- **對 Builder Agent**：前 7–14 天優先保證能接到任務、可驗收、可得款。
|
||
- **對 Scout**：有機會參與分潤，但需以 capture 成功與規則回補完整為有效條件。
|
||
- **對需求者**：提供 3 分鐘需求提交 + 一鍵授權支付，不需理解 MCP/任務底層術語。
|
||
|
||
#### 3) 收益與風險平衡（第一版）
|
||
- capture 成功後先行釋放分潤（現金流先行）。
|
||
- 加入：`provisional payout + reserve pool + replay ledger + dispute hold`。
|
||
- 核心不是「全鎖」而是「可回補」；先跑起來，後續再加深防護。
|
||
|
||
### 三、系統流程設計（DAP + Marketplace 分離）
|
||
#### 1) 狀態模型（v1）
|
||
- Demand 流程狀態：
|
||
- `SCOUT_DISCOVERED`
|
||
- `PREQUALIFIED`
|
||
- `DRAFT_TASK_READY`
|
||
- `CUSTOMER_CONFIRM_PENDING`
|
||
- `PAY_LINK_ISSUED`
|
||
- `PAY_AUTHORIZED`
|
||
- `TASK_LAUNCHED`
|
||
- `CAPTURED`
|
||
- `DISPUTED`
|
||
- `RESOLVED`
|
||
- Marketplace 流程狀態：
|
||
- `OPEN`
|
||
- `CLAIMED/EXECUTING`
|
||
- `VERIFYING`
|
||
- `COMPLETED/CANCELLED/FAILED`
|
||
- `DISPUTED`
|
||
- `RESOLVED`
|
||
|
||
#### 2) 核心原則
|
||
- `lead_id` 與 `task_id` 一對一可追溯，所有關聯事件皆可逆向查詢。
|
||
- `lead` 先存在；僅當 `CONFIRM + 支付授權` 後，才生成正式 `task`。
|
||
- 所有轉換皆寫入可追蹤事件：含風險分級、品質分級、決策原因。
|
||
- 任務池與需求池拆分，避免「有需求未成交」污染對外公開任務看板。
|
||
|
||
#### 3) 風險分層
|
||
- HIGH 風險 lead：直接人工稽核，不進任務池。
|
||
- C 級任務：僅導向 onboarding/訓練，不進外部主池曝光。
|
||
- B 級任務：白名單優先。
|
||
- A 級任務：外部主池。
|
||
|
||
#### 4) Mermaid：總體流程
|
||
```mermaid
|
||
flowchart TD
|
||
S[外部 AI / Scout 看到需求訊號] --> A[POST acquire/lead]
|
||
A --> B[Prequal + Sanitization]
|
||
B -->|pass| C[DRAFT_TASK_READY]
|
||
B -->|risk high| X[人工審核 + 封存]
|
||
C --> D[CUSTOMER_CONFIRM_PENDING]
|
||
D --> E[一鍵支付連結]
|
||
E --> F[授權成功]
|
||
F --> G[task launch -> OPEN]
|
||
G --> H[list_open_tasks]
|
||
H --> I[claim_task]
|
||
I --> J[submit_solution]
|
||
J --> K[Judge pass]
|
||
K --> L[capture]
|
||
L --> M[provisional payout]
|
||
M --> N[provisional hold + reserve pool]
|
||
```
|
||
|
||
### 四、Growth + GMV 執行策略（第一階段專用）
|
||
#### 1) 進攻型產品資產
|
||
- **3 分鐘需求入口**（最短阻力）
|
||
1. 模板選擇
|
||
2. 一句話需求
|
||
3. 自動生成草案
|
||
4. 一鍵支付
|
||
5. 提交
|
||
|
||
- **Agent 10 分鐘 Quickstart**
|
||
- 3 類 demo 任務（helloworld UI、樣式修正、微元件）
|
||
- 最小錯誤碼字典：`retryable / non_retryable / human_escalation`
|
||
- 10 分鐘閉環範本：`list_open_tasks -> claim_task -> submit_solution -> judge pass/fail`
|
||
|
||
- **Trust/成交頁（必做）**
|
||
- 公開披露 judge 流程、支付節點、分潤拆解、爭議邊界、客服 SLO。
|
||
- 與任務頁/客服頁分離，避免混淆。
|
||
|
||
- **成功案例頁（首批可追溯）**
|
||
- 每筆至少提供：需求摘要、草案鏈接、judge pass 證據、capture 結果、花費/時長。
|
||
|
||
#### 2) Scout 白名單計畫
|
||
- 3–5 支 Scout，逐一設定：
|
||
- 可投遞 channel（GitHub / Reddit / 社群）
|
||
- 受控回覆模板（禁止自由發文）
|
||
- 指標：曝光→點擊→支付→capture
|
||
- 自動降載條件：
|
||
- conversion 持續低於門檻
|
||
- spam_score 上升
|
||
- refund/dispute 率異常
|
||
|
||
#### 3) 佔位內容策略（防空池）
|
||
- Day 1 先建立 20–40 筆低門檻官方種子任務，優先快成交。
|
||
- 任務難度分層，確保新進 Agent 有「可完成」體驗。
|
||
- 每筆任務包含：acceptance criteria、回傳示例、錯誤排查（常見失敗）
|
||
|
||
#### 4) Mermaid：三條漏斗關係
|
||
```mermaid
|
||
flowchart LR
|
||
D[Demand Funnel] --> A[Agent Funnel] --> C[Conversion Funnel]
|
||
D --> D1[view->submit]
|
||
D1 --> D2[draft_confirm->pay]
|
||
A --> A1[open->claim]
|
||
A --> A2[claim->submit]
|
||
A --> A3[submit->judge_pass]
|
||
C --> C1[claim->capture]
|
||
C --> C2[capture->payout_ready]
|
||
```
|
||
|
||
### 五、KPI、Gate 與日常運營（第一優先）
|
||
#### 1) Day 1–14 最小生存門檻
|
||
- `claim_success` 首週 >= 8%，第二週 >= 12%
|
||
- 外部 demand conversion >= 1.5%
|
||
- 第一筆 capture 在前 7 天完成
|
||
- Trust page / 成交頁上線（未上線不啟動 scout 外部擴量）
|
||
|
||
#### 2) Day 15–30 成長門檻
|
||
- `capture_success >= 95%`
|
||
- `dispute_handle_cost_per_task <= NT$60`
|
||
- `open_task_stockout` 每日低於 5%
|
||
- 三條漏斗（Demand / Agent / Conversion）完整可視化，有可回滾趨勢線
|
||
|
||
#### 3) Gate / Failback（硬規則）
|
||
- 任一核心漏斗紅燈持續 24 小時以上：先封鎖新 scout 外放量，先做 quickfix + demo 補齊。
|
||
- demand conversion 停滯：先優化轉單頁與支付文案，不先擴張渠道。
|
||
- builder 失敗率上升：先修 quickstart、judge error guidance。
|
||
|
||
#### 4) Mermaid：紅線 Playbook
|
||
```mermaid
|
||
flowchart TD
|
||
M[每6小時 KPI 盤點] --> S1{claim_success達標?}
|
||
S1 -->|No| B1[封鎖新 scout 外流量]
|
||
S1 -->|Yes| S2{capture>=95%?}
|
||
S2 -->|No| B2[開啟 builder 修復 sprint]
|
||
S2 -->|Yes| S3{dispute_cost<=NT$60?}
|
||
S3 -->|No| B3[降額 scout / 延長 hold]
|
||
S3 -->|Yes| G[保留增量 scout + 小規模放量]
|
||
```
|
||
|
||
### 六、測試與驗收場景（v1，不立即上線）
|
||
1. MCP 新 Agent 首次接案到 capture 成功閉環
|
||
2. 需求者 3 分鐘入口完成一次 payment link 轉 task
|
||
3. 同一 lead idempotent 重複提交不重複建任務
|
||
4. 高風險內容進入人工 queue，禁止進 task pool
|
||
5. Scout token 重播/濫發阻擋，事件可追溯
|
||
6. 併發 100 筆 lead 時，lead/task 關聯完整且無 state 汙染
|
||
7. capture → payout → dispute hold 全程保留可稽核事件
|
||
|
||
### 七、落地文件結構（直接插入 MD）
|
||
- `2026-06-07 更新：Phase 1 進攻版解決方案（第一輪變現導向）`
|
||
- `Demand Acquisition Plane v1 產品規格（台灣優先）`
|
||
- `Lead vs Task 狀態機與追溯規則`
|
||
- `Scout 白名單第一波實驗方案`
|
||
- `Trust + 成交頁 + 成功案例規格`
|
||
- `30 天執行 + Go/No-Go + 例外回退`
|
||
- `MCP/Scout/Builder 三漏斗 KPI 儀表盤定義`
|
||
- `Incident Playbook（高併發/返單/spam）`
|
||
|
||
### 八、假設與預設值
|
||
- 台灣優先，介面文案與金額以 `NT$` 為主，保留美元輔助。
|
||
- 分潤先行放行以支撐現金流，搭配 `provisional + reserve` 作回補護欄。
|
||
- Scout 第一階段採白名單 + token + 指紋去重。
|
||
- 不追求一次全功能，追求可觀測、可賺、可回滾的最小可擴展版本。
|
||
- 所有新增事件必須可追溯到 `lead_id`，可回到對應 `task_id`。
|
||
|
||
### 九、決策鎖（Phase 1 已定）
|
||
- 主軸優先：流量導入與變現，不先做全量風控擴張。
|
||
- scout 方式：白名單先行（3–5 家/組），質量優先。
|
||
- 上線順序：先讓需求進、任務轉、交易得，再加深防護。
|
||
- 三條漏斗儀表是第一階段成敗的唯一判斷依據。
|
||
|
||
---
|
||
|
||
## 2026-06-07 追加整合：Claude v3.2 實作版補齊與差異化修正
|
||
|
||
你貼的 v3.2 已經是非常完整的「戰鬥實務版」，對應到現有文件我們做**採納＋修訂**如下，不做重複而是補齊缺口。
|
||
|
||
### 一、直接採納（直接接上現有文件）
|
||
|
||
- 採納 `Open Bounty Board` 的 v3.2 版本欄位（`task_id / title / status / difficulty / scope_clarity_score / reward / prd_blocks / acceptance_criteria / settlement / communication`）到「任務契約規格」章節，作為 `v3.2_contract` 版本描述。
|
||
- 採納 SW-01~SW-20 明細與驗收方向，不重複定義，保留「Day1 20 筆高信心任務」現有實作節奏。
|
||
- 採納 `FAILED_RETRYABLE`、`PAYOUT_READY`、`PAYOUT_SETTLED`、`REFUND_PENDING` 這種中介/可觀測狀態；若你現行有對應流程可直接對齊，不再另建新機制。
|
||
- 採納 `Judge Result` 結構：`overall_result / tests[] / artifacts / error_signature / error_classification`，作為 Judge 回報的最小契約。
|
||
- 採納 Redis keyspace 通知 + 補償掃描雙軌（你已在前序版本有描述，這裡補上為「強制」）。
|
||
|
||
### 二、與現行文檔衝突項（建議統一）
|
||
|
||
#### 1) 種子池獎金池不一致
|
||
- v3.2 記載：100 筆種子池總額 `$100`
|
||
- 現行 Phase 1：100 筆種子池總額 `$500`
|
||
- **建議統一值**：保留 `$500` 作為 Phase 1 目標，並把 `$100` 視為「小規模風控/回歸種子池（v3.2 smoke pool）」。
|
||
|
||
#### 2) Schema 格式字眼
|
||
- v3.2 範例使用 `type: OBJECT/STRING` 大寫風格（文件示意）
|
||
- 現行文件與實作採 `JSON Schema` 小寫常規
|
||
- **建議**：v3.2 作為規格草稿示意，實作文件改沿用標準 JSON Schema 小寫。
|
||
|
||
#### 3) `claim_task` 身份欄位
|
||
- v3.2 範例有 `developer_wallet`，現行文件更傾向用 agent 身份+授權 token
|
||
- **建議**：優先保留 auth token 做主識別，再把 wallet 視為選填 metadata，避免綁死入口型態。
|
||
|
||
### 三、建議補齊到現行 MD 的 3 段
|
||
|
||
#### (1) 交易路徑：A1 / A2 次序
|
||
- 明確寫成：`claim_task -> auth-hold + ledger precreate -> judge verify -> capture -> payout`
|
||
- capture 之前一律不可進行外部 payout，避免對帳漂移。
|
||
|
||
#### (2) v3.2 監控告警矩陣
|
||
- 新增到你已建 `OODA Playbook` 的「紅燈條件」：
|
||
- `state_revert_lag_p99 > 90s` 持續兩小時
|
||
- `stripe_webhook_delay_p95 > 120m` 持續 2 小時
|
||
- `open_task_stockout_ratio > 15%` 持續 30 分鐘（需啟用官方種子補位）
|
||
|
||
#### (3) 3 條漏斗 + 可執行指標收斂
|
||
- Demand：view→submit、點擊→授權
|
||
- Agent：open→claim、claim→submit、submit→judge_pass
|
||
- Conversion：claim→capture、capture→payout_ready、dispute_hold 持續中位值
|
||
|
||
### 四、建議直接插入的 Mermaid（v3.2 版簡化）
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[acquire lead] --> B{prequal}
|
||
B -->|high risk| C[人工審核]
|
||
B -->|pass| D[DRAFT_TASK_READY]
|
||
D --> E[CUSTOMER_CONFIRM_PENDING]
|
||
E --> F[PAY_LINK_ISSUED]
|
||
F --> G[PAY_AUTHORIZED]
|
||
G --> H[TASK_LAUNCHED -> OPEN]
|
||
H --> I[claim_task]
|
||
I --> J[submit_solution]
|
||
J --> K[Judge Verify]
|
||
K -->|pass| L[capture + payout_ready]
|
||
K -->|retryable| M[FAILED_RETRYABLE]
|
||
K -->|non-retryable| N[FAILED]
|
||
```
|
||
|
||
### 五、專業看法：這份 v3.2 還缺的兩個「第一週會爆炸」點
|
||
|
||
1. **提交 payload 大小與檔案數上限不夠具體**
|
||
建議先加硬限制（如檔案總大小、總行數、單檔上限），否則 submit_solution 可被大型噪音 payload 擠爆 E2B runner 成本。
|
||
|
||
2. **Golden Task 不可缺席**
|
||
除了 SW-01，建議固定保留 5 個 Golden 任務（跨 `$1/$5/$10`）做每次部署前 smoke；否則你會在 UI 或 schema 小改中不知道是 regression 還是 judge 改壞。
|
||
|
||
### 六、下一步（已對齊你需求）
|
||
- 先補寫入：`v3.2_contract` schema 對位段（附版本欄位）
|
||
- 先補入：`JudgeResult` output schema（含 `error_signature`）
|
||
- 先補入：Seed pool 100 筆的「發佈與失敗重算流程」與「高風險擋檔紀錄」欄位
|
||
|
||
✅ 以上 3 段已在本文件 `2026-06-08 補盲版` 中補齊，且保留原流程順序不變。
|
||
|
||
---
|
||
|
||
## 2026-06-08 補盲版（v4.0）：補齊 Claude v3.2 缺失的生死點
|
||
|
||
你提的 3 大補盲是 Phase 1 可行性關鍵，這裡直接把它們併入 v3.2 對位章節並固化。
|
||
|
||
### 第一部分：金流防欺詐與台灣落地（補到第九章金流架構）
|
||
|
||
#### 1) 交易與合規新增要點（Anti-Fraud & Compliance）
|
||
1. Stripe Idempotency Key：每個 `capture/refund` 必含穩定 key（`task_id + amount + phase`），並有唯一約束。
|
||
2. Webhook 冪等：Stripe 重試 3 天，API 必須有去重鎖與 replay-safe handler（`Stripe-Event-Id` / `event_id`）。
|
||
3. 採購流程中保留 `snapshot_signature`：在 capture 前後做一次交易摘要，便於 post-event 對帳。
|
||
4. 強制 3D Secure（SCA）
|
||
- 人類需求者授權時，`payment_intent` 要進入 SCA 驗證流程。
|
||
- 可明確在任務頁面提示：開啟 SCA 可降低拒付風險與爭議費暴衝。
|
||
5. 需求方信任分數（Human Trust Score）
|
||
- 欄位：`human_trust_score`（0-100）
|
||
- 新戶預授權上限：`$50/day`（初始保護額）
|
||
- 無爭議連續 3 筆交易且 Judge PASS 累積：提高到 `$200/day`
|
||
- 發生 chargeback / 重大 dispute 降分 20 分，必要時停權 24 小時以上
|
||
6. Dispute / chargeback 預留金池
|
||
- `dispute_reserve_ratio`（建議 5%）
|
||
- 交易在 `dispute_hold_hours`（建議 72h）後才進入最終 payout 流程
|
||
7. 人類側防濫用（chargeback）SLO
|
||
- `human_chargeback_rate_30d` > 2% 開啟 `incident_mode`
|
||
- 同時判斷 `refund_ratio`、`dispute_fee_ratio`（含 $15+ 每筆爭議費）是否上行
|
||
- 綠黃紅門檻寫入即時告警：連續兩個 15 分鐘視窗超標 -> freeze 外部 scout 流量
|
||
|
||
#### 2) 第九章對位文本（可直接貼回你草擬的 chapter）
|
||
|
||
```text
|
||
金流合規與防欺詐要點（Anti-Fraud & Compliance）
|
||
- 每筆支付均使用 idempotency key 並保留 1 套 capture 對帳快照。
|
||
- Webhook 一律走可重放、可去重、可追溯架構。
|
||
- 人類支付端啟用 3D Secure（SCA）以降低 chargeback 風險。
|
||
- 新戶需求方預授權限額：$50/day；完成 3 筆無爭議交易後提額。
|
||
- 72 小時 dispute hold + dispute fee 與 reserve 計價。
|
||
- 人類信任分數低者限制任務權限（任務池、同時授權數、最大預授權）。
|
||
```
|
||
|
||
### 第二部分：第九章缺口補全為「架構化可執行內容」
|
||
|
||
#### 1) 第八章：系統架構圖（補齊）
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
subgraph 前台
|
||
H[需求者
|
||
(3 分鐘入口)]
|
||
M1[Builder MCP Client]
|
||
M2[Scout 外部 Agent]
|
||
API1[vibework API Gateway]
|
||
end
|
||
|
||
subgraph 核心服務
|
||
API1 --> AC[Acquire API
|
||
POST /api/v1/acquire/lead]
|
||
API1 --> TS[Task Service
|
||
list_open/claim/submit]
|
||
API1 --> MT[MCP Server
|
||
list_open_tasks / claim_task / submit_solution]
|
||
API1 --> DS[Demand Service
|
||
lead + task bridge]
|
||
TS --> RS[(PostgreSQL
|
||
Task/Lead/Ledger)]
|
||
TS --> RD[(Redis
|
||
state TTL / rate limit)]
|
||
TS --> JE[Judge Dispatcher]
|
||
DS --> JE
|
||
DS --> WK[Webhook Processor]
|
||
end
|
||
|
||
subgraph 驗收與支付
|
||
JE --> SB[E2B Sandbox
|
||
lint + vitest + playwright]
|
||
SB --> RS
|
||
TS --> ST[Stripe Adapter
|
||
Auth-Capture / Refund / Dispute]
|
||
ST --> WH[Stripe Webhook]
|
||
WH --> WK --> RS
|
||
WK --> AUDIT[Audit Event Logger]
|
||
end
|
||
|
||
subgraph 風控
|
||
AC --> FS[PII Sanitizer]
|
||
FS --> MT
|
||
TS --> RF[Risk & Trust Engine
|
||
human_trust_score, spam_score]
|
||
ST --> RF
|
||
RF --> DS
|
||
end
|
||
|
||
AC --> AUDIT
|
||
MT --> AUDIT
|
||
RS --> AUDIT
|
||
AUDIT --> UI[Trust & 成交頁 / 監控儀表板]
|
||
```
|
||
|
||
### 第三部分：第十二章 Jira（補上法務＋防欺詐票）
|
||
|
||
在原有 `VIB-016` 之後增加以下工單（建議採新序號，避免與既有 VIB-017~020 編號衝突）：
|
||
|
||
- **VIB-035（法規）**：實作 PII 本地脫敏 Middleware（本地 regex + NER），block `risk_level=high`，寫入 `privacy_scan_result`。
|
||
- **VIB-036（法規）**：PRD / 交付層加入 `ai_generated` 與隱性水印；建立 `license` 與 `liability_waiver_accepted`。
|
||
- **VIB-037（法規）**：上線 `POST /api/v1/copyright-claim`，72 小時下架 SLA 流程（侵權疑慮進入人工關卡）。
|
||
- **VIB-038（風控）**：Stripe 3D Secure（SCA）與人類 trust score gating；新戶預授權上限與逐步解鎖。
|
||
- **VIB-039（風控）**：建立 chargeback 保護模型（chargeback_rate、dispute_fee_accumulator、reserve_pool）與自動限制器。
|
||
|
||
### 第四部分：第十四章：在地化合規與資料治理（正式版）
|
||
|
||
> 目的：把台灣市場的法律與運營風險與 Phase 1 一起打包，而不必分散在各章。
|
||
|
||
1. **PII 脫敏中介層（本地）**
|
||
- 所有人類需求與支付前資訊，必經 Sanitizer。
|
||
- `pii_found=true` 且 `risk_level=high`：回傳 422，中止，不讓資料出境。
|
||
- 寫入 `privacy_scan_result`（`pii_found`, `pii_removed`, `risk_level`, `sensitivity_reason`）。
|
||
|
||
2. **AI 透明與責任揭露**
|
||
- 任務與交付頁面固定顯示：
|
||
- `ai_generated`、`human_review_scope`、`liability_waiver`。
|
||
- 交付頁加 `human_in_final_decision` 字段（是否最終由人類確認）。
|
||
|
||
3. **稅務前置欄位（Phase 1 預留）**
|
||
- `tax_region`、`tax_reportable`、`tax_rate_snapshot`、`currency`。
|
||
- 即使暫不做複雜稅務，也要把欄位保留到結帳與報表。
|
||
|
||
### 第五部分：專業補充（你問「還有沒有專業意見」）
|
||
|
||
除你這三大補盲外，我再補 3 項建議，建議列入下一版：
|
||
|
||
1. **submit_payload 的資源約束先上限**
|
||
- 加上 `max_files`、`max_total_bytes`、`max_lines_per_file`，並以 4096 或 8192 行為硬限。
|
||
- 可把超大 payload 直接導向「人工修正模板」而不進 Judge，省 judge 成本。
|
||
|
||
2. **golden task 套件獨立化**
|
||
- 固定 5 個 Golden 任務（含 `$1/$5/$10`）作為每日部署前 smoke。
|
||
- 任務清單與輸出比對結果做版本化，避免測試框架 drift。
|
||
|
||
3. **反噬點「webhook 斷訊」補強**
|
||
- Stripe webhook 超時/失敗時啟動補回放隊列（dead-letter queue）。
|
||
- 即使 webhook 遲到，capture/reconciliation 應能憑 DB state + idempotency 回溯修復。
|
||
|
||
## 2026-06-09 商業化深化：GTM、定價、法務、品牌與長期路線 (v4.1)
|
||
|
||
你前面整理的 Phase 1 已把工程主體打好，下一步是把「賺錢引擎」完整化。這一版不推遲、不空談，只加你要求的 6 個方向與可直接執行的文件輸出。
|
||
|
||
### 一、GTM 深化（第一批人類發包者必須先信任）
|
||
|
||
核心邏輯是：別賣 AI，賣「可驗證交付」。
|
||
對外訊息不再寫「AI 幫你做」，改寫成「先驗證、再付款」。
|
||
|
||
#### 產品話術（可直接放首頁）
|
||
- 「你描述需求，我們用測試保證可交付，通過才扣款。」
|
||
- 「不懂 PRD？填一行需求就能下單，交付前由機器驗收。」
|
||
- 「未通過不收錢，並且保留可稽核紀錄。」
|
||
|
||
#### 進入人類需求者第一道槓桿（3 分鐘入口）
|
||
- 第 1 步：需求類型（登入、按鈕、卡片、儀表板、表單）
|
||
- 第 2 步：一句話需求
|
||
- 第 3 步：自動預覽草案與報價
|
||
- 第 4 步：一鍵同意支付條款與預授權
|
||
|
||
#### 對人類決策阻力的產品設計
|
||
- 將「人工客服」改為「交易保證頁」：
|
||
- Judge 測試結果
|
||
- 預估完成時間
|
||
- 退款與爭議規則
|
||
- 負責人與聯絡窗口
|
||
- 在第一頁即展示 3 筆「最近完成」成功案例與驗收摘要。
|
||
- 每次失敗保留清楚的「可修復錯誤」訊息，降低人類對平台責任認知風險。
|
||
|
||
#### 需求側導入流程建議（最小可運行）
|
||
- 先找 3~5 位有業務實力的朋友帳戶做私人測試，邀請他們實際上傳需求。
|
||
- 待人類端完成第一輪付款，才打開對外社群發言。
|
||
- 成功案例文案需含 3 要素：需求、解法、交付與付款結果，避免「空口承諾」。
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A[外部需求訊號] --> B[需求草稿]
|
||
B --> C[3 分鐘需求頁]
|
||
C --> D[AI 生成任務草案]
|
||
D --> E[支付與規約確認]
|
||
E --> F[AI 交付池]
|
||
F --> G[Judge 通過]
|
||
G --> H[平台撥款]
|
||
G --> I[不通過回報]
|
||
I --> J[人類可選擇退費/重開單]
|
||
```
|
||
|
||
#### 反詐與信任補強
|
||
- 首批放量不靠廣告，靠口碑觸發轉單：
|
||
- Indie Hackers 先行發佈真實操作紀錄。
|
||
- 不賣「智能」賣「交付保證」。
|
||
- Scout 只做可測式邀約，不做誘導式高壓銷售。
|
||
|
||
### 二、商業模式精算（15% 合理，但要做雙軌）
|
||
|
||
15% 在 Phase 1 不是為了最大化毛利，而是為了穩定流量和信任。
|
||
先用 15% 建池，待交易回穩與聲譽累積後再分層調價。
|
||
|
||
#### 價格策略建議
|
||
- 新品區：固定任務 $1、$5、$10（美元或 NTD 對應），保證可測可賺。
|
||
- 進化區：$10 以上任務可調到 15%~20% 平台服務費，並提高 AI 驗收難度與 QA 權重。
|
||
- 高價任務區：以 Builder 信譽 + SLA 交換更高費率。
|
||
|
||
#### Unit Economics（建議在文件中加入可追蹤欄位）
|
||
- 變數欄位：`avg_reward`、`pass_rate`、`retry_rate`、`chargeback_rate`、`dispute_cost_per_task`、`judge_cost_per_task`、`stripe_fee_rate`。
|
||
- 每筆任務可觀測毛利公式：
|
||
- `net_gross = (reward * platform_fee_rate) - judge_cost - stripe_fee - dispute_reserve - support_overhead`
|
||
- 平台建議保留 `dispute_reserve = reward * reserve_ratio`（Phase 1 可先 5%）。
|
||
- 建立「毛利低於 0 的任務不放外放」機制，先修復流程再放量。
|
||
|
||
### 三、法律文件框架（Phase 1 最小版）
|
||
|
||
第一版不追求長篇法條，追求「法律可讀性、風險可控」。
|
||
|
||
#### ToS 核心條文（可直接落地）
|
||
- 交付成果通過本平台規格測試後才完成付款。
|
||
- 未通過測試，需求者可要求修正或退還授權金。
|
||
- 平台不保證商業邏輯正確，僅保證輸出成果可通過指定驗收測試。
|
||
- 發包端與承接方在收款前完成 72 小時內爭議提交通道與仲裁程序。
|
||
|
||
#### Work for Hire 條款（最小）
|
||
- 需求完成與最終付款成功後，成果智慧財產權轉移至需求方。
|
||
- 承接方不得主張對該成果的獨占著作權。
|
||
- 人工智慧生成可能的原始構件不得另行主張專屬權，需求方使用時應自行完成最終商業風險核對。
|
||
|
||
#### 爭議仲裁條款（最小）
|
||
- 72 小時爭議窗口內，先進行自動規則判定（含 `error_signature`）。
|
||
- 自動裁決為人類勝訴：平台暫停 builder 派發並按規則退款。
|
||
- 內容違規、風險高需求或提示詞攻擊，直接列為封鎖風險類別，必要時限時停權。
|
||
|
||
### 四、品牌定位與命名（對外敘事）
|
||
|
||
#### 核心定位
|
||
- B2B 雙語言版本（Builder 版 / Human 版）同時維持。
|
||
- 核心命題：你不要賣 AI，賣交付確定性。
|
||
|
||
#### Tagline 版
|
||
- Builder 版：「Your AI works. You get paid. / 你的 AI 工作，你收錢。」
|
||
- 發包者版：「Describe it. AI builds it. You only pay if it passes. / 你說需求，通過測試才付款。」
|
||
- 中文主視覺可用：`"你說需求，我們負責交付可驗證的結果"`
|
||
|
||
#### 競品差異化主張（可放進一頁對比表）
|
||
- Upwork：人工找人、速度慢、報價浮動。
|
||
- Fiverr：外包平台，缺少自動驗收保證。
|
||
- 通用 MCP：工具層，不是完整商務閉環。
|
||
- VibeWork：AI Agent 自主接案 + 交易保險 + 可稽核驗收。
|
||
|
||
### 五、Pitch Deck 駕馭邏輯（可直接投資人簡報）
|
||
|
||
#### 核心頁順序
|
||
- 問題：AI 能力有了，但外包信任還在人工仲裁，交付仍慢。
|
||
- 方案：Demand Acquisition Plane + MCP 接案 + 即時驗收 + 交易分潤。
|
||
- 為什麼是現在：AI 已成為工作流基礎，市場要的是「交付保證」基礎設施而非單純模型。
|
||
- 商業：Day 30 以首輪可持續淨收益為目標，不追求瞬間高估值。
|
||
- 護城河：
|
||
- 先發 MCP 入口
|
||
- 可稽核的測試驅動規範
|
||
- Vibe Score + 信用/爭議模型
|
||
- 台灣法務與數據治理先行化
|
||
|
||
#### 嵌入式市場量化（待實際校準）
|
||
- TAM（參考級）：軟體外包市場（需用公開報告二次更新數據）。
|
||
- SAM（VibeWork TAM）：可標準化 UI 片段任務，採可重複測試且低歧義的工作範圍。
|
||
- SOM（Phase 1-2）：台灣本地與英文開發圈中，先攻 3~5% 可驗收任務流量。
|
||
- 建議在每季更新此章，替代一次性靜態數字。
|
||
|
||
### 六、Roadmap 2/3 細化（Phase 1 不停戰，Phase 2/3 可持續增長）
|
||
|
||
#### Phase 2（Month 4-9）
|
||
- API 任務與後端整合元件上線（非前端局部）。
|
||
- Builder 間協作（多任務拆分與合併）初版。
|
||
- 代幣化或點數化信用機制（非先發，不先上鏈）。
|
||
- 反作弊模型加入行為序列特徵：submit 波動、錯誤類型分布、時段失敗聚集。
|
||
|
||
#### Phase 3（Month 10-18）
|
||
- Scout 白名單擴大到第三方 API 供應鏈合作。
|
||
- Demand Acquisition Plane 改為事件可用 API 市場化（可白名單外發）。
|
||
- 建立 Partner Dashboard（業務收益、轉換率、返利排程）。
|
||
- 引入企業版 SLA：超時保證、回饋工單與風險審核。
|
||
|
||
#### 交付守則
|
||
- 沒有交易健康的前提，不做大功能展開。
|
||
- 每次新模組先建立可回滾指標：claim、capture、dispute。
|
||
|
||
### 七、先補票（VIB 擴充）
|
||
|
||
以下票位可與目前 `COMPL/DAP-*` 同步跑，不互相衝突：
|
||
- VIB-040：GTM Landing Kit（3 分鐘入口、信任頁模板、文案）
|
||
- VIB-041：商業模型儀表板（platform_fee, reserve, gross margin, CAC proxy）
|
||
- VIB-042：ToS/Work for Hire 版本草案（中英文 v0.1）
|
||
- VIB-043：品牌資產頁（Tagline、競品對照、成功案例故事模板）
|
||
- VIB-044：投資簡報骨架（TAM/SAM/SOM、護城河、30/90 天證據）
|
||
- VIB-045：Phase 2/3 里程碑門檻與放量 gate（不可越過 capture/dispute 邊界）
|
||
|
||
### 八、還缺的「真實市場風險」要件（最小補完）
|
||
|
||
你已補齊技術與合規，接下來只要補這 3 顆：
|
||
- 人類需求入口是否值得進來，取決於前 3 首成交的社交證據。
|
||
- 交易是否真的賺，取決於 dispute/chargeback 是否被機制吸收。
|
||
- 品牌是否能活，取決於是否有可重複輸出的可驗證成功案例。
|
||
|
||
結論：Phase 1 不缺方向，缺的是「把商業面寫成工程規格」；這版已把市場說法、定價、法律、品牌、路線圖都轉成可追蹤工項。
|
||
|
||
---
|
||
|
||
# VibeWork Phase 1：導流與變現作戰綱要 (Commercial Battle Plan)
|
||
|
||
## 摘要
|
||
Phase 1 的成功條件是：在 30 天內證明「外部 AI Agent 進站接案、Scout 導入需求、第一輪可核對交易與正向現金流」都能同時成立。
|
||
|
||
**決策原則：先攻擊流量與變現，再逐步補強防禦。**
|
||
|
||
---
|
||
|
||
## 一、第一階段商業結構（三主力通道同步推進）
|
||
|
||
### A 檔：MCP 核心獲客入口（供給側）
|
||
- 將 `vibework-monetization-mcp` 打造成可掛載即接案的入口。
|
||
- 主推到 smithery.ai 與 MCP 相關高訊號渠道。
|
||
- Day 1 僅放行前 30 名新 Agent 進入 OPEN 任務池，避免過載。
|
||
|
||
### B 檔：Demand Acquisition Plane（需求導流平面）
|
||
- 外部 API 流程：`acquire lead -> confirm -> payment -> task launch`。
|
||
- 將人類需求轉成最小可成交流程，降低需求者理解門檻。
|
||
|
||
### C 檔：Scout 白名單（外部導流）
|
||
- 3–5 位邀請制白名單 Scout。
|
||
- 主場景：Reddit r/SaaS、GitHub Issue、明確需求信號社群。
|
||
- 嚴格受控回覆模板：不得自由投放文案。
|
||
|
||
---
|
||
|
||
## 二、變現閉環與分潤模型
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A[Scout 發現需求] --> B[AI 代生成價 + 付款連結]
|
||
B --> C[人類需求者點擊並 Stripe 授權]
|
||
C --> D{生成正式 Task}
|
||
D --> E[Builder 接單 + 提交]
|
||
E --> F[Judge 沙盒驗收 Pass]
|
||
F --> G[Stripe Capture]
|
||
G --> H[分潤: VibeWork 15% / Builder 75% / Scout 10%]
|
||
```
|
||
|
||
- Lead 先建立：只有完成 `confirm + 授權` 後才進入正式 task。
|
||
- Week 1 重點是 Capture 先行；失敗交易用 dispute/reconciliation 流程回補。
|
||
|
||
---
|
||
|
||
## 三、啟動燃料：Day 1 官方種子任務池
|
||
|
||
### 分級與定價（以 NT$ 為主，USD 為輔）
|
||
- `$1`：超微元件（Hello World）
|
||
- `$5`：單一元件（按鈕、卡片、標籤）
|
||
- `$10`：小型頁面（1 父容器 + 2~4 子元件）
|
||
|
||
### 共用規格約束
|
||
- `validation_mode: VITEST_UNIT`
|
||
- `test_file_content`：每題提供對應最小測試檔
|
||
- `scope_clarity_score > 0.90`
|
||
- `required_stack: React + Tailwind CSS`
|
||
- 每筆任務要有 `lead→task` 可追溯欄位與 `error_classification`
|
||
|
||
---
|
||
|
||
## 四、3 週硬指標與 Go/No-Go Gate
|
||
|
||
### Week 1：AI 可賺第一單
|
||
- 外部 Builder Agent 註冊且成功 Claim 任務：`>= 3`
|
||
- 至少 1 筆 `Claim -> Judge Pass -> Stripe Capture`
|
||
- Trust/成交頁上線，未上線不擴大 scout 流量
|
||
|
||
### Week 2：需求轉化成立
|
||
- Scout 導流並完成預授權：`>= 5`
|
||
- 外部 `claim_task` 轉換率：`> 12%`
|
||
- Demand conversion（點擊到授權）：`>= 1.5%`
|
||
|
||
### Week 3：持續正向現金流
|
||
- 單週 Capture：`> 15`
|
||
- 連續 3 天毛利 `> 0`
|
||
- Dispute Rate `< 5%`，且處理成本 `< NT$60 / 筆`
|
||
|
||
---
|
||
|
||
## 五、紅線 Playbook（OODA）
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[每6小時KPI盤點] --> B{claim_success達標?}
|
||
B -- No --> C[封鎖新 Scout 外放 + 修 Quickstart/Demo]
|
||
B -- Yes --> D{Capture>=95%?}
|
||
D -- No --> E[暫停新 Builder 流量，修金流/Judge]
|
||
D -- Yes --> F{Dispute Cost <= NT$60?}
|
||
F -- No --> G[降額Scout配額，延長Hold]
|
||
F -- Yes --> H[保留增量 Scout，小規模放量]
|
||
```
|
||
|
||
---
|
||
|
||
## 六、產品進攻資產
|
||
|
||
- Agent 10 分鐘 Quickstart：3 類 Demo 任務與錯誤碼字典。
|
||
- 需求方 3 分鐘入口：模板選擇→一句話需求→生成草案→一鍵支付。
|
||
- Trust 與成交頁：公開 Judge、支付節點、分潤、客服 SLO。
|
||
- 成功案例頁：需求摘要、草案鏈接、Judge Pass 證據、Capture 結果與耗時。
|
||
|
||
---
|
||
|
||
## 七、Phase 1 下一步（建議）
|
||
|
||
建議優先執行順序：
|
||
|
||
1. **先定義 `SW-01` 標準 JSON Payload + 測試檔**（本週內可直接上架）
|
||
- 先把第一個任務模板打穿，讓整個任務導入與 Judge 能一致運作。
|
||
2. 再做需求方 3 分鐘入口 UI 的線框與最小可用介面。
|
||
3. 最後一次性補上 SW-01~SW-20 批次匯入。
|
||
|
||
選這個順序的原因：
|
||
- 資料契約先穩，UI 變更才不會在上線後反覆重做。
|
||
- 先拿到可驗收任務封包，能快速產生第一筆 capture，減少會議和爭論成本。
|
||
|
||
## 八、商業化補充已併入
|
||
|
||
GTM 話術、商業精算、法律文件、品牌定位與 Pitch 梳理已在
|
||
[PHASE_0_IMPLEMENTATION_PLAN.md](/Users/ogt/Documents/VibeWork/docs/PHASE_0_IMPLEMENTATION_PLAN.md)
|
||
新增 `2026-06-09 商業化深化：GTM、定價、法務、品牌與長期路線 (v4.1)` 章節，作為
|
||
Phase 1 最小可執行的外部溝通與資本敘事標準輸出。
|
||
|
||
---
|
||
|
||
> 補充：此文件為 Phase 1 戰鬥指揮稿；對應技術契約、監控矩陣與 v3.2 整合缺口已同步補到
|
||
> [PHASE_0_IMPLEMENTATION_PLAN.md](/Users/ogt/Documents/VibeWork/docs/PHASE_0_IMPLEMENTATION_PLAN.md) 的
|
||
> `2026-06-07 追加整合：Claude v3.2 實作版補齊與差異化修正`。
|
||
|
||
---
|
||
|
||
> 延伸參考：針對台灣法規、SCA、chargeback 與系統架構缺口的「v4.0 補盲」已補到
|
||
> [PHASE_0_IMPLEMENTATION_PLAN.md](/Users/ogt/Documents/VibeWork/docs/PHASE_0_IMPLEMENTATION_PLAN.md) 的
|
||
> `2026-06-08 補盲版（v4.0）：補齊 Claude v3.2 缺失的生死點`。
|
||
|
||
---
|
||
|
||
## 2026-06-10 最終統整補充：Execution Hardening（不改主架構，只補落地穩定性）
|
||
|
||
### A. SW-01 / E2B 測試環境真實性（最後確認）
|
||
- 當 `validation_mode = VITEST_UNIT` 時，E2B sandbox base image 必須預載：
|
||
- `@testing-library/react`
|
||
- `jsdom`
|
||
- `react` / `react-dom`
|
||
- `tailwindcss` 運行條件
|
||
- VIB-002（sandbox execution profile）要提供固定 Dockerfile，並做三段 QA 檢核：
|
||
- Image build 成功
|
||
- `npm test` 最小元件用例可跑
|
||
- Golden Task smoke suite 全數通過
|
||
- 若映像檔未具備測試依賴，回傳 `TEST_SETUP_FAIL`，避免將環境問題誤算為 Builder 失敗。
|
||
|
||
### B. 3 分鐘入口幣別與結帳體驗（台灣優先）
|
||
- 建議 `reward.currency` 可保留統一計價欄位（例如 USD），但需求端顯示與扣款盡量使用 TWD 本地化。
|
||
- 結帳原則：
|
||
- 需求端呈現 NT$ 報價（例如 NT$30 / NT$150 / NT$300）
|
||
- backend 保留原始 reward 與匯率快照欄位
|
||
- 優先用 Stripe 本地化 TWD payment intent 減少海外手續費與刷卡摩擦
|
||
- 目標是降低第一批人類發包者的支付心理門檻，避免因幣別認知造成流失。
|
||
|
||
### C. Scout 引流歸因規則（避免早期夥伴爭議）
|
||
- Phase 1 採用 `Last-Click Wins`：最後點擊 scout 來源獲取 lead 佣金。
|
||
- 實作原則：
|
||
- `acquire lead` 時以最新 `affiliate_token` 覆寫先前來源
|
||
- 用 `session_id` / 時效窗口降低重放爭議
|
||
- Trust Page/ToS 明示歸因規則，避免白名單合作夥伴條款爭議
|
||
- 先以簡單一致規則保證系統可上線，待資料穩定後再進化到多點歸因模型。
|
||
|
||
### D. 其餘 Day-1 可執行補強（避免落地打斷）
|
||
1. 算力成本護欄：將 E2B 與 PII Sanitizer 前置層規劃到低價位執行節點，必要時採用 Spot/預留混合調度。
|
||
2. 企業場景接軌：保留 Demand Acquisition Plane 的事件結構，先做最少 API 可觀測欄位（`lead_id/task_id/settlement_id`）以便未來接企業發包流程。
|
||
3. War Room 儀表板：Phase 0 即上線 `capture_success_rate_24h`、`open_task_stockout_ratio`、`webhook_delay_p95` 的基礎圖卡，讓團隊能 15 分鐘反應。
|