企业官网建设流程全解析

这几年我有一半的工作时间耗在整理文档上：不管是简历、合同、发票还是项目验收报告，要做个评审，就得先把几十份材料里的关键字段“抄”到一张汇总表里。这个过程不难，但是极其消耗人：你看一份简历要三分钟，抄一份合同条款要十分钟，等搞到两百份材料的时候，整个人都会变得很暴躁。

最近某位AI领域的知名讲师推了一门新课，标题很直白——用AI一键提取文档信息。我看到这个题目的第一反应是：这个方向终于有人认真讲了。文档信息提取，学术界叫信息抽取，是个很老的方向，老到以前做这种系统的人都在跟正则表达式和模板规则缠斗。大模型出来之后，这个事情的形态整个变了：你不再需要写一条一条规则，只需要让模型读文档，再按你定义的字段清单把答案吐出来。

这篇文章不打算复述那门课，而是从我实际做过的几个提取项目出发，把“AI一键提取文档信息”的完整链路拆开讲清楚：需求到底有多大、技术管道怎么搭、实测中最要命的坑是哪些、怎么保证结果真的能落地。适合两类人看：一类是刚听说AI提取文档信息、想快速入门的新人；另一类，是已经做了简单Demo、但一上真实数据就翻车的同学。

1. 从“逐份手翻”到“一句话出结果”：这个需求到底有多大

1.1 那些年我们手动整理过的文档

文档信息提取不是小众需求。我做过的项目里，最常见的是这几类：

• 简历筛选：帮团队从两百份简历里抽出姓名、工作年限、技能栈、最近一家公司、期望薪资。以前是HR一页页翻，再把关键信息敲进表格，一份三分钟，两百份就是一个完整的工作日。
• 合同条款整理：法务或者商务同事需要把合同里的甲方乙方、合同金额、付款周期、违约金比例、保密期限抽出来，做成台账。一份合同十几页，读完再摘录，很考验耐心。
• 发票和报销单：财务每个月要处理几百张发票，抽出开票日期、商户名、金额、税号。好在发票格式相对固定，但不同年份、不同票种的版式差异，仍然让各种“智能识别”方案在真实数据上翻车。
• 验收报告和项目材料：验收时要把几十份报告里的核心指标、结论、遗留问题抄出来，按模板汇总给专家看。

这些场景的共性是什么？字段是清晰的，格式是混乱的。你要的信息就那么几个字段，但承载信息的文档长什么样五花八门。这正好是传统规则方案搞不定的地方，也正好是“AI提取”能切入的地方。

1.2 为什么正则和表单工具替代不了人

很多人听到“自动提取”，第一反应是写正则表达式。确实，我是从正则时代过来的，那个年代做信息抽取，核心工作就是研究“不同写法之间的公约数”。

比如一个日期字段，文档里可能是“2024年1月1日”，也可能是“2024/1/1”，还可能是“2024-01-01”，甚至“一五年底”。你写一个正则需要覆盖所有情况，再叠加各种边界情况，表达式会膨胀到你下个月就看不懂。更麻烦的是，文档一旦换了一个版式，之前的正则就废了一大半。信用卡账单和手机话费单，都能长成完全不同的样子，规则系统维护成本极高。

还有一类方案是上线“表单平台”，本质是让录入员在一个网页里手敲，只是把Excel变成了在线表单。这种方案没有减少人力，只是把人工搬到了另一个界面。所以回到问题的本质：文档信息提取真正的瓶颈不是“工具”，而是“理解”——把一段非结构化的自然语言，准确地映射到一批结构化的字段上。这个“理解”环节，以前必须由人来做，现在大模型可以代劳了。

1.3 大模型改变了什么，又没改变什么

大模型出现后，信息提取的思路变成：我把要提取的字段和它们的含义描述清楚，再把文档全文丢给模型，让模型“读完之后”按照我的字段定义输出结构化结果。就像你请了一个理解力一般的实习生，你告诉他抓哪些字段、字段是什么含义、拿不准的地方空着别乱填，他看一遍文档，会帮你把表格填好。

