公司已经从手板阶段进入小批量试产，信息流建设度为 0。这个阶段最危险的不是“系统不高级”，而是图纸、BOM、工艺、软件版本、SN 与批次无法形成统一事实链，导致试产问题既难追责，也难复盘。
审批、任务、知识通知可以放在飞书，但 BOM、图纸版本、MES、SN、批次追溯必须落到结构化系统中。
让研发、试产、质量、供应链和售后共享一套可信数据链，而不是继续靠群消息和人工台账。
试产期的 IT 投入不是“后台支持”，而是控制交付风险、质量风险和放量风险的经营动作。
一旦进入小批量试产，图纸、BOM、工艺、测试与软件版本不再只服务研发团队，而会直接影响采购、仓储、装配、调试与售后。
没有统一账号、网络边界、代码与制品仓、数据备份和日志审计，后面不管上 MES、PDM 还是 AI，都会反复返工。
文件命名混乱、版本控制缺失、流程不可复用时，AI 只能制造更多噪音；先把数据、权限、流程标准化，AI 才能落地为工程效率。
不是追求大而全，而是让试产阶段的每一条关键业务流都能留下结构化足迹。
飞书承接消息、审批、任务、例会、异常协同。
研发事实源负责图纸/BOM/版本；制造事实源负责工单/SN/批次/测试。
所有关键变更都能追溯到人、时间、对象、版本与结果。
架构重点是“分层”和“最小耦合”：协同层、事实层、集成层、基础层各司其职，后续扩展才不会推倒重来。
先把“能跑起来的骨架”建成，再让业务数据逐步收口。
完成账号体系、权限分层、代码仓与制品仓、备份策略、命名规则、版本规范；定义飞书与业务系统的边界；明确图纸/BOM/SN/批次的唯一编码规则。
把研发变更、工单、来料、SN、测试记录串起来，先覆盖关键机型、关键工位和关键物料；完成第一条试产数字闭环。
建立跨系统审计与看板，打通飞书通知、研发版本、生产履历、质量问题；在此基础上再接入 AI 助手、知识检索、自动报表与 CICD 扩展。
这些风险在手板阶段可以忍，在试产阶段会直接转化为经营损失。
装配现场拿到的图纸、程序、BOM 不是同一版，返工与报废成本会迅速放大。
设备故障无法回溯到物料批次、工位、测试或软件版本，质量改善会停留在经验层。
系统未分层时，所有跨部门问题都要靠主管手工协调，扩产时最先崩的是管理带宽。
这 4 个判断决定后续建设是“可扩展”还是“反复推翻”。
飞书保留协同与审批职能，结构化主数据进入专业系统，禁止长期依赖手工表格做正式事实源。
先覆盖关键机型、关键物料、关键工位、关键测试，不追求一步到位的大 ERP。
研发 owner 管版本与变更，制造 owner 管履历与执行，IT owner 管平台、集成、安全与审计。
考核指标建议看闭环覆盖率、追溯完整率、变更周期、试产问题复盘时效，而不是单看系统上线数量。
架构图各层对应的产品文档、概要设计、详细设计与技术选型，点击直接跳转。
云上 VPC/LB/WAF/CDN · 内网 IDC · 混合云专线/VPN · 内部 DNS (PrivateZone/Route53) · 工厂网络 OT/IT 隔离
Rancher 多集群控制面 · ACK/EKS/K3s 三套集群 · 6 个标准配套 · Grafana+Loki 可观测 · 物理主机台账 · HPA+CA 弹性
飞书 SSO、SpringBoot 管理员 RBAC、pure-admin-thin Portal、JWT/JWKS/Gateway 业务服务接入
Prometheus + Thanos + Grafana、ElasticSearch 审计日志、AlertManager + 飞书告警、OSS/S3 备份
pure-admin-thin(Vue3+Element Plus) + SpringBoot admin-be、飞书 SSO、操作审计、配置下发、iframe 旧后台嵌入