wooo/agent-bounty-protocol

Fork 0

Files

OG T 9e79e58f87 chore: initial commit with Phase 0 setup

2026-06-06 22:56:21 +08:00

139 KiB

Raw Permalink Blame History

VibeWork Master Implementation Plan — 最終整合版（單一文件 v4.2）

作者：Codex / 需求：可執行、可觀測、可變現版本：v4.2

更新日誌：v4.2（最後統整）
一頁商業導向執行綱要（Phase 1）
- 核心目標（21 天）
- 1. 啟動燃料：官方種子任務池（The Seed Supply）
- 1. 流量入口：Agent 白名單入埠（The Traffic Gates）
  - Builder Agent（接案方）
  - Scout Agent（導流方）
- 1. 變現閉環：從引流到抽成（The Revenue Loop）
- 1. 3 週硬指標（Go/No-Go Gate）
  - Week 1（先證明「AI 可賺到第一單」）
  - Week 2（先證明「人類願意買單」）
  - Week 3（先證明「能持續正向現金流」）
- 決勝原則（Phase 1 最後裁決）
- Phase 1 專屬作戰文件
Week 1 先發 20 筆官方種子任務（Day 1 可上架清單）
- 1. 任務上架原則（v1）
- 1. 20 筆 Day 1 任務題目（可直接建檔）
- 1. 測試範例（共用）
- 1. 20 筆 Day 1 發布作業清單
- 1. 風險條件
Phase 0 目標
優先順序
第一個技術驗證：Audit Logger
PRD 版本與來源錨點基礎
技能證據與時效基礎
獨立部署要求
補充章節：MCP 任務閉環工程討論（可直接拆成 Jira Tickets）
- 1. 判斷結果：accept_criteria 為「關鍵風險」
- 1.1 問題定義
- 1.2 修正方針（Judge Agent）
- 1.3 可驗收的 Judge Contract
- 1.4 具體實作票（Jira）
- 1. 判斷結果：claim_task 超時機制若用 Cron 會失效
- 2.1 修正方針（Redis TTL + Pub/Sub + 補償機制）
- 2.2 風險控制（務必加上）
- 2.3 狀態回滾順序（示例）
- 2.4 具體實作票（Jira）
- 1. 判斷結果：供給側冷啟動會直接決定 MCP 成敗
- 3.1 供給側修正方案
- 3.2 供給側品質規範（防止「空城計」）
- 3.3 具體實作票（Jira）
- 1. 任務狀態機（正式版本，避免多人協作亂轉）
- 4.1 每一個轉換的責任與副作用
- 4.2 交易一致性要求（不做的話會失敗）
- 1. 進場即用：可直接執行的驗收清單（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. 第一階段變現能否成立？最終專業結論
- 1. 失敗門檻轉為可操作的紅黃綠（Day 1-30）
- 1. 紅燈 Kill Switch 決策（實作在運維層）
- 1. 與外部參考規範對齊的專業補強（已校準）
- 1. 先天風險與我建議的對策（不是可選）
- 1. 新增圖：紅黃綠閉環決策
- 1. 下一步：要不要直接把紅黃綠矩陣與 Kill Switch 變成「第一階段上線 SOP」
- 簡結
架構圖與流程圖（Mermaid）
- 1. 任務狀態機總覽
- 1. Judge Agent 端到端驗收流程
- 1. Redis TTL 超時與 DB 補償防護
- 1. 供給側冷啟動導流閉環
- 1. 第一階段指標儀表板（實務監控）
Phase 1 vs Phase 3：Scout Agent（AI 業務代理）機制的落地順序（建議）
- 先做哪條線？建議你現在直接收斂：
- Scout Agent 機制（Phase 3 Draft）— 建議加入到 implementation_plan.md
  - 1. 目標邏輯
  - 1. 核心流程（Scout API）
  - 1. Scout 風險與治理（先放到 Phase 3）
  - 1. Phase 1 必要的先行 KPI（收斂至此）
- 1. 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. 先澄清目標：第一階段的商業最小成功定義
- 1. 第一階段（Day 1-30）商業門檻（可直接當 Go/No-Go Gate）
  - 供給方流量（AI Agent）
  - 需求方流量（人類付費需求）
  - 收益與風險
- 1. 商模設計：雙方都能持續參與的最小閉環
  - 對 Builder AI 的價值
  - 對 Scout AI 的價值
  - 對需求方的價值
- 1. Demand Side GTM：只靠 MCP 不夠，還要三條導流管道
  - A) 產品內導流（最先級）
  - B) 外部 MCP 入口（第二優先）
  - C) Scout 擴散（第三優先）
- 1. 不是只有技術：對賬與收費的商業保險絲（Recommerce Safety）
- 1. 第一階段可執行商業路線圖（14 / 30 天）
  - Day 1-14
  - Day 15-30
- 1. 我建議新增的「商模與獲利」補充章節（下一次可直接塞到文件）
- 1. 風險與提醒（這一段是我比較強勢的商模意見）
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. 法律與合規（最高優先）
  - 1. 資料洩漏與隱私（最高優先）
  - 1. 爭議與客服成本（最高優先）
- 二、補上你們討論中 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. 三主力通道（同步推進）
  - 1. 價值主張
  - 1. 收益與風險平衡（第一版）
- 三、系統流程設計（DAP + Marketplace 分離）
  - 1. 狀態模型（v1）
  - 1. 核心原則
  - 1. 風險分層
  - 1. Mermaid：總體流程
- 四、Growth + GMV 執行策略（第一階段專用）
  - 1. 進攻型產品資產
  - 1. Scout 白名單計畫
  - 1. 佔位內容策略（防空池）
  - 1. Mermaid：三條漏斗關係
- 五、KPI、Gate 與日常運營（第一優先）
  - 1. Day 1–14 最小生存門檻
  - 1. Day 15–30 成長門檻
  - 1. Gate / Failback（硬規則）
  - 1. Mermaid：紅線 Playbook
- 六、測試與驗收場景（v1，不立即上線）
- 七、落地文件結構（直接插入 MD）
- 八、假設與預設值
- 九、決策鎖（Phase 1 已定）
2026-06-07 追加整合：Claude v3.2 實作版補齊與差異化修正
- 一、直接採納（直接接上現有文件）
- 二、與現行文檔衝突項（建議統一）
  - 1. 種子池獎金池不一致
  - 1. Schema 格式字眼
  - 1. 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）
  - 1. 第九章對位文本（可直接貼回你草擬的 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）

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
下一步既定順序：先確立 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 發布作業清單

上午：由產品/PM 先以固定 acceptance_criteria 模板批量建檔 20 筆
中午前：把 20 筆推送到「官方種子池」OPEN（僅白名單可見）
下午前：每 5 筆抽一筆人工跑一次 submit→judge→capture dry-run
下午：補齊失敗任務的測試文件與錯誤指引後再啟用對外曝光
晚上：輸出 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 可以在清楚的資料模型、權限邊界、稽核紀錄與部署邊界上實作。

