简介：本文从真实企业AI项目经验出发，分析AI落地过程中最容易被低估的环节——需求确认与场景治理。文章梳理了“智能问答”等模糊需求背后的多种技术形态、文档工程陷阱、使用环境对方案的反向约束，并给出可执行的需求澄清方法与阶段化交付建议，帮助团队减少返工、降低项目失败风险。
做了三个企业级AI项目之后，我发现一个非常残酷但必须正视的事实：大多数项目失败，并不是因为模型效果不好，而是因为需求从一开始就没有被定义清楚。
这不是对甲方的贬低。事实上，在AI项目的早期阶段，“甲方不知道自己想要什么”是一种普遍现象，甚至可以说是正常状态。因为AI的能力边界、交付形态和传统软件系统存在很大差异，甲方往往只能用最熟悉的词来描述诉求，比如“智能问答”“智能分析”“像会聊天一样”。
而这类描述背后，可能对应着十种完全不同的系统形态、技术路线和交付成本。如果乙方在需求阶段没有把这些差异显性化，项目大概率会走向两个结果：要么最终交付一个最容易被接受的聊天机器人，要么在中途反复变更需求，导致预算和信心同步消耗。
本文基于真实的企业AI项目经历，系统拆解AI落地过程中最容易被忽视的困难点，并给出可执行的需求治理与交付建议。
“智能问答系统”是企业AI项目中最常见的需求描述之一。听起来非常明确，但实际执行时，这四个字至少可以指向以下几种完全不同的技术方案：
第一种：FAQ机器人。 基于预设问答对进行匹配，用户问什么，系统从知识库中查找最相近的问题并返回固定答案。技术实现简单，甚至可以在半天内完成原型。但它的理解能力非常有限，对未见过的问法几乎无能为力。
第二种：文档检索型知识库。 将企业内部文档经过解析、切片、向量化后，根据用户问题在文档内容中进行语义检索，并由大模型生成答案。这种方式能处理更开放的表达，但对文档质量和工程链路要求很高。
第三种：结构化数据查询。 用户通过自然语言查询数据库中的指标、工单、日志或台账数据，系统需要将自然语言转换成查询语句并返回结构化结果。这和文档检索完全是两条技术路线。
第四种：业务系统联动型助手。 不仅回答“是什么”，还要执行“做什么”，例如创建工单、发送通知、触发审批流。这要求AI系统与既有业务系统做深度集成。
第五种：语音交互终端。 在特定物理环境中，通过语音输入和语音输出完成问答，涉及语音识别、语音合成、降噪处理、设备部署等一系列额外问题。
当甲方说“我想要智能问答”时，他脑子里可能只浮现出第五种体验，却完全不了解背后是哪种技术形态在支撑。这个认知差，就是项目失控的起点。
即使确定了做“文档检索型知识库”，真正开始执行后，第一个让项目停滞的环节往往不是模型或算法，而是文档工程的复杂程度。
在一个电力行业项目中，甲方最初表示“把所有文档都放进去”。这句话听起来轻松，实际执行时却暴露出大量问题。
企业内部文档的格式极其分散。调度规程可能是PDF扫描件，继电保护手册是排版密集的Word文档，配网运维规范是Excel表格，设备说明书是图片夹杂文字的混合版式，检修报告甚至没有统一的模板。扫描件可能没有文字层，需要OCR识别；表格数据不能直接按段落切分；图表和公式如果处理不当，会严重干扰嵌入向量的质量。
仅仅是把这些文档转化为可用文本，就可能消耗数周时间。而甲方通常会感到困惑：“不就是把文件上传进去吗？为什么这么慢？”
这个认知差异的核心在于，甲方理解的“上传”是文件从本地复制到服务器，而乙方实际要做的是：格式解析、版面还原、OCR识别、表格提取、段落切分、元数据标注、向量化索引等一系列工程处理。任何一个环节做不到位，都会直接影响最终问答的准确率。
因此，在需求确认阶段，第一件该做的事情不是讨论功能菜单，而是让甲方把所有文档样本发过来。看完文档类型、格式分布、内容质量之后，再谈能做什么、不能做什么、需要多长时间。
另一个常见失误是：需求沟通围绕“功能”展开，却忽略了“使用场景”。而使用场景一旦变化，整个技术方案可能都需要推翻。
还是以电力行业为例。一个知识库问答系统在文字交互阶段测试良好，但甲方在测试阶段提出：“我们要在值班室加一个设备，值班员用语音提问，系统语音回答。”
从产品角度看，这只是一个交互方式的升级。但从技术角度看，这是完全不同的一套工程问题。
变电站值班室的环境噪声非常复杂：设备运行的低频噪声、空调风机的持续背景声、偶然出现的告警声、多人对话的交叉声音。在这种环境下做远场语音识别，准确率会显著下降。如果再加上专业术语密度高、发音相似词多，识别错误会进一步传导到下游的知识库检索环节，造成答案偏差。
试了相当长一段时间后，甲方最终决定暂时放弃语音方案，回到文字交互。这个过程的成本并不低，但本可以在需求阶段就被有效规避。
这里有一个非常实用的提问框架。做需求确认时，不要只问“你要什么功能”，而要问清楚五个W：
任何一个环节缺失，都可能让技术方案错位。比如在户外强光环境下，屏幕显示方案就比语音方案更不适用；在戴手套操作的环境中，触屏交互就需要重新设计。
很多企业AI项目最终都演变成了聊天机器人，这并不是因为聊天机器人是甲方真正需要的，而是因为它在项目推进中具有天然的“竞争优势”。
从演示效果看，聊天机器人最容易在短时间内做出可展示的界面。有了大模型支持，随便接入一个通用对话能力，就能让页面“动起来”。这会给决策者一种“项目在推进”的直观感受。
从开发成本看，聊天机器人的技术路线相对成熟，开箱即用的组件多，不需要深入理解业务系统，也不需要复杂的文档工程和系统集成。在中短期交付压力下，团队自然倾向于选择成本最低、见效最快的形态。
从验收逻辑看，聊天机器人可以用模糊的“像人一样对话”来掩盖很多不明确的需求。相比之下，“故障根因分析”“合同风险识别”“调度指令校验”这些真正的业务目标，验收标准却很难定义。如果没有人愿意在需求阶段把验收标准说清楚，项目只会滑向最容易交付的形式。
于是出现了典型现象：系统上线两个月后，用户除了问天气、写周报、聊天解闷之外，几乎没有沉淀任何有效业务价值。管理层看到投入产出比之后，砍预算就成了必然结果。
解决上述问题的关键，不是找一个更“懂AI”的甲方，而是在项目早期建立一套需求显性化机制。具体可以分为四个步骤。
第一步：文档盘点先行。 在签合同或项目启动阶段，就要求甲方提供全量文档或数据样本。不要接受“差不多”“各种都有”这类模糊描述。对每个文件类型做标记：格式、是否有文字层、表格密度、图片含量、更新频率。基于这些信息评估预处理工作量和知识库可行性。
第二步：场景走查代替需求访谈。 不要只坐在会议室里聊需求，要带着问题去真实的业务环境观察。用户在任何场景下的操作约束，都可能比需求文档上的一句话更关键。比如噪音环境对语音方案的影响、网络隔离对云端模型的限制、权限管控对数据上传的约束。
第三步：分级定义“智能”。 将甲方的模糊需求拆解为多个明确的智能等级，并用示例说明每个等级的输入、输出和边界。例如：
让甲方根据实际业务价值选择等级，而不是笼统地说“要智能一点”。
第四步：用小范围真实验证替代大范围承诺。 在技术合同或项目方案中设置一个“可验证的最小场景”。这个场景必须足够真实，同时范围可控。它可以是一个班组、一个工位、一类文档。跑通之后，再逐步扩展。这样才能避免“等到交付才发现不是要的东西”的被动局面。
企业AI项目落地的困难点，往往不是模型能力不够，而是需求本身没有被治理。模糊的“智能问答”可能掩盖多种截然不同的技术路线；被忽视的文档工程可能在项目中期消耗大量资源；未被问清的使用场景可能让已经完成七八成的系统面临推倒重来。
真正专业的做法，不是抱怨甲方不懂AI，而是在项目早期就把不可见的需求显性化，把模糊的期待拆解为可验证的交付物，把技术方案的边界诚实地摆到桌面上。这套能力，才是当前企业AI落地中最稀缺的部分。