企业官网建设流程全解析

上一周我接到一个挺折腾的活儿：把公司知识库里两百多份PPT统一处理成结构化数据，方便后面做检索和问答。一开始我以为这事儿很简单，不就是读文本嘛，结果真上手才发现，PPT大概是Office三件套里最不友好的一个。同样一页内容，有人用文本框拼，有人用SmartArt，有人干脆截图往里一贴——程序提取出来的东西，经常是一堆乱序的文字碎片，根本没法直接用。

这篇文章我不想讲那些"如何用Python读取PPT"的入门废话，而是把从文件结构、提取管线、表格还原到schema设计的完整经验拆开来讲。内容偏实战，适合正在做知识库底座、文档中台或者办公自动化的小伙伴参考，读完你至少能避开我踩过的几个大坑。

1. 为什么"能打开看到"不等于"能被程序使用"

在做任何技术方案之前，先得搞清楚一个底层问题：PPT这玩意儿的组织形式，天生就不是为了让机器理解而设计的。

1.1 视觉逻辑和数据结构是两套系统

你用PowerPoint打开一页幻灯片，看到的是一个排版精美的页面：标题在左上角，正文在中间，图表在右侧。这是"视觉逻辑"。但在文件内部，这一页其实就是很多个形状（Shape）的堆叠，每个形状有自己的坐标、大小、文字内容，彼此之间没有任何语义关联。

这就好比一个房间里摆满了家具，人眼一看就知道哪里是客厅、哪里是书房，但对一个盲人来说（程序就是那个盲人），他只能挨个摸过去：这里有个沙发，那里有个书架，再那边还有张小桌子。至于"这个房间是干什么用的"，完全要靠猜。

所以"提取PPT内容"这件事，本质上是做一次从"视觉逻辑"到"结构逻辑"的逆向还原。你得自己定义一套规则，告诉程序：什么样的形状组合算一个标题、什么样的位置关系算一个段落、什么样的布局属于章节页。

1.2 三大痛点：乱序、冗余、信息丢失

我整理了PPT智能提取最常见的三个问题，基本覆盖了所有痛苦来源：

乱序：文本块的位置坐标和阅读顺序不一致。比如右下角的文本框创建时间早于左上角的标题，按创建顺序读出来，就是一段完全颠倒的话。在python-pptx里遍历shapes，顺序基本是创建顺序，不是视觉顺序。

冗余：PPT里有大量辅助性元素。页码、日期、公司logo、母版里自带的页脚，这些信息混在正文里，不去除干净，后面的数据分析就是灾难。

信息丢失：很多内容根本不在文本层里。比如一张贴在幻灯片里的截图、一个嵌进去的Excel图表、一个组合过并转成图片的流程图——这些在程序眼里就是一张"哑图"，什么信息都提不到。

这三大痛点决定了：PPT提取不能只写一个循环读shape.text就完事，必须有一套分层的处理策略，而且必须有后处理环节来"收拾残局"。

2. 先把武器拆明白：pptx文件的真实构造

很多人用python-pptx好几年，其实不知道这个库底层到底在干什么。等你弄清楚pptx文件的内在结构，很多之前觉得"莫名其妙"的Bug都会迎刃而解。

2.1 pptx是一个压缩包，不是单文件

你拿到一个后缀为.pptx的文件，它实际是一个ZIP压缩包。在终端里可以直接把它解压看个通透：

# 复制一份pptx文件，把后缀改成.zip再解压 cp 演示文稿.pptx demo.zip mkdir pptx_unzip unzip demo.zip -d pptx_unzip tree pptx_unzip

解压之后你会看到这样的目录结构：

pptx_unzip/ ├── [Content_Types].xml ├── docProps/ │ ├── app.xml │ └── core.xml ├── ppt/ │ ├── presentation.xml # 演示文稿主文件，记录了幻灯片顺序 │ ├── slides/ │ │ ├── slide1.xml # 每一页幻灯片的内容 │ │ ├── slide2.xml │ │ └── ... │ ├── slideLayouts/ # 版式文件，决定页面大概框架 │ ├── slideMasters/ # 母版文件，全局样式 │ └── theme/ # 主题文件，配色和字体

