我們怎麼把 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 共享大腦的雛形。