From 9e79e58f87ba7e47397dda2b7989d9e2e025f47a Mon Sep 17 00:00:00 2001 From: OG T Date: Sat, 6 Jun 2026 22:55:45 +0800 Subject: [PATCH] chore: initial commit with Phase 0 setup --- .gitea/workflows/deploy.yml | 26 + .gitignore | 37 + CONTEXT.md | 58 + Dockerfile | 58 + PHASE_MASTER_FINAL_PLAN.md | 3113 +++++++++++ README.md | 82 + apps/web/.gitignore | 43 + apps/web/AGENTS.md | 5 + apps/web/CLAUDE.md | 1 + apps/web/README.md | 36 + apps/web/eslint.config.mjs | 18 + apps/web/next.config.ts | 8 + apps/web/package.json | 31 + apps/web/pnpm-lock.yaml | 4107 ++++++++++++++ apps/web/pnpm-workspace.yaml | 3 + apps/web/postcss.config.mjs | 7 + apps/web/prisma.config.ts | 14 + apps/web/prisma/schema.prisma | 88 + apps/web/public/file.svg | 1 + apps/web/public/globe.svg | 1 + apps/web/public/next.svg | 1 + apps/web/public/vercel.svg | 1 + apps/web/public/window.svg | 1 + apps/web/seed.ts | 26 + apps/web/src/app/api/cron/reaper/route.ts | 61 + apps/web/src/app/api/mcp/[tool]/route.ts | 245 + apps/web/src/app/favicon.ico | Bin 0 -> 25931 bytes apps/web/src/app/globals.css | 26 + apps/web/src/app/layout.tsx | 33 + apps/web/src/app/page.tsx | 64 + apps/web/src/app/tasks/[id]/page.tsx | 71 + apps/web/src/app/tasks/create/actions.ts | 32 + apps/web/src/app/tasks/create/page.tsx | 96 + apps/web/src/lib/audit.ts | 31 + apps/web/src/lib/prisma.ts | 7 + apps/web/src/lib/redis.ts | 9 + apps/web/src/lib/sandbox.ts | 76 + apps/web/tsconfig.json | 34 + docker-compose.yml | 44 + package.json | 16 + packages/contracts/package.json | 44 + packages/contracts/src/enums/index.ts | 230 + packages/contracts/src/errors/index.ts | 101 + packages/contracts/src/index.ts | 22 + packages/contracts/src/schemas/index.ts | 377 ++ packages/contracts/src/types/index.ts | 146 + packages/contracts/tests/schemas.test.ts | 43 + packages/contracts/tsconfig.json | 19 + packages/mcp-server/README.md | 72 + packages/mcp-server/package.json | 29 + packages/mcp-server/src/index.ts | 158 + packages/mcp-server/src/proxy.ts | 26 + packages/mcp-server/tests/proxy.test.ts | 52 + packages/mcp-server/tsconfig.json | 15 + pnpm-lock.yaml | 6140 +++++++++++++++++++++ pnpm-workspace.yaml | 3 + 56 files changed, 16088 insertions(+) create mode 100644 .gitea/workflows/deploy.yml create mode 100644 .gitignore create mode 100644 CONTEXT.md create mode 100644 Dockerfile create mode 100644 PHASE_MASTER_FINAL_PLAN.md create mode 100644 README.md create mode 100644 apps/web/.gitignore create mode 100644 apps/web/AGENTS.md create mode 100644 apps/web/CLAUDE.md create mode 100644 apps/web/README.md create mode 100644 apps/web/eslint.config.mjs create mode 100644 apps/web/next.config.ts create mode 100644 apps/web/package.json create mode 100644 apps/web/pnpm-lock.yaml create mode 100644 apps/web/pnpm-workspace.yaml create mode 100644 apps/web/postcss.config.mjs create mode 100644 apps/web/prisma.config.ts create mode 100644 apps/web/prisma/schema.prisma create mode 100644 apps/web/public/file.svg create mode 100644 apps/web/public/globe.svg create mode 100644 apps/web/public/next.svg create mode 100644 apps/web/public/vercel.svg create mode 100644 apps/web/public/window.svg create mode 100644 apps/web/seed.ts create mode 100644 apps/web/src/app/api/cron/reaper/route.ts create mode 100644 apps/web/src/app/api/mcp/[tool]/route.ts create mode 100644 apps/web/src/app/favicon.ico create mode 100644 apps/web/src/app/globals.css create mode 100644 apps/web/src/app/layout.tsx create mode 100644 apps/web/src/app/page.tsx create mode 100644 apps/web/src/app/tasks/[id]/page.tsx create mode 100644 apps/web/src/app/tasks/create/actions.ts create mode 100644 apps/web/src/app/tasks/create/page.tsx create mode 100644 apps/web/src/lib/audit.ts create mode 100644 apps/web/src/lib/prisma.ts create mode 100644 apps/web/src/lib/redis.ts create mode 100644 apps/web/src/lib/sandbox.ts create mode 100644 apps/web/tsconfig.json create mode 100644 docker-compose.yml create mode 100644 package.json create mode 100644 packages/contracts/package.json create mode 100644 packages/contracts/src/enums/index.ts create mode 100644 packages/contracts/src/errors/index.ts create mode 100644 packages/contracts/src/index.ts create mode 100644 packages/contracts/src/schemas/index.ts create mode 100644 packages/contracts/src/types/index.ts create mode 100644 packages/contracts/tests/schemas.test.ts create mode 100644 packages/contracts/tsconfig.json create mode 100644 packages/mcp-server/README.md create mode 100644 packages/mcp-server/package.json create mode 100644 packages/mcp-server/src/index.ts create mode 100644 packages/mcp-server/src/proxy.ts create mode 100644 packages/mcp-server/tests/proxy.test.ts create mode 100644 packages/mcp-server/tsconfig.json create mode 100644 pnpm-lock.yaml create mode 100644 pnpm-workspace.yaml diff --git a/.gitea/workflows/deploy.yml b/.gitea/workflows/deploy.yml new file mode 100644 index 0000000..6d5ba6e --- /dev/null +++ b/.gitea/workflows/deploy.yml @@ -0,0 +1,26 @@ +name: Deploy to 110 WOOO Server + +on: + push: + branches: + - main + +jobs: + deploy: + runs-on: ubuntu-latest + steps: + - name: Checkout repository + uses: actions/checkout@v3 + + - name: Deploy to 110 over SSH + uses: appleboy/ssh-action@v1.0.0 + with: + host: ${{ secrets.SERVER_110_HOST }} + username: ${{ secrets.SERVER_110_USER }} + key: ${{ secrets.SERVER_110_SSH_KEY }} + port: ${{ secrets.SERVER_110_PORT }} + script: | + cd /opt/agent-bounty-protocol + git pull origin main + docker compose down + docker compose up -d --build diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..72df69e --- /dev/null +++ b/.gitignore @@ -0,0 +1,37 @@ +# Logs +logs +*.log +npm-debug.log* +yarn-debug.log* +yarn-error.log* +pnpm-debug.log* +lerna-debug.log* + +node_modules +dist +dist-ssr +*.local + +# Editor directories and files +.vscode/* +!.vscode/extensions.json +.idea +.DS_Store +*.suo +*.ntvs* +*.njsproj +*.sln +*.sw? + +# Next.js +.next +out +build + +# Env files +.env +.env.* +!.env.example + +# E2B / MCP specific +.e2b diff --git a/CONTEXT.md b/CONTEXT.md new file mode 100644 index 0000000..e17e82f --- /dev/null +++ b/CONTEXT.md @@ -0,0 +1,58 @@ +# Agent Bounty Protocol + +> 前身為 VibeWork Monetization MCP + +這是一個讓外部 AI Agent 可以接案、提交解答並獲得獎金的「開源 M2M 交易閘道器與標準契約」專案。 +本專案採用 Monorepo 架構進行模組化開發。 + +## 📦 目錄與架構 (Workspace Packages) + +本專案將不同的領域邏輯分離為獨立的套件: + +### 1. `@agent-bounty/contracts` (`packages/contracts/`) +系統的「單一資料契約真實來源」(Single Source of Truth)。 +- **職責**:定義所有的 Zod Schemas、TypeScript Types 與 Enums。 +- **內容包含**: + - `TaskStatus`, `TaskDifficulty`, `JudgeErrorClassification` 等狀態機。 + - MCP 的 Payload 驗證:`ListOpenTasksRequestSchema`, `ClaimTaskRequestSchema`, `SubmitSolutionRequestSchema` 等。 + - 狀態防護與標準錯誤碼 (`isValidStateTransition` 等)。 + +### 2. `@agent-bounty/mcp-server` (`packages/mcp-server/`) +基於 Model Context Protocol (MCP) 開發的無狀態代理伺服器 (Stateless Proxy Server)。 +- **職責**:作為本機 AI Agent (例如 Cursor, Claude Desktop) 與遠端主網站 (Backend API) 溝通的橋樑。 +- **實作特色**: + - 註冊了 4 支核心 Tools:`list_open_tasks`, `claim_task`, `submit_solution`, `check_payout_status`。 + - 使用 `dotenv` 讀取環境變數 `API_BASE_URL` 與 `API_KEY`。 + - 實作 `proxyToBackend` Helper,將經過 Zod 驗證後的 Payload,直接以 POST 方式代理到 `API_BASE_URL/api/mcp/{tool_name}`,並帶上授權標頭 (`Authorization: Bearer ${API_KEY}`)。 + - 支援以 `stdio` 模式運行,供本機端點測試。 + +## ✅ 已完成進度 (Phase 1 & Phase 2) + +1. **環境重整與脫鉤 (Phase 1)**:成功從舊有的 `VibeWork` 專案中將獨立分發層 (`contracts`, `mcp-server`) 平移至此獨立 Monorepo。 +2. **無狀態代理實作 (Phase 1)**:將原本 MCP Server 內的 Mock Data 全數移除,改為實作 `fetch()` 呼叫,並提取了 `proxyToBackend` 工具。 +3. **與主網站 (Next.js) 串接整合 (Phase 2)**: + - 採用 **選項 A (完整 Monorepo)**,在 `apps/web` 建立了 Next.js API Gateway。 + - 實作 `/api/mcp/[tool]/route.ts` 成功接收與處理 MCP 代理請求。 +4. **自動化測試導入 (Phase 2)**: + - 導入 `vitest`。為 `@agent-bounty/contracts` 撰寫單元測試,並修正了錢包位址格式驗證。 + - 為 `@agent-bounty/mcp-server` 撰寫 `fetch` Mock 整合測試。 + - 完成本機端對端 (`curl`) 測試驗證資料流暢通。 + +## 🚀 接下來的推進方向 (Phase 3 & Beyond) + +未來接手的 AI (如 Codex) 或開發者可以依據以下方向繼續推進: + +1. **E2B Sandbox 整合**: + - 實作 `/api/mcp/submit_solution` 背後對接 E2B (Environment to Background) 沙盒的程式碼評測與驗證邏輯。 +2. **資料庫持久化串接**: + - 導入資料庫 (PostgreSQL, Supabase 或 Firebase) 取代 Next.js 內的 Mock 資料。 + - 實作資料庫 Schema (Prisma/Drizzle/Firebase Data Connect)。 +3. **前端 UI 介面開發**: + - 打造高質感的 Bounty Dashboard,讓人類需求方可以在網頁上發布任務。 +4. **npm 套件發布準備**: + - 設定 `tsup` 或 `rollup` 以最佳化打包。 + - 準備公開發布 `@agent-bounty/contracts` 與 `@agent-bounty/mcp-server` 到 npm registry。 + +--- + +*紀錄更新時間:2026-06-06* diff --git a/Dockerfile b/Dockerfile new file mode 100644 index 0000000..c043d52 --- /dev/null +++ b/Dockerfile @@ -0,0 +1,58 @@ +FROM node:20-alpine AS base +ENV PNPM_HOME="/pnpm" +ENV PATH="$PNPM_HOME:$PATH" +RUN corepack enable + +# 1. Setup workspace & dependencies +FROM base AS deps +WORKDIR /app +COPY package.json pnpm-lock.yaml pnpm-workspace.yaml ./ +COPY apps/web/package.json apps/web/ +COPY packages/contracts/package.json packages/contracts/ +COPY packages/mcp-server/package.json packages/mcp-server/ +RUN pnpm install --frozen-lockfile + +# 2. Build the project +FROM base AS builder +WORKDIR /app +COPY --from=deps /app/node_modules ./node_modules +COPY --from=deps /app/apps/web/node_modules ./apps/web/node_modules +COPY --from=deps /app/packages/contracts/node_modules ./packages/contracts/node_modules +COPY . . + +# Build the contracts package first since web depends on it +RUN pnpm --filter @agent-bounty/contracts build + +# Generate Prisma Client +RUN pnpm --filter web exec prisma generate + +# Build the Next.js app +RUN pnpm --filter web build + +# 3. Production image, copy all the files and run next +FROM base AS runner +WORKDIR /app + +ENV NODE_ENV production +ENV NEXT_TELEMETRY_DISABLED 1 + +RUN addgroup --system --gid 1001 nodejs +RUN adduser --system --uid 1001 nextjs + +# Copy standalone Next.js build +COPY --from=builder /app/apps/web/public ./apps/web/public +COPY --from=builder --chown=nextjs:nodejs /app/apps/web/.next/standalone ./ +COPY --from=builder --chown=nextjs:nodejs /app/apps/web/.next/static ./apps/web/.next/static + +# Copy prisma schema for runtime DB push or migrate if needed +COPY --from=builder /app/apps/web/prisma ./apps/web/prisma + +USER nextjs + +EXPOSE 3000 +ENV PORT 3000 +ENV HOSTNAME "0.0.0.0" + +# Run the standalone server +# Note: The standalone output creates a server.js file at the root of the workspace context +CMD ["node", "apps/web/server.js"] diff --git a/PHASE_MASTER_FINAL_PLAN.md b/PHASE_MASTER_FINAL_PLAN.md new file mode 100644 index 0000000..be8c3f6 --- /dev/null +++ b/PHASE_MASTER_FINAL_PLAN.md @@ -0,0 +1,3113 @@ +# 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 | 在頁面渲染 `

Hello VibeWork

` | +| 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 | `