其中slides目录下的每个slideN.xml对应一页幻灯片。所有文本、形状、图片、表格，都写在里面。

2.2 最小的slide XML长什么样

我用文本编辑器打开一个最简单的slide XML，精简后的核心结构是这样的：

<p:sld xmlns:a="http://schemas.openxmlformats.org/drawingml/2006/main" xmlns:p="http://schemas.openxmlformats.org/presentationml/2006/main"> <p:cSld> <p:spTree> <p:nvGrpSpPr>...</p:nvGrpSpPr> <p:grpSpPr>...</p:grpSpPr> <p:sp> <p:nvSpPr> <p:cNvPr id="4" name="标题 1"/> <p:nvPr/> </p:nvSpPr> <p:spPr/> <p:txBody> <a:p> <a:r> <a:t>季度业务复盘</a:t> </a:r> </a:p> </p:txBody> </p:sp> </p:spTree> </p:cSld> </p:sld>

注意看，一个形状（<p:sp>）由三部分组成：命名信息（nvSpPr，里面有id和name）、形状属性（spPr，包括位置和大小）、文本主体（txBody，里面是真正的文字内容）。python-pptx做的事情，就是把这套XML包装成Python对象，然后暴露给你一个清爽的API。当你调用shape.text时，它实际上是在遍历txBody里所有a:t标签并拼接文本。

2.3 格式坐标的坐标系：EMU，不是像素

还有一个细节：pptx内部的长度单位叫EMU（English Metric Unit），1英寸等于914400 EMU，1厘米等于360000 EMU。python-pptx里读取到的shape.left、shape.top、shape.width、shape.height，单位都是EMU。

这直接影响排列顺序判断。如果你要按"从上到下、从左到右"重排文本块，不能用原始值直接排序，需要先转成统一的坐标系：

from pptx.util import Emu # Emu本身提供了转换成其他单位的方法 # 建议统一转成pt或者毫米再排序 left_pt = Emu(shape.left).pt top_pt = Emu(shape.top).pt

我平时习惯全部转成毫米（mm），因为和排版习惯对齐，认知负担最小。

3. 搭一个最小可用的提取管线

这一节给你一套我反复用了很久的提取骨架。不追求一步到位，先把管线跑通，后面再逐步加规则。

3.1 环境准备与读取演示文稿

安装依赖没有什么悬念，python-pptx是首选，配合pandas做表格整理、json做序列化输出：

pip install python-pptx pandas lxml

读取文件本身只需要几行：

from pptx import Presentation prs = Presentation("示例.pptx") print(f"幻灯片总数: {len(prs.slides)}") print(f"页面尺寸: {prs.slide_width} x {prs.slide_height} EMU")

这里有一个很多人忽略的点：拿到prs.slides只是拿到了一个Slides对象，它支持__getitem__和__iter__。建议先转成list再遍历，避免遍历过程中反复触碰文件句柄：

slides = list(prs.slides)

3.2 遍历形状并分类提取

核心遍历逻辑，我建议按形状类型分派处理。python-pptx里常见的shape_type有：TEXT_BOX、PLACEHOLDER、PICTURE、TABLE、SMART_ART、CHART、GROUP等。

from pptx.enum.shapes import MSO_SHAPE_TYPE def process_shape(shape, page_data, depth=0): """递归处理形状，页面数据以字典形式传入""" # 组合形状需要递归展开 if shape.shape_type == MSO_SHAPE_TYPE.GROUP: for sub_shape in shape.shapes: process_shape(sub_shape, page_data, depth + 1) return # 表格单独处理 if shape.has_table: table = shape.table table_data = extract_table(table) page_data["tables"].append(table_data) return # 文本框或占位符，提取纯文本 if shape.has_text_frame: text = shape.text.strip() if text: # 记录坐标信息很重要，后面排序要用 page_data["text_blocks"].append({ "text": text, "left": shape.left, "top": shape.top, "width": shape.width, "height": shape.height, "shape_name": shape.name }) # 图片信息（注意：这里只能拿到图片占位，拿不到图片内容） if shape.shape_type == MSO_SHAPE_TYPE.PICTURE: page_data["images"].append({ "name": shape.name, "left": shape.left, "top": shape.top })

