企业官网建设流程全解析

1. 先别急着列功能清单：归档系统和"能存能搜"完全是两码事

接到这个"批量 PDF/OCR 归档系统功能需求文档"时，我心里想的是：这活儿不难吧，无非写清楚用户可以上传 PDF、系统识别文字、然后存进数据库。真正动笔之后我才发现，难点根本不在"存"和"搜"，而在"批量"和"OCR"这两个词背后的各种边界条件。一份需求文档如果只写"支持批量处理""支持 OCR 识别"，等于什么都没写。评审的时候，研发会追问：批量是并发 10 份还是一万分？OCR 失败是重试还是让人工补？找不到识别结果算是归档成功还是失败？这些问题才是需求文档真正的价值所在。

我为什么对这类系统有这么大执念？因为几年前我参与过一次档案数字化项目，当时采购方只有一个朴素的要求：把堆积如山的合同扫描件变成能搜到内容的电子档案。结果系统上线后大家发现，确实把所有 PDF 都存到服务器了，但搜索功能形同虚设。原因很简单：扫描件没有文本层，系统的全文检索根本搜不到一个字，所有人还是得靠人工翻文件。项目复盘时我们都意识到，问题不是出在采购的软件不够强，而是最初的功能需求文档里就没有定义清楚 OCR 的处理边界、识别失败怎么办、以及归档后用户到底应该怎么找到这份文件。从那时起我就养成一个习惯：写需求文档之前，先逼自己把所有抽象字眼翻译成可验证、可测试、可验收的规则。

如果你正在负责类似系统的需求编写，或者刚接手档案数字化的产品设计，这篇文章会把我在编写"批量 PDF/OCR 归档系统功能需求文档"过程中踩过的坑、想清楚的问题和最终写进文档里的规则一条条拆给你看。

1.1 我从一次失败的历史归档项目里学到的教训

那次失败的合同归档项目，让我对"归档"和"存取"的区别有了非常直观的认识。归档系统不是网盘。网盘的核心能力是文件存取，用户把文件丢进去，能下载、能分享、能预览，就完成使命了。归档系统的核心能力是长期保存和可信检索，它强调文件不可随意篡改、目录结构稳定、后续任何时间都能快速定位到某一份具体文档里的某一段文字。

这个定位差别直接决定了需求文档的第一页应该怎么写。我见过太多人上来就写"用户登录后点击上传按钮，系统弹出上传框"，这种写法写三千字也解决不了任何决策问题。我更建议用"用户故事 + 关键约束"的方式开篇。比如：

• 作为档案管理员，我希望能够批量导入历史扫描版 PDF 合同，并自动识别其中的文字，这样就不需要手动为每一份合同录入标题和关键条款。
• 作为业务人员，我希望可以通过合同编号、签署日期或合同正文关键词检索到目标档案，并且在结果页看到命中位置的原图截图，这样可以快速确认是不是我要找的那份合同。
• 作为系统运维，我希望批量任务在凌晨执行时不影响白天的正常检索服务，并且任何异常任务都能有日志和补偿机制，这样我不必半夜爬起来处理。

这三条用户故事，看起来很简单，但每条背后都挂着一串需求决策。第一条决定了系统必须有 PDF 类型检测、OCR 引擎接入、元数据抽取这些能力；第二条决定了系统必须有全文索引、坐标级命中反馈、权限过滤这些能力；第三条决定了系统必须有任务队列、并发控制和故障恢复机制。功能需求文档如果从这些故事出发，后面就不会写成一份人云亦云的功能罗列。

1.2 需求文档的第一页应该写清什么：边界、角色、流程

动笔之前，我们必须先回答三个边界问题：做什么、不做什么、由谁来做。

第一页里我会明确写出系统范围。批量 PDF/OCR 归档系统，重点在"归档"，所以核心流程是：采集文件、预处理、OCR 识别、建立索引、入库归档、检索借阅。它不应该包揽的是：在线多人协作编辑、复杂工作流审批、实时音视频处理、业务表单引擎。也许这些功能听起来有价值，但每加一个，系统复杂度会指数级上升。功能需求文档的价值恰恰在于敢写"本系统不做什么"。

