写下我们看到的，
也写下我们判断错的

10 月 22 日，林傲网络在上海发布 Leonet DataFlow 3.0。这是该产品自 2020 年推出以来幅度最大的一次内核重构：调度层从"定时批处理 + 独立流任务"改为统一的事件驱动模型，流与批共享同一套算子与状态管理。

在实际压测中，单条链路的端到端延迟从 2.1 秒降至 800 毫秒，同等资源下的吞吐提升 2.4 倍。对制造客户而言，这意味着设备状态、工序报工与质量数据可以近乎实时地进入排产与看板，而不是等到下一个整点。

为什么这次重构值得做

过去两年，我们在项目中反复遇到同一个矛盾：业务希望"实时"，但运维希望"少一套系统"。流批分离的架构让两套逻辑各自演化，最终口径不一致、故障排查困难。3.0 的设计目标是让一套 SQL 同时覆盖实时与离线，减少一次数据搬运，就减少一次出错的机会。

我们不再追求"最快的实时"，而是追求"可解释的实时"——每一个延迟都能量化到具体的算子与网络跳数。

目前，DataFlow 3.0 已在国内某汽车零部件集团的 11 个工厂完成灰度，覆盖 3,400 余台设备与 26 条产线。灰度期间，数据链路告警数量下降 41%，运维人员从 6 人缩减到 3 人。

3.0 版本对现有客户免费升级，提供双轨并行迁移工具与 30 天回滚保障。详细的技术白皮书可通过商务渠道索取。

几乎每个来找我们聊 AI 的客户，第一个问题都是"用哪个模型"。但当我们真正进入项目，会发现模型选型往往是最不影响结果的一环。

三个更靠前的问题

• 知识是否被整理过？同一份产品手册存在 7 个版本、互相矛盾，任何模型都救不了。
• 流程是否允许人工兜底？没有复核环节的自动化，一旦出错就是事故，而不是"效果不好"。
• 谁为错误答案负责？如果业务方不认领结果，项目在上线后就会自然死亡。

我们通常建议客户先做一次"知识体检"：抽取 200 个真实问题，看现有资料能否回答，人工回答需要多久。这个动作通常只需两周，却能避免三个月的无效开发。

AI 项目的成本不在推理，而在把散落在人脑和共享盘里的经验，变成机器可检索的结构化知识。

至于模型，我们的实践是：先用中等规模模型跑通场景与评测集，确认业务价值成立后，再考虑更大的模型或微调。多数企业场景在 7B–32B 区间即可获得可接受的效果，成本却低一个数量级。

过去三年，我们参与了 46 个数据中台相关项目的建设或复盘。其中约七成，在上线一年后使用率显著下降，最终退化为"只给领导看的大屏"。

把失败原因归类后，技术因素只占 18%。其余集中在三件事上：

一、指标没有"负责人"

同一个"活跃客户数"，市场部、财务部、运营部算出三个结果。没有人为口径签字，数据团队只能做裁判，最后谁都不服。我们的做法是为每个一级指标指定唯一 Owner，并把定义写进指标中心，变更需要走评审。

二、业务方不会用，也不敢用

很多中台交付时只培训了 IT 部门。业务人员第一次打开工具，面对 300 张表无从下手。有效的做法是先做 5 个"高频、简单、能立刻行动"的看板，让业务尝到甜头，再逐步扩展。

三、没有运营角色

项目组撤场后，没人负责数据质量、没人处理新增需求、没人推动使用。我们建议客户设置"数据产品经理"岗位，哪怕只有半个人，也比零好。

数据中台不是交付一个系统，而是建立一个持续产生决策的组织习惯。

如果你正在规划数据项目，建议先回答一个问题：上线六个月后，每周一早上会有谁打开它，用它决定什么？答案越具体，项目成功率越高。

8 月底，林傲网络正式通过 CMMI（能力成熟度模型集成）5 级评估。这是软件工程领域的最高成熟度等级，要求组织在项目执行中实现量化管理与持续优化。

与很多人的印象不同，CMMI 5 级并不等于"文档更多"。评估组重点关注的是：我们是否能基于历史数据预测项目偏差，并在偏差出现前采取动作。

三个已经在用的量化实践

• 基于 800 多个历史项目估算交付工时，新项目偏差超过 15% 时自动触发复盘。
• 每周采集缺陷密度与回归通过率，低于阈值时暂停提测，先补测试。
• 把技术债按"影响面 × 修复成本"排序，每个迭代固定预留 15% 容量偿还。