这个范式带来了两个改变：

1. 换文档格式不再需要重写规则。同样是抽“合同金额”，扫描版合同、Word合同、PDF合同，字段含义一致，只需改很少的提示词，不用改核心逻辑。
2. 处理复杂语义变容易了。像“验收结论是同意还是附条件同意”这种判断，规则很难定义，模型可以基于上下文理解。

但大模型没改变的事情更重要：

• 模型输出不保证100%准确，它偶尔会“脑补”原文没有的内容；
• 长文档有上下文窗口限制，不能指望一次性把整本合同都塞进去；
• 字段清单本身需要人来设计，这也是全流程里最考验经验的部分；
• 落地到生产环境，你仍然需要校验、人工复核、异常处理，而不是“模型输出即答案”。

换句话说，AI解决的只是“抄写”这个环节，字段设计、数据校验、结果兜底这些脏活累活，还得自己做。这也是这篇文章后面大半部分要展开的内容。

2. 文档提取的核心链路：读取、清洗、切分、抽取、校验逐段拆解

一套完整的文档信息提取链路，基本是下面八步：文档载入、格式解析、文本清洗、语义单元切分、模型结构化抽取、结果校验、输出落库、人工复核闭环。很多人做Demo时只关心“调用模型”那一步，实际上前面三步和后面两步才是决定成败的地方。

2.1 第一公里：文档格式解析决定成败

先说文档载入。拿PDF举例，同样是PDF，本质上有两种完全不同的形态：

• 文本型PDF：里面有真正的文本层，可以直接提取出文字，速度快，精度高。
• 扫描型PDF：本质是一张一张图片，必须经过OCR（光学字符识别）才能得到文字。
• 混合型PDF：部分页是文本，部分页是扫描图，最常见于“客户发过来的纸质材料再扫描合成一个PDF”的场景。

所以第一步不是“提取”，而是“判断这个文件到底是哪种”。判断方法不复杂：试着提取文本层，如果一页里能提取出的有效文字低于阈值（比如每页少于50个字符），就判定为扫描型，走OCR路线。这个阈值要根据你的文档情况调，我常用的经验值是按页判断，连续两页低于阈值就整篇走OCR。

OCR环节，中文扫描件的识别精度和英文差距不小，尤其是碰到带表格、带印章、带图片说明的文档。表格线会把文字“切”断，印章盖在数字上会直接遮挡信息。流程上建议先做图像预处理：转灰度、去噪、适当锐化，有条件的话做倾斜矫正。处理完之后再丢给OCR组件，识别率会明显提升。扫描件这一环如果没做好，后面模型再聪明也没用，因为输入就是脏的。

2.2 语义切分：别把“按窗口切”和“按逻辑切”混为一谈

拿到纯文本之后，下一个关键步骤是切分。这里有个容易踩的误区：很多做检索问答的人习惯了“固定窗口切块”，比如每块512个token、相邻块重叠100个token。这个做法在RAG检索场景下没问题，但在结构化提取场景下会出大问题。

为什么？因为提取的目标是“把一个完整对象的信息送给模型”。比如一份简历，一个人的完整信息可能正好分布在一个半页面里，你按512 token硬切，就可能把“工作经历”切到上一段，把“教育经历”切到下一段，模型每块都只看到残缺信息，提取结果自然残缺。

正确的做法是按逻辑边界切分：

• 优先按空行、章节标题、编号（第1条、第2条）、表格结构切；
• 切出来的每个块，尽量是一个“语义单元”；
• 同时限制块的最大长度，超过上限再按句号或逗号做二次切分。

我常用的策略可以概括为“标记优先、长度兜底”。先看文档里有没有明显的标题空行，有就按这些切；切出来发现某一段太长，再在段落内部找关键断点切开。这样做的好处是，模型看到“一整份简历的核心段落”或“一整条合同条款”的概率大幅提高，提取质量也会随之提升。

