行動開發多 Bot 分工：案例導讀與縮小版 checklist

來源

根據官方指南《Grok Bot for mobile app development》（約 2026-08-25，作者 Ryan Perry）重寫。原文是手機遊戲 Rank’em 的個人多 Bot 案例；文中成效數字屬該案例自述，不構成你專案的保證。畫面與權限以你為準。

若還沒裝好，先看 從零上手。

為什麼談「多 Bot」而不是單一聊天窗

寫 App 本體愈來愈快，上架之後還有獲客、素材疲勞、後端與 live ops、審核與憑證、裝置特異崩潰。原文把「遊戲本體以外那一大塊」拆成職缺，每職缺一隻長駐 Bot，彼此可交接。台灣個人開發者與小團隊很難一次養六席；下面先講概念，再給縮小版 checklist。

先把 Bot 想成職缺

官方案例強調側邊欄裡每一席，比較像「固定同事的對話」，通常要備齊：

1. 職稱說明：負責哪條產線、明確拒絕哪些事。
2. 連線：已登入的分析、廣告、商店、錯誤追蹤、程式庫等帳號。
3. 雲端電腦：瀏覽器與終端機，筆電關閉仍可跑。
4. 例行（Routines）：固定時刻彙報，不必你每次打開 App 才觸發。
5. 技能（Skills）：你操作一次並錄下點擊路徑，之後重播（API 卡驗證時特別有用）。
6. 交接（Handoffs）：直接把工作傳給另一隻 Bot，不必每步經過你。

最後一項決定「像不像團隊」，沒有交接，多隻 Bot 只是多個分身；有交接，才能形成分析→素材→工程→釋出的流水線。

官方案例六席（僅供對照，標案例性質）

席次	職責摘要	界線示例
Orchestrator	管商店與分派	路由，少自己改核心邏輯
Analytics／UA	讀花費與行為，唯一可宣布「發現」	不寫素材、不改 App 程式
Creatives	把發現變成廣告規格與變體	不自己下廣告預算
Engineer	依規格改 App／後端	發現要寫成規格再收
Infra／Deploy	叢集、憑證、部署與回滾	沒過這關不進玩家環境
Bug fix	夜間掃錯誤追蹤	明顯的修、不明顯的上報

原文還示範：先把「分析↔玩法」回饋圈做成第一隻 Bot；夜間與早晨例行讀廣告與產品漏斗；素材上傳若 API 不通，就錄一次網頁操作當技能。案例自述曾因調整素材與功能假設，改善安裝成本與 D7 留存；那是該產品當時的結果，請當啟發，勿當你的 KPI 模板。

個人／小團隊：建議從 2～3 席起

不要複製六席名稱，依你本週最痛的一環開刀： 兩席起步（一人專案）

• 營運觀察：每晚摘要安裝、崩潰、商店評論關鍵句；有廣告再加花費與 CPI。唯一可宣布「值得改什麼」。
• 建置與修復：收觀察席的規格（要寫成可驗收事項），改程式、跑基本檢查；部署與上架前必須問你。

三席（兩人小團隊）

• 上面兩席，再加上 釋出守門：TestFlight／內部測試、隱私標籤文案草稿、憑證到期提醒、分階段釋出檢查清單。玩家看得到的版本，一定經過這席與你的核可。

廣告素材若你每週都在換，再拆第四席「Creatives」；在那之前，觀察席只輸出「下一則素材該測的假設」給你自己做也行。

設定一隻 Bot 的最小模板（繁中）

可直接貼上後改專案名：

你是《專案名》的營運觀察席。你只讀資料、宣布發現、寫成給工程的規格草稿。你不改程式、不下廣告單、不回覆使用者私訊。每晚 21:00（台北）彙報：安裝／活躍／崩潰／商店評論摘要；若有廣告帳號，附上花費與素材勝出／落敗。發現要附證據連結。需要花預算或對外交互前先問我。工具缺連線時先問我，不要自行繞道。

工程席則寫：「只接受規格、不接受模糊建議；合併與上架前列 diff 摘要等人核可。」

縮小版一週 checklist

• 寫下本週唯一目標（例如「弄清為何 Day-1 流失」或「穩過一次內部測試」）。
• 開 2～3 隻 Bot，職稱與禁止事項寫進說明。
• 接上你真正每天看的工具；接不上的先記缺口，勿假裝有 API。
• 設一條台北時區例行彙報；輸出短到你早餐滑得完。
• 選一個最煩的手動流程錄成 skill（例如匯出報表、上傳一則測試素材）。
• 規定交接格式：觀察→工程用「規格」；工程→釋出用「版本說明＋風險」。
• 花錢、上架、對使用者發公告、刪資料：人核可。
• 標註本專案是學習／個人練習專案或商業專案；商業專案另審個資與廣告帳戶權限。
• 記得：同帳號 Bot 常共用雲端電腦與登入，分工≠隔離。

何時先別上多 Bot

• 若連本機建置與一個正式測試軌都尚未穩定，先別上多 Bot。
• 公司禁止把商店、廣告、崩潰後台接到雲端代理人。
• 你期望「一鍵保證 CPI 大幅下降」：案例數字不可直接外推。

下一步：用最小模板開一隻營運觀察席，跑七天只讀彙報。覺得規格寫得清楚，再開建置席接交接。完整六席敘事見官方原文。