前言¶

團隊裏常見的問題是：同一批報表每個月手工彙總一次，同一批通知每天要按規則分發一次。這類任務重複度高、規則穩定，但很少有人願意專門爲它寫一套系統。一般的做法是要麼繼續人工處理，要麼臨時拼一段腳本——腳本跑過一兩次就沒人維護了。

辦公自動化 這個 Skill 走的是第三條路：先讓 Agent 識別哪些任務值得自動化，再按「觸發器—動作—兜底」的結構把方案設計出來，最後輸出可以直接跑的腳本、集成配置或低代碼搭建步驟。下面介紹這個 Skill 的實際情況、能力和啓用方式。

這是什麼¶

一句話定位：面向企業辦公場景的自動化方案生成 Skill，輸入是一段任務描述，輸出是可運行的自動化方案。

它解決的不是「怎麼調用某個 API」，而是「這個活兒該不該自動化、自動化成什麼形態、出了異常怎麼辦」。和通用代碼生成 Skill 的區別是，它把兜底和觸發條件當成方案的一等組成部分，而不是寫完腳本之後的補丁。

核心功能¶

官方簡介寫的是：識別高重複辦公任務，設計觸發器-動作-兜底，生成可運行的自動化方案（腳本/集成/低代碼）。拆開看是三步。

1. 識別候選任務。從一段工作描述裏判斷哪些環節屬於高重複、規則明確的類型，把值得自動化的部分挑出來。
2. 設計觸發器-動作-兜底。確定什麼時候啓動（定時、事件、手工觸發）、啓動後做什麼、失敗之後回到什麼狀態。
3. 生成可運行方案。按任務性質給出三種落地形態之一：獨立腳本、已有系統的集成配置，或低代碼平臺的搭建步驟。

需要 API Key 的環節在資料裏沒有出現，標籤 requires_api_key=false 說明本身不依賴外部付費模型接口，可以直接在本地 Agent 環境裏跑。

安裝與啓用¶

已抓取的資料裏沒有提供具體的安裝命令或配置字段，只有名稱、座標、版本、分類、來源歸屬和標籤這幾項元數據。這個 Skill 遵循通用 SKILL.md 格式，實際啓用方式以 SkillHub 頁面爲準。

下面是啓用前需要確認的幾項信息，命令本身需要在頁面上覈對後再執行：

# 待確認項：資料中未給出安裝命令
# 1. 安裝來源：SkillHub 頁面 https://www.skillhub.cn/skills/kunlungrowth/kunlun-office-auto
# 2. 加載位置：Agent 的 skill 目錄（具體路徑取決於所用 Agent）
# 3. 額外配置：資料中未列出任何配置項

另外兩點值得注意。一是該 Skill 無需 API Key，裝完即可用，不用先申請密鑰。二是 SkillHub 頁面當前顯示安裝次數爲 0、下載 1223 次、評分 100000。安裝數爲 0 意味着還沒有可參考的實際部署反饋，評分數字則是平臺側的展示值，不宜當作使用體驗的佐證。

典型用法¶

資料裏沒有給出官方的完整可復現示例，下面的用法是按 Skill 自帶的三步流程組織的，屬於流程層面的描述，不是經過實跑驗證的輸出樣例。

第一步，把任務說清楚。給 Agent 一段具體的工作描述，包含觸發頻率、涉及的文件或系統、期望結果：

每週一上午 9 點，把上週五新增的客戶工單按優先級分類，
寫入銷售羣公告，並把高優先級工單同步到負責人郵箱。

第二步，讓 Agent 先判定自動化收益，再給出方案結構。這個 Skill 會按觸發器—動作—兜底的順序組織答案，而不是直接開始寫代碼。

第三步，看產出物屬於哪種形態。規則簡單、數據量小的通常落到腳本；需要對接現成系統的落到集成配置；在低代碼平臺上搭建的落到搭建步驟。拿到方案後建議先在測試數據上跑一遍，確認兜底路徑能覆蓋失敗場景。

適用場景與注意¶

適合的場景：規則明確、重複頻率高、輸入輸出邊界清楚的辦公任務，例如定期彙總、按規則分發、跨表格搬運數據、批量通知。

不太適合的場景：規則本身還在頻繁變化的工作。這類任務自動化之後，維護腳本的開銷會超過人工處理的開銷，而且每次規則調整都要改方案，不如等規則穩定後再做。

使用時的三個注意點：

1. 觸發器要能被驗證。如果「什麼時候啓動」這一步只能靠口頭約定，自動化方案實際上是不可運行的。
2. 兜底要落到具體動作。僅僅寫「失敗則通知某人」不夠，需要明確通知渠道、通知對象和重試次數。
3. 權限和數據範圍要先確認。自動化腳本會以當前環境的身份訪問文件和系統，涉及跨部門數據時需要提前確認授權範圍。

結尾¶

辦公自動化 的價值在於把「該不該自動化、自動化成什麼樣」的判斷過程固化進了 Skill，輸出的方案帶觸發器和兜底，而不是一段跑完就不管的腳本。需要了解最新安裝方式和示例，以官方頁面爲準：https://www.skillhub.cn/skills/kunlungrowth/kunlun-office-auto