01
客服与工单处理
典型问题
重复问题占用大量人力，复杂问题在转人工时上下文丢失，客户要重新描述一遍。
真正的难点
难点不在模型回答得好不好，在两件事：历史工单数据的质量（很多企业的工单记录本身就是残缺的），以及转人工的判断规则（什么情况必须转、转到谁）。
交付物
- 面向客服坐席的辅助应答系统，带出处引用
- 转人工的判断规则与上下文传递机制
- 基于真实工单的评测集与准确率报告
怎么算见效首次解决率、平均处理时长、转人工率、人工修正率。
行业场景
AI 落地在哪些环节最容易见效
我们不按行业讲故事。下面按场景类型拆开：解决什么问题、难点在哪、交付什么、怎么判断有没有效果。
先说什么样的场景值得做
同一家公司里，有的场景两周能上线，有的做一年也落不了地。差别通常不在技术难度，而在下面四个条件是否同时成立。
条件一
有明确的业务指标可改善
不是"想用 AI 提升效率"，而是"这个环节平均处理时长 12 分钟，希望降到 4 分钟以内"。指标说不清，验收就无从谈起。
条件二
数据拿得到、够用
解决这个问题所需的数据存在、能取出来、质量能支撑判断。这是最常见的隐性卡点，也是我们诊断阶段最先查的一项。
条件三
有真实使用者愿意参与
系统最终由具体的人使用。如果这些人从设计阶段就没参与，上线后大概率闲置 —— 这是 AI 项目失败最被低估的原因。
条件四
错了不会造成不可逆后果
适合先做的是"判断错了可以人工兜底"的环节。直接关系资金、安全与合规的关键决策，应当先做辅助而非替代。
六类常见场景
每一类都给出：典型问题、真正的难点、交付物、以及见效的判断方式。这些来自行业公开讨论与我们的项目经验，不涉及具体客户信息。
02
企业知识库问答
典型问题
知识散落在文档、Wiki、邮件、聊天记录里，新人上手慢，老员工被反复问同样的问题。
真正的难点
最大的难点是权限隔离：不同岗位、不同部门能看到的资料范围不一样。把权限做对之前，问答做得再准也不能上线。其次是知识本身的时效性 —— 过期文档比没有文档更危险。
交付物
- 带权限过滤的检索与问答系统
- 知识来源清单与时效标注机制
- 问题覆盖率报告（哪些问题系统答不了，为什么）
怎么算见效问题覆盖率、答案采纳率、人工介入率、新人上手周期。
03
文档与票据处理
典型问题
合同、订单、发票、检验报告靠人工逐条录入，慢且容易错。
真正的难点
难点在版式的不一致与例外情况。同一类单据在不同供应商那里格式不同，还会有手写、盖章遮挡、扫描倾斜。需要为"识别不出来"设计兜底流程，而不是假设百分之百准确。
交付物
- 结构化抽取系统，输出可校验的字段
- 置信度阈值与人工复核队列
- 准确率按字段拆分的评测报告
怎么算见效字段级准确率、人工复核比例、单张处理耗时、错误导致的返工量。
04
数据问答与分析
典型问题
业务人员想看数据只能提需求排队，数据团队被重复的取数需求占满。
真正的难点
难点不是把自然语言转成 SQL，而是口径统一：同一个"活跃客户"，销售、财务、运营的定义可能都不一样。口径不统一时，系统给出的数字没人敢用。
交付物
- 自然语言查询入口，带口径说明与查询过程可追溯
- 指标口径字典（这部分工作常被低估）
- 权限与数据范围的映射
怎么算见效取数需求的人工工单量下降幅度、查询结果被采纳的比例、口径争议数量。
05
跨系统流程自动化
典型问题
一件事要在三四个系统里重复录入，中间靠人工搬运和邮件确认。
真正的难点
难点在异常处理。正常的流程自动化很容易，麻烦的是某个系统临时不可用、某条数据不符合校验规则时怎么办。异常路径没设计好，自动化反而增加工作量。
交付物
- 自动化流程与异常处理规则
- 失败重试与人工接管机制
- 运行监控与告警
怎么算见效人工操作步骤数、端到端耗时、异常中断频率。
06
质量检测与设备预警
典型问题
质量异常靠事后抽检发现，设备故障造成非计划停机。
真正的难点
这类场景对数据基础的要求最高：传感器覆盖是否完整、采样频率是否够、历史故障样本是否标注。数据基础不具备时，任何模型都做不出效果 —— 这种情况我们会直接说明。
交付物
- 异常识别与预警模型
- 与现有工单或产线系统的对接
- 预警阈值调优与误报率评估
怎么算见效漏报率与误报率、提前预警时间、非计划停机时长。
行业侧重差异
同一类场景在不同行业里的卡点并不相同。以下是我们在沟通中反复遇到的差异。
制造业
存量系统多且老，接口常不开放；数据在车间与 IT 之间断层。适合从文档处理、质检辅助这类边界清楚的环节切入。
金融
合规与审计要求最高，任何自动化都需要留痕与可解释。适合先做辅助决策而非自动决策，且必须从一开始就设计审计日志。
医疗健康
数据敏感度高，通常要求私有化部署或在院内网络内运行。场景上适合从文书处理、病历结构化这类减轻事务负担的环节入手。
政务与公共事业
采购流程长，通常需要先入库或入围。对服务商的现场服务能力有明确要求，也在意交付后的持续运维。
零售与消费
数据量大但分散在多个渠道，口径统一是主要工作。适合从客服、商品内容生成、评价分析这类见效快的环节开始。
有几类场景我们通常建议不要做
数据基础不具备的预测类项目
没有足够的历史样本与标注，预测类模型做不出可用效果。这种情况我们会建议先补数据基础，而不是先做模型。
目标本身就是"上个 AI"的项目
如果立项原因是要有一个 AI 项目，而不是要改善某个具体指标，项目会很难验收。这类需求值得先把目标改写成业务指标。
直接替代关键决策的项目
涉及资金、安全、合规的最终决策，现阶段适合做辅助与提示，不适合无人复核的自动执行。这不是技术保守，是责任边界问题。
已有成熟产品完全覆盖的需求
标准化的需求买产品比定制开发更便宜也更快。这种我们会直接建议你去买产品，即使那不是我们的生意。
常见问题
你们做过哪些行业？
我们能公开讨论的行业经验集中在制造业、金融、医疗、政务与消费零售这几类的场景形态上。出于客户保密要求，我们没有可公开的具体案例 —— 这一点我们不做包装。你可以在诊断阶段要求我们说明同类场景的做法、遇到过的坑，以及哪些做法验证过无效。
我们的场景不在上面六类里，能做吗？
这份清单不是能力边界，只是常见形态。判断标准是前文那四个条件：指标明确、数据可用、有使用者参与、错了可兜底。四个条件都成立的新场景，同样可以做。
一个场景从开始到上线要多久？
诊断通常 1–2 周，试点 3–8 周，取决于存量系统数量与数据可用程度。数据不可用是最常见的延期原因，因此我们在诊断阶段会先查这一项，而不是等到开发阶段才发现。
能不能先做一个小范围试试？
这正是我们推荐的开始方式。固定范围试点就是把边界收窄到一个能验证的最小单元，效果达标再扩大。范围会在开始时冻结，验收标准提前约定。
你的场景在上面吗？
把具体情况讲一遍。我们会判断它是否满足那四个条件 —— 如果结论是不该做，我们会明确写出来。
contact@mail.kchangai.com