SELF-INITIATED PRODUCT／AI OPERATIONS CASE
把 AI 協作從聊天紀錄，變成可交辦、可驗收、可回看的工作系統。
將散落在不同 AI 工具、工作階段與專案文件裡的工作，整理成可追蹤、可驗證、可交接的協作流程。
01／PROBLEM
真正的問題不是 AI 不夠快，而是工作沒有可回看的脈絡。
需求釐清可能在 GPT，程式實作交給 Codex 或 Claude Code，版本與交付留在本機文件及 GitHub。每次工具或工作階段切換，背景都可能需要重新說明。
重要決策若只存在某一段對話，下一個執行者看得到任務，卻不一定知道為什麼這樣做、什麼才算完成。
背景反覆遺失
不同 Session 重新開始後，目標、限制與先前決策容易被壓縮成不完整摘要。
交付沒有共同座標
文件、任務、branch、commit 與 PR 各自存在，完成狀態難以互相核對。
審查標準到最後才出現
模糊需求直接進入執行，可能到交付時才發現成果偏離真正問題。
未完成被過度簡化
等待、阻擋、退回與風險若只剩進度百分比，就失去責任與下一步。
02／WHAT CHANGED
已建立可追溯的工作基礎，長期成效仍持續觀察。
任務脈絡更清楚
任務目標、狀態、成果與下一步有固定位置，不再散落於不同聊天與文件。
執行與審查分工
執行者、品質審查與人工決策有明確責任，不把重要判斷交給單一黑箱。
工作狀態可以追溯
完成、退回、阻擋、風險與學習保留在同一條工作脈絡裡。
跨 Session 可以接續
新工作階段能透過文件、Task ID、commit 與 PR 重新建立背景。
目前尚無足以公開的長期量化資料，因此不使用節省工時、錯誤率或效率提升的推估數字。
03／SOLUTION OVERVIEW
四個簡單解法，把工作從對話搬到可追蹤的系統。
Project／Task 取代 Session
工作核心從單次對話改成可跨工具持續存在的專案與任務。
Task ID 是共同座標
同一組編號貫穿文件、commit 與 PR，任何人都能對得起來。
GitHub 保存版本與回退
版本、diff、審查狀態與回退方式都留在可回看的紀錄裡。
人工批准保留最終決策
高風險或不確定的判斷，最後一步仍交回人來拍板。
04／KEY DECISIONS
速度不是第一個決策；先決定工作要如何保持可信。
七個決策都能由目前 repository 的介面、資料契約、測試或交付紀錄支持。
從 Session 為中心，改成 Project／Task 為中心。
- Why
- Session 會結束，專案與任務脈絡必須能跨工具持續存在。
- Trade-off
- 交辦前要先整理歸屬、目標與狀態，不能把所有背景留在對話裡。
- Evidence
- Repository 具有 project_id、任務詳情、專案進度與跨工作階段接續入口。
把 GitHub 當成版本與交付基準。
- Why
- 聊天中的『完成』無法替代可回看的 branch、commit、diff 與 review 狀態。
- Trade-off
- 交付速度受版本紀錄與審查 gate 約束；本機完成不直接等於已上線。
- Evidence
- Task／handoff 資料保存 github_branch、github_commit、github_pr 與 rollback 欄位。
把規劃、執行、審查分配給不同 AI。
- Why
- 同一個模型從定義問題一路審查自己的結果，容易延續原本盲點。
- Trade-off
- 需要更清楚的 handoff 與共同驗收條件，也增加一次協調成本。
- Evidence
- AI 團隊介面與任務欄位分開顯示 coordinator、executor、reviewer 與人工拍板。
不確定時 fail closed，或回到人工確認。
- Why
- 缺少權限、證據或明確範圍時，繼續自動執行會把未知風險變成實際影響。
- Trade-off
- 流程會保留 Blocked、Awaiting review 等未完成狀態，不用漂亮進度掩蓋等待。
- Evidence
- 任務建立、狀態轉換與批准 action 具有 server-side 驗證、拒絕原因與人工 gate。
補充決策
05建立人類可讀的 Task ID 與固定文件入口。
- Why
- 任務需要一個能被複製到文件、commit 與 PR 的共同座標。
- Trade-off
- 所有建立入口都要遵守相同格式與驗證規則，歷史資料不假裝完整回填。
- Evidence
- 任務建立契約、external_id 產生規則與列表／詳情一鍵複製已有程式與測試。
06自評之外，再保留第三方審查。
- Why
- 功能能執行，不代表內容、風險與原始目標都被正確處理。
- Trade-off
- 重要成果不會以最快速度直接結案；可能退回重做或等待補證據。
- Evidence
- Handoff 保存 self_review_score、third_party_review_score；審查佇列支援結構化退回。
07用 Platform／DB 保存狀態、決策與證據。
- Why
- 只靠 Markdown 或聊天，無法穩定查詢任務、風險、交付與決策之間的關係。
- Trade-off
- 資料 schema、遷移與存取權限本身也需要治理，不能把資料庫視為自動正確。
- Evidence
- Repository 定義 wr_tasks、wr_handoffs、wr_decisions、wr_risks 與 approvals 等資料契約。
05／WORKFLOW
每一個節點，都知道誰負責判斷、誰負責執行。
- 01
Idea
人提出問題，不預設解法
- 02
Project
Platform保存長期背景與範圍
- 03
Task
人＋Platform寫清楚目標、邊界與驗收
- 04
Planning
AI拆解方案與風險
- 05
Execution
AI／人依授權完成可逆工作
- 06
Review
AI執行驗證與第三方審查
- 07
Human decision
人批准、退回或停止
- 08
Evidence
GitHub保存 diff、commit、PR 與回退
- 09
Learning
Platform＋人把通過驗證的做法帶進下一次
人保留方向、高風險操作與最終批准；AI 負責拆解、執行與審查；Platform 保存狀態；GitHub 保存版本與可回退證據。
06／PRODUCT EVIDENCE
畫面不是功能清單，而是每個設計決策留下的證據。
總覽把執行狀態、風險與下一步放在同一個可回看的入口。
任務建立先問工作類型、成果與邊界，避免模糊需求直接進入執行。
AI 團隊畫面把規劃、執行、審查與人工拍板拆成不同責任。
07／CURRENT STATUS
同一個產品裡，也要把完成與未完成分開。
已實作並投入內部使用
- Project／Task 追蹤與人類可讀 Task ID
- 任務建立、成果、風險與審查介面
- GitHub 交付欄位、證據與回退資訊
已有版本，仍分階段驗證
- 本機 Runner 與互動式工作階段狀態
- 跨 repository／GitHub 對帳
- 部分自動派工與狀態同步
取得真實資料後才擴充
- 尚未定義驗收條件的新自動化
- 需要更高權限或不可逆操作的流程
08／MY ROLE & BOUNDARIES
我負責判斷與邊界，不是負責把一切自動化。
- Workflow discovery：從實際交辦、退回與接續紀錄中找出反覆出現的斷點。
- Product direction：決定平台要記住 Project、Task、Decision、Evidence 之間的哪些關係。
- AI orchestration：把規劃、執行、審查拆給不同 AI，並設計 handoff 與驗收條件。
- Delivery governance：訂定版本、審查 gate 與 fail closed 規則，決定何時保留人工批准。
- Validation：檢查產出是否符合任務單、留下證據、能否被下一個工作階段接續。
- 主要使用者目前是 Mavis 本人，尚無足夠長期、多使用者量化資料。
- 部分跨工具自動化仍在驗證，不能把單一環境成功當成整體完成。
- 不同 AI 工具有 Session、權限與可見資訊限制，狀態不一定能自動同步。
- 高風險、不可逆或外部寫入操作必須保留人工批准與回退方式。
- 公開案例只能使用已安全裁切、排除敏感內容的真實畫面。
REFLECTION
最有價值的不是再多一個面板，而是讓未完成也能被正確描述。
正確的判斷
先處理任務邊界、狀態語意與驗收證據，而不是先追求全自動。
目前限制
主要使用者仍是 Mavis，缺少長期、多使用者量化資料，數字仍持續累積中。
NEXT