这里有个非常重要的经验：shape.text是python-pptx提供的一个便捷属性，它会自动把文本框里的段落用换行拼接。但它的拼接逻辑比较粗暴——所有段落不管什么层级、不管有没有项目符号，一律用\n连起来。如果需要保留段落的层级信息，就得逐段读取：

def extract_paragraphs(shape): """逐段落提取文本，保留大纲级别""" paras = [] for para in shape.text_frame.paragraphs: paras.append({ "text": "".join(run.text for run in para.runs), "level": para.level, # 0表示一级，1表示二级 "bullet": para._pPr is not None }) return paras

段落级别（level）对后续还原PPT的结构层级非常关键，千万不能丢。

3.3 读取备注页里的信息

备注页是PPT里很容易被忽视但价值极高的部分。演讲者的备注里往往藏着PPT画面上看不到的解读：数据口径、业务背景、引用来源。

def extract_notes(slide): """提取备注页文本""" if slide.has_notes_slide: notes_slide = slide.notes_slide notes_text_frame = notes_slide.notes_text_frame return notes_text_frame.text.strip() return ""

有一类场景特别受益于备注提取：培训课件。讲师讲义的文字量往往比幻灯片页面上大一个量级，把这些备注收进来，整个文档库的信息密度立刻就不一样了。

3.4 识别章节页和标题页

一整套PPT基本遵循"封面→目录→章节页→内容页→结尾页"的结构。如果能自动识别每一页扮演的角色，后面做知识库切片就省事很多。

我用的方法是基于文本特征和形状数量的启发式规则：

def classify_slide(text_blocks): """根据提取结果判断幻灯片类型""" if not text_blocks: return "blank_or_image" # 封面：文字块少，且第一块文字字号通常很大 # 目录：文字块通常有一组编号或者"目录"字眼 # 章节页：文字较少，但有一个明显的标题，有时带"第X部分"字样 all_text = "\n".join([b["text"] for b in text_blocks]) if "目录" in all_text or "CONTENTS" in all_text.upper(): return "toc" if "第" in all_text and ("章" in all_text or "部分" in all_text or "节" in all_text) and len(text_blocks) <= 3: return "section_divider" if len(text_blocks) <= 2 and max((b.get("font_size") or 0) for b in text_blocks) > 30: return "cover" return "content"

规则不追求100%准确，做到7成以上能分对就够了。剩下分不对的，后面让LLM后处理兜底，这个问题我后面会细讲。

4. 表格提取这块硬骨头怎么啃

PPT里的表格是提取工作的重灾区。由于PPT表格的处理逻辑和Word、Excel完全不一样，直接读经常拿到一堆拼不起来的字段。

4.1 基础表格转DataFrame

python-pptx读取表格还算友好。它把表格抽象成Table对象，里面是Row、Cell的二维结构：

def extract_table(table): """把python-pptx的Table对象转成二维数组""" rows = [] for row in table.rows: row_data = [] for cell in row.cells: cell_text = cell.text.strip() row_data.append(cell_text) rows.append(row_data) return rows

看起来简单，但这里有个隐藏坑：Python-pptx读取Cell时，如果单元格没有文本内容，返回的是空字符串，而不是None。后续做数据清洗时，空字符串和None的处理逻辑不同，建议在转型时统一：

cell_value = cell.text.strip() or None

4.2 合并单元格：提取流程里最大的"拆弹点"

PPT表格中合并单元格是非常常见的操作。表头跨两列、分组行跨多行，在视觉上很自然，但在数据层面直接导致了一个问题：合并后的单元格，其余被合并的区域会返回空字符串。

举个例子，一个3行3列的表格，"项目"这个单元格合并了3行，那么python-pptx读出来的是：

项目 | Q1 | Q2 | 100 | 200 | 300 | 400

第一列第二行、第三行的位置是空的。如果你直接把这张表塞给下游，别人根本不知道那些数字属于哪个项目。

我的处理策略是"向下填充"：遇到空单元格时，用同一列上一个非空值填充。这段逻辑要注意方向：列合并要向右填充，行合并要向下填充，并且往往需要同时处理。

def fill_merged_cells(rows): """对二维数组做合并单元格填充——向下填充，兼顾向右填充""" if not rows: return rows n_rows = len(rows) n_cols = len(rows[0]) # 先做列方向的填充（向下），再做行方向的填充（向右） # 注意顺序：先向下，再向右，这样两种合并都能覆盖 # 向下填充 for c in range(n_cols): last_value = None for r in range(n_rows): current = rows[r][c] if current is None or current.strip() == "": rows[r][c] = last_value else: last_value = current.strip() # 向右填充 for r in range(n_rows): last_value = None for c in range(n_cols): current = rows[r][c] if current is None or current.strip() == "": rows[r][c] = last_value else: last_value = current.strip() return rows

4.3 跨行跨列嵌套表的处理

还有一种更让人头疼的情况：一个单元格里嵌套了一个mini表格。python-pptx里直接在单元格内访问子表格不太方便，但好消息是cell.text_frame能拿到文字内容，遇到嵌套表格时，可以通过检查cell.has_table之类的属性来捕获：

# 伪代码形式说明：python-pptx对嵌套表的支持并不透明， # 建议遇到这种文件直接用lxml去解析底层的XML

如果PPT里嵌套表的比例不高，我的建议是不要花太多精力去适配——直接把内嵌表的文本拼进单元格文本里即可，保证信息不丢比保证格式完整更优先。

4.4 表格方向信息：识别表头和首列

提取表格只是第一步，更关键的是要告诉下游"哪一行是表头"。我的思路是用位置信息辅助判断：表格的第一行往往是表头，第一列往往是行名。这本身不能百分之百可靠，但作为默认规则，在绝大多数业务PPT里是成立的。

def table_to_dict(table_data): """把二维表格转成字典列表，默认第一行为表头""" if not table_data: return [] header = table_data[0] data_rows = table_data[1:] result = [] for row in data_rows: # 让空表头列自动编号：Header_1、Header_2…… record = {} for idx, value in enumerate(row): key = header[idx] if idx < len(header) and header[idx] else f"Column_{idx+1}" # 同一列重名的表头需要去重 if key in record: key = f"{key}_{idx}" record[key] = value result.append(record) return result

如果后续有明确的业务字段清单，这一步就用不上，直接按字段名映射就行。但作为通用能力，把表格转成"表头+记录列表"的结构，下游怎么用都舒服。

5. 从"提取"到"结构化"：JSON Schema设计的实战经验

提取出文本和表格只是原始素材。要真正做到"把演示文档变成结构化数据"，还必须有一个稳定的、贴合业务场景的JSON Schema。这一节讲的是我反复迭代后沉淀下来的设计思路。

5.1 数据模型的层次：演示文稿 > 幻灯片 > 内容块

不要把所有信息平铺成一个巨大的JSON数组——那样下游解析时痛苦万分。我推荐三层嵌套结构：

{ "document_id": "ppt_2025_001", "document_name": "2025年Q1业务复盘.pptx", "total_slides": 12, "pages": [ { "page_no": 1, "page_type": "cover", "title": "2025年Q1业务复盘", "text_blocks": [], "tables": [], "images": [], "notes": "" } ] }

这个结构的关键在于：每一页都有独立的page_type标记，下游做知识库切片时可以直接按这个字段过滤。比如只索引"content"页的内容，封面和目录页跳过，能省不少存储和检索开销。

5.2 一张Schema字段设计对照表

我把自己常用的字段和用途整理成了一张表，直接照着用就行：

5.3 用启发式规则补全"页面标题"

提取出来的文本块是零散的，但每页通常都有一个"主标题"。怎么确定哪个文本块是标题？我用的规则按优先级排序：

1. 形状名称包含"Title"或"标题"字样的占位符，优先度高；
2. 字号最大的文本片段；
3. 位置在页面上方1/3区域内的文本块。

混合使用这三条规则，标题识别的准确率能到85%以上。代码实现大概长这样：

def infer_page_title(text_blocks): """推断页面主标题""" if not text_blocks: return None # 规则1：找形状名里带Title的 for block in text_blocks: shape_name = block.get("shape_name", "") if "title" in shape_name.lower() or "标题" in shape_name: return block["text"] # 规则2：找字号最大的 candidates = [b for b in text_blocks if b.get("font_size")] if candidates: max_size = max(b["font_size"] for b in candidates) # 防止封面页大字串场：内容页标题字号一般集中在20~36pt top_size_blocks = [b for b in candidates if b["font_size"] == max_size] if top_size_blocks and max_size >= 18: return top_size_blocks[0]["text"] # 规则3：位置在页面上方，且横向居中 top_area = [b for b in text_blocks if b.get("top_mm", 0) < 40] if top_area: top_area.sort(key=lambda x: x["left_mm"]) # 取最靠近横向中间位置的那个 middle_left = min(top_area, key=lambda x: abs(x["left_mm"] - 75)) return middle_left["text"] return text_blocks[0]["text"] if text_blocks else None

5.4 把零散文本拼接成"可读正文"

有了标题，还要处理正文。多个文本框可能是同一段落拆开的，或者视觉上属于同一结构。这一步我的做法比较朴素：按坐标排序之后，用空行分隔合并成一个整体文本。

def text_blocks_to_article(text_blocks): """把坐标排序后的文本块合并成一篇文章，保留顺序""" blocks = sorted(text_blocks, key=lambda b: (b["top_mm"], b["left_mm"])) lines = [] for block in blocks: text = block["text"] # 跳过纯数字页码 if text.isdigit() and len(text) <= 3: continue lines.append(text) return "\n".join(lines)

排序的tuple用了两个维度：top_mm精确到毫米，保证同一行的多个文本框按从左到右排列。对大多数内容页来说，这个方案已经能还原出很接近原始阅读顺序的文本了。

6. 一批乱得离谱的PPT实测复盘与处理策略

理论讲完了，下面是我从两百多份真实PPT里踩出来的几个典型案例，每一类都有对应的处理策略，希望你别重复走弯路。

6.1 形状重叠导致文本重复提取

业务PPT里常有装饰性的半透明色块压在文字上方。python-pptx会把它当作一个独立shape。如果这个半透明色块里也有文字（有些设计师喜欢在里面放一点标签），那提取时同一区域就会出现两段文字叠在一起。

我的处理方案是增加"重叠检测"：如果两个文本块的包围盒重叠面积超过50%，就保留坐标在上层的那一个。判断层级可以通过读取shape._element里的<a:off>顺序，或者直接看shape在shapes列表里的index（index越大越靠上层）。

def is_overlap(rect1, rect2, threshold=0.5): """判断两个矩形是否重叠超过阈值""" # rect: (left, top, right, bottom) x1 = max(rect1[0], rect2[0]) y1 = max(rect1[1], rect2[1]) x2 = min(rect1[2], rect2[2]) y2 = min(rect1[3], rect2[3]) if x2 <= x1 or y2 <= y1: return False inter_area = (x2 - x1) * (y2 - y1) area1 = (rect1[2] - rect1[0]) * (rect1[3] - rect1[1]) if area1 == 0: return False return inter_area / area1 >= threshold

6.2 多级列表缩进全部丢失

PPT里做多级列表通常是用段落级别或者首行缩进实现的。python-pptx读取段落level时会给出一个数字（0、1、2），这个数字对应的是"大纲级别"设置。

但问题在于：很多人做缩进并不是改大纲级别，而是直接手动加空格或者敲Tab。这种情况下，段落level全是0，文本前却多了一长串空格。

处理方式：提取时把"字符串开头的空白字符"也作为一种缩进信号，和level字段结合起来判断：

import re def get_indent_level(para): """综合段落级别和文本缩进判断层级""" level = para.level text = "".join(run.text for run in para.runs) leading_spaces = len(text) - len(text.lstrip(" \t")) if leading_spaces > 0: level = max(level, min(leading_spaces // 2, 4)) return level

这招不能保证100%准确，但在大多数场景下能把层级关系还原得七七八八。

6.3 截图型PPT怎么处理

相当一部分PPT，特别是外部供应商提供的方案，里面大量内容都是截图：竞品分析截图、系统页面截图、聊天记录截图。这些内容程序提取不到文本，只有一张图片。

这类内容的价值在于：图片里可能藏着关键信息。要提取它，只能上OCR。我自己常用的是离线方案，在服务器上部署PaddleOCR，准确率不错而且不需要联网。流程上，我在前面加了一步判断：如果一张图片占满了几乎整页（宽度超过页面80%、高度超过页面80%），就单独标记为full_page_image，走OCR管线；否则只记录图片位置，不做OCR，因为小图OCR性价比太低。

6.4 SmartArt图表的提取

SmartArt在程序里的本质是一组预设几何形状的组合，它的文本散布在多个shape里。python-pptx无法直接判断一个组合是不是SmartArt，但可以通过底层XML判断：

def is_smartart(shape): """判断shape是否为SmartArt""" try: return shape._element.findall('.//{http://schemas.openxmlformats.org/drawingml/2006/diagram}relIds') except Exception: return False

SmartArt的提取策略很简单：文本是逐块分布的，直接收集所有子shape的文本并保持顺序就行。结构关系（哪个框指向哪个框）很难还原，对知识库来说，文本完整就够了。

6.5 处理"只有一个标题，正文全是图片"的页面

这种页面常见于产品介绍PPT：一个大标题，下面一张产品高清大图。提取结果就是标题+图片引用。遇到这种情况，我会特别标注"本页无文本正文"，交给下游时提示可能需要人工补录或者走图像识别，避免被当成空页处理掉。

7. 数据落地：从JSON到知识库/Excel/问答应用

把结构数据生成JSON只是第一步，真正产生价值的是下游应用。这节分享几个我已经在用的落地场景，可以直接借鉴。

7.1 切片给大模型做RAG或问答

最直接的应用是把JSON按"幻灯片+备注"切块，投喂给检索增强生成（RAG）系统。切片策略上，我建议以页为最小单位，不要跨页拼接。如果一页内容超过3000字，再按段落切分。

def build_rag_chunks(structured_data): """把结构化PPT数据转成RAG切片""" chunks = [] for page in structured_data["pages"]: if page["page_type"] == "content": title = page.get("title") or "" body = text_blocks_to_article(page.get("text_blocks", [])) tables_text = "" for idx, table in enumerate(page.get("tables", [])): tables_text += f"\n表格{idx+1}:\n" for row in table: tables_text += " | ".join([str(c) if c is not None else "" for c in row]) + "\n" notes = page.get("notes") or "" chunk = { "page_no": page["page_no"], "title": title, "content": f"{title}\n{body}\n{tables_text}\n备注:{notes}" } chunks.append(chunk) return chunks

切片这块有个小建议：把表格转成文本时用竖线分隔，比如项目 | Q1 | Q2，大模型对这种格式的理解远好于二维数组JSON。原因也不复杂：预训练语料里Markdown表格本来就不少，模型对竖线分隔天然熟悉。

7.2 批量汇总成全量Excel

还有一种常用的落地方式：把所有PPT里的表格全部汇总到Excel里，做成一个俯瞰全局的台账。比如几十份业务复盘PPT，每份里都有"核心指标"那张表，汇总到一张大表里，就直接能比对了。

思路是：解析每份PPT的JSON，把候选表格（通过表头关键字过滤，比如"指标""数据""金额"）统一抽取出来，用pandas纵向拼接后写出。

import pandas as pd def merge_tables_to_excel(all_data, output_path): """汇总多份PPT里的表格到单个Excel文件""" frames = [] for doc in all_data: for page in doc["pages"]: for table in page.get("tables", []): if len(table) < 2: continue # 至少要有表头加一行数据 header = [str(c) if c else f"列{i}" for i, c in enumerate(table[0])] df = pd.DataFrame(table[1:], columns=header) df.insert(0, "来源文档", doc["document_name"]) df.insert(1, "页码", page["page_no"]) frames.append(df) if frames: result = pd.concat(frames, ignore_index=True) result.to_excel(output_path, index=False)

这个方案最大的好处是：把原来需要人工一页页翻Excel的活，压缩成了跑一段脚本的工作。实测下来，90份PPT汇总到一张总表，耗时不到5分钟（包含JSON生成）。

7.3 页面类型统计和文档体检

结构化的另一个好处是可以做"文档质量体检"。比如统计一份PPT里"文字太少"的页面有多少、图片页占比多高、有没有备注信息。这些指标对内容团队改进PPT制作质量很有参考价值。

def document_health_report(data): """生成PPT结构健康报告""" total = data["total_slides"] content_pages = [p for p in data["pages"] if p["page_type"] == "content"] image_only_pages = [p for p in content_pages if not p["text_blocks"] and p["images"]] no_notes_count = sum(1 for p in data["pages"] if not p.get("notes")) report = { "总页数": total, "内容页数": len(content_pages), "纯图片内容页占比": f"{len(image_only_pages) / max(len(content_pages), 1) * 100:.1f}%", "无备注页占比": f"{no_notes_count / max(total, 1) * 100:.1f}%" } return report

这个报告在公司内部推行后，团队重新梳理了对外PPT的模板规范——很多"信息黑洞"页面被提前发现，整个知识库的质量上了一个台阶。

8. 进阶：用大模型做一轮后处理

规则管线解决了80%的问题，剩下20%靠正则和判断很难搞定。这20%里，最典型的就是"这页到底在讲什么"这样的语义判断。现在的大模型恰好擅长这个，我用LLM做后处理，把整个管线的可用性拉到了95%以上。

8.1 什么时候需要LLM后处理

我的判断标准很简单：只要下游任务涉及"语义理解"，就需要LLM。比如：

• 判断某个页面是不是"产品介绍页"；
• 给页面生成一句摘要；
• 把零散的表格字段标准化成固定维度；
• 校正标题识别的错误。

如果只是把文本灌进关键词搜索里，那规则管线就够了，没必要每次都调大模型烧钱。

8.2 一个LLM后处理的调用示例

我用DeepSeek API做后处理，流程上注意控制返回格式。这里贴一个生成页面摘要的提示词示例：

from openai import OpenAI client = OpenAI( api_key="your-api-key", base_url="https://api.deepseek.com" ) def generate_page_summary(title, text_blocks, notes): """调用大模型生成页面摘要""" content = f"标题: {title}\n正文片段: {text_blocks[:1500]}\n备注: {notes[:500]}" resp = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你是一个PPT内容分析助手。请根据给出的页面内容，用一句话概括该页的核心观点，不要输出与摘要无关的内容。"}, {"role": "user", "content": f"请为以下PPT页面生成摘要：\n{content}"} ], temperature=0.3, max_tokens=200 ) return resp.choices[0].message.content.strip()

注意几点：一是temperature要调低，保证稳定输出；二是给足"系统提示词"，告诉模型你只要一句话摘要，别让它自由发挥；三是输入文本要加长度截断，避免token超限。

8.3 后处理结果的回填策略

模型生成的摘要、规范化字段要写回JSON里的新字段，不要让它们覆盖原始内容。我用了一个约定：所有模型生成的结果统一放derived字段下，原始提取结果保持原样。

structured_data["pages"][i]["derived"] = { "summary": summary, "page_type_predicted": predicted_type }

这样设计的好处是可追溯：后期想对比规则判断和模型判断的区别，随时能拉出来看，不会污染原始数据。

9. 这套流程的性能与规模验证

最后交代一下实测数据，方便你对这套方案的整体产出能力有个概念。

测试环境：8核CPU、32GB内存、无GPU。数据源：286份企业内部PPT，总页数4127页，文件大小从几百KB到200MB不等。

有几份文件特别难处理：一是页数超过300页的性能怪兽，二是嵌入了大量高清图片的"图库型"PPT，三是文件损坏但PowerPoint能自动修复的"残次品"。针对第三种情况，我建议读取前先在线做一次有效性检查：

from pptx import Presentation try: prs = Presentation("有问题的文件.pptx") except Exception as e: print(f"读取失败: {e}") # 可以考虑用win32com或其他方式先修复

如果公司里Windows环境占主流，遇到损坏文件可以直接用PowerPoint的自动化接口另存一份，绕开python-pptx的读取限制。

——

我自己现在日常处理文档的流程已经固定成：pptx先走这套"解析+提取+LLM后处理"的管线，生产出标准化JSON，再根据需要分发到RAG、Excel台账、质检报告等下游任务。整个体系不是一次性搭完的，而是在处理一批批真实文件的过程中逐步加规则、补bug才稳定的。如果你也要做类似的事，建议一开始别追求完美，先跑通100份文件，把高频的坑都踩一遍，后面的迭代速度就快了。这套方案可能不够优雅，但它扛住了真实业务场景的考验，这是我觉得最值得分享的价值所在。