企业官网建设流程全解析

上周五晚上九点，我路过财务部，看到小林还在工位上，屏幕上开着三个系统窗口，正把销售系统里的订单号一个个复制到财务系统里核账。她跟我抱怨了一句："每周五都是这个流程，数据明明是一个源头出来的，为什么每次都要重新录一遍、重新对一遍。"这句话我记了很久，也是后来我下定决心去做这个"轻型AI中台"的直接契机。

这几个月，我利用手头的服务器资源，把一套基于开源组件的轻型AI中台从规划到落地完整走了一遍，针对性解决的就是标题里那两件事：消除重复录入、消减对账困难。没有动辄几个亿的DataOps平台，没有几十人的算法团队，用的全是社区成熟的开源方案——本地部署大模型做底座，可视化编排平台做应用层，再把OCR、向量检索、工作流串起来，跑通了两条真实业务链路。

这篇文章不是什么概念科普，而是一个可以跟着复现的实战记录。我会把技术选型过程、两个核心业务场景的落地细节、完整部署步骤、以及我在部署和运行阶段踩过的最典型的几个坑，全部摊开来讲。适合正在考虑搞AI中台但预算有限的中小公司IT负责人，也适合想用本地大模型解决实际业务问题的后端工程师和数据同学。

1. 很多人把中台想复杂了：这个项目到底要解决哪两件事

1.1 重复录入的本质是"数据搬运工"太多

先说重复录入。你去任何一家业务系统多的公司里看，都会发现同一个数据被录入了好几次。销售在CRM里录一份合同，财务开票系统里要再录一遍购买方信息和金额，仓储系统发货时还要手工对照着填一次收货单位。数据本身从源头到末端没有任何变化，变化的是不同系统的表结构、字段命名和业务口径。

过去为什么宁可让员工重复劳动也不做系统打通？因为传统系统集成的成本实在太高了。两个系统之间要开发接口，要约定报文格式，要解决字段映射，还要考虑后续升级维护。一个接口的开发周期以周为单位，而公司里可能同时存在几十个这样需要打通的点。业务部门等不起，那就只能靠人肉搬运。

AI中台在这里的价值不是"更聪明的系统集成"，而是把搬运工作本身自动化。让大模型读一张采购单、一份合同、一张发票，把里面的关键要素抽取出来，再按目标系统的字段规则自动填进去。人从"打字员"变成"审核员"，重复录入这个动作自然就消失了。

1.2 对账困难的本质不是算法不行，而是数据没先"说同一种话"

再说对账困难。我一开始以为对账难在"算法不够智能"，真做起来才发现，卡点根本不是匹配算法，而是两边数据根本不在同一套口径上。

举几个最常见的例子。业务系统的收入确认日期和银行流水的到账日期可能差两三天；同一张采购单在A系统里金额是含税价，在B系统里是不含税价；对方单位名称在合同里叫"北京华信科技有限公司"，在发票里却写成"华信科技（北京）有限公司"。这些差异叠加在一起，财务对账的时候只能靠人脑去判断"这两个到底是不是同一笔"。

所以AI中台要做的最重要的一件事，不是一上来就做差异分析，而是先把两边数据变成"可比较"的形态。先做字段映射和标准化，再做匹配，最后才是差异识别。这一步捋顺了，对账难的问题直接消掉一大半。

1.3 为什么"轻型"两个字是关键

现在市面上讨论AI中台，很多方案都喜欢往大了做，讲起来全是数据底座、模型工厂、特征平台、MLOps，一套下来预算至少千万级，实施周期按年算。但对于绝大多数中小企业甚至大公司的某个事业部来说，真正要解决的痛点可能就两三个。

"轻型"的核心含义就是：用最小的成本，最快地解决最痛的问题。不需要自研模型，用现成的开源大模型；不需要自研平台，用Dify这类开源编排工具；不需要建大数据集群，一台带GPU的服务器就能跑起来。我这次全部采用本地部署的路线，一方面是因为财务数据、客户信息、合同内容这些敏感数据不允许出内网，另一方面也是想验证一下"轻量到什么程度还能干成事"。

两周内把MVP跑通，一个月内让业务部门实际用起来，这才是中小企业需要的中台节奏。

2. 技术选型复盘：我为什么最终选了 Ollama + Dify 这一套

2.1 模型服务层：本地部署大模型是底线

