从量产交付到模型与真机：Work Timeline 讲稿
从量产交付到模型与真机：Work Timeline 讲稿
缪东旭｜2026.09
使用方式
- 60—90 秒口头版：无需打开 Deck，先完成定位、两条证据与第一问
- 负责人 / Head 路线：
01 → 02 → 03 → 05 → 08 → 09，约 5—6 分钟 - Hands-on / Staff 路线：
01 → 02 → 05 → 07 → 08 → 09，约 5—6 分钟 - 数据 / 评测路线：
01 → 02 → 06 → 07 → 08 → 09，约 5—6 分钟 - 完整路线：按
01—09展开，约 10—12 分钟 01展示三个职业时代，02展示四次责任扩展；两者是不同阅读层次，不是两套时间线- 页面文字是证据和导航，不需要逐项念
60—90 秒口头版
我过去七年多主要解决一类问题：当算法的单点能力已经出现以后，怎样把它变成稳定交付、可验证迭代的完整系统。
在自动驾驶阶段，我从 0 到 1 组建了最多 9 人的感知系统团队，负责量产工程、质量和性能机制。代表结果包括版本平均 Crash 率按每百万公里统计下降约 98%，问题定位与责任人路由由约一天缩短到一小时以内。
2025 年主动转入机器人业务后，我先从整机集成、性能和测试切入，2—3 周内开始承担交付，随后进入完整任务、模型真机部署、数据评测、开放场景，以及 π0.5 微调和 G2 真机适配。
我主要以机器人系统技术负责人或 hands-on technical lead 的方向看机会。系统工程与交付是最稳定的主线，数据与评测、模型后训练和真机适配是近两年继续向模型与任务效果延伸的能力纵深。我希望继续从问题定义、方案推进一直跟到真机验证和交付。
你们现在最需要解决的问题，更接近完整任务交付、模型与数据迭代，还是团队和研发机制建设？
数据 / 评测岗位的接法
系统交付是我最确定能够承担的基础能力。下一步希望不只停在系统和工程支持上，而是继续向数据、评测和模型迭代深入，把从数据准备、版本比较到真机验证这一轮真正接起来。
在 VLN 阶段，我和模型同事共同围绕真机任务效果推进迭代。我主责真机部署、数据生产和批量评测，模型同事主责架构和训练。数据侧从本地执行扩展到云端百实例级，单实例吞吐提升约两倍；评测侧把指标、轨迹、视觉结果和失败案例放在一起比较模型版本。最后不是只给一张总分，而是一起判断下一轮应该补数据、改模型，还是先解决环境和工程问题。
01｜开场：三个职业时代与长期主线
我想沿着一条主线介绍过去七年多的工作：责任范围怎样从算法研发和现场交付，扩大到系统架构、团队建设、机器人完整任务，以及模型、执行和验收闭环。
首页把经历压缩成三个职业时代：自动驾驶、机器人系统交付、模型到真机。它不是按组织名称切分，而是按主要问题和责任边界切分。
这些阶段看起来跨度较大，但解决问题的方法稳定：先说清要解决的问题、系统边界和验收方式，再建立观测；一次解决以后，将方法沉淀为架构、工具、流程与 Owner 能力。
根据岗位需要，后面可以走负责人路线，也可以走 hands-on 或数据评测路线。
02｜全景：四次责任扩展，方法没有变
我第一次真正理解“交付”是在 DeepMotion。算法指标好只是起点，到了现场还要能运行，出了问题要能定位，最后客户可以验收，事情才算完成。
2021 年进入小米汽车自动驾驶早期研发团队以后，问题从个人项目交付扩大为多个算法团队、平台和车型共同面对的系统问题，所以责任开始进入团队建设和规模化工程治理。
第二页进一步拆成四次责任扩展：先整合共性工程，再让质量和性能机制支撑规模化协作；2025 年转入机器人业务，承担整机系统和一类完整任务；2026 年继续把模型后训练、真机执行和机器验收接成闭环。
这页只用于建立因果地图。后续不需要按顺序讲完，可以直接进入与岗位最相关的阶段。
03｜从 0 到 1：搭建感知系统团队
刚进入小米时，板端集成、平台迁移、发版、性能和排障这些共性工作分散在各算法团队，很多事情依赖少数熟悉全链路的人。
我把这些问题集中起来，从零组建最多 9 人的感知系统团队，负责招聘、培养、绩效和团队目标，同时持续参与关键架构和实现。
我们统一代码组织和运行框架，也把发版、回放验证、代码检查、性能分析和 Crash 排查逐步做成工具和机制。新成员通常一两天可以提交第一个有效修改，静态检查覆盖率达到 95%。
我判断团队是否成立的标准，是负责人变化后系统能否继续运行。后来我转岗，Owner、代码、工具和流程仍继续使用。最多 9 人是直接团队范围，约 400+ 人是机制服务的研发协作规模，两者不混用。
04｜从 1 到 N：质量与性能机制
到了量产阶段，感知已经是百人级协作，模块持续合入，也运行在不同算力平台上，靠发版前人工检查或少数人临时处理已经无法扩展。
我主要推动三类事情：测试左移；把 Crash 排查中的人工判断写进自动路由系统；把性能优化从单热点扩大为整机资源预算。
最终，版本平均 Crash 率按每百万公里统计下降约 98%，平均定位并分发给责任人的时间从约一天缩短到一小时以内；低配平台以不到五分之一算力覆盖约 80% 功能模块。
这里的“定位并分发”不是完整解决时间，“约 80%”也只按功能模块数量统计，不代表体验和模型规格完全等价。
05｜转入机器人：从技术支点进入完整任务
2025 年主动转入机器人业务时，我没有等掌握定位、地图、导航、运控和操作的全部细节再开始贡献，而是先从可迁移的系统集成、性能和测试方法切入。
大约 2—3 周后，我开始承担整体集成和性能交付。横向上负责三类工站共用的整机集成、资源观测和性能问题；纵向上端到端负责其中一类完整任务，对效果、版本节奏和最终交付负责。
我们建立 90 多项专项测试，把整机 CPU P90 控制到 60% 以下，稳定后每类工站分别完成 300 多组端到端自测并移交测试团队。我直接负责的完整任务，平均单次时长从 3.5 分钟降到 2 分钟以内。
这个案例证明的是跨领域迁移速度和明确范围内的端到端责任，不把横向整机责任表述为所有算法模块的最终责任。
06｜模型与系统协同：部署、数据与评测共同闭环
机器人交付以后，我进一步进入 VLN 模型部署、数据生产和评测。这是一条由不同主责共同推进的闭环：大家共同围绕任务效果迭代，我负责连接传感器输入、模型推理、机器人接口和运控；较大的模型在云端执行，较小的模型可以直接在机器人板端运行。
团队尝试了不同 VLM 骨干与动作输出方案，并对绝对坐标、增量坐标、距离-角度等 waypoint 表示，以及单帧、多帧和 grounding 数据配方进行对照。
VLN 的场景与数据来源包括 OmniGibson、Habitat、BEHAVIOR-1K、InteriorGS，以及自建场景与 Digital Twin。数据生产链从这些仿真场景和视频样本开始，用 VLM 自动生成标签，再通过多模型复核和人工异常处理形成可用数据。数据生产的单实例吞吐提升约两倍，并扩展到云端百实例级。
模型评测链从待评测版本出发，把指标、轨迹、视觉结果和失败案例放在一起做归因。随着数据生产和批量评测规模扩大，方案逐步收敛，并在真机目标导航中取得可用效果。两条链路最终共同回答同一个问题：下一轮应补数据、改模型，还是先解决环境与基础设施问题。
这一阶段我主责模型真机部署、数据生产与批量评测，模型同事主责架构和训练。我们通过评测和真机失败证据共同收敛方案。我也会把部署约束带回方案讨论，例如自回归模型的输出表示会影响序列长度和真机耗时。2026 年两项具体 π0.5 任务微调属于另一个明确范围，不能把两个阶段的 ownership 混在一起。
07｜从仿真指标到真机验证：Endless Testing
评测体系不是一开始就全自动。我们先在仿真中建立 SR、NE 和碰撞等指标，同时保存轨迹、起终点、过程和失败位置，让评测结果能够解释。之后把运行、记录和可视化扩展到云端批量任务，再部署到 TurtleBot、Thor 和真实环境中验证。
当这些基础环节稳定以后，我们开始尝试 Endless Testing。过去由测试人员观察场景、选择目标、编写指令、移动机器人并整理结果；现在由 VLM 理解机器人看到的场景，生成适合当前环境的 go-to 指令，交给 VLN 模型执行，保存指标与视觉证据，再由 Oracle 移动或复位机器人进入下一轮。
这个系统已经在内部部署，并在部分场景中形成效果。它还不是完全不需要人工：异常情况仍然需要兜底，也不能把万级自动测试的目标写成已经完成。但它验证了一个重要变化：VLM 不只用于数据标注或作为被评测模型，也开始承担测试操作员的一部分职责。
这项实践成为后续 Agent 执行和机器验收工作的前置经验：开放目标可以由模型理解，但物理执行、结果证据和异常恢复必须落在明确、受控的系统边界内。
08｜任务适配、受控执行与机器验收
最近的工作分成三个相互连接的层次。
第一是模型后训练与真机适配。基于公开任务体系和 Genie Sim 3.0 工具链，我打通了两组 π0.5 任务的数据、微调、推理、传感器与机器人接口、自有场景适配和智元 G2 真机执行。这个案例证明快速理解上游能力和边界，并亲自完成从公开能力到自有任务的工程闭环；不表述为稳定成功率、基础模型或上游公开项目的原创成果。
第二是受控执行。开放目标不能只靠固定 Workflow，但物理执行也不能完全放开。所以我提出并主导 RoboClaws：上层 Agent 负责理解目标、规划和选择 Skill，Skill 承载任务策略，MCP 只暴露稳定、受控、可观察的机器人能力。
第三是机器验收。RoboHarness 在任务开始前定义完成条件、失败边界、基线和证据格式，运行后自动收集指标、图像、告警和基线对比，形成可复查的 proof pack。项目获得部门 AI Hackathon 一等奖。
三类证据严格区分：限定任务集动作成功率超过 90% 是基础动作能力证据；G2 证明两组模型任务的真机链路已经打通；RoboClaws 和 RoboHarness 分别证明受控执行与验收方法。
09｜收尾：下一步承担什么责任
我比较擅长把单点技术放进完整系统，找到真正影响交付的问题，再通过架构、工具、评测和团队持续解决。
我的工作通常有四步：定义边界和验收；建立观测和证据；把一次解决写进工具与流程；最后交给 Owner、团队或受约束的 Agent 持续运行。
下一步以机器人系统技术负责人或 hands-on technical lead 为主要方向。系统工程与稳定交付是主线，同时继续保留数据与评测、模型后训练、微调和真机适配的技术纵深。我希望继续深入一线技术，从问题定义、方案推进一直跟到真机验证和交付。
我先讲到这里。前面这些经历中，哪一段与你们现在面对的问题最接近？我们可以直接回到那一页继续聊。