对我们来说，证书的意义在于外部约束：它让"按流程做事"不再是可选项。对客户来说，这意味着项目质量不依赖于某位项目经理的个人状态。

客户是华东地区一家拥有 860 家门店的连锁零售商。改造前，门店要货流程是：店长每周一手工填报 → 区域经理汇总 → 总部商品部审核 → 仓库发货。整条链路平均 14 天，遇到节假日更长。

先解决数据，再谈算法

项目第一周，我们做了一件看起来"不够技术"的事：把 12 万条商品主数据清洗了一遍。结果发现 3,700 条商品存在重复编码，另有 1,100 条缺少最小陈列单位。这些问题不解决，任何预测模型都是在噪声上做拟合。

随后，我们把门店按商圈类型、面积、历史动销聚成 9 类，为每类建立独立的预测基线，再叠加促销、天气与节假日因子。模型本身并不复杂，但特征工程花掉了整个项目 60% 的时间。

结果与反思

• 补货决策周期从 14 天缩短到 3 天，紧急调拨减少 44%。
• 缺货率下降 31%，同时库存金额下降 9.6%——这两个指标过去被认为互相矛盾。
• 店长每周用于填报的时间从 3.5 小时降到 20 分钟。

项目上线后第三个月，客户主动提出把预测范围扩展到生鲜品类。这比任何验收报告都更能说明系统在被使用。

把一个十年历史的单体应用打成镜像，部署到 Kubernetes 上，并不能叫云原生。它只是换了一个运行环境，所有耦合、所有停机窗口、所有"改一处要全量回归"的问题都还在。

真正的改造从拆分边界开始

我们的做法是先画业务能力地图，找出变更频率差异最大的部分。比如订单与商品，订单逻辑每周都在变，商品主数据几个月才动一次——它们就应该分开部署、分开发布。

拆分不必一步到位。我们通常采用"绞杀者模式"：新功能以独立服务实现，通过网关逐步接管老系统的流量，老系统只做只读或兜底，最终自然退役。

三个容易被忽略的前置条件

• 可观测性先行：拆之前先有统一日志与链路追踪，否则故障定位会从"难"变成"不可能"。
• 数据一致性方案：跨服务事务不要指望强一致，提前设计补偿与对账。
• 组织对齐：团队边界不调整，服务边界迟早会被拉回去。

一个中型系统的改造通常需要 3–4 个迭代周期，期间新旧并行。接受"一段时间内有两套系统"，比追求"一次性切换"现实得多。

客户是一家资产规模约 3,000 亿元的城商行。改造前，反欺诈、授信准入、额度调整三类规则分散在五个系统中，由不同团队维护。每次策略调整，需要业务提需求、科技排期、测试回归，平均两周。

90 天做了什么

• 第 1–3 周：梳理 286 条存量规则，合并重复逻辑，标记失效规则 41 条。
• 第 4–7 周：搭建实时特征平台，接入 34 个数据源，特征一次定义、多场景复用。
• 第 8–11 周：上线决策引擎，支持规则与模型组合编排、灰度发布与 AB 实验。
• 第 12–13 周：并行运行，新旧结果逐笔比对，差异率降至 0.3% 以下后切换。

切换后，策略迭代周期从 14 天降至 1 天，审批时效从平均 3.5 天缩短到 4 小时。更重要的是，每一笔拒绝都可以回溯到具体的规则版本与特征取值，满足内审与监管要求。

合规部门从"最后签字的人"变成了"提前参与设计的人"，这是项目能顺利上线的主要原因。

2026 年第二季度，我们面向 120 家年营收 5 亿元以上的企业做了一次匿名调研，覆盖制造、零售、金融与公共服务四个领域。样本不大，但趋势足够清晰。

三个值得注意的变化

第一，新建系统的预算占比下降。2024 年这一比例约为 58%，2026 年降至 41%。企业不再急于采购新平台，而是先处理存量系统的数据与流程问题。

第二，数据治理预算翻倍。27% 的受访企业把"主数据与指标口径"列为年度第一优先级，高于"AI 应用"（22%）与"云迁移"（16%）。这是一个务实的变化。

第三，AI 预算更集中。虽然尝试 AI 的企业变多，但预算集中在少数 2–3 个场景，且要求 6 个月内看到可量化结果。广撒网式的试点明显减少。

对服务商的启示

当客户不再为"新技术"付费，而是为"解决具体问题"付费时，能讲清楚投入产出、愿意承担结果的服务商才会留下。我们内部也在调整：方案汇报的第一页不再是架构图，而是"这个项目预计改善哪个指标、改善多少、怎么验证"。