关于角色，我一般分四类：普通用户（检索和预览）、档案管理员（批量导入、人工复核、元数据补充）、系统管理员（参数配置、任务调度、异常处理）、审计员（查看操作日志）。这四个角色的权限边界，在需求文档里要有专门一节。尤其是档案管理员和系统管理员要严格区分，档案管理员可以在授权范围内修改元数据，但绝不能让他直接改 OCR 识别出的正文内容；系统管理员可以配置 OCR 引擎参数，但最好也不应该随意篡改已归档文件。

流程方面，我习惯用一张状态流转描述取代冗长的流程图。归档文件从进入系统开始，至少要经过"待处理 - 预处理中 - OCR识别中 - 待复核 - 已归档 - 检索可用 - 异常/失败"这些状态。状态之间的流转规则写清楚后，研发和测试才不会在"识别失败算不算归档"这种问题上各执一词。我的做法是：任何一份文件，只要没有进入"已归档"状态，就必须留在异常处理区，等待管理员决定是重试、人工修正还是原样保留。

2. PDF 进入流水线前的"体检"：类型识别、质量判定和格式转换

真正让我意识到 PDF 世界有多复杂的，是第一次处理五花八门的真实文件。很多非技术同事以为 PDF 就是 PDF，其实 PDF 内部差别很大，处理策略完全不同。需求文档里如果只写"系统支持 PDF 文件"，后续实现阶段一定会被各种边界文件搞得焦头烂额。

2.1 原生PDF、扫描PDF、混合PDF，处理难度完全不同

根据文件形成方式，我把 PDF 分成三类：

• 原生数字 PDF：由 Word、WPS、LaTeX、网页打印等工具直接生成，文件内部带有文本层和字体信息。这类文件可以直接提取文字，不需要 OCR，准确率近乎 100%。
• 扫描图像 PDF：由扫描仪、相机、传真机生成，每一页就是一张大图片，没有文本层。这类文件必须依靠 OCR 才能变成可检索文本。
• 混合 PDF：部分页面有文本层，部分页面是扫描图。例如一个文件前 20 页是从系统导出的电子文档，后面 30 页是后来补充的纸质合同扫描页。

需求文档中需要明确一个规则：系统必须自动检测 PDF 每个页面是否存在可提取的文本层，以此决定该页面是否需要走 OCR 流程。判断逻辑不要依赖文件后缀、来源目录或用户手动指定，因为真实场景里用户根本分不清也懒得区分。检测可以在服务端实现，用 PDF 解析库读取页面对象中的字体和文本内容即可，但需求文档不需要写代码，只需要写明行为规则。

同时，我建议在文档里增加一条兜底规则：如果页面有文本层，但提取出来的字符数异常少（比如整页只有几个字），或者文本内容出现大量乱码，系统仍然应该触发 OCR。原因是有时候 PDF 的字体编码不标准，文字看着正常，复制出来却是一堆乱码。这一类文件占比不高，但一出现就会让用户觉得"系统识别能力差"。

2.2 把电子文件统一转成 PDF/A：归档格式比你想的重要

归档系统绕不开 PDF/A 标准。普通 PDF 是"今天能用就行"，PDF/A 是"十年后打开还得是这样"。它强制要求字体嵌入、禁止依赖外部资源、对颜色空间也有约束，这样才能保证长期存档时文件不会因为操作系统或字体缺失而变化。

我曾经处理过一批从业务系统导出的带订单 PDF，看起来工工整整，但放到归档系统后，过了半年换了一台新服务器再调出来，标题字体变成了系统默认字体，排版全乱。原因就是原文件没有嵌入字体，打开时依赖本机字体库。从那以后，我写归档类需求文档都会强制加上格式转换要求：所有进入归档库的文件，原则上都转换为 PDF/A-1b 或 PDF/A-2b 格式。

这里有一个务实的变通：如果转换后导致原文件排版异常严重，或转换失败，文件仍然需要归档，但系统必须在元数据中标记"原格式存档，非标准合规"，并且保留原始文件备份。我们不能为了格式合规而把不可转换的关键文档拒之门外，但也不能让不合规的文件混在标准目录里毫无标识。这份需求文档里最好写清楚转换结果有三种：转换成功、转换失败、转换后存在风险需要人工确认。

