OpenClaw 企業使用曲線

有好多人都跟我說：「欸，為什麼最近 OpenClaw 不紅了？會不會它根本就是一個假議題呢？」

我今天把這幾個月 OpenClaw 的使用曲線，請 OpenClaw 來畫一下圖表。因為內容涉及公司的一些數據，我這些數據的 scale 跟點數是有調整過的，但整體趨勢是不變的，所以我會以趨勢來做說明。

折線圖是 OpenClaw 總 Task 數，彩色長條是公司機敏文件的 Task 數。最有意思的不是高峰，是中間那段低谷。

那段低谷不是因為我不用了。是因為我在做 SOP 數位化。

這件事不是技術問題。這件事是組織問題。而這段低谷，才是 AI 真正落地在企業的關鍵。

調研期：不急著動手

OpenClaw 剛推出的時候，我花了不少時間做調研。不是那種隨便玩兩下的調研，是真的去理解它的架構、能力邊界、跟既有工具的整合方式。

這段調研期很重要。因為它讓我真正開始用的時候，不是從零開始摸索，而是帶著明確的整合目標進去的。

個人工作流爆發

調研結束之後，我很快就把 OpenClaw 整合進自己的 Skill 裡，然後開始大量使用。

這個階段做的事情都是個人工作流：Email 處理、文件整理、資料彙整。說白了就是把原本手動做的事情，丟給 OpenClaw。圖上前段那個高峰，就是這段時間。

在這段期間，我開發出了一個對我影響很大的 Skill，叫 Daily Briefing。它把我的 Todo、Calendar、Email 整合在一起，每天早上自動給我一份簡報。

這個 Skill 讓我對 OpenClaw 徹底改觀了。我第一次覺得它非常好用，而且一定要放進我的公司工作流裡面。它不只是「幫忙跑任務」，而是能主動整理我的一天。這個過程本身就是 OpenClaw 的優勢 — 你不是在一個固定的 UI 上點來點去，而是在對話中反覆修正、逐步逼近你真正要的東西。功能一推出，就能整合多個數據源，馬上變得非常好用。

有了龍蝦之後，n8n、Make.com、還有其他排程工具，全部都被我拋棄了。因為我還是不斷地在每次提問當中修改它、進化它。那些固定流程的工具做不到這件事。

這些 Skill 大概是在個人研發的最後階段開發出來的。只是那時候卡在資安的議題，沒辦法直接用在企業工作流，只能留在我個人的使用場景裡。

效果很好。但也只到這裡。

因為個人工作流跟公司工作流是兩回事。

低谷期 — SOP 數位化才是真正的門檻

當我試著把 OpenClaw 導入公司流程時，使用量直接崩下來。

我花了一段時間重新 align 公司的工作流。一開始試著直接把 OpenClaw 塞進既有的流程裡，結果發現大部分的工作流根本沒辦法直接 implement。原因不是 OpenClaw 不夠強，而是公司的 SOP 本身就不夠數位化。

很多流程還停留在「口頭交代」「Email 轉寄」「會議上講一下」的階段。你沒辦法把一個模糊的人類流程直接交給 AI Agent 去執行。

所以我做了一件聽起來很基本但極其關鍵的事：把 SOP 盡可能數位化。

寫下來。流程化。讓每一步都有明確的輸入和輸出。

這件事對一般公司來說，我們的進展動作已經算非常快了。

為什麼我推得比別人快

這裡我要坦白說一件事：我的條件比大部分人好。

第一，我是管理層。 改流程不需要層層審批，我自己就能拍板。

第二，我對這項技術非常了解。 不是那種「聽過 AI」的了解，是真的理解 Agent 的能力邊界，知道哪些事情它做得到、哪些做不到。

第三，流程修改有一大部分是由我們團隊主導。 不需要跨部門協調，也不需要等其他團隊配合。

這些條件加在一起，讓我能很快完成 SOP 調整。但我非常清楚，在大部分公司裡，光是「說服管理層讓 AI 碰 SOP」這件事，可能就要拖非常久。

起手式：Email CC

我一開始的做法非常簡單 — 就是透過 Email CC 的方式，讓 OpenClaw 讀取相關資訊。

不需要改系統、不需要串 API、不需要 IT 部門配合。CC 一個信箱，OpenClaw 就能讀到上下文。

這個做法的好處是「零門檻」。任何人都會 CC Email。任何部門都不會因為你 CC 了一個信箱就跳出來反對。

後來隨著 SOP 數位化的推進，我進一步把資訊整合到數位化系統裡。那時候 OpenClaw 就已經能處理很多事情了。

從 Email CC 到系統整合，這個過程是漸進的。不是一次到位，是慢慢長出來的。

隱私牆與地端 Server

接著碰到了一個關鍵問題。

公司的機敏 Task，我後來還是決定不要放到雲端。

其實地端模型這條路，去年就開始嘗試了。OpenClaw 出來之後，我也試了很多當時的模型，包含 Gamma 還有一些小模型。但講難聽一點，沒有一個可以用的。不是跑不動，是品質根本不到能拿來 review 文件的水準。

直到 Qwen 出了新版本之後，整個局面才改了。我試完之後就立刻去購入地端 Server。

結果一上線就發現：大量的 NDA、IP 協議、SOW 文件，都可以透過地端模型來進行 review。

這扇門一打開，使用量就直接回來了。

企業文件 Review 上線

地端設備架好之後，公司相關機敏的 Task 分類就直接上去了。從圖上可以看到，彩色長條從那個時間點開始出現，而且成長得很快。其實到現在，這些機敏 Task 已經很輕易地就能整合進工作流裡了。

最近的進展：LLM Wiki 串起地端生態

最近我又加入了一個新的拼圖 — LLM Wiki，一個參考 Karpathy 做法建立的知識庫 Skill。

會選它的原因很直接：它是一個完全地端的 solution。所有的知識整理、索引、查詢都在本機跑，不需要上雲端。

更重要的是，它能幫我把龍蝦跟本機的 Claude Code、Codex 做整合集成。以前這幾個工具各自獨立運作，現在透過 LLM Wiki 作為中間的知識層，它們可以共用同一套整理過的脈絡。龍蝦知道的事情，Claude Code 也能查到；Codex 產出的結果，也能回到 Wiki 裡沉澱。

這件事的意義在於：地端不再只是「雲端的替代方案」，它開始長出自己的生態。

幾個心得

SOP 數位化是 AI 落地的前提，不是結果。 很多公司以為「導入 AI 之後流程會自動改善」。不會。你得先把流程改到 AI 能接手的程度，AI 才能幫你。

管理層懂技術，推動速度完全不同。 這不是在自誇，是在描述現實。如果改流程需要說服好幾層主管，那光是 SOP 數位化這一步就可能卡非常久。

Email CC 是最低成本的起手式。 不要一開始就想串 API、接系統。先讓 AI 能「看到」資訊，後面的整合自然會長出來。

隱私不是放棄 AI 的理由，是架構選擇。 雲端不行就用地端。合約限制了工具選擇，但限制不了問題的解法。

那段低谷期才是最有價值的。 如果你的 AI 使用曲線一路往上、沒有任何低谷，那你可能只是在做個人探索，還沒碰到組織層面的問題。真正的企業導入，一定會經歷一段「看起來退步、其實在鋪路」的階段。

下一步

目前的狀態是穩定運作中。個人工作流跟企業文件 review 都在跑。

接下來要做的，是把這套做法推廣到更多團隊成員。這又會是另一段低谷期 — 因為每個人的工作流都不一樣，SOP 數位化的過程得再走一遍。

但至少我知道了：那段低谷不是失敗，是必經之路。