AI项目落地难在哪：需求不清与场景错配

做了几个企业级AI项目之后，一个反复出现的结论越来越清晰：技术选型很少是项目失败的主因，真正致命的是需求定义阶段就已经埋下的模糊性。 很多甲方在启动会上说“我们想做一个智能问答系统”，这句话听起来像需求，实际上只是一个愿望。它到可交付系统之间，隔着文档治理、场景验证、边界确认三道深坑。

本文从工程落地角度拆解这个问题的成因，并给出一套可复用的需求收敛方法。

一、“智能问答”四个字，至少对应五种系统

当甲方说“智能问答”时，可能指代完全不同的东西：

1. FAQ匹配型：预设问答对，用户提问后做相似度匹配返回答案。实现成本低，半天可出原型，但知识覆盖面受限于预设条目。
2. 文档检索增强型：将业务文档解析、切片、向量化，用户提问后检索相关片段并生成回答。适合知识密度高、更新频繁的场景。
3. 任务型对话：面向工单查询、设备状态查询等结构化操作，需要对接业务系统接口。
4. 多轮分析型：结合告警数据、日志做归因分析，输出结论而非原文摘录。
5. 语音交互型：在文字问答基础上叠加语音识别与合成，用于 Hands-free 场景。

这五类系统的技术栈、数据要求、验收标准完全不同。如果需求确认阶段不把这层歧义拆开，项目必然在中期返工。

二、第一个坑：文档治理被严重低估

以文档检索增强型系统为例，真正耗时的不是模型调用，而是把异构文档变成可用文本。

实际企业文档通常包含：PDF（含扫描件）、Word、Excel、图片、手写批注。其中扫描件没有文字层，需要 OCR；表格跨页合并单元格需要结构化还原；规程类文档有大量编号层级，切片时若按固定字数截断，会把一条完整规程拆成互不相关的片段。

一个典型的文档预处理流程如下：

# 示意性流程，非特定产品接口
def build_knowledge_base(docs):
    for doc in docs:
        if doc.is_scanned:
            text = ocr(doc)          # 扫描件走 OCR
        elif doc.is_pdf:
            text = extract_pdf(doc)  # 优先取文字层
        else:
            text = parse_office(doc)
        chunks = semantic_chunk(text)  # 按标题层级与语义边界切片
        index(chunks)

这段代码看起来简单，但 semantic_chunk 的策略直接决定召回质量。按固定 512 字符切片是最省事的做法，也是最容易在验收时被业务方挑出问题的做法——因为答案经常被切断。

工程建议：在需求确认阶段就要求甲方提供全量文档样本，先做一轮解析可行性评估，再承诺交付时间。 不要在没有看到扫描件比例的情况下报价。

三、第二个坑：使用场景没问清楚

原文提到的语音问答案例非常典型：功能本身不难，难的是部署环境。值班室有设备噪声、空调噪声、偶发报警声，语音识别准确率在这种条件下会显著下降。试了三个月后回退到文字方案，前期投入全部沉没。

这说明需求确认的问题清单不能停留在“你要什么功能”，而要下沉到：

• 谁用：值班员、调度员还是管理层？角色不同，查询深度不同。
• 在哪用：安静办公室、现场、噪声环境？环境决定输入模态可行性。
• 用什么设备：PC、移动端、大屏还是语音终端？设备决定交互设计。
• 什么时候用：日常查询还是应急场景？应急场景对响应时延和答案确定性要求更高。

把这四个维度问全，技术方案才不会在中期被推翻。

四、为什么项目容易滑向聊天机器人

原因很现实：聊天机器人是唯一能在两周内出 Demo 的形态。 它不需要文档治理，不需要对接业务系统，不需要定义验收指标。演示效果好，上线快，但两个月后用户发现除了问天气和写周报没有正经用途，投入产出比被质疑，预算被砍。

这不是聊天机器人的错，而是用 Demo 形态代替了需求分析。正确的做法是把聊天界面当作交互外壳，背后必须挂载明确的业务能力：知识检索、工单查询、告警归因。外壳可以快速交付，能力必须按需求逐项验收。

五、一套可复用的需求收敛方法

综合上述踩坑经验，建议在项目启动阶段执行三步：

第一步：文档先行。 先收全量文档样本，做解析成功率评估，输出《文档可治理性报告》。扫描件占比超过阈值时，先谈 OCR 投入再谈模型。

第二步：场景四问。 对每个候选功能，强制回答“谁、在哪、用什么设备、什么时机”四个问题。任何一个维度模糊，该功能不进入开发排期。

第三步：验收指标前置。 在开发前定义可量化指标，例如检索召回率、答案引用准确率、端到端响应时延。没有指标的模块不允许上线，避免“感觉能用”式的验收。

结语

企业AI落地的困难点，表面看是技术成熟度，实际是需求工程能力。把“智能问答”拆成五类系统、把文档治理计入工期、把使用场景问全、把验收指标前置，这四件事做到位，项目成功率会显著提升。技术方案可以迭代，需求定义一旦跑偏，返工成本远高于前期多花的那两周确认时间。