企业官网建设流程全解析

月底我去财务部帮忙处理对账，桌面上Excel窗口开了十几个，同一笔银行回单被人为改了三次摘要，两个系统的订单号格式对不上，最后只能靠人眼逐行打勾。这种场景我见得太多——不是没有系统，而是系统之间各说各话；不是大家不努力，而是重复录入和对账这种事，靠人肉真扛不住。

几个月前，我们给一家集团下属子公司搭了一套轻型AI中台，目标就两个：让AI把重复录入的活干完，让系统把对账的差异自动标出来。这里说的“中台”不是那种动辄几十人团队的大工程，而是几台服务器上一组容器化服务，把OCR识别、大语言模型、规则引擎和流程编排串成一条流水线。整套东西从设计到上线用了不到两周，运行效果比预期好很多。

这篇文章会把整套架构逻辑、技术选型和部署过程完整拆一遍，包括踩过的坑和排查思路。适合正在被重复录入和对账难题困扰的企业IT负责人、财务数字化岗位的同学，也适合想用本地大模型做实际业务的运维和开发工程师。

1. 先搞清楚：重复录入和对账难，到底难在哪

1.1 重复录入的真相：系统之间缺一个“翻译层”

先明确一个判断：重复录入不是人的问题，是系统集成缺失的问题。销售在CRM录了合同，商务在ERP里要再录一遍销售订单，财务在财务系统又要录发票——每个系统的字段语义、格式规则、校验逻辑都不一样。大家不是想偷懒，而是系统之间根本没有一条自动转换的通道。

传统思路是做接口开发，但老系统的接口往往不开放，文档缺失，字段定义混乱，集成成本很高。于是很多企业选择了最原始的办法：让文员复制粘贴，让会计重新录入。这个办法短期不花钱，长期却把人力成本越拖越高，出错率也随单据量线性上升。

轻型AI中台要做的第一件事，就是把“系统之间的人工翻译”变成“机器自动翻译”。通过OCR识别纸质单据或PDF，再用大语言模型理解语义，把字段映射成目标系统需要的格式，经过规则校验后自动写入。这个过程替换的不是某个人，而是整套重复搬运的流程。

1.2 对账困难的本质：时间、口径、状态三个不一致

对账难，表面看是数据对不上，本质上是三个层面的不一致叠加在一起。

第一是时间差。银行流水很多是T+1甚至T+2才入账，业务系统按交易发生日记账，月底最后几天产生的交易，两边天生对不齐。第二是口径差。一笔订单含税还是不含税、退货怎么冲抵、满减如何分摊，业务侧和财务侧的定义经常不同，两边拿各自口径做同一道题，答案自然不一样。第三是状态差。一边单据还在草稿状态，另一边已经变为已审核；一边审核通过，另一边被退回修改。系统之间的状态流转没有同步机制，核对时就会产生大量“假差异”。

用Excel做对账，本质是靠人眼临时记忆这些差异规则再逐行判断。单据量少还行，量一大就彻底失控。AI中台的做法是先把所有来源数据统一成标准流水模型，再用规则引擎做确定性匹配，把模糊的部分交给大模型判断，最后输出差异报告给财务复核。这样系统处理的是“规则和模型”，而不是“某一个具体的Excel文件”。

1.3 为什么不是“换一套ERP”或“无限加人”

很多企业第一次听到AI中台，第一反应是“我们要不要干脆换ERP？”我的回答通常是不建议。换ERP意味着流程重构、数据迁移、全员培训，周期以年计算，预算以百万计算，中小企业折腾不起。即使换完，新ERP内部模块打通了，跟上下游伙伴和银行系统的对接问题依然存在。

加大人力也治标不治本。单据量涨一倍，人不是只涨一倍，沟通协调成本会超线性增长。重复录入本身是反人性的工作，人员流动率高，培训成本高，出错率反而更不可控。

所以轻型AI中台的定位很明确：在所有存量系统外面套一层“智能翻译和智能核对层”。它不替代任何核心系统，不推倒重来，用最小的侵入换取最大的自动化收益。对预算有限、系统老旧、老板又急着要效果的团队来说，这是回报率最高的一条路。

2. 技术选型与整体设计：能轻则不重

