它是什麼

飛書知識庫「Grok Bot 焚诀」裡、網名「金尘马」寫的〈萬字長文|Grok Bot 從入門到精通〉。主線是把「一句一句指揮」改成「交代一個要長期負責的結果」,再逐步加 Skill、定時任務和第二個 Bot。與 grokbot-what-it-is-first-setup-20261113、grokbot-team-orchestration-20261113 互補,本卡保留這篇獨有的組件拆分、檔案三種用法、無人值守品質規則與電商示例,不重複訂閱價目。

能用來做什麼

給第一個長期崗位寫說明、判斷何時才該拆第二人,以及用共用目錄做跨崗位交接。

怎麼用(作者方法,未實測)

原文稱使用前要滿足:帳號有 Grok Bot 資格、桌面客戶端(macOS/Windows;移動端當時寫支持 iPhone)、開啟雲端儲存。建立入口是側邊欄 New → Create new agent,再到 Edit Profile 填名稱、職位與崗位說明。

五個核心組件:Bot(誰長期負責)、Skill(怎麼做)、定時任務(何時開始)、群聊(公開交接)、連接器(進哪些軟體與資料源)。

適合長期交給 Bot 的工作:結果會反覆出現、資料源與工具相對穩定、方法能逐漸說清、交付能檢查、人閘能提前劃界。崗位說明建議寫:負責結果、長期資料源、步驟與判斷、固定交付物、驗收標準、禁止動作、人工審批點、失敗時怎麼處理。先寫最低可用版,做完一件真實任務再補規則。

派任務寫清五件事:最終結果、去哪找資料、限制、交付格式、做到哪一步要回來確認。不要只發「幫我研究一下」。第一次交付後直接指出錯在哪、缺什麼、以後用什麼格式。

配置:

  • 雲電腦:網頁任務會自己開遠端瀏覽器,可隨時查看或接管;多 Bot 交接放 ` 專用目錄,專案分開資料夾與檔名。
  • 連接器:原文路徑為 Settings → Plugins,新增後可在聊天用 @ 引用;有連接器時優先於反覆模擬點擊。覆蓋不到的網站再用瀏覽器,遇驗證由人接管。
  • 三種檔案用法:一次性資料直接發進聊天;Bot 之間交接放 `;要處理本機目錄時,再在 Settings → General → Agent → Execution on Local Computer 授權。本機動作會顯示命令並請求同意。雲電腦與面前的 Mac/Windows 是兩套環境。

Skill:任務穩定跑通後再保存,並換一種輸入重測。原文稱 Teach a task 可透過最長約十分鐘的瀏覽器示範生成 Skill。Skill 裡至少要有:何時該用、輸入與權限、步驟、怎樣算合格、缺失與失敗怎麼辦、哪些動作必須等人批准。

定時任務:先確認負責人、時區、輸入與預期結果;第一次測試排在 5 到 10 分鐘後,並做一次 Test run。無人值守至少補上:寫明實際來源與時間;沒有當期資料就報錯;部分完成要分開寫已完成/未完成/原因;重試不可重複發送或生成衝突檔;發布、刪除、付款與生產變更繼續等人;來源格式變了要重測;人要定期抽查,不能把連續成功當成永久可靠。

第二個 Bot:等專業分工真正出現再建立。群聊用 @名稱指定下一手,每階段只設一名負責人,避免兩人同時改同一檔;@everyone 只在所有成員都要處理時用。群裡交接當時只支持文字;要看圖就直接發給下一手。

權限:同一帳號共用雲電腦、檔案與登入態,分 Bot 不能隔離帳號權限。發信與私信、發布、付款退款、刪檔、改權限、改生產系統,都應停在人工審批;規則要寫明具體範圍。