2.3 结构化抽取：让模型按你的字段清单交作业

这一步是整条链路的心脏。字段清单的写法，决定了模型能不能稳定输出。

先说字段Schema，我一般直接用JSON格式描述：

{ "type": "object", "properties": { "姓名": {"type": "string", "description": "候选人姓名，例如：张三"}, "工作年限": {"type": "integer", "description": "工作总年限，单位年"}, "技能栈": {"type": "array", "items": {"type": "string"}, "description": "候选人的技术技能列表"}, "离职状态": {"type": ["string", "null"], "enum": ["在职", "离职", "未知"], "description": "目前的工作状态"} }, "required": ["姓名", "工作年限", "技能栈"] }

写这段Schema有三个要点：

1. 每个字段都给示例。“姓名”这个字段如果只有type没有description，模型可能把“王小明”和“王某”理解成两种格式，有了示例它会照葫芦画瓢。
2. 允许null。不是所有字段每份文档都有，字段设计时就要允许null，明确告诉模型“没有就填null”。
3. 用enum约束枚举字段。像离职状态这种有限选项，用enum可以极大减少模型的自由发挥。

Prompt的写法，我的固定模板大概长这样：

请阅读下面的文档片段，根据字段定义提取信息。 字段定义： {JSON Schema} 要求： 1. 只提取文档中明确出现的信息，禁止根据常识推断或补充。 2. 如果文档中没有某个字段的信息，字段值填null。 3. 输出必须是合法的JSON对象，不要输出任何解释性文字。 4. 遇到歧义信息时，取文档中最直接明确的表达。 文档片段： {原文片段} 输出JSON：

这段Prompt里，“禁止根据常识推断”和“没有就填null”是关键。如果没有这两句，你很快会见到模型开始编造数据的场景——这事我下一章专门讲。

在实际接口层面，现在主流的大模型服务都支持“结构化输出”或“函数调用”模式，你直接把Schema传进去，模型会保证返回的JSON符合Schema约束。这种模式比自己解析模型自由输出的文本要稳得多，强烈建议优先使用。如果你用的模型不支持，就只能在Prompt里要求JSON格式，然后自己在代码里做解析容错。

2.4 校验不是附加题，是必答题

模型把JSON吐出来，不等于事就完了。直接落库，等于把模型的“幻觉”直接放进业务系统，早晚出问题。我见过的合格项目，至少要做三层校验：

• 必填字段校验：Schema里标记为必填的字段，值不能为null。如果为null，说明模型没找到信息，需要记录缺失原因。
• 格式校验：日期字段是否真正是日期，金额字段是否是数字，枚举字段是否在允许列表内。类型不符就标记异常。
• 业务一致性校验：比如合同“生效日期”必须早于“结束日期”，如果出现矛盾，说明提取结果至少有一处是错的。

这三层校验写起来不复杂，但能把模型输出里相当一部分明显错误挡在外面。校验不通过的记录不要直接丢弃，而是进“人工复核清单”，后面会有专人处理。

3. 实操代码：搭一个可复用的批量提取管道

讲完原理，我直接给一套可以照着改的最小实现。代码不是完整生产级，但骨架是对的，你往上补业务逻辑就行。

3.1 环境准备与选型，先别急着上复杂框架

新手经常犯的一个错，是一上来就引各种重量级框架。我的建议是，做提取管道这种任务，先老老实实用基础工具：

• 语言：Python，3.10以上，生态最省心。
• 文档解析库：PDF文本提取和OCR各选一个自己熟悉的库即可，重点是把“文档转纯文本”这个函数封装好。
• 大模型接口：任意支持“结构化输出”或“函数调用”的对话模型都可以。注意看它的JSON约束能力，这比看它的“单轮对话聪明不聪明”更重要。
• 输出存储：批量任务先用JSONL文件存中间结果，简单直观，方便断点续跑。

3.2 单文件提取核心逻辑

先写一个单文件提取的函数骨架：

