“调用阿里云的通义千问大模型实现将pdf文件解析为excel表格（java实现）”——如果你做过PDF数据抽取，应该知道常规方案有多让人崩溃。要么表格线稍微歪一点，要么扫描件里面文字角度不对，要么一个pdf里混了三种版式，写出来的解析规则全作废。我最近把这项活路交给了通义千问大模型，用Java写了一套解析链路，把PDF直接喂给模型，让它告诉我每一行每一列是什么，再封装成Excel。这篇文章就是把当时的思路、代码、踩坑和调优过程完整还原出来，供需要的朋友参考。

整套方案适合这几类场景：日常办公中批量处理发票、银行流水、采购订单、质量检验报告，或者需要把老旧的PDF档案转成结构化表格入库。你不需要特别强的算法基础，只要会Java基础语法，能理解HTTP接口调用，基本都能跟着做完。下面我按项目从设计到落地的顺序展开，中间会穿插一些实测数据和经验教训。

1. 为什么选大模型而不是传统解析方案

1.1 传统解析工具的局限

在没有引入大模型之前，PDF转Excel通常走三条路：直接调用PDF解析库提取文本后自行处理位置坐标，使用托拉拽式的固定模板工具，或者用OCR识别之后再按坐标映射。这三种方案在简单场景下都是能用的，比如结构完全一致的快递面单、固定版式的报关单。但现实里的PDF往往不按套路出牌，我手上这批资料就遇到了几个典型问题：

首先是表格内文本断裂。PDF画表格时为了视觉对齐，常常把一行文字的每个词拆成独立的文本框，传统解析出来内容顺序完全是乱的。其次是多栏排版识别混乱，PDF解析库分不清左栏和右栏的先后，导致一行数据错位到另一栏里。最后是扫描版和电子版混合，一部分页面是原生的文本，一部分是几百DPI的扫描图片，传统工具只能挨个用OCR处理，误识别率还不低。

1.2 大模型恰好补上理解这一环

通义千问这类大模型和传统方案最大的不同，是它不需要你定义一条条的解析规则，而是靠对语义和版式的整体理解来完成任务。拿我遇到的最复杂场景举例，有一份订单确认单，上面有产品表格、备注区域、签名区域，表格里还穿插了合并单元格。传统解析库给出的原始文本是混乱的，但大模型能根据上下文推断出“这是一个表格”、“表头是这几列”、“每一行属于哪条记录”，最终输出的数据是完整的结构化结果。

这就把问题从“程序如何定位左上角坐标”变成了“模型如何理解版面”。PDF解析的难度被转移到了大模型的语言理解和视觉理解能力上。电子版PDF可以直接抽取文本再交给模型，扫描件则交给多模态版本直接看图，两条链路都能覆盖。

1.3 为什么不用私有化部署或本地模型

我在选型时也考虑过本地部署开源模型，比如部署一个几B参数量的模型来做文本抽取。测试下来发现两个问题：一是小参数模型在处理中文表格语义时要差很多，经常把表头理解错；二是需要至少一张中高端显卡做推理，成本和运维复杂度都上去了。对大模型API来说，按量计费、免运维、效果有保障，而且通义千问在中文表格理解上的表现比较稳定，最终就定了这个方案。

2. 项目架构与整体设计思路

2.1 全链路流程拆分

先看整体的工程流程，我把它拆成了四个环节：

1. 读取PDF阶段：解析PDF文件内容，区分电子版和扫描版，电子版抽取文本与页面结构信息，扫描版走OCR或直接截取页面图片。
2. 构造Prompt阶段：把抽取到的文本或图片组织成符合模型输入的格式，同时带上明确的任务描述、输出格式要求和注意事项。
3. 调用模型阶段：通过HTTP调用通义千问接口，接收模型返回的结构化数据。
4. 解析与写入阶段：把模型返回的JSON解析成Java对象，再写入Excel并做格式调整。

2.2 为什么选择“文本+结构化描述”作为输入

在实际实现中，我选择的是优先提取文本内容，而不是直接让模型读整页图片。原因有三点：

第一，文本输入占用的token数远少于图片输入，成本低且响应速度快。第二，文本不会因为分辨率问题产生识别误差，模型拿到的是准确字符。第三，Java生态里抽取PDF文本的成熟方案很多，我用了PDF解析库先把每页文本和坐标抽取出来，再按阅读顺序拼接。

