1设备系统与业务系统各自为政
产线有产线的数据，业务有业务的系统，中间靠人工抄录、Excel 传递，又慢又错。
物联版把设备数据直接连接到 Odoo 流程：扫码过站、传感器上报、测试结果，自动变成工单、质检单和维修单。
客户价值
它解决四类关键问题
这四类问题，几乎出现在每一家准备数字化的企业里。数字化底座的每一档，都是冲着其中一类或几类去的。
2数据很多，但没有转化为行动
大屏很漂亮，但异常还是靠人盯。更常见的情况是：现场一直在产生数据，数据却停在设备里、停在表格里，走不到该做决策的人手上。
规则引擎把「看见」变成「行动」：温度超限自动建维修单，库存告罄自动触发采购建议，异常走向闭环处理。这段从现场到经营的距离，就是数字化底座要缩短的那一段。
3访问变慢，复杂计算拖累业务
人一多系统就卡，排程一跑全公司等，接入压力和计算压力挤在同一台业务系统上。
网关版把「人」的访问挡在前面做加速；Rust 插件把重计算摘出来单独加速。访问归访问、计算归计算。
4多个项目重复建设、难以升级
每个项目都从零搭一套，越搭越重，交付经验无法沉淀，维护成本逐年上升。
数字化底座以配置和插件适配客户差异，便于复制、维护与扩展；客户从低档起步，高档平滑升级，投入不浪费。
也直说不适合的情况：如果现有系统整体可用、只是个别环节别扭；或是超大型集团的多层级合并报表；又或者选型硬性要求厂商背书与全国服务网点兜底——这些情况下我们会建议别换 Odoo。看完整的诚实边界 →
产品体系
四档产品体系：按需起步，平滑升级
按「人多不多、有没有设备、有没有重计算」三个问题划分四档。档位之间是递进关系：高档包含低档的全部能力，升级不断档、投入不浪费。
Go 网关
接住所有人访问的入口
Go IoT
让设备把数据送进系统的转接头
Rust 插件
把算得慢的那一步，换成更快的算法
profiler
先量一量哪里真的慢
TIER 01第一档
标准版
Odoo
- 解决
- 业务流程分散在多套系统和表格中，数据对不上、流程靠人盯
- 适合
- 人不多、无设备接入、无重计算需求的企业
起点档 · 地基
TIER 02第二档
网关版
Go 网关 + Odoo
- 解决
- 并发上来后系统越用越慢：报表打不开、高峰期卡顿
- 适合
- 人多、系统访问压力大的企业
+ 人的流量入口
TIER 03第三档
物联版
Go 网关 + Go IoT + Odoo
- 解决
- 设备数据与业务脱节，靠人工抄录、跨系统传递，又慢又错
- 适合
- 有产线、传感器或现场设备的企业
+ 设备的流量入口
OPTION跨档选配
行业加速
Rust 行业插件
- 解决
- 复杂计算拖慢业务，算力成为瓶颈
- 适合
- 有生产排程、路径优化、批量计算需求的企业
可挂在任意一档上
分工铁律：Go 网关是「人」的流量入口；Go IoT 模块是「设备」的流量入口；Rust 行业插件跨档选配，可挂在任意一档上。四条链路边界清晰，各自独立扩缩容，互不绑架。
行业覆盖
19 个行业，各有推荐起步档
蓝色为第一 / 第二档起步，青色为第二档起步，紫色为第三档（物联版）起步。Rust 插件一律按 profiler 结果确认后再叠加。
交付方式与信任
四个阶段，每一步都留下可验收的东西
无论从哪一档起步，实施路径都是同一套，只是每一步的工作量随档位增减。完整的七步流程、服务保障与响应口径在服务与交付页。
第 1 步
需求调研与方案设计
摸清流程、痛点与目标，用「三问定档」确定起点档位；产出系统方案与集成方案，档位组成、边界与交付物双方确认后才开工。
第 2 步
部署集成与设备接入
环境部署，Go 网关、Go IoT 模块、Rust 插件按档位按需安装；第三档项目再做设备注册、认证配置与现场联调。
第 3 步
流程配置与培训上线
单据流程、权限体系、规则引擎按企业实际运作配置到位，再分角色做操作培训，试运行验证通过后正式切换。
第 4 步
持续运维与问题响应
日常运维、版本升级与问题响应按约定口径执行，处理过程与结论留痕；合同之外的工作先说明再动手。
信任从哪里来：业务核心是开源平台，代码与数据在客户自己手里——可自行运维、可更换实施方与开发方、可自己招人接手，换服务商不等于换系统。设备接入提供项目级、设备级与 mTLS 三档认证，关键操作全程留痕。
交付场景
交付过什么：几类企业的共同点
按「行业 · 组织范围 · 起点档 · 要解决的具体问题」来说明我们实际在做什么。按约定不披露客户名称与经营数据，所以这里只给结构性事实。
汽车零部件 · 多工序报工
报工原本靠班组第二天补录，进度表永远滞后一天，齐套要等人工核对完才敢排产。扫码过站接进流程后，报工与工序记录在事件发生的当下就落库，序列号和工序的追溯链也一起补齐。
物流运输 · 在途与回单
调度靠电话和微信确认车在哪，运费要等回单齐了才能结，月底和承运商对不上账。车辆定位与回单凭证接入后，在途状态和结算单挂在同一条记录上，缺单与异常能提前发现，不用等到结算环节才被动暴露。
单厂设备维护 · 告警闭环
该保养、该维修靠人定期想起来，告警停在监控屏上没人接手，处理完也没有记录。规则命中后自动生成维修单并派工，处理结果回到同一条设备记录里，逾期未处理会被顶上来。
常见问题
关于选型、集成与数据
一定要从第一档开始吗？
不一定，按「三问定档」定起点：有现场设备的行业直接从第三档（物联版）起步，人多、访问压力大的行业从第二档（网关版）起步。起点由业务现状决定，不由销售决定。
能不能对接我们现有的 ERP、MES、WMS 或财务软件？
常见的做法是通过标准接口对接，把对方系统里已有的数据同步进来，避免重复录入。对接范围要等调研时确认对方的系统、版本和开放接口之后才能评估清楚。如果对方系统不开放接口，我们会把限制先讲明，再一起看有没有替代路径。
数据能不能导出？以后不合作了怎么办？
数据在你们自己的系统里，可以按需导出成通用格式，也可以做完整备份。业务流程与规则以配置和文档的形式交付，系统不依赖我们才能运行。以后如果更换服务方，接手的是一套正常运行中的系统和一份完整的配置与文档，不需要推倒重来。
有没有做过跟我们同类的项目？
我们做的行业集中在制造、物流、设备与零售这几类，19 个行业方案里都给出了对应的推荐起步档。您的行业和现场情况我们大概率已经见过类似的做法，具体到细节会在调研时直接问清楚，不含糊。
上线要多久？
取决于起点档位、需要接入的设备数量、流程改造的范围以及要对接的系统数量，没有一个通用答案。调研之后我们会给出排期计划，把每个阶段的工作内容和前置条件写清楚。宁可把不确定性提前讲明，也不在中途加价。
上线之后维护找谁、响应怎么算？
上线之后由我们继续提供日常运维、版本升级和问题响应，响应级别与服务时段在合同里明确约定。如果确实需要合同之外的工作，我们会先说明再动手，不做临时加价。
数据安全怎么保障？
设备接入提供三档认证：项目级（试用显式开启）、设备级（生产默认）、mTLS（高安全场景）；人员账号与权限沿用 Odoo 原生体系。关键操作全程留痕，可追溯。数据的导出方式与备份安排可以按你们的要求来。
会不会被 Odoo 官方绑定？
不会。Odoo 社区版是开源的，代码可以自己审计、部署和维护，不按用户数收授权费。后续升级、换实施方、换开发方都可以做，接手的人能凭代码和文档继续做下去。
Go 网关会不会把业务逻辑从 Odoo 拿走？
不会。网关只做「接得住、回得快」——高并发接入、访问加速、热点缓存，不碰业务。所有业务规则、单据逻辑、权限体系仍在 Odoo，它是唯一的事实来源。
什么时候才需要 Rust 行业插件？
只有性能分析（profiler）证明存在 CPU 计算热点后才引入对应插件。排程、路径优化、批量计算属于典型场景。插件跨档选配，例如纯 Odoo 的工厂 MRP 跑不动，可以只加一个排程插件，不必上全套底座。
私有化部署和托管 SaaS 怎么选？
同一套底座两种形态都能跑：私有化部署放在你们自己的环境里，数据边界自主可控；托管 SaaS 由我们统一托管、升级和维护。选哪种主要看数据主权要求、要对接的内网系统有多少，以及你们愿意投入多少运维精力。
以后业务增长了，升级会不会推倒重来？
不会。档位之间是递进关系：高档包含低档的全部能力。升级动作是「加」，不是「换」——加网关、加 IoT 模块、加插件，每一步都是增量投入，已有投入不浪费。