2.1 三个设计原则，能帮你少走一半弯路

在动手部署之前，我建议先把设计原则定下来。我们当时给自己立了三条规矩，后来发现这几条规矩省了很多麻烦。

原则一，能开源就不自研。OCR、大模型推理、流程编排这些能力，在开源社区已经非常成熟，完全没必要从零写。自研看着有面子，维护起来全是坑。

原则二，能轻则轻，拒绝一上来就上K8s。轻型中台的核心价值是快速见效，单机Docker Compose足以覆盖绝大多数业务量。等业务量真正增长到需要水平扩展的时候，再迁到集群不迟，但第一版一定别把复杂度堆上去。

原则三，接口标准化，不做私有协议。所有服务对外只暴露HTTP接口，数据格式统一用JSON，消息传递走标准HTTP回调或消息队列。这样未来替换任何一个组件，都不会影响整条链路。

这三条原则的本质，是保证系统的可替换性和可运维性。后续做审计、迁移、排障都会轻松很多。

2.2 核心组件选型对比

我把整套中台的组件整理成一张表，方便你直接参考：

选型逻辑是“每个能力只选一个最接近业务的工具，不追求大而全”。比如OCR，PaddleOCR对中文场景识别效果好，社区活跃，部署也简单；如果PDF是文档类而非扫描件，用MinerU直接做版面分析和文本抽取，效果比传统OCR更理想。

大模型推理这里多说一句。很多人一上来就想部署几十B甚至上百B的模型，我强烈建议先从3B到8B的轻量模型开始，比如Qwen2.5系列。原因很简单：企业业务场景里，字段抽取和语义判断这类任务对推理能力要求没有那么高，但对接入延迟和服务器资源非常敏感。一个能在CPU上流畅运行的量化模型，比一个跑不动的大模型有用得多。

2.3 整体架构：一条流水线串起四个环节

整套中台的架构可以用一句话概括：从数据接入到业务写入，一条流水线串起四个环节。

第一个环节是数据接入。文件上传、FTP目录扫描、数据库定时任务、消息队列都可以作为入口。单据可能是扫描件、PDF、Excel，也可能是邮件附件，接入层把这些异构入口统一收拢。

第二个环节是智能处理。OCR先做文本识别，大模型再做字段提取和语义理解，规则引擎最后做校验。这个环节是整个中台的核心，解决的问题是“把非结构化信息变成结构化业务数据”。

第三个环节是业务编排。n8n这类流程引擎负责把处理结果按规则分发，调用ERP接口写入数据，创建复核工单，触发通知推送。所有步骤可配置、可追溯、可回滚。

第四个环节是输出与闭环。写入目标系统、生成对账差异报告、把异常项推送到待办池，人工确认后落库归档。没有闭环的自动化只是玩具。

这四个环节对应到两条具体业务链路上：一条是智能录入链路，解决重复录入；一条是自动对账链路，解决对账困难。下面进入实操部分。

3. 实操部署：两周内把中台跑起来

3.1 基础环境准备：硬件怎么配，系统怎么装

先讲硬件。我们当时用的是一台64GB内存、16核CPU的服务器，没有独立显卡。如果你们的单据量不大，32GB内存、8核CPU起步完全够用；如果打算跑8B量化模型，建议32GB内存以上；要跑视觉模型或者大批量OCR，再加一块NVIDIA显卡会更从容。磁盘建议留500GB以上，模型文件、Docker镜像、业务数据会分散吃掉不少空间，系统盘千万别塞满。

系统方面推荐Ubuntu 22.04或24.04 LTS。Docker和Docker Compose装好后，基本没有其他系统层面的依赖。在内网环境部署时，有一个容易被忽略的环节：提前把需要用到的模型文件下载好，用离线方式拷入服务器。我们第一次部署时没准备离线包，结果现场等下载等了大半天，非常被动。

Docker安装完成后，建议把镜像仓库地址配置好，避免反复拉镜像时因为网络原因失败。这里顺带提醒，所有容器服务尽量固定端口映射和存储卷位置，方便后期备份和迁移。

3.2 编排核心服务：数据库、推理服务、流程引擎