需要提醒的是，转换过程绝对不是一次 PDF 另存为那么简单。批量转换时，要考虑字体文件缺失、页面尺寸变化、透明效果被改写等问题。我在需求文档里通常会要求系统记录转换前后页数和文件大小的变化，便于管理员判断是否出现异常。

2.3 加密、损坏、超大文件的预处理规则

真实归档环境里，总会出现一些"不听话"的文件。最常见的三类：

第一类是加密 PDF。带打开密码的文件，系统拿不到内容，更谈不上 OCR。需求文档要写清楚：遇到加密文件，系统先将文件放入异常区并提示需要密码；支持管理员在权限范围内上传解密后的文件或填写密码后重新处理。这里千万不要写"自动破解密码"这类需求，既不安全也不合规。

第二类是损坏伪装的 PDF。比如文件后缀是 .pdf 但内容根本不是 PDF，或者文件头损坏、页面数据缺失。系统必须在预处理阶段识别并将这类文件隔离，不能让它占着 OCR 任务队列浪费资源，更不能把坏文件混进已归档目录。归档系统有一条铁律：宁可保留可疑文件等人工判断，也不能自动删除用户上传过的任何东西。

第三类是超大文件和高页数文件。曾有一次业务方一次导入 1000 份 PDF，其中有一份 1.6GB 的扫描绘图文件，直接导致当时的处理进程崩溃。所以需求文档要明确文件大小限制和处理方式：支持最大单文件 500MB 或 1000 页，超过限制时系统不能静默跳过，要给出明确提示，并允许在管理员配置后开启超大文件队列。处理巨型文件时建议按页拆分处理，但归档时仍然要保留完整卷宗逻辑，不能让目录里出现一堆碎页。

这些预处理规则在需求文档里不显眼，但上线后被业务方和运维方骂得最狠的往往就是这些边界场景。

3. OCR 触发规则与识别质量：不是所有页面都需要跑一遍引擎

很多人听到"OCR 归档系统"，第一反应是：把所有 PDF 扔进 OCR 引擎，输出文本。这个思路没错，但成本极高，而且识别效果未必理想。我见过一个团队上线初期让所有 PDF 全部过一遍 OCR，结果几百台服务器的 CPU 全部跑满，晚上批量任务积压到第二天还没跑完。优化之后才发现，其实有一大半数字原生 PDF 根本不需要 OCR，直接提取文本又快又准。

3.1 可编辑文本PDF直接跳过OCR，这是最省钱的优化

需求文档里需要明确一个基本原则：系统优先尝试提取 PDF 内嵌文本层，只有对无法提取文本层的页面才执行 OCR。这个规则的收益是立竿见影的，因为 OCR 是算力密集任务，而文本提取几乎只消耗 I/O。

之前有个客户，合同文件 70% 是从办公系统直接导出的原生 PDF，只有 30% 是历史扫描件。如果不做区分，所有文件全部过 OCR，每天的归档量会多跑三倍以上的任务；做了区分之后，批量任务整体完成时间缩短了接近一半。这些数字在需求文档里不体现出来，研发阶段很容易被一句"反正都要识别"带偏。

当然，只跳过 OCR 还不够。需求文档还要规定，原生 PDF 提取出的文本必须经过清洗和校验。有时文本层存在，但字符顺序错乱、空格丢失严重，或者包含大量不可打印控制字符。我的做法是增加一个"有效文本率"指标：如果某页提取出的文本内容过于稀疏或异常，就自动降级为 OCR 处理，保证最终索引质量。

3.2 语言、清晰度、倾斜矫正和置信度阈值怎么定

OCR 不是黑魔法，它是把图像上的文字形状识别成编码字符的过程。影响识别效果的因素很多，需求文档里至少要约定以下几项：

第一，语言范围。绝大多数业务文档是简体中文和英文混合，具体还可能包含繁体中文、数字、标点。文档中要明确支持的语言组合，比如"简体中文 + 英文 + 数字"是默认配置，"繁体中文"作为可选配置。如果一开始需求文档不提语言支持，后续换了 OCR 引擎或加了语言包才发现识别结果乱码，就很被动了。

