上线失败的原因，很少是模型不够聪明
过去两年，很多公司试过 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 落地这件事，方法比选型重要。同一套方法在不同公司会指向不同配置，所以本文不给「哪家最好」的答案。
如果只能记一句话：先解决员工在哪儿用、出事能不能查这两头，中间的四件事才有意义。