優先順序

建立 Next.js、TypeScript、Tailwind CSS 專案骨架。
建立 PostgreSQL 與 ORM migration。
建立身份驗證與 RBAC 基礎。
建立 AuditEvent 寫入機制。
建立區塊式 PRD、版本、來源錨點與變更請求 schema。
建立技能與工具標籤的證據時效 schema。
建立 PRD 與 ChangeRequest API 契約。
建立 demo 種子資料。
建立 Docker 與 K3s 相容的部署骨架。

第一個技術驗證：Audit Logger

VibeWork 是高度依賴 AI 的 marketplace，因此 AuditEvent 應在 Auth、User CRUD 與 PRD 流程之前先完成。未來所有重要問題都會依賴它追蹤：

AI 為什麼產生這條 PRD。
AI 為什麼推薦這位 Vibe Coder。
誰在什麼時間修改了專案狀態。
frozen PRD 是否被正確保護。
ChangeRequest 如何被評估與接受。

建議 schema：

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

觸發條件：任務進入 VERIFYING。
沙盒執行環境：固定 Node 版本、工作目錄、依賴安裝策略、最小網路權限。
測試順序：lint -> unit -> e2e，每個階段可設定 fail-fast。
成功判定：exit code = 0 且所有測試符合規格。
失敗分類：
- test_failed（邏輯/行為不符）
- timeout（超過 5 分鐘）
- resource_exhausted（CPU/Memory 限制）
- environment_error（沙盒或工具層失敗）
輸出 schema（不可省略）：
- overall_result（pass/fail）
- tests[]（name, status, duration_ms, logs）
- artifacts（screenshot, logs, coverage summary）
- error_signature
行為規則：test_failed 可附帶 retryable/non_retryable 標記，供後端決策重試、回退、或進入人工仲裁。

1.4 具體實作票（Jira）

VIB-001 建立 Judge Agent 服務 API 與結果 schema。
VIB-002 建立 sandbox execution profile（Node 版本、resource limit、網路策略）。
VIB-003 建立驗收測試 runner template（lint/unit/e2e）。
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 狀態回滾順序（示例）

收到 Redis key 過期事件。
取得 task_id 對應 DB 行。
原子交易更新：EXECUTING -> OPEN 且寫入 error_reason=claim_timeout。
釋放 Stripe auth-hold。
發出 task_state_reverted 事件並寫 audit log。

2.4 具體實作票（Jira）

VIB-005 建立 Redis TTL key 命名、TTL 時間、超時副作用對照表。
VIB-006 建立 task:state_reaper worker 監聽 expired 事件。
VIB-007 建立 DB 重掃補償任務（每 1 分鐘檢查 TTL 與 DB 狀態）。
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 供給側品質規範（防止「空城計」）

任務描述欄位完整度必檢：title、success criteria、測試條件、預期輸出、限制條件。
付款策略上限可控：可視難度分層（例如 $0.1~$5）並設置預算上限。
違規與無效任務速率管控：低質任務需自動下架並提供修正提示。
合作方來源任務附上來源授權與敏感資料審核結果。

3.3 具體實作票（Jira）

VIB-009 建立官方種子任務生成與上架 pipeline。
VIB-010 建立 issue scraper 與 PRD 轉換流程（含授權檢查與人工審核）。
VIB-011 建立合作方任務上架流程與質量欄位驗證。

4) 任務狀態機（正式版本，避免多人協作亂轉）

建議統一任務生命週期定義，前後端、MCP、Judge Agent 必遵守同一張規則表。

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 每一個轉換的責任與副作用

OPEN -> EXECUTING：MCP/後端，進行 agent 資格與 auth-hold。
EXECUTING -> OPEN：timeout worker，回退狀態、解除預授權、寫錯誤日誌。
EXECUTING -> VERIFYING：後端，打包提交結果、觸發 Judge 任務。
VERIFYING -> COMPLETED：Judge Agent，回傳 pass + 後端 capture 金流、發出 webhook。
VERIFYING -> FAILED：Judge Agent 或後端 watchdog，依失敗型別決定可重試策略。
FAILED/OPEN/COMPLETED 互轉前必進行事件記錄與 idempotency 保護。

4.2 交易一致性要求（不做的話會失敗）

Stripe capture 必要使用 idempotency key。
state transition 必須搭配 audit log 與事件總線，不得僅靠 cache 結果。
所有回退與 capture 都是可重入操作並保證單次副作用執行。

5) 進場即用：可直接執行的驗收清單（Phase 0~Phase 1）

實作 Judge Agent contract 並可回傳 pass/fail + 測試 log。
使用 Redis TTL 作為主要 timeout 觸發機制並加 DB 補償。
在 API 層實作 task state machine 轉換 guard 與錯誤碼。
先行上線官方 100 筆種子任務並驗證 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（上線驗證）

MCP 列表可見性：vibework-monetization-mcp 在主要目標入口成功回應率 ≥ 99%。
任務可用性：OPEN 任務非空比率 100%，且平均查詢回傳時間 < 300ms。
首位 Agent 體驗：至少 3 位外部測試 Agent 在 24 小時內完成一次 claim_task。

Day 4-7（完成第一輪交易）

端到端交易數：至少 5 筆 claim_task -> submit_solution。
Judge 通關率：VERIFYING 到 COMPLETED 成功率 ≥ 60%。
超時與回退可控：OPEN 回退率 ≤ 30%，且每筆皆有 error_signature。

Day 8-14（開始穩定化）

每日活躍任務流量：list_open_tasks 調用日均 > 50。
付費完成值：每日最少 1 筆成功 capture（或對應等值 token/credits 完成）
供給端補位：官方種子任務池 30 天內補空率 = 0（不出現 10 分鐘以上「OPEN 全為 0」）。

Day 15-30（可決定繼續擴張）

總完成任務數：日均完成任務 > 3。
兌付穩定性：capture 成功率 ≥ 98%，refund + retry 率可被追蹤並低於 5%。
初步經濟指標：每日毛利（淨平台手續費）連續 3 天為正，且下降率受控。
客訴可控：DISPUTED 比率 < 5%，平均仲裁時長可量測。

立即可實作但不需改程式碼的文件補件

為了讓第一階段 KPI 可成立，建議在 implementation_plan 內新增以下非功能項目（文件化即刻可做）：

Day 1 入口文件：5 分鐘上手（install MCP、list、claim、submit、check）。
Day 2 成功案例：固定一個「可複製/可重複」的 1 美元按鈕任務示範。

2026-06-06 更新：v3.1 專業修正（持續討論版）

A) 對「這些做法能否達成第一階段目標」的最終工程判斷

在目前這版裡，導流與變現都已具備「可驗證可放量」的前提，但要嚴格區分兩種成功：

可交易（technical readiness）

需先成立：MCP 可調用、任務不為空、Judge 有明確 pass/fail、金流可捕獲與回滾。
這是「能做」：目前方案已經把這三條補齊。

可盈利（economic readiness）