下面这份docker-compose.yaml是整套中台的最小骨架。它把PostgreSQL、Ollama和n8n三个核心服务编排在一起，启动后你就有了一套可运行的雏形。

version: "3.8" services: postgres: image: postgres:15-alpine environment: POSTGRES_DB: ai_middle_platform POSTGRES_USER: aiuser POSTGRES_PASSWORD: change_me volumes: - pgdata:/var/lib/postgresql/data ports: - "5432:5432" healthcheck: test: ["CMD", "pg_isready", "-U", "aiuser"] interval: 10s timeout: 5s retries: 5 ollama: image: ollama/ollama:latest volumes: - ollama:/root/.ollama ports: - "11434:11434" restart: unless-stopped n8n: image: n8nio/n8n:latest environment: - N8N_HOST=0.0.0.0 - N8N_PORT=5678 - DB_TYPE=postgresdb - DB_POSTGRESDB_HOST=postgres - DB_POSTGRESDB_DATABASE=ai_middle_platform - DB_POSTGRESDB_USER=aiuser - DB_POSTGRESDB_PASSWORD=change_me ports: - "5678:5678" depends_on: postgres: condition: service_healthy restart: unless-stopped volumes: pgdata: ollama:

这个文件有三个细节值得说明。第一，PostgreSQL加了健康检查，n8n只有在数据库可用后才启动，避免启动顺序混乱。第二，Ollama的数据目录挂载到命名卷，模型文件不会因为容器重建而丢失。第三，所有服务都设置了restart策略，服务器重启后能自动拉起。

启动命令很简单：

docker compose up -d docker compose ps

看到三个服务处于Up状态后，再单独把OCR服务加进来。我建议OCR单独跑一个容器，避免和推理服务抢资源，也给后续替换留下余地。加进来之后，用docker compose ps再确认一次所有容器都是健康状态，然后再开始配置业务链路。

3.3 智能录入链路：从扫描件到自动写入

现在解决第一个核心问题：消除重复录入。我以“供应商送货单自动录入ERP”为例，拆解整条链路。

操作流程分为六步：

1. 把送货单扫描件或拍照件上传到指定目录，或者通过网页表单、企微机器人发送给中台接口。
2. 中台调用OCR服务，识别图片中的文本和表格区域。
3. 把OCR原文交给本地大模型，模型根据提示词提取结构化字段。
4. 规则引擎校验必填项、金额一致性等。
5. 调用ERP开放接口，生成采购入库单。
6. 记录完整日志，校验失败或接口异常的单据自动进入人工复核队列。

其中第三步是整个链路的技术关键点。我把提示词模板贴出来，你们可以直接抄：

你是一个单据信息抽取助手。从下面OCR识别出的原始文本中， 提取字段：supplier、delivery_date、material_code、quantity、 unit_price、total_amount。 要求：物料编码保持原样；金额统一转为数字；无法确定的字段填null。 只输出JSON，不要任何解释。 原始文本： {ocr_text}

为什么这里要用大模型而不是传统正则表达式？因为送货单来自不同供应商，模板五花八门，正则表达式换一家供应商就要改一次；而大模型只需要在提示词里描述字段语义，就能适应格式变化。当然大模型也不是万无一失，所以还要靠第四步的规则引擎兜底。

规则引擎的校验逻辑可以用JSON表达，比如：

{ "supplier": {"required": true}, "delivery_date": {"type": "date", "required": true}, "quantity": {"type": "number", "min": 0}, "unit_price": {"type": "number", "min": 0}, "total_amount": {"type": "number", "equal_expected": "quantity * unit_price"} }

这里有个细节很多人容易忽略：金额校验不要只判断“是否为空”，要主动计算“数量乘以单价”是否等于总金额。很多重复录入错误其实在源头就可以用这种简单规则拦截，省得对账时再返工。我们在实际项目里就是靠这条规则，把送货单的错误率压下去一大截。

3.4 自动对账链路：从银行流水到差异报告

第二个核心问题是消减对账困难。我以“银行流水与业务收款记录核对”为例，讲清楚整条链路。

流程是：每天凌晨定时任务从银行导出的电子回单Excel读取流水，同时从业务系统的数据库只读视图拉取收付款记录。两边的数据先经过清洗层统一成标准格式，包括交易日期、金额、收付方向、摘要四个字段。

