Phase 1｜工程可运行原型（MVP）

细化工程人才树（Baseline v1.0 对应）

Founder / 创始人
Chief Systems Architect / 首席系统架构师
│
├─ 机械 / 结构系统（重载底盘与执行机构）
│  │
│  ├─ 结构负责人（Heavy-duty Lead）
│  │  ├─ 履带底盘总体结构设计
│  │  ├─ 车架焊接结构与载荷路径
│  │  ├─ 重心 / 倾覆角 / 防埋设计
│  │  └─ 维护与更换友好性设计
│  │
│  └─ 执行机构结构工程师
│     ├─ 推雪板 / 抛雪头 / 滚刷接口
│     ├─ 快换结构与前端标准法兰
│     ├─ 浮动机构（地形适应）
│     └─ 防雪、防冰、防异物侵入
│
├─ 电气与电源系统（低温可靠性核心）
│  │
│  └─ 电气工程师
│     ├─ 主电压平台（48V / 72V）选型
│     ├─ 主接触器 / 急停回路
│     ├─ 电池加热与低温保护
│     ├─ DC/DC 分级（24V / 12V）
│     └─ 线束、保险、过流与失效保护
│
├─ 控制与嵌入式系统（不乱跑是第一原则）
│  │
│  ├─ 嵌入式控制工程师
│  │  ├─ 行走电机控制（差速 / 四驱）
│  │  ├─ 执行机构电机控制
│  │  ├─ 功率限制与热保护
│  │  └─ 实时状态监控
│  │
│  └─ 控制逻辑与安全工程师
│     ├─ 状态机（启动 / 运行 / 故障）
│     ├─ 互锁逻辑（急停、舱门、电池）
│     ├─ 异常优先级与降级策略
│     └─ 碰撞 / 卡死 / 信号丢失处理
│
├─ 自动化与系统集成（工程落地关键）
│  │
│  └─ 系统集成工程师
│     ├─ I/O 点位定义
│     ├─ 端子编号与布线规范
│     ├─ 接地与抗干扰
│     ├─ 传感器与执行器集成
│     └─ 整机上电与调试流程
│
├─ 感知与传感器融合（规则优先）
│  │
│  └─ 感知工程师
│     ├─ 雷达（前向 / 障碍物）
│     ├─ 超声 / ToF（近距雪墙、边界）
│     ├─ IMU（姿态、防翻）
│     ├─ 里程计 / 编码器
│     └─ 多传感器一致性校验
│
└─ 基础软件与调试支持（最小必需）
   │
   └─ 软件 / 工具支持工程师（可兼任）
      ├─ 参数配置与日志输出
      ├─ 本地调试工具
      ├─ 简单远程接管接口
      └─ 故障数据导出

Phase 1 树的三个“硬约束原则”

1. 每个岗位都必须直接服务于“夜间不出事故”
2. 不允许出现“现在先凑合，后面再重构”的角色
3. 任何智能化设计，必须先通过规则与互锁

Phase 1 明确不进入树的内容（即使有人主动要做）

- 多机器人协同
- 高精地图
- 视觉为主的感知
- 云端调度平台
- 产品经理驱动需求

Phase 1 成功的唯一判据（不是 KPI）

在无人工值守条件下，
连续多晚，
完成至少一个核心场景的清扫任务，
期间发生异常但不造成危险，
且可复盘。

Phase 2｜系统稳定化与基站闭环

细化工程人才树（Baseline v1.0 对应）

