任务样本：真实输入加人工结果
需要的是真实输入与人工处理结果的配对，不是整理过的漂亮案例。样本要覆盖常见情形与典型例外，数量不必很多，但必须能代表上线后的流量结构，否则评测结果没有参考价值，也无法在上线后被复现验证。
知识底稿：可检索才算有
制度、流程、产品参数、话术存在共享盘里不算有，要按主题拆分、标注适用范围与生效时间，并指定维护人。没有版本管理的知识库，模型回答会混用新旧两套口径，越用越乱，最后没人敢引用它的结论。
接口：先看鉴权与限流
字段能否读取、用什么身份读取、调用频率上限多少，决定集成方案与工期。多数延期发生在鉴权审批与网络策略上，立项时就要把这三件事问清，并落到具体责任人与时间点，否则等待会被默认为零成本。
数据分级：决定部署形态
数据是否涉敏、能否进入第三方环境，直接决定用云服务接口还是私有化部署。分级结论应由客户方数据负责人出具，供应商只能提供方案与技术说明，不能替代判定，也不承担判定带来的合规责任。
运行环境：留出日志与评测空间
除算力之外，还要预留调用日志、评测环境与回滚空间。日志留存与审计要求在多数行业是硬性条件，缺了它系统即便跑起来，也过不了内部合规审查，上线计划会被整体推迟，返工往往从架构层开始。
适用与不适用
适合谁
- 准备立项、需要判断数据与系统可行性的企业
- 数据分散在多个系统、口径不统一的集团型组织
- 需要向合规部门说明数据边界的项目
不适合谁
- 数据完全不可用且不愿投入人工标注的团队
- 要求极短周期内就给出可行性结论的紧急项目
典型场景
某物流企业在立项前做了一次数据盘点：抽取三个月的客服会话、整理常见问题清单、确认运单系统可提供只读接口、由信息安全部门给出数据分级结论。盘点发现会话记录缺少处理结果，于是补做两周人工标注，才把评测集建起来，项目因此推迟，但避免了后续返工。
可执行步骤
- 抽取近半年真实任务样本，补齐人工处理结果、判定结论与例外说明，由业务方确认样本代表性
- 按主题拆分知识底稿，逐条标注适用版本、生效时间与维护人，并做一次检索测试
- 列出待对接系统，逐项确认鉴权方式、字段字典、调用上限与责任人并记录在案
- 由客户方数据负责人出具数据分级与部署边界结论，书面留档备查，并由合规岗备案
- 预留日志留存、评测与回滚所需的环境，并在上线前完整演练一次，确认链路完整可用
常见坑
- 用整理过的案例做评测集，上线后真实输入格式混乱，抽取环节大面积失败，评测结论完全失真；评测本身也失去意义。
- 知识库直接搬共享盘文件，格式与口径不统一，检索命中率低，回答似是而非，业务方逐渐不再使用。
- 接口到开发阶段才申请鉴权，审批周期一拖再拖，工期只能压缩测试环节，缺陷全部留到上线后暴露。
- 数据分级由供应商判断，出问题后责任无法界定，合规评审被退回重做，项目整体延后一个季度；责任也随之模糊。
自检与验收清单
- 任务样本是否同时含真实输入与人工处理结果
- 知识底稿是否按主题拆分，并有版本与维护人，并明确更新周期
- 接口鉴权方式、字段字典与调用上限是否已确认
- 数据分级与部署边界是否由客户方书面出具并留存
- 日志留存、评测与回滚三套环境是否已就绪可用
常见问题
没有历史数据能做吗？
能做但风险高。可先用小样本人工标注起步，或选择对历史数据依赖较低的场景，例如基于制度文档的问答；完全没有样本的场景，建议先做两周人工记录再立项，边跑边补数据而不是先上系统。
数据一定要出内网吗？
不一定。常见做法是先分级：公开与一般内部数据可用云服务，涉敏与核心数据走私有化或混合部署。边界由客户方数据负责人判定，供应商提供方案与影响说明，最终结论以书面形式留存。
接口没有文档怎么办？
先做接口探测与字段核对，形成一份最小接口说明，由对方系统负责人确认。没有文档并非不能做，但要在排期里单列这段时间，不能按有文档的节奏承诺上线，否则联调阶段必然被动。