最近团队做了个内部提效项目方向叫“轻型AI中台”。名字听起来大实际落地的场景很具体消除重复录入、消减对账困难。做完之后财务和运营两条线的日常工作量明显下降我才觉得这方向值得单独写一篇复盘。先说清楚它是干什么的。企业里大量单据——发票、银行回单、出入库单、报销单——需要人肉搬到业务系统里录完业务系统还要对着银行流水一笔一笔核销月底对账对到怀疑人生。所谓轻型AI中台就是在这堆系统前面加一层“智能搬运工”先把单据图片和PDF里的内容抽出来用大模型整理成结构化字段再通过接口回填到ERP或财务系统同时把两边系统的数据拉通按规则自动完成匹配和对账。它解决的是接口缺失、系统孤岛、人工录入和账目核对这几件事适合正被录入量和对账折磨、又不想上来就搞重型数据平台的中小团队参考。我在这篇文章里会把这套东西从设计思路、技术选型到部署细节、上线坑点完整讲一遍。你不用照着抄代码但可以把它当成一份从零搭建“内部AI提效层”的路线图尤其是最后那节常见问题是我实际跑了两周才踩完的坑建议直接保存。1. 先想清楚再动手轻型AI中台到底解决什么问题1.1 重复录入的根源系统孤岛与人工搬运先别急着聊模型选型。很多团队一看到AI中台四个字就兴奋张口就要上大模型、上RAG、上智能体结果连自己要解决什么痛点都没讲清楚。我们这个项目的起点特别朴素财务共享中心每天收到几百张发票和回单ERP是老系统没有现成的接口供应商接口报价高得离谱于是所有单子都靠录入员手动敲进系统。这背后的本质不是“人懒”而是系统孤岛。业务系统管业务财务系统管账银行系统管流水三个系统之间没有自动化的数据通道。录入员就是这条通道上的人力桥梁每一笔单据都要人工完成“看单子→找字段→敲键盘→提交”这个动作。重复录入的本质是数据在不同系统间搬运时缺少一个标准化的“翻译层”。轻型AI中台做的事情就是把这个人肉搬运工替换成“OCR识别大模型抽取接口回填”的流水线。注意我说的是替换掉搬运动作不是替换掉人。人从敲键盘变成审核机器结果这是后面要重点讲的人机协同设计。实际推进中你会发现技术反而不是最难的难的是让老系统愿意“开口说话”。很多老系统没有API或者有API但需要商务谈判。所以我在设计系统时额外加了一个兜底方案系统输出结构化JSON后如果目标系统没有接口就自动生成符合导入模板的Excel文件人工只要“下载—导入”两步。这个细节虽然土但在老系统改造上省了大力气。1.2 对账困难的本质数据口径无法对齐再说对账。很多团队以为对账难是“数据对不上”其实大部分情况是“口径不一样”。两边系统的数据其实都记录了同一笔交易但字段定义完全不同。举个我遇到的例子银行的回单里叫“付款人名称”业务系统里叫“客户名称”银行写的“交易日期”是资金实际清算日业务系统里的“业务日期”是合同签约日两者可能差两三天。再加上金额含税不含税、往来单位简称全称不一致、摘要写法五花八门月底财务对账基本是在做人工模糊匹配。轻型AI中台在这里扮演的是“口径转换层”。我用大模型对银行流水摘要做语义清洗把“收XX公司货款”和“XX公司合同编号XXX回款”归一化成统一的往来单位字段再用规则引擎做三层匹配金额完全相等、日期偏差±3天、单号或名称做模糊匹配。命中越多置信度越高只有低置信度的才转人工。这个设计的巧妙之处在于它不要求两个系统改造自己的数据结构而是在中间层建立一个“统一台账”让两边数据在进入台账前就已经完成规范化。对账从“月末人工Excel大战”变成了“每天凌晨自动跑批早上看差异表”工作量直接消减一个数量级。1.3 为什么是“轻型”而不是“重型”别一上来就搞平台这里必须说一个很多团队容易踩的坑一提到中台就条件反射地想到主数据管理、数据治理、微服务架构、全链路监控、组织级共享服务中心恨不得把一个企业内部的数据湖都搬出来。结果往往是项目做了三个月还在搭“平台底座”业务方已经等得不耐烦了。我一直推崇轻型路线核心就一句话先用一个周末解决一个具体业务问题再谈平台化。轻型AI中台的“轻”体现在四个地方部署轻单台服务器Docker Compose编排不引入K8s和复杂的服务网格模型轻优先用7B量化的开源大模型一张普通显卡甚至纯CPU都能跑不追求刷榜场景轻只聚焦2到3个高频痛点场景比如单据识别、对账匹配、台账核销不搞全业务覆盖团队轻两三个会写Python的人就能维护不需要专门的算法工程师和数据平台团队我们用这套思路从零到跑通第一个真实场景大概用了一个多星期。这个速度在传统“平台思维”下根本不敢想象。轻是因为它能快速见效能快速见效业务方才会愿意持续投入数据质量和你一起打磨。2. 架构设计与技术选型一套可以周末部署完的AI中台2.1 整体拓扑接入层、智能层、业务层轻型AI中台的架构不复杂我用三句话就能描述清楚整体数据流接入层接收图片、PDF、Excel等原始单据做格式转换和预处理统一走API入口智能层OCR负责把图片变成文本大模型负责把文本变成结构化JSON规则引擎负责校验和兜底业务层把结构化数据回写到业务系统、生成统一台账、执行对账匹配、输出差异表用文字描述就是单据文件先进OCR服务转成文本块文本和业务预设的提示词一起送给大模型大模型吐出JSON字段JSON过一遍规则校验通过的进台账不通过的进人工队列台账和从银行/ERP同步来的流水做对账匹配生成每日差异表。这个分层最核心的价值是解耦。OCR、大模型、业务回写三者互不依赖任何一个模块都能单独升级替换。比如今天用PaddleOCR明天想换别的OCR引擎只要保证输出还是文本块上下游就不用动。再比如大模型从7B升到14B只是推理服务内部变化网关和业务层无感。因为不依赖K8s我连注册中心都没用。服务间通过Docker Compose的内部网络互访一个固定网段内用服务名做互相调用。这种“单机内网通信”看起来简陋但胜在零额外运维成本。对日处理几百上千张单据的团队来说完全够用。2.2 模型选型OCR和LLM分开选不混为一谈很多人误以为AI中台就是“一个大模型包打天下”这是完全错误的理解。识别和抽取是两件不同的事拆开选型才是正确姿势。OCR部分我们选的是PaddleOCR主要看中三点一是中文识别效果好尤其印刷体和常见手写体二是自带版面分析能力发票、回单这种固定版式可以切分出表格区域三是官方提供Docker镜像部署极其省事。GPU跑的加速比明显但CPU模式也能用只是速度慢一些适合单据量小的场景。大模型部分选的是Qwen系列具体来说当时用了Qwen2.5-7B-Instruct的Q4_K_M量化版。为什么不用更大的14B或者72B因为我们的核心诉求是私有化部署和响应速度单据抽取任务本身属于“指令跟随信息抽取”7B量级在结构化输出上已经表现得相当好。如果你手头有24G显存的卡那上14B会更稳但代价是并发能力下降。硬件不够的时候量化7B是性价比很高的选择。给一张我们内部对比过的选型参考表模型方案显存要求抽取稳定性并发能力适用场景Qwen2.5-7B-Q4CPU/8G8G内存在边缘线中等低单并发测试验证、个人项目Qwen2.5-7B-Q4GPU 12G12G良好中等可设并发4中小团队日常单据Qwen2.5-14B-Q4GPU 24G24G优秀低并发1-2复杂单据、高精度要求Qwen2.5-72B多卡/大内存48G优秀低预算充足的团队另外提一句语音类附件比如会议录音转纪要和报销说明可以用Whisper本地模型少量情况我们自己跑过部署方式和LLM是同一个套路。这是题外话但对完整中台能力是个有意义的补充。2.3 部署形态为什么用Docker Compose而不是K8s有一部分读者可能会问现在K8s不是标配吗为什么用Docker Compose这种“老古董”我的回答很简单K8s解决的是大规模、高可用、弹性伸缩的问题而这套轻型AI中台的负载特征是“单机可扛、峰值有限、无状态服务为主”上K8s属于给自己找麻烦。你得多维护一个控制平面还要解决存储、网络、Ingress一堆问题这对三五个人的小团队是纯负担。Docker Compose在这套场景下有几个实打实的好处一键启动所有服务开发和生产环境行为一致服务间通过Compose网络互访不用操心IP变化升级某个组件只要替换镜像重建容器其他服务不受影响配置直观写在一个yaml文件里所有人都能看懂下面是我们docker-compose.yml的简化版结构包含四个核心服务网关、OCR、LLM推理、任务队列。version: 3.8 services: gateway: build: ./gateway ports: - 8000:8000 environment: - OCR_URLhttp://ocr:5000 - LLM_URLhttp://ollama:11434 - DB_URLpostgresql://aihub:aihubpostgres:5432/aihub depends_on: - ocr - ollama - postgres ocr: image: paddlepaddle/paddleocr:latest volumes: - ./models:/paddle/models - ./data:/paddle/data expose: - 5000 ollama: image: ollama/ollama:latest volumes: - ./ollama_data:/root/.ollama environment: - OLLAMA_NUM_PARALLEL4 - OLLAMA_MAX_LOADED_MODELS2 expose: - 11434 postgres: image: postgres:16-alpine environment: - POSTGRES_USERaihub - POSTGRES_PASSWORDaihub - POSTGRES_DBaihub volumes: - ./pg_data:/var/lib/postgresql/data nginx: image: nginx:alpine ports: - 443:443 - 80:80 volumes: - ./nginx/conf.d:/etc/nginx/conf.d - ./nginx/certs:/etc/nginx/certs depends_on: - gateway你注意我用了一个postgres数据库这是用来存统一台账和任务状态的。很多开源项目喜欢用SQLite但在生产环境跑SQLite并发写容易出问题。PostgreSQL单独起一个容器多出来的内存开销完全可以接受。2.4 用Dify还是自研网关先想清楚你要的是原型还是生产做AI中台一个绕不开的问题要不要用Dify这类开源平台。现在社区里很多人在问Dify本地部署教程热度很高说明它确实解决了一部分人的痛点。我的观点是分情况。如果你要的是快速验证想法比如让业务方看看大模型抽取单据的效果那Dify非常合适。它自带了工作流编排、知识库、对话界面你只要把提示词和模型服务接进去几个小时就能出一个可交互的Demo。这类平台的价值是让业务方提前看到结果降低沟通成本。但如果你要的是深度集成到业务系统里比如把抽取结果自动回写到ERP那我就建议自研一个轻量网关。原因也很实在第一Dify的对外API接口主要是对话式封装按业务场景定义字段级入参出参反而有些绕第二当需要做置信度判断、人工复核队列、自动重试这些精细化控制时自研代码的可控性高得多第三维护一个两百行代码的FastAPI网关比维护一套Dify平台心理负担小得多。我们的最终方案是两者结合Dify用来做内部原型的快速验证和Prompt实验生产链路跑的是自研网关。实验归实验生产归生产各取所长。3. 核心交互设计让“自动录入”真正被业务接受3.1 置信度与人机协同不要让机器全权代理这是整个项目里最值得分享的设计心得。一开始我们也想做成“全自动”单据进来直接回写系统财务连看都不用看。但真的落地时发现行不通——不是技术不行是业务方不敢放权。任何自动化系统都有出错概率。就算你准确率能到98%那2%的错误落在具体某一张重要发票上就是100%的事故。业务方不可能为一个不确定的自动化系统放弃人工审核的责任。所以后来我们改了设计思路从“全自动”变成“置信度分级”高置信度比如匹配度≥95%自动回写业务系统同时留审计日志中置信度80%到95%进入人工复核队列页面上一屏展示原文截图和抽取结果人只需要确认或修改低置信度80%直接转人工录入机器结果作为参考草稿这套设计的本质是把AI当成了一个“很聪明但需要被约束的员工”。它干活但行为被规则约束超出能力范围的事主动交还给人类。机器处理它能处理的人只需要负责机器不擅长的双方的工作量都能降下来。这里有个实战技巧置信度阈值不是固定的而是动态调节的。上线第一周把高置信阈值设到99%宁可多转人工也别自动回写错误数据等业务方看到机器结果确实可靠再逐步放开到95%。信任是一点一点攒出来的别指望一步到位。3.2 字段映射与冲突处理老系统改造的隐性工作量在系统设计之外还有一个被严重低估的隐性工作量字段映射。AI中台抽取出来的字段叫什么都可以但回写到老系统时必须变成老系统认得的名字和格式。这里最怕的是“字典不完全”很多老系统的枚举值没有文档得靠人工梳理。举几个实际遇到的例子AI抽取结果里“日期”是标准格式老系统里却是“YYYYMMDD”八位字符串AI抽取的“含税金额”老系统要的是“不含税金额”中间差一个税率字段AI抽出的“往来单位”是全称老系统的下拉列表里存的是简称。这些差异如果不提前处理回写时就是一片报错。我们做法是在网关里加了一个字段转换层本质是一个mapping配置表。每个业务场景对应一张映射表定义AI字段和系统字段的对应关系、格式转换规则、枚举值映射。比如{ biz_type: invoice, field_mapping: [ { ai_field: invoice_date, system_field: F_DATE, transform: to_yyyymmdd }, { ai_field: amount_with_tax, system_field: F_AMOUNT, transform: calc_without_tax } ] }这个转换层的数据结构要设计得足够灵活因为老系统接口永远有你没想到的怪癖。宁可多花一天时间做映射配置也别把转换逻辑硬编码在代码里。后面每接一个新场景只需要增加一张配置表代码一行不用改。对于完全没有接口的老系统最终兜底方案是生成导入文件。AI中台把结构化数据按老系统的导入模板生成Excel人工下载后走老系统的批量导入功能。表面上多了一步“人工导入”但相比原来逐条敲键盘效率已经提升了七八成。这个折中方案在预算有限时值得一试。3.3 对账逻辑设计从月末痛哭到每天自动出差异表对账是消减人工工作量的重头戏。我们的对账逻辑分三大块数据准备、自动匹配、差异输出。数据准备阶段每天凌晨定时任务从银行系统和ERP系统拉取前一天的流水和业务单据放进统一台账。这里的关键是清洗把银行摘要文本用大模型做标准化比如“货款- 张三”和“张三科技有限公司货款”统一成“张三科技”把金额格式去千分位、去币种符号把日期统一成标准格式。清洗这块原来想用正则写后来发现正则规则维护不过来改用大模型做语义清洗准确率显著提升。自动匹配阶段用三层规则逐层匹配第一层是强匹配金额完全相等、日期差异在3天内、业务单号完全相同这种直接判定为“已对平”。第二层是模糊匹配金额差异在可容忍范围如银行手续费导致往来源名称做相似度匹配相似度大于85%且金额一致则标记为“待人工确认”。第三层是智能匹配完全没有单号大模型根据业务描述判断是否为同一笔交易并给出理由但绝不自动核销只建议。差异输出阶段每天生成一张差异表按“金额不一致”“日期异常”“缺少匹配项”分门别类。财务人员早上打开看板只需要处理机器三个“拿不准”的单子其余几千条流水已经自动对平了。这个对账跑批的设计有几个容易踩坑的地方一是银行流水和ERP数据的时间戳时区要保持一致否则“当天”数据会出现偏差二是数据量大时匹配要有索引别全表扫描三是匹配算法必须做成可追溯的某笔账为什么被判为“已对平”要有日志可查。做到这三点财务才会真正信任这个系统。3.4 提示词工程的落地坑让大模型按JSON字段输出大模型抽取单据听起来很美好真做起来最大的坑是“输出格式不稳定”。你问大模型“识别这张发票的开票日期、金额、购买方”它可能给你一段漂亮的文字描述而不是字段化的JSON或者JSON字段名每次都不一样导致下游没法处理。解决方案很简单强制JSON schema输出配合零温度和少量示例。我们为每个业务场景写固定的提示词模板模板里先给一段角色设定再给一个“必须遵守的字段定义”最后给一个输出示例。温度参数设为0让输出尽量确定。这里我截取一段发票抽取的提示词核心部分请你从以下OCR识别出的文本中抽取指定字段严格按JSON格式输出不要输出任何解释文字。 字段定义 - invoice_no: 发票号码字符串 - invoice_date: 开票日期格式YYYY-MM-DD - seller_name: 销售方名称 - buyer_name: 购买方名称 - amount_without_tax: 不含税金额数字 - amount_with_tax: 含税金额数字 - tax_rate: 税率数字 OCR文本 {ocr_text} 输出示例 {invoice_no: 12345678, invoice_date: 2025-01-01, ...}有了这个结构大模型的输出基本稳定字段名不会乱跑。但要注意即使有了schema约束偶发情况还是有——比如JSON里混入注释文字、数字带了单位、日期格式错乱。所以我在网关里加了一层后校验每个字段定义正则表达式约束校验不过的整条数据降级为低置信转人工处理。规则是机器的兜底机器是人的增效这个理念贯穿始终。4. 实操部署要点从一台空机器到跑通首个场景4.1 硬件与系统准备先说硬件底线。我们实际用的是一台普通服务器8核CPU、32G内存没有独立GPU后面才上了一张12G显存的消费级显卡。如果你只是想跑通流程做验证那8核16G的机器就够了如果要应对日常生产建议至少32G内存有条件的加一张12G以上显存的GPU大模型并发能力会强很多。对于纯CPU跑7B量化模型单次抽取响应大概在10到20秒之间能接受但谈不上流畅。这里给个建议先搞清楚你的业务负载上限。比如每天500张单据分摊到8小时工作制每分钟最多处理两单纯CPU也够了。但如果月底集中爆发就得考虑GPU或者提前做好任务队列削峰。我们当时就踩过这坑月底最后三天业务量翻倍CPU排队长达两小时后来把预处理从模型调用中拆出来并加了Redis队列才算平稳。操作系统方面生产环境强烈建议Linux。我用的是Ubuntu 22.04 LTS社区资料多、兼容性好。Windows也可以做开发测试但容器化和服务稳定性在Linux下更让人放心。社区里经常有人问Windows怎么部署Docker我只能说能跑但别拿去当生产环境。装好系统后直接装Docker Engine和Docker Compose插件。# Ubuntu 安装Docker curl -fsSL https://get.docker.com | sh systemctl enable --now docker docker compose version这三个命令执行完容器环境就算搭好了。整个过程不超过十分钟别把基础环境想复杂了。4.2 模型下载与本地推理服务模型服务这块我们用Ollama做推理框架因为它的部署方式太省心了。拉模型、起服务、跑推理基本就是几个命令的事而且自带OpenAI兼容接口其他服务对接很容易。# 拉取量化后的7B模型 ollama pull qwen2.5:7b-instruct-q4_K_M # 测试一下是否可用 ollama run qwen2.5:7b-instruct-q4_K_M 你好做一个自我介绍 # 后台起服务 ollama serve容器化部署时官方镜像会自动启动推理服务。需要注意一个参数OLLAMA_NUM_PARALLEL。这是并发工作数默认可能只有1意味着同时只能处理一个请求。我们调到了4配合12G显存体验好了不少。如果你在容器外跑记得这个环境变量要传给容器。OCR服务直接用PaddleOCR官方镜像。这里分享一个细节第一次启动时镜像会初始化模型时间较长如果你在内网环境没有外网需要提前把模型文件下载好挂载进容器指定模型目录路径。我们实际生产环境就是纯内网所有镜像和模型都是提前准备好离线导入的。启动OCR服务的命令大致如下docker run -d --name paddleocr \ -v $(pwd)/models:/paddle/models \ -v $(pwd)/data:/paddle/data \ -p 5000:5000 \ paddlepaddle/paddleocr:latestOCR服务启动后可以先用一张测试发票调用一下识别接口确认输出文本块的基本质量。这里有个经验直接调用底层OCR接口返回的是带坐标的文本块虽然信息全但格式复杂。我们的网关代码里做了封装只提取纯文本内容传给大模型这样大模型的输入干净抽取准确率也更高。4.3 网关与业务接入网关是整个中台的门面业务方只跟它打交道。我们用的是FastAPI主要因为异步性能和自动生成的接口文档易于调试。网关暴露两个核心接口一个是抽取接口输入单据文件输出结构化字段另一个是确认回写接口业务方审核通过后调用它把数据写入目标系统。抽取接口的大致逻辑是from fastapi import FastAPI, UploadFile import httpx app FastAPI() app.post(/extract) async def extract(file: UploadFile, biz_type: str): # 1. 调用OCR服务获取文本 ocr_text await call_ocr(file.file.read()) # 2. 组装提示词调用LLM服务 prompt build_prompt(biz_type, ocr_text) llm_result await call_llm(prompt) # 3. 解析并校验JSON字段 parsed parse_and_validate(llm_result) # 4. 根据置信度决定直接入库还是转人工 if parsed.confidence 0.95: await write_to_ledger(parsed) return {status: auto_passed, data: parsed} else: await queue_for_review(parsed) return {status: review_needed, data: parsed}实际代码会比这个复杂比如要处理大文件上传、OCR超时重试、并发控制等等但整体骨架就是这样。接口鉴权我们用的最简单方式每个业务系统分配一个API Key放在请求头里。内网环境下这种级别够用没必要上OAuth2那套复杂的。业务系统接入时如果对方有技术团队把API文档甩给它们联调一天能完成。如果对方是外包维护的老系统没有开发资源那就走“生成导入模板”的兜底方案让业务人员用Excel文件完成数据流转。4.4 上线验证与性能摸底新系统上线最怕的是“自我感觉良好”。所以我们在正式切换前跑了一周“影子模式”机器一边跑人工照常做原来的录入动作事后对比两边结果。这周的主要目的是收集真实的准确率数据而不是听我们吹效果。我们拿200张历史发票先做了离线测试统计三类指标字段识别准确率、完全不需要人工干预的比例、单张处理耗时。结果很说明问题比如发票号码和金额的准确率能到99%以上但“购买方名称”偶尔会被OCR识别错导致大模型跟着错这块准确率只有92%左右。有了这个数据我们在提示词里加强了对购买方名称的上下文校验又增加了一个专用的校对规则上线前把准确率拉到了97%。影子模式跑完还有一个更重要的指标业务方工作量下降了多少。我们统计了同一批单据在人工录入和AI中台处理两种模式下的平均耗时AI中台人工复核模式比纯人工录入平均节省60%的时间而且月底对账时间从两天缩短到半天。有了这些数字做底业务部门开会讨论时就不会有人再质疑“AI是不是帮倒忙”了。还有一个隐蔽但重要的点系统上线不等于项目结束。我们设计了一个“每周质量报告”自动统计本周有多少单据走了自动回写、多少走了人工复核、人工复核里被修改的字段占比是多少。这些数据既是对系统的监控也是持续优化提示词和规则的依据。AI中台跑得越久规则积累越多效果只会越来越好。5. 常见问题与排查技巧把这些坑提前告诉你5.1 模型响应慢、并发低这是每个第一次部署本地大模型的人都会遇到的问题。现象是单条请求响应十几秒并发一高就排队而且越排越久。排查思路分三步走第一步看资源。用docker stats看到底是CPU跑满了还是内存不够导致频繁swap。如果是前者说明模型推理本身吃紧如果是后者加内存或者换更小的量化模型。第二步看并发配置。Ollama默认的并发数很低你可以在启动时加OLLAMA_NUM_PARALLEL4环境变量也可以设置OLLAMA_MAX_LOADED_MODELS控制同时加载几个模型。前者对频繁调用很重要别用默认值。第三步看调用模式。如果业务调用是突发的比如月底集中处理那一定要在接入层加Redis队列做削峰。请求先进队列后台Worker池按固定速率消费避免瞬时请求把模型服务打死。我们后来就是这样处理的体验顺滑很多。5.2 同一张单据识别结果不稳定有段时间业务反馈同一张发票上午和下午识别出的结果不一样字段值偶尔会变。这个问题的根子在于大模型生成带有随机性虽然温度设为0但某些推理框架在并发时行为不完全确定。处理方案有三招第一把temperature参数明确设为0有些框架默认值不是0一定要显式传入第二为每个业务场景做few-shot示例示例要足够贴近真实单据第三在网关加“二次校验”逻辑对金额、单号这种关键字段让大模型跟着校验规则走而不仅仅是信任第一次输出。更彻底的办法是对关键单据做两次独立抽取两次结果一致才判定为高置信。代价是耗时翻倍所以只适用于重要单据场景。我们后来只对金额超过阈值的单据启用双抽其他单据不做在成本和准确性之间找平衡。5.3 业务方反馈“没有减少工作量”这是心态上很容易崩的时刻。你会觉得系统明明很好为什么业务方不认。后来我理解了如果业务方还在逐条核对你自动生成的所有单据那他们和之前手动录入相比只是把键盘打字换成了鼠标检查工作量并没有本质变化。应对这个问题的方法不是解释技术多厉害而是改变流程设置一条“不看不审”的默认通道。对高置信度单据直接自动回写业务方不需要逐条确认而是通过日报查看结果。业务方真正要处理的只有中低置信度单据。同时管理层要把“AI自动通过率”和“人工复核量”作为核心KPI考核的是业务方对机器的信任度是否足够而不是机器的技术指标。这里的经验总结起来就是自动化系统要提效革的不只是重复劳动的动作还有业务方的工作习惯。习惯的改变需要制度和数据共同推动光靠一个系统是推不动的。5.4 内网部署环境与证书自动续期很多企业内部网络是物理隔离的模型和镜像都只能靠离线包搬运。我们的做法是找一个有外网的开发机把需要的东西全部打包成镜像文件——Docker镜像用docker save导出模型文件直接拷贝然后在内网服务器上docker load导入。这个过程比较笨但可靠。另外一个容易被忽略的点是HTTPS证书。内部系统部署很多人直接用HTTP但浏览器会警告、而且流量明文走内网也不规范。我们用的是自签CA证书在内网员工电脑上安装根证书实现信任同时部署了Nginx作为TLS终结层所有的API调用走HTTPS加密。证书有效期一般只有一年手写命令续期容易忘所以我们做了个定时任务每月自动检测并执行续期脚本再用cron挂起来。这个习惯告诉你不管内部系统多小TLS加密和证书自动化都值得做别到浏览器整天弹警告时才想起来。这里要提醒一句内网证书的信任策略会因公司而异生成证书前最好先跟运维确认内部CA的规范。先有规范再谈自动化否则脚本写好了也白搭。5.5 长尾单证类型如何扩展系统上线后业务方会觉得“既然发票都能自动弄那合同、报销单、出入库单能不能也一起弄”这是好事但也容易把系统搞乱。我们的做法是不让每种新单据都改代码而是把“单证类型”设计成配置项。每个新类型只要在配置中心定义四样东西OCR预处理参数、提示词模板、字段校验规则、回写映射表。新类型上线本质上是配置一条数据不需要重启服务。配置结构大致长这样{ biz_type: expense_report, ocr: {layout: table, pages: multi}, prompt_template: expense_report_extract_v1, fields: [...], mapping: {...} }这个设计的好处是业务方自己也能参与配置维护不必每次需求都排开发工期。当然提示词模板的质量仍然要由懂技术的人把关否则配置得越灵活扯淡的错误就越多。系统扩展必须建立在“基础骨架稳定”的前提下配置化是一把双刃剑。最后再分享一点我的实际体会项目收尾的时候我复盘了一下发现最值得骄傲的其实不是用了多大的模型、多新的框架而是把一个具体到不能再具体的业务痛点用一套足够轻、足够务实的方案解决了。很多人搞AI中台上来就问“该选哪个模型”但真正决定项目成败的往往是需求界定、流程重构、数据规范这些看起来不性感的东西。我个人的体会是大模型在这套系统里的角色更像一个聪明但缺乏纪律的员工你需要给他明确的岗位说明提示词、工作模板JSON Schema和上级复核机制置信度分级。只有把这三样配齐它才能真正成为团队的一员。而规则引擎和人工兜底永远是大模型安全感的重要来源。最后再分享一个小技巧如果你准备在团队里推这套东西先不要急着给所有人画“全自动”的大饼而是选定一条最痛的业务线比如月底对账先用两周时间跑出一个让财务愿意在例会上主动夸的结果后面的推广会顺利得多。这个项目的扩展方向也多得很从账单、合同到库房条码只要把“抽取—映射—核验—回写”这个链路做稳什么单据进来都能接得住。