需再成立：有效 capture 連續發生、refund+dispute 受控、SLO 有閉環、外部需求有穩定輸入。
這是「能賺」：目前仍需第 2 段 GTM 觀測與仲裁機制穩住后才算成立。

因此答案是：
這套方案能讓第一階段很快從 0 到 1，但要長時間「穩定變現」，必須先通過 Day 14 Gate、再逐步放大。

B) 「先做 A1 還是 A2」的建議（核心工程決策）

這是我建議給團隊的明確順序：

A1（Reconciliation Ledger）優先啟動

理由：任何金流動作如果沒有對帳邏輯，A2 的任何通過結果都可能掩蓋財務誤帳。
若先做 A2 再補 A1，後續會出現 capture 漏帳、退款無對齊、狀態飄移的高成本回溯。

A2（Judge E2B）以「小型驗證路徑」並行預熱

在 A1 的交易邊界骨架完成前，先做一個最小可回收（dry-run）版的 Judge 健康檢查。
目的是給團隊「可視化士氣」與時間估算，而不把所有測試結果當成正式可賺交易依據。

Day 1-2 風險控制順序

每次 claim_task 都必須同時觸發：
- 狀態鎖定（FOR UPDATE）
- auth-hold
- reconciliation ledger 的預記錄（待 capture）
這樣當 judge 出錯時，仍可精準追責與回滾。

C) 第二輪核心架構討論：交易路徑、外部擴散路徑、失敗邊界

交易交易路徑（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"]

任務狀態機（含失敗治理）

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 幫需求者拓散」的方向，這是正確增長邏輯，但建議先做能力上限測試再放大：

Phase 1 重點先抓：

金流對帳零漂移、Judge 通過率、退款/仲裁可控、供給池持續有任務。

只有在 Day 14 Gate 通過後，才啟動少量 Scout beta。
Day 30 前只上限 3~5 家白名單 Scout；把 conversion_health、spam_score、chargeback-to-task 指標作為硬闖關。
若沒有先修完退款與仲裁鏈路，先快樂做大量 scout 只會快速放大客服與爭議成本。

E) v3.1 追加的可直接拆票清單（Phase 1 穩化）

VIB-012：補上「交易前提條件」頁（可在 PRD 附件）：
- 任務可用性、MCP 文件版本、Judge fail code 對照、錯誤回報流程。
VIB-013：建立 golden task suite（3–5 個固定樣本）
- 每次部署前自動跑，作為第一道線上品質閘道。
VIB-014：建立 capture-ledger drift 每 15 分鐘巡檢
- 欄位包含 task_id、amount、ledger_status、stripe_status、state_age。
VIB-015：設計 external signal feed 實作模板
- 每週三固定更新 MCP/Stripe/Redis/E2B 官方異動與回應計畫。
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 決策（實作在運維層）

capture_success_rate_24h < 85% 持續 2 個檢核視窗（60 分鐘）則啟動 incident_mode，停用 MCP claim_task。
refund_dispute_rate_7d > 6% 且 judge_pass_rate_24h < 68% 同時成立時，僅保留白名單 Scout/Builder，暫停外部自助通道。
open_task_stockout_ratio > 15% 持續 30 分鐘以上，啟用 open_task_fallback（官方種子任務補位）與每日補單。
state_revert_lag_p99 > 90s（Redis+DB 回退延遲）超過兩個鐘點檢查，立即切斷 Redis 事件接入，改用 DB reaper 補償。
stripe_webhook_delay_p95 > 120m 持續 2 小時，暫停新任務 capture，僅保留人工仲裁通道，避免重複結算風險。

4) 與外部參考規範對齊的專業補強（已校準）

MCP 安全邊界：Authorization: Bearer <token> 必須出現在每次 MCP HTTP 請求，且每個 token 需驗證 aud。這是目前 MCP 規格文件明確要求。
Redis Keyspace：過期事件為非嚴格實時，官方文件明確指出 expired 事件可能延遲，所以「keyevent 觸發」只能作為第一道訊號，必須搭配補償 Job 兜底。
Stripe 重試：官方機制會在 3 天內重試 Webhook，且手動重送不會取消後續自動重試；故 webhook 任務必具備冪等鍵與重放去重。
Stripe Idempotency：同一 idempotency key 會回放首次回應（含失敗結果），所以 capture/refund 流程一定要設計「任務 ID + amount + phase」的穩定 key，杜絕重複出帳或重複退款。

5) 先天風險與我建議的對策（不是可選）

首輪 Scout 不做大流量，先 3~5 家白名單，並以 conversion_health 作為硬性過濾閾值。
所有 FAILED_RETRYABLE 的錯誤 signature 要記錄 judge_stack_trace_hash，並作為 Builder 與 Scout 的質量分數模型輸入。
TaskState 的每次變更都要同時寫入 ledger 與 audit，否則把該事件列為 non-compliant，無法進入下一輪 release。
list_open_tasks 率低於 99% 時，先修 MCP 可用性再談 KPI，不要先調整 KPI。

6) 新增圖：紅黃綠閉環決策

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. 任務狀態機總覽

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 端到端驗收流程

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 補償防護

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. 供給側冷啟動導流閉環

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. 第一階段指標儀表板（實務監控）

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 會把問題放大到無法控制的程度。

因此建議採「分層放行」策略：

Phase 1：先把 GTM 流量 + 核心交易閉環 + KPI 做穩（只接收人類主動上傳與官方 Seed）。
Phase 2：開放 Scout API 的最小可行版本（MVP 代理），但只允許白名單/邀請名單 Agent。
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）

POST /api/v1/scout/draft_task：Scout 依據外部需求輸入草擬 PRD、建立草案與追蹤碼。
平台回傳 payment_link（含 affiliate_id、task_seed、ttl）。
Scout 於外部通道回覆推廣，但只能使用受控模板。
人類付款並完成 auth-hold 後，任務進入正式 OPEN。
Builder Agent 接單後走完整個 claim -> submit -> judge -> capture 流程。
付款結算時按 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）

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 當作宣傳器。

我建議的實作策略（四步走）

先定義需求信號，不先定義推廣渠道
以「需求片語」取代「平台宣傳」：先學會抓到 需求文本 -> PRD 草稿 -> 付款鏈接 的穩定轉換。
可行的輸入源先是：Reddit/GitHub Issues/Discord 討論中的明確開發委託訊號，不是所有貼文。
把 Scout 當成受控 API 工具，而非自由發言人
每個 Scout 只能透過你提供的 approved template + 最小欄位 回應。
例如：必填欄位包含 需求摘要 / 交付範圍 / 風險免責 / 點擊連結，避免無差別 spam。
先做「意向分數」再做「佣金」
不是每次建立 draft 都給獎金，而是採 lead_intent_score。
只有當人類完成付款到 capture 後，且在爭議期過後，Scout 才結算。
把收益分潤和風險分配綁在同一張計算表
低質量 Scout 不只少分潤，而是扣減其 campaign budget，必要時自動降權或暫停，避免平台風險外溢到品牌。