第二，图像质量要求。扫描件最好不低于 300 DPI，OCR 前系统应对图像做自动纠偏、去噪和二值化。这里有个非常常见的问题：很多扫描件歪斜三五度，直接识别会导致文字行对不齐，准确率爆降。所以需求文档要写清楚"系统自动检测页面倾斜角度，超过 1 度即执行旋转矫正"。至于分辨率，OCR 引擎通常不会因为图片无限大而更好，我的建议是识别前将图像缩放到高约 2500 到 3500 像素的范围，兼顾速度和准确率。

第三，置信度阈值。OCR 引擎对每个字符都会输出一个置信度分数。需求文档必须定义系统行为：字符级置信度低于 0.8 时，在文本结果中标记为低置信字符；页面级平均置信度低于 0.6 时，整页标记为疑似低质量；文档级低置信页面占比超过 20% 时，该文档进入人工复核队列。这些阈值不是拍脑袋定的，而是通过小批量试跑真实样本调整出来的。我建议你在写需求文档时预留这些参数为可配置项，而不是硬编码。

3.3 低置信度文档的人工复核流程

OCR 识别再快，也不可能 100% 正确，尤其是历史扫描件、印章遮挡文字、手写批注这些场景。当你把置信度阈值和低质量规则写清楚后，其实已经给人工复核流程留好了入口。

人工复核的角色通常是档案管理员。系统需要生成一个复核任务列表，每个任务展示原图页面、OCR 识别出的文本和置信度标记，管理员可以局部修正识别文本、确认无误或标记"该页无法识别，请人工录入摘要"。复核完成后，系统用修正后的文本更新全文索引，同时保留 OCR 原始结果作为追溯依据。

我在文档里会把复核分为"全量复核"和"抽检复核"两类。对高价值档案，比如涉及合同金额、身份证号、发票代码的文件，必须全量复核；对普通通知、会议纪要这类材料，可以先按 10% 抽检，如果抽检结果显示错误率高于 2%，则自动升级为全量复核。这样既控制了人力成本，也守住了底线。另一个容易忽略的点是，复核任务一定要在统计报表里留存记录。审计时如果发现某份档案索引文本和原始图明显不符，你可以直接查是哪个复核人、什么时间、改了什么内容。归档系统的可信度就是这样一点点建立起来的。

4. 批量处理的队列设计：需求文档里的"批量"必须量化成规则

"支持批量"这四个字是我在需求评审会里最怕看到的。批量到底是一次传 10 个文件、100 个文件还是十万页？每天要处理多少？高峰期和低谷期的差异有多大？如果这些不去量化，研发只能按最坏情况设计，成本爆炸；按最乐观情况设计，线上直接压垮。正确做法是，把"批量"拆成队列、并发、重试、优先级几个可配置项写清楚。

4.1 并发上限、优先级和排队策略

需求文档中要明确系统采用任务队列处理批量文件，而不是用户上传后立刻同步处理。同步处理看起来简单，但一旦文件一多，用户就必须一直等着服务器算完，体验极差，而且中途断网任务就没了。队列模式的好处是削峰填谷，用户上传后可以先返回"已提交任务，正在排队"，后台按节奏依次处理。

关于并发上限，我的建议是文档中不写死单机数字，而是写"系统支持通过配置控制同时处理的归档任务数，任务内页面级并发可调"。默认配置根据机器资源确定，比如单台处理节点同时运行 3 个任务，每个任务内并行处理 4 页。这样写的好处是，后期扩节点时不用改需求文档，只需要调配置。

优先级和抢占规则也要写清楚。例如：系统支持两类队列，普通队列和加急队列；加急队列只有当普通任务运行间隙插入，不能中断已开始的普通任务。原因很简单，已经在 OCR 的页面如果被打断，重试成本很高，不如让它跑完。业务上需要加急的场景一般是审计调阅、司法协助、上级检查，数量不多但时效要求极高。给它们单独的队列和更高优先级是合理的，但不要做成无限抢占，否则普通归档任务永远完不成。

4.2 失败重试、断点续传和处理状态

