先把容易误解的地方讲透
- 先确认宿主上下文和权限边界。
- 先用标准库表和模板，不重复发明结构。
- 先按 OCR / ASR / 切片做务实多模态，不夸大原生理解。
- 先跑试点模块，不承诺一上来全系统覆盖。
FAQ
高频问题
先把最容易反复解释的内容固定下来，减少销售、实施和研发的重复口头沟通。智引是不是一个聊天插件？
不是。聊天只是接入形态之一。它更核心的定位是业务操作智能体内核，重点在权限感知、知识召回、步骤生成和结构化返回。
客户一定要单独建数据库吗？
更推荐单独数据库或至少单独 schema。这样知识、反馈、审计和会话记忆不会污染宿主核心业务库，后续迁移也更容易。
是不是每接一个软件都要重新设计一套库表？
不应该。正确做法是共用一套标准库表，只在 softwareId、tenantId、模块映射和知识资产上区分。真正变化大的部分放在适配器和映射层，而不是反复重画数据库。
为什么要做菜单映射和权限映射？
因为不同宿主系统的菜单编码和权限码完全不统一。没有映射，就无法把宿主上下文稳定转换成智引标准协议。
多模态是不是天然就需要一个很强的大模型？
不一定。一期更务实的路线通常是图像先 OCR、语音先转写、文档先切片，然后再进入 query 流程。真正原生多模态理解可以后续增强。
越用越聪明具体指什么？
当前更准确的说法是反馈驱动排序优化、回答策略调整和知识回流，而不是承诺自动训练出更强模型。
一个新客户多久能接入？
如果宿主权限上下文清楚、资料能及时提供，最小可用版本可以按 2 天接入流程推进。真正全模块上线则取决于文档质量和业务复杂度。
Reality Check
项目推进时最常被问到的现实问题
把这些问题说透，反而更容易建立正确预期。值不值得做
前提是宿主系统有权限模型、菜单结构和知识资料。如果这些都没有，项目会先卡在基础治理而不是 AI 本身。
实现难不难
一期 API、标准库表和前端入口不算难，真正难的是跨客户标准化、知识质量和长期运营闭环。
要不要自建模型
不必一开始就做自研大模型。更务实的路线是先把 OCR、ASR、检索、规则和接口编排做好，再逐步增强模型层。
多模态是不是必须重投入
不是。图像可先 OCR，语音可先 ASR，文档可先解析切片。一期先把输入编排打通，比上来追求原生多模态更稳。