PDF 转 Excel 的关键不是一次性丢给工具，而是先降低信息密度，再逐步提取结构化数据。
本文整理自早期学习笔记，发布时间按学习阶段归档。
正文
场景：
图片占位：f32de9cfb466b10a301dd3c35f2ad0b2.jpg
图片占位：c62610627828a6c4f1966a58fdae5bcd.jpg
步骤
第一步：Pdf 切片
网站：在线拆分PDF文件。免费拆分PDF文件
Why: 文件信息过多，处理结果不好。2-3 也 pdf 最好
第二步：AI提取信息
豆包为例：
Why:豆包大模型的多模态功能比较优秀
系统提示词：随便写：不推荐
识别pdf的内容。纯文字，可用性不高
系统提示词：生成 csv 格式
先识别pdf里面的内容，
然后输出为 cvs表格的格式发给我，方便我直接下载
系统提示词+打开写作模式：生成 word/pdf 格式
先识别 pdf 里面的内容，
然后生成为 可以直接导出的表格格式发给我，方便我直接下载
第三步：导入 excel
①：电脑方案（电脑端）：
复制粘贴
Cvs 转化为 excel 表格：免费CSV转Excel在线工具 – CSV转XLSX
②：手机方案：
Cvs 转化为 excel 表格
原理：
问题一：上传文件识别和 OCR 识别的核心区别
| 对比维度 | 本次识别方案 | 传统 OCR 识别 |
|---|---|---|
| 核心处理对象 | 电子生成的可编辑 PDF，底层是数字化字符流 | 纸质扫描件、拍照图片、图像版 PDF，底层是文字像素 |
| 核心逻辑 | 直接读取文档底层字符编码，无损提取原文 | 图像预处理 + 文字区域检测 + 像素转字符，算法还原文本 |
| 准确率 | 100% 匹配原文，无识别误差 | 受图片清晰度、字体、排版、光线影响，有概率出现错字、漏识别、音标乱码 |
| 核心适用场景 | 电脑生成的可编辑 PDF/Word/Excel 等电子文档 | 纸质文件拍照、扫描件、图片里的文字提取 |
| 说人话-例子 | 看着答案写作业（无脑誊抄） | 自己写作业（靠脑子想） |
| App 应用 | Ai 理解 pdf/excel 文件的内容 | 微信的图片识别功能（轻量级）/全能扫描王OCR 文字提取（重量级）/相机的文档模式 |
问题三：为什么不转化为 excel?/excel 文件的本质
| 对比维度 | CSV（豆包可直接生成） | Excel（.xlsx，豆包不直接生成） |
|---|---|---|
| 文件本质 | 纯文本格式，仅字符 + 分隔符（逗号 / 换行） | OOXML 格式：本质是 ZIP 压缩包，内含多层 XML 结构 |
| 内部结构 | 无结构，纯数据流 | 包含：工作表、样式、字体、颜色、公式、图表、批注、多 Sheet 等完整文档对象 |
| 生成难度 | 字符串拼接即可，无任何库依赖 | 必须用专业 SDK（POI/Epplus/OpenXML），要构建 XML 树、压缩打包、格式校验 |
| 模型适配性 | 与大模型文本生成天然匹配 | 属于二进制 / 结构化文档生成，超出对话式文本模型的原生能力 |
| 安全风险 | 纯文本，无执行逻辑，零安全风险 | 可嵌入 VBA 宏、OLE 对象，存在代码执行、恶意文件风险 |
| IO 与性能 | 极轻量，内存 / CPU 开销可忽略 | 需序列化、压缩、IO 写入，客户端 / 服务端开销都大 |
| 跨平台 | 任何系统 / 语言可直接解析 | 必须依赖办公软件的解析引擎，跨平台易出现格式兼容问题 |
问题二、千问 vs 豆包的场景分工
| 公司 | 核心战略 | Excel 定位 |
|---|---|---|
| 阿里巴巴（千问） | 云钉一体，企业服务优先：通义千问是阿里 AI 的统一底座，核心使命是赋能阿里云、钉钉的企业服务生态，打通「商业 – 办公 – 云服务」的全链路。 | 必须把端到端的 Excel 处理能力（上传 – 解析 – 处理 – 生成 – 下载）做进通义千问的核心功能，形成「钉钉 + 通义千问 + Office 文档」的原生办公体验，直接服务企业用户的高频刚需。 |
| 字节跳动（豆包） | C 端流量优先，场景化分工：豆包的核心定位是 C 端通用 AI 超级入口，优先服务抖音、今日头条的海量 C 端用户；而企业办公的深度需求，完全交给旗下飞书产品承接。 | 深度 Excel 处理能力，是飞书的核心办公卖点，飞书已基于豆包大模型，做了多维表格、文档 AI、合同信息提取等重度办公功能。豆包本身无需重复建设，避免内部产品竞争，仅需提供轻量 Excel 处理能力，满足 C 端用户的基础需求即可。 |
效果一般
图片占位：Pasted image 20260306214711.png