夜雨聆风AI SCENARIO NOTE
AI 场景建设，业务部门不能饭来张口
企业做 AI，不是技术部门端出一道菜，业务部门点头试吃。真正能跑起来的场景，必须从业务现场长出来。
很多企业推进 AI 场景时，会出现一个很常见的错位。
业务部门说：我们这里也想用 AI，能不能帮我们做一个？
技术部门问：具体想解决什么问题？有什么数据？怎么判断效果？哪些情况不能出错？
业务部门又说：你们不是懂 AI 吗？你们先做一个出来，我们看看。
再往后，就容易变成一句话需求丢给技术部门，业务部门当甩手掌柜，最后只负责验收。
这不是务实的场景开发态度，更像是在许愿。它的问题不在于谁态度不好，而在于大家对 AI 场景建设的理解不一样。
核心判断
AI 场景不是技术部门凭空做出来的。业务部门如果只给一句话需求，然后甩手验收，最后大概率只能得到一个演示。
FIGURE 01
一个 AI 场景真正需要什么
业务问题
不是一句“提高效率”，而是具体到哪个岗位、哪个流程、哪个动作卡住了。
原始流程
没有 AI 之前，这件事怎么做，谁在做，哪里耗时，哪里容易出错。
业务样本
要有真实材料、真实案例、历史结果、常见异常，而不是只给一个概念。
判断规则
什么算对，什么算错，哪些结果可以接受，哪些结果必须人工确认。
实现分级
哪些环节能很快做，哪些值得攻坚，哪些现在暂时不要承诺。
持续反馈
第一次做出来不是结束。业务部门要持续试、持续指出问题、持续修正边界。
01 AI 不是万能外包
很多业务部门对 AI 的期待，其实有点像外包。
我告诉你我要什么，你们技术部门负责做出来。做得好，我用；做得不好，你们再改。
如果再极端一点，就是业务部门给一句话需求，后面基本不参与，只等着最后验收。这种方式做传统系统都容易变形，做 AI 场景更容易失控。
传统系统建设里，这种方式已经很容易出问题。到了 AI 场景里，问题会更明显。
因为 AI 场景不是只实现几个按钮，也不是只把页面做出来。它要理解业务材料、处理模糊输入、输出可被业务接受的结果，还要知道什么时候不能直接给答案。
这些东西，技术部门不可能凭空猜出来。技术部门懂模型、平台和系统，但业务部门才知道现场到底怎么运转。
AI 场景建设里，技术部门可以做能力，但不能替业务部门定义业务。
02 业务要先讲清楚问题
业务部门参与 AI 场景建设，第一件事不是提需求，而是讲清楚问题。
“我们想做智能助手”，这不是问题。
“客服每天要查十几个系统才能回答一个客户问题，其中有三类问题最耗时间，而且容易回答不一致”，这才开始接近问题。
“我们想做知识库”，也不是问题。
“一线人员找制度要问老员工，历史项目经验散在群聊和文档里，新人经常按旧版本执行”，这才是问题。
更进一步，业务部门还要把没有 AI 之前的流程讲透。原来谁接收信息，谁判断，谁查询资料，谁复核，谁对外输出，哪一步最耗时间，哪一步最容易出错。
这些信息看起来琐碎，但它们决定了 AI 到底该插在哪个位置。AI 不是凭空替代一整条流程，而是先进入那些最清楚、最重复、最容易验证的环节。
AI 要解决的是具体场景里的摩擦，不是一个听起来很正确的名词。
业务问题越清楚，AI 场景越容易做实。
如果业务部门自己也说不清楚卡在哪里，技术部门做出来的东西只能停在通用能力展示。
03 样本比口头描述更重要
AI 场景最怕只有口头描述，没有真实样本。
业务部门说：“我们这里有很多材料，需要 AI 帮忙整理。”
这句话对技术团队帮助有限。
真正有用的是：拿出十份典型材料，标出来哪些信息有价值，过去人工怎么处理，最后希望输出成什么样，哪些错误不能接受。
业务部门不用写代码，但必须提供业务样本。
没有样本，技术团队只能凭理解做。凭理解做出来的东西，演示时可能过得去，一进真实工作就会露出问题。
业务样本是 AI 场景的原材料。没有原材料，就不要指望技术部门端出一桌菜。
04 先把实现分级
业务流程讲清楚以后，技术部门要做的不是照单全收，而是做可行性评估。
一个场景里，通常会同时存在三类事情。
第一类，是 AI 很快就能做的。比如资料摘要、字段提取、格式整理、初稿生成、相似案例检索。这类环节适合先做，快速让业务部门看到变化。
第二类，是可以啃一啃的硬骨头。比如复杂规则判断、多系统联动、长流程任务执行、结果可信度评估。这类事情不是不能做，但要拆阶段，不能一口气承诺到生产可用。
第三类，是当前暂时不要做的。比如业务规则本身还没统一，数据没有稳定来源，责任边界没人愿意承担，或者一旦出错影响太大。
这一步很重要。AI 场景建设不能靠热情推进，也不能靠一句“技术上想想办法”。能快做的先做，值得攻坚的拆开做，暂时不能做的先放下。这样项目才不会一开始就被过高预期拖垮。
业务部门讲清楚流程，技术部门讲清楚可行性。
这两个动作接上以后，AI 场景才会从“大家都觉得可以试试”，变成“知道先从哪里做”。
05 验收不能只说好不好用
业务部门还要参与定义效果。
很多 AI 场景做到后面会卡在一句话上：感觉不太好用。
这句话很真实，但不够可执行。
哪里不好用？答案不准，还是格式不对？速度太慢，还是引用不清楚？是覆盖不了长尾问题，还是关键问题不能稳定处理？
业务部门必须把“好不好用”拆成可以判断的标准。
比如准确率、召回率、人工复核比例、处理时长、问题覆盖范围、可追溯来源、不能自动处理时的转人工规则。这些标准不一定一开始就很完美，但必须有。
没有效果标准，AI 场景就会变成反复试感觉。试到最后，谁都说不清楚到底差在哪里。
06 反馈不是挑毛病
AI 场景建设里，第一次做出来的结果，通常都不会完美。
这很正常。
真正重要的是，业务部门能不能持续反馈。
不是简单说“这个不行”，而是指出具体问题：哪类问题答错了，哪份材料没识别出来，哪个字段提取错了，哪种情况必须人工确认，哪个输出格式不适合现场使用。
反馈越具体，技术团队越容易改。反馈越停留在感觉，场景越容易停在演示阶段。
业务部门不能把反馈当成额外负担。对 AI 场景来说，反馈本身就是建设的一部分。
写在最后
企业做 AI 场景，不能变成技术部门单方面端菜。
业务部门也不能饭来张口，只说我要一个 AI，然后等别人把结果做好。
真正能跑起来的场景，一定是业务和技术一起做出来的。业务讲清楚原来的流程、耗时的环节、真实的样本和判断标准；技术判断哪些能快做，哪些值得攻坚，哪些现在还不能做。
这个过程不会一次成型。它需要业务部门持续试、持续反馈，也需要技术部门不断调整方案、修正边界。
AI 场景不是许愿许出来的，而是在业务和技术之间一点点磨出来的。