你這套模式的核心判斷

可行性：高。技術上成立，且可成為 Phase 3 的主成長引擎。
風險：高。若不加控制，先天會造成 spam、詐騙、品牌風險與支付退款風暴。
優先順序：第一階段不做全量 Scout 開放，先做 Phase 1交易穩定 與 Phase 2白名單試行。

我建議你現在採納的決策（最務實版本）

現階段：把 GTM/導流 目標只聚焦在 官方 seed + 社群口碑 + 直接邀請。
同步在文件中建立 Scout MVP，但上線條件設為：
- capture 稳定率 95%+
- judge_pass 穩定到 60%+ 且持續 14 日
- DISPUTED 低於 5%
等這三條穩住後，先啟動 3~5 家白名單 Scout（內部夥伴、測試夥伴）。
只在白名單中測完 conversion_health、spam_rate、refund_rate，再改為開放邀請制。
最後才進入公開募兵式擴散，並把風險參數（訊息上限、回報率門檻、退潮機制）打在平台配置檔供隨時調整。

建議寫進 API 參數（Phase 3）作為你下一輪設計原型

POST /api/v1/scout/draft_task
POST /api/v1/scout/score_update（回報點擊、付款、退單）
GET /api/v1/scout/attribution/:task_id（可追溯 attribution chain）
GET /api/v1/scout/reputation（可降權/暫停/封鎖）
POST /api/v1/scout/settle（capture 後的延遲分潤入帳）

為什麼我建議「先穩住交易，再做病毒式成長」？

交易可穩定，才能承受外部流量；
外部流量來了，代表需求變多，judge 會暴露你最脆弱的工程瓶頸；
瓶頸修過，再放大供給才會像複利，不是放大失敗。

這是我對你想法的專業結論：
方向正確，落地順序要保守一點，但不能保守太久。Phase 1 先把品質鏈變硬，Phase 2/3 再把增長鏈打開。

專案追加章節：Judge Agent 的 E2B 隔離、安全與快取策略（Phase 1b 先行）

先把這段先落實到可實作規格是關鍵。否則後續 Scout 擴張會放大風險。

A. 網路隔離設計（Network Isolation）

預設 Deny All（預設封鎖所有外部連線）。
僅對必要依賴開啟短暫 allowlist：
- npm registry / package manager：僅限 job boot 階段依賴下載
- 內部 metadata service：僅供提交結果上報
禁止長連線與敏感埠：
- 禁止 bind/listen（避免任務建立反向網路服務）
- 禁止 0.0.0.0 對外暴露端口
時間與資源上限（單次 run）：
- CPU 時間：例如 2 vCPU / max 30 秒（L1）
- Memory：固定上限（例如 1GB）
- 檔案系統：只允許 256MB writable 層
- 磁碟 I/O：限制高速寫入配額，防止惡意大量寫碟
行為限制：
- 禁止 curl/wget/ssh/ssh-keyscan
- 禁止超過 N 行為的 process spawn（例如 > 20）
- 禁止超過 1 次 git 指令，且只允許 clone 指定白名單

B. 快取策略（可降低驗收成本與延遲）

Dependency Cache（必做）
- 快取 key 以 packageManager + lockfile hash + node_version 做分桶
- 失敗時降級為「無快取重跑」，避免阻塞測試
Test Artifact Cache
- 錯誤案例快取 error_signature 與 repro steps
- 相同 task_id + testsuite hash 的失敗可快速回傳（需加 max-age）
Runner Image Cache
- E2B 基底映像預載常用工具（node + git + playwright）
Warm Pool
- 建立最小預熱池（例如 3~5 個 container）
- 在高峰期用 queue depth 自動擴容，低谷時回收，避免啟動風險
成本護欄
- 每任務 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：基礎可見性與第一批任務

建立 vibework-monetization-mcp v1 上線（Owner：Backend）
實作 list_open_tasks 可回傳 OPEN 任務（Owner：Backend）
建立官方種子任務 20 筆（Owner：PM + Admin）
驗收條件：
- 端點回應率 ≥ 99%
- 任務回傳延遲 < 300ms

Day 3-5：交易關鍵路徑打通

實作 claim_task（含 DB 鎖 + Stripe Auth-Hold）（Owner：Backend）
實作 submit_solution 進入 VERIFYING（Owner：Backend）
實作 Judge L1/L2 最小回路（Owner：AI Infra）
驗收條件：
- 至少 3 位外部 Agent 完成 claim
- 每筆任務皆有可讀錯誤回報（fail 時）

Day 6-10：支付與回復流程強化

完成 capture/release 冪等機制（Owner：Backend + Finance）
實作 Redis TTL timeout + worker + DB 補償 job（Owner：Backend）
實作 audit log 每次狀態轉換（Owner：Backend）
驗收條件：
- Open -> Executing -> Verify -> Completed/Failed 全流程可復現
- timeout rollback 正常解除 auth-hold 且不重複執行

Day 11-14：KPI 仪表與修正節拍

上線 KPI dashboard（Owner：Data）
開通支援流程（Owner：SRE + PM）
啟動 replaybook（API 變慢、Judge 失敗、支付失敗）
驗收條件：
- 首週有效交易 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 先上` 最短安全鍊` 橫切

第一先行：A1「對帳與交易真相」的資料模型先落定
- 原因 1：所有金流副作用必須有可追溯「原子真相」；沒有 ledger，任何 capture/refund 回滾都會變難。
- 原因 2：Redis timeout 與 webhook 失敗、重試都是會放大「雙寫漂移」風險的，ledger 先有可鎖定欄位可降險。
- 原因 3：你已確定平台核心目標是「先固化交易」，所以要先把 可對帳 放在前端，不能先放在 demo 效果前。
同時啟動 A2 的最小連線試跑
- 先驗證 E2B sandbox warm start -> 一次性 run -> 回報 schema 可跑通。
- 但不要把 A2 跟 production 實際任務強耦合，否則會因為付款系統尚未穩而掩蓋測試錯誤。
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 風險控管規格（更可執行版本）

若你接受上面順序，以下是可直接寫卡的補充規則：

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
ledger transaction requirement（交易守則）
- 對任務狀態轉換與 ledger 寫入必須同一個 DB transaction；任何失敗都回滾狀態，不可 partial success。
- 任何 webhook 重放都不能改變 ledger 的既有狀態機結果，除非是「可重放對帳修正」類別。
- webhook 處理路徑與 API 重試路徑都要走同一張 stripe_ledger，以便對帳。
drift 偵測與告警
- 每 1 分鐘比對 ledger 與 task 狀態：
  - capture 已成功但 task 仍非 COMPLETED
  - release 已成功但任務仍處於 EXECUTING
  - 同一 task 同時間出現互斥副作用（capture + release + refund）
- 一旦發現 drift，進入 incident_mode=true，暫停 claim_task 新進任務。
人工回補（runbook 入口）
- 提供 ledger reconcile --task-id --range 指令清單：
  - 查重放記錄
  - 重新查 Stripe object 狀態
  - 產生 correction_journal 供審核

