Table of Contents
🖥️ 委派給一台電腦
這類 AI 助理跟聊天機器人的差別，一句話就講完：它有一台自己的電腦。有桌面、有終端機、有瀏覽器，你關掉筆電它照樣在跑。但真正難的從來不是功能。難的是——你要把哪一段工作交出去、交到哪裡為止、出事了誰接。
📋 設定一個 Bot，其實是在寫職務說明書。而職務說明書永遠要回答四題：什麼情況下該動手、做完交出什麼、哪些動作要先問過我、卡住了怎麼辦。
⚠️ 第四題最常被跳過，也最常出事。人在不確定時會停下來問；這種系統不會，它會挑一個看起來合理的方向繼續做。
🔑 共用一台電腦，等於共用所有帳號。A Bot 登入過的網站，B Bot 往往也能用。
🏥 授權從來不是全有全無。會出事的組織通常不是授權太少，而是授權邊界沒寫下來——每個人憑印象判斷自己能做到哪，然後某一天發現印象不一致。
👉 這波工具最大的副作用可能不是效率，而是逼我們把一直靠默契運作的流程，第一次真的寫下來。
#AI #AIAgent #工作流程 #委派 #數位轉型
委派給一台電腦
Grok Bot 101 真正在談的不是 AI 功能，是你能不能把一份工作講清楚
這類助理跟聊天機器人的差別，一句話就講完：它有一台自己的電腦。有桌面、有檔案系統、有終端機、有瀏覽器，登入狀態會留著，你關掉筆電它照樣在跑。你可以打開它的視窗看進度，遇到驗證碼或付款再把桌面接回來。
但真正難的從來不是這些功能。難的是：你要把哪一段工作交出去、交到哪裡為止、出事了誰接。這不是新問題——任何帶過人的人都處理過。差別只在於，這次被委派的對象不會累、不會問、也不會在不確定的時候停下來。
一、設定一個 Bot，就是寫一份職務說明書
設定畫面只有三個欄位：名稱、職稱、描述。前兩個是標籤，真正決定成敗的是第三個。
大多數人寫描述的方式，是描述「希望它會什麼」。這會失敗，因為那是履歷，不是職務說明書。有用的寫法是把你自己做這份工作時，腦中那套判斷寫出來——而職務說明書要回答的，永遠是同樣四個問題。
第四題最常被跳過，也最常出事。人在不確定時會停下來問；這類系統不會——它會挑一個看起來合理的方向往下做。所以「不確定時停下來回報」必須是你寫進去的，不是預設。
二、三種觸發方式，決定它算不算「同事」
| 觸發方式 | 用在什麼工作 | 要注意 |
|---|---|---|
| 聊天 | 一次性任務、釐清需求、臨時分派 | 最安全，但你不在就不會動 |
| 例行與事件 | 每日摘要、PR 更新、CI 失敗、被 mention | 「你關掉筆電也要跑」的工作才值得做成這種 |
| 其他 Bot | 窗口請設計補圖、再請文件寫說明 | 鏈一長，錯誤會沿著鏈傳遞而且沒人喊停 |
三、共用一台電腦，等於共用所有帳號
這是整份指南裡最值得放大的一句：如果那台電腦已經登入購物網站，它理論上就能下單。就像一個可信的同事坐在你電腦前——差別是他知道哪些事該先問你，而系統不知道。
| 動作 | 預設授權 | 對應到醫院的話 |
|---|---|---|
| 讀專案、查資料、開 PR 草稿 | 放手做 | 例行檢查，做完報告即可 |
| 對外寄信、付款、下單 | 先問再做 | 要簽名的處置 |
| 強制推送、刪分支、合主幹 | 不授權 | 不在授權範圍內的操作 |
授權從來不是全有全無。真正會出事的組織，通常不是授權太少，而是授權邊界沒有寫下來——每個人憑印象判斷自己能做到哪，然後在某一天發現印象不一致。
四、外層與內層：把脈絡整理乾淨的人，和動手的人
指南裡最實用的一招，是別讓同一個代理又討論又動手。外層負責從文件、討論串、議題追蹤器把脈絡收乾淨，寫成一份乾淨的 brief；內層（雲端寫碼代理或你本機的 coding agent）拿著 brief 進 repo 改碼、跑測試、開 PR。
這個分工你應該很熟：整理病史、把問題問清楚、決定要做什麼，跟實際執行處置，本來就是兩件事。硬塞在同一段對話裡，上下文會越髒越難收，最後誰都說不清楚當初為什麼那樣改。
三種交接方式，由輕到重：
- Brief 交接：Bot 產出可直接貼進寫碼工具的指示（背景、範圍、驗收、明確不做什麼），你執行，結果貼回來驗收。
- 檔案中介：規格、專案記憶檔、驗收清單放在 repo 或雲端硬碟，人和工具讀同一份。
- GitHub 當橋：寫碼工具開 PR，Bot 做摘要、review 提醒、CI 狀態與後續分派。
五、多 Bot 要有窗口，不然你會被刷版
三個可以直接照抄的劇本：
- 小功能上線：你講需求 → 需要畫面找設計 Bot、需要對外說明找文件 Bot → 窗口彙整成 brief → 你或寫碼工具實作 → 回來驗收。
- 文件與程式分軌：重構測試走寫碼工具，SOP 與會議結論走文件 Bot，窗口只負責確認兩邊講的是同一件事。
- 上線週群組：把窗口、文件、設計拉進同一個群組，你只對窗口下指令，由它分派與追進度。
六、怎麼開始
| 時間 | 做什麼 |
|---|---|
| 今天（30 分鐘） | 寫好一個主 Bot 的職稱與描述，含那四個問題的答案。拿一件真實小任務跑一輪「整理 brief → 寫碼工具 → 驗收」。 |
| 這一週 | 瓶頸在 PR 或議題，就接 GitHub 設每日摘要；需要信件或行程再接信箱與日曆。試一次三角色的小鏈。 |
| 這一個月 | 把手動做過三次以上的流程做成例行。需要時再加專精 Bot，避免全能瓶頸。順便盤點：哪些自己寫的小工具，其實該退回成流程。 |
七、可以直接抄的提示詞
向窗口 Bot 要一份寫碼 brief
目標：
技術限制：
相關檔案／目錄（若知道）：
完成定義（怎麼算做完）：
明確不要做：
不確定的地方：請列出來問我，不要自己選一個往下做。
請輸出可直接貼進寫碼工具的指示。請窗口指揮其他 Bot
請你當窗口：
1. 先請設計 Bot 產出……
2. 再請文件 Bot 寫……
3. 最後彙整成「摘要 + 寫碼 brief」給我。
不要自行廣播給無關的 Bot。
任何一步失敗就停下來回報，不要跳過繼續。設計一個例行（接好服務之後）
每個工作日早上給我：
- 未合併的 PR
- 等我 review 的項目
- CI 失敗的項目
用繁中短摘要。沒有變化就保持安靜。這類助理的上限，幾乎不在模型，而在你能不能把一份工作描述到別人接得住。能寫成職務說明書的工作，就能委派；寫不出來的，通常代表你自己也還沒想清楚。從這個角度看，這波工具最大的副作用可能不是效率，而是逼著我們把一直靠默契運作的流程，第一次真的寫下來。
本文改寫自 Matt Palmer 的公開指南《Grok Bot 101》，重新以委派、授權邊界與外層／內層分工的角度整理，並補上實務上的接法。插圖為內嵌 SVG，隨 HTML 一併貼上即可，無需外部圖檔。