我曾建立一支 AI 團隊，最後卻放棄了：為甚麼我仍想試 Grok Bot？

2026/9/30 · Study Straight

最近在 YouTube 經常看到 Grok Bot 的廣告，令我很想親自試一試。不過，這並不是因為我缺少另一個 AI 工具。情況剛好相反：我已經使用 ChatGPT、Claude Code、Codex、OpenClaw、豆包等不同平台。每一個工具都有自己的優點，但工具愈多，我愈常遇到同一個問題——我的工作 context 被切成很多碎片。

另一方面，我有多個網站需要管理。每個網站都有自己的讀者、語氣、內容方向、技術設定、歷史決定和待辦事項。Claude Code 和 Codex 可以直接協助本機專案與程式開發，其他工具則可能保存了研究、寫作或營運對話。當我轉到另一個 AI 平台，往往又要重新解釋一次：這個網站是做甚麼的、哪些內容已經完成、哪些做法試過但不適合、我對品質有甚麼要求。

結果，我原本想用 AI 減少工作，卻花了不少時間管理 AI。

這也不是我第一次遇上這個問題。

我曾經建立一支 AI 團隊，最後卻沒有繼續

在開始使用 OpenClaw 時，我參考了很多網上資源，也很快建立了幾個不同的 agents。我當時的分工很清楚：一個負責寫文章、一個擔任主管理、一個處理財務，另一個負責 marketing。

看起來，我已經由一個人變成一間小公司。

但真正開始使用後，我才發現建立幾個 agents 並不等於建立了一個團隊。每個 agent 可以各自完成一些工作，但要它們互相溝通、理解前一個 agent 做過甚麼、知道應該把甚麼交給下一個角色，又需要另一輪設定和調教。

我不只要管理工作，還要管理 agents 之間的交接。哪一個 agent 擁有最新資料？文章 agent 改變了內容方向後，marketing agent 是否知道？主管 agent 應該根據哪一個版本作決定？如果 context 沒有同步，我仍然要在中間複製、解釋和修正。

調教了一段時間後，我便漸漸沒有再繼續使用這套安排。畢竟，調教 agents 本身不會直接為工作帶來收入；而左手 copy、右手 paste，雖然笨一點，其實也花不了多少時間。問題的重點不是每個 agent 完全沒有用，而是整個系統所增加的協調工作，未必少過它替我節省的時間。

所以，當我最近看到很多 Grok Bot 廣告，我的興趣和懷疑其實同時出現。它是否真的解決了我在 OpenClaw 遇到的協調問題？還是只把「建立多個 agents」包裝得更容易，最後仍然要由我替它們搬運 context？

我需要的不是更多對話，而是一個持續工作的角色

Grok Bot 最吸引我的地方，不是它能不能生成一篇更漂亮的文章，而是它把 AI 的基本單位由一次性的 chat，改成一個可以長期保留的 Bot。

根據 SpaceXAI 的產品介紹，Grok Bot 是仍在 beta 階段的 always-on agent。Bot 在雲端電腦上工作，可以使用瀏覽器、檔案和已登入的工具；即使使用者離開，它仍可繼續處理任務。官方亦稱，Bot 會保留對話、學習工作方式，並可與其他 Bots 分享工作和協調任務。

對我來說，這種設計的意義不是「AI 變成了真正的員工」，而是我終於可以把 context 放在一個較穩定的角色裏，而不是每次開新 chat 都由零開始。

例如，我可以為每個網站設立一個清楚的角色：

• 一個 Bot 負責內容盤點，熟悉網站主題、讀者和文章歷史；
• 一個 Bot 負責技術檢查，追蹤失效連結、頁面速度和發布問題；
• 一個協調 Bot 整理各網站的進度，只把需要我判斷的事情帶回來。

理想情況下，我不再是不同 AI 之間的人肉 router，不需要像過去使用 OpenClaw 時一樣，反覆替不同 agents 複製背景資料、搬運結果和提醒下一步。

但 persistent context 不等於完整而可靠的記憶

這裏需要冷靜一點。

Grok Bot 官方文件寫得比宣傳頁更具體：每個 Bot 會保留較穩定的偏好、角色 context 和過往工作的摘要，但不同 Bot 的對話和學習內容仍然分開。Bots 共用的是同一部雲端電腦、檔案、瀏覽器 session 和應用程式登入；需要跨角色合作時，則透過 shared files、group chats 或直接 handoff 傳遞資料。

