做了这么多年政企数字化项目，有一个现象反复出现：AI项目出问题，很少是技术本身扛不住，更多是启动那一刻就没把“要解决什么”说清楚。老板在办公会上提了一句“我们也要上AI”，业务部门跟着兴奋，供应商拿着通用方案来宣讲，需求文档洋洋洒洒几十页，真到开发阶段才发现——谁每天在用、错了谁兜底、上线后拿什么指标判断成败，这三个问题一个都答不上来。

政企AI项目启动前，先过立项、数据、流程、验收四道关

需求调研不是走过场的填表环节。它本质上是一次“把技术愿望翻译成业务约束”的过程，翻译得粗，后面全是返工。下面这份清单，按立项、数据、流程、验收四个板块拆开，每一块都对应几个必须在开工前拿到明确答案的问题。不复杂，但漏一个，项目就多一道暗坎。

一、立项关：先分清“功能愿望”和“业务问题”

“做一个AI助手”“建一个知识库”“上智能体”——这些说法可以开启讨论，但不能直接变成项目范围。同样的“知识助手”，服务对象是窗口人员还是后台审批岗，数据范围、权限设计、验收口径完全不同。立项阶段最怕的不是需求少，而是需求停在名词层面，没人往下追一步。

清单上至少要问到这几条：

这件事现在谁在做，每天做多少次？ 不是问“AI能做什么”，而是问“没有AI的时候，这条流程怎么走、卡在哪、一次耗多久”。频次决定价值规模，也决定样本量够不够跑出一个可靠的东西。一天处理一千次的工单分类，和一年碰不上几回的重大决策辅助，技术路线和投入量级不在一个维度上。

业务负责人是谁，验收时谁签字？ 政企项目里，找不到业务Owner的场景，立项建议先缓一缓。信息化部门可以推动项目，但判断“输出结果能不能进入实际业务环节”的，必须是真正用它的那条线的人。没有这个角色，后面所有关于“准不准”“好不好用”的争论都会悬空。

这一版明确不做什么？ 需求规格里“非目标”和“目标”同样重要。不写清楚“不处理哪类问题、不对哪类输出负责、哪些动作仍然保留人工”，开发就没有边界，验收也没有底线。

这一关过不了，后面数据再干净、模型再先进，也很难落到一个能持续运行的业务闭环里。

数据调研要落到字段级：谁负责、怎么更新、什么权限、谁来评测

二、数据关：系统里有，不等于AI能用

数据是需求调研里最容易被高估的部分。打开后台一看，几年的工单、文档、日志都在，感觉“燃料充足”。真拉出来一跑，字段缺失、格式不统一、同一件事十几种写法、历史数据里混着测试记录，才是常态。有调研显示，超过六成的企业把“数据基础薄弱”列在AI落地挑战的第一位。

清单上要落到具体条目：

每个数据源有没有明确的Owner、版本和更新机制？ “连公司数据库”不是需求。要问到字段级：哪些数据进，哪些明确不进；制度文件挂在系统里的是最新版还是三个版本同时在跑；设备编码在几个系统里能不能对上。没有Owner的数据，用起来就是一次性消耗品，项目上线之日就是它开始过期的时候。

权限和敏感等级定清楚了没有？ 政企场景下，AI能“看到”什么，和谁能“用”它看到什么，必须分开回答。哪些内容可以进提示词、哪些只能在脱敏后进入、日志里什么字段必须遮掉，这些不在调研阶段定下来，上线前再做就是返工级别的改造。

业务专家有没有时间参与答案评测？ 数据“能用”和“好用”之间差着一道人工判断。模型输出对不对，最终要由懂业务的人来裁定。调研阶段就要确认：谁能抽时间做评测集、谁来标注“对”和“不对”的标准。如果全靠项目组临时找人凑答案，验收时的争议会远远多于共识。

流程调研别只照SOP走，要把高频例外和权责边界问出来

三、流程关：把例外场景问出来，别只照着SOP走

