企业官网建设流程全解析

纸质单据这件事，做过企业信息化的人都知道它有多磨人。财务、仓储、物流、医疗、政务窗口，每天成百上千张送货单、报销单、入库单、检验报告在流转，录入靠人眼加键盘，一张单子从拿到手到进系统平均要花两到五分钟，错一个字后面全盘返工。我见过一家做建材批发的公司，三个文员全职录单据，月底对账还是对不上，问题就出在手写数字"7"和"1"、"6"和"0"的识别上。这两年 OCR 技术成熟了不少，但真正把"扫描识别—自动存档—对话式分析"这条链路完整跑通、还能让业务人员自己用起来的方案，依然不多。这篇要聊的，就是基于 MCP 协议对接 WorkBuddy，把结构眼 AI 智能扫描仪这套东西落到企业真实单据场景里的完整思路和实操细节。不管你是技术负责人、业务主管，还是刚接触 AI 工具想找落地场景的从业者，这里面的选型逻辑、踩坑记录和参数配置，都能直接拿去参考。

1. 纸质单据录入的真实痛点与方案选型逻辑

1.1 为什么传统 OCR 方案在企业场景里总是"差一口气"

先说清楚一个事实：单纯把图片转成文字，这件事十年前就能做。Tesseract 这类开源引擎、各家云厂商的 OCR 接口，识别印刷体早就够用了。但企业单据场景的难点从来不在"识别"本身，而在识别之后的一连串问题。

第一是版式不固定。同一家公司的送货单，不同供应商送来的格式五花八门，有表格式的、有纯文本的、有手写填空的，还有盖章盖在关键字段上的。通用 OCR 返回的是一堆没有结构的文本行，你还得自己写规则去解析哪个是单号、哪个是金额、哪个是日期。规则写多了维护成本爆炸，供应商换个模板就得改代码。

第二是手写体识别率。印刷体 99% 的准确率听着漂亮，但单据上真正关键的信息——签字、手写数量、手写备注——往往就是手写的。传统引擎在这块的表现经常掉到 70% 以下，而单据录入对准确率的要求是接近 100%，因为一个数字错了就是真金白银的损失。

第三是识别完就完了，没有后续。识别出来的数据要么导出 Excel 人工再处理，要么写进数据库就躺在那里。业务人员想问"上个月华东区退货单里金额超过五万的有几张"，还得找技术导数据。这就是为什么很多企业上了 OCR 之后，文员的工作量只减少了三成——省下的是打字时间，没省下的是理解和分析时间。

结构眼这套方案的核心差异，就在于它把 OCR 当成整条链路的起点而不是终点。识别只是第一步，后面接的是自动存档和对话式分析，而串联这三步的，是 MCP 协议。

1.2 MCP 协议到底解决了什么集成难题

MCP，全称 Model Context Protocol，是让 AI 模型能够标准化地调用外部工具和数据源的一套协议。你可以把它理解成"AI 世界的 USB 接口"——以前每接一个工具都要写一套定制代码，现在只要工具实现了 MCP Server，AI 就能按统一的方式去调用它。

放到我们这个场景里，MCP 的价值体现在三个层面。

工具调用的标准化。扫描仪识别完一张单据，需要做几件事：把图片存到指定目录、把结构化数据写进数据库、把关键字段提取出来供后续查询。这些动作如果每个都手写集成代码，工作量巨大且脆弱。用 MCP 把这些能力封装成 Server，AI Agent 就能按需调用，新增一个能力只需要加一个 Server，不用动主流程。

上下文的无缝传递。识别结果、存档路径、原始图片，这些信息需要在识别模块、存档模块、分析模块之间流转。MCP 的上下文机制让这些数据能带着元信息一起传递，不会出现"识别完了但不知道这张单子对应哪个供应商"这种断链问题。

对话式分析的天然支持。这是最关键的一点。因为数据是通过 MCP 暴露给 AI 的，业务人员用自然语言提问时，AI 能直接通过 MCP 去查询底层数据，而不是靠预先写死的报表。问"这批单据里有没有异常金额"，AI 会自己去调数据、做比对、给结论。

