先看样本，不看表数量
让业务方导出近三到六个月的原始记录，含成功与失败两类，抽样检查关键字段是否为空、口径是否一致。数据量再大，没有可判断的结论字段也评不出准确率，只能凭感觉讨论效果，结论也无法复核。
知识资料要能机读
制度、话术、评审意见分散在扫描件与个人电脑里时，先做一轮整理：统一命名、标注版本与责任人、清掉过期文件。否则后续检索会把旧口径当成现行规定，回答越自信反而越危险，检索时也没有版本依据。
系统能力决定形态
有只读接口与数据库账号，可以做实时调用；只能定期导出，就设计批量处理与人工触发。诊断阶段不必追求实时，但要把导出频率、字段范围与责任人写清楚，避免方案建立在假设之上，接口一变就要重做。
身份与权限是前置
组织架构能否同步、角色如何划分，决定检索时要过滤哪些文档。权限体系缺失时，先按部门建最小可用分组，别等系统上线再补，否则越权访问会在第一次试用时就出现，补权限往往要等到第二次评审。
合规问题提前问
样本里是否含个人信息、能否放到外部环境处理、模型服务条款是否允许留存数据，这些答案会直接改变技术路线。诊断报告应把合规结论单列一节，由客户方法务或安全人员确认，而不是留到实施阶段。
适用与不适用
适合谁
- 正在评估某场景是否具备数据条件的企业
- 数据分散在多个系统、需要先摸清家底的团队
- 准备把业务资料整理成知识库的部门
不适合谁
- 数据尚未电子化、也没有整理计划的单位
- 要求诊断阶段就给出系统架构详图的团队
典型场景
某零售企业想评估门店巡检问答能否上线。诊断组抽取近三个月巡检记录，发现描述字段大量为空，只有结论字段可用；又调取制度文件，发现三个版本并存。团队据此把方案从问答改为按检查项结构化录入，先补数据再谈模型。
可执行步骤
- 列出每个候选场景需要的最小字段清单，并标出可用于判定的结论字段
- 抽取近三个月的真实记录，统计字段缺失率与不同部门之间的口径差异
- 核对系统导出能力、可导出字段范围、导出频率与账号权限申请周期，并指定对接人
- 把个人信息、数据出境与外部环境处理的问题整理成清单，交法务确认，书面留档
- 在报告中标出硬门槛与可过渡项，写明补齐责任人与时限，并约定复核时间
常见坑
- 只统计表的数量与存储容量，不看字段含义与填充情况，评估结论与实际可用性严重脱节，方案容易建在空字段上。
- 拿测试环境的少量样例当依据，正式数据缺失严重，直到原型阶段才发现，此时改方案的成本已经很高。
- 忽视权限与组织架构，检索把无权文档一并召回，直接触发合规事件，评审阶段被一票否决，事后很难补救。
- 把合规判断留到实施阶段，技术路线已经定型才发现数据不能出内网，只能推倒重来，前期投入全部沉没。
自检与验收清单
- 每个场景是否有最小字段清单与结论字段，可逐条核对
- 样本是否覆盖失败案例与异常月份，且包含难例
- 知识资料是否有版本号、生效日期与责任人，可追溯
- 导出频率与账号权限是否书面确认，并有书面签字
- 合规结论是否单列成节并由法务或安全签认，有人负责
常见问题
没有任何历史数据能做诊断吗？
可以做，但结论只能是先补数据。此时诊断重点转为设计记录模板与采集流程，明确由谁在什么节点录入，通常需要先跑一段人工流程，再谈模型，周期也会拉长，这一点要提前说明。
数据在内网不能出，还能做原型吗？
可以，选择本地部署或客户内网环境，样本不出网。代价是需要准备算力与运维人力，诊断阶段要把这部分条件一并评估，避免原型阶段再走一次采购流程，避免重复投入，也更稳妥。
需要客户提供多少数据？
按场景定。通常每个意图或每类工单需要数十条到上百条真实样本，并且要有标准答案。数量不是关键，覆盖边界、难例与不同业务分支才是，数量本身并不构成真正的门槛。