企业官网建设流程全解析

上个月帮朋友公司做了个小项目，把财务和运营部门天天喊累的两件事给解决了：供应链单据重复录入、月度对账来回扯皮。方案不复杂，就是部署了一套轻量级 AI 中台。说是“中台”，其实也就是几台机器加开源组件，没动他们原来的 ERP，也没搞大改造。今天就把这套东西从需求拆解、架构选型、部署步骤到落地踩坑完整复盘一遍，给同样被重复录入和对账折磨的团队做个参考。

先说结论：这条路是能走通的。一个三五人的 IT/数据团队，有两三周时间，用 Docker Compose、Ollama、Qwen 模型加上一个流程编排平台，就能把一个最小可用的 AI 中台跑起来。它解决的核心问题很聚焦：让机器自动从各类单据里提取结构化数据，再通过规则引擎和模型能力去替代人工比对、合并、确认，把员工从机械劳动里解放出来。适合谁看？准备上 AI 但不想被大平台绑定的企业运维、想往 AI 应用方向转的开发，以及公司正在做数字化改造但预算有限的朋友。

1. 先想清楚：AI 中台到底解决哪两个问题？

很多团队一听到“AI 中台”就想到建设企业级机器学习平台、数据湖、模型训练集群，觉得没有千万预算玩不转。实际上，对于大多数中小企业来说，AI 中台的价值根本不在“训模型”，而在“用模型”。我们这次要解决的就是两个非常现实、非常“土”的问题：重复录入和对账困难。

1.1 重复录入的典型链路

重复录入的场景比想象中普遍。最常见的是供应链环节：供应商发来一张送货单，可能是 PDF、图片或者 Excel，仓库文员要把送货单上的物料编码、数量、批次号、送货日期重新敲进 ERP 的采购入库单里。如果一天有几十张送货单，每张 5 到 20 行物料，那这一天就是复制粘贴循环。更烦的是，不同供应商的送货单格式完全不一样，有的用 code，有的用料号，有的没批次号，操作员稍不留神就录错一行，后面库存、成本、结算全跟着错。

类似的还有客户采购订单。客户通过邮件发来 Excel 或盖了章的 PDF，业务助理要把订单编号、产品型号、单价、交期重新录入到订单系统。很多订单系统没有导入功能，或者导入模板和客户表格不一致，所以只能人工中转。还有一个高频场景是财务收付款单据：银行回单、发票、内部收款确认单，同一笔业务要在三个系统里分别录入，格式还都不一样。

这些场景的共同特点是：信息其实已经存在于某个文件或外部系统里了，但因为没有统一采集和转换通道，只能靠人肉搬运。重复录入带来的问题不只是人工成本，还包括录入错误导致的后续对账困难、库存差异、应收账款长期悬账。

1.2 对账困难的三类痛点

对账困难是重复录入的“果”。我们这次梳理用户痛点时发现，对账难基本逃不开三类情况：

第一，数据口径不一致。银行流水的日期是“到账日”，ERP 里记的是“业务确认日”，两边的日期可能差两三天，金额还分含税不含税、原币本币。拿这些数据直接比对，电脑都会“打架”，何况是肉眼对账的人。

第二，唯一标识缺失。很多对账单上没有统一发票号或合同号，只有转账备注，备注里写的是“货款”这两个字。银行侧显示“张三公司”，ERP 里客户名称是“张三（上海）贸易有限公司”，这种文本差异靠 Excel Vlookup 很难自动配平。

第三，数据分散。销售收入在 ERP，回款记录在资金系统，费用在 OA 系统，银行流水又导自网银。要完成月度对账，得先把五六个系统的导表汇总到一个表里，再做格式转换和清洗，这个准备过程就占了整体对账工作量的 70%。

所以我们的核心目标不是做一个通用的 AI 平台，而是先解决“数据的进”和“数据的对”这两个环节：让 AI 中台成为所有非结构化单据的统一入口，让结构化、半结构化数据在进入核心业务系统之前就被清洗成标准格式。这才是所谓“轻型 AI 中台”的真正定义。

2. 为什么选“轻量”方案：架构与选型复盘

确定要解决的问题后，接下来最关键的就是选型。我们面对的现实约束很明确：预算有限，硬件有限，IT 团队只有两三个人，而业务部门希望尽快看到结果。这种情况下，任何重平台方案都活不过第一轮评审。

2.1 中台不一定要“重”

