上線只是開始，使用率才是驗收標準
「上線三個月，日活只剩個位數」——這是企業 AI 專案最常見的結局，也是最容易被誤讀的一個。常見的歸因是「員工不習慣用 AI」「大家還是喜歡問同事」，聽起來合理，實際上掩蓋了真正的工程問題。
把使用率拆開看，它其實是一個乘法：
使用率 = 入口便利度 × 單次有用率 × 可做的事的範圍 × 知道它能做什麼的人佔比四個因子任意一個接近零，整體就接近零。而大多數專案只優化了其中一項（通常是「模型答得好不好」），另外三項從來沒被當成指標看過。
下面把最常見的五個原因拆開講，每個都說清楚「症狀是什麼」和「怎麼改」。
症狀：後台數據顯示綁定人數不少，但日活很低；問一圈發現大家都說「知道有這個東西，就是沒打開過」。
如果 AI 助手是一個獨立網頁或獨立 App，你實際上是在要求員工改變工作習慣：本來在飛書裡跟同事說一句話就能解決的事，現在要先切到瀏覽器、登入、再提問。多出來的這幾步，在企業場景裡幾乎等於勸退。
怎麼改：讓助手長在員工本來就在用的聊天工具裡。飛書、企業微信、釘釘、微信、QQ、Teams、WhatsApp 都可以作為入口，員工像 @ 同事一樣 @ 它。管理側要能完成各平台的綁定：掃碼綁定飛書/企微/微信，配置 QQ 機器人、Teams 機器人、WhatsApp 機器人號碼等，綁定一次全公司可用。
一個可驗證的判據：從員工產生疑問，到他把問題發出去，中間需要幾次點擊？超過 3 次就該重做入口。
症狀：試用期大家問得很熱鬧，兩週後沒人問了。翻聊天記錄會發現，問題集中在「今天天氣」「幫我寫首詩」這類沒有業務價值的內容。
原因是：當助手只能給建議、不能真的把事做完時，員工試兩次就得出結論——「還不如我自己做快」。真正能提升使用率的是能動手的能力：讀檔案、寫文件、執行命令、上網查資料並核對、記住個人偏好。比如「把上週客戶會議紀要整理成跟進要點，順便起草一封感謝郵件」，只會聊天的助手回你一段建議，能動手的助手直接把檔案寫出來。
怎麼改：先找出你們公司裡「重複發生、步驟固定、有明確產出物」的三件事（例如週報彙總、客戶跟進記錄整理、制度問答），把這三件事做成可執行的技能模板。別一開始就追求全能，先讓員工在真實任務上感受到「它真的把活幹了」。
症狀：員工問「年假怎麼請」，助手答的是《勞動法》通用條款，而不是公司自己的請假流程；問「報銷標準」，答的是「一般企業通常……」。
這類回答會迅速摧毀信任。員工第一次發現答案跟公司實際規定不符，之後就不會再問了——而且會告訴同事別問。
怎麼改：把公司自己的文件接進去，讓助手先查知識庫再回答，並且每條關鍵資訊標註出處；找不到就明確說沒有，不拿通用答案冒充公司規定。文件上傳後自動切分、建立索引，通常幾分鐘就能用。
再往上一層是部門維度：客服部的話術手冊可見範圍鎖定在客服部，財務規章只給相關部門看，知識庫按部門各建各的、跟組織架構對齊。這樣員工問出來的答案才是「我們部門的規定」，而不是「網上的說法」。
症狀：所有能力預設關閉，員工問什麼都是「抱歉，我沒有權限」；或者反過來，一開始全開、出了小事故後一刀切全關。
這兩種極端都會殺死使用率。全關的狀態下，員工無法形成任何正向體驗；全關之後的一刀切，會讓之前累積的使用習慣一起消失。
怎麼改：按崗位發能力，而不是全開或全關。做法是把「怎麼辦一件事」的步驟存成技能模板，按部門分配——報銷規章給財務和全員查，程式規範只給研發；後台對常用命令做全域啟停，哪些命令對員工開放由管理員一鍵控制。內部系統透過標準協議（如 MCP）接入，每台伺服器的啟停、哪些 Agent 能載入哪些遠端工具，都能按部門分別管控。
同時把「可追溯」補齊：誰在什麼時候問了什麼、助手做了什麼、動了哪些檔案，都能回看。這是 IT 敢放開權限的前提，也是使用率能上去的前提——權限和使用率是一起漲的，不是先後關係。
症狀：日活不高，但每次做演示的時候大家都很興奮；演示完過兩天又回到原樣。
這是最容易被忽略的一個原因：員工不是不想用，是不知道「在什麼場景下該用它」。企業內部沒有形成具體的使用場景描述，助手就只是一個「聽說過但想不起來用」的工具。
怎麼改：把能力翻譯成崗位語言，而不是功能清單。不要發「我們上線了 AI 助手，支援知識庫問答與檔案操作」這種通知；要發「銷售同事：把上週的客戶會議紀要丟給它，它會整理成跟進要點並起草感謝郵件」這種場景卡片。
有效做法通常有三條：
使用率低的時候，最常見的錯誤是立刻開始改功能。正確順序是先量出問題在哪一環，再動手。下面這套流程 7 天可以跑完，不需要額外系統。
從後台拉四組數：綁定人數、近 7 天活躍人數、人均提問次數、提問內容分佈。重點不是總量，而是分佈——如果提問集中在少數幾個人身上，說明是「種子使用者在用、其他人沒進來」；如果提問集中在無業務價值的內容上，說明是能力或場景問題。
把使用者分成三類：活躍使用者（每週用 3 次以上）、嘗鮮使用者（用過 1-2 次就停）、未使用使用者（綁定但從未提問）。三類人的問題完全不同，混在一起看會得出錯誤結論。
每類各找 3-5 人，只問：①你上次想用它是什么時候？②當時為什麼沒用？③如果它能替你做完一件事，你希望是哪件？不要問「你覺得這個產品怎麼樣」——得到的只會是客氣話。
把訪談結果對回上面五個原因。經驗上，「嘗鮮使用者」流失大多是原因一或原因二（入口麻煩、能力太弱）；「未使用使用者」大多卡在原因五（不知道能做什麼）；「活躍使用者抱怨」通常是原因三或原因四（答案不準、權限不夠）。
挑影響面最大的一環改，改完盯兩週的活躍人數曲線。一次改多項，最後無法判斷哪一項起了作用。
診斷完進入執行階段，下面這份清單按週排，可以直接拿去用：
| 週次 | 動作 | 完成判據 |
|---|---|---|
| 第 1 週 | 入口收口：至少在員工日常使用的 IM 裡可用，不需要裝新軟體 | 新員工從入職到第一次提問 ≤ 3 次點擊 |
| 第 1 週 | 知識接入：公司制度、流程、手冊上傳並建立索引 | 抽查 10 個高頻問題，答案與公司規定一致且帶出處 |
| 第 2 週 | 場景卡片：每個部門 3 張，寫清「什麼時候用 + 怎麼問」 | 每個部門至少 1 人在群裡按卡片提問並得到可用結果 |
| 第 2 週 | 種子使用者：每部門 1-2 人，先在真實任務上跑通 | 種子使用者每週主動使用 ≥ 3 次 |
| 第 3 週 | 能力按崗位發：技能與命令按部門啟停，不是全開或全關 | 至少 3 個部門有各自專屬技能 |
| 第 3 週 | 可追溯：操作日誌、成本記錄、問題上報通道就位 | 能回答「上週誰讓它動過哪些檔案」 |
| 第 4 週 | 複盤：把有價值的對話沉澱成技能，下架沒人用的技能 | 技能數量淨增，且每個技能近 7 天有呼叫 |
這份清單裡，第 1 週的兩項是地基。入口沒解決，後面所有推廣動作都是在給一個沒人打開的工具做宣傳；知識沒接入，第一次提問就會消耗掉員工的信任。
最後給一份自評表，10 題，每題 1 分，低於 6 分建議先別做推廣動作，回去補地基层：
| # | 自評項 | 達標標準 |
|---|---|---|
| 1 | 入口 | 在員工日常使用的 IM 裡可直接提問，無需安裝新軟體 |
| 2 | 首次體驗 | 新員工 5 分鐘內能獨立完成一次有效提問 |
| 3 | 動手能力 | 至少 3 件真實任務能由助手產出可用檔案 |
| 4 | 知識準確度 | 抽查 10 個制度類問題，答案與公司規定一致 |
| 5 | 出處標註 | 關鍵答案能指出依據來自哪份文件 |
| 6 | 部門隔離 | 不同部門看到的知識範圍不同 |
| 7 | 權限分級 | 不同崗位能做的事不同，且不是全關 |
| 8 | 可追溯 | 能查到誰在什麼時候讓它做了什麼 |
| 9 | 場景認知 | 隨機抽 5 名員工，至少 4 人能說出一個使用場景 |
| 10 | 種子使用者 | 每個主要部門至少有 1 人每週使用 ≥ 3 次 |
第 9 題特別值得單獨看。它測的不是產品能力，而是「員工腦子裡有沒有這個工具的位置」——這一項不過，其他九項再好，使用率也上不去。
AI 助手的使用率問題，本質上是產品與組織的問題，不是模型的問題。換一個更聰明的模型，不會讓員工多打開一次；把入口放對、把公司知識接上、把能力按崗位發下去、把場景講清楚，才會。
如果只能記一句話：使用率是設計出來的，不是推廣出來的。