換句話說，它不是一個甚麼都記得、永遠不會混亂的「總腦」。Context 仍然需要設計。

而且，共用電腦和登入雖然方便，也代表權限邊界要特別小心。官方文件提醒，放在共用電腦上的內容，應視為所有 Bots 都可以接觸。網站後台、客戶資料、付款工具和電郵帳戶，不應因為操作方便便一次過全部開放。

產品目前仍在 beta。官方展示的效率提升和使用案例，主要來自公司內部及早期使用者，不能當成每個人都會得到的結果。真正使用時，網站可能阻擋自動化、登入可能失效，有些步驟仍會要求人手處理。記憶也不應取代最新資料核對；涉及重要決定時，仍應要求 Bot 回到原始來源檢查。

真正的問題，是我要把甚麼交給哪一個 Bot

有了 OpenClaw 的經驗，我愈想嘗試 Grok Bot，愈覺得第一步不應該再次建立一支龐大的 AI 團隊。

如果我把一個混亂的網站、一堆沒有命名規則的檔案，以及不清楚的要求全部交出去，persistent agent 只會令混亂持續得更久。AI 可以保存 context，但不能替我決定哪些 context 才重要。

我會先為一個網站建立一份簡單的「網站 context pack」：

1. 這個網站服務誰，以及它不服務誰；
2. 內容主題、語氣和不能接受的寫法；
3. 現有工具、資料位置和發布流程；
4. 甚麼叫完成，如何檢查結果；
5. 哪些動作可以自動做，哪些必須先問我；
6. 最近的重要決定，以及作出決定的原因。

這份資料不應只留在某個 AI 的記憶裏，而應成為我自己擁有、可以閱讀和更新的外部 source of truth。這樣，即使日後更換模型或平台，我也不需要重新建立整個工作世界。

Grok Bot 在雲端，怎樣接入我 Mac 裏的 Personal OS？

這是我真正要解決的技術問題。

我的 Personal OS 在 Mac 的 Obsidian vault 裏，Grok Bot 則主要在雲端電腦工作。根據 Grok Bot 的電腦與應用程式文件，它的雲端電腦有自己的 /workspace；這個空間與我眼前的 Mac 是兩個不同的檔案系統。桌面版可以在我開啟權限並逐次批准後，在本機執行指令，但這只是按需要存取本機資料，並不代表兩邊的檔案會自動同步。

因此，我不會把 Grok Bot 的 memory 當成 Personal OS，也不會把整個 vault 一次過搬上雲端。我的 Mac 仍然是 source of truth，Grok Bot 的雲端電腦只是工作層。

我的 Personal OS 原本已經分成兩層：

• personal/ 是由我書寫的私人 human layer，包括 journal、ideas、projects 和 reviews；
• ai-layer/ 是可以讓 AI 處理來源、分析和綜述的工作層。

這個分界可以繼續使用。我會在 AI layer 之下增加一個經篩選的 Grok Bridge，只放 Bot 完成工作所需的 context，而不是把所有私人日記、家庭資料和原始想法交給雲端服務。

整個關係可以簡化成：

Mac 上的 Personal OS（source of truth）
        ↓ 只同步經篩選的 context
Grok Bridge（雲端 /workspace 的工作副本）
        ↓
一個 Personal OS Steward Bot
        ↓ 產出進入 review queue
我確認後，才寫回 Personal OS 或網站

Grok Bot 官方亦要求使用者留意：同一帳戶下的所有 Bots 共用一部雲端電腦，包括檔案、browser sessions 和登入資料。因此，把不同網站放進不同 Bots，並不等於它們在權限上互相隔離。Bot 可以有不同角色和記憶，但它們仍看得到同一個 /workspace。這也是我不應把敏感資料全部上傳的原因。

不同 context roots，不代表我要再建立更多 Bots

我的資料並非只在一個資料夾：Personal OS 是一個 root，Study Straight 網站是另一個 root，其他項目則分散在 Site A、Site B，以及外置硬碟上的專案資料夾。

Grok Bot 不會自動理解這些本機路徑。我的做法會是為它建立一份簡單的 ROOTS.md，使用容易理解的 logical names，而不是依賴 Mac 上很長的絕對路徑：

personal-os     → 個人方向、週檢和項目索引
study-straight  → 網站內容、研究和發布狀態
site-a          → 內容網站的進度和 momentum signals
site-b          → 另一項品牌或網站專案