整个方案里，模型层是第一块拼图。我最早考虑过直接调云端大模型API，效果确实好，但一个现实问题摆在那：要处理的是财务单据、合同文本、客户信息，这些数据别说传出去，连走公网都会让合规那边炸毛。所以结论很明确，必须本地部署，私有化运行。

模型服务层我选了Ollama。原因不复杂：安装简单、依赖少、对GPU的要求灵活，而且社区里现成的模型可以直接拉取。这次我用的是DeepSeek系列的开源模型来跑表单理解、字段抽取和对账辅助。选择DeepSeek主要看重它中文能力强，在处理中文发票、合同条款、公司全称这些文本时明显比同参数级的其他模型更稳。Ollama配合本地GPU跑起来之后，模型调用方式和OpenAI兼容，接口层面非常省心。

如果你所在团队已经有用惯了vLLM或者llama.cpp的，也可以平替。但Ollama对中小团队最友好的地方在于，它把模型下载、加载、常驻管理、并发控制都做成了傻瓜式操作，可以少操很多心。

2.2 应用编排层：Dify 承担了80%的"脏活"

模型层就绪之后，接着要想的是：怎么让业务人员用得起来？总不能让他们打开终端去敲Python调模型接口。

我选Dify作为应用编排层，核心看中的是三点。第一，它天生支持对接Ollama这类本地模型供应商，可视化配置就能把模型接进来。第二，它内置了知识库和检索增强生成（RAG）的完整链路，后面做合同条款问答、制度查询直接能复用。第三，它支持编排多步骤工作流，这意味着"读文档、抽字段、填表单、送人工确认"这条链路，不需要写一堆胶水代码，在界面上就能拉出来。

实际用下来，Dify让我少写的代码量在一千行以上。模型调用、Prompt管理、日志追踪、权限控制都有现成的界面，这对一个主要精力在业务落地的团队来说，价值非常大。

2.3 模型选型：7B、14B、32B怎么实测取舍

模型参数档位的选择，直接决定了显存需求、推理速度和效果上限。我在这套中台里前后测了7B、14B、32B三个档位的模型，结论值得分享一下。

对仅做"把采购单里的供应商、金额、日期抽出来"这类任务，14B是性价比最高的档位，单卡24G显存就能跑得动，速度和质量的平衡点最好。7B用在从聊天记录、备注文本里提取关键词这类轻量任务上没问题，但放到整张结构化表格上就不太够用了。32B我最后只在合同条款深层理解这类非高频场景里保留了一个实例，平时不常驻。

3. 消除重复录入的实现细节：从"人填表"到"AI填表"

3.1 场景还原：一张采购单在三个系统里被录入三次

先还原一下部署前的业务流程。业务员收到供应商发来的采购单，是一张PDF或者照片。他先要打开ERP系统，把采购单号、供应商名称、订单日期、物料明细、金额逐行填进去；然后打开OA系统走审批，再把同样的信息填一遍；审批通过后，财务人员拿到单据，还要在财务系统里把供应商、含税单价、税额这些字段再录一次。

一张单子，三个系统，三次录入，中间任何一次敲错一个数字，后面对账就多一个差异点。这就是典型的重复录入加对账困难的组合问题。

AI中台要替代的，是把这张采购单从"解析"到"填表"的整个过程自动完成。拆解下来就是四步：原始单据解析、业务要素抽取、目标系统字段映射、自动提交或人工确认。

3.2 基于表单理解Agent的自动填充链路

我在Dify里搭了一套"表单自动填充Agent"工作流，核心流程是这样的：

1. 接收端：业务员把采购单文件传到指定入口，可以是钉钉/企微机器人，也可以是一个简单的上传页面。
2. 解析端：如果是PDF或图片，先调用OCR服务转成文本；如果是Excel或Word，直接解析成纯文本。
3. 抽取端：把原始文本交给本地大模型，Prompt里明确要求输出JSON格式，字段包括供应商全称、采购单号、签订日期、物料清单、含税总金额、币种、付款条件。这个环节是AI中台的核心能力所在，Prompt设计得非常关键。
4. 映射端：拿到JSON后，通过一段Python脚本按目标系统的字段规则做映射。比如ERP里的"供应商"字段是编码而非名称，就调用基础资料接口把名称翻译成编码。
5. 提交端：调用各系统的API自动填入表单。考虑到业务系统的稳定性，我在提交前插入了一个人工确认环节——所有字段自动填好，页面展示给业务员，他扫一眼点确认，系统才真正提交。

这套链路跑通之后，业务员处理一张采购单的时间从十五分钟缩短到一两分钟，主要时间花在审核AI填得对不对，而不是自己打字。