提示：MCP 不是某个厂商的私有协议，它是开放标准。这意味着你今天对接 WorkBuddy，明天想换别的 AI 客户端，只要对方支持 MCP，整套工具链不用重写。选型时这一点比单纯的识别准确率更重要，因为它决定了方案的寿命。

1.3 WorkBuddy 在链路里扮演的角色

WorkBuddy 在这套方案里是"调度中枢"和"交互入口"的双重角色。一方面它作为支持 MCP 的 AI 客户端，负责编排整个识别—存档—分析流程；另一方面它提供了业务人员直接对话的界面，让不懂技术的人也能用起来。

为什么选它而不是自己写个脚本调 API？因为自己写脚本的话，流程是死的——识别完固定存到某个路径，固定写进某张表。但真实业务里需求是变的，今天要按供应商分类存档，明天要按金额区间分文件夹，后天要加个异常预警。用 WorkBuddy 这种 Agent 形态的工具，这些调整可以通过配置和对话完成，不用改代码。

而且 WorkBuddy 支持 Skill 机制，可以把"识别送货单"、"识别报销单"、"识别入库单"这些不同单据类型的处理逻辑封装成独立的 Skill，按需加载。这比把所有逻辑塞进一个大脚本里要清晰得多，也方便不同业务线各自维护自己的 Skill。

2. 从扫描到入库：识别链路的工程化拆解

2.1 图像预处理：被大多数人跳过但决定成败的一步

我见过太多方案直接拿手机拍的照片丢给 OCR，然后抱怨识别率低。问题不在 OCR 引擎，在输入质量。企业单据扫描有几个必须做的预处理动作，跳过任何一个都会让后面的识别率打折扣。

去噪与二值化。扫描件常见的噪声有纸张纹理、装订孔阴影、复印产生的底灰。用 OpenCV 做自适应阈值二值化，能把文字和背景干净地分开。这里的关键参数是 blockSize 和 C，blockSize 一般取 11 到 31 之间的奇数，太小会把文字笔画当噪声去掉，太大对光照不均的处理效果差。C 值取 2 到 10，具体看扫描件的对比度。

倾斜校正。单据放歪了是常态，尤其是批量扫描时。用霍夫变换检测文本行的角度，然后做仿射变换旋转回来。倾斜超过 3 度，OCR 的识别率就会明显下降，超过 10 度基本就废了。校正这一步花不了多少算力，但收益极大。

分辨率归一化。OCR 引擎对输入分辨率有最佳区间，一般 300 DPI 左右效果最好。太低文字糊成一团，太高反而因为笔画过粗影响识别。扫描时如果设了 600 DPI，预处理阶段要降采样到 300 左右。

关键区域裁剪。如果单据版式相对固定，可以预先定义 ROI（感兴趣区域），只把包含关键字段的部分送去识别。这不仅能提速，还能减少无关文字对结构化提取的干扰。比如送货单，真正要的是单号、日期、供应商、物料明细、金额、签字这几块，页眉页脚的宣传语完全没必要识别。

import cv2 import numpy as np def preprocess_document(image_path): img = cv2.imread(image_path, cv2.IMREAD_GRAYSCALE) # 降采样到合适分辨率 if img.shape[1] > 3500: scale = 3500 / img.shape[1] img = cv2.resize(img, None, fx=scale, fy=scale, interpolation=cv2.INTER_AREA) # 自适应二值化 binary = cv2.adaptiveThreshold( img, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 21, 8 ) # 倾斜校正 coords = np.column_stack(np.where(binary < 128)) angle = cv2.minAreaRect(coords)[-1] if angle < -45: angle = 90 + angle if abs(angle) > 0.5: (h, w) = binary.shape M = cv2.getRotationMatrix2D((w // 2, h // 2), angle, 1.0) binary = cv2.warpAffine(binary, M, (w, h), flags=cv2.INTER_CUBIC, borderMode=cv2.BORDER_REPLICATE) return binary