批量处理，最怕任务跑到一半挂了。需求文档里必须有一套完备的任务异常恢复机制。

我通常定义三个层面：单页失败、单文件失败、整批任务失败。单页 OCR 失败时，重试该页最多 2 次，两次间隔 30 秒；如果仍失败，标记该页为"识别失败"，继续处理其他页面，等任务结束时统一汇总。单文件失败时，比如文件下载失败、PDF 解析失败、转换失败，记录失败原因并进入异常区，不影响同批次其他文件。整批任务失败时，比如服务器重启、消息队列崩溃，系统重启后应扫描未完成任务并自动恢复，已归档成功的数据不重建索引。

这里重点说断点续传。正式归档任务往往包含上千份文件，如果用户辛辛苦苦提交了 1000 份，跑到第 800 份时系统宕机了，重启后必须从断点继续，而不是从头再来。实现上只需要状态持久化，每处理完一份文件就更新一次任务进度。需求文档里可以写一条很明确的验收规则："批量处理过程中重启服务，重启后任务自动恢复，已归档文件不重复入库，未完成文件继续处理。"

处理状态的实时反馈也很重要。用户需要看到：当前任务总进度、成功数量、失败数量、处理中数量、失败文件清单下载。管理员还可以看到每个任务的排队时间和平均处理时长，用来判断系统是否需要扩容。我会在需求文档中要求系统生成批次汇总报告，包含每个文件的归档结果、页数、耗时、OCR 置信度等关键字段，这份报告也是管理员归档留存的凭证。

4.3 批量任务的上传方式、去重和进度展示

批量文件怎么进入系统，也需要需求文档回答。常见方式有三种：Web 页面上传压缩包（zip 批量导入）、共享目录定时扫描、API 接口对接业务系统。三种方式不是互斥的，但优先级不同。对于以历史档案数字化为主的项目，共享目录扫描可能最方便，管理员把扫描仪导出的文件放进指定文件夹，系统定期拾取。对于日常业务归档，API 接口更合适，业务系统直接推送附件。Web 上传适合处理零散文件和临时补充材料。

无论哪种方式，我强烈建议加上文件去重机制。去重有两个层面：第一，同一个文件的二进制内容是否重复，可以通过 MD5 或 SHA-256 计算文件指纹判断；第二，同一份文件的不同版本，比如某人修改后再次上传，需要结合文件名和业务属性判断。对于归档系统，我倾向于"重复文件不自动删除，但进入复核区由管理员判断"，避免因为一个简单哈希碰撞或误判把有价值的文件过滤掉。

批次名称和来源记录也必不可少。需求文档要写明，每个批次必须有批次号、提交人、提交时间、来源渠道和备注信息。将来审计时，任何一个文件都能追溯到它来自哪个批次、哪次操作，这是归档系统最底线的要求。

5. 归档目录、元数据与全文检索：归档后找不到等于白做

文件识别完、处理完了，最后一步是归档。这一步做得好不好，直接决定用户愿不愿意用这套系统。归档的本质不是把文件塞进硬盘，而是建立一套结构化的知识体系：用户按什么路径能找到文件，搜什么词能命中文档，谁能看哪些内容。需求文档里这部分写深了，系统才有长期价值。

5.1 目录结构设计：按业务组织还是按时间组织？

归档目录设计是需求文档里最容易被轻视的部分。常见做法是让用户自己建文件夹、自己放文件，结果半年后目录树里出现十八层子目录，管理员自己也说不清某个文件在哪个角落。

我建议在需求文档中定义一套受控目录，而不是完全自由的文件夹结构。比如主结构按"来源部门 - 业务类型 - 年度"三层组织，下面不再允许用户随意创建深度子目录。这么做有点违背一些人的直觉，但归档和日常办公不同，归档目录追求的是稳定和可预期，而不是灵活。如果你把一个文件归档在某个目录里，三年后发现目录名变了、层级调整了，检索路径就断了。

原始文件和索引数据最好分开存储。正式归档库只能写入不可修改的归档文件和对应的索引数据；还有一个独立的工作区，用来方等待处理、中间转换产物和异常文件。这样设计的好处是，正式库数据量可控、备份策略清晰，管理员日常维护不会被待处理文件干扰。

