选型难的不是比功能表，是先想清楚哪些约束是硬的、哪些只是听起来重要
选型最常见的失败方式，是先看一圈功能表，然后发现最想要的那家过不了合规评审。顺序反了。
正确的顺序是先回答三个问题，它们和功能无关，但会直接砍掉大部分候选：
这三个问题答完，候选通常只剩一到两条路线。剩下的工作才是比功能。
下面 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 能力。
如果只能记一句话：先用硬约束砍候选，再用维度打分，最后用自评表确认。顺序对了，选型会快很多。