企业上 AI 之前，先把数据治理做对：从纸质档案到可查询数据
“数据都没有，做个屁的 AI 改造。”这句话虽然直接，但它指出了企业 AI 项目最常见的前置问题：资料还没有被整理成可以可靠使用的业务数据，就开始讨论知识库、Agent 和模型选型。
纸质维修单还在档案柜里，产品手册有多个“最终版”，Excel 里的型号写法各不相同。这样的资料即使被接入模型，也只会让系统更快地生成看起来合理、实际却无法核对的答案。
本文以一批纸质维修单、扫描版产品手册和 Excel 配件表为例，整理一条可以落地的企业数据治理流程：
确认用途
→ 盘点原件
→ 扫描采集
→ OCR 与版面解析
→ 清洗和业务核对
→ 验收与发布
→ 持续维护
文中的型号和记录是模拟数据，工具组合和处理方法可以迁移到企业项目，但具体字段、权限、验收线和保留期限仍需要由业务负责人确认。
先确定用途：同一批资料，不同目标需要不同治理深度
数据治理不是为了把所有资料做成同一种格式，而是为了支持一个明确用途。
同一批维修单可能有三种目标：
| 使用目标 | 最低需要整理到什么程度 |
|---|---|
| 查询某台设备的历史维修 | 设备编号可以定位，原件可以打开和追溯 |
| 统计配件消耗 | 配件编号、数量、单位和日期需要拆成字段 |
| 分析哪些型号经常返修 | 需要定义维修事件、设备型号和返修口径 |
第一批不要一开始就覆盖全公司的所有历史资料。更稳妥的做法是选择一条产品线，把目标写成一句可以验收的话：
售后人员可以按设备编号找到该设备的历史维修单，
每条结果都能打开对应原件，无法确认的编号进入人工核对队列。
这句话会决定第一批要收哪些文件、需要提取哪些字段，以及最后如何测试。
OCR 只负责识字，不负责把资料变成可信数据
OCR（Optical Character Recognition，光学字符识别）的工作很具体：读取扫描件或照片里的文字，输出可以复制和搜索的文本。
它不会自动判断：
AB-100是否被识别成了AB-10O；- 表格中的数量是否仍然对应正确的配件名称；
- 两份同名手册中哪一份正在生效；
- 维修单中的空白代表没有消耗，还是没有填写；
- 手写备注是否足够清楚，可以进入正式统计。
因此，OCR 的结果应该被视为待核的原始识别结果，而不是已经确认的业务事实。
一个典型流程应该是：
原始扫描件
→ OCR 文本
→ 业务字段
→ 人工确认
→ 正式数据
在人工确认之前，不要让 OCR 结果直接覆盖原件，也不要让模型自动补全看不清的型号和数字。
第一步：盘点原件，不要看到纸就直接扫描
桌上放着一本打印手册，不代表它没有更好的电子原件。开始扫描前，先查找：
- 编写或维护部门；
- 共享盘和文档系统；
- 邮件附件；
- 业务系统中的原生 PDF；
- Word、Excel 或其他原始文件；
- 已经存在的历史版本。
如果能找到 Word、Excel 或带文字层的 PDF，就优先读取原文件，避免因为再次 OCR 引入错误。
接着建立资料台账。每份资料至少记录：
| 字段 | 作用 |
|---|---|
| 资料编号 | 让原件、扫描件、OCR 结果和清洗记录关联起来 |
| 资料类型 | 维修单、产品手册、配件表等 |
| 来源部门或人员 | 追踪事实和补充信息的来源 |
| 收到时间 | 确认处理批次和时间边界 |
| 适用型号或范围 | 支持版本和适用关系判断 |
| 当前状态 | 待处理、识别中、待核、已发布或已归档 |
原件保持收到时的样子，不要直接在原始文件上改字。纠错应发生在工作副本，并记录修改内容、理由和确认人。
第二步：扫描时保住一份完整电子原件
扫描前先处理纸张和顺序：
- 确认一张单据有几页；
- 检查背面是否有备注；
- 确认附件属于哪一张单据；
- 扫描前使用资料编号；
- 扫描后立即检查页数和顺序。
如果原件有六页，PDF 只有五页，应在纸张还在手边时补扫，而不是等到后面解析失败再回头找。
如果使用手机拍摄，要检查：
- 反光；
- 阴影；
- 透视变形；
- 手指或设备遮挡；
- 最小字号；
- 型号中的数字和字母；
- 小数点；
- 手写备注。
批量扫描前，先用四类页面做试扫：
- 清晰打印页；
- 细小表格页；
- 褪色复印件；
- 带手写批注的页面。
试扫样本确认可用后，再采用相同设置处理后续文件。自动裁边、去背景和删除空白页可能伤害浅色文字、印章和签字。处理后的图片另存，不要覆盖原始扫描图。
人眼已经看不清的内容，应标记为“待核”，不能让模型根据上下文猜一个看似合理的值。
第三步：根据文件类型选择 OCR 和解析工具
原生文件优先读取本身
Word 和 Excel 应直接读取文件结构。带文字层的 PDF 可以先复制几段文字检查；只有整页都是图片的 PDF，才需要完整 OCR。
一批资料全部重新 OCR，可能会把原本正确的文字重新识别错。
扫描 PDF：先做可搜索文本层
如果目标只是搜索和引用原文，可以使用 OCRmyPDF 为扫描 PDF 增加文字层。处理后应保留：
原始扫描件
可搜索 PDF
OCR 文本
处理日志
初次处理完成后，不要只看命令是否成功退出。应使用原件中明确存在的设备型号进行搜索，再把包含数字和单位的一段文字与原图对照。
常见问题包括：
- 中英文语言包没有选对；
- 页面方向判断错误；
- 原图分辨率过低；
- 型号、数字 0 和字母 O 混淆；
- 小数点或单位被遗漏。
原图质量太差时，优先重扫，不要在错误输入上反复调模型参数。
复杂版面：不要只依赖纯 OCR
产品手册通常同时包含标题、段落、图片和表格。OCR 可以识别文字，却不一定保留它们之间的关系。
例如，第一列的配件名称和第二列的数量错了一行，生成出来的 CSV 可能仍然整齐，但业务含义已经错误。
对于表格和复杂版面，可以考虑 PaddleOCR 的版面和表格解析能力。处理时先选择三类样本：
- 纯文字页；
- 复杂表格页；
- 模糊扫描页。
重点检查：
- 表头是否被拆错；
- 单元格是否串行；
- 跨页表格是否能关联；
- 结果能否定位回原页；
- 合并单元格和无边框表格是否被正确处理。
结构不稳定的表格应进入待核队列，不能直接加入正式统计。
第四步：清洗数据，但只批量修改能明确判断的问题
OCR 和表格解析完成后，可以先处理确定性较高的问题：
- 去除字段前后的多余空格；
- 统一已经确认的日期格式；
- 清理重复页眉；
- 合并被识别过程拆开的同一段文字；
- 统一已由业务确认的编码格式。
每条被修改的数据至少保留：
原始值
修改后值
修改规则或原因
修改时间
修改人或确认人
对应资料编号
如果只有 AB-10 和 AB-100 两个近似值，不能凭相似程度直接合并。它可能是 OCR 漏字，也可能确实是两个型号。应对照原图和已确认的产品清单，再决定是否合并。
缺失值不能顺手补成零
维修单没有填写配件数量，可能代表：
- 没有消耗；
- 没有记录；
- 原件模糊；
- 字段不适用。
这四种含义不能都填成 0。缺失值的业务语义必须单独建模。
用 OpenRefine 处理同一列的不同写法
OpenRefine 适合处理一列中出现多种写法的情况，例如：
售后部
售后部门
售后服务部
可以先使用文本 Facet 查看每种写法和出现次数，再清理首尾空格，最后使用聚类功能找出相似值，交给业务负责人确认。
工具可以把相似值放在一起供人判断，但不应在没有确认的情况下自动合并：
售后部
售后服务有限公司
两者看起来相似，却可能是部门和外部公司的不同主体。
Excel 字段必须先定义口径
一列叫“维修日期”，它可能表示：
- 报修日期；
- 开工日期；
- 完工日期；
- 录入日期。
一列叫“配件数量”，也可能表示：
- 本次领用数量；
- 历史累计数量；
- 计划数量；
- 退回数量。
程序可以发现格式不同，却不能单独决定两个字段在业务上是否是同一回事。字段含义、单位换算和记录唯一标识必须由业务负责人确认。
一条维修记录可以整理成：
| 字段 | 示例 | 处理要求 |
|---|---|---|
| 设备编号 | EQ-00125 | 按文本保存，不能丢掉前导零 |
| 维修单号 | WO-2026-0042 | 作为业务记录标识 |
| 配件编号 | AB-100 | 与已确认的配件清单匹配 |
| 数量 | 2 | 与单位拆开 |
| 单位 | 件 | 没有换算规则时不能直接换成其他单位 |
| 维修日期 | 2026-09-01 | 先明确日期口径 |
| 来源页 | repair-0042.pdf#page=2 | 保留回溯路径 |
复杂表头要保留上下文。例如“上半年／维修／数量”和“下半年／采购／数量”不能都简化成“数量”。明细行与合计行也要区分，避免统计时重复计算。
重复、版本和权限必须分开处理
重复文件
可以先用文件指纹找出完全相同的副本。但同一张纸扫描两次，文件指纹可能不同，需要继续根据资料编号、页面内容和来源人比对。
重复记录
不能只用“设备编号 + 日期 + 配件编号”判断重复。同一台设备在同一天可能两次领用同一种配件。
只有找到维修单号、明细行号或其他业务唯一标识，才可以确认重复。
版本
版本应记录：
- 适用型号；
- 设备批次；
- 生效时间；
- 替代关系；
- 维护部门；
- 当前状态。
修改时间最新，不代表当前有效。旧设备的历史维修记录仍应保留它当时适用的手册版本。
权限
从维修单提取的文本和表格，应继承原文件的访问范围。原始 PDF 只有售后组可以打开，旁边的清洗表也不能默认向全员开放。
如果要给外部人员做故障分类统计，应另外生成去掉客户姓名、联系方式和其他识别信息的用途副本。
验收要打开数据看，而不是只看程序有没有报错
程序运行成功，只能证明它走到了最后一步。数据验收至少分两层。
规则检查
先用确定性规则检查：
- 是否有文件没有处理状态；
- 必填字段是否为空；
- 日期是否可以解析；
- 设备编号是否能在设备清单中找到；
- 维修单号是否重复；
- 配件编号是否存在于已确认清单；
- 清洗记录是否能返回原始文件。
清洗结果是 CSV 时，可以用 DuckDB 查询缺失、重复和无法匹配的记录。固定规则应优先于让大模型猜测。
人工抽查
人工抽查应覆盖不同质量的样本：
- 清晰打印页；
- 模糊扫描件；
- 复杂表格；
- 手写记录；
- 带印章或阴影的页面。
重点核对型号、日期、数量、单位和会影响业务处理的条款。只抽查清晰页面，会让结果看起来比真实情况更好。
数量、单位和适用版本存在未解决错误时，对应记录不应进入正式统计。不影响当前用途的缺口，可以保留说明后交给业务负责人决定是否接收。
历史数据清理后，还要改变新数据入口
如果新维修单仍然按旧方式产生，历史资料清理很快会再次失效。应该反过来改进资料入口：
- 设备编号设为必填；
- 配件从已确认清单中选择；
- 数量和单位分开填写；
- 记录经办人和处理时间；
- 维修单、附件和扫描件使用统一编号；
- 纸质表单统一版式和扫描交接方式。
每个处理批次都应记录：
收到什么文件
使用了什么规则
哪些成功
哪些失败
哪些等待人工确认
哪些已经发布
失败后只重跑有问题的部分。规则改变后，根据批次找回受影响的数据重新检查。人工确认过的修正不能被下一次程序运行直接覆盖，应保留原始识别结果，再叠加人工确认层；两者冲突时重新进入待核队列。
开源工具如何组合
目标只是搜索原文
可以从以下组合开始：
扫描件
→ OCRmyPDF
→ 可搜索 PDF
→ 资料台账
→ 人工抽查
资料包含大量复杂表格
可以增加：
PaddleOCR
→ 版面和表格解析
OpenRefine
→ 字段清洗和相似值核对
DuckDB
→ 缺失、重复和匹配检查
资料需要长期更新
再增加：
- 接收入口；
- 批次状态；
- 失败重试；
- 人工确认队列；
- 版本和发布管理；
- 变更审计；
- 权限继承和用途副本。
如果企业要求数据不出内网，工具、模型和处理目录都应放在企业允许的环境中，并单独验证外部网络请求和日志内容。
数据准备好了，再谈知识库和 AI
AI 可以帮助标出疑似错字、给出分类建议、整理字段冲突，但这些结果应该进入待核队列，不能直接覆盖正式数据。
当产品手册已经分清版本和适用型号后，可以接入知识问答；当维修记录已经拆好字段和单位后，可以放进可查询的数据表。
不同问题应使用不同机制：
| 用户问题 | 更合适的处理方式 |
|---|---|
| 某台设备以前修过什么 | 按设备编号查记录，并返回原件引用 |
| 某类配件用了多少 | 用确定性查询统计，再让模型解释结果 |
| 当前型号适用哪份手册 | 按版本和适用范围检索 |
| 这张模糊维修单是什么型号 | 进入人工核对，不让模型直接确认 |
暂时不接 AI 也没有问题。只要售后能够按设备编号找到正确资料，仓库能够按统一口径核对配件，新资料进入后也有固定处理方式，数据治理就已经产生了业务价值。
总结：数据治理是 AI 项目的前置交付物
企业 AI 的可靠性不只取决于模型，也取决于模型接触到的资料是否可追溯、字段是否有口径、版本是否明确、权限是否继承、错误是否有人处理。
可以把这条路径记成：
原件可追溯
→ 识别结果可核对
→ 字段含义可解释
→ 版本和权限可管理
→ 数据质量可验收
→ 新资料可持续进入
→ 知识库和 AI 才有可靠基础
OCR 让纸张变得可搜索，数据治理才让资料变得可使用。对于 FDE 来说，第一项交付未必是一个 Agent，也可能是让客户终于知道自己有哪些资料、哪些资料可信，以及下一批数据应该如何正确进入系统。
本文根据 Miles Ma 于 2026 年 9 月 9 日发布的 X 帖子《FDE 系列教程｜数据治理从入门到精通》整理，并对流程进行了结构化改写。文中的工具、命令、版本和能力可能变化，实际使用前请查看对应项目的当前文档。医疗案例和处理数字属于原帖引用的示例，不应直接当作 GPT88 的效果承诺或行业平均数据。