然后进入第一轮规则匹配：相同金额、日期相差不超过3天、摘要含有关键业务编号的，直接标记为“已核对”。这一轮能解决大约70%到80%的常规单据。

剩下未匹配的记录进入第二轮，交给大模型做语义判断。比如银行回单摘要写着“XX化工货款”，业务系统收款单备注是“合同HT2025-0018”，两者金额一致但日期差了两天，传统规则匹配不上，大模型却能判断出这大概率是同一笔业务。判断结果不是直接写死，而是生成“疑似匹配”标记，供财务人员复核确认。

再往下是差异分类输出。我们把差异分成四类：多收、少收、时间差、无业务凭证。每类差异对应不同的处理动作，比如“时间差”自动标记为正常待后续核对，“无业务凭证”推给业务部门追查。

最后是闭环设计。差异报告每天生成后自动推送到财务负责人的待办池，人工确认结论回填到系统。这些确认过的结论会成为后续对账的参考，模型判断越用越准。只有走通这一步，财务团队才愿意信任这套流程，真正的价值才会落地。

3.5 人工复核界面：让业务敢用AI的关键设计

很多技术团队做自动化项目，容易犯一个错误：一上来就追求100%全自动，把人工环节全部砍掉。实际上业务部门根本不敢接受这种方案，出了问题连回溯入口都没有。

我们的做法是在n8n流程里单独挂一个“复核节点”。所有识别结果不是直接写进ERP，而是先进入待办池，由财务人员或库管员在页面上确认。确认动作留给人工，识别动作交给AI。运行半个月后，团队对AI的准确率有了体感，才逐步放开部分低风险单据的自动写入权限。

这个设计虽然多了一点点人工成本，但换来了信任和回溯能力。自动化项目最怕的不是AI出错，而是出错之后没人敢承担责任。留一个复核入口，就是给业务部门留一条安全通道。

4. 部署实施中踩过的坑与排查技巧

4.1 模型推理慢、内存吃紧的排查思路

第一次跑的时候，我们用Ollama部署了一个8B量化模型，机器是16核CPU加64GB内存，单条提示词响应要十几秒，并发一多直接排队。排查下来问题出在三个地方。

第一，并发参数没有调。Ollama默认配置会尝试并行处理多个请求，但CPU推理的并行能力有限，并发一高反而互相拖慢。把并发数调到2或3，单次响应时间反而快了不少。第二，模型选型偏大。对字段抽取这类任务，3B到4B模型完全够用，换成小模型后响应时间降到三五秒，准确率并没有明显下降。第三，提示词里塞了太多历史示例，每次请求都带着一大段上下文，token计算量大。精简提示词后响应时间又缩短一截。

后来我们还做了一个优化：把OCR识别和大模型推理拆成异步任务。用户提交单据后立即返回“处理中”，后台跑完再通知结果。这样即使单个请求耗时三五秒，用户体感上也不觉得慢，整体吞吐量也能上来。

4.2 OCR识别质量差，问题不一定在OCR本身

OCR识别不准，多数人第一反应是换更好的OCR模型。但根据我的观察，很多场景的识别问题出在图片质量上，而不是模型能力上。

常见的现象有：手机拍的单据歪斜、有阴影；扫描件有黑边；印章盖住了关键字段。PaddleOCR自带方向分类器和版面分析，但前提是输入图片足够清晰。我们的经验是在OCR之前加一个图像预处理环节：先做方向校正，再做亮度均衡，最后裁掉无用边缘。

另外有个技巧，OCR识别出的原始文本不要做太多过滤，原样交给大模型处理。很多人喜欢先用正则清理空格和换行，结果反而把关键信息弄丢。大模型本身对文本中的噪声有很强的容错能力，保留原始上下文更有利于准确抽取。

4.3 老系统没有API，打通数据流的三种办法

这是项目里被问得最多的问题。老ERP系统可能连接口文档都没有，数据库直接操作又怕出事。我的经验是按优先级用三种办法。

第一种，利用系统自带的导入导出功能。绝大多数业务系统都支持Excel导入导出，只是格式不友好。我们可以让中台在后台生成符合导入模板格式的Excel文件，再调用系统的命令行或定时任务完成导入。这个方案侵入性最小，实施也最安全。