这段代码是我实际项目里用的精简版，参数是根据一批 500 张真实送货单调出来的。你可以直接拿去用，但 blockSize 和 C 这两个值建议拿你自己的样本再微调一下，不同扫描仪出来的底灰程度不一样。

2.2 OCR 引擎选型：通用引擎与专用模型的取舍

预处理做完，接下来是选识别引擎。市面上主流的选择有这么几类，各有各的适用场景。

选型的核心判断依据是：你的单据里手写内容占比多少，以及错误成本有多高。如果只是印刷体的快递单，Tesseract 加个好的预处理就够了。但如果是手写金额、手写签字的财务单据，通用引擎的准确率撑不住，必须上专用模型或者做针对性微调。

结构眼这类专用方案的优势在于，它针对单据场景做了字段级的优化。不是返回一堆文本行让你自己解析，而是直接返回结构化的 JSON，单号、日期、金额、明细都给你分好。这省掉的是最耗时的后处理环节。

注意：不要迷信宣传里的"99% 准确率"。那个数字通常是在特定测试集上跑出来的，跟你的真实单据分布可能差很远。选型时一定要拿自己的样本做测试，至少 200 张，覆盖各种版式和书写习惯，看实际字段级准确率。

2.3 结构化提取：从文本行到可用字段

OCR 返回的原始结果是一堆带坐标的文本行。要变成能入库的结构化数据，中间要做字段映射和校验。

字段映射的思路有两种。一种是基于位置的模板匹配，适合版式固定的单据——预先标注好"金额"字段在图片的哪个区域，识别时只取那个区域的文本。另一种是基于语义的提取，用规则或小模型判断哪段文本是金额、哪段是日期。实际项目里通常是两者结合：位置做初筛，语义做兜底。

校验环节是保证数据质量的关键。几个必做的校验：

• 金额校验：识别出的金额要做数字格式校验，还要跟明细行的合计做交叉验证。如果明细加总跟总额对不上，说明有字段识别错了，需要人工复核。
• 日期校验：日期格式要合法，还要在合理范围内。识别出"2025-13-45"这种明显错误的，直接标红。
• 单号校验：如果单号有固定格式（比如前缀加数字），用正则校验。不符合格式的标记为可疑。
• 必填字段检查：供应商名称、金额、日期这些关键字段如果为空，不能静默通过，要触发人工复核流程。

这套校验逻辑建议封装成一个独立的 MCP Server，这样识别流程和分析流程都能调用同一套校验规则，保证一致性。

3. 存档环节：让每张单据都能被找到

3.1 存档结构设计：目录命名与元数据分离

识别完的单据往哪存，这件事看着简单，做不好后面全是麻烦。我见过把图片全堆在一个文件夹里的，几千张之后找一张单子跟大海捞针一样。也见过按日期建目录但文件名用时间戳的，业务人员根本不知道哪个文件对应哪张单。

合理的存档结构应该满足两个条件：人能看懂，机器能检索。我的做法是目录按业务维度分层，文件名带关键标识，同时把完整元数据写进数据库。

目录结构示例：

/archive /2025 /01 /供应商A 20250115_SN20250115001_送货单.jpg 20250115_SN20250115001_送货单.json /供应商B ...

文件名里的 SN 是单据编号，这样即使不看数据库，光看文件名也能定位。同名的 json 文件存的是这张单据的完整识别结果和元数据，方便单独查看。

元数据单独存一份到数据库（SQLite 或 PostgreSQL 都行），字段包括：单据ID、类型、供应商、日期、金额、识别置信度、存档路径、处理状态、复核标记。数据库是给分析用的，文件系统是给人工查阅用的，两者通过单据ID关联。

3.2 通过 MCP Server 封装存档能力

存档这个动作要封装成 MCP Server，暴露几个标准方法给 AI 调用：

• save_document(image_path, metadata)：保存图片和元数据，返回存档路径和单据ID
• query_document(filters)：按条件查询单据，支持按日期、供应商、金额区间等过滤
• get_document_detail(doc_id)：获取单张单据的完整信息
• update_review_status(doc_id, status)：更新复核状态