import json def process_document(file_path: str, schema: dict) -> dict: # 1. 解析文档为纯文本 text = extract_text(file_path) # 2. 如果文本过少，说明可能是扫描件，走OCR流程 if len(text.strip()) < 80: text = ocr_scan(file_path) # 3. 按语义边界切分 blocks = split_semantic_blocks(text) # 4. 对每个块做抽取 results = [] for block in blocks: if not has_potential_fields(block, schema): continue partial = extract_fields_with_llm(block, schema) results.append(partial) # 5. 合并多个块的抽取结果 merged = merge_results(results) return merged

这里几个函数的核心逻辑分别是：

• extract_text：调用你的PDF文本提取库，返回纯文本。注意保留段落间的换行标记，这比把所有内容挤成一行有用得多。
• ocr_scan：扫描件转文本，建议在预处理阶段做灰度化和去线处理。
• split_semantic_blocks：按空行和编号切分，返回块列表。
• has_potential_fields：一个启发式过滤器，判断这个块里是否有可能出现目标字段。比如提取“姓名”时，如果块文本里连一个人名都看不到，就可以直接跳过，节省调用成本。
• extract_fields_with_llm：核心调用函数，把块和Schema一起发出去。

extract_fields_with_llm的关键实现，大概是这个模式：

import json def extract_fields_with_llm(text_block: str, schema: dict) -> dict: prompt = build_extract_prompt(text_block, schema) raw = call_llm_json(prompt, schema) # 使用结构化输出模式 # 如果接口不支持结构化输出，需要对raw做json解析容错 return raw

3.3 批量处理、断点续跑与并发控制

单文件跑通之后，批量只是重复执行。但批量任务有两个坑必须处理：中断恢复和限流。

中断恢复的做法很简单：每处理完一个文件，就立刻把结果追加写入一个JSONL文件。这样程序中途挂了，下次启动时先读一遍已经完成的任务列表，跳过它们继续跑。别等全部完成再一次性写，不然跑了两个小时突然断网，全白干。

from pathlib import Path def run_batch(file_list, schema, output_path): done_files = get_done_files(output_path) for file_path in file_list: if file_path in done_files: continue try: result = process_document(file_path, schema) append_jsonl(output_path, {"file": file_path, "result": result}) except Exception as exc: append_jsonl(output_path, {"file": file_path, "error": str(exc)})

限流方面，大模型接口一般都有每分钟请求次数限制。批量任务建议用线程池控制并发数，跑一部分之后观察返回状态，遇到限流错误就退避重试。我的经验值是并发3到5个请求比较稳妥，具体看接口配额。

3.4 出错的兜底：解析失败和非法JSON怎么处理

真实数据里一定会出现“模型输出不是合法JSON”的情况。原因可能是上下文被截断、输出被限制、或者模型中途放弃。兜底逻辑我建议按下面顺序处理：

1. 正则提取最外层大括号，从原输出里挖出疑似JSON片段。
2. 尝试修正常见错误：单引号替换双引号、去掉末尾多余的逗号。
3. 修复不了就重试一次，但最多重试两次，避免消耗太多调用费用。
4. 仍然失败就记录原样输出，进入人工复核清单。

还有一类错误是“模型返回了合法JSON，但字段明显不对”。比如提取合同甲方，模型返回了一个人名而不是公司名。这种问题靠代码兜不住，必须回到Schema和示例去调。所以批量跑第一版时，不要追求直接出最终结果，而是先跑一小批，看看失败的分布再动手改。

4. 实测翻车记录：OCR乱码、跨页截断、幻觉字段的应对方案

这章是我最想写的部分。纸上谈兵都很顺，真实数据里我几乎每个项目都踩过同样的坑，整理出来给大家省点时间。

4.1 扫描件表格线把文字打断