Founder / 创始人
Chief Systems Architect / 首席系统架构师
│
├─ Phase 1 核心工程体系（持续参与，不重组）
│  ├─ 机械 / 结构系统
│  ├─ 电气与电源系统
│  ├─ 控制与嵌入式系统
│  ├─ 自动化与系统集成
│  └─ 感知与传感器融合
│
├─ 停靠 / 充电 / 融雪基站系统（Phase 2 核心）
│  │
│  ├─ 基站机构与对接工程
│  │  ├─ 自动停靠几何与容错设计
│  │  ├─ 防风、防埋、防错位结构
│  │  ├─ 对接失败自恢复机制
│  │  └─ 冰雪环境下的机械可靠性
│  │
│  └─ 基站电气与热管理工程
│     ├─ 自动充电接口与安全隔离
│     ├─ 低温条件下的充电策略
│     ├─ 执行机构 / 履带融雪加热
│     ├─ 基站自身供电与保护
│     └─ 过流 / 过温 / 异常断开逻辑
│
├─ 系统可靠性与失效工程（必须新增）
│  │
│  ├─ 测试工程师（夜间 / 极端天气）
│  │  ├─ 连续多夜运行测试
│  │  ├─ 暴风雪 / 吹雪 / 再堆积验证
│  │  ├─ 被埋 / 脱困失败场景复现
│  │  └─ 人工干预最小化测试
│  │
│  └─ 可靠性工程师（Failure-driven）
│     ├─ 失效模式与风险分类
│     ├─ 安全停机与降级策略验证
│     ├─ 单点失效排查
│     └─ 设计改进反馈闭环
│
├─ 控制系统稳定化与异常管理
│  │
│  ├─ 控制逻辑工程（升级）
│  │  ├─ 状态机稳定性重构
│  │  ├─ 异常优先级与互斥关系
│  │  ├─ 长时间运行内存 / 状态管理
│  │  └─ 不确定状态下的保守决策
│  │
│  └─ 安全策略与策略验证
│     ├─ 多重异常叠加处理
│     ├─ 通信中断 / 感知退化策略
│     ├─ 电量不足 / 低温耦合判断
│     └─ “宁可回站，不可硬撑”规则
│
├─ 远程运维、固件与日志体系（商用分水岭）
│  │
│  └─ 固件 / OTA / 运维工程师
│     ├─ 远程日志与事件记录
│     ├─ 故障时间线复盘
│     ├─ 参数远程调整
│     ├─ 固件升级与回滚
│     └─ 黑匣子数据结构设计
│
└─ 系统验证与交付准备（内部）
   │
   └─ 系统验证工程师
      ├─ 基站 + 机器人联合测试
      ├─ 真实场景压力测试
      ├─ 运行成功率统计
      └─ Phase 3 输入条件确认

Phase 2 的四条“不可退让原则”

1. 所有设计必须假设：夜里一定会出问题
2. 所有问题必须能被记录、复盘、解释
3. 任何异常优先级高于“完成任务”
4. 基站失败 = 系统失败，不能视为外部条件

Phase 2 明确不引入的内容（即使技术上可行）

- 多机器人协同
- 云端复杂调度平台
- 高级 AI 决策模型
- 自动学习 / 自我优化策略

Phase 2 成功的工程判据（不是展示指标）

在真实夜间雪况下，
连续多夜运行，
允许任务失败，
但不允许安全失败，
且每一次失败都可被工程解释与复现。

Phase 2 与 Phase 1 的本质区别（一句话）

Phase 1 解决“能不能跑”
Phase 2 解决“敢不敢放夜里”

Phase 3｜产品化与规模化前夜

细化工程人才树（Baseline v1.0 对应）

Founder / 创始人
Chief Systems Architect / 首席系统架构师
│
├─ Phase 1 + Phase 2 工程体系（保持不拆）
│  ├─ 机械 / 结构系统
│  ├─ 电气与电源系统
│  ├─ 控制与嵌入式系统
│  ├─ 自动化与系统集成
│  ├─ 感知与传感器融合
│  ├─ 基站系统
│  ├─ 测试与可靠性
│  └─ 运维 / 固件 / 日志
│
├─ 产品工程与配置管理（Phase 3 中枢）
│  │
│  └─ 产品工程负责人
│     ├─ 硬件等级定义（L1 / L2 / L3）
│     ├─ 场景 → SKU 映射规则
│     ├─ 功能边界冻结与裁剪
│     ├─ 版本兼容性策略
│     └─ 成本、可靠性、能力平衡
│
├─ 多机器人协同与任务调度（规模化前置）
│  │
│  └─ 车队与调度工程师
│     ├─ 多机区域划分
│     ├─ 任务优先级与接力机制
│     ├─ 基站共享与避让规则
│     ├─ 故障机退出与接管逻辑
│     └─ 不同能力等级混编策略
│
├─ 制造工程与工业化（能不能规模交付）
│  │
│  ├─ 制造工程师
│  │  ├─ 装配流程设计
│  │  ├─ 线束与模块标准化
│  │  ├─ 装配一致性与容错
│  │  └─ 生产问题反馈闭环
│  │
│  └─ 工艺与质量工程师
│     ├─ 焊接与结构工艺
│     ├─ 批量可靠性控制
│     ├─ 关键件质量判定
│     └─ 成本与良率平衡
│
├─ 系统验证与发布管理（工程到产品的门槛）
│  │
│  └─ 系统验证工程师
│     ├─ SKU 级测试矩阵
│     ├─ 工厂验收（FAT）流程
│     ├─ 现场验收（SAT）基线
│     ├─ 发布阻断条件定义
│     └─ 回退与升级策略验证
│
└─ 现场部署与客户交付支持（闭环能力）
   │
   └─ 现场系统工程师
      ├─ 客户现场部署
      ├─ 场景参数调优
      ├─ 实际雪况适配
      ├─ 问题定位与回传
      └─ 工程改进输入

