我們怎麼把 Slack 裡的 AI 助理,調教成公司的共享大腦
ARTOGO 導入 Dainy 的第一課,企業 AI 不是先接工具,而是先定義角色、權限和資料來源。分享把 Slack AI 助理調教成公司共享大腦的實際過程。
很多公司導入 AI 的第一步,是先問這個 AI 可以接哪些工具,Slack、Notion、Gmail、Drive、Figma、排程、資料庫都能接,我們一開始也往這個方向想,但真正導入之後才發現,工具從來不是第一個問題。
真正的第一個問題是:這個 AI 在公司裡到底是誰,它是誰,決定了大家會怎麼用它。
- 只是 chatbot:大家把它當成搜尋框,問完就結束。
- 是助理:它得知道怎麼回話、何時查資料、何時提醒風險、何時不該亂答。
- 是公司共享大腦:它還得知道誰在問、能看哪些資料、哪些操作要授權、哪些事要留下紀錄。
這就是我們調教 Dainy 的起點。
從人格開始,不是從 API 開始
Dainy 一開始不是先被要求接工具,而是先被要求設定溝通方式,Walt 問得很直接,我們要怎麼設定妳的溝通人格和做事方式,這看起來像語氣問題,其實是企業 AI 的產品定義問題。
我們不想要 Dainy 像客服,客服式回答太安全、太泛、太罐頭,公司內部真正需要的是一個可以一起工作的角色,所以我們把她調成公司秘書和管理幕僚的混合:
- 要簡潔,但不能少掉判斷。
- 要專業,但不能官腔。
- 要主動查資料,但不能亂猜。
- 可以提醒風險,但不能製造焦慮。
- 給的是結果,不是她剛剛跑了哪些內部流程。
這些設定後來變成她的基礎行為,我們不是在訓練一個比較會講話的 AI,而是在定義一個能放進公司工作流的角色。
一個共享大腦,要有權限邊界
把 Dainy 從個人助理提升成公司共享腦之後,馬上遇到下一個問題,共享腦不代表所有人都能看所有資料,真正能在公司裡用的 AI 一定要有權限邊界,所以我們把每則 Slack 訊息的 sender 當成身份,誰在問就用誰的權限決定她能做什麼:
- 管理員:調設定、管排程、核准高風險操作。
- 主管:看跨部門摘要,但敏感內容仍受權限限制。
- 一般同仁:查自己部門與共用資料,也能請她整理文件、寫草稿、找資料。
- 外部或未知:只能使用低風險功能。
這一步很關鍵,企業 AI 最危險的不是答錯,而是把不該給的人看的資料講出去,或替不該操作的人做了操作。
公司 AI 要有資料來源順序
Dainy 回答公司問題時不能只靠模型記憶,公司裡有正式規則、會議決策、Notion 頁面、Drive 文件、Gmail 往來、Figma 設計、Slack 討論,這些來源一旦衝突她不能自己猜,所以我們幫她排了一條來源順序:
- 公司政策與權限規則優先。
- Notion 的公司指令、Workflows、Knowledge、Memory。
- Google Workspace、Gmail、Calendar。
- Figma 設計與 Slack 討論脈絡。
- 最後才是公開網路資料。
這讓她的回答不再只是合理推測,而是有來源、有查證、有邊界的公司回答。
工具接上後,它才變成操作層
當角色、權限、來源都穩定,工具才真正發揮價值,現在她可以在 Slack 接住需求,再去查 Notion、整理文件、讀信、看設計、查網頁、建頁面、更新排程、把大任務拆給子代理,於是她不只是回答問題,而是可以完成工作,例如:
- 每天整理市場追蹤,判斷哪些是競品動態、哪些只是重複新聞。
- 掃描 BD 信件,整理客戶線索與後續問題。
- 把 Slack 討論整理成 Notion 會議紀錄。
- 看 Figma 或截圖,整理成開發規格。
真正難的是持續調教
導入之後我們學到一件事,AI 助理不是設定一次就完成,它比較像一位新同事,剛加入時需要被糾正、被校準、被提醒什麼能做什麼不能做,我曾經讓她畫出線條交叉得像沒調教過的圖,這看起來只是美感問題,其實反映的是 AI 的產出不能只看有沒有做,還要看能不能真的拿去用,所以我們把每一次回饋都寫回工作規則,市場追蹤重複列出同一則新聞時,就把同一事件不同網址也算重複寫進排程,這些小修正累積起來,才是企業 AI 真正變好用的原因。
我們現在怎麼看 Dainy
現在的 Dainy 不只是 Slack 裡的一個 bot,更準確地說,她是 ARTOGO 內部的 AI 操作層,在 Slack 接住需求,用權限判斷身份,依公司來源查證,再透過工具完成整理、草稿、寫入、排程與通知,她還不完美,也不該被當成不會犯錯的系統,但她已經從可以聊天,走到可以被調教、被治理、被放進公司流程裡工作。
這是我們導入 AI 的第一個結論,企業 AI 的核心不是模型多強、也不是工具接多少,而是公司能不能把它調教成一個有角色、有權限、有來源、有驗證的工作夥伴,Dainy 只是第一步,但這一步已經讓我們看到公司 AI 共享大腦的雛形。