上線失敗的原因，很少是模型不夠聰明
過去兩年，很多公司試過 AI 助手，結果大體相似：第一週大家很興奮，第三週用得少了，第三個月只剩幾個人偶爾問一句。
複盤下來，原因幾乎都不是「模型答得不夠好」。真正讓專案停在那兒的是另外一些問題：員工要裝一個新 App 才能用；IT 不知道誰在問什麼；財務的規章制度和全員手冊混在一個知識庫裡；出了問題查不到是誰、什麼時候、動了什麼。
下面這六件事，是落地過程中反覆出現的卡點。每件事我都會說清楚「卡在哪」和「通常怎麼解」。
這是決定使用率的第一道關，也是最多專案栽跟頭的地方。
如果 AI 助手是一個獨立的網頁或 App，就等於要求員工改變工作習慣——上班先打開飛書，再打開另一個視窗問 AI。聽起來只是多一步，實際上多數人三個月內就不會再打開了。
更現實的做法是讓助手長在員工本來就在用的聊天工具裡。員工在飛書、企業微信、釘釘、微信、QQ、Teams 或 WhatsApp 裡像 @ 一個同事那樣 @ 它，問制度、要材料、讓它整理表格。不用裝新軟體，也不用改習慣。
對 IT 來說，這意味著後台要能完成各平台的綁定配置：掃碼綁定飛書/企微/微信，配置 QQ 機器人、Teams 機器人、WhatsApp 機器人號碼等。綁定一次，全公司可用。
「能聊天」和「能幹活」是兩件事。員工真正需要的是後者。
舉個例子：銷售說「把上週客戶會議紀要整理成跟進要點，順便起草一封感謝郵件」。這句話背後包含讀檔案、理解內容、寫新檔案三個動作。只會聊天的助手會給你一段建議文字；能動手的助手會真的把檔案寫出來。
這類能力通常包括：寫文件、執行命令、上網查資料並核對、記住你的偏好。最後一項容易被低估——問過一次的事，下次不用再教，這是「越用越順手」的來源。
但「能動手」也意味著風險。所以每做一步都應該留痕：做了什麼、動了哪個檔案，事後能一條一條回看。這是第六件事要解決的問題，也是 IT 敢放開權限的前提。
企業知識庫和「把文件丟給 AI」的區別，全在邊界上。
最基礎的能力是：員工手冊、報銷制度、IT 規範這些文件上傳後自動切分、建立索引，幾分鐘就能用。員工問「年假怎麼請」，助手先查知識庫再答，每條關鍵資訊標註出處，找不到就明確說沒有——不拿通用答案冒充公司規定。
但真正在企業裡跑起來，還需要一層部門維度。比如客服部有一套話術手冊，可見範圍應該鎖定在客服部；財務規章只給相關部門看。知識庫按部門各建各的，跟組織架構對齊，這比「一個大庫所有人共用」實用得多。
再往上一層，是把文件裡的概念關係整理出來——制度條款、系統名稱、流程節點之間的關聯，檢索時優先匹配相關上下文，複雜問題答得更準。
同一個助手，銷售和研發需要的功能不一樣。全開或全關都不合適。
常見的做法是「技能」——把「怎麼辦一件事」的步驟存成模板。比如報銷怎麼走、新人怎麼入職、客訴怎麼安撫。業務專家可以在後台把成熟流程打包成技能；員工聊完一輪有價值的對話，助手也能把步驟整理成技能初稿，管理員過目後上線。
技能按部門分配：報銷規章給財務和全員查，程式規範只給研發。後台還能對常用命令做全域啟停——哪些命令對員工開放，管理員一鍵控制。
另外，企業內部系統可以透過標準協議接入（MCP），每台伺服器的啟停、哪些 Agent 能載入哪些遠端工具，都能在後台按部門分別管控。這解決了「接得越多、越難管」的問題。
AI 助手的價值上限，取決於它能碰到多少真實數據。
只讀公司文件的助手，回答永遠停留在「網上標準答案」的水準。能對接制度庫、工單系統、內部資料庫的助手，答起來才像熟悉業務的同事。
接入方式上，現在比較通行的做法是走標準協議（如 MCP），把內部系統包裝成一組工具供助手呼叫。好處是接入方式統一、可複用，不用每個系統各寫一套對接。管理側則要能統一看到有哪些接入、各自狀態如何、誰能用。
這部分通常由 IT 配置，員工無感——他們只是在聊天框裡問問題，背後呼叫了哪些系統不需要知道。
這是最容易被跳過、事後最貴的一件事。
企業場景和消費級場景最大的差別在這裡：不是「能不能用」，而是「出事時能不能說清楚」。至少要能回答三個問題——誰在什麼時候問了什麼；助手做了什麼、動了哪些檔案；某個操作能不能追溯到具體的人。
配套的還有成本可見性：每一次模型呼叫都有用量記錄，成本花在哪兒清清楚楚；以及問題閉環——助手呼叫工具失敗、權限不夠、環境異常時，能主動上報到管理後台，員工也可以對不滿意的回答點回饋，兩邊一起定位。
權限層面同樣要分清：角色不同，能做的事就不同。研發能在本機專案裡動程式，財務只能查制度——越權的事做不了，這是敢全公司推廣的前提。
把上面六件事做成一份清單，上線前逐條確認：
| # | 檢查項 | 達標標準 |
|---|---|---|
| 1 | 員工入口 | 至少在員工日常使用的 IM 裡可用，不需要裝新軟體 |
| 2 | 動手能力 | 能寫檔案、執行命令、查資料，且每一步可回看 |
| 3 | 知識邊界 | 可按部門隔離，答案帶出處，找不到會說沒有 |
| 4 | 能力分配 | 技能與命令可按部門啟停，不是全開或全關 |
| 5 | 系統接入 | 內部系統走標準方式接入，後台統一管理 |
| 6 | 可追溯 | 操作有日誌、成本有記錄、問題有上報通道 |
這六項裡，第 1 項和第 6 項最常被低估。前者決定有沒有人用，後者決定敢不敢放開用。
這六件事在不同行業長什麼樣？官網的使用場景頁按電商客服、企業辦公、零售門店、技術研發、倉儲物流五類做了拆解，可以對照自己部門的業務看。
最後說一句部署。上面六件事的能力，和部署在哪沒有直接關係，但數據邊界有。
常見三種形態：雲端部署（最快上線，數據在服務商側）、混合部署（核心數據在內網，部分能力用雲）、全本地部署（數據一步不出門）。選哪種取決於你們的合規要求——如果業務數據不允許出內網，那就只剩後兩種。
三種形態對應的硬體配置、網路與合規細節，官網的部署方案頁按團隊規模給了參考配置，可以直接對號入座。
需要提醒的是，全本地部署要額外算一筆運維成本：模型更新誰做、知識庫更新誰做、擴容誰買機器。這筆帳經常被漏算。
AI Agent 落地這件事，方法比選型重要。同一套方法在不同公司會指向不同配置，所以本文不給「哪家最好」的答案。
如果只能記一句話：先解決員工在哪兒用、出事能不能查這兩頭，中間的四件事才有意義。