失败一：方案先行
先有产品或模型结论，再按结论设计访谈提纲，访谈中只记录支持结论的说法。这样做出来的诊断等于给方案找证据，错误方向不会被否定，原型阶段往往返工。预算随之沉没，团队也会怀疑诊断方法本身的价值。
失败二：访谈对象错位
只访谈信息中心或管理层，拿不到一线真正在用的表格、例外处理和口头规则。诊断需要的恰恰是这些非标准动作，缺了它们，流程图画得再整齐也落不了地，方案推下去就卡住，最后还是要回头补访谈，时间更紧。
失败三：没有现状基线
诊断要能回答改之前是多少。缺少工时、差错率、返工次数这类基线时，任何改进都无法验证，评审时也说不清收益来自哪里。建议在诊断期就用一周抽样记录基线，而不是等上线后再补，补出来的数字往往已经失真。
失败四：跳过数据核验
在会议桌上确认系统里有数据，却没有抽样看字段、缺失率和导出权限。等到原型阶段才发现关键字段为空或口径不一，工期与信心一起崩。核验要看真实导出文件，不看截图，也不看别人整理好的汇总表。
失败五：结论没有出口
报告只写现状与建议，不写做不做、先做哪个、什么条件下停。没有决策出口的诊断会被归档，资源投向也不会改变。合格结论应包含优先级、责任人、停止条件，以及下一轮复核的时间点，缺任何一项都会让结论悬在空中。
适用与不适用
适合谁
- 有多个 AI 候选场景、需要先排优先级的企业
- 上一轮项目效果不佳、想弄清原因的业务负责人
- 准备立项、但还说不清验收口径与数据条件的团队
不适合谁
- 已确定采购某产品、只需要实施排期的项目
- 没有业务负责人参与、仅由 IT 部门推动的诊断
典型场景
某集团信息中心收到六个部门的 AI 需求，从合同审查到排产预测都有。诊断组用两周访谈一线与财务，把每条需求还原成具体任务和现状基线，再按价值与可行性打分。最终只留两个场景进入原型，其余四个写明暂缓理由，避免了一次性铺开。
可执行步骤
- 先写一页诊断章程，明确目标、范围、不做什么以及最终决策人，并请对方当场确认
- 按岗位名单排访谈，让一线操作岗与管理层各占一半时间，并留出整理时间
- 索取真实导出文件，逐项核验字段含义、缺失率与访问权限，记录抽样结论
- 为每个候选场景补一条现状基线与可量化的改进目标，写进同一张表，留档备查
- 开决策会，逐场景给出做、缓、不做的结论并由业务负责人签认，同步记入会议纪要
常见坑
- 访谈提纲由服务商单方拟定，问题围绕自家产品能力展开，客户真正的痛点被跳过，诊断随即变成产品介绍。
- 把部门负责人的口头承诺当作需求确认，人员一变动就无人认账，项目只能重来，书面确认与上级背书缺一不可。
- 诊断期就索要报价与方案，深度让位于商务，结论朝着能签单的方向倾斜，客户拿到的其实是售前材料。
- 只访谈总部，忽略分公司与现场班组的差异，方案在一线根本执行不下去，试点首周就会收到大量例外反馈。
自检与验收清单
- 诊断章程与不做什么清单是否已双方签字，可查
- 访谈名单是否覆盖一线操作岗、现场班组与财务
- 是否用真实导出文件核验过字段含义与缺失率
- 每个候选场景是否都有可复现的现状基线与目标
- 结论是否写明优先级、责任人与停止条件，可直接执行
常见问题
诊断要花多长时间？
单场景通常两到三周，多场景排队则四到六周，取决于关键岗位能否按约访时间出席。排期时把数据核验与法务评审并行，能省下一到两周，前提是这两条线各有明确负责人。
诊断报告要多厚？
厚度不是标准，能支撑决策才是。建议正文控制在二十页内，把场景评分表、现状基线、数据缺口与停止条件放在前面，访谈记录放附录，方便决策人直接看结论而不是翻材料。
能不能跳过诊断直接做原型？
可以，前提是场景单一、验收口径清楚、样本可获取。若需求来自多个部门且彼此冲突，跳过诊断会把分歧带进开发，返工成本通常高于一次诊断，也会消耗业务方的耐心，这一点常被忽略。