P-01PAIN POINT
“票面自由度高”
票据多由不同业务员手写，字体、力度、倾斜度差异大；存在跨行书写、涂改划线、覆盖签字等情况，传统 OCR 模型经常一错全错。
字段级识别准确率
96.1%
复杂手写票面 · 抽样 1,200 张
单页平均处理时长
1.8s
端到端 · P95 ≤ 3.0s
人工复核工作量
-82%
上线前 vs. 上线后 · 同口径
已稳定生产运行
11 个月
覆盖 6 类业务订单 / 3 个客户
/ 01The Problem
客户面对的真实问题
客户是一家覆盖华南三省的快消品分销商，每天从近 800 家终端门店手工接单，再由后台录单员录入 ERP 进行发货与对账。订单几乎全部为手写，且票面状态远比示例图复杂。
P-02PAIN POINT
字段语义模糊
数量与单价、备注与品名常常混排；缩写如 "红牛 6 听"、"老干妈辣 ×3" 需要结合行业语义才能正确归一化为标准 SKU。
P-03PAIN POINT
人工录入成为瓶颈
客户每天有 1,200~1,800 张手写订单需要在 30 分钟内完成入库，2 名录单员持续加班，仍然存在 0.7% 左右的误录漏录率。
P-04PAIN POINT
误差直接造成账款风险
数量、单价或客户名称一旦录错，会同步影响发货、对账、月度结算，误差不止于“麻烦”，而是真金白银的资损。
/ 02Live Sample
一张订单走完整条流水线
下面这张是客户真实场景中的一张手写订货单（已脱敏）。我们把原图、识别结果叠加图、以及最终落库的结构化 JSON 同屏展示，让客户对“AI 究竟做了什么”建立一手认知。
INPUT客户原始手写票面
jpg · 1408×1056
OUTPUT识别结果
票面褶皱100%
纸张折痕导致字段错位，模型仍正确归位 12/12 行。
跨行涂改97%
原价被划掉、上方手写新价格，识别结果取最新值并保留审计痕迹。
字段交叠94%
备注列字迹压住单价列网格，由结构化后处理还原列归属。
/ 03How We Think
不是赌某一种 AI，而是组合最合适的几种
面对一个真实业务场景，我们不会一上来就选定某条技术路线。在与客户对齐目标之后，我们对三条候选路径都做了同口径的样本评估，再据此设计融合方案，让每条路径都做它最擅长的那部分。
APath
云厂商通用 OCR API
腾讯云 / 阿里云 / 百度智能云
- 开箱即用，接入成本极低
- 印刷体、规则表格识别已经非常成熟
- 按调用计费，业务初期成本可控
- 对随性手写体、连笔字泛化能力有限
- 无法理解客户特有的商品语义（如缩写、行业黑话）
- 字段结构需要业务侧自行还原
- 印刷体准确率
- 98%+
- 本场景手写准确率
- 68.4%
- 字段结构化
- 需自建
我们的判断 · 适合作为兜底通道与冷启动基线
BPath
多模态大模型直读
GPT-4o / Qwen-VL / 通义千问 VL
- 对自然语言上下文理解强，能处理涂改、跨行等复杂情况
- 可以一步输出结构化 JSON，工程链路更短
- 对行业语义有较好的常识泛化
- 单张推理成本与延迟显著高于专用模型
- 字段级准确率波动较大，关键数字偶发幻觉
- 私有化部署门槛高，数据合规需要单独设计
- 本场景手写准确率
- 88.7%
- 单张端到端延迟
- 4.2s
- 千张推理成本
- ≈ ¥48
我们的判断 · 适合处理疑难票面与语义二次校正
CPath
自研专用 OCR
滚水科技 · GS-OCR-Hand v2
- 针对客户真实样本微调，对手写体识别表现稳定
- 字段检测 + 识别两阶段架构，可控、可解释
- 推理成本与延迟均有显著优势
- 训练与维护需要持续的数据闭环投入
- 对从未见过的票样仍需要少量人工标注做迁移
- 缺乏跨字段的“语义判断”能力
- 本场景手写准确率
- 93.2%
- 单张端到端延迟
- 0.9s
- 千张推理成本
- ≈ ¥6
我们的判断 · 作为主链路承担 90% 以上日常流量
Final Decision
融合而不是选择
我们最终交付的不是某一个模型，而是一条 “自研 OCR 主链路 + 多模态语义校正 + 云厂商兜底” 的融合管线： 超过 90% 的日常票面由自研模型在 1 秒内完成识别；置信度低于阈值的字段会走多模态大模型做二次理解； 当样本质量极差或服务异常时，会自动降级到云厂商 OCR 并标记人工复核。
这种结构让"准确率、成本、延迟、可控性"这四个互相牵扯的目标得以同时达成，也是我们在每一个 AI 项目里都会强调的工程哲学：用工程把模型的不确定性收敛为业务的确定性。
/ 04How It Works
一条可解释、可降级、可演进的 AI 管线
我们坚持把 AI 工程当作“管线”而不是“黑盒”：每一步都有明确职责、明确输入输出、明确兜底策略。下面这五步管线 + 四层系统架构，是这套手写订单 OCR 方案的全部技术骨架。
- STEP / 011
采集与版式归一
通过移动端 / 扫码枪 / 飞书表单等多通道采集，统一做去畸变、白平衡、阴影抑制与版式校正，把“图像质量”这一变量先排除掉。
DocAlignDeskewShadow Removal - STEP / 022
字段检测（DET）
使用基于 DBNet++ 的字段检测器，先识别整张票的逻辑结构（表头、行、列），再为每一个手写笔画绑定语义角色（品名/数量/单价/备注）。
DBNet++Layout-awareRoI Routing - STEP / 033
字符识别（REC）
字符识别由自研 GS-OCR-Hand v2 担纲，针对客户的 4.6 万张真实样本做了领域微调；置信度低于 0.85 的字段会自动转入下一步语义复核。
CRNN + AttentionDomain Fine-tuneConfidence Routing - STEP / 044
多模态语义校正（LLM）
对于涂改、跨行、上下文依赖强的字段，调用多模态大模型，结合该客户的 SKU 词典与历史订单上下文做“读懂”层面的二次校正。
VLMRAG · SKU DictSelf-Consistency - STEP / 055
结构化后处理与规则校验
把识别结果按业务规则做归一化：单位换算、价格区间校验、客户实体匹配、合计金额闭环校验，最终输出可直接入 ERP 的结构化记录。
Rule EngineEntity ResolveAudit Log
系统架构 · 分层视图
v2.1 · 2026.04L1 · Access
采集与接入层
支持 5 种业务通道接入，统一做幂等、限流与脱敏。
Channel
移动端 App
Channel
扫码枪 · Webhook
Channel
飞书表单同步
Gateway
API Gateway · JWT
L2 · Inference
AI 推理层
三条推理链路 + 路由器，按置信度与样本特征自动切换。
Primary
GS-OCR-Hand v2
Semantic
Qwen-VL · LLM
Fallback
Tencent OCR
Router
Confidence-aware Router
L3 · Business
业务编排与规则层
把识别结果对接到 ERP / 对账 / 复核工单的真实业务流。
Engine
字段归一与单位换算
Match
客户 / SKU 实体解析
Audit
金额闭环校验
Workflow
人工复核工单流
L4 · Data Loop
数据闭环层
线上每一次识别都会反哺到训练数据集，让模型每月自动迭代。
Storage
样本仓 · COS + Postgres
Label
在线标注与差错回收
Train
月度增量微调
Monitor
漂移监测与告警
/ 05How We Deliver
十周交付，并不是一次性结束
我们把每一个 AI 方案都做成"可被验收 + 可被迭代"的项目：交付前是十周的工程化落地，交付后是持续的数据闭环。下面是这次手写订单识别项目的真实时间线。
- Week 0Milestone · 01
场景诊断
和客户业务侧、IT 侧一起把订单流走一遍，明确“哪一步要替换、哪一步要保留”。
业务流程现状图数据/合规约束清单成功指标定义书 - Week 1–2Milestone · 02
数据冷启动
采集 4,600 张真实票面，构建首版训练集与评测集，统一标注规范。
标注规范 v1评测集（1,200 张）首版基线指标 - Week 3–4Milestone · 03
三路径并行评测
在同一评测集上跑通云厂商 / 多模态 / 自研三条路径，输出选型报告。
三路径技术评测报告成本-延迟-准确率象限图 - Week 5–7Milestone · 04
融合方案研发
构建置信度路由 + 多模态校正 + 兜底降级的完整管线，并完成压力测试。
GS-OCR-Hand v2 微调权重推理服务 v1.0压力测试报告 - Week 8–9Milestone · 05
灰度试运行
在客户 1 个仓库灰度运行两周，每张票面同时双跑（AI + 人工）做对账。
双跑对账日报工单复核界面 v1 - Week 10Milestone · 06
全量上线
推全到 6 个仓库 / 800 家终端，关键指标达成预设 KPI 后正式签收。
上线运行手册应急回滚预案 - 持续Milestone · 07
数据闭环与月度迭代
线上误差自动回流到样本仓，每月触发一次增量微调，模型能力随业务一起长。
月度增量样本集月度模型评测纪要
/ 06The Result
把不确定的“识别”换成可计量的“收益”
我们不喜欢用“显著提升”这种含糊词。下面是上线前后同口径、同样本下的关键指标对比，以及客户原话——这些是衡量这个 AI 方案是否真正解决问题的最直接证据。
指标
上线前
上线后
变化
字段级识别准确率
BEFORE68.4%
AFTER96.1%
+27.7pp
单页平均处理时长
BEFORE约 90s（人工）
AFTER1.8s
-98%
每日峰值处理能力
BEFORE≈ 1,800 张
AFTER≈ 12,000 张
×6.7
录入误差导致的对账差异
BEFORE0.7%
AFTER0.04%
-94%
单张端到端成本
BEFORE¥0.42（人工时薪）
AFTER¥0.06
-85%
人工复核投入
BEFORE2 名全职录单员
AFTER0.4 人 · 仅复核
-82%
“过去我们最怕的就是月底对账，因为录单员稍微看花眼一行，整张单的数字都会错。滚水科技这套 OCR 方案上线之后，我们 6 个仓库的订单基本上是“扫一下、几秒钟、自动入 ERP”，月底对账差异从 0.7% 掉到了万分之四。更重要的是，它没有让我们把数据交给某个外部黑盒——所有模型权重和数据都在我们自己的私有云里。
李李先生 · 客户方 IT 总监 · 华南某快消分销集团
Sign-Off
项目签收里程碑
- UAT 通过2025.06.20
- 全量上线2025.06.27
- 首次月度评审2025.07.31
- 年度续约2026.05.08
/ 07Where It Fits
同一套方案，可以解决类似的一类问题
这套“自研 OCR + 多模态校正 + 兜底降级”的工程范式，并不局限于手写订单。所有“票面 / 表单 / 单据”类的识别问题，都可以基于这套骨架快速迁移落地。
餐饮供应链可复用 →
酒店、连锁餐饮的手写订货单
厨师长 / 楼面写就的库存补货单，识别后直达进销存系统。
快消分销可复用 →
终端门店的纸质回单
业务员从门店带回的回单，扫一下即可同步月度销售台账。
建筑工程可复用 →
工地施工日志与签收单
户外票面常有油污、皱褶，融合方案对环境鲁棒性更好。
医药流通可复用 →
诊所、药房的处方与领用单
字段语义敏感（剂量/单位），结合 SKU 词典做严格校验。
物流末端可复用 →
派件、退货的手写运单
签字与备注混排，识别后直接回写到运单管理系统。
金融票据可复用 →
支票、回执、对账单的人工填写区
高合规要求场景下提供本地部署 + 全链路审计。
/ 08About Us
为什么是滚水科技
我们是一家以"软件定制 + AI 工程化"为主业的团队。过去三年里，我们把超过 20 个 AI 场景从"看上去能做"推到"能在生产环境稳定运行 12 个月以上"——这背后不是某种单一技术，而是一套被反复验证过的工程方法论。
Our Team
把 AI 落到地里去
/ 01
方法论
- 场景诊断 → 数据冷启动 → 三路径评测 → 融合方案 → 灰度 → 全量 → 闭环迭代
- 每个 AI 项目都按“工程项目”管理，配独立的 PM、里程碑与验收口径
- 拒绝“PoC 永久 demo”，所有方案都以可签收、可计量的指标交付
/ 02
技术栈
- 视觉：DBNet++ / CRNN / TrOCR / 自研 GS-OCR-Hand 系列
- 多模态：Qwen-VL / GPT-4o / Gemini-Pro Vision · 灵活路由
- 工程：FastAPI / Triton / vLLM / Postgres / Redis / K8s · 私有化部署
/ 03
工程能力
- 高并发推理服务调优（单机 100+ QPS · GPU 利用率 70%+）
- 数据闭环平台（标注 / 评测 / 漂移监测 / 自动微调）
- 全链路可观测：业务指标、模型指标、成本指标统一上报
Let's Talk如果你有一个还没解决的
如果你有一个还没解决的
具体场景， 我们一起看看 AI 是不是合适的解法。
先聊一次方案对齐，不收费、不绑定。我们会和你一起把场景拆开，判断这个问题是否值得用 AI 来做、用哪一种 AI 做最划算，并在 5 个工作日内给你一份可落地的初步方案与报价。
公司地址
深圳市龙岗区京基御景时代大厦南塔 10 层