這樣做是因為：你不是要「先出成果」，你是要讓第一波外部 Agent 在你系統裡每一次動作都可以被你們會計、法務、客服、SRE 同時信任。

Day 15-30 第二梯次執行順序（穩定化 + 控制擴張）

第一輪交易穩定後，Day 15-30 不追求新酷功能，而是做兩件事：

讓系統在 10 倍壓力下還是可預期，2) 讓需求散播能力「可控」開啟。

Day 15-21（Phase 2）：供給與媒合能力加強

Task discovery 欄位擴充（難度、技能、預估時長）
- Owner：API/Backend
- 验收：list_open_tasks 支援多條件過濾並維持 P95 < 300ms
pgvector 最小語意媒合 PoC
- Owner：AI Infra
- 驗收：單任務可建議 1~3 個候選 Builder，延遲 < 2 秒
Reputation v1 與節流落地
- Owner：Backend
- 驗收：新 Agent 同時 claim 限制 + 連續失敗 3 次 24 小時降權
官方種子池補強（每天補齊，避免 OPEN 空白）
- Owner：PM/Admin
- 驗收：7 日連續 OPEN 非空比例 >= 99%

Day 22-26（Phase 2）：金流與運維收斂

dispute/refund 進一步與 reconciliation ledger 對齊
- Owner：Finance + Backend
- 驗收：refund 事件可回溯到事件 id 與任務/agent 全鏈路
FAILED_RETRYABLE 自動重排與節流
- Owner：AI Infra
- 驗收：類型化錯誤可避免無限重試，平均重試率下降 > 30%
judge budget 成本看板
- Owner：Data
- 驗收：可監控錯誤類型、平均 runtime、容器啟動成本
高併發重試壓測
- Owner：SRE
- 驗收：1k claim + 500 submit 並發下無 deadlock、無狀態漂移

Day 27-30（Phase 3 鎖定門檻與白名單啟動）

Scout 白名單（5 家）內部驗證
- Owner：Growth + API
- 驗收：每家完成至少 3 次 draft -> payment -> capture 閉環
Scout 風控 啟動
- Owner：Security + Backend
- 驗收：轉換率健康度、spam、回報率告警規則生效
商業可見指標 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）

Scout API 白名單從 5 家增至 10~15 家
- Owner：Growth + Security
- 驗收：全部 Scout 流量都走白名單授權與速率門檻
API Usage Quota 動態化（按 conversion_health 調整）
- Owner：Backend
- 驗收：低轉換 Scout 自動降額，無人工介入
Attribution 串接完成（task -> scout -> builder -> payment）
- Owner：Backend + Data
- 驗收：任務可追溯到 3 層 ID 並可重建完整事件鏈
Support / FAQ 從單語意提升為半自動回覆
- Owner：PM + Support
- 驗收：失敗常見錯誤回覆時間 ≤ 5 分鐘

Day 41-50（Phase 3.2）

多來源任務輸入：合作方 API + 手動上架並行
- Owner：API + PM
- 驗收：不同來源任務都可進入同一套狀態機
Reputation 加權模型更新
- Owner：AI Infra + Backend
- 驗收：成功率高的 Agent 推薦權重上浮，異常行為降權
支付對帳 每日快照 + 每小時告警
- Owner：Finance + SRE
- 驗收：每日對帳報表與警示可自動化發送
金流風險測試（refund burst / webhook delay scenario）
- Owner：SRE
- 驗收：可在 15 分鐘內完成 incident_mode 啟停

Day 51-60（Phase 3.3）

Scout 外部品牌內容 A/B 測試（3 條模板）
- Owner：Growth
- 驗收：conversion_health 不低於白名單期中值
多區域監控（核心服務與外部通道）
- Owner：SRE
- 驗收：關鍵告警跨 24h 保持可定位與可回放
財務保底 指標穩定化
- Owner：Finance
- 驗收：platform_take >= 預算底線、post_capture_quality 無明顯回落
商業決策會議節點（是否進入大規模公開）
- Owner：PM + Leadership
- 驗收：形成 go/no-go 決議與更新的 Gate 條件

30-60 Replaybook（SRE + 運營一頁式手冊）

Playbook A：支付異常（capture/refund 偏差）

觸發條件：

capture 成功率 < 95%（1 小時）或 webhook event_id 連續重複異常

處置順序：

啟動 incident_mode（暫停新任務 claim）
鎖定所有 retryable capture API 呼叫
查 reconciliation drift：task 狀態 vs stripe_ledger
對 pending webhook 重放，查 Stripe event id 是否可重試
對有 source=api 的同日異常請求加 idempotency 標記並回填
修正後每 5 分鐘回報一次狀態；問題解除後恢復 claim

Playbook B：Judge 失效（大量 TEST_FAIL / TIMEOUT）

觸發條件：

FAILED_RETRYABLE 比例 > 30%（15 分鐘）或平均 judge 延遲 > 2 倍基線

處置順序：

限制 judge_concurrency，啟動 cooldown queue
將 timeout 任務移入人工排查清單，不允許無限重試
檢查 error_signature 熱點是否為測試環境退化（套件版本、快取污染）
啟用 runner fallback profile（降速 + 重跑資源較高配置）
通知 Builder 提交者：提供具體 error_signature 修正建議

Playbook C：Scout 異常（spamming / conversion 失效）

觸發條件：

conversion_health 連續 2 天下滑 30% 以上
spam_score 過高（外部回報或 blocked ratio 上升）

處置順序：

一鍵切換 scout_scoped_mode=off（暫停新轉介）
將高風險 scout 列入 quarantine
降低所有 scout daily API 配額 50%
啟動邀請審核：逐一人工複核 template 與 payment link
異常恢復後，逐步恢復配額（按比例）

Playbook D：狀態機異常（超時/重複回退）

觸發條件：

某 task 在 10 分鐘內狀態切換超過 5 次
reconciliation drift > 0

處置順序：

鎖定該任務與相關 agent 的 claim 權限
查 audit log 與 ledger 原始事件
手動將任務壓到 FAILED 或 OPEN（依情境）
生成 correction_journal 給合規與財務複核
修復後恢復狀態轉換與排程

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：公開通路啟動

公開 Scout API（邀請制 V2）
- Owner：Growth + Backend
- 驗收：外部邀請入口使用率 > 40%，仍維持 conversion_health 不低於白名單基準
任務模板標準化（Top 20 任務類型）
- Owner：PM + Backend
- 驗收：同類需求在不同來源的 pass/rollback 行為誤差可比較
scout_reputation 全鏈路導入 claim/submit gate
- Owner：Backend
- 驗收：低質量 Scout 不能跨任務反覆刷量
Dispute 服務化流程（仲裁 queue）
- Owner：Platform + Finance
- 驗收：爭議進入 4 小時內有第一次回應

Day 71-80：經濟化與風險化繁簡