一提到“轻量级 AI 中台”，可能有人会觉得是简化版数据中台，实际上我们的思路完全不同。这里提的是“能力中台”：把 AI 能力（文本识别、信息抽取、语义匹配、自动生成）封装成统一服务，再通过可视化工作流把能力和业务系统串起来。它不是一套庞大的软件，而是一个由几个独立服务组成的小生态：

• 流程编排层：负责把“接文件 → 解析 → 抽取 → 校验 → 写系统”这些步骤编排起来，同时提供知识库、Agent 对话、API 发布能力。
• 模型服务层：提供大语言模型推理和向量化能力，支持本地部署，保证业务数据不出内网。
• 文档解析层：处理 PDF、图片、扫描件的 OCR 和版面解析，把物理世界的信息转换成模型可读的文本。
• 数据存储与集成层：保存业务日志、处理结果、差异数据，并通过 Webhook、API 或中间表方式和现有系统打通。

为什么选分层而不是选一个“全家桶”AI 平台？因为分层的容错率高。模型挂了一个组件，其他组件还能继续跑；单个组件升级换代也不影响整体。对中小团队来说，这种可替换性比一揽子方案重要得多。

2.2 核心组件与替代方案

我们在四个组件上做了多轮比较，下面说下最终选择理由和思考，方便大家做决策时参考。

有一点要提醒：如果公司政策允许把数据发到外部 API，也可以把模型服务换成云端大模型接口，效果可能会更好一些，尤其长文档理解能力会明显提升。但多数对账和录入数据涉及业务和客户信息，走内网本地部署更稳妥。我们这套架构里，Ollama 接口和外部模型 API 可以并存，在 Dify 里按应用切换就行，灵活度很高。

2.3 部署拓扑与数据流

整个部署拓扑可以浓缩成一句话：所有服务跑在 Docker 容器里，对外统一通过内网网关暴露 API，数据只在内网流转。具体数据流是按这条链路走的：

业务文件进入某个“待处理目录”或用户上传 → 文档解析服务把 PDF/图片转成干净文本 → 流程编排平台调用模型服务，按预设字段抽取和格式化 → 代码节点做规则校验，比如金额阈值、日期格式、必填项检查 → 通过 HTTP 请求或中间表写入 ERP/财务系统 → 把处理结果和失败原因推送企业微信或钉钉。

需要注意，模型抽取这一步不是百分之百可信的，所以在它后面必须有一层“规则校验”兜底。我们专门设计了校验节点，宁可让机器人把可疑单据标出来转人工，也不要它“自信”地写错数据。AI 中台的核心价值是减少人工重复操作，而不是完全替代人的判断。

3. 从零部署：Docker Compose 拉起一套轻量 AI 中台

下面进入实操环节。我这里不是写完整的产品安装手册，而是把我们在部署过程中验证过的关键步骤和容易踩坑的地方拎出来讲，照着做基本能复现。

3.1 服务器与基础环境准备

先说说硬件底线。流程编排平台加数据库，8GB 内存的机器就能跑；但加上 7B 甚至 14B 的本地模型，内存就吃紧了。我们的建议配置是：CPU 8 核以上，内存 32GB，如果有 NVIDIA 显卡，显存不低于 12GB，没有显卡也能跑，就是速度慢一些。

纯 CPU 环境跑 Qwen2.5 7B 的量化版，推理速度大概在每秒 8 到 15 个 token，处理一个三四百字的送货单，耗时大约 20 到 40 秒，对非实时的批量录入场景完全可以接受。如果做对账这类需要大量文本比对和 JSON 生成的任务，建议上 GPU，体验会好很多。

操作系统直接用 Ubuntu 22.04 LTS，装好 Docker 和 Docker Compose 插件：

sudo apt update && sudo apt upgrade -y sudo apt install docker.io docker-compose-v2 -y sudo systemctl enable --now docker docker --version docker compose version

装完后把当前用户加到 docker 组，避免每条命令都加 sudo：

sudo usermod -aG docker $USER newgrp docker

3.2 部署流程编排平台（以 Dify 为例）

我们直接用官方 Docker Compose 方式部署。先建目录，再克隆代码：

mkdir -p /opt/ai-platform cd /opt/ai-platform git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d

第一次启动会拉很多镜像，包括 PostgreSQL、Redis、Sandbox 等，时间取决于网络环境，大概需要几分钟到十几分钟。启动完成后：

docker compose ps

看到所有容器状态为 healthy 或 running，就可以访问 http://服务器IP 了。首次访问会要求设置管理员邮箱和密码，这个密码是访问整个编排后台的管理员凭证，要妥善保管。