流程调研最常见的失误，是拿着标准操作手册问一遍，就以为摸清了。真实的业务运转中，大量动作发生在SOP之外——复制粘贴、私人表格记录、群里吼一声确认、遇到边界情况凭经验绕过去。AI项目真正容易翻车的地方，往往不在主流程，而在例外场景。

清单上要有这一条硬要求：让实际执行的人打开真实系统，从头到尾走一遍最近发生的案例。 不要只看流程图，看他在哪一步停下来翻文件、在哪一步找人确认、哪一步把数据从A系统搬到B系统。这些“笨动作”里藏着需求调研真正有价值的信息。

同时追问：最常见的五种例外是什么？ 字段缺失、政策版本冲突、权限不够、系统超时、身份对不上——这些例外决定了第一版的范围应该收到多窄。很多项目启动时想把所有分支都覆盖，结果第一版铺得太开，每一个场景都只做到半成品。更务实的做法是：第一版只跑通一个主场景加两三个高频例外，把闭环走完，再迭代。

还有一个判断值得放在流程关里：这条流程里，哪一步是“信息搬运”，哪一步是“规则判断”，哪一步是“权责决定”？ 信息搬运和规则判断适合交给AI提效，权责决定必须留在人手里。分不清这三类动作，就会把不该自动化的东西推给模型，把该由系统高效处理的事情留给人去耗。

验收标准拆到功能、质量、安全、运营四层，项目交接才落得下去

四、验收关：不能只写“准确率不低于90%”

验收标准写到“准确率90%”就结束，几乎是政企AI项目里最常见的合同隐患。准确率本身没有错，问题在于：谁来判断“准确”？样本从哪里来？边界情况算不算？一个政策问答场景，有标准答案的题目能测准确率，但窗口人员遇到的真实问题里，大量是跨条款、带前置条件、需要结合具体材料的，这些不在测试集里，90%的数字就只是一个纸面安慰。

验收清单建议拆成四层来写：

功能层：流程能不能走完，出错时看不看得见。 不是“系统能不能生成答案”，而是“答案生成之后，有没有路径进入下一个动作；生成不了的时候，用户知不知道该怎么办”。

质量层：输出达不达标，异常能不能人工接管。 质量指标要和具体场景绑定。缩短检索时间，就测检索时间；降低返工，就测返工率。同时必须写清楚：什么情况下系统应该拒答、什么情况下必须转人工、人工接管的入口在哪里。

安全层：权限、日志、数据保留和审计过不过。 政企项目的验收，安全不是加分项，是准入项。操作能不能追溯、越权访问能不能拦住、数据到期能不能清理，这些在调研阶段就要作为验收条目写进去，而不是等上线前再做安全测试。

运营层：上线之后谁负责升级、故障和成本。 一个AI系统交付之后，模型会迭代、数据会过期、业务规则会变。验收时不回答“谁维护、怎么升级、用量成本谁监控”，交接就只是把一套需要持续喂养的系统放在那里，等它慢慢静默失效。

回到一个判断：需求调研做扎实，比选对模型更省钱

政企AI项目走到今天，模型能力之间的差距在缩小，真正拉开交付质量的，是启动之前那几周有没有把问题问到位。清单的价值不在于填满一张表，而在于让业务方和技术方在动手之前，对“做成什么样算成”有一个共同的、可检验的答案。

武汉启创动力数字科技从2017年开始深耕政企数字化赛道，依托自主研发的“灵枢”AI智能体PaaS平台，在政务咨询、企业知识库、AI办公助手和数据处理等场景中，形成了从需求梳理、知识库构建到私有化部署和运维的完整交付路径。在实际项目推进中，团队把需求调研作为开发启动的前置关卡：业务Owner不明确的不进入设计，数据权限和评测责任人没有落定的不进入开发，验收条目不能追溯到具体业务场景的不进入交付。这套做法并不复杂，但它让项目在开始的时候就少了一些“先做出来再说”的冒险。

如果你正在梳理一个政企AI项目的需求，不妨先把上面四关的问题过一遍。清单不需要长，但每一个问题背后，都对应着后面某个可能返工的地方。把调研做在前面，后面省下来的，远不止一轮开发的成本。