盘点占一半时间
文档收集、去重、补责任人与校对识别结果，往往比开发更耗时。为什么容易被低估？因为立项时看到的是功能清单，看不到文档现状。建议先抽一批估算，再按每百份文档的实际处理速度外推工期，并留缓冲。
规范可以并行
元数据字段、切分规则与命名规范不必等清洗完成，可与盘点同步推进，用首批文档试跑。怎么做？选三个部门各出十份文档按草案处理一遍，发现问题就改规范，比全部做完再返工便宜得多，也更容易达成一致。
评测决定能否上线
评测阶段要回答两个问题：常见提问能否命中，答案能否溯源到原文。判定标准怎么定？由业务方确认，未达标就继续调切分与召回，不进入试运行；跳过这一步，试运行会变成反复救火，问题也说不清，进度跟着失控。
试运行设退出条件
试运行不是无限期观察，应约定周期、样本量与通过条件，例如连续两周抽检达标、无越权事件。边界是未达标时扩展范围只会放大问题，正确做法是缩回试点继续修，而不是加人加时间硬推，那样只会放大问题。
适用与不适用
适合谁
- 需要在季度内上线并给出时间表的项目组
- 文档量大、清洗工作量一时说不清的企业
- 多部门协作、容易在收集环节拖延的组织
不适合谁
- 文档尚未收集、连用途都未确定的筹备阶段
典型场景
某保险公司计划季度末上线核保知识库。项目组先抽样一百份文档，测出平均处理速度，据此把盘点清洗排了六周，规范与开发并行四周，评测两周，试运行两周。中途两个部门文档缺失，团队缩小首批范围而不是压缩评测，最终按期上线。
可执行步骤
- 抽样估算每百份文档的处理工时，据此排定盘点与清洗的周期
- 规范草案与盘点并行推进，用三十份文档试跑并逐条修订规则
- 评测阶段先定命中与溯源的判定标准，再由业务方确认后执行
- 试运行约定周期、样本量与通过条件，未达标就果断缩范围
常见坑
- 按开发工期排计划，忽略盘点清洗，上线前两周才发现文档未齐，只能带病上线，返工更贵。
- 规范等清洗完再定，前期处理过的文档全部返工，时间与人力双浪费，团队士气受挫，后续再难推动。
- 试运行没有退出条件，问题反复出现却一直再观察，项目拖到预算耗尽，最终不了之，复盘也找不到责任点。
自检与验收清单
- 盘点清洗工时是否按抽样结果估算
- 规范是否与盘点并行试跑并及时修订
- 评测判定标准是否由业务方确认并签字
- 试运行是否有周期与明确的通过条件
常见问题
最快多久能上线？
取决于文档现状与首批范围。若文档已电子化、责任人明确，单部门试点可在数周内完成；含大量扫描件或跨部门收集时，盘点往往就要数周。压缩评测换来的提前上线，通常在使用阶段补回来。
能不能边上线边补文档？
可以分批，但要有明确的首批边界与后续排期。边上线边补的风险是用户第一次检索就遇到空白，形成这个库没用的印象，之后再推广成本很高，也很难挽回，也少走弯路，成本也更低。
里程碑怎么向管理层解释？
用产出而不用百分比：多少份文档入库、评测通过多少条、越权测试是否通过。产出型里程碑可核对、可追溯，也能在延期时快速定位是收集、清洗还是调优环节出了问题，便于追责。