文档识别转换工作台功能需求文档
所属分类：图像/转换
产品案例页：https://engineering.gugudata.com/products/imagerecognition/image-conversion-workbench/
产品定位与目标用户
文档识别转换工作台面向需要高频处理资料文件的团队，提供从文件导入、队列管理、批量处理、文档预览、OCR 提取、格式转换到结果导出的完整工作界面。产品重点解决传统资料处理流程中的三个问题：文件来源复杂、处理动作分散、结果难以统一留存。用户可以在一个页面内完成 PDF、图片、Word、HTML 等资料的识别与转换，减少在多个工具之间切换、重复上传和人工核对的成本。
目标用户包括行政档案人员、招投标资料整理人员、财务票据与合同处理人员、内容运营人员、客户资料录入人员、企业知识库维护人员以及需要批量归档的业务团队。典型工作中，这些用户会同时面对扫描件、电子 PDF、图片、Word 文档、表格附件和网页资料。工作台需要让用户清楚看到文件是否已进入队列、当前处于什么处理状态、提取结果是否可读、转换结果是否可下载，以及批量任务是否存在失败项。
产品不是单一的“上传后等待下载”工具，而是一个面向日常业务操作的资料处理台。它需要让使用者在处理前可以组织文件，在处理中可以观察进度，在处理后可以核对文本、表格、元数据和转换文件。界面应保持专业、清晰、低干扰，突出文件队列、文档预览、提取结果和处理进度，让用户能够快速判断当前任务是否正常推进。
典型业务场景
在招投标资料整理场景中，用户会收到大量 PDF 招标文件、合同扫描件、报价单、会议纪要、设计图纸和补充说明。工作台需要支持用户一次性添加多个文件或文件夹，按文件名、类型、大小和状态查看队列。用户可以先选择需要处理的文件，再执行 PDF 拆分、PDF 转文本、OCR 图片转文本、OCR 图片转 Word、图片压缩、HTML 转 PDF、Word 转 PDF 等动作。处理后，右侧区域应展示提取出的文本内容、转换生成的文件列表和处理记录，便于用户快速确认资料是否可归档。
在合同与档案归集场景中，团队常常需要把纸质扫描件转成可检索文本，把长 PDF 拆分成单页或章节，把图片型 PDF 转成 Word 或纯文本，把网页资料保存成 PDF 或 Word。工作台应让用户不必理解每种文件背后的处理差异，只需要围绕“选择文件、选择动作、查看结果、导出文件”的流程完成任务。对于已经完成的文件，列表中需要有明确的完成状态；对于正在处理的文件，需要显示处理中状态；对于等待处理的文件，需要保留在队列中，避免被误认为失败。
在内容运营和知识库维护场景中，用户可能需要从网页、PDF、图片和 Word 文档中抽取正文内容，再进入后续编辑、审核或知识库录入。工作台应支持用户查看原始文档预览，同时在右侧查看提取结果。提取结果需要按文本、表格、元数据等维度组织，便于用户快速判断结果是否满足后续使用要求。对于转换生成的文件，工作台需要列出文件名、转换类型、状态、大小和操作入口，让用户可以清晰知道每个输出文件的来源和用途。
核心工作流
用户进入工作台后，首先看到顶部的处理导航和主要操作按钮。顶部导航包括工作台、任务管理、模板管理、规则设置和系统设置。工作台用于当前文件处理；任务管理用于查看历史批量任务、失败任务和任务明细；模板管理用于沉淀常用处理方案；规则设置用于配置文件命名、分类、归档或转换规则；系统设置用于管理默认处理偏好和团队级使用配置。
第一步是添加资料。用户可以通过“添加文件”上传单个或多个资料，也可以通过“添加文件夹”导入一组相关文件。导入后，文件进入左侧文件队列。文件队列展示文件总数、筛选标签、搜索框、文件类型、文件大小和处理状态。用户可以通过全部、待处理、处理中、已完成、失败等状态筛选队列，也可以按文件名搜索。队列底部应展示已选择文件数量和总大小，帮助用户确认本次批量处理范围。
第二步是选择处理动作。工具栏提供 PDF 拆分、PDF 转文本、OCR 图片转文本、OCR 图片转 Word、图片压缩、HTML 转 PDF、Word 转 PDF 等常用能力，并保留“更多”入口承载扩展动作。用户可以先选择队列中的一个或多个文件，再点击“开始处理”。对于不适配当前文件类型的动作，界面应在业务层面给出清晰提示，避免用户提交后才发现不可处理。
第三步是查看处理过程。处理中状态需要在文件队列中实时呈现，右侧处理进度区域需要展示总进度、已完成、处理中、待处理和失败数量。进度条用于表达整体任务推进情况，状态数字用于支持用户快速判断任务是否卡住或是否需要人工介入。对于批量任务，用户应能在不中断已完成结果查看的情况下继续观察剩余文件处理情况。
第四步是核对结果。中间文档预览区展示当前选中文件的页面内容，支持分页、缩放和自动适配。右侧提取结果区展示文本、表格和元数据切换标签。用户可以直接复制文本，也可以导出文本文件。转换结果区列出生成的 PDF、TXT、DOCX 等文件，并显示转换类型、完成状态、文件大小和操作入口。处理记录用于记录本次任务中的关键提示，帮助用户判断失败项或异常项是否需要重试。
第五步是导出和归档。完成处理后，用户可以下载转换结果、复制提取文本、按任务或文件维度归档处理产物。对于多文件批处理，产品应允许用户继续保留队列上下文，避免用户每处理一批资料就重新组织文件。对于失败文件，用户应能通过失败筛选快速定位，并在修正文件或调整动作后重新处理。
文件队列需求
文件队列是工作台的主要入口，需要承担资料组织和任务状态反馈的双重职责。列表应至少展示文件名、类型、大小和状态。文件类型需要让用户快速区分 PDF、PNG、DOCX、TIF、JPG、XLSX 等常见资料。状态需要使用清晰文字和可识别的视觉标识，覆盖待处理、处理中、已完成和失败。对于批量导入的文件，队列排序应保持稳定，避免用户在处理过程中失去上下文。
队列筛选需要服务于批量任务管理。用户可以查看全部文件，也可以只看待处理、处理中、已完成或失败文件。筛选标签旁应显示数量，帮助用户快速评估任务规模。搜索框用于按文件名查找资料，适合文件数量较多时定位单个合同、报价单或扫描件。选中文件后，底部应显示已选择数量和文件总大小，防止用户误处理过多或过少文件。
队列还需要支持任务中的状态变化。开始处理后，选中文件应从待处理进入处理中，完成后进入已完成，异常时进入失败。状态变化需要尽量及时，避免用户误以为系统无响应。对于正在处理的文件，列表中应保留明显状态；对于已完成文件，用户应可以继续选中查看预览和结果。对于失败文件，产品需要给出可理解的失败状态，并允许后续重试或切换处理方式。
批量处理需求
批量处理是工作台的核心价值。用户在一次导入后，可以对多个文件执行同一种处理动作，也可以围绕同一批资料连续执行多种动作。例如先对 PDF 进行拆分，再对拆分结果进行文本提取；或者先对图片进行 OCR，再将结果导出为 Word。产品应把这些动作组织为清晰的工具栏，减少用户记忆成本。
“开始处理”是批量任务的主按钮，需要在用户选择文件和处理动作后触发。处理过程中，用户应能够看到暂停、清空队列等控制入口。暂停适用于较长批量任务，清空队列适用于用户确认当前资料不再需要处理的情况。清空队列应避免误操作，至少需要在界面表达清楚会移除当前队列中的资料。
更多处理能力可以通过“更多”入口承载，但高频动作应直接展示在工具栏上。截图中的高频动作包括 PDF 拆分、PDF 转文本、OCR 图片转文本、OCR 图片转 Word、图片压缩、HTML 转 PDF 和 Word 转 PDF。这些动作覆盖了从扫描件到可编辑文本、从网页到文档、从大文件到压缩图片的常见需求，适合放在一级操作区。
文档预览需求
文档预览区用于帮助用户在处理前后核对原始资料。预览区应展示当前文件名、当前页码、总页数、缩放比例和视图控制。用户可以在预览中查看 PDF 页面，确认识别对象是否正确，也可以通过缩放查看细节。对于多页文件，页码和缩略图可以帮助用户快速切换页面。
预览区底部的缩略图列表适合展示多页文档结构。用户可以看到第 1 页、第 2 页、第 3 页等页面缩略图，并快速定位需要核对的页面。对于长文档，缩略图可以显示省略状态，让用户知道文档还有更多页。预览区需要与右侧提取结果保持上下文一致：当用户选中某个文件或页面时，右侧应展示对应的结果或当前任务输出。
自动适配开关用于提升阅读效率。对于不同尺寸的扫描件、合同页、图片和 PDF，预览需要尽量保持合适缩放，减少用户手动调整。缩放和适配功能应以清晰图标和状态呈现，确保用户能快速理解当前视图是 100% 原始比例还是已适配容器。
识别结果需求
提取结果区需要让用户快速判断 OCR 或文本提取质量。结果区应提供文本、表格和元数据三个视图。文本视图展示识别出的正文内容，适合合同条款、招标公告、报价说明等资料；表格视图用于承载从票据、清单、报价单或表单中提取出的结构化内容；元数据视图用于展示文件属性、页数、识别语言、处理时间等辅助信息。
文本结果需要支持复制和导出。复制文本适合用户直接粘贴到业务系统、知识库或办公文档；导出 TXT 适合批量归档和后续自动化处理。对于识别文本，界面应保持可读性，段落、编号和标题需要尽量清晰呈现。用户只需要看到可判断、可复制、可导出的业务结果。
转换结果区需要展示每个输出文件的名称、转换类型、状态、大小和操作入口。截图中的结果包括 PDF 拆分结果、PDF 转文本结果和 OCR 图片转 Word 结果。用户可以据此确认每个处理动作是否已经生成对应文件。对于多种格式输出，文件命名应让用户能理解来源，例如原始文件名加转换动作或页码信息。
处理记录用于补充说明任务执行中的业务提示。它不应成为主要结果展示区，但需要在用户排查失败项、查看异常提示或确认任务完成时提供依据。记录内容应面向操作人员，避免出现不必要的无关术语。
任务管理、模板管理与规则设置
任务管理用于承接批量处理后的历史记录。用户需要在任务管理中查看处理过的批次、任务状态、创建时间、文件数量、成功数量、失败数量和结果入口。对于经常处理资料的团队，历史任务可以帮助他们追溯某批文件是否已经转换、是否存在失败项、结果文件是否已生成。
模板管理用于沉淀常用处理方案。例如“招标文件归档模板”可以包含 PDF 拆分、OCR 文本提取、文本导出和结果命名规则；“合同扫描件处理模板”可以包含图片 OCR、Word 导出和归档分类。模板应降低重复配置成本，让团队成员按统一流程处理资料，减少个人经验差异带来的结果不一致。
规则设置用于管理文件命名、结果分类、状态处理和归档约定。用户可以设置结果文件命名规则、按文件类型自动选择处理动作、按业务标签归档输出内容，或者对失败文件设定重试策略。规则设置应采用业务语言描述，例如“按原文件名生成结果”“完成后加入归档列表”“失败文件保留在失败筛选中”，避免出现无关的处理细节。
系统设置用于承载团队级默认偏好，例如默认视图、默认导出格式、常用操作按钮、文件大小提示和结果保留策略。系统设置不应干扰日常操作，但需要为长期使用提供稳定的配置入口。
接口调用蓝图
接口调用蓝图只列出当前案例的核心接口。所有请求地址均使用生产 API 域名，接口文档地址指向咕咕数据公开详情页。表格中的*表示必填参数；appkey只代表调用方自己的访问凭证占位，不展示真实值。
| 业务步骤 | 接口名称 | 接口文档 | 请求地址 | 关键入参 | 关键出参 | 传参关系 |
|---|---|---|---|---|---|---|
| PDF 拆分 | PDF 分割拆分 | pdfsplitter | POST https://api.gugudata.com/imagerecognition/pdf-splitter | appkey* (query)、file* (body)、storage (body) | 拆分页文件、页码关系、处理状态 | 用户上传的 PDF 作为file输入，拆分结果继续作为后续 PDF 识别或 OCR 的对象。 |
| PDF 文本提取 | 通用 PDF 文件流 OCR 到文本 | pdf2text | POST https://api.gugudata.com/imagerecognition/pdf2text | appkey* (query)、pdffile* (body) | 可复制文本、页内正文 | 原始 PDF 或拆分页作为pdffile输入，返回文本进入结果核对区。 |
| PDF 转 Word | 通用 PDF 文件流 OCR 到 Word | pdf2word | POST https://api.gugudata.com/imagerecognition/pdf2word | appkey* (query)、pdffile* (body)、storage (body) | Word 文件链接、转换状态 | 同一pdffile在文本核对后可继续生成可编辑 Word。 |
| 图片地址 OCR | 通用图片地址 OCR 到文本 | ocr | POST https://api.gugudata.com/imagerecognition/ocr | appkey* (query)、imageurl (body)、imagebase64 (body) | OCR 文本、识别状态 | 图片 URL 写入imageurl，识别文本进入右侧文本视图。 |
| 图片文件 OCR | 通用图片文件流 OCR 到文本 | imagestreamocr | POST https://api.gugudata.com/imagerecognition/imagestreamocr | appkey* (query)、imagefile* (body) | OCR 文本、识别状态 | 本地图片作为imagefile上传，适合扫描件批量识别。 |
| 图片转 Word | 通用图片地址 OCR 到 Word | ocr2word | POST https://api.gugudata.com/imagerecognition/ocr2word | appkey* (query)、imageurl (body)、imagebase64 (body) | Word 文件链接、转换状态 | 图片地址或 Base64 识别后生成 Word 产物。 |
| HTML/URL 转 PDF | HTML/URL 转 PDF | html2pdf | POST https://api.gugudata.com/imagerecognition/html2pdf | appkey* (query)、type* (body)、content* (body)、landscape (body)、showpages (body)、filename (body)、storage (body) | PDF 文件链接、页面设置结果 | type区分 URL 或 HTML，content传入网页地址或 HTML 内容。 |
| HTML/URL 转 Word | HTML 转 Word | html2word | POST https://api.gugudata.com/imagerecognition/html2word | appkey* (query)、type* (body)、content* (body)、filename (body)、storage (body) | Word 文件链接、转换状态 | type和content与 HTML 转 PDF 保持一致，用于可编辑文档输出。 |
| Word 转 HTML | Word 转 HTML | word-to-html | POST https://api.gugudata.com/imagerecognition/word-to-html | appkey* (query)、file* (body)、storage (body) | HTML 内容或文件链接 | Word 文件作为file输入，结果可继续进入网页预览或转换流程。 |
| 图片压缩 | 图片压缩与尺寸优化 | image-compress | POST https://api.gugudata.com/ai/image-compress | appkey* (query)、image_file (body)、image_url (body)、targetWidth (body)、targetHeight (body)、maxWidth (body)、maxHeight (body)、quality (body)、format (body) | 压缩后图片、尺寸和质量结果 | 图片文件或地址进入压缩接口，输出用于预览、归档或二次识别。 |
参数流转说明
核心参数流从文件队列开始：PDF 文件进入拆分接口后，拆分结果继续作为pdffile传给 PDF 转文本或 PDF 转 Word；图片文件进入imagestreamocr，图片地址进入ocr或ocr2word；HTML 与 URL 通过type和content分流到 HTML 转 PDF 或 HTML 转 Word；图片压缩接口在上传前后都可使用，用于降低文件体积并保持预览清晰。
用户输入的原始对象需要和每一步接口结果保持明确对应关系。页面应保留原始输入、当前处理参数和接口输出结果之间的联系，让用户可以从任一结果回到来源对象。例如用户修改关键词、日期、代码、文件、城市或号码后，所有依赖该参数的结果都需要重新标识为待刷新或重新查询，避免旧结果和新条件混在一起。
不同接口之间传参时，只传递公开接口需要的业务字段。文件类场景传递文件、文件地址或识别文本；数据查询类场景传递代码、日期、区域、关键词或分页条件；文本类场景传递正文、目标语言、对比文本或处理风格；号码类场景传递原始号码、标准号码和国家区号。接口返回结果进入页面后，需要转换为业务人员能理解的字段名称和操作入口。
如果用户批量处理多个对象，系统应把每个对象的参数和结果分开保存到列表行或任务项中。批量任务可以并行展示进度，但用户在页面上看到的仍应是每条业务对象的输入、状态和输出，不能只显示一个模糊的整体结果。失败项需要保留原始输入和失败步骤，方便用户修正参数后重新提交。
相关接口能力范围
当前分类下完整相关接口包括：HTML 转 Word、HTML/URL 转 PDF、Markdown 转 PDF、PDF 分割拆分、PDF 解析格式化输出、PDF 转 HTML、PPT 转高精度 PDF、PPT 转高精度图片、Word 转 HTML、图片压缩与尺寸优化、通用 PDF 文件流 OCR 到 Word、通用 PDF 文件流 OCR 到文本、通用图片地址 OCR 到 Word、通用图片地址 OCR 到文本、通用图片文件流 OCR 到文本。这些接口仍由页面下方“相关数据接口”区域统一展示，接口名称、简介、能力标签和文档入口保持完整。PRD 正文中的调用蓝图用于说明核心链路，不替代接口详情页，也不覆盖每个接口的全部参数、示例和响应字段。
用户阅读本案例时，应先理解 文档识别转换工作台 的业务流程，再根据接口调用蓝图判断是否满足自己的集成场景。如果需要扩展到同分类下其他能力，可以继续点击下方接口文档查看完整说明。这样既能保证 PRD 可读，又能保留完整接口入口。
体验要求
页面整体应保持工程服务站点当前的克制风格。功能需求文档是辅助用户理解产品能力的正文区域，不应做成过重的营销模块。标题、段落、列表和表格需要适合长文阅读，文字宽度不能过长，移动端不能溢出。PRD 区域应出现在截图之后、接口列表之前，让用户先看到产品界面，再阅读功能说明，最后查看可调用接口。
桌面端左侧导航保持固定，用户滚动阅读 PRD 和接口列表时仍可切换案例或行业。移动端采用单列布局，导航、截图、文档和接口列表按顺序展示。未配置 PRD 的案例不显示空白区域，避免其他产品案例页面出现无内容模块。
验收标准
当用户访问“文档识别转换工作台”案例时，应能依次看到产品标题、产品截图、功能需求文档和相关数据接口。功能需求文档不少于 3000 个中文字符，内容覆盖截图中可见的文件队列、批量处理、文档预览、提取结果、转换结果和处理进度，也覆盖顶部导航中的任务管理、模板管理、规则设置和系统设置。相关数据接口区域仍显示 15 个图像/转换接口，接口名称、简介、能力标签和文档入口完整可见。
当用户切换到其他产品案例时，页面应继续正常显示截图和接口列表，不出现空白 PRD 区或错误信息。当用户在移动端访问页面时，长文档、表格和接口行应保持可读，不应出现横向遮挡主要内容的问题。当用户点击接口文档入口时，应打开对应的咕咕数据接口详情页，并保留当前产品案例的来源参数。
关于 GuGuData Engineering 产品案例
更多产品案例请访问 GuGuData Engineering 产品案例。
GuGuData Engineering 产品案例页展示基于咕咕数据接口能力构建的数据接入、业务流程和产品原型，帮助团队从真实业务场景出发，快速评估接口组合、调用方式和落地价值。