Payout 自動化升級（延遲結算 + 批次任務）
- Owner：Finance + Backend
- 驗收：支付批次可回溯、可重跑、可回補
全量告警收斂至「三層健康度」
- Owner：SRE
- 驗收：系統可視化三層卡片（交易穩定 / 驗收穩定 / 流量品質）
多維收斂測試（同時存在：外部流量暴增、judge 波動、webhook 重試）
- Owner：SRE
- 驗收：保留 incident_mode 時間 < 15 分鐘，關鍵告警不丟
反濫用策略收斂（黑名單 + 行為圖模型）
- Owner：Security
- 驗收：spam 任務比率下降且誤封比例可接受

Day 81-90：可交付成長版本判定

形成「公開版商業門檻」決議
- Owner：PM + Leadership
- 驗收：明確 go / no-go 與對應資源需求
版本化成長儀表（Cohort / LTV proxy / CAC proxy）
- Owner：Data
- 驗收：可按 source / scout / 任務難度看長短期留存與收益
形成 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 份「外部訊號更新」：

MCP 生態安全與授權規格更新
付款/扣款平台異常策略更新（Stripe 行為變更）
Judge/沙盒工具鏈性能與漏洞訊息
供應鏈 AI 平台條款變更（MCP Marketplace / MCP registry）

取樣清單（優先順序）

官方規格變更
- MCP 安全最佳實踐（授權、scope、confused deputy）
- Redis keyspace notifications 的事件保證邊界
付款事件規則變更
- Stripe idempotency、webhook 重試語意、event 版本差異
沙盒安全更新
- E2B / container runner 的隔離策略、資源配額、CVEs
競品/同類平台策略
- 新的任務質量風控、Scount 激勵機制、反垃圾機制

議題落地機制

每次外部更新必須走三道：

Signal: 相關組員建立 ticket（Owner、風險、影響範圍）
Impact: 30 分鐘內做可判定影響分析（高 / 中 / 低）
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）

14 日內至少 60 筆有效 claim（外部 Agent 非官方）
日均 open->claim 轉換率（外部）≥ 12%
外部 Agent 的 FAILED_RETRYABLE 比例 < 35%（否則代表驗收門檻過高或測試任務品質問題）

需求方流量（人類付費需求）

每日至少 1 筆新需求者完成 draft_task 或 直上架自建任務
需求方從 查看示例頁 到 點擊預授權 的轉換率 ≥ 1.5%
支付鏈路 24 小時內完成 capture 至少 3 筆（若低於，代表需求導入未形成真實變現）

收益與風險

平台抽成（或差價）日均毛利 ≥ US$12（含 3 天滑動平均）
退款/爭議 造成的潛在成本 <= 平台毛利的 20%
chargeback / dispute 率 < 4%

3) 商模設計：雙方都能持續參與的最小閉環

對 Builder AI 的價值

快速取得可完成任務，穩定獲得獎金，且有重試次數規則避免無限消耗。
待回報：每筆有可預測的 Builder fee（建議 75%）、透明失敗原因（error signature）、可追溯歷史績效。

對 Scout AI 的價值

Scout 不是廣告，而是「可持續導流的成交代理」，獎勵條件可用 capture 成功 + 非爭議 做結算。
建議採 延遲結算（如 72 小時）避免無效交易抽成。

對需求方的價值

3 步完成需求轉換：草稿化需求 → 一鍵確認 → 付款授權 → 回傳成果。
設定可讀性規格卡（預估時間、測試條件、失敗處置、退款規則），降低認知成本。

4) Demand Side GTM：只靠 MCP 不夠，還要三條導流管道

A) 產品內導流（最先級）

5 分鐘 demo + 官方種子任務（保證展示成功案例）
成功任務公開頁：列出任務前/后、測試證據、耗時、獎金分配
「零接觸轉化」設計：未登入可先看任務流、可先試運行樣例、再選擇註冊

B) 外部 MCP 入口（第二優先）

上架與標註 API 能力，提供最小可執行腳本
針對流行 Agent 框架（例如 AutoGPT 類代理工具）放置標準串接 README
每週一次「接案示例日誌」更新，降低開發者接入不確定感

C) Scout 擴散（第三優先）

先做小規模白名單（3~5 家）
要求每筆邀請鏈接都帶追蹤碼
用 轉換率健康值 做配額配發，而非先用總量封頂

5) 不是只有技術：對賬與收費的商業保險絲（Recommerce Safety）

分潤遞延：Scout/Builder 分潤延後結算，保留 dispute 窗口，避免無法追回的無效抽成。
異常任務封鎖成本模型：若某 Builder 錯誤導致多次退款，立即降權或暫停。
需求失真保險：若需求方長時間未回應，任務需進入 待補件，避免無限等待佔用 pool。
價格歸一化：第一階段建議固定 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) 我建議新增的「商模與獲利」補充章節（下一次可直接塞到文件）

VIB-017：建立「需求方轉換儀表板」（曝光、草稿完成率、授權成功率）
VIB-018：建立「每日 P&L」模型（每任務：gross - stripe_fee - payout - refunds - support）
VIB-019：建立「Scout 測試客群」邀請流程（3 家白名單 + 轉換閾值）
VIB-020：建立「需求端快速 onboarding」文件（5 分鐘版本 + 視覺化任務流程）
VIB-021：建立「交易門檻自動化判定器」把 Green/Yellow/Red 直接綁定 上架 / 限量 / freeze

8) 風險與提醒（這一段是我比較強勢的商模意見）

不要先追求大量 Scout 代理，先確定 1~2 支高質量供給渠道能穩定賺錢，否則會放大品質事故。
不要把免費流量當作驗證替代，免費流量只測得技術，不測得 economics。
先把需求端轉換做起來，因為需求不足時，供應越豐富也是浪費成本。
**把「放量」和「利潤」拆開：先放量 30%，再放量 60%，最後才放量 100%，每一階段都要過 Day Gate。

我不是不要技術，而是：先把金流與需求導入變成同一個可度量模型，技術才會變成可賺的槓桿，而不是成本中心。

2026-06-06 更新：v3.4 漏洞稽核（先賺、再放大）＋專家視角補盲

你問得很好：到目前為止，架構面已經很強，但要把「能跑」變成「能穩定賺」，還有幾個常被低估的缺口。
以下不是否定，而是把第一輪失敗成本壓到最低的「硬約束」。

一、這一輪還可能漏掉的 14 類思考（高優先度）