Dify 的 .env 文件默认可以满足我们需求，但有几个配置需要留心。如果服务器上用 Nginx 对外提供访问，把APP_API_URL和APP_WEB_URL改成你的对外域名，否则前端发的请求地址会是错的。另外，SECRET_KEY默认值建议改掉，生成一个随机字符串填进去。

3.3 部署本地模型服务

本地部署大语言模型这块，我们用的是 Ollama。安装命令很简单：

curl -fsSL https://ollama.com/install.sh | sh systemctl status ollama

确认服务在跑后，拉取模型。信息抽取和 JSON 生成任务，我们用的是 Qwen2.5 7B 指令版，量化成 Q4，效果和速度比较均衡：

ollama pull qwen2.5:7b-instruct-q4_K_M

如果内存和显卡比较宽裕，建议直接上 14B 量化版，抽取的细节稳定性会更好：

ollama pull qwen2.5:14b-instruct-q4_K_M

还需要一个向量模型，用于知识库检索和语义匹配。我们用的是 bge-m3，做中文语义相似度很稳：

ollama pull bge-m3 ollama list

这里有一个比较隐蔽的坑：Dify 是跑在 Docker 容器里的，容器内想访问宿主机上 Ollama 的 11434 端口地址不能写 localhost，而要根据你的实际部署方式判断。宿主机是 Linux，容器和宿主机共享网络时可以写http://172.17.0.1:11434或http://host.docker.internal:11434不一定在所有环境都支持，最稳妥的方法是在 Dify 容器配置里加 extra_hosts，把 host.docker.internal 指向宿主机 IP。我们自己测试时，最后直接沿用了宿主机内网 IP，简单省事。

在 Dify 后台的“设置 → 模型供应商”里添加 Ollama，填入模型名称、API 地址和上下文长度，再把 Qwen2.5 加为大模型，bge-m3 加为 Embedding 模型，就完成了模型层的注册。

3.4 初始化应用与权限

模型注册好后，就可以创建应用了。Dify 里一个应用就是一个独立的业务场景，比如“送货单自动录入”是一个工作流应用，“月度账单核对助手”是另一个工作流应用。这里我建议按场景隔离，不要把所有业务塞进同一个工作流里，否则后面权限、测试、排错会越搞越乱。

权限控制方面，Dify 管理员账号不要共享给业务人员，每个使用方单独开账号并分配应用权限。对外部系统开放的 API 建议走一个统一网关，或者在 Nginx 层加上 IP 白名单，只允许业务网段的机器访问。我们的原则是，AI 平台内部接口尽量不对公网暴露，能内网就内网，能白名单就白名单。

4. 落地场景一：用工作流消除重复录入

部署只是为了搭台，真正解决问题要靠上面的业务流程编排。第一个场景，我们处理的是供应商送货单的自动录入。

4.1 自动录入 Agent 的设计思路

流程设计成三段式：文件预处理器、信息抽取器、业务写入器。

文件预处理器专门负责把各种格式的文件变成纯文本。收到 PDF 或图片后，调用一个单独的解析服务。这个服务我们会用 Python 写一个接口，底层用 PaddleOCR 做中文识别，MinerU 处理复杂版面，输出纯文本或 Markdown。如果接入的是 Excel，就用 openpyxl 读完后转成“字段名：值”的格式，方便后续模型理解。

信息抽取器是核心。我们在大模型提示词里给出了“提取标准”：把原始文本中的关键信息映射到目标字段，不做的操作包括计算金额、推测缺失编码。每一步都要求模型输出固定 JSON，不开玩笑，如果这里不加以约束，后面再强大的校验规则都兜不住。

业务写入器负责把抽取结果按 ERP 的要求转换成可落地的格式。我们对接的 ERP 没有开放标准 API，所以就换成了“中间表”模式：AI 中台把待写入数据插入一个专门的 MySQL 表里，ERP 那边写一个定时任务轮询这张表，把状态为“待处理”的行读走。这样既能降低对接复杂度，又避免了 AI 平台直接操作核心业务数据库的风险。

4.2 关键提示词与 JSON Schema

信息抽取这一环，提示词的质量几乎决定了项目的成败。我们经过十几版迭代后，最终落到这个框架上：

