企业AI落地 · 场景选择 · 知识库
企业第一次上AI，别碰核心系统
第一批 AI 场景应该足够具体，可以单独上线，出了错也能及时退回人工。
第一批 AI 场景不必解决公司最宏大的问题。它应该足够具体，可以单独上线，出了错也能及时退回人工。
很多老板第一次规划 AI 项目，会下意识盯着公司最核心的地方。
生产系统能不能全部智能化？销售、客服和供应链能不能一起打通？能不能做一个全公司都能用的 Agent？
这些目标听起来够大，也最容易把第一个项目拖进泥里。
核心系统牵涉权限、接口、历史数据和大量例外。跨部门项目还要重新分配责任。模型效果尚未验证，组织问题先全部涌了进来。几个月后，团队开了很多会，却连“到底什么算成功”都没有说清楚。
企业第一次投入 AI，更适合找一块小而完整的业务闭环。
它不需要改造整个核心系统，不同时横跨多个部门，不依赖一堆没有接口的旧系统；可以单独上线，失败以后也不会影响核心业务。
沿着这套标准筛选，企业内部知识库通常会成为一个不错的起点。
第一个项目要有五道安全门
AI 场景能否快速看到结果，通常取决于项目边界，而不是演示效果。
我会先看五件事。
不动核心系统。
第一版尽量只读，不直接修改 ERP、CRM、生产控制或财务系统。需要的数据可以通过经过授权的文件、导出结果或只读接口获得。这样即使模型答错，也不会立刻变成生产事故。
先由一个部门负责。
试点要有明确的业务负责人，能提供资料、解释规则、判断答案是否正确。项目一开始就横跨销售、研发、客服和 IT，任何一个环节没有人拍板，进度都会停下来。
资料拿得到。
资料可取，要看项目启动时能否拿到有效版本、确认访问权限，并完成抽样检查。大量信息只存在老员工脑中时，要把知识整理单独列成工作，不能假装数据已经准备好了。
可以独立上线。
员工可以从一个独立入口使用，原来的工作方式仍然保留。试点有效再扩展，无效就停掉，不必先改造所有人的流程。
失败可以退回人工。
AI 回答不了、证据不足或碰到高风险问题时，系统应当明确拒答并转给原来的负责人。第一批场景不适合让模型直接执行不可逆操作。
这五项里，如果有两三项都无法满足，先不要急着开发。项目缺的可能是资料整理、责任人或接口条件，而不是更强的模型。
2023年的一个制造业项目：先做“内部客服”
2023 年，我们团队曾给一家制造企业做内部知识库。
当时的问题很常见。销售、对外客服、售后和研发掌握的信息并不一致。很多产品问题依靠微信和电话口口相传。销售在客户现场遇到问题，随时往群里问；研发和售后还有自己的工作，不可能一天到晚守着消息回复。
公司最初很容易想到对外智能客服，但我们没有从客户入口开始。
对外回复一旦出错，会直接影响客户承诺、报价和品牌。内部员工提问的风险相对可控，遇到不确定内容还可以继续找研发或售后确认。
所以第一步做的是“内部客服”。
我们把经过确认的产品资料放进知识库，让销售和客服先查询那些反复出现、答案明确的问题。知识库负责准备答案和出处，员工再决定如何回复客户。
这个范围看起来不大，却具备几个适合试点的条件：问题每天都在发生，重复工作很多，答案能回到产品资料核对，项目效果也可以观察。
研发和售后的重复响应有没有减少？销售得到第一条有效信息的时间有没有缩短？哪些问题仍然必须转人工？这些都能通过使用记录和抽样复核得到答案。
相比“建设企业级 AI 中台”，这样的试点不够宏大，却更容易形成一次完整的学习。
为什么知识库适合作为第一批场景
知识库还有一个经常被忽略的优势：任务边界比较稳定。
一次典型任务可以在很短的链路内结束：
员工提出问题 → 系统查找内部资料 → 返回带出处的答案 → 人工确认或纠错
这类任务不需要依赖一段无限增长的对话，员工也不必让系统记住昨天聊过什么。每次提问都可以围绕当前问题、当前身份和当前资料重新完成检索。
这里说的“不需要记住”，指业务回答不依赖长期对话记忆。为了审计、纠错和优化，系统仍然可以按权限保存查询记录、引用来源和反馈结果。
链路短，带来几个工程上的好处：
• 输入和输出容易定义；
• 错误能够回到原始文档检查；
• 员工不满意时可以直接转人工；
• 第一版不必连接所有业务系统；
• 每次修改都可以用固定问题重新测试。
这也是为什么内部知识问答通常比“全自动处理客户业务”更适合第一轮验证。前者先减少找资料和重复解释，后者还要同时解决身份、权限、动作执行与责任承担。
知识库最容易被做成“文件垃圾场”
场景简单，不等于把文件上传后就能结束。
很多企业把产品手册、会议纪要、制度文件和历史方案一起放进知识库。员工问一个问题，系统找出三个版本不同的答案。模型看起来回答完整，实际引用的资料已经过期。
一个能上线的内部知识库，至少要补齐下面几件事。
第一，明确资料负责人。谁决定哪份文件有效？产品改版以后，谁更新知识？
第二，保留版本和生效时间。答案要展示引用来源，员工能够点回原文，看到资料什么时候发布、适用于哪个产品版本。
第三，继承原有权限。销售能看的资料，不代表所有员工都能看；项目接入 AI 后，访问边界不能消失。
第四，建立拒答和转人工规则。找不到证据、资料冲突或问题涉及报价与质量责任时，系统应当停止猜测。
第五，把纠错留进系统。员工发现答案过期或引用错误，不能只在群里提醒一句。反馈要能回到文档负责人和评测问题集。
知识库的维护责任没有确定，系统上线那天就已经开始变旧。
上线前先记基线，上线后才知道有没有结果
企业 AI 项目常见的验收方式是开一次演示会。领导问几个准备好的问题，系统都答出来，项目就算成功。
演示只能证明系统能运行，无法证明它减少了工作。
试点开始前，可以先记录一段时间的现状：销售每天向研发和售后重复咨询多少次；从提问到获得有效答复要多久；哪些问题频率最高；哪些回答经常需要重新解释。
上线后再观察四类变化：
• 重复咨询是否减少；
• 获取第一条有效信息的时间是否缩短；
• 员工能否自行解决更多标准问题；
• 人工纠错集中在哪些资料和问题上。
这里不必提前承诺一个漂亮百分比。先定义数据怎么记录、谁负责复核、什么变化值得继续投入。试点结束时，企业才有依据决定扩充资料、增加用户，还是停止项目。
第一次落地，可以按四个阶段推进
先收窄问题。
只选择一个部门和一类高频问题。例如销售查询产品参数，不要同时把售后诊断、报价审批和研发知识全部塞进来。
再整理资料。
确定有效文档、版本、权限与负责人，准备一批真实问题和标准答案。资料冲突先由业务部门解决，不能交给模型投票。
然后小范围试用。
先让少数真实用户使用，保留原有咨询渠道。每次错误都记录来源、问题类型和人工修改，不要只改提示词。
最后按业务结果扩展。
如果重复咨询和响应时间出现稳定变化，再增加资料范围或使用人数。如果主要错误来自文档过期，先补维护机制；如果用户根本不愿用，先检查入口和流程。
扩展是试点的结果，不是项目启动时的前提。
企业第一次做AI，不要追求“一步到位”
企业当然可以有长期 AI 战略，也可以规划跨部门 Agent 和核心系统改造。可第一个项目承担的是另一项任务：让团队学会如何定义问题、准备数据、设置权限、处理错误并验证结果。
内部知识库适合起步，并非因为技术最简单，而是它容易收窄成一个每天发生、答案可以核对、失败能够人工接管的工作闭环。
第一个场景跑通以后，企业会获得比演示更有用的东西：一套真实的资料治理方式，一批经过验证的问题，明确的责任边界，以及员工愿不愿意使用 AI 的现场反馈。
这些能力准备好了，再去碰核心系统，风险会小很多。
你们公司每天反复发生、答案又能核对的那个问题是什么？它可能就是第一个 AI 场景。
完