電商示例(示意,不是通用編制):先有一名「店鋪經營值班員」,穩定後再拆內容增長、庫存分析、訂單售後;共用 ` 下的建議、風險表與晨報。庫存預警時,各崗位只檢查自己的資料,再由主管匯成「是否補貨、是否改內容計畫、是否改發貨與回覆」三件事給人決定。

限制與坑

  • 原文寫產品仍處於 Beta,介面與流程會變。
  • 作者在文末的關注與變現數字是作者自述,不當事實,本卡不轉錄。
  • 本卡不展開訂閱選檔與省額度細節,見相關卡。

成本

見 grokbot-quota-saving-checklist-20261113。本篇未另列價目。

工作流遷移與資料展示分層(55、58)

可信度 B;作者方法,尚未實測;沿用既有正式狀態。Last updated: Oct 14 年份未寫明。

55 建議反覆打磨的 Skill 留在原工具,穩定且需長期運行的才搬到雲端;模型、流程與分工不要同時全換,以免失敗難定位。先約定可複製範圍,搬後實際調用驗收;Skill 所在位置與由誰調用分開寫,且補齊服務對象、負責段落及交付對象。不得把這條經驗理解為可複製登入態。

55 的資料路線是手機收集 → 知識庫待審 → 按任務提供給相關崗位;優先接現有可雲端存取、可供 Agent 調用的庫,不把所有資料推給所有 Bot。58 補充將雲電腦資料庫留作源資料,腳本定時同步到 Notion Database 作人看的映射視圖,不把展示看板當源庫。這是作者架構偏好,不代表已驗證同步可靠性。

用訪談釐清需求及證據化巡檢(56、57)

57 的獨有起步法是請入口 Bot 一次只問一題:負責結果、交付物、來源與使用帳號、步驟、完成標準、停止點、保存位置與週期。先交崗位說明給人確認,再建立並試跑;缺答案時先提出方案,不自行假定。

團隊版先訪談目前流程與人工審核環節,整理順序後才比較三種編制方案;每案列角色、上游落點、下游讀取位置、審批點及優缺點。選定後才建角色與共享規則,最後用一個小任務逐件驗收。這補充需求釐清方法,不要求起步就建三套團隊或新增多個 Bot。

56 用網站巡檢示範驗收:只訪問指定頁面及已授權來源;保留連結、檢查時間、截圖、操作步驟、預期與實際結果;問題按影響排序。沒有異常也記錄檢查範圍,登入失效或缺資料就列缺口並繼續其他頁面,不反覆卡在同一步。檢查任務不混入修改網站。

把巡檢存 Skill 時補上「內容與昨天相同不等於異常」,只有預定內容未出現或狀態不符要求才報問題。演示報表匯出還要補空記錄、日期選擇及下載檔檢查。檢查頻率與通知頻率分開,有新問題才通知,其餘留檔;需要確定響應時限的關鍵系統不依賴此類對話執行。重要結果回到原業務系統,記憶不替代權威紀錄。

57 的採集示例另記每個關鍵詞近期檢索次數與取得目標內容的成功情況,供每週調整關鍵詞;未提供統一計分公式,不補造。自媒體交付的完整流程見 grokbot-content-production-review-20261113。

可信度 B;作者方法,尚未實測;沿用既有正式狀態。來源頁均標 Last updated: Oct 14,年份未寫明。

逐角色量測與先做業務盤點(30)

網名 CyrilXBT 的課程先讓幕僚長讀使用者授權的既有業務記錄,提出最值得測的三個具體重複任務;先手工驗收,再測單角色獨立執行,最後才排程,不一次開出全部角色。這是教學路線,不要求每種首任務必經同一編制。

獨有的月度量測按 Bot 分開記:相對手工基線真實省時、交付前仍需改動的程度、近期信任上升/持平/下降;不能用整體印象掩蓋單崗位退化。勝任銷售研究不證明能勝任財務行政;新任務重走驗收。與 grokbot-one-person-company-20261113 的角色評分互補,不另建課程卡。

來源反覆「每 Bot 一台電腦」措辭與同庫共享模型衝突,不沿用;所稱購物人閘不當技術上永不越權的保證。價格與資格為舊資訊,不重刊作開通指南。

可信度 B;作者方法,尚未實測;沿用既有正式狀態。頁面 Last updated: Oct 14 年份未寫明。

更新紀錄