你是一名供应链数据录入员。请阅读用户提供的送货单内容，提取以下字段并输出 JSON。 规则： 1. 金额统一转为数字，单位为“元”，不要带货币符号和千分位逗号。 2. 日期统一输出为 YYYY-MM-DD 格式，如果原始只有年月，则日为 01。 3. 物料编码、送货单号如果未识别，输出 null，禁止推测。 4. 只输出 JSON，不要任何解释性文字。 5. 如果一段文本中有多行物料，全部放在 items 数组里。 JSON Schema: { "supplier_name": "string", "delivery_no": "string or null", "delivery_date": "YYYY-MM-DD or null", "items": [ { "material_code": "string or null", "quantity": "number", "unit_price": "number or null" } ] }

模型侧参数把 temperature 调到 0，有 JSON mode 就开启 JSON mode，减少自由发挥。如果模型偶尔返回了 Markdown 代码块包裹的 JSON，可以在 Dify 工作流里加一个代码节点，先把 ```json 包裹内容剥掉再做 json.loads，避免因为小格式问题断掉流程。

这里再讲一个实操技巧：公司自己的历史送货单数据不要浪费。抽 10 到 20 条典型记录，作为 few-shot 示例写进提示词里，能显著提升字段对齐准确率，尤其是针对缩写、特殊单位和表格变体。

4.3 与 ERP/WMS 的对接细节

写回 ERP 的环节，很多人会直接调 ERP 接口，但实际情况是很多老系统的接口又糙又不稳定。所以我们采用中间表方案，设计了一张ai_platform_inbound_pending表，字段包括业务类型、供应商、单据号、明细 JSON、状态、错误信息、创建时间。业务系统读了数据以后，把状态改成“已处理”并回写业务单据号。

这个方案的好处是异步解耦，AI 平台这边发送失败也不影响业务系统正常运行，人工排查时可以盯着状态字段看是哪一个环节卡住了。中间表方案省掉了大量接口联调沟通，适合老系统多、接口文档残缺的企业环境。等以后核心系统升级有了稳定 API，再逐步把中间表替换成 API 调用也不迟。

操作体验上，仓库文员只需要把供应商发来的 PDF 文件拖到一个指定目录，或者在企微机器人发文件，工作流收到文件就开始自动处理。处理完发送一张“录入结果回执”到群里，包含抽取的字段截图和“已成功写入 ERP”的状态，有异常的单据单独标出来提醒人工复核。这套流程跑起来之后，原来每天的录入量由人工 2 小时缩短到机器 3 分钟，人工只负责审异常单，效果非常直观。

5. 落地场景二：用对账大脑消减对账困难

第二个场景是在第一个场景稳定运行两周后启动的，目标是替代财务每个月最头疼的那张银行余额调节表和应收应付核对表。

5.1 数据接入与标准化

对账的第一步不是匹配，而是清洗。我们把参与对账的数据分两类：一类是业务侧导出的 Excel，比如 ERP 里的应收明细、回款记录；另一类是银行和第三方支付平台导出的流水文件。把这些文件统一放进一个“对账原始数据表”，然后在清洗层做标准化。

清洗的内容包括几项：日期统一成YYYY-MM-DD，金额统一成“元”并把负号统一方向，银行流水里的“贷方/借方”换算成“收入/支出”，备注文本里的全角字符、空格统一处理。再建立“客户别名表”，比如把“张三上海公司”“张三（上海）贸易有限公司”“上海张三贸易”映射到一个内部客户编码上。这个别名表可以先用规则自动生成，再让财务人员手工确认，一次处理几百个名称，基本能覆盖主要对账主体。

5.2 模糊匹配的多种手段

对账匹配不能只靠大模型胡猜，我们分了三个轮次：

第一轮是精确匹配。如果业务流水号和银行流水号能对应上，或者日期相同、金额相同，就直接标记为“已对平”。这部分通常能自动解决 60% 以上的常规对账。

第二轮是规则辅助匹配。我们把匹配度量化成打分制，考虑因素包括日期差、金额差、交易对方名称相似度。名称相似度用两个互相补充的方法：一是编辑距离，适合简称和全称差异不大的情况；二是把标准化后的名称用 bge-m3 向量化，做余弦相似度，适合名字差别比较大的情况。最终给一个综合分数，超过 0.8 分的自动进入“预匹配”，财务看一眼确认即可。

第三轮是把“未匹配”的单据交给大模型做辅助分析。把银行一侧流水和业务侧未匹配列表，连同历史匹配样本，一起放进 Prompt，让大模型帮忙找出“金额拆分”“多笔对冲”“日期跨月”之类的隐藏关联。这里大模型只做建议，不代表最终结果，所有对账结论仍然要由财务人员确认后落库。这一轮处理好了，那些原来需要财务翻一个月凭据才能找到的差别，往往几分钟就能给到线索。

匹配结果的输出是“差异清单”，主要包括四张表：银行已收但业务未确认、业务已确认但银行未到账、金额不一致记录、无法自动匹配需人工查看记录。每张表都带关联的业务单据号和银行流水号，点击就有据可查。

5.3 差异清单与告警输出

对账结果不是生成一个文件就完事，而是要主动推送到工作群。我们用 Dify 工作流里的“企业微信机器人”节点，把差异清单转成 Markdown 摘要发到财务群。正常情况下秒回“对账完成，全部一致”，有差异时显示差异数量和类型，并附上在线查看链接。财务人员不用每天惦记要不要对账，只要看到消息提示，点进后台处理那几条可疑记录就行。

对账 Agent 上线后，月度对账从两个人忙两三天，压缩到一个人半天到一天，而且留下完整的审计过程。每一笔自动匹配记录都保存了匹配依据、打分明细和操作人，这比翻 Excel 里的批注清爽太多了。

6. 部署后遇到的问题排查与避坑记录

这几周折腾下来，踩过的坑比预想得多。下面把典型问题和处理方式整理成速查表，希望能帮大家少走弯路。

6.1 场景型问题速查表

6.2 模型幻觉与校验设计

所有用大模型做数据提取的方案都会面临一个核心问题：幻觉。模型不是数据库查询，它会在不确定时“脑补”一些合理但错误的内容。我们的对策分三层：

第一层是提示词约束，明确禁止在物料编码、编号类字段上做推测，不确定就输出 null。第二层是规则校验，抽取结果不能直接落库，必须过一层代码节点，检查必填字段是否为空、金额是否在合理范围、日期是否是一个真实日期。第三层是抽检复核，我们要求业务方每天随机抽 5% 的自动录入单据做二次确认，用来发现规则之外的系统性偏差。

这里特别提醒一句：不要用大模型去做需要高精度算数的操作，比如把“含税金额”换算成“不含税金额”这种事，我们自己吃了亏。模型大概率会把税率算错或者把四舍五入搞乱。正确做法是让模型抽取原始值，再用 Python 规则去计算派生值，把“智能”留给识别文本和判断语义，把“精确”留给代码。

6.3 数据安全与权限控制

部署 AI 中台，安全合规绝对要放在第一位。我们的处理方式是：业务数据尽量留在内网，所有模型推理走内网地址；对 Dify 的 API 启用访问令牌，只授权给业务系统调用；对账结果文件在服务器上保留审计日志，记录每次查询和写入操作。

有一个常被忽略的细节是容器日志。如果业务单据里包含客户隐私信息，日志里打印了原始文本，运维人员随时能在 Docker 日志里看到完整内容。我们后来把所有涉及业务数据的日志级别调低，并在代码里对打印内容做了脱敏处理，只保留单据号、字段长度等必要信息。这个动作在等保和内部审计时非常有用。

7. 最后想说的几条实在话

平台部署完、场景跑通之后，回头想想，真正让项目成功的其实不是技术本身，而是几个看起来不太“AI”的决定。

第一，选模型别贪大。7B 模型在单据抽取和规则对账上已经够用，14B 会好一点，但带来的硬件成本和推理延迟提升并不一定划算。先把流程跑通，再根据效果决定是否换大模型，这样风险最低。

第二，推进节奏要克制。我们刚开始激动，想一口气把合同审核、库存预测、智能客服全塞进中台，后来被业务方拉着冷静下来，先只做两个最痛、ROI 最明显的场景。等录入和对账都跑顺了，IT 团队再慢慢加新应用，业务部门对 AI 的信任感才会稳步建立起来。

第三，数据质量永远是根本。AI 中台不是神仙，垃圾进去垃圾出来。项目上线前一定要花时间做数据字典、别名表、编码规范，这是一次性投资，却能减少后面 80% 的匹配错误。我们最后甚至安排了一位财务骨干兼职负责“数据质量”这件事，她比我们更清楚哪些字段能信、哪些渠道的数据需要前置清洗。

这套轻量 AI 中台后面还能怎么扩展？我个人的想法是：把已经接好的文档解析和抽取能力复用到合同问答、供应商资质审核里，把知识库和检索能力接到客服和售后场景。底层那些组件不变，业务侧只需要建新工作流、配新提示词，就可以扩展出新的 AI 应用。这也是当时坚持用“能力中台”思路的原因——完成一次部署，后续就能不断从这套底座上长出新的生产力。希望这次复盘能给你们带来一些可以直接落地的启发。