3.3 OCR与模型分工：用本地视觉模型吃掉不规范的纸质单据

整个链路里最容易翻车的环节其实是OCR，而不是大模型本身。如果单据是结构化的电子文件，比如规整的Excel，大模型抽取非常轻松。但现实业务里永远有大量的扫描件、拍照件、传真件，表格线歪的、印章盖在文字上、字迹深浅不一。

我在OCR选型上坚持走本地路线，核心原因是合规。发票、合同这些单据直接传云OCR是在给自己挖坑。我用了PaddleOCR作为基础识别层，它在中文字符、表格线检测上的表现在开源方案里算是第一梯队。每次扫描件先过PaddleOCR识别出文本块，再做版面还原，把表格结构尽量还原成"表头-单元格"的对应关系，然后再交给大模型做字段抽取。

这里有一个重要经验：不要试图让一个大模型直接读懂扫描图片里的表格，那样鲁棒性会很差。正确的做法是OCR负责"看得见"，大模型负责"看得懂"，两者各管一段。这个分工在后面踩坑章节我还会再展开说。

4. 消减对账困难的实现细节：把"人对账"改成"机器先对一遍"

4.1 先把四张表的口径拉齐：字段映射与标准化

对账困难最终的落地表现，是财务人员每月要把业务系统里的应收/应付数据、银行实际的流水、发票系统里的开票记录、以及内部账套里的科目余额四张表来回比对。

做AI中台之前，我一直以为对账的难点是"找差异"，做之后才明白，真正的难点是"在找差异之前，先把四张表变成同一套语言"。我建立了一张字段标准化配置表，把四张表里的关键字段逐一映射到统一口径：

标准化这一步，既用了规则脚本处理确定性的格式转换，也用大模型处理那些规则处理不了的脏文本。典型的就是客商名称归一化，纯粹靠正则根本写不全，交给大模型按统一规则重写后准确率高很多。

4.2 用向量相似度做"模糊匹配"：解决同一笔交易两种写法的难题

口径拉齐之后，你会发现还有一个顽固问题：两边数据里"这同一笔"长得不完全一样。对方单位名称差几个字，备注里单据号格式不同，金额因为手续费导致差几块钱。这些数据用传统的关系型数据库JOIN是永远对不上的。

我的方案是在匹配环节引入向量检索。具体做法是：把标准化之后的对账记录里的关键字段（客商名称、摘要、备注、金额近似值）拼成一段文本，用Embedding模型转成语义向量，写入向量数据库。做匹配时，拿另一侧数据的向量去检索最相似的N条候选，再结合金额、日期做二次过滤，最后形成一个带置信度分数的匹配建议。

比如银行流水摘要里写"货款-华信科技"和业务系统里记账摘要写"华信科技（北京）有限公司 9月订单款"，传统关键字匹配根本对不上，但向量化之后，这两条文本的语义方向非常接近，余弦相似度很高，系统会先把它们作为疑似匹配对推给财务复核。这一步直接解决了我之前最头疼的脏数据问题。

匹配不是终点，人审闭环必须保留。我设了一条规则：相似度超过0.95且金额日期一致的直接自动勾稽；相似度在0.8到0.95之间的进入待复核队列，由财务一键确认；低于0.8的才真正进入人工排查列表。这样设计之后，财务真正需要一行行肉眼看的数据量降到了原来的五分之一以下。

4.3 异常报告怎么设计才不会又被扔进垃圾桶

很多系统做对账报表，习惯于把"所有对不上的记录"全部列出来，一张Excel几百行发给财务，财务根本看不过来，最后结果就是报表被归档，问题还留在那。

这次我让AI中台在生成异常清单之前，先对每一条差异做一次"归因解释"。系统会先判断这条差异属于哪个类别：是时间差导致的未达账项，还是金额口径不一致，还是名称写法差异，或者是真正的漏记错记。自动生成的报告按风险等级排序，同时附上机器对该差异的初步解释。

比如某条流水在系统中找不到对应单号，模型会结合备注信息、金额相似度、对方名称相似度给出一个结论："疑似与业务单BD20241008-003存在两日到账时间差，建议核对9月29日以后入账流水"，财务只需要验证这个解释是否成立，而不是从头大海捞针。正确的归因做到位，AI中台在财务同学心里的信任度才算真正建立起来。

5. 从0到1部署实录：硬件、安装、调优全记录

5.1 硬件清单与资源预算：16G显存够不够用