需求端品質保證（Demand Quality Gate）
- 問題：AI 很快把任務接起來，但需求規格是否有效、可驗證、可交付可能不穩。
- 指標：每週「需求失真率」低於 8%（需求方不回覆、標註失真、返工率）。
- 負責：PM + Builder PM。
首位需求者信任設計
- 問題：需求方怕詐騙/不透明，不知道誰在做、多久交付、如果退費多久處理。
- 指標：新需求者首次支付前完成 Demo 視覺頁的停留時長、回退率、客服詢問率。
- 負責：PM + 法務 + 客服。
價格彈性與預期管理
- 問題：固定 3 段價位是好開始，但要避免錯價導致低價惡性競爭或高價無人接單。
- 指標：每價位段的成交率與任務放棄率；價格區間轉換率。
- 負責：商務 + Product。
獲利模型中的稅務與保留金
- 問題：未先規畫稅務留存，早期「毛利」看似正但實際現金不進帳。
- 指標：Payout 週期、稅務預留比例（建議先預估 15~25% 緩衝）、可提領淨額精度。
- 負責：Finance + 法務。
Builder/Scout 反向激勵失衡
- 問題：只看量獎勵容易放大劣質輸出，尤其重試率高時成本會失控。
- 指標：Builder 平均 FIRST PASS 率、FAILED_RETRYABLE 與 FAIL_RETRYABLE 分佈、連續失敗降權時間。
- 負責：Ops + PM。
外部流量來源風險池化
- 問題：外部來源（如某 MCP 客戶端版本更新或某社群渠道）可能突然退潮。
- 指標：任一來源佔比不得超過 45%，來源多樣性 Gini > 0.55（越高表示越集中，風險上升）。
- 負責：Growth + 資訊安全。
客服時效與 SLA
- 問題：第一批外部 Agent / 需求者最在乎「發生問題時，多久有回應」。
- 指標：P1 回覆 < 15 分、P2 < 2 小時、P3 < 24 小時；Dispute 首次回應 < 4 小時。
- 負責：客服 + 運維。
爭議處理資本成本
- 問題：你可能以為爭議只影響聲譽，忽略了它的現金流鎖定。
- 指標：Dispute in-flight 金額、平均釋放/退款時長、待處理金額上限。
- 負責：Finance + 法務。
資料保存與隱私
- 問題：代碼、聊天、截圖、支付回執都可能需長期留存；缺少策略會阻塞合規/仲裁。
- 指標：任務留存天數符合條款；資料刪除 API 的覆核時間；備援恢復演習通過率。
- 負責：法務 + 資安 + 後端。
品牌濫用與反垃圾法務壓力
- 問題：Scout 自動外宣若過度，會被平台限流/封鎖，品牌會背黑鍋。
- 指標：平台封鎖事件率、外發訊息審核通過率、scout spam_score 平均值。
- 負責：法務 + Growth + Scout API Owner。
資源定價與預算上限
- 問題：Judge Sandbox、重試、replay、人工仲裁可能吞掉預算，導致早期虧損。
- 指標：每單測試成本、每成功交易毛利、月 burn 與安全預算佔比。
- 負責：Ops + FinOps。
交易時間窗控
- 問題：只要 judge 或 webhook 偶發抖動，外部流量即時下滑。
- 指標：P95 任務完成總時長、支付 from claim 的延遲分位、超時任務回收時間。
- 負責：SRE + 後端。
反作弊與帳號濫用
- 問題：套用多帳號刷單、重複創任務、低質量流量導量可能扭曲 KPI。
- 指標：異常行為比率、帳號風險分數、同設備多重帳號成功率。
- 負責：資安 + 欺詐防護。
增長訊號未落地 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 延伸）
- 形成可複用的日報：交易成功率、來源風險、客服等待時間、爭議回收率

四、關鍵結論：目前討論有沒有漏掉關鍵？

不再是「有沒有漏掉」，而是「有沒有先放對風險」：

你現在已經沒有把重心放錯，仍然是「先交易再放量」正確。
最容易漏掉的是：需求端、風險資本、客服 SLA、稅務及來源集中度。
建議把 v3.4 視為 Phase 1 的「必上條件」，不是 v3 之後的美化章節。
一旦以上 14 類缺口中任一高風險項目持續紅燈，無論 agent 接了多少，請直接暫停擴量與外部推廣，回到封口修復。

五、補充：Phase 1 失敗邊界一圖（可直接貼進文件）

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 的項目（並非否定）

稅務與國際金流、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.

四、台灣優先市場的補充缺口（這是高價值但容易漏掉）

外籍金流與台灣本地支付認知差異

設計「台幣顯示」「美元/台幣雙幣種」頁面。避免需求者看見金額後無法立即判斷實際付款成本。
先以新手友善路徑提供「台幣試用任務」與「小額快速任務（NT$）」

台灣法規與客服歸責文件語言

條款與同意流程要有完整正規中文（非只機械翻譯），避免因語言歧義引發同意效力問題。
在任務啟動前補 3 秒同意頁（可跳過但需記錄）

個資法與合作資料界線

任務、對帳、聊天紀錄要有保存與刪除策略（保留與刪除皆可追溯）
對敏感需求（醫療/金融）應直接轉人工篩檢，避免自動交付風險外溢

客服渠道本地化

第一期先上線可追溯客服入口（Email + LINE 官方帳號 + 回報單），並在 dispute flow 預留 中文回覆模板

品牌風險管理（平台聲譽）

所有 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 正常放量，而不是用廣告流量掩蓋「制度未到位」的缺口。

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 控制）

如果以下任一條件成立，立刻暫停新流量放入：

有人資安/法務指出 pii_found=high 還被送入雲端模型。
產出未完整記錄 ai_generated/liability waiver（責任聲明）且未通過審核。
Copyright claim 被證明成立且處理超過 72 小時。
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 最佳實作順序（我建議）

Day 1–2：合規護城河先上
- COMPL-002 + COMPL-001 + privacy_scan 寫入 AuditEvent
Day 3–5：可裁決證據
- COMPL-003、error_signature + 自動仲裁前置規則
Day 6–10：金流風險封鎖
- COMPL-004 + dispute_hold + dispute_cost 指標化
Day 11–14：台灣啟動 Gate
- 驗證 1 次 high-risk 擋檔、1 次侵權申訴、1 次自動仲裁、1 次 dispute_hold 釋放

五、我補上兩個你還沒明講但會讓你少踩坑的台灣實戰項目

保全包導出：每筆任務需能 1-click 匯出「合規包」
（輸入原文、脫敏報告、judge 報告、付款事件、裁決紀錄）以便日後申訴與稽核。
客服語意一致：客服回覆模板固定三段式：
1. 事實邊界（做了什麼）
2. 權責邊界（誰該承擔）
3. 修復邊界（多久解決 / 如何申訴）

六、v3.5 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 進攻式判斷標準（唯一目標）

供給端進站：外部 AI Agent 能穩定完成 list_open_tasks -> claim_task（首輪白名單）
需求端進站：Scout 幫忙將外部需求轉為可付款 lead，並進入任務流程
交易端閉環：lead 可轉為 task，完成 judge pass -> capture -> payout_ready
現金流成立：第一批交易可持續、可稽核、可回損回補（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：總體流程

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：三條漏斗關係

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

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，不立即上線）

MCP 新 Agent 首次接案到 capture 成功閉環
需求者 3 分鐘入口完成一次 payment link 轉 task
同一 lead idempotent 重複提交不重複建任務
高風險內容進入人工 queue，禁止進 task pool
Scout token 重播/濫發阻擋，事件可追溯
併發 100 筆 lead 時，lead/task 關聯完整且無 state 汙染
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 版簡化）

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 還缺的兩個「第一週會爆炸」點

