第一步：说成事实
访谈不要从想要什么功能开始，而要先问现状怎么做的、多久一次、卡在哪、错了谁承担。把这些写成可核对的事实，才能判断是流程问题、数据问题还是确实需要模型。凭一句想上 AI 就立项，后面几乎必然返工。
第二步：拆到可验收
把业务问题拆成具体任务：输入是什么、输出是什么、谁判定对错、允许多少偏差。拆不到这一步，需求就还停在愿望层面。任务清单也是后面选型与报价的基础，拆得越清，方案越好比较。
第三步：核条件与风险
逐项核对数据是否可得、系统能否对接、权限与合规是否允许、业务方是否愿意承担复核。风险要写成具体的失败情形与影响，而不是笼统的高中低。条件不满足时，诊断结论应明确说不建议做。
第四步：给选项而非答案
至少给出三条路径：小范围试点、采购成熟产品、暂缓并先做数据治理，并写清各自的前提、代价与不做的后果。只给一个方案，决策者无法比较；给三个又都不写代价，等于把判断推回给领导。
第五步：落成立项口径
诊断报告结尾要能直接用于立项：范围、验收条件、所需角色、风险与不做清单。口径写清，后续报价与排期才有共同基准。诊断不是写一份漂亮的行业分析，而是让决策者敢在立项单上签字。
适用与不适用
适合谁
- 准备立项但说不清要做什么的企业
- 已多次试点失败、需要重新梳理需求的团队
不适合谁
- 需求已明确、只差开发排期的项目
- 希望诊断直接给出采购清单的诉求
典型场景
某企业的客服部门提出要上 AI。诊断访谈发现，真正的问题是知识分散在三个系统、答复口径不一致。团队把需求改写为同一问题的答复口径统一，并拆成知识归并与答复复核两个任务，最终建议先做知识治理，模型接入放到下一阶段。
可执行步骤
- 访谈业务方，逐条记录现状、发生频率、卡点与出错责任
- 把问题拆成有输入、输出与判定标准的任务清单，并逐条编号
- 逐项核对数据可得性、系统能否对接、权限与合规四项条件
- 给出三条候选路径，并写明各自前提、代价与不做的后果
- 把结论写成可直接用于立项的范围、验收口径与不做清单
常见坑
- 从功能清单开始访谈，收集到一堆想要，却没人说得清现状究竟怎么跑，方案无法验证。
- 只给一个方案，决策者无从比较，立项会上反复追问细节，项目在过去一个月里原地打转。
- 风险只写高中低，没有具体失败情形与影响，等出问题时才发现没人想过怎么应对。
自检与验收清单
- 问题是否已写成可核对的事实、频次与责任
- 任务是否有输入输出、判定标准与判定人
- 条件与风险是否逐项核对并留下记录
- 是否给出三种路径并写明前提与代价
常见问题
诊断要多久？
取决于业务范围与访谈对象数量，单场景通常以周为单位，跨部门要多轮。时间主要花在核对事实与确认口径上，而不是写报告。压缩到一两天，往往只能得到一份正确却无法执行的结论。
结论能是不建议做吗？
能，而且应该。若数据不可得、责任人不明或收益无法验证，明确说不做比勉强立项更负责。结论要写清在什么条件下可以重启，让业务方知道努力方向，而不是简单否决。
内部自己做诊断可以吗？
可以，但要注意立场。内部团队往往难以质疑既有的立项意图，也容易漏掉跨部门条件。折中做法是内部主导、外部做一次独立复核，重点看任务拆解与验收条件是否站得住。