这样封装的好处是，AI 在做对话式分析时，不需要知道底层是文件系统还是数据库，只需要调用这些方法。将来存储方案换了，比如从本地文件系统换成对象存储，只需要改 Server 的实现，上层逻辑不动。

# 存档 MCP Server 的核心逻辑示意 import json import sqlite3 from pathlib import Path from datetime import datetime class ArchiveServer: def __init__(self, base_dir, db_path): self.base_dir = Path(base_dir) self.conn = sqlite3.connect(db_path) self._init_db() def _init_db(self): self.conn.execute(''' CREATE TABLE IF NOT EXISTS documents ( doc_id TEXT PRIMARY KEY, doc_type TEXT, supplier TEXT, doc_date TEXT, amount REAL, confidence REAL, archive_path TEXT, review_status TEXT DEFAULT 'pending', created_at TEXT ) ''') self.conn.commit() def save_document(self, image_path, metadata): doc_id = metadata['doc_id'] doc_date = datetime.strptime(metadata['doc_date'], '%Y-%m-%d') target_dir = self.base_dir / str(doc_date.year) / f"{doc_date.month:02d}" / metadata['supplier'] target_dir.mkdir(parents=True, exist_ok=True) # 保存图片和元数据 ... return {'doc_id': doc_id, 'path': str(target_dir)}

这段是骨架，实际实现里还要处理并发写入、文件命名冲突、异常回滚这些细节。但核心思路就是：存档逻辑集中在一个地方，对外只暴露语义化的方法。

3.3 存档时的几个实操坑

文件名冲突。同一供应商同一天可能有多张单据，如果文件名只用日期加供应商就会覆盖。解决办法是文件名里带上单据编号，编号本身是唯一的。如果单据编号识别失败，用时间戳加随机后缀兜底。

大文件处理。高分辨率扫描的图片单张可能十几兆，批量存档时 IO 会成为瓶颈。建议存档前做一次压缩，JPEG 质量设 85 左右，肉眼几乎看不出差别，体积能降到三分之一。但要注意，如果后续还要做精细的 OCR 复核，原始高清图要保留一份。

元数据写入的原子性。图片存了但元数据写失败，或者反过来，都会造成数据不一致。做法是先把图片写到临时目录，元数据写库成功后再移动到最终位置。移动是原子操作，不会出现半成品。

权限与审计。单据涉及财务信息，存档目录的访问权限要控制好。建议按业务线分目录，不同业务线的人只能访问自己那部分。同时记录每次访问和修改的日志，方便审计。

4. 对话式分析：让业务人员自己问数据

4.1 为什么对话式分析比固定报表更实用

传统做法是技术根据业务需求开发报表，业务提需求、技术排期、开发、上线，一轮下来少说两周。等报表出来了，业务需求可能又变了。对话式分析把这个循环打破了——业务人员直接用自然语言提问，AI 通过 MCP 去查数据、做计算、给答案，不需要预先开发。

实际用起来是这样的场景：财务主管想知道"这个月华东区供应商的送货单里，金额超过十万的有哪些，分别是什么时候送的"。以前要么等报表，要么自己导 Excel 筛。现在直接在 WorkBuddy 里问一句，AI 调query_document方法，按条件过滤，把结果整理成表格返回。整个过程几秒钟。

更关键的是追问能力。看到结果后可以接着问"其中哪些还没复核"，AI 会带着上一轮的上下文继续查。这种交互式探索是固定报表给不了的。

4.2 分析场景的典型问法与背后的 MCP 调用

不同的问法背后对应不同的 MCP 调用组合，理解这个映射关系有助于你设计更好用的 Server 接口。

设计 Server 接口时，要尽量让查询能力通用化。query_document接受一个 filters 字典，支持日期范围、供应商、金额区间、置信度阈值、复核状态等任意组合。这样 AI 能灵活组合出各种查询，不用为每个场景单独写方法。

4.3 让分析结果可追溯

对话式分析有个容易被忽视的问题：AI 给出的结论，业务人员怎么验证？如果 AI 说"本月异常单据有 15 张"，业务得能点进去看到具体是哪 15 张，每张的原始图片和识别结果是什么。