有一批扫描版的报销单，表格里“项目名称”那一列，OCR出来的结果经常是“项目名 称”或者“项目名1称”。为什么？表格线在图像上是一条连续的黑线，OCR引擎在做字符切分时，偶尔会把表格线识别成一个干扰字符，或者把紧挨着表格线的汉字切开。这种错误很典型，越是在表格密集的文档里越容易出现。

我的处理办法分两步。第一步是图像预处理阶段做“去线”——检测横向和纵向的长直线，把它们从二值图里抹掉，这样表格里的文字就干净了。第二步，在Prompt里加一句提示：“如果字段值中出现明显异常的孤立字符，请结合上下文修正。”注意，这只能解决简单情况，如果OCR错误太严重，你必须回到图像处理去重跑，不能指望模型当“万能纠错器”。

4.2 长文档跨页引用，字段提取不全

合同类文档很多是跨页引用的。比如合同前面定义“甲方”是某公司，后面有一页写“甲方应于合同生效后30日内付款”。如果你是按页切块，模型在只看后面那页时，根本不知道“甲方”是谁，提取结果就是null。

这个问题我试过几种方案，真正有效的是**“先全局后局部”的两段式抽取**。第一步，先把全文塞给模型，只让它提取文档级的关键主体和定义，比如“合同双方分别是哪两家公司”“合同编号是多少”。第二步，切块提取细节字段时，把第一步得到的全局信息作为背景一并放进Prompt。这样每个块在提取时都带着“上下文”，跨页引用的问题基本能解决。

注意全局信息这一步，如果文档太长超过上下文窗口，就要先做摘要再抽取。你可以让模型先按章节生成结构化摘要，再从摘要里提取“全局字段”，这种方式对超长文档更稳。

4.3 模型“脑补”了文档里没有的信息

这是所有坑里最危险的。有一次提取简历，“离职时间”字段文档里根本没有写，模型给填了“2024年6月”。看起来非常合理——可能它根据工作经历的结束时间推断出来的——但它就是文档里不存在的信息，一旦被下游直接采用，会出业务事故。

为什么会这样？因为大模型在生成时天然倾向于“补全一个连贯的答案”，空着不填反而会让它觉得不完整。对策必须多管齐下：

• Prompt里写明“只提取明确出现的信息，没有就fill null”；
• 字段Schema里用type: ["string", "null"]并在description里再次强调；
• 要求模型在返回结果的同时，给出每个非空字段的“原文证据”，也就是从文档里摘出一段原话作为支撑；
• 后置校验里加一条：如果某个字段的值非常常见，同时它的原文证据为空，就标记为人工复核。

“原文证据”这个设计特别好用。它把模型输出变成了“可解释”的状态，后面人工复核时不用再翻整篇文档，只需要对照证据片段就能快速判断对错。

4.4 同文档多实体时，字段定义直接决定结果质量

还有一次是提取合同条款，文档里“乙方”出现了两家公司，因为Schema里我只把“乙方”定义成字符串，模型每次只返回第一个发现的公司，另一个被遗漏了。后来改成数组类型，并给了明确的少量示例（few-shot），模型才稳定地返回全部乙方。

{ "乙方": { "type": "array", "items": { "type": "object", "properties": { "公司名称": {"type": "string"}, "地址": {"type": ["string", "null"]} } }, "description": "合同中的全部乙方，一个公司一个对象" } }

这个教训是：字段定义本身就是在教模型理解任务。你把“乙方”定义成字符串，模型就理解为“找第一个乙方”；你定义成数组，它才知道“要把所有乙方都收进来”。所以动手写Prompt之前，先认真把字段清单当成数据模型来设计，每一个多值可能性都要想清楚。

5. 效果评估与“人机协同”兜底：让提取结果真正能落地

做到这一步，管道能跑通，坑能规避，但离“放心上线”还有距离。很多项目死在最后这关：没有评估，没有兜底，模型输出直接进系统，出了几次错就没人敢用了。

5.1 别凭感觉判断准确率，先做一版黄金样本

评估提取效果，不能靠“我看着挺好”这种主观判断。正确做法是：挑30到50份有代表性的文档，人工把答案标好，做成“黄金样本”。然后让管道对这30份文档跑一遍，逐字段比对结果。

