飛書開源 CLI，讓 AI 直接管協作

飛書這次開源的，不是小工具。它是一套 CLI。官方公開了 200+ 命令，還有 19 個 AI Agent Skills。能碰的範圍很實在，像日曆、文件、多維表格、訊息都包進去。

你如果平常有在用 Claude Code 或 Cursor，這件事就很有感。AI 不只會寫程式碼，還能改行程、查文件、發訊息、整理表格。講白了，就是把辦公軟體接到命令列。

這種做法很像把企業協作系統，直接塞進 AI 工作流。對開發者來說，這是新接口層。對團隊來說，很多原本要一直點滑鼠的流程，終於能腳本化。

飛書 CLI 到底做了什麼

先講最簡單的。這個 飛書 CLI 把飛書能力拆成命令，再包成 AI 能懂的 Skills。AI 不用看整個介面，也不用猜按鈕在哪。它只要會呼叫命令，就能做事。

這一點很重要。因為很多 AI 工具卡住，不是模型不夠強，而是工具層太亂。UI 很漂亮，但對 Agent 來說很痛苦。命令列就不一樣，參數清楚，回傳也比較穩。

它涵蓋的範圍也夠廣。日曆、文件、多維表格、訊息，都是辦公室最常見的高頻操作。這些動作看起來瑣碎，但每天累積起來很花時間。真正吃掉人力的，常常不是思考，而是執行。

• 200+ 命令，覆蓋核心協作功能
• 19 個 AI Agent Skills，方便 AI 工具直接調用
• 支援日曆、文件、多維表格、訊息等場景
• 開源後可直接檢視實作與二次整合

為什麼這種 CLI 很重要

很多人談 AI 辦公自動化，只會想到寫郵件草稿或整理會議摘要。老實說，那些只是表面。真正省時間的，是中間流程。像建立會議、改時間、補資料、同步群組訊息、更新表格，這些才是每天重複最多的地方。

飛書 CLI 的價值就在這裡。它把這些步驟變成結構化命令。AI 只要理解目的，就能拆成一串可執行動作。這比單純聊天機器人更實用，因為它直接接到工作流尾端。

我更在意的是，這代表辦公軟體開始往 API 化、命令化走。以前很多企業系統把功能藏在 UI 裡。要自動化，只能靠 RPA、網頁爬操作，或零散 API。現在 AI Agent 需要的是穩定工具層。CLI 正好補這一塊。

“The future of work is not about working harder, but about working smarter.” — Satya Nadella

這句話被講很多次，但放在這裡不算空話。飛書 CLI 做的事，就是把「更聰明地工作」變成實際命令，不是停在簡報裡。Satya Nadella 談的是工作方式改變，而這類工具是在把改變落地。

你可以把它想成一個中介層。上面是 LLM。下面是企業協作系統。中間這層如果做得好，AI 才能真的動手，不是只會講。

和傳統辦公自動化比，差在哪

傳統辦公自動化通常靠宏、RPA、Webhook，或內部腳本。這些方法能用，但問題也很明顯。設定麻煩、維護累、介面一改就壞，而且很難讓 AI 直接參與決策和執行。

飛書 CLI 的思路更適合 AI 原生工作流。它把能力暴露成命令，再讓模型透過 Skills 理解用途。這樣一來，AI 不需要猜按鈕在哪，只要照命令執行。

如果拿常見工具來比，差異很明顯。不是誰比較潮，而是誰比較適合接 AI Agent。

• Microsoft 365 很強，但自動化多半還是靠 Power Automate 與生態整合
• Google Workspace 有 Apps Script 和 API，開發者體驗不差，但偏傳統開發模型
• 飛書 CLI 把可執行動作壓成命令列，適合 Claude Code、Cursor 直接呼叫
• 200+ 命令代表它不是 demo，而是覆蓋完整協作操作面

從效率看，這差很多。AI Agent 如果能直接呼叫命令，就不用人工在多個頁面跳來跳去。也不用為每個動作另外做插件。對團隊內部工具鏈來說，整合門檻會低很多。

開發者為什麼會在意

這類專案最吸引人的地方，不是「飛書能不能被 AI 控制」。而是「企業軟體能不能像開發工具一樣被編排」。如果答案是可以，那很多內部系統都會換一種玩法。

飛書 CLI 也在傳一個很直接的訊號。企業協作軟體正在進入可組合階段。AI Agent 不只會呼叫通用 LLM API，還會呼叫有明確語意的業務命令。這比叫模型自己讀一堆文件再猜，可靠得多。

我覺得會先受影響的，是兩種團隊。第一種是已經在做 AI 辦公助手、內部知識庫、流程自動化的團隊。第二種是平台工程或開發者體驗團隊。他們會開始想：我們的系統能不能也提供 CLI，讓 AI 直接接上來？

如果你想把這套思路放進自己的產品，先做兩件事就好。第一，把高頻操作抽成穩定命令。第二，把參數和回傳值設計清楚。AI 最怕模糊接口，最愛結構化輸入輸出。

這波會怎麼影響產業

飛書這次開源，真正值得看的，不是「能不能讓 AI 發訊息」。而是它會不會變成企業軟體的新接口習慣。只要更多廠商把核心功能做成可呼叫命令，AI Agent 就會從會用工具，變成直接操作系統。

短期內，最先受益的會是已經把 Claude Code、Cursor、Copilot 這些工具放進日常流程的團隊。這些團隊會最快發現，當日曆、文件、訊息都能被命令列驅動，很多協作流程會變短，也更適合批量處理。

從更大的脈絡看，這件事也和企業軟體的 API 化有關。過去很多 SaaS 產品只把 API 當附加功能。現在 AI 需要的是一層更明確的執行面。誰先把這層做完整，誰就更容易進入 AI 工作流。

我猜接下來 12 個月，會看到更多類似的開源 CLI 和 Agent Skills 包裝層。不是每家都要做得很大，但每家都得想清楚：你的系統能不能被 AI 一條命令接管？

這問題很現實。因為一旦使用者習慣了「叫 AI 直接做」，他們就不想再回去手動點十幾次了。

背後其實是工作方式在換

這類工具不是只有技術味。它也在改工作習慣。以前大家習慣的是「人操作軟體」。現在開始變成「人下指令，AI 操作軟體」。中間差的不是介面，而是責任分工。

對台灣很多團隊來說，這種轉變很實際。因為不少公司已經在用飛書、Google Workspace、Microsoft 365，卻還是靠人工處理大量協作細節。只要有穩定 CLI，很多流程就能先從內部工具開始試。

但我也不會講得太美。這類系統要真的上線，還是得處理權限、審計、錯誤回復、敏感資料保護。AI 可以幫忙做事，但不能亂做事。沒有權限邊界，工具越強，風險也越高。

接下來可以怎麼看

飛書開源 CLI 這件事，我的判斷很直接。它不是單一產品功能，而是一個訊號。企業協作軟體正在往「可被 AI 直接操作」的方向走，而且這方向很可能會越來越常見。

如果你是開發者，現在就可以想一件事。你的內部系統，有沒有辦法像飛書 CLI 這樣，被拆成清楚命令？如果答案是沒有，那你之後接 AI Agent 時，可能會比別人多繞很多路。

我會建議先挑一個高頻場景試做。像是排會議、同步文件、更新表格，先從最常重複的流程下手。別一開始就想做全自動。先讓一個流程穩定跑起來，比空談 AI 更有用。

說白了，這波重點不是 AI 會不會聊天，而是它會不會真的幫你把事情做完。這才是大家在乎的地方。