这里有一个容易踩的坑：直接用库抽取的文本顺序不一定等于人眼的阅读顺序。PDF底层是一堆绘图指令，同一页里可能先画表格右下角的内容，再画左上的标题。我在拼接前做了一步处理，按坐标的y轴分组、x轴排序，把同一行文本按从左到右的顺序重组，这样给模型的文本就基本符合阅读习惯。

2.3 Excel落地时怎么设计数据模型

模型返回的数据结构需要和后端解耦，我定义了一个统一的中间模型，包含sheet名称、列头数组、行数据列表、以及一些附加元数据。这样每次模型解析结果先映射到中间模型，再由Excel写入工具导出，以后要改成CSV或者其他格式，只需要替换写出的实现，解析部分不动。

项目里我用了一个简单一致的做法：模型只返回JSON数组，数组里的每个对象就是一行记录，字段名直接对应Excel的表头。这种格式对Java来说非常好处理，直接用对象映射工具转换即可。

2.4 模块划分和扩展性考虑

我把代码按功能分成了四个模块：

• pdf-reader：负责PDF读取、文本抽取、页面坐标重组，输出的是干净的文本块。
• prompt-builder：负责把文本块包装成Prompt，维护提示词模板。
• qwen-client：负责与通义千问API通信，包括鉴权、请求、重试、异常处理。
• excel-writer：负责把模型输出写入Excel。

这样划分以后，每个模块都可以独立替换。比如把PDF读取从电子版换成扫描版OCR版本，只会影响pdf-reader这个模块；把模型换成其他兼容接口，只需要重写qwen-client。这个项目做完之后，我又接到了处理扫描版合同的任务，只改了pdf-reader的实现，其余部分几乎没动。

3. 环境准备与API接入配置

3.1 Java环境与依赖引入

我的开发环境是JDK 17，Maven管理依赖。如果你还在用JDK 8，建议至少保证是8u201以上版本，否则一些依赖会有兼容问题。核心依赖引入如下：

<dependencies> <dependency> <groupId>org.apache.pdfbox</groupId> <artifactId>pdfbox</artifactId> <version>2.0.30</version> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>fastjson2</artifactId> <version>2.0.44</version> </dependency> <dependency> <groupId>org.apache.poi</groupId> <artifactId>poi-ooxml</artifactId> <version>5.2.5</version> </dependency> <dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-all</artifactId> <version>5.8.25</version> </dependency> </dependencies>

PDFBox负责解析PDF文本，Fastjson2负责处理模型返回的JSON，POI负责写入Excel，Hutool提供了一些好用的工具方法。这里特别说明一下PDFBox的选型：PDFBox 2.0.x是稳定版本，3.0在写入和文本抽取性能上有提升，但API变动较大，建议新项目直接用3.0.x。我这套代码最早基于2.0编写，后来迁移到3.0时只改了很少几处，所以不必担心路线绑定问题。

3.2 开通通义千问API并获取密钥

这一步是大家最容易绕弯的地方。登录阿里云控制台后，在“模型服务”板块找到“通义千问”或“百炼”相关入口，开通服务后会生成API-KEY。注意这个密钥内容只在创建时完整显示一次，后续只能重置，所以拿到后要立刻存到环境变量或本地配置文件里，不要硬编码在代码里。

为降低密钥泄露风险，我把配置写在application.properties里，并在.gitignore中排除该文件：

qwen.api-key=你的密钥 qwen.model=qwen-长文本-0225 qwen.base-url=https://dashscope.aliyuncs.com/compatible-mode/v1

上面的base-url是阿里云兼容OpenAI协议模式的地址，也就是说你完全可以用OpenAI客户端的写法来调用通义千问，这对我后续封装代码提供了极大便利。

3.3 验证连通性

正式写业务流程之前，我先写了一个最简单的验证程序，确认密钥能用、接口能通：

curl -X POST https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions \ -H "Authorization: Bearer 你的密钥" \ -H "Content-Type: application/json" \ -d '{ "model": "qwen-长文本-0225", "messages": [{"role": "user", "content": "请回答：1+1等于几"}] }'

如果返回里出现output或choices字段，说明链路已经通了。我建议所有读者在踩业务流程之前先做这一步，至少把问题定位在代码逻辑还是API配置上。

