把复杂算法系统，
推进到可交付、可评测、可迭代
系统工程是主线；数据、评测与模型适配，是向真实任务延伸的纵深
20192020202120222023202420252026
2019.03 — 2021.07
DeepMotion.ai
算法工程师
泊车合作项目交付负责人
起点：第一次端到端负责
方案、现场调试与交付
首页只做一件事：一分钟内讲清职业弧线。三段按实际时长画，机器人阶段最短，但挂了四个案例，节奏在加快。方法一直是同一条线：先说清问题、系统边界和验收方式，再建立观测，最后把一次解决沉淀成架构、工具、流程和 Owner
从负责栈的一段，到负责整条栈
团队规模与协作影响在自动驾驶阶段最大；进入机器人后，个人负责的环节从平台、集成、测试，延伸到数据、模型与任务执行
负责 / 主导参与未涉及
小米汽车 自动驾驶2021—2025
感知系统团队负责人小米 机器人实验室2025—今
整机系统与任务 Owner任务交付与执行
泊车合作项目交付负责人
感知模块量产交付
端到端负责螺柱工站任务
模型微调与真机适配
三组微调：π0.5 两组、XR-1 一组
质量、测试与发版
现场测试
测试左移、自动发版、MIL/SIL/HIL
90+ 项集成验证与专项测试
系统集成与性能
性能优化
资源治理，Crash −98%
三个工站的整机集成与可观测性
算法与策略
泊车相关算法研发
跨平台算法优化
限定取放初版，动作成功率 >90%
计算平台与部署
工控机 → Orin-X / N、Thor-U
VLN 云端 / 板端部署
团队与影响范围
个人贡献者，单个合作项目
直接团队最多 9 人；机制服务约 400+ 人协作
横向集成三个工站与各平台团队的能力
这页把两件事分开讲：影响力的峰值在自动驾驶，那时带 9 人团队、机制服务几百人的研发协作；机器人阶段团队更小，但个人从计算平台、集成、测试，一直负责到数据、模型和任务执行。实色是负责或主导，虚线是参与
从 0 到 1：
让团队和机制一起成立
问题
早期板端集成、平台迁移、发版和排障分散在各团队，上下文集中在少数人身上
我的责任
从 0 到 1 组建最多 9 人的感知系统团队，负责团队建设、量产交付、质量准出和系统性能
做了什么
- 1统一多团队共用的代码与运行框架、自动发版
- 2建设 MIL / SIL / HIL、代码质量与性能工具
- 3用文档和责任边界，让成员 Owner 完整模块
边界
9 人是正式管理范围；400+ 是共用机制服务的研发协作规模，两者不混用
范围由内向外
研发协作约 400+ 人规模使用
共用工程底座9+ 子团队，30+ 模块
代码与运行框架自动发版MIL / SIL / HIL质量与性能工具Owner 机制
感知系统团队最多 9 人，正式管理
9 人直接团队上限
400+人规模研发协作
仍在运行转岗后代码、工具与流程继续使用
判断团队是否成立，看的是负责人变化后系统能否继续运行。跨团队影响约 9+ 个子团队、30+ 个模块，这是机制影响范围，不表述为直接管理人数。后来转岗，Owner、代码、工具和流程仍继续使用
跨平台演进，
把质量与性能做成机制
问题
感知软件栈要从工控机迁到多代车端平台，约束各不相同；规模化协作不能靠发版前人工检查和少数人救火
我的责任
主导感知软件栈的平台演进与架构升级：跨平台集成、算力与资源预算、算法优化和量产 bring-up
做了什么
- 1测试左移：检查和回放进入变更路径
- 2Crash 自动路由：从堆栈识别模块，直接派给责任人
- 3资源治理：帧率、时延、CPU、GPU、内存进同一张预算表
边界
Crash 率为版本平均值，按每百万公里统计；定位时间是定位并分发给责任人的平均时间，不是完整解决时间
平台在换，机制不变
测试左移变更即检查
自动路由Crash → Owner
资源预算一张预算表
持续回归修复留基线
−98%版本平均 Crash 率
1 天 → 1 小时问题定位并路由到责任人
3 款车端平台：Orin-X、Orin-N、Thor-U
量产阶段模块持续合入，又运行在不同算力平台上，靠发版前人工检查无法扩展。补充口径：低配平台以不到五分之一算力覆盖约 80% 功能模块，按功能模块数量统计，不代表体验和模型规格完全等价
把整机从实验室状态，
收敛到小批量交付
问题
团队的年度重点研发项目：三个工站各自研发抓取算法，平台能力由各团队统一支持，需要集成成一套能稳定运行、能被观测的整机
我的责任
负责跨团队的系统集成、可观测性工具与测试；同时端到端负责螺柱工站的任务
做了什么
- 1把各团队的导航、定位、运控等能力集成进同一套整机栈
- 2补齐可观测性工具，性能和问题能被统一看到
- 3建立 90+ 项集成验证与专项测试
边界
P90 统计的是任务运行全过程的整机资源占用；小批量交付指几十台规模
责任范围
任务层三个工站
其他工站抓取算法 2 人
螺柱工站抓取算法 2 人任务我端到端负责
其他工站抓取算法 2 人
<60%任务全程整机 CPU P90
90+集成验证与专项测试
几十台小批量交付规模
2025 年转入机器人后，先从可迁移的系统集成、性能和测试方法切入：横向让三个工站在同一套整机栈上跑起来、看得见、测得住，纵向端到端负责螺柱工站的任务。不把整机横向责任表述成所有算法模块的最终责任
让一次评测，
决定下一轮做什么
问题
模型迭代需要大量仿真数据和可比较的评测；只看成功率，定位不到失败原因
我的责任
负责 VLN 从传感器接入、云端或板端推理到运控的真机部署，以及仿真数据生产与模型评测的规模化
做了什么
- 1数据生产与评测扩展到云端百实例级
- 2单实例数据生产吞吐提升约 2 倍
- 3用指标、轨迹、视觉结果和失败案例比较版本、归因问题
边界
模型架构与训练由算法同事负责；我负责数据、评测与部署这一侧
一轮迭代
数据生产仿真 · 百实例
→模型版本算法同事负责
→批量评测指标 · 轨迹 · 视觉
→真机验证部署 · 执行
我负责协作
百实例级云端并行生产与评测
约 2×单实例数据生产吞吐
4 类证据指标、轨迹、视觉、失败案例
评测不是终点，而是回答下一轮该补数据、改模型，还是先修环境和工程。每次评测固定初始状态、成功条件和复位，失败可以分类；未知异常、恢复失败和证据冲突仍进入人工兜底
三组微调：
真机场景、仿真量化、换模型
问题
要判断一个具身模型能否用在自己的任务上，既需要真机场景的验证，也需要能反复量化的实验环境
我的责任
负责三组微调从数据适配、训练、推理到评测的完整链路
做了什么
- 1真机数据：用挑战赛的商超取放数据微调 π0.5，在智元 G2 上执行
- 2仿真量化：在 Genie Sim 的数据与环境里微调 π0.5，做闭环仿真评测
- 3换模型：在第二组的数据与评测基础上，微调 XR-1
边界
第一组验证的是真机上的任务执行；第二、三组的结论来自仿真评测
三组微调，各自回答一个问题
第一组ICRA 2026 挑战赛任务
数据真机数据 · 商超取放
→微调π0.5
→验证G2 真机执行
第二组可量化、可复现的实验
数据Genie Sim 数据
→微调π0.5
→验证闭环仿真评测
第三组在第二组基础上换模型
数据Genie Sim 数据
→微调XR-1
→验证闭环仿真评测
3 组微调实验
2 种模型：π0.5、XR-1
仿真 + 真机两类验证
三组是分开的：第一组用 AGIBOT World Challenge @ ICRA 2026 的真机数据，商超场景的取放任务；第二组基于 Genie Sim 3.0 的数据和仿真环境，便于做量化实验和闭环仿真评测；第三组在第二组基础上改为微调 XR-1。不把仿真结果延伸为通用真机成功或模型优劣结论
让 Agent 决定目标，
让系统负责执行与验收
问题
开放任务里，Agent 要能调用机器人能力，但不能越过权限、状态和执行边界；结果还要能被机器验收
我的责任
提出并主导 RoboClaws（受控执行）与 RoboHarness（机器验收）
做了什么
- 1约 1.5 个月完成限定范围取放初版
- 2用 Task、Skill、Tool 与后端接口契约组织能力
- 3用指标、视觉证据和基线对比做自动验收
边界
取放成功率限定在两种机器人形态和限定任务集；16s → 3s 来自公开案例
分工
Agent决定做什么理解目标拆分任务选择 Skill
RoboClaws负责怎样安全执行稳定接口超时与权限急停与反馈
RoboHarness 验收指标 · 视觉证据 · 失败案例 · 基线通过 / 失败 / 人工
>90%限定任务集动作成功率
16s → 3s公开案例抓取规划时间
一等奖2026 部门 AI Hackathon
任务开始前先定义完成条件和失败边界，运行时收集指标、图像、告警和基线，再决定通过、失败或人工复核。长期工作方式也回到这里：定义边界，建立证据，把一次解决交给 Owner、团队或受约束的 Agent 持续运行