企业已经积累了客户、销售机会和跟进记录，接入 AI 不应意味着推翻正在运行的 CRM。真正的工作在于：让 AI 通过受控接口理解业务问题，并取得可核验的结果。
先确定系统边界，而不是先选择模型
存量 CRM 通常包含客户、销售机会、联系人、跟进日志、组织架构和审批流程。这些表的数据口径未必一致，人员权限还可能由部门、岗位、负责关系共同决定。AI 层不宜直接拥有数据库管理员权限，更不应绕过原系统的授权链。
- 明确一期场景：例如查询本人负责的待跟进客户、按周汇总团队销售活动，而不是一次性承诺“什么都能问”。
- 确定数据新鲜度：是否允许查询延迟、历史快照和缓存，哪些指标必须实时读取。
- 判断数据来源：优先使用稳定的业务 API；没有 API 时，再评估只读视图或经过治理的查询服务。
一种实用的分层结构
用户 / CRM 页面 / 内部助手
↓ 身份与会话
API 网关（鉴权、限流、审计）
↓
业务语义层（客户、机会、跟进、指标口径）
↓ ↘
受控工具 / 查询服务 AI 编排与自然语言理解
↓ ↙
CRM API / 只读数据视图 / 报表服务
↓
有来源、时间范围和权限说明的结果模型适合识别意图、补齐缺失条件、解释结果；精确的金额、计数、百分比与状态统计应交由确定性服务计算。对于“本月新增客户多少个”这类问题，必须先定义“新增”的业务日期字段、排除规则、时区与组织范围。
六个可交付的工程步骤
- 业务盘点：列出目标角色、典型问题、源数据与验收示例，先解决最有价值的少数问题。
- 语义建模：为“客户”“有效跟进”“成交”等定义统一口径，把表关系封装成受控查询能力。
- 权限接入：复用可信登录身份，工具服务端校验用户的数据范围，而非要求模型自行遵守。
- 工具编排：对只读查询建立白名单；发送消息、修改数据等操作采用单独授权与人工确认。
- 结果核验：输出来源、统计区间、条件；对关键数值构建可重复的校验用例。
- 上线与维护：建立错误率、响应时间、成本、审计日志和变更回滚机制。
PoC 验收时应该测什么
| 验收维度 | 建议验证方法 |
|---|---|
| 正确性 | 准备独立计算的标准答案，检查数值、日期范围、过滤条件。 |
| 权限 | 分别使用不同组织、岗位和数据拥有者账号验证越权不会发生。 |
| 稳定性 | 检查字段缺失、接口超时、重复请求、空结果和异常重试。 |
| 可解释性 | 对结果给出依据与查询条件，不确定时明确提示。 |
| 可维护性 | 业务规则变更后，能更新配置或查询服务并回归验证。 |
适合从哪里开始
对于已有 CRM 的团队，优先试点“角色权限内的客户跟进查询 + 每周摘要报告”通常比全量开放数据和工具更容易验收。之后再考虑跨系统关联、复杂任务与自动化执行。