第二种，申请只读数据库账号。如果老系统用的是Oracle、SQL Server这类数据库，可以让DBA开一个只读账号给中台拉数据。只读权限严格控制，绝不直接执行写操作。写入仍然走应用的导入通道，或者由业务人员确认后手动操作。

第三种，Web页面自动化操作。这是最不推荐的方案，因为它依赖页面元素定位，系统一升级就失效。仅在完全没有其他通道时才考虑，而且要做好随时维护的准备。整体优先级就是：文件优先，数据库只读次之，UI自动化最后。

4.4 对账结果总有少量差异，如何逐步收敛

上线初期，对账模块识别出了大量差异，财务那边一度有情绪。后来我们做了三件事，把差异量控制到了合理范围。

第一，降低自动化目标预期。先做到95%自动核对，剩下5%由人工确认，而不是追求100%全自动。这个预期必须先对齐。

第二，把每次人工确认的结论沉淀下来。财务确认“差异类型为时间差”之后，这个结论回写到规则库里，下一次遇到类似记录自动套用规则，模型的判断负担也会越来越轻。

第三，建立一个简易的对账知识库。把历史对账中出现的典型案例、判断依据整理成文档，定期加入到大模型的提示词参考中。这样模型的判断会越来越符合企业实际业务语义，而不是停留在通用理解水平。

这三件事本质上都是在做同一件事：让系统在真实业务反馈中持续学习。没有这个过程，任何花哨的模型都跑不出好结果。

5. 落地效果与可扩展方向

5.1 实际落地效果：数字比吹嘘实在

说下我们当时的数据。送货单录入方面，原来每单需要文员手工录入三到五分钟，现在从上传单据到写入ERP平均不到三十秒，其中大部分时间是OCR和模型推理消耗，人工只需要在异常队列里偶尔确认一下。

对账方面，原来每月末财务两个人对三天，经常还要加班；现在每天自动生成对账报告，月末只需要集中处理少数疑难点，当天就能出结果。客户公司后来统计过，每个月省下来的工时超过六十个小时，这还不算因为错账返工带来的隐性成本。

当然要说明，这套效果是在单据格式相对规范、业务量几百到上千单的场景下取得的。不同业务形态效果会有差异，但方向是明确的：只要重复录入的痛点是真实的，这套架构就值得一试。

5.2 扩展方向：从录入对账走向更多智能化场景

这套中台跑通以后，可以顺理成章地向其他场景扩展。

如果数据量快速上涨，可以把分析型查询从PostgreSQL迁到Doris这类列式存储上，让对账统计和报表更流畅。如果对高并发推理有要求，可以把Ollama换成vLLM这类推理框架，模型也可以换更大的版本，效果和吞吐量都有提升空间。

监控方面建议尽早接上Zabbix或Prometheus加Alertmanager，把主机负载、容器状态、服务接口可用性都纳入告警范围。中台本身作为自动化基础设施，一旦出问题影响的是整条业务线，不能让它变成盲区。

边缘部署是另一个方向。如果你有Jetson设备或者RK3588这类开发板，可以把OCR或目标识别模型量化后部署到边缘端，在车间入口直接完成单据识别和物体检测，减轻中心服务器的压力。我们也在探索把送货单拍照识别前置到仓库门口，让文员连上传这一步都省掉。

5.3 最后的几点个人体会

从这套项目里，我最大的体会是：轻型AI中台真正做成功，靠的不是模型多强，而是流程设计多扎实。先把录入和对账的具体场景摸清楚，再谈AI；先保留人工复核的闭环，再谈自动化；先让业务看到效果，再谈规模化推广。

还有一个很朴素的建议：日志一定要写全。我们每次处理单据都会记录完整的过程信息，包括OCR原文、模型输出、规则校验结果、最终写入状态。这些日志在初期调试和后期追溯时都是救命稻草，千万别省。

如果你正在为重复录入或对账难题头疼，又不想启动一个伤筋动骨的大项目，这套轻型AI中台的思路可以直接拿来用。从一个场景开始，把流水线跑通，再逐步扩大范围，你会看到自动化带来的价值比想象中更快显现。