我最开始只有一台旧工作站，单卡16G显存。实测发现跑7B模型做轻量任务完全没问题，但要常驻14B模型同时做表单抽取和对账归因，显存就吃紧了，并发一上来就开始排队。后来调到一台双卡机器上，显存问题彻底缓解。

根据这几个月的实测，我给不同预算的团队列个参考：

另外提醒一句，中台不是一台放在你工位下面的玩具机，最终是要让业务部门通过内网访问的。所以网络部署至少要满足：模型服务绑定内网地址，Dify平台对业务部门开放，数据链路全在内网闭环。

5.2 Ollama 部署细节：模型文件管理、并发参数、开机自启

Ollama的安装本身没什么好说的，一条命令就搞定。真正要花心思的是运行参数。我在部署时做了三件事：设置OLLAMA_HOST让服务监听内网IP而非本机回环；设置并发参数控制同时处理的请求数；设置OLLAMA_KEEP_ALIVE控制模型在显存中的驻留时间。

举个例子，Linux上用systemd管理Ollama服务时，我改了service文件里的Environment。要注意OLLAMA_MAX_LOADED_MODELS这个参数，多应用场景下如果不限制，Ollama会把多个模型同时驻留显存，直接导致显存被打满，后面我会在踩坑章节详细说。

模型管理上，建议把下载好的模型文件和模型运行时的缓存目录单独挂到数据盘，避免系统盘被几个大模型文件塞满。这个看起来很基础的细节，实际操作中真的会踩坑。

5.3 Dify 部署细节：Docker Compose 编排、接入 Ollama、环境变量

Dify的官方部署方式是Docker Compose，直接拉取全套容器就能起来，包括API服务、Web服务、Worker、数据库，以及可选的向量数据库和Redis。整个过程我没有改代码，只调了两个地方。

一个是模型供应商配置。Dify后台"模型供应商"页面里可以直接添加Ollama，填上Ollama的内网地址（一般是http://内网IP:11434），把要用的大模型名称填进去，就能在应用里调用了。模型名称要跟Ollama里实际拉取的模型完全一致，比如我用的模型全名是deepseek-r1:14b，这里就不能只写deepseek。

另一个是向量数据库。Dify默认支持多种向量库，我用的是Qdrant，同样走Docker方式部署。Dify界面上配置好之后，知识库上传文档时会自动完成切片和Embedding写入。这一步做完，Dify后台就能直接创建聊天助手和工作流应用了。

5.4 向量检索服务的初始化：embedding 模型选择与索引构建

向量检索这块，最关键的是选对Embedding模型。中文场景不建议用通用英文Embedding模型跑，效果会差很多。我用了BGE系列的中文Embedding模型，在客商名称、摘要文本的语义匹配上表现明显更好。

初始化向量索引时有两个参数要特别注意：文档分片大小和重叠长度。分片太大，检索时片段粒度太粗，命中不精准；分片太小，上下文信息不完整，模型理解困难。我最后用的分片大小是500字符、重叠100字符，对合同和制度类文档效果比较均衡。

建立索引后一定要做一次抽样验证：拿几条真实业务数据去搜，检查相似度排序是否符合预期。不要等上线了才发现检索结果全是垃圾，那段debug时间会非常痛苦。

6. 踩坑实录：三个最典型的部署与运行故障排查过程

6.1 Ollama 服务偶发假死：显存没释放，还是并发队列堵了

现象很典型：Dify里的工作流跑了一周，某天开始所有请求都超时，日志里全是连接错误。第一反应是不是模型崩了，重启Ollama服务确实能恢复，但过一两天又复发。

我开始逐步排查。先用nvidia-smi看显存占用，发现显存几乎被打满，但奇怪的是Ollama刚启动时只加载了一个模型。再用ollama ps查看当前驻留的模型，结果发现除了表单抽取用的14B模型，还有一个7B模型和一个小模型也同时驻留在显存里。原因就出在OLLAMA_MAX_LOADED_MODELS这个参数上，如果不设置或设置太大，Ollama会根据请求自动把用到的模型全部加载进显存，多个模型挤在一起，显存不够就开始交换，整个服务就假死了。

修复方案：明确设置OLLAMA_MAX_LOADED_MODELS=1，强制同一时间只驻留一个模型；同时把不同模型放到不同的Ollama实例或服务端口上，避免相互挤占。改完后再没有因为这个原因复发过。

6.2 Dify 的应用流偶发超时：连接池与大上下文的全链路定位