做法是在返回结果里带上单据ID和存档路径。WorkBuddy 的界面里可以把这些做成可点击的链接，点开直接看原图和识别详情。这样业务人员既能享受对话的便利，又能随时回到原始数据核对，信任度就建立起来了。

另外，对于涉及金额汇总的分析，建议在返回结果里附上计算口径说明。比如"总额 128 万，统计范围是 2025 年 1 月 1 日至 1 月 31 日、状态为已复核的送货单"。这样避免因为口径不一致产生误解。

5. 完整链路的串联与 WorkBuddy 配置要点

5.1 把识别、存档、分析串成一条流水线

前面几块单独看都不复杂，难的是串起来。整条链路的触发方式可以有两种：手动触发和目录监听。

手动触发适合零散单据，业务人员扫完一张，在 WorkBuddy 里说"处理这张单子"，AI 调用识别 Skill，走完整个流程。目录监听适合批量场景，扫描仪输出到一个监控目录，有新增文件就自动处理。

WorkBuddy 里配置这条链路，核心是定义好 Skill 和 MCP Server 的对应关系。一个典型的配置思路：

• 识别 Skill：绑定 OCR MCP Server，输入图片路径，输出结构化数据
• 存档 Skill：绑定 Archive MCP Server，输入结构化数据，输出存档路径
• 分析 Skill：绑定 Query MCP Server，输入自然语言查询，输出分析结果

这三个 Skill 可以组合成一个工作流，也可以单独调用。批量处理时用工作流，临时查询时单独调分析 Skill。

5.2 WorkBuddy 安装与 MCP 连接配置

WorkBuddy 的安装本身不复杂，官网下载对应平台的安装包，按提示走就行。真正需要花心思的是 MCP 连接的配置。

配置 MCP Server 时，每个 Server 需要指定启动命令和参数。以本地 Python 实现的 Server 为例，配置大概长这样：

{ "mcpServers": { "ocr-server": { "command": "python", "args": ["/path/to/ocr_server.py"], "env": { "OCR_API_KEY": "your_key_here" } }, "archive-server": { "command": "python", "args": ["/path/to/archive_server.py"], "env": { "ARCHIVE_BASE_DIR": "/data/archive", "DB_PATH": "/data/documents.db" } } } }

几个配置要点：

路径要用绝对路径。相对路径在不同工作目录下启动会出问题，这个坑我踩过，排查了半天才发现是路径问题。

环境变量传敏感信息。API Key、数据库密码这些不要硬编码在代码里，通过 env 传进去。WorkBuddy 的配置支持 env 字段，用起来很方便。

Server 启动要快。如果 Server 启动要加载大模型或者做耗时初始化，WorkBuddy 连接时会超时。建议把重初始化逻辑做成懒加载，第一次调用时才执行。

日志要输出到文件。MCP Server 的 stdout 通常被协议占用，调试信息要写到文件里，不然看不到。这个细节不注意的话，Server 出问题你都不知道从哪查。

5.3 实测中的性能与稳定性问题

跑通 demo 和稳定运行是两回事。实际部署后会遇到几个典型问题。

并发处理。批量扫描时可能同时有几十张单据进来，如果串行处理会很慢。做法是用队列加多 worker，但要注意 OCR 接口通常有 QPS 限制，worker 数量不能超过限制。我一般设 3 到 5 个 worker，配合重试机制。

内存占用。图像处理是内存大户，一张 300 DPI 的 A4 扫描件解压后占几十兆。批量处理时如果不及时释放，内存会涨得很快。处理完一张就显式释放图像对象，别指望垃圾回收及时跟上。

失败重试。OCR 接口偶尔会超时或返回错误，要有重试机制。但重试不能无脑重试，要区分错误类型——网络超时可以重试，参数错误重试多少次都没用。建议最多重试 3 次，间隔递增。

幂等性。同一张单据如果被处理两次，不能产生两条记录。用单据编号做幂等键，存档前先查一下是否已存在，存在就跳过或更新。