5.2 元数据字段和抽取规则

归档系统不能只靠全文字检索。元数据是帮用户快速缩小范围的关键工具。每份归档文件至少要有这些核心字段：文档编号（系统自动生成）、标题、文档类型、签署日期、责任部门、责任人或上传者、保密级别、页数、文件大小、哈希值、归档时间、来源批次号。

元数据从哪里来？需求文档应该给出三种来源：文件名规则解析、OCR 结果自动抽取、管理员手工补充。比如文件名按照"供应商名称-合同类型-日期.pdf"这个规则命名时，系统自动切分出供应商、合同类型和日期。OCR 结果自动抽取则相对复杂，比如从合同首页识别出甲方乙方名称、合同编号、签署日期，这个能力需要单独建模，不是常规 OCR 能保证的。公平起见，我会在需求文档中将"从 OCR 文本中自动抽取结构化字段"写为可配置的高级能力，而不是默认必须项。

凡是自动抽取的字段，都必须保留可信度和人工确认入口。为什么？因为自动抽取一旦出错，就会污染整个检索体系。比如合同日期被识别成 2099 年，用户按年份筛选时这份合同就永远找不到了。人工确认不一定每条都要做，但对高价值文档，管理员应该至少审核标题、日期和合同编号这几个关键字段。

5.3 全文索引、检索响应和权限过滤

归档系统最核心的用户价值就四个字：找得到、看得见。建立全文索引时，既要索引文件名和元数据，也要索引 OCR 识别出的页面文本。检索范围默认应该限定为"普通用户只能搜索自己有权访问的档案，管理员可以全局检索"。这条权限过滤必须在查询入口就生效，不能等结果返回后再做界面隐藏，否则容易造成越权访问。

检索响应时间建议写入非功能需求：在不超过 100 万份文档的规模下，关键词检索响应时间小于 3 秒，模糊检索小于 5 秒。这个数字不夸张，只要索引设计合理，现代搜索引擎都可以做到，但如果没有写到文档里，上线后就没人对性能负责。

关于命中结果展示，我推荐保留 OCR 文本的坐标信息。用户搜索到某份档案后，可以直接跳转到原图中命中文字所在的位置，并高亮显示。从需求角度，这需要系统具备按页面级存储 OCR 结果并按坐标渲染的能力。如果预算或时间不允许，也可以退化为只显示命中的页码和上下文文本，但效果就差很多。现实中业务人员最关心的是定位到合同里的某一条约定，截图式的命中反馈能极大提升效率。

最后别忘了预览水印和下载审批。归档文件避免被随意扩散，预览页面建议叠加查看者标识水印；原文件下载需要走审批流程或至少留下操作日志。这些功能在需求文档里看似不起眼，但在正式项目里往往是合规部门盯得最紧的部分。

6. 非功能需求、验收标准和上线前绕不开的坑

功能需求写完之后，千万别急着定稿。归档系统是典型的"功能看着不难，做扎实不容易"的系统。我把非功能需求和验收标准单独拿出来仔细过了一遍，这一轮帮我发现了不少功能需求里的自相矛盾。

6.1 性能、存储、兼容性这些指标必须写进文档

性能指标要具体到能测试。我常用的几条是：批量导入 1000 份混合 PDF、总大小 2GB 时，应在 8 小时内完成全部处理和归档；单页 OCR 平均耗时不超过 5 秒；系统同时支持至少 50 个用户在线检索，检索响应时间满足上文标准。这些指标不要拍脑袋，最好基于 PoC 试跑数据来定。如果没有条件试跑，至少给一个合理范围并注明"需在试运行阶段验证调整"。

存储容量也要计算。OCR 过程中会产生中间图像、OCR 结果和索引数据，这些都会占用磁盘空间。我的经验是：1GB 的扫描版 PDF 归档后，加上 OCR 中间产物和索引，整体占用大约增长 30% 到 100%，如果保留多版本文件，占用还会更大。需求文档里要明确存储规划、备份策略和清理规则。OCR 中间图像是否可以归档后定期清理？可以，但清理前必须确认全文索引已经建立，否则以后再想重新识别就没有原始图像素材了。

