選型難的不是比功能表，是先想清楚哪些限制是硬的、哪些只是聽起來重要
選型最常見的失敗方式，是先看一圈功能表，然後發現最想要的那家過不了合規評審。順序反了。
正確的順序是先回答三個問題，它們和功能無關，但會直接砍掉大部分候選：
這三個問題答完，候選通常只剩一到兩條路線。剩下的工作才是比功能。
下面 6 個維度，前 3 個是「能不能用」，後 3 個是「用起來貴不貴」。建議每個維度按 1-5 分打分，並給硬限制維度設一票否決。
問的是「員工在哪裡用到它」。可選形態包括：獨立網頁／App、嵌入現有 IM、嵌入現有 OA／簽核流程、開放 API 供其他系統呼叫。
評估要點：接入現有 IM 通常須要平台側的應用建立與回呼設定權限，這部分權限往往不在 IT 手上，要提前確認誰能開。如果只支援獨立網頁，等於要求員工改工作習慣，這是最難的一步。
問的是「能不能換模型、能不能混用」。有三種典型形態：只能用它內建的模型；可以設定 API Key 接自己的模型；可以本地載入開源模型。
評估要點：模型迭代很快，今天最強的模型半年後可能不是。鎖定單一模型的產品，半年後你可能要為它整個換掉。至少要確認「換模型要不要改業務程式碼」。
問的是「資料在哪裡、經過誰」。要問清楚四件事：請求發往哪裡；有沒有留存；留存多久；能不能關閉留存。
評估要點：很多方案寫「不用於訓練」，但沒說「留存多久」。這兩件事是分開的。合規評審時，稽核方通常要的是留存策略和刪除機制，而不只是一句承諾。
問的是「誰問了什麼、能看什麼」。企業場景和消費級場景最大的差別在這裡：同一個知識庫，業務和財務能看到的範圍不一樣。
評估要點：至少要確認三點——能不能按人／部門隔離知識範圍；能不能記錄誰在什麼時候問了什麼；日誌能不能匯出給稽核。第三點經常被忽略，出事時才發現查不了。
問的是「上線之後誰在管」。包括：模型更新誰做、知識庫更新誰做、壞了誰修、擴容誰買機器。
評估要點：把這三類成本分開算——一次性投入（部署／整合）、週期性投入（模型與知識庫維護）、突發投入（故障與擴容）。SaaS 方案把前兩項壓得很低，但第三項（資料合規引發的整改）可能很高；私有化方案反過來。
問的是「不想用了怎麼辦」。這是最少被評估、事後最貴的一項。
評估要點：知識庫能不能匯出成通用格式；對話歷史能不能匯出；接入的 IM 應用能不能乾淨地下線；有沒有資料被鎖在對方格式裡的風險。建議在合約裡就寫明匯出格式和匯出方式，而不是等要換的時候再談。
把上面 6 個維度套到三條常見路線上，大致是這樣：
| 維度 | 自研 | SaaS 託管 | 私有化平台 |
|---|---|---|---|
| 接入方式 | 完全自由，但要自己寫 | 通常只支援獨立網頁／App | 可接 IM／OA，需平台權限 |
| 模型自由 | 完全自由 | 基本鎖定廠商模型 | 可換、可混用、可本地 |
| 資料邊界 | 完全可控 | 資料出內網，依賴廠商策略 | 資料不出內網 |
| 權限與稽核 | 要自己實作 | 依廠商提供的粒度 | 可按組織架構自訂 |
| 維運成本 | 最高，需專職團隊 | 最低，開箱即用 | 中等，需基礎維運能力 |
| 退出成本 | 低（都是自己的） | 高（資料在對方格式裡） | 中（可匯出，但要搬遷） |
| 適合 | 有研發團隊、需求高度特殊 | 無合規硬限制、要快速試用 | 資料不能出內網、要接現有 IM |
須要說明的是，「私有化平台」這一列寫的是能力上限，實際能不能達到取決於產品實作。選型時要讓廠商示範具體動作，而不是看宣傳頁：比如當場示範「換一個模型須要改幾行設定」「匯出一份知識庫給我看格式」。
下面 10 個問題，答「是」的題號決定你的路線。建議拉上 IT、法務／合規、業務三方一起答——這三方對同一道題的答案經常不一致，不一致的地方就是選型風險點。
| # | 問題 | 答「是」的含義 |
|---|---|---|
| 1 | 業務資料不允許出公司內網？ | 排除純 SaaS |
| 2 | 員工日常在飛書／企微／釘釘裡工作？ | 必須具備 IM 接入能力 |
| 3 | 有稽核或合規部門會定期檢查？ | 權限與日誌匯出是硬性要求 |
| 4 | 不同部門能看到的知識範圍不同？ | 須要按組織架構隔離 |
| 5 | 半年內可能換模型？ | 模型必須可替換 |
| 6 | IT 團隊少於 3 人且不懂模型部署？ | 私有化維運成本要額外評估 |
| 7 | 希望 2 週內看到效果？ | 傾向 SaaS 或託管式私有化 |
| 8 | 有研發團隊能持續投入？ | 自研可行，但仍要算維護成本 |
| 9 | 未來可能因為政策或成本換方案？ | 退出成本必須寫進合約 |
| 10 | 知識庫內容會頻繁更新？ | 更新流程要自動化，不能靠人肉 |
如果第 1、3、4 題都答「是」，基本可以確定要私有化或混合路線；如果只有第 7 題答「是」，先上 SaaS 試用是更省時間的做法。
功能表上每家都有「知識庫」「多輪對話」「權限管理」。真正的差別在限制上：資料在哪、能不能匯出、壞了誰修。
「支援企業微信」可能只是「能把訊息轉發過去」，而不是「能在企微裡完成問答、帶權限、帶稽核」。
上線時匯入 200 份文件很容易，難的是三個月後制度改了，誰去更新、多久更新一次。
不用於訓練 ≠ 不留存 ≠ 可刪除。這三件事要分別確認，並寫進合約。
選型時沒人想「將來怎麼換掉」，但真到要換的時候，資料匯不出來是最貴的坑。
選型這件事，方法比結論重要。同一套限制在不同公司會指向不同路線，所以本文不給「哪家最好」的答案——那須要結合你們自己的資料邊界、組織架構和 IT 能力。
如果只能記一句話：先用硬限制砍候選，再用維度打分，最後用自評表確認。順序對了，選型會快很多。