老板在会上说："客服回复太慢，能不能上个AI？"
第二天，项目群建起来了。
有人研究大模型，有人整理知识库，有人讨论RAG和Agent，还有人约了三家供应商来演示。会议开得很热闹，方案写了几十页，预算也很快有了数字。
只有一个问题没人追问：客服为什么慢？
这个问题没答清楚，后面的技术路线越完整，项目跑偏得越远。企业最后很可能花了几十万，买到一个回复更快的"传声筒"，原来的堵点仍在原地。
"回复太慢"没有资格直接进入技术方案
客户等了两小时才收到回复，后台记录看起来都一样。走到现场，可能会遇到四种完全不同的情况。
- 客户消息分散在多个渠道，值班人员根本没看见；
- 客服要在五六个系统里来回查产品、订单和售后政策；
- 产品组合复杂，新员工看到了资料，也无法判断该用哪条规则；
- 退款、补偿和特殊报价都要审批，客服没有权限给出明确答复。
第一种情况需要消息聚合和任务分配。第二种情况需要数据连接与权限治理。第三种情况可以引入知识检索和AI辅助判断。第四种情况要改审批链和授权边界。
四种病因共用一个表面症状。直接把"回复慢"翻译成"智能客服"，相当于医生只听见病人说头疼，就开出同一张处方。
*图：回复慢可能来自消息、资料、判断或审批，技术方案完全不同。*
很多AI需求，只是业务焦虑换了一个技术名字
这种错位在企业里很常见。
老板说销售能力差，需求文档里出现"销售Agent"；老板说公司知识没有沉淀，方案变成"企业知识库"；老板说员工效率低，项目目标变成"给每个岗位配AI助手"。
听起来都有对应产品，落到日常工作却不知道从哪里下手。
"销售能力差"至少要继续拆：销售不会识别客户需求，还是不会推荐产品？不会处理异议，还是不会判断跟进时机？客户线索质量差、产品定价没有竞争力，也会表现成成交率低。
如果这些判断点没有拆开，销售Agent能做的多半是从一堆话术里拼出一段顺滑回复。文字质量提高了，销售决策没有变化。
知识库也会遇到同样的尴尬。
不少企业把制度、产品资料、会议纪要一股脑放进系统。员工提问后，AI同时找出五份答案：一份已经过期，一份仅适用于华东区，一份是会议讨论稿，两份互相冲突。
文档数量从来不能代表知识已经可用。系统还需要知道哪份当前有效、适用条件是什么、谁能查看、冲突时听谁的、答错后由谁复核。缺少这些规则，检索速度越快，错误信息传播得越快。
AI会把流程里的含糊批量复制
一套模糊流程在公司里可能运行很多年。
老员工知道哪些制度只写在纸面上，遇到哪类客户要找谁通融，哪份表格里的字段不能全信。新人靠口口相传慢慢补齐这些隐性规则。
接入AI以后，公司希望系统稳定、批量、自动地执行。可AI拿到的只有互相冲突的文件、不完整的数据和没人说清楚的例外。
它不会替企业补完责任边界。它只会以更高速度重复现有的模糊。有时输出还很流畅，让错误更难被发现。
模型选型解决不了这类问题。参数再大，也无法替业务负责人决定退款权限；推理再强，也无法判断两份制度谁具有最终效力。
能落地的项目，从一个"业务判断点"开始
企业项目需要把镜头拉近。
不要从"做一个销售Agent"出发，改为观察销售在某个时刻要做的判断：首次沟通后，他要判断客户属于哪类、需求优先级多高、应该推荐哪款产品、下一步安排演示还是继续培育。
判断点确定后，项目团队才知道要准备什么。
- 输入数据来自CRM、通话记录还是订单系统；
- 业务规则由谁提供，多久更新一次；
- AI给建议、生成草稿、触发提醒，还是可以执行动作；
- 哪些情况必须转人工；
- 谁验收结果，错误如何纠正和追溯。
*图：场景、判断、数据、动作和验收缺一段，项目都容易在交付时暴露空白。*
这条链路把一个漂亮的AI设想变成可测试的业务任务。技术团队也能据此判断是否需要知识库、工作流、Agent，或者只需一个普通规则引擎。
立项会上，连续追问这五件事
一个项目值不值得进入开发，可以用五个问题过一遍。
**谁在什么业务环节遇到了问题？**
"销售效率低"太宽。要写到具体岗位、动作和时点，例如"客户经理完成首次访谈后，无法在当天确定跟进策略"。
**他现在依据什么信息作出判断？**
把数据源、制度、经验和隐性规则列出来。信息拿不到、版本不可信或无权访问，都要在立项前暴露。
**这个判断影响什么业务结果？**
结果可以是响应时长、一次解决率、报价准确率或库存风险。没有可观察结果，验收只能靠"感觉挺智能"。
**AI在流程里做什么？**
建议、提醒、起草和执行对应不同风险。涉及发消息、改订单、调价格或写回系统时，应设置明确权限、人工确认和回读验证。
**AI出错后，谁负责发现和纠正？**
没有负责人、异常入口和审计记录，系统上线后只会出现一场熟悉的争论：业务说AI不准，技术说数据有问题，供应商说需求变了。
用一句话检查你的AI项目
拿出准备立项的项目，试着补完这句话：
当【某个岗位】处于【某个业务环节】时，系统根据【数据与规则】，帮助他作出【具体判断】，触发【明确动作】，最后由【责任人】验收结果。
例如：
当售后客服收到退款咨询时，系统根据有效售后政策、订单状态和客户等级，判断是否满足退款条件，生成回复草稿并标注引用来源，由客服确认后发送。
当客户经理完成首次沟通时，系统根据CRM资料、访谈纪要和产品准入规则，判断客户优先级并推荐下一步动作，由销售主管抽检建议与实际推进结果。
当员工查询差旅制度时，系统只检索其权限范围内当前生效的正式文件，返回答案和来源；发现文件冲突时停止作答，转交制度负责人处理。
一句话写不完整，项目还停留在愿望阶段。此时采购模型、搭建知识库或开发Agent，只会把尚未定义的空白交给技术团队猜。
预算批准前，再看六个验收项
立项材料至少应留下这六项：
1. 一个具体岗位与业务场景；
2. 一个可观察、可记录的判断节点；
3. 已确认的数据来源、权限和有效期；
4. AI动作的边界与转人工条件；
5. 明确的业务指标与测试样本；
6. 对结果负责的人，以及错误修正记录。
六项里如果有一半写着"后续再定"，开发越早启动，返工成本越高。
企业AI项目最昂贵的失败，并非系统无法运行。演示可能很顺，页面也很漂亮，模型甚至能给出令人惊讶的回答。上线几个月后，业务人员依旧绕过它，因为系统从头到尾都没有碰到那个让工作卡住的判断。
下一次有人说"这里上个AI"，会议室里最有价值的回应不是模型名称。
把流程画出来，找到谁在何时做不了哪个决定。问题写对以后，AI才有机会带来可验收的结果。