第二个坑是Dify工作流偶发超时，而且很有规律：每天上午十点前后必现，下午偶尔来一次。排查过程分了三步：先看Dify日志，发现大量请求卡在"等待模型供应商响应"这一步；再看Ollama侧日志，发现上午那个时段模型推理耗时突然从两三秒涨到三十秒以上；最后点开具体请求，发现那些超时的请求都是长上下文请求。

根因有两个。一是上午是业务高峰期，并发请求多，Ollama默认串行队列处理不过来，大量请求排队。二是Dify里有些Prompt里把历史对话和参考资料全部塞进了上下文，导致模型输入Token膨胀，推理时间和显存占用都上去了。

调整方案：在Dify侧对应用做流量拆分，高频短任务走一个轻量模型，长文档理解任务单独走一个模型；同时限制上下文长度，给工作流节点加上了最大Token截断。并发方面，把OLLAMA_NUM_PARALLEL设置成按显存余量计算的合理值，让Ollama能够并行处理互相独立的请求。改完之后高峰期的平均响应时间重新回到了三秒以内。

6.3 中文表格识别乱码：从通用视觉模型到本地OCR的切回

最开始我图省事，想直接让大模型看扫描件的图片，结果发现一个非常麻烦的问题：识别结果里频繁出现错字、漏行，最离谱的是金额栏的"收款人"三个字被识别成"收 款 人"，中间多了空格，后面字段抽取全乱了。

排查过程是这样的：我先拿原始图片和模型输出对比，发现模型对密集表格的辨认能力并没有宣传的那么好，特别是表格线、印章、手写批注混在一起的扫描件，输出稳定性很差。然后又对比了一条关键链路，让同一个模型去读OCR出来的文本，发现正确率一下子上来了很多。

原因也简单：视觉大模型对中文密集表格的抗干扰能力不足，而OCR模型经过专门训练，对版面结构更敏感。数据库场景下的表格乱码，最佳路线是"专业OCR配合规则做版面还原，大模型只做语义抽取"。我把这条链路的顺序改过来之后，识别准确率从不到八成直接拉到了95%以上，问题彻底解决。

7. 上线三个月后的复盘：效果、成本、还能怎么扩展

7.1 重复录入工时下降多少才算及格

上线三个月，数字算是比较实的：财务和业务侧日均处理的单据量没有变，但单张单据的综合处理时间从平均十五分钟降到了不到三分钟。人工介入的动作从"逐字段录入"变成了"查看并确认"。重复录入相关的工时整体下降了接近60%。

更重要的是错误率的下降。以前人肉录入，一张单子总有一两个字符出错的风险；现在字段由模型从原始单据抽取，再经过标准化和规则校验，录入类错误基本归零。财务那边反馈，最明显的感受是月底对账的"不平项"少了，因为源头录入错得少了，后续所有环节都跟着顺了。

7.2 对账异常率的变化与复核机制的调整

对账单侧的月度异常条目数，从上线前的每个月两百条左右降到了现在的四五十条，而且这四五十条里大部分是AI已经做过归因解释、只需要财务确认的情况。财务真正需要从头人工排查的，最后只剩十几条。

财务部门的操作习惯也发生了实质变化。以前是月初花两三天时间逐笔核对，现在变成每天花十分钟看AI推送的待确认队列，效率提升的同时还不用加班了。新的复核机制是月度抽盘加异常点抽查，也就是说因为AI把源头的账目录错了堵住，财务不再需要等月底大扫除。

7.3 下一步玩法：从"填表/对账"延伸到知识库问答与报表解释

这套中台跑稳之后，我目前的规划是先把知识库问答做起来，把采购合同、财务制度、报销标准这些文档传进去，让新员工直接问AI"差旅报销要什么材料""供应商准入流程是什么"，减少事务性咨询对老员工的占用。再往后可以尝试让AI解释财务报表里某个科目变动的原因，这个需要的数据质量要求更高，我打算先在单个事业部试点。

中台的边界很重要。我不会盲目往里面塞功能，每个新增应用都要先回答一个问题：它是替代人工真的在减少重复劳动，还是仅仅在制造一个新的演示Demo。目前看来，把基础能力平台化之后，新增一个应用的成本确实在快速下降，这也是将这套轻型架构继续扩展的信心所在。

如果只让给后来者一句忠告，我想说：别一上来就追求建设一个宏大完整的中台。先把一两个真正让人痛到不行的流程跑通，AI的能力自然会沉淀为平台能力，中台是打出来的，不是规划出来的。