兼容性方面，至少要覆盖：PDF 版本 1.3 到 1.7、符合 PDF/A 的文件、常见扫描生成的 PDF、内嵌字体和自定义字体的 PDF、包含 JPEG 和 JPEG2000 压缩图像的 PDF。文档里最好写明，遇到格式异常文件时系统必须记录详细原因并隔离处理，而不是报个英文错误给用户。

6.2 如何用验收用例逼出需求文档里的模糊点

写完需求文档后，我会设计一套验收用例，目的不是给测试用，而是验证需求本身是否自洽。举几个例子：

第一个用例：上传一个混合 PDF，前 10 页是原生文本层、后 20 页是扫描图。系统应该自动对后 20 页执行 OCR，前 10 页直接提取文本，最终检索时所有页面内容都能被命中。这个用例能检测系统是否实现了"页面级文本层检测"。

第二个用例：上传 1000 份文件，其中包含 30 份加密文件、20 份损坏文件、10 份超过 500MB 的文件。系统应该先把异常文件隔离到异常区，正常文件继续处理，最终批处理报告清晰列明各类失败原因。这个用例能检测异常处理链路是否完整。

第三个用例：批量任务执行到一半，人为重启服务。重启后，任务队列自动恢复，已经归档的文件不被重复处理，未完成的部分继续处理。这个用例能检测断点续传能力是否真实存在，而不是写在文档里好看。

这三个用例几乎每次都能暴露出需求文档里的问题。比如第一个用例会问你：如果单独一页文本层提取出现乱码，算不算文本层有效？第二个用例会问你：加密文件是否允许管理员输入密码？第三个用例会问你：已归档文件重复上传算不算重处理？与其等到研发阶段被追问，不如在文档里主动把这些分支讲清楚。

6.3 我在实际评审中被挑战最多的五个问题

如果只给你五个需要提前准备的灵魂拷问，我建议把答案先想好：

第一个：文件允许被删除吗？归档系统的原则是文件只能进入和标记，不能轻易物理删除。操作要分软删除和硬删除。软删除只标记、不进索引、但保留原文件；硬删除必须管理员二次确认，并且保留审计日志至少若干年。

第二个：OCR 识别结果可以被用户随意修改吗？不能。识别文本要区分"原识别结果"和"复核修正结果"。普通用户无权限修改，管理员复核时修改的内容要记录修改人、修改时间和前后值。

第三个：要不要支持手写体识别？这个必须明确回答。OCR 引擎对手写体支持远弱于印刷体，如果业务档案里大量存在手写批注，一定要提前说明系统只承诺印刷体识别，手写体作为辅助能力不计入验收指标。否则项目验收时一定会被拿手写件来挑战。

第四个：批量任务的执行时间窗口是多久？如果归档量很大，建议默认把批量任务安排在夜间执行，白天只处理少量加急文件和检索请求。这个决策会影响队列、并发和存储设计，一定要在功能需求里写清。

第五个：系统要保留哪些历史痕迹？至少包括：谁在什么时候导入了一批文件、谁修改了什么文件属性、谁在什么时候检索了什么关键词、谁下载或预览了哪份档案。如果事前没写，事后合规审计时补日志功能会非常痛苦。

我自己在评审会上的体会是，研发最怕的不是需求多，而是需求含糊。你把上述这些问题都给出了明确答案之后，评审会往往就能从一个"讨论大会"变成"过方案大会"，方案推进会顺畅很多。

最后再分享一个我自己的操作习惯：写完初稿后，别急着发给所有人，先拿 100 份真实的样本 PDF 跑一遍你选定的 OCR 引擎和转换工具，把识别率、耗时、失败率记录下来，再根据这些数据回去调整需求文档里的阈值和目标值。我第一次写这类文档时，凭感觉把置信度阈值定成了 0.9，结果 40% 的文件都进了人工复核，团队差点被淹没。后来改成 0.85 并增加首页强制复核、后续页抽检的机制，效率才平衡过来。功能需求文档从来不是一次定稿就完事的东西，它是需要和真实样本、真实业务持续较劲才能扎实的。希望这篇复盘能让你在动笔之前，少走我走过的那些弯路。