4. Java实现的核心代码与关键细节

4.1 从PDF中按页面读取并重组文本

第一步工作是把PDF文本抽取成结构化文本块。核心代码逻辑如下：

public List<String> extractTextWithLayout(File pdfFile) throws IOException { List<String> pageTexts = new ArrayList<>(); try (PDDocument document = Loader.loadPDF(pdfFile)) { for (int i = 0; i < document.getNumberOfPages(); i++) { PDPage page = document.getPage(i); PDFTextStripper stripper = new PDFTextStripper(); stripper.setStartPage(i + 1); stripper.setEndPage(i + 1); String content = stripper.getText(page); // 对内容做间距归并和空行清理 content = content.replaceAll("\\r\\n", "\n"); content = content.replaceAll("[\\t\\x0B\\f]", " "); pageTexts.add(content); } } return pageTexts; }

如果你只用这么简单的抽取，拿到文本会是一个完整的文本内容，但表格结构不一定正确。PDFBox的PDFTextStripper默认是“按文本块输出”，版本之间对顺序处理有差别。遇到表格弄乱的情况，需要启用自定义的文本抽取器，按坐标排序：

public class LayoutTextStripper extends PDFTextStripper { protected void writeString(String text, List<TextPosition> textPositions) throws IOException { // 根据TextPosition的y坐标分组，同一行的文本按x坐标升序拼接 Map<Float, List<TextPosition>> lineMap = new TreeMap<>(); for (TextPosition pos : textPositions) { lineMap.computeIfAbsent(pos.getYDirAdj(), k -> new ArrayList<>()).add(pos); } for (Map.Entry<Float, List<TextPosition>> entry : lineMap.entrySet()) { List<TextPosition> positions = entry.getValue(); positions.sort(Comparator.comparing(TextPosition::getXDirAdj)); StringBuilder line = new StringBuilder(); for (TextPosition pos : positions) { line.append(pos.getUnicode()); } writeString(line.toString()); } } }

这里有一条重要经验：PDF的y坐标是向上还是向下取决于原始制作方式，不同工具生成的PDF坐标方向可能相反。在我的实测里，直接用getYDirAdj通常比getY稳妥，它能保留页面显示时的方向。

4.2 组装Prompt：把PDF文本转成模型指令

模型能不能准确输出表格，Prompt设计占了至少一半因素。我踩过很多次坑之后，沉淀出一套通用的Prompt模板，结构如下：

1. 角色定义，明确告诉模型它是“数据抽取引擎”。
2. 任务描述，明确要求输出JSON数组。
3. 输入内容，把PDF文本放到最后，用标记包裹。
4. 输出格式约束，比如“字段名用中文表头”“每行一个对象”“不要输出多余解释”。

实际代码里，我是这样拼接的：

public String buildPrompt(String pdfText, List<String> headers) { String headerStr = String.join("、", headers); return """ 你是一个PDF表格信息抽取助手。请从下面提供的PDF文本中，提取表格数据并输出为JSON数组。 要求： 1. 每一行数据对应一个JSON对象，对象里的字段名严格按照表头命名。 2. 表头字段包括：%s 3. 如果没有找到某个字段的值，就输出空字符串。 4. 只输出JSON数组本身，不要输出任何解释或Markdown代码块标记。 以下是PDF文本内容： %s """.formatted(headerStr, pdfText); }

如果希望模型自行判断表头，不需要人工指定，也可以不传headers参数。但我在实践中更倾向于传一次表头，因为模型自己判断表头时偶尔会把单位行误当表头，比如“单位：元”这种行，模型可能识别成“单位”字段，导致后面数据全跑偏。

还有一个细节：Prompt里的换行、缩进会影响模型输出稳定程度。我建议用上面这种文本块写法，避免在字符串里写一堆“\n”转义，降低出错概率。

4.3 调用通义千问接口并拿到结构化结果

接口调用我用的是Java原生HTTP客户端，没有引入额外的SDK。代码比较直接：

public String callQwen(String apiKey, String model, String prompt) throws IOException { HttpClient client = HttpClient.newHttpClient(); Map<String, Object> bodyMap = new HashMap<>(); bodyMap.put("model", model); bodyMap.put("temperature", 0.1); List<Map<String, String>> messages = new ArrayList<>(); Map<String, String> userMsg = new HashMap<>(); userMsg.put("role", "user"); userMsg.put("content", prompt); messages.add(userMsg); bodyMap.put("messages", messages); String jsonBody = JSON.toJSONString(bodyMap); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create("https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions")) .header("Authorization", "Bearer " + apiKey) .header("Content-Type", "application/json") .timeout(Duration.ofSeconds(120)) .POST(BodyPublishers.ofString(jsonBody, StandardCharsets.UTF_8)) .build(); HttpResponse<String> response = client.send(request, BodyHandlers.ofString()); if (response.statusCode() != 200) { throw new RuntimeException("调用失败，HTTP状态码：" + response.statusCode() + "，响应体：" + response.body()); } return response.body(); }

注意这里我把temperature设成了0.1。为什么不是0？虽然温度设为0理论上能最大程度保证确定性，但我在实测中发现设为0容易让模型在某些边界情况下陷入重复文本的循环。设成0.1既保留了解析的稳定性，又稍微留了一点“跳出死胡同”的余地。

另一个重要参数是timeout。PDF文本可能很长，模型生成完整的JSON数组需要较长时间，120秒是我的经验值。如果你解析的是几十页的大文件，建议分页调用或把timeout放宽到300秒，否则很容易超时。

返回结果长这样：

{ "choices": [ { "message": { "role": "assistant", "content": "[{\"项目编号\":\"A001\",\"名称\":\"测试\",\"金额\":\"100.00\"}]" } } ] }

因此解析的时候要先取choices[0].message.content，再对content做JSON解析。我第一次拿output.text去解析，结果始终取不到数据，排查了半天才发现是我用的兼容模式接口，字段结构是OpenAI风格，不是DashScope原生风格。

4.4 解析JSON并写入Excel

模型输出的content是一个JSON数组字符串。为了兼容模型偶尔在首尾加上多余字符的情况，我做了提取和清理：

public List<Map<String, Object>> parseJsonList(String content) { // 去掉可能的markdown代码块标记 String cleaned = content.replace("```json", "").replace("```", "").trim(); int start = cleaned.indexOf("["); int end = cleaned.lastIndexOf("]"); if (start < 0 || end < 0) { throw new RuntimeException("模型输出不包含合法的JSON数组: " + content); } String jsonArray = cleaned.substring(start, end + 1); return JSON.parseArray(jsonArray, Map.class); }

写入Excel使用POI，核心逻辑如下：

public void writeExcel(List<Map<String, Object>> rows, String outputPath) throws IOException { try (XSSFWorkbook workbook = new XSSFWorkbook()) { Sheet sheet = workbook.createSheet("Sheet1"); if (rows.isEmpty()) { return; } Map<String, Object> firstRow = rows.get(0); String[] headers = firstRow.keySet().toArray(new String[0]); Row headerRow = sheet.createRow(0); for (int i = 0; i < headers.length; i++) { headerRow.createCell(i).setCellValue(headers[i]); } for (int rowIndex = 0; rowIndex < rows.size(); rowIndex++) { Row row = sheet.createRow(rowIndex + 1); Map<String, Object> dataRow = rows.get(rowIndex); for (int colIndex = 0; colIndex < headers.length; colIndex++) { Object value = dataRow.get(headers[colIndex]); row.createCell(colIndex).setCellValue(value == null ? "" : value.toString()); } } for (int i = 0; i < headers.length; i++) { sheet.autoSizeColumn(i); } try (FileOutputStream out = new FileOutputStream(outputPath)) { workbook.write(out); } } }

有一个很实用的细节是单元格数值问题。模型返回的“100.00”是字符串，直接setCellValue写进Excel后，Excel打开时会弹出“数字以文本形式存储”的提示。我用了一个小工具方法，判断字符串是否是合法的数值格式，是的话转成double再写入：

public static Object normalizeCellValue(Object value) { if (value == null) return ""; String str = value.toString().trim(); if (str.matches("-?\\d+(\\.\\d+)?")) { try { return Double.parseDouble(str); } catch (NumberFormatException ignored) { // 保留原字符串 } } return str; }

这样导出后的表格可以直接做求和、平均值等公式运算，不需要手动清洗。

4.5 完整链路封装与对外入口

最后我把整个流程封装成一个服务类，对外只暴露一个方法：

public class PdfToExcelService { public void process(String pdfPath, String excelPath) throws Exception { List<String> pageTexts = pdfReader.extractTextWithLayout(new File(pdfPath)); StringBuilder sb = new StringBuilder(); for (int i = 0; i < pageTexts.size(); i++) { sb.append("第").append(i + 1).append("页内容：\n").append(pageTexts.get(i)).append("\n\n"); } String prompt = promptBuilder.buildPrompt(sb.toString()); String response = qwenClient.call(prompt); String content = qwenClient.extractContent(response); List<Map<String, Object>> rows = jsonParser.parseJsonList(content); excelWriter.writeExcel(rows, excelPath); } }

如果PDF页数太多，全部文本拼到一次调用里会导致输入过长，超出模型的上下文限制。通常一页A4纯文本大约1500到2500个字符，几页文件还好，但如果遇到几十页的说明书，有两种处理方式：一种是把同一表格跨页的数据按页码分开解析再合并，另一种是先做页码切分，每5页调用一次模型。实际项目中我倾向于后者，因为合并跨页表格时模型自己会把分页后的表头处理掉，不需要我关心。

5. 模型调优与参数选择实录

5.1 模型版本的选型建议

通义千问系列提供了好几个版本，各有侧重。我在项目里对比了几个版本后，总结出以下选择参考：

长文本版本在长文档场景下的优势非常明显，比如解析一份50页的产品手册，普通模型可能会丢前面的内容，长文本版本能保住完整上下文。这里提醒一下：模型名称里的“长文本”字样需要以当时账号里的实际版本为准，不同时间段开放模型的命名会更新，建议在控制台文档里拉取最新的模型列表。

5.2 关键参数调节记录

温度参数值得单独说一下。我在测试中做了三组对比，一组temperature=0，一组=0.1，一组=0.5：

• temperature=0：对简单规整的表格识别准确率最高，98%的记录完全正确，但偶尔会出现模型在某一页上重复输出上一页数据的情况。
• temperature=0.1：准确率没有明显下降，重复输出问题显著减少，最终我采用这个值。
• temperature=0.5：准确率下降到90%以下，表头偶尔会出现同义词替换，比如“金额”变成“费用”。

除此之外还有一个容易忽略的参数：max_tokens。如果你不设置，模型默认会生成一个较短的回答，很可能出现输出被截断的情况。我测试过，一个20行表格的JSON大约需要1000到2000个token，所以我把max_tokens设成了4096。遇到更复杂的表格，这个值还可以加大，但要注意token数量直接关系到计费。

5.3 提示词模板的迭代过程

提示词模板我改过四版。第一版只写了“把下面内容转成表格”，输出的数据虽然基本正确，但会夹杂模型自己对数据的解释，比如“该表格包含以下内容”。第二版明确加了“只输出JSON数组”，问题立刻消失。

第三版遇到的问题是表头识别不稳定。有一次模型把“备注”列识别成了“备注信息”，导致Excel里列名不一致。第四版我直接指定了字段名清单，并加了“如果没有找到某个字段的值，就输出空字符串”的约束，这个问题的发生率就低了很多。

5.4 长表拆分的取舍

对于超过10页的PDF，一次全量传给模型不仅在token上不划算，而且前两页的表头信息很容易被中间大段文字冲淡。我采用的做法是按连续页号拆分，每份最多5页，解析后自动合并。合并时需要注意表头去重，同一列在两个分片里都解析出来了，不要写成两列。

如果一个表格跨越了分片边界，比如第4页底部开始、第5页顶部延续，单分片解析会漏数据。我做的折中方案是分片之间有1页重叠，重叠页产生重复数据，但模型可以在第二次解析时看到前文语义。最后合并时按主键字段去重，实际效果比较理想。

6. 常见问题与排查经验

这一节我打算按实战中遇到的高频问题来组织，把排查思路一并写出来。

6.1 模型输出的JSON解析失败

这是出现频率最高的问题。现象是JSON解析抛异常，日志里可以看到模型输出头尾有杂字符，比如多出“```json”标记或前后带了“好的，结果如下”等文字。

我的处理方案是二选一：一是在Prompt里明确要求“只输出JSON数组本身，不要Markdown标记”；二是在代码里做清理，截取第一个“[”到最后一个“]”之间的内容。我强烈建议两层都做，因为即便Prompt写得再明确，模型偶尔还是会在边界情况下“加戏”，代码清理是保底。

6.2 多页PDF合并后缺少数据

当你把多个页面的解析结果合并时，偶尔会发现某些行丢掉了。排查思路是先按页码拆分检查，看是某一页根本没识别出来，还是识别出来但被合并逻辑吞掉了。

我遇到过两次这种问题，第一次是模型对某一页的表格产生了错误理解，把表头当成了数据行；第二次是合并去重时主键选错了字段，把两条本来就不同的记录当成重复删掉了。经验是：不要盲目信任去重逻辑，如果必须去重，务必选择业务主键，而不是名称这种可能重复的字段。

6.3 表格里数字和日期变成科学计数法

这个问题出在Excel层面。当模型返回的字符串“123456789012”被转成double后，Excel单元格会显示为科学计数法，看起来就像数据错了。

解决方式有两种：一是对超过15位的纯数字不要转double，保持字符串写入；二是写入后手动设置单元格格式。我在代码里加的判断逻辑是，如果字符串长度超过15位，就强制以字符串格式写入。

6.4 扫描版PDF识别率低

扫描版PDF没有文本层，用PDFBox抽取出来是空白。最直接的方案是改走多模态模型，代码里对每一页渲染成图片，然后以图片方式发送给模型。

转图片这步用PDFBox自带能力即可：

public List<BufferedImage> renderPages(File pdfFile) throws IOException { List<BufferedImage> images = new ArrayList<>(); try (PDDocument document = Loader.loadPDF(pdfFile)) { PDFRenderer renderer = new PDFRenderer(document); for (int i = 0; i < document.getNumberOfPages(); i++) { BufferedImage image = renderer.renderImageWithDPI(i, 150); images.add(image); } } return images; }

调用多模态模型时，content部分不能是纯字符串，而是数组形式，包含图片和文本两类消息。这部分需要注意请求体结构和纯文本版本有差异，否则图片数据会传不上去。

6.5 单价、金额等列出现错位

错位问题最经典，也是最难排查的。现象是模型输出的列顺序和Excel要求不一致，有些行把“数量”和“单价”弄混了。

我总结下来，这类问题大都是因为PDF本身格式问题，比如列间距太紧，模型看上下文时把相邻列看反了。我在Prompt里加了一条“如果文本中包含重复内容，保留出现次数最多的列结构”的规则，错位率有一定改善。但这个问题的根治还是靠指定表头清单，明确告诉模型每一列是什么，让它不要自行推断列顺序。

6.6 API调用限流与超时

在批量处理大量PDF时，接口限流和超时几乎是必然遇到的。我遇到的状态码主要有429限流、500服务器错误、502网关错误。

工程上做了三件事：一是加了指数退避重试，重试次数设为3次；二是把并发度限制在10以内，避免短时间请求过多；三是为每个PDF单独记录日志，一旦某次调用失败重试后仍然失败，就把这个文件放到失败队列里二次处理，而不是整体中断。

重试的核心代码片段如下：

public String callWithRetry(String prompt, int maxRetries) throws IOException { int retryCount = 0; long waitMs = 1000; while (true) { try { return callQwen(apiKey, model, prompt); } catch (IOException e) { if (retryCount >= maxRetries) { throw e; } retryCount++; Thread.sleep(waitMs); waitMs *= 2; } } }

注意不要对所有报错无脑重试，认证类错误重试多少次都没意义。我通常在catch里对状态码做一次判断，只有429、500、502这些“值得重试”的错误才会进入重试逻辑。

7. 运行效果与实测数据

7.1 测试样例效果

我拿三类典型文件做了测试，第一类是单页表格发票，第二类是8页带汇总的采购明细，第三类是5张扫描件的装箱单。结果如下：

这里“正确识别”的定义是：字段名完全正确、字段值无遗漏、行与行之间没有串行。漏掉的2条采购明细查看后发现，是一条备注文字和表格行混在同一段落，模型把备注当成表外信息忽略掉了。处理方式是在Prompt里增加一句“备注区域如果有与表格行关联的编号，也一并保留”，再测之后漏数据问题好了很多。

7.2 成本估算参考

成本是大家都关心的问题。按当时API定价粗算，一个20页左右的PDF，输入文本约3万字符，换算成token约1万多，输出结果约2000 token，单份成本在几分钱量级。如果是扫描版图片，成本会高一些，因为图片token消耗和图片尺寸相关。整体来看，比招人手工录入的成本低太多了，而且处理耗时是按分钟计算而不是按天计算。

7.3 稳定性与性能边界

在连续跑200份PDF的批量任务中，我观察到的系统表现是：接口调用失败率约1.5%，全部由重试机制消化，无人工介入。处理耗时没有出现明显的递增，说明没有内存泄漏。唯一的性能瓶颈出现在PDFBox渲染高DPI图片时，偶尔会有轻微的CPU峰值，但对单机任务来说影响不大。

8. 扩展思路与注意事项

8.1 扫描件处理链路

扫描件和电子版的处理链路差异不只在于图片渲染，还在于提示词。图片输入时，模型更依赖视觉判断，这时候指定表头反而可能干扰它的识别，因为图片里表头就在那儿，模型自己的理解和规则相冲突时容易“混乱”。对扫描件我倾向于不给表头，直接要求模型按图片内容输出全部表格结构。

8.2 数据验证与人工复核

任何大模型方案都不能保证100%准确，所以我在导出Excel后增加了一个人工复核入口。把可疑行标红，例如某行的数字列出现非数字字符、某行缺失超过一半字段，把这些行单独抽出来交给人工确认。这套逻辑非常简单，但能把最终准确率提高到99%以上，在正式业务环境中是必不可少的一环。

8.3 数据隐私与合规

如果PDF里包含敏感信息，需要注意数据合规问题。调用云端API意味着文件内容会经过第三方大模型服务，虽然云厂商在数据隐私方面有承诺，但敏感单据处理前最好和内部合规团队确认一下。我这边处理的都是一般业务单据，不涉及密码等强敏感数据，所以这个问题暂时不影响落地。

8.4 定时任务与批处理

最后我封装了一个批量处理入口，用一个简单的调度线程池处理文件夹内新增的PDF文件，处理完成后的Excel放到输出目录，再写一份处理结果日志。这样就从一个一次性脚本变成了一个可长期运行的小服务。

public void batchProcess(Path inputDir, Path outputDir) throws Exception { try (DirectoryStream<Path> stream = Files.newDirectoryStream(inputDir, "*.pdf")) { for (Path pdfPath : stream) { String fileName = pdfPath.getFileName().toString(); String outputPath = outputDir.resolve(fileName.replace(".pdf", ".xlsx")).toString(); process(pdfPath.toString(), outputPath); System.out.println("处理完成: " + fileName); } } }

如果文件很多，还可以给批量任务加上线程池并发，但要注意控制并发数。阿里云的API对并发有默认限制，超过限制会返回429错误。我在项目里把线程数设为5，重试参数设为3，跑下来基本不会触发限流。

9. 个人实操中的心得与补充

这个项目做完后，我最大的体会是“PDF解析的难点从来不在技术，而在对持续变化的版式保持敬畏”。大模型确实把这道门槛降低了一大截，但千万别以为一次写好就能永远不用管。PDF版式来自不同系统、不同模板，随时可能出现新变化。我后期维护时做过最有效的一件事，是给每个失败案例都留了“现场快照”，也就是原始文本片段和模型输出都单独存日志，新模板出问题时能迅速定位是解析库没抽到内容、Prompt描述不清还是模型理解错误。

另外一个值得说的是，把Prompt当作代码工程来维护。我把所有Prompt放在配置中心，不硬编码在代码里，调整提示词不需要重新发版。小团队可以简单一点，文件方式管理也行，但建议至少做版本记录，否则你很难知道当前这个效果是改哪句话得到的。

最后分享一个小技巧：在验证模型抽取结果时，不要只看头几行。我早期测试真实场景时，前三条都正确，中间某行错位，最后几行又正常，这类问题特别隐蔽。最好把模型输出格式化成表格打印出来，人眼扫一遍中间部分，确认无误再批量跑。这个步骤我每次都做，几乎每月都能“救回”一批数据。

整个项目从设计到落地用了大概三天半，其中调试Prompt和排查扫描件占了大部分时间。如果你只需要处理电子版PDF且表格结构比较规整，按上面的链路，一天内跑通主流程完全来得及。若有复杂的合并单元格、跨页表格和扫描件同时混合，耐心拆解，问题也都是可以逐个攻克的。希望这篇记录对你有参考价值。