交付场景
四个交付场景,用工程师的讲法
以下是根据我们的业务类型与客户所处市场整理的示例性复合案例,不指向具名客户——这样才能在不违反保密义务的前提下,把真实的数字与架构取舍摆出来。
◇ 示例性复合案例 · 非具名客户 · 精密制造 · 280 人 · 16 周
精密制造:从十二张表格,到一个生产真相
两个工厂,一个在新加坡,一个在柔佛。订单、物料与在制品跑在一套 2011 年的本地 ERP 上,外加十二张只有三个人看得懂的表格。月结要十一个工作日,在制品数据传到决策者手上时已过期三天。
11 → 2月结所需工作日
71% → 94%交期承诺准确率
+18%十二个月后的库存周转
真正的问题
- 同一料号在四套系统里主数据不一致。
- 车间进度用纸单上报,第二天才录入。
- 直接换掉旧 ERP 意味着停产数周。
我们建了什么
- 主数据服务,过渡期向旧 ERP 双写。
- 工位扫码报工,单次不到四秒。
- 实时在制品看板与月结自动对账。
真正改变了什么
- 财务从对账转向分析。
- 销售按实时产能报交期。
- 旧 ERP 第九个月下线,零停产。
ReactNode.jsPostgreSQLRedisMQTTDockerAWSGrafana
◇ 示例性复合案例 · 非具名客户 · 持牌资管 · 约 US$180M · 20 周
持牌资产管理:让一次检查变成周二下午的事,而不是两周的事
一家香港持牌资管机构,KYC、投资审批与投后跟踪散落在邮件、共享盘和一位非常勇敢的运营经理身上。准备一次监管检查,要从收件箱里人工还原三年的决策过程。
9 → 3完成一轮客户尽调所需天数
100%带防篡改审计留痕的审批比例
数天 → 分钟为检查取证所需时间
真正的问题
- 两年后要证明「谁依据什么批准了什么」。
- 个人数据以未加密附件散落在多个邮箱。
- 现成合规平台按跨国银行定价。
我们建了什么
- 双人复核与只追加日志的流程平台。
- OCR 与大模型抽取,入库前人工确认。
- 一键导出任意持仓的决策时间线。
真正改变了什么
- 尽调不再是接收新资金的瓶颈。
- 运营经理不再是单点故障。
- 合规从「口头声称」变成「现场演示」。
Next.jsFastAPIPostgreSQLS3 + KMSOCRLLM extractionPDPO
◇ 示例性复合案例 · 非具名客户 · 跨境零售 · 6 渠道 3 市场 · 10 周
跨境零售:六个渠道,六种真相,一本字典
一家零售集团在新加坡、马来西亚与香港通过六个渠道销售,每个渠道对「一笔销售」的定义都不同。月度复盘要四个人拼三天表,会上一半时间在争论谁的数字才对。
6 → 1统一到同一口径的数据源
12 → 0.5准备月度复盘所需人日
提前 5 天缺货预警较原流程提前
真正的问题
- 这是披着看板外衣的口径问题。
- 退货、撤单与压货被加在一起。
- 三种货币、三套税务每月手工调平。
我们建了什么
- 按小时抽取的 ELT 管道,原始层可重放。
- 在数仓层强制执行的指标字典。
- 缺货预测直接推送给采购。
真正改变了什么
- 月度复盘从对账会变成决策会。
- 采购转向计划性补货。
- 最受重视的交付物是那本指标字典。
ELTPostgreSQLClickHousedbt-style modellingMetabaseAirflow
◇ 示例性复合案例 · 非具名客户 · 企业服务 · 每月 2,000+ 份文件 · 12 周
企业服务机构:让 AI 可以出错,但出错不要紧
一家新加坡企业服务机构,每月把两千多份 PDF 上的同一批字段录入三套系统。错误不多,但总是发现得太晚——通常是被监管机构或客户发现的。
22 → 4单份文件的处理分钟数
+31 pp一次性提交通过率提升
100%带留痕理由的自动化决策比例
真正的问题
- 同一批数据要录三遍。
- 直接用大模型抽取:诱人但危险。
- 必须回答「系统为什么这么判」。
我们建了什么
- 分类 → 抽取 → 规则校验 → 低置信转人工 → 回写。
- 每个字段带置信度与原文坐标。
- 400 份标注文件的评测集作上线门禁。
真正改变了什么
- 员工从录入转向异常处理。
- 错误在接收环节就被抓住。
- 交付周期可预测到能写进 SLA。
PythonFastAPILLM extractionRule engineHuman-in-the-loopEval harness