每個 root 只需要一個精簡的 context pack，例如：

• CONTEXT.md：目的、讀者、原則和重要背景；
• STATUS.md：目前狀態、已完成及下一步；
• DECISIONS.md：重要決定、日期和原因；
• BOUNDARIES.md：可讀、可寫、必須先批准的事情；
• INBOX.md：等待 Bot 處理的任務；
• OUTBOX.md：Bot 已完成、等待我覆核的結果。

Bot 的長期 memory 用來記住自己的角色、我的偏好和穩定規則；會變動的專案狀態，則留在這些檔案中。每次工作時，我只需指定 root，例如「在 study-straight root 檢查本週文章進度」，Bot 便先讀該 root 的 context pack，而不是搜尋整個 Personal OS 或依靠模糊記憶。

至於怎樣把經篩選的 context 送到雲端，實際上有三個層次：

1. **最簡單的試用方式：**手動把一個 context pack 附加到對話，只測一項任務，不先建立同步系統。
2. **穩定使用後：**把 Grok Bridge 放在私人 Git repository 或一個有權限控制的雲端資料夾，再同步到 Grok Bot 的 /workspace。Bot 的修改先進入 branch 或 outbox，由我檢查後才合併回 Mac。
3. **只有需要時才讀本機：**開啟 Execution on Local Computer，維持預設的逐次批准，讓 Bot 在我的 Mac 在線時讀取指定資料夾。私人 journal、密碼、付款資料和整個家目錄仍然不開放。

對我來說，第一階段甚至不需要多個 Bots。一個 Personal OS Steward 已經足夠：它先讀 ROOTS.md，根據任務選擇正確的 context root，整理資料和提出建議，再把結果放進 review queue。只有當某項工作已經穩定、重複，而且確實需要不同權限或專業標準時，我才增加第二個 specialist Bot。

這樣做的目的，是避免重演 OpenClaw 的經驗：還未證明一個 agent 能帶來價值，便先花時間建立一整間 AI 公司。

我的第一個測試，不會是全自動管理網站

我會由一項低風險、可驗收的工作開始，例如讓 Personal OS Steward 每星期讀取 site-a 的 context pack，再檢查這個網站：整理新增內容、找出失效連結、列出需要更新的舊文章，最後提交一份有來源的建議清單。

第一階段只讀取和起草，不自動發布、不刪除內容、不購買服務，也不代表我向外發送訊息。每次發現錯誤或遺漏，我便把修正寫回 context pack 和檢查規則。等到結果穩定，我才逐步開放可逆的操作。

我要測試的也不是「Grok Bot 聰不聰明」，而是三件較實際的事：

• 我重複交代背景的時間有沒有減少？
• 它在不同星期能否保持同一套網站標準？
• 加上檢查和修正後，我的總工作量到底有沒有下降？

如果答案是否定的，再多幾個 Bots 也只是多幾個需要我管理的工具。

從管理工具，走向管理責任

我對 Grok Bot 的興趣，來自一個很現實的疲倦：我不想再把自己變成 ChatGPT、Claude Code、Codex、OpenClaw、豆包、不同 agents 和各個網站之間的搬運工。

但解決方法未必是找到一個平台，把所有東西吞進去。更可能的方向，是把每個網站的 context 變成自己的資產，再交給一個有明確角色、權限和完成標準的 agent 持續工作。

這也許是 persistent agent 真正值得期待的地方：它不只是記住我說過甚麼，而是承接一項清楚的責任，知道甚麼可以繼續做、甚麼時候應該停下來問我。

YouTube 廣告可以令我注意到一件產品，卻不能證明它適合我的工作。因此，我會試 Grok Bot，但我不會先建立四、五個 Bots，也不會先問它能做多少。

我會先問自己：在我管理的多個網站裏，哪一項責任已經清楚得足以交出去？

資料來源：

• Introducing Grok Bot — SpaceXAI
• Designing Grok Bot for a world of persistent agents — SpaceXAI
• Grok Bot overview and documentation — SpaceXAI
• Use the computer and apps — SpaceXAI
• Approvals, security, and privacy — SpaceXAI

註：本文引用的是供應商截至 2026 年 9 月 30 日公布的產品功能、設計說明和案例。Grok Bot 仍屬 beta；文中對網站管理的用法是作者擬進行的測試，並非已驗證的成效。

AI 創作Productivity 生產力個人成長