比对指标用信息抽取领域的经典三个数：精确率、召回率、F1。在这里：

• 精确率，关注的是“模型输出的字段值里，有多少是对的”；模型容易乱编，精确率就会很难看。
• 召回率，关注的是“黄金样本里存在的字段值，模型找回了多少”；模型漏填太多，召回率就低。
• F1，综合两者。

我习惯把结果整理成一张字段级别的评估表：

有了这张表，你才能跟业务方说清楚“哪个字段可以自动用，哪个字段必须人工复核”。比如甲方名称准确率高，可以直接采信；付款周期错误多，就必须设计人工复核清单。

5.2 用置信度标记和人工复核清单兜底

在真实业务里，我不追求“全自动100%准确”，那既不现实也不安全。我追求的是“大部分字段自动，少部分敏感字段人工确认”。实现方式是在管道里加入置信度标记规则：

• 模型返回null时，标记为“缺失”。
• 格式校验失败时，标记为“格式异常”。
• 原文证据片段为空时，标记为“待复核”。
• 业务一致性校验失败时，标记为“逻辑冲突”。

所有被标记的记录，汇成一张“人工复核清单”。复核页面不需要做得多复杂，只要展示三样东西：原始文档片段、模型抽取结果、模型给的原文证据。人工只需要做选择题：对，或不对。这样做，复核速度可以做到每条约10秒，远比从头看文档快。

5.3 把复核结果回流到提示词，形成迭代闭环

人工复核过程中修正过的结果，不要浪费。它们是最宝贵的训练信号——不是用来微调模型，而是用来改进Prompt。每隔一段时间，把复核结果里“模型做错了但人改正了”的例子，挑选一部分做进few-shot示例，再跑一次黄金样本，看指标是否提升。

我见过最成功的做法是，每次迭代保存一版Prompt版本，跑一次黄金样本，记录指标。当Prompt越调越复杂、指标不再提升时，说明已经到了当前模型能力的瓶颈，这时候再考虑换更强的模型或者微调。这个闭环每个月跑一次，项目的准确率能稳定在可接受范围内。

6. 给新人的三条路线建议

课程可以告诉你“怎么调用接口”，但真正能把文档信息提取做成生产级的人，靠的是对细节的死磕。我做了几个项目之后，有几个体会特别深，写在这里当收尾。

6.1 从字段化程度高的文档开始

新手入门，不要一上来就做无固定格式的开放文档，比如“从一堆新闻里抽事件脉络”，那太难了。先做简历、名片、发票、银行流水这类字段固定、边界清晰的文档。这类文档的“正确答案”非常明确，你很容易判断模型做得好不好，也容易积累Prompt调优的感觉。

6.2 先手动调试单文件，再写批量管道

我见过太多人一上来就搭批量任务，结果跑出来一百条结果里四十条是错的，再去一条条排查原因，效率极低。正确顺序是：先拿5份文档，单文件手动跑，逐条检查输出质量，把Prompt调到满意；再拿30份文档跑批量，统计错误分布；最后才考虑全量上线。每一步都在验证上一阶段的假设。

6.3 保持可解释性：每个输出都能回溯到原文

最后也是最重要的一条：任何自动提取的结果，原则上都要能回溯到原文。模型输出某个字段值，必须能出示原文证据。这在业务上是刚需——没人敢采信一个说不清来源的信息。技术上也好实现，我前面说的“原文证据”设计就是这个目的。记住这句话：让模型说“原文哪里写了”，而不是让它“自己认为”。

AI一键提取文档信息，这件事本身的技术门槛已经很低了，难的是把准确率、可解释性、人工复核流程串起来。你只要把前面这几章说的链路走一遍，踩过几个坑，很快就能做出比“手动整理快十倍”的东西。工具一直在变，但“想清楚字段、校验结果、让人能复核”这套方法论，什么时候都不会过时。