AI项目落地难：需求迷雾与场景陷阱

一、现象：为什么AI项目总在“聊天机器人”上打转？

过去几年，大模型能力快速迭代，政策层面也在持续推动智能化应用。但一个尴尬的现实是：真正进入生产环境、产生可衡量业务价值的AI系统，比例依然很低。大量项目最终收敛成一个“能问天气、能写周报”的对话窗口，上线两个月后因投入产出比不佳被削减预算。

这不是技术单点的问题。经过多个企业级AI项目的实践，我发现一个关键矛盾：多数需求方并不清楚自己要什么，而技术团队又容易在模糊需求下选择“最省事”的路径。

当被问到“你想用AI做什么”时，最常见的回答是“像某个通用对话助手那样”。但具体到业务场景——是内部知识检索？是告警根因分析？是合同条款比对？还是工单自动分类？——往往没有明确答案。于是，技术团队倾向于选择演示最快、上线最早的方案：一个通用的聊天机器人。它看起来“什么都能做”，实际上在具体业务中什么都做不深。

二、根因分析：需求模糊如何一步步拖垮项目

2.1 “智能问答”四个字，可以指向十种不同系统

以电力行业某项目为例，初始需求是“智能问答系统”。听起来清晰，实则高度歧义。它可以被理解为：

• FAQ匹配型：预设问答对，用户提问后做相似度匹配，半天可上线；
• 文档检索型：将业务文档灌入索引，用户提问后返回相关段落；
• 结构化查询型：对接数据库或业务系统，将自然语言转为查询语句；
• 多轮任务型：支持上下文追问、条件筛选、流程引导；
• 语音交互型：在文字问答基础上叠加语音识别与合成。

不同理解对应完全不同的技术栈、数据准备量和交付周期。如果不在项目启动前对齐，后期必然出现“做完了说不是这个”的反复。

2.2 文档治理：被低估的“三周工作量”

当方向确定为文档检索型后，第一个技术障碍不是模型，而是文档解析与清洗。业务方提供的资料包括：调度规程、设备手册、运维规范、检修报告，格式涵盖PDF、Word、扫描件、Excel。其中扫描件没有文字层，必须引入OCR；PDF存在多栏排版、表格嵌套、页眉页脚干扰；Word版本混乱，同一文件存在多个修订版。

仅将这些材料转化为可检索的文本块，就耗费了三周。而需求方对此的预期是“上传文件即可”。这个认知差是项目延期的主要来源之一。

实践建议：在需求确认阶段，第一步不是讨论功能，而是要求业务方提供全量文档样本，由技术团队完成解析可行性评估。评估内容包括：

• 文件格式分布；
• 扫描件占比及清晰度；
• 表格与图文混排比例；
• 是否存在加密或权限限制；
• 更新频率与版本管理方式。

只有完成这一步，才能给出可靠的工期与效果预期。

2.3 场景错配：语音问答在变电站值班室的失败

第二个典型陷阱是使用场景未定义清楚。项目中期，业务方提出增加语音问答，要求在值班室部署设备，值班员通过语音提问并获得语音回答。

从技术组件看，语音识别加语音合成即可实现。但真实环境是：变电站值班室存在持续设备噪声、空调风声、偶发报警声。在这种信噪比条件下，通用语音识别准确率大幅下降。经过三个月现场测试，最终业务方主动放弃语音方案，回退到文字交互。

这个教训指向一个通用原则：需求确认时必须追问“谁、在什么环境、用什么设备、以什么方式使用”。功能列表只是表象，使用场景才决定技术方案的可行性边界。

三、方法论：从模糊需求到可交付系统的四步框架

3.1 场景锚定：用“用户-环境-任务”三元组替代功能列表

不要问“你要什么功能”，而是问：

• 谁使用？（岗位、角色、技能水平）
• 在什么环境下使用？（噪声、光照、网络条件、是否移动）
• 完成什么任务？（查询、比对、生成、审批、告警响应）
• 当前流程是什么？（人工步骤、耗时、错误率）
• 期望改善哪个指标？（时间、准确率、覆盖率）

将回答整理为场景卡片，每个卡片对应一个可验证的最小闭环。优先选择高频、规则明确、容错率适中的场景作为第一期目标。

3.2 数据可行性评估：先看数据，再谈模型

在确定场景后，立即评估所需数据的可获得性与质量。对于知识检索类场景，核心问题是：

• 文档总量与增量速度；
• 解析难度分布；
• 是否具备标注数据用于效果评估；
• 是否有权限分级需求。

如果数据准备成本过高，应果断调整场景范围，而不是强行推进。

3.3 技术方案分层：检索、生成与编排分离

一个稳健的企业AI系统通常包含三层：

1. 检索层：负责从结构化或非结构化数据中召回候选内容；
2. 生成层：负责基于召回结果生成自然语言回答或摘要；
3. 编排层：负责多轮对话管理、工具调用、权限校验与日志审计。

将这三层解耦，可以独立评估每一层的效果与瓶颈。例如，检索层可以用召回率和准确率衡量，生成层可以用事实一致性和可读性评估。避免将问题笼统归因于“模型不够强”。

3.4 迭代节奏：用可演示的最小闭环换取信任

不要追求一次性交付完整系统。建议以两周为一个迭代周期，每个周期交付一个可演示的最小闭环。例如：

• 第一周期：完成文档解析与索引构建，支持关键词检索；
• 第二周期：接入生成层，支持自然语言提问并返回引用来源；
• 第三周期：增加权限过滤与审计日志；
• 第四周期：根据真实用户反馈优化召回策略与回答格式。

每个周期结束时，与业务方共同验证效果，及时调整方向。这种节奏可以避免“六个月后才发现方向错了”的灾难。

四、总结：AI落地的核心挑战不在模型，而在需求工程

回顾多个项目的成败，技术问题往往不是最致命的。真正拖垮项目的是：

• 需求方无法准确描述业务场景；
• 技术团队在模糊需求下选择最简路径；
• 文档与数据治理成本被严重低估；
• 使用环境与交互方式未在方案设计前确认。

解决这些问题的关键，是将AI项目当作需求工程与数据工程问题来对待，而非单纯的模型选型问题。只有在场景、数据、交互三个维度都完成对齐后，技术能力才能转化为可衡量的业务价值。