数据采集生产系统：从一个采集功能到规模化生产体系
补天石 · 2025–2026 · 已上线
这是个什么项目
起点是老板一句“这个月要采到 100 小时”。我们从 Research Box 采集模块抽出端到端链路，先做出 MVP。设备侧从“等自研硬件”转向 iPhone，因为采集链路与设备无关。目标推到 1000 小时、引入供应商与运营后，系统从采集工具变成平台、运营、供应商共用的生产管理系统。
系统覆盖平台管理员、平台质检员、供应商管理员、采集员和质检员。核心机制有三层：供应商自治，平台只管理供应商，供应商自行管理一线人员；批次账单连接生产事实、质量判定和结算事实，双方共享同一份事实；自动质检将五类检测设为人工质检前的硬前置，运行在 Flyte + Ray 常驻模式上。国内与马来西亚使用同一套系统，按配置运行。
它既承载真实生产与结算，也是采集数据入库、进入下游的入口。多方参与要求体系化管理人和流程，并为质量争议建立共同事实；规模化则要求质检不能靠人堆。系统已发展到约 20 个微服务，服务边界治理仍在推进。
系统长什么样
角色与协作
┌──────────────────────────────────────┐
│ 平台：项目分发 / 二次复核 / 结算确认 │
└──────────────────┬───────────────────┘
▼
┌──────────────────────────────────────┐
│ 供应商 × 8–12 │
│ 供应商管理员 → 采集员 / 质检员 │
│ 各自独立管理一线人员 │
└──────────────────┬───────────────────┘
▼
批次账单：生产事实 → 质量判定 → 结算事实
平台与供应商共享同一份事实
计算底座：Flyte + Ray 常驻 / Kafka 触发
自动质检：手部 / 黑帧 / 静态 / 人脸 / 过曝·抖动
项目规模
- 时间：约一年（2025–2026）
- 组织：平台、运营、多级质检与 8–12 家供应商（供应商自治）
- 地域：国内 + 马来西亚两地真实生产，同一套系统按配置运行
- 系统：约 20 个微服务，服务边界治理进行中
核心问题清单
① “这个月要采到 100 小时”，怎么变成多角色、多供应商、多地域的生产体系？
→ 设备无关的抽象让 iPhone 在硬件未就绪时顶上；供应商自治，多角色协作体系化。
② 平台与供应商之间的数据质量争议，怎么从机制上消除？
→ 批次账单连接生产、质量判定与结算事实，双方共享同一视图，争议场景本身消失。
③ 规模上来之后，怎么让质检不靠人堆？
→ 自动质检五类检测成为人工质检前的硬前置；Flyte + Ray 常驻计算模式支撑高频流式处理。
我的职责
Demo 阶段完成采集端（Web / iOS）设计与实现，设计供应商自治架构和批次账单机制；接手 CTO 主导的重构初版，约两周推至生产可用并持续演进；将自动质检工程化为流水线，独立实现 Flyte + Ray 常驻服务模式。整体贡献约 70%，架构设计贡献超过 50%。自研硬件 MQTT 协议和重构初版不由我完成。
生产规模
- 从“这个月 100 小时”起步，峰值约 3000 采集小时/天，为真实生产最大值，尚未触到系统瓶颈。
- 批次账单累计 9 万+ 条数据、约 5 万小时进入真实结算，“我采了 8 小时你只算 4 小时”式争议在机制层面消失。
- 供应商自治让协作不需要平台下沉：平台只面对供应商一层，多角色生产在同一套边界内运行。
- 5 类自动检测（手部 / 黑帧 / 静态 / 人脸 / 过曝抖动）是人工质检前硬前置；Flyte + Ray 常驻模式上线后，Pod 生命周期类问题不再出现。