Phase 3 的四条“产品化硬原则”

1. 功能可以不全，但边界必须清晰
2. 每一个 SKU 都必须能被测试覆盖
3. 任何新能力不得破坏 Phase 2 的稳定性
4. 没有交付与回收能力的功能，视为不存在

Phase 3 明确不引入的内容

- 无边界的智能决策系统
- 无验证路径的自学习模型
- 为销售定制的临时功能
- 未定义成本的“技术演示能力”

Phase 3 成功的工程判据（不是市场指标）

同一型号机器人，
在不同场地、不同雪况下，
由不同人员部署，
表现可预期、可解释、可复现。

Phase 3 的一句话定位

Phase 1 解决“能不能跑”
Phase 2 解决“敢不敢放夜里”
Phase 3 解决“能不能交付给别人用”

Phase 4｜规模化运营、平台化与长期演进

工程级细化人才树（Baseline v1.0 延伸）

Founder / 创始人
Chief Systems Architect / 首席系统架构师
│
├─ Phase 1–3 全部工程体系（长期保留）
│  ├─ 机械 / 结构
│  ├─ 电气与电源
│  ├─ 控制与嵌入式
│  ├─ 自动化与系统集成
│  ├─ 感知与传感器
│  ├─ 基站系统
│  ├─ 测试与可靠性
│  ├─ 运维 / 固件 / 日志
│  ├─ 产品工程
│  ├─ 制造与工业化
│  └─ 现场交付与支持
│
├─ 平台工程与系统演进（Phase 4 技术核心）
│  │
│  ├─ 平台系统工程负责人
│  │  ├─ 跨产品线系统一致性
│  │  ├─ 硬件代际兼容策略
│  │  ├─ 长期技术债控制
│  │  └─ 架构演进路线冻结与升级
│  │
│  └─ 公共能力工程
│     ├─ 通用控制框架复用
│     ├─ 通用基站与接口标准
│     ├─ 通用日志 / 诊断框架
│     └─ 跨 SnowBot / 后续机器人复用
│
├─ 规模化运维与车队运营（RaaS 前提）
│  │
│  ├─ 车队运维工程
│  │  ├─ 大规模设备健康监控
│  │  ├─ 故障统计与趋势分析
│  │  ├─ 维护周期与备件策略
│  │  └─ 远程与现场运维分工
│  │
│  └─ 运维工具与系统工程
│     ├─ 运维控制台
│     ├─ 批量升级与回滚
│     ├─ 权限与操作审计
│     └─ 客户级隔离策略
│
├─ 数据与工程反馈闭环（不是 AI 炫技）
│  │
│  └─ 工程数据分析工程师
│     ├─ 真实雪况与运行数据统计
│     ├─ 失效模式频率分析
│     ├─ 场景与 SKU 表现对比
│     └─ 反向输入产品与架构决策
│
├─ 产品线扩展与复用（战略层）
│  │
│  └─ 产品线系统工程负责人
│     ├─ SnowBot → MowBot / PatrolBot 复用
│     ├─ 新场景适配边界评估
│     ├─ 不可复用能力隔离
│     └─ 新产品是否立项的工程裁决
│
└─ 商用体系与长期交付保障（工程支撑）
   │
   ├─ 技术交付与客户成功工程
   │  ├─ 长周期客户运行支持
   │  ├─ SLA 技术支撑
   │  └─ 工程问题升级路径
   │
   └─ 合规、认证与标准工程
      ├─ 北美 / 欧洲合规演进
      ├─ 安全标准持续符合
      ├─ 行业规范对齐
      └─ 新法规影响评估

Phase 4 的五条“铁律”（非常重要）

1. 架构演进优先级高于功能扩展
2. 所有数据必须服务工程决策，而不是营销
3. 平台复用以“减少复杂度”为目标，而不是技术统一
4. 新产品线不得破坏 SnowBot 的成熟度
5. 创始人仍然保留系统级否决权

Phase 4 明确要避免的三种“公司病”

- 为了规模而牺牲系统可解释性
- 为了平台而过度抽象
- 为了资本故事而提前技术跃迁

Phase 4 成功的工程判据（不是估值）

系统已经不是“靠几个人记忆在运转”，
而是靠结构、规范和数据在演进；
创始人可以不盯每一个项目，
但系统不会跑偏。

四个阶段一句话总览（闭环）

Phase 1：机器能不能跑
Phase 2：夜里敢不敢放
Phase 3：能不能交付给别人用
Phase 4：公司离了某几个人还能不能长期进化