6. 落地过程中踩过的坑与经验总结

6.1 识别准确率的那些"意外"

盖章遮挡。供应商的章经常盖在金额或者签字上，OCR 遇到盖章区域识别率骤降。解决办法是在预处理阶段做印章检测，把红色印章区域提取出来，识别时对这块区域做特殊处理，或者标记为需要人工确认。

表格线干扰。有表格的单据，表格线会被 OCR 当成字符识别，产生一堆乱码。预处理时做表格线检测和去除，能显著提升识别质量。OpenCV 的形态学操作可以提取横竖线，然后从二值图里减掉。

多栏排版。有些单据是左右两栏的，OCR 按行扫描会把两栏的内容混在一起。这种情况需要先做版面分析，识别出栏的边界，分栏后再识别。结构眼这类专用方案通常内置了版面分析，通用引擎就得自己处理。

手写连笔。手写识别最难的是连笔字，尤其是快速书写的数字。实测下来，专用模型对工整手写的识别率能到 90% 以上，但潦草连笔会掉到 70% 左右。对于这类单据，建议设置置信度阈值，低于阈值的自动标记人工复核，不要硬扛。

6.2 数据一致性问题的排查思路

有次客户反馈说分析结果对不上，明明扫描了 100 张单子，系统里只查到 95 张。排查过程值得记录一下。

第一步，查存档目录，数图片文件数量，确认是 100 张，说明识别和存档都执行了。第二步，查数据库记录数，只有 95 条，说明有 5 张的元数据没写进去。第三步，查日志，发现这 5 张都是同一供应商的单据，报错是"supplier 字段为空"。第四步，看原始识别结果，发现这 5 张单据的供应商名称是手写的，识别失败了，导致元数据里 supplier 为空，写库时被非空约束拦下了。

根因清楚了：识别失败没有触发人工复核，而是静默失败了。修复方案是加一个校验环节，关键字段为空时不能静默通过，要标记为待复核并记录原因。这个坑的教训是，任何环节的失败都要有明确的处理路径，不能让它悄悄溜过去。

6.3 业务人员真正用起来的关键

技术跑通只是第一步，让业务人员愿意用才是难点。几个实际经验：

降低使用门槛。不要指望业务人员去学 MCP、Skill 这些概念。WorkBuddy 的界面要配置得足够简单，常用操作做成快捷指令，比如"处理新单据"、"查本月汇总"这种一键触发的按钮。

给出即时反馈。单据处理完要有明确的提示，识别成功显示关键字段让用户确认，识别失败说明原因并引导复核。没有反馈的话，用户不知道系统到底有没有在工作。

保留人工兜底。再好的识别也有出错的时候，复核界面要做得顺手。原图和识别结果并排显示，可疑字段高亮，修改后一键保存。复核效率决定了业务人员对系统的接受度。

从一个小场景切入。不要一上来就全公司推广，先找一个单据量适中、痛点明显的部门试点。跑顺了再复制到其他部门。我见过一上来就全铺开结果问题百出最后被弃用的案例，教训很深。

6.4 后续可以扩展的方向

这套链路跑通之后，有几个自然的扩展方向。一是加异常检测，识别出的金额、日期如果偏离历史分布，自动预警。二是做供应商画像，基于历史单据数据，分析各供应商的送货规律、金额分布、异常率。三是跟 ERP 系统对接，识别完的数据直接推送到采购或财务模块，省掉人工录入的最后一步。

每个扩展方向都可以做成独立的 MCP Server，按需加载。这样整套系统的边界是开放的，业务需要什么能力就加什么 Server，不用推倒重来。

我个人在实际项目里最大的体会是，AI 落地企业场景，技术只占三成，剩下七成是流程设计和用户习惯培养。识别准确率从 95% 提到 98% 固然有价值，但让业务人员愿意用、用得顺手，价值更大。结构眼加 WorkBuddy 这套组合，最大的优势就是把复杂的技术细节藏在了对话界面后面，业务人员看到的就是"扫一下、问一句、拿到结果"，这才是能真正推广开来的形态。