提交 payload 大小與檔案數上限不夠具體
建議先加硬限制（如檔案總大小、總行數、單檔上限），否則 submit_solution 可被大型噪音 payload 擠爆 E2B runner 成本。
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）

Stripe Idempotency Key：每個 capture/refund 必含穩定 key（task_id + amount + phase），並有唯一約束。
Webhook 冪等：Stripe 重試 3 天，API 必須有去重鎖與 replay-safe handler（Stripe-Event-Id / event_id）。
採購流程中保留 snapshot_signature：在 capture 前後做一次交易摘要，便於 post-event 對帳。
強制 3D Secure（SCA）
- 人類需求者授權時，payment_intent 要進入 SCA 驗證流程。
- 可明確在任務頁面提示：開啟 SCA 可降低拒付風險與爭議費暴衝。
需求方信任分數（Human Trust Score）
- 欄位：human_trust_score（0-100）
- 新戶預授權上限：$50/day（初始保護額）
- 無爭議連續 3 筆交易且 Judge PASS 累積：提高到 $200/day
- 發生 chargeback / 重大 dispute 降分 20 分，必要時停權 24 小時以上
Dispute / chargeback 預留金池
- dispute_reserve_ratio（建議 5%）
- 交易在 dispute_hold_hours（建議 72h）後才進入最終 payout 流程
人類側防濫用（chargeback）SLO
- human_chargeback_rate_30d > 2% 開啟 incident_mode
- 同時判斷 refund_ratio、dispute_fee_ratio（含 $15+ 每筆爭議費）是否上行
- 綠黃紅門檻寫入即時告警：連續兩個 15 分鐘視窗超標 -> freeze 外部 scout 流量

2) 第九章對位文本（可直接貼回你草擬的 chapter）

金流合規與防欺詐要點（Anti-Fraud & Compliance）
- 每筆支付均使用 idempotency key 並保留 1 套 capture 對帳快照。
- Webhook 一律走可重放、可去重、可追溯架構。
- 人類支付端啟用 3D Secure（SCA）以降低 chargeback 風險。
- 新戶需求方預授權限額：$50/day；完成 3 筆無爭議交易後提額。
- 72 小時 dispute hold + dispute fee 與 reserve 計價。
- 人類信任分數低者限制任務權限（任務池、同時授權數、最大預授權）。

第二部分：第九章缺口補全為「架構化可執行內容」

1) 第八章：系統架構圖（補齊）

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 一起打包，而不必分散在各章。

PII 脫敏中介層（本地）
- 所有人類需求與支付前資訊，必經 Sanitizer。
- pii_found=true 且 risk_level=high：回傳 422，中止，不讓資料出境。
- 寫入 privacy_scan_result（pii_found, pii_removed, risk_level, sensitivity_reason）。
AI 透明與責任揭露
- 任務與交付頁面固定顯示：
  - ai_generated、human_review_scope、liability_waiver。
- 交付頁加 human_in_final_decision 字段（是否最終由人類確認）。
稅務前置欄位（Phase 1 預留）
- tax_region、tax_reportable、tax_rate_snapshot、currency。
- 即使暫不做複雜稅務，也要把欄位保留到結帳與報表。

第五部分：專業補充（你問「還有沒有專業意見」）

除你這三大補盲外，我再補 3 項建議，建議列入下一版：

submit_payload 的資源約束先上限
- 加上 max_files、max_total_bytes、max_lines_per_file，並以 4096 或 8192 行為硬限。
- 可把超大 payload 直接導向「人工修正模板」而不進 Judge，省 judge 成本。
golden task 套件獨立化
- 固定 5 個 Golden 任務（含 $1/$5/$10）作為每日部署前 smoke。
- 任務清單與輸出比對結果做版本化，避免測試框架 drift。
反噬點「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 要素：需求、解法、交付與付款結果，避免「空口承諾」。

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、明確需求信號社群。
嚴格受控回覆模板：不得自由投放文案。

二、變現閉環與分潤模型

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）

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 下一步（建議）

建議優先執行順序：

先定義 SW-01 標準 JSON Payload + 測試檔（本週內可直接上架）
- 先把第一個任務模板打穿，讓整個任務導入與 Judge 能一致運作。
再做需求方 3 分鐘入口 UI 的線框與最小可用介面。
最後一次性補上 SW-01~SW-20 批次匯入。

選這個順序的原因：

資料契約先穩，UI 變更才不會在上線後反覆重做。
先拿到可驗收任務封包，能快速產生第一筆 capture，減少會議和爭論成本。

八、商業化補充已併入

GTM 話術、商業精算、法律文件、品牌定位與 Pitch 梳理已在 PHASE_0_IMPLEMENTATION_PLAN.md 新增 2026-06-09 商業化深化：GTM、定價、法務、品牌與長期路線 (v4.1) 章節，作為 Phase 1 最小可執行的外部溝通與資本敘事標準輸出。

補充：此文件為 Phase 1 戰鬥指揮稿；對應技術契約、監控矩陣與 v3.2 整合缺口已同步補到 PHASE_0_IMPLEMENTATION_PLAN.md 的 2026-06-07 追加整合：Claude v3.2 實作版補齊與差異化修正。

延伸參考：針對台灣法規、SCA、chargeback 與系統架構缺口的「v4.0 補盲」已補到 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 可執行補強（避免落地打斷）

算力成本護欄：將 E2B 與 PII Sanitizer 前置層規劃到低價位執行節點，必要時採用 Spot/預留混合調度。
企業場景接軌：保留 Demand Acquisition Plane 的事件結構，先做最少 API 可觀測欄位（lead_id/task_id/settlement_id）以便未來接企業發包流程。
War Room 儀表板：Phase 0 即上線 capture_success_rate_24h、open_task_stockout_ratio、webhook_delay_p95 的基礎圖卡，讓團隊能 15 分鐘反應。

139 KiB Raw Permalink Blame History Unescape Escape

VibeWork Master Implementation Plan — 最終整合版（單一文件 v4.2）

目錄

更新日誌：v4.2（最後統整）

VibeWork Phase 1：導流與變現優先版 1-Page Battle Plan (Commercial Battle Plan)

一頁商業導向執行綱要（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) 風險條件

VibeWork AI 代理接案網路：終極商業與技術落地方案 (Master Implementation Plan v3.0)

Phase 0 實作計畫

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. 任務狀態機總覽

139 KiB

Raw Permalink Blame History

1) 判斷結果：`accept_criteria` 為「關鍵風險」

2) 判斷結果：`claim_task` 超時機制若用 Cron 會失效

Scout Agent 機制（Phase 3 Draft）— 建議加入到 `implementation_plan.md`

3) Scout 風險與治理（先放到 `Phase 3`）

最佳順序：`A1 與 A2 並行啟動，但 A1 先上` 最短安全鍊` 橫切

`scout_tasks`

`scout_reputation`

`affiliate_ledger`