训练与后训练系统：从跑通训练到看清模型

前一阶段 Research Box 已经有过训练相关的 Demo，但那套能力从一开始就是按 5 台 GPU 以下的小规模场景规划的，重点是把 Demo 链路跑通。后来公司真正进入 VLA 训练场景，需要重新建设一套面向更大规模的训练基础设施——这不是给 Research Box 加几个训练按钮的迭代关系，而是一次从规划目标就不同的重做：训练系统的目标是让训练本身成为平台可以理解、管理、追踪的对象，而不只是"帮用户起一个 Pod"。

而当训练系统本身跑起来之后，一个更深的问题浮上来：模型训出来了，到底行不行？ 具身智能不像纯软件，训练集指标好看不代表放到真实机器人上能把任务做对。这个问题推着我从"训练系统"进一步往前，去设计一整套后训练闭环——从训练可见性、真机评测、失败分类到数据回流。这一部分目前的状态是"链路设计完成 + 训练可见性和真机评测的第一版基线落地"，不是完整交付的成熟产品，需要诚实标注边界。

章一：训练基础设施

Sidecar-First：不假设底层可控

处境

训练系统要面对的底层算力形态从一开始就不是单一的：有裸金属（完全可控，可以自由挂载、注入进程）、有虚拟机（部分可控）、有 Container（挂载受限）、有一些云厂商或专用算力供应商只允许提供一个镜像名（几乎没有注入空间）。问题的核心是：无论底层算力以什么形式提供，训练任务都必须按照平台定义的方式运行，平台不能丢掉对训练过程的控制。 如果用户在训练 Pod 里随意执行自己的代码，从哪里拉数据、怎么训练、结果放哪里、产物是什么，平台就全部失去掌控——训练任务和平台就脱钩了，平台退化成一个纯粹的资源分配器。

桌上的选项

一条最省事的路是规定所有训练任务必须使用平台提供的标准镜像，把平台能力直接烧进镜像里。这条路技术上最简单，但用户成本很高：用户被迫放弃自己想用的镜像，或者用户自己打一版镜像还要重新注册回平台自建的 Harbor，平台还得再维护镜像仓库的容量管理。为了平台自己方便去限制用户，代价太大。

第二条路是 PID 1 注入：做一个平台自己的一号进程，编译成二进制放在 S3 上，Pod 启动时挂载进去作为容器的第一个进程。用户的真实训练命令通过环境变量传进来，由 PID 1 在启动前做环境初始化、执行用户命令、训练过程中收集日志和监控、训练结束后收集产物上传。这条路对训练过程的控制力最强，但依赖底层允许挂载和进程注入——一旦底层是 Container 且不允许自定义挂载，PID 1 方案就走不通。

第三条路是 Sidecar：把平台管理逻辑做成一个独立的 Sidecar 容器，跟着用户的主容器一起起来。主容器只负责最简单的启动和监听，Sidecar 负责初始化、采集、产物管理。对用户环境的侵入很小，用户主容器可以自由使用任意镜像，缺点是 Sidecar 和用户真实运行时之间有一层偏差——用户进程崩了、退出异常的时候，Sidecar 要通过一些约定信号去感知，控制力比 PID 1 弱一点。

我的选择

最终确定的优先级是 Sidecar 优先，Standard Image 兜底，PID 1/挂载作为特定场景能力——而不是很多人第一直觉的 "PID 1 最强所以先上 PID 1"。核心判断是：平台应该尽可能不限制用户的训练环境，同时保持平台对训练生命周期的控制。Sidecar 在这个权衡里是最平衡的一档——不强迫用户用平台镜像，不依赖底层挂载能力，实现相对简单，控制力也够用。PID 1 方案对底层有假设（能挂载、能替换 entrypoint），这些假设在异构算力环境下并不总成立，把它作为默认路径就等于把"可用的算力"和"可控的算力"划等号，这不成立。Standard Image 只在最极端的场景下使用——用户就是要用最便宜、最受限的基础设施，平台没法把控制点塞进去，这时候才让用户接受"必须使用平台镜像"这一层限制。

代价

Sidecar 和用户真实 Runtime 之间有偏差，要保证用户进程成功、失败、崩溃等各种情况下平台都能把结果文件和处理流程正确收尾，需要设计比较小心的信号协议。三层并存也意味着控制逻辑不能只写一套——不同 Runtime 下产物收集、状态上报、失败感知的具体实现有差异。

结果

Runtime 分层落地之后，用户可以在保留自己训练镜像的前提下把训练任务提交到平台，平台通过 Sidecar 完成生命周期管理。目前 2 名算法研究员的真实 VLA 训练全部走这条路径，累计 30 到 50 次训练任务，没有出现过因为 Runtime 限制而绕开平台的情况。

回看

这里面真正让我纠结的其实不是任何一层的实现难度——PID 1、Sidecar、Standard Image 单独看都不是特别复杂的事情。真正卡人的是到底应该做统一方案，还是做分场景的方案这个决策上的反复。我最终认识到，这类问题不能按"哪个方案技术上最优雅"来判，只能按"用户怎么样最简单"来判。平台的价值在于把复杂度吃掉，不是把复杂度转嫁给用户。所以最终选择的顺序不是按平台控制力从强到弱排的，而是按对用户侵入性从小到大排的。

K3s 与算力管理

处境

训练系统上线的第一件事是把 GPU 变成平台可以调度的资源。原来的 Research Box 是面向 5 台 GPU 以下的小场景做的，很多能力都很轻，算力纳管这一层几乎没有。训练系统这次要面对的是"数量会持续增长、类型会持续异构"的算力池，得先建立一个真正意义上的调度底座。

桌上的选项

一条路是直接上完整 K8s——功能最全、生态最好、未来扩展空间最大，但完整 K8s 的运维复杂度也是最高的，Master 节点、Etcd、网络插件、存储插件全都要维护。另一条路是 K3s——K8s 的轻量发行版，功能上覆盖了我们当前场景需要的所有能力，运维负担明显更轻。

我的选择

选 K3s。判断依据很直接：当前规模下 K3s 已经满足需求，没有必要为了"未来某天可能需要"的完整 K8s 能力而承担现在的运维复杂度。集群搭起来之后，接下来的几件事是把 GPU 真正变成平台可分配的资源——NVIDIA Device Plugin 部署到集群，让 GPU 对 K8s 调度器可见；RuntimeClass 配好，定义训练 Pod 使用的运行时；节点纳入集群、打标签、划资源池。这些做完，GPU 才算是"平台可以管理的资源"，而不只是"某台机器上的一张卡"。

存储这一层的思路是把复杂度藏在平台侧、把简单交给用户。用户在训练环境里需要两样东西：一个可以持久存放代码、模型、临时文件的工作空间，以及一份可以直接使用的训练数据集。工作空间的做法是通过 FUSE FS 把底层存储挂进容器，在 K3s 集群内以 PVC 形式挂载为容器内目录——用户看到的就是一个普通目录，可以放任何东西，重新进入环境的时候数据还在。隔离通过 Kubernetes RBAC 加配置层面保证，每个用户一份独立的持久化存储，A 用户不会误访问 B 用户的数据。数据集这一层是把 S3 上的 Object 通过 FUSE 挂载映射为容器内的文件目录，用户在训练代码里读的就是一个文件路径，不需要关心 S3 的 API、Bucket、Object。

异构算力接入这一层的复杂度前面 Sidecar 那一节已经讲过，本质上是同一件事的另一面——K3s 做集群调度，Runtime 分层做训练任务对不同底层的适配，两层配合把"从裸金属到纯 Container"的各种算力形态统一收进来。

代价

存储选型上目前仍然有一些空间没定死。FUSE FS 和其他方案（比如 RASSFS）之间的选择在真正投入大规模生产之前还没有做最终判断，缓存、统一挂载这些面向大数据量的能力也没有完整建设——因为当前的数据规模和用户规模确实还没到需要这些能力的量级，硬做等于过度设计。

结果

K3s 集群 + GPU 纳管 + NVIDIA Device Plugin + RuntimeClass 上线，用户持久化存储 + S3 数据集挂载上线。之后所有的训练任务都通过这一层进入平台，GPU 资源分配、存储挂载、Runtime 选择在用户看来就是一个训练任务的提交动作，底层的复杂度对用户不可见。

回看

选 K3s 这件事其实和后面很多决策是同一类判断：当前规模下够用的方案，比理论上更完备的方案更值得选。K8s 的完整能力在我们的规模下用不上，硬上等于把运维成本白白提上去。这个思路后来在存储选型、异构算力接入、Runtime 分层这些决策上反复被印证。

Training SDK 与可追溯体系

Runtime 那一层解决的是"平台怎么控制训练任务"，SDK 解决的是另一个问题——"训练代码本身怎么和平台建立结构化关系"。这两件事是并行的，不能互相替代。

我亲自写了 Training SDK，提供六件核心能力：SDK 初始化、Metrics 输出、训练任务信息输出、Artifact 输出、Model 输出、普通文件输出。用户在训练代码里通过 SDK 把训练过程中产生的信息交给平台，底层由 Sidecar 或 PID 1 负责把这些内容转发到平台侧的图表看板和产物管理系统里去。Metrics 走 MLflow 的图表；Artifact 走产物管理；Model 走模型管理。用户不需要直接和平台的存储、数据库、消息队列打交道——只需要认识 SDK 提供的那几个接口。

配合 SDK，训练任务在启动的时候会把一整套上下文信息记录下来：使用的镜像、环境变量、代码库、代码版本（我们建议用户把训练代码仓库直接拷进镜像里，SDK 在训练时读取当前目录的 Git commit 拿到代码版本）、启动命令、超参数、数据集（用户在平台创建训练任务时指定数据，平台负责挂载——技术上用户可以绕开平台用脚本训练，但那样会失去记录，我们的建议是尽量从平台任务入口发起训练）。训练过程中，SDK 把超参数、Metrics dump 到本地文件，Sidecar 统一回收上传到训练任务表。训练结束后，用户在页面上把 Artifact 确认发布为 Model 的时候，之前记录的所有训练上下文会一起绑定到这个 Model 上。

于是一个模型不再是一个孤立的 `.pt/.pth/checkpoint` 文件，而是一个可以回答"我是怎么训练出来的"的对象——顺着 Model 可以找到对应的 Training Job，再找到 Code Version + Dataset + Hyperparameters + Metrics + Environment + Artifact 的完整训练路径。

这套设计不是"平台架构漂亮"的产物，而是从我自己的真实痛点转化来的。我以前训模型的时候踩过这个坑：训了几十个版本，找到一个效果最好的，之后要在这个版本上继续迭代，但当时的代码、数据、参数、环境已经找不清楚了——这时候人就傻了。多版本评测的时候也是同样的问题，如果不知道每个版本背后的完整上下文，对比就没有意义。所以这套追溯体系是从一开始就作为平台的基础能力设计的，不是"做好了再加"的功能。

同时需要诚实说明的是：目前实现的是完整记录 + 可追溯，没有实现"一键复现"。也就是说，拿一个已经产出的 Model，可以顺着它记录的代码 commit、镜像、依赖、数据集、超参重新发起训练——这条路径的信息是全的，人工按这些信息去重训是可以的。但"用户点一个按钮就自动按记录去重训一遍并验证结果"这件事，目前没有优先级，也没有做。这个边界不能包装成"已经实现可复现"。

Metrics 这一层通过 MLflow 落地。平台已经接入 MLflow，训练过程中的 Training Metrics（loss、learning rate 等）、Evaluation Metrics、GPU 和资源运行指标、Checkpoint 都能在平台界面上看到，不同训练实验之间的曲线对比也支持。训练从"提交 Job → 等结果"的黑盒过程，变成了一个可以观察和比较的实验过程。

在这一切之上还有一条方向探索——边缘计算训练。这里的"边缘"不是 IoT 小设备，而是云厂商在边缘侧提供的计算资源——性能上完整可用，稳定性比中心机房差一点，价格显著更便宜。我们对接边缘算力的动机就是成本。架构上的核心是中心存储为主、边缘存储为缓存：训练任务启动的时候，由中心节点把对应的数据集从中心存储拉到边缘存储；训练在边缘 GPU 上进行，训练过程中产出的 Checkpoint 和模型先保存到边缘存储；训练任务结束后由一个 DaemonSet 负责异步把边缘的模型数据同步回中心存储；同步完成之前，中心侧看到的这个模型处于"暂时不可用"的状态。这样的结构可以接受边缘节点中途失败——训练过程中挂了就重跑，Checkpoint 支持恢复；重要的数据和模型最终仍以中心存储为准，不会因为边缘节点丢数据而丢结果。

这条链路已经用 π0.5 做过 Demo 训练，把标准数据集从云端拉到边缘、在边缘完成训练、再把模型异步同步回中心的完整流程跑通了。Checkpoint 和失败恢复的能力已经实现，但没有进行大规模生产验证；训练用的数据集目前仍然是标准 Demo 数据集，还没有完全接入我们自有的采集系统。所以这一块准确的定性是架构验证 / 内部 Demo 已跑通，不能算作生产规模落地。

技术架构：训练系统分层

训练系统分层架构

┌─────────────────────────────────────────┐
│  用户层                                  │
│  Training SDK（模型存储/导出/Metrics/超参/MLflow）│
│  用户代码 + 训练命令                      │
└──────────────────┬──────────────────────┘
                   ▼
┌─────────────────────────────────────────┐
│  运行时层（三层降级，Sidecar 优先）        │
│                                         │
│  裸金属/可控环境 → PID 1 注入            │
│    平台二进制作为容器第一进程              │
│    环境初始化 → 执行用户命令 → 收集产物    │
│                                         │
│  Container/挂载受限 → Sidecar            │  ← 默认路径
│    独立伴生容器处理平台管理工作            │
│    用户容器不受侵入                      │
│                                         │
│  极度受限 → Standard Image               │
│    平台能力封装进镜像本身                 │
│    用户使用平台提供的标准训练环境          │
└──────────────────┬──────────────────────┘
                   ▼
┌─────────────────────────────────────────┐
│  存储层                                  │
│  用户持久化存储（FUSE FS / PVC 挂载）     │
│  S3 数据集挂载（映射为本地目录）           │
│  每用户独立空间，RBAC 隔离               │
└──────────────────┬──────────────────────┘
                   ▼
┌─────────────────────────────────────────┐
│  调度层                                  │
│  K3s（非完整 K8s，够用即可）              │
│  GPU Device Plugin + RuntimeClass        │
│  计算节点纳管(含边缘算力节点)             │
└─────────────────────────────────────────┘

训练可追溯链路
  Training Job
    ├─ 代码仓库 + Git Commit
    ├─ 镜像 + Python/pip 环境
    ├─ 超参数
    ├─ 训练配置
    ├─ 数据集引用
    ├─ Training Metrics（MLflow）
    └─ Artifacts
         └─ 用户确认发布 → Model
              └─ 携带完整训练上下文

章二：后训练闭环

Research 体验优先：产品方向的一次判断

处境

训练系统的基础能力建成之后，下一步往哪走出现了明显分歧。当时桌上其实有两个方向都值得投入，但资源不允许同时做深。

桌上的选项

路线 A：把数据闭环做深。 采集 → 数据 → 标注 → 训练 → 数据回流，形成完整的数据飞轮。这条路的价值在于长期——一旦数据自动化跑起来，模型迭代速度会有质的变化。

路线 B：先解决用户核心 Research 体验。 让研究人员真正能够看数据、配训练、跑实验、看 Metric、做评测。这条路的价值在于当下——直接解决用户天天遇到的问题。

我的选择

选路线 B，把重心聚焦到 Research Experience 上。判断的依据是：用户当前更直接的问题不是数据闭环有没有完全自动化，而是跑完实验之后不知道模型表现如何。数据闭环再自动化，如果研究人员看不清自己实验的结果，闭环闭得再快也是白转。相反，如果先把"看数据 → 配训练 → 跑实验 → 看 Metric → 做 Evaluation"这条研究人员每天都在走的路径做顺，就算数据回流那一段还需要一部分人工，整体研发效率也会立刻上一个台阶。

这个决策严格说不是纯技术判断，而是一次产品判断——在有限资源下，用户当下痛的地方在哪儿、平台的投入应该压到哪儿。这个判断也决定了后训练这一块后面的建设重点：从"训练基础设施"进一步转向"实验结果质量 + Metric + Evaluation"。

代价

数据闭环那条路暂时被压后。目前数据回流到再训练的链路架构已经设计了（Failure Case → 确定需要什么数据 → 到已有数据系统里找 → 重新组织 Dataset → 重新训练），但完全自动化还在推进中。

结果

方向定下来之后，训练可见性和真机评测这两条线开始真正落地。前者已经跑通并进入 2 名算法研究员的日常研发流程，后者以 Success/Failure 的粗粒度基线跑起来了并且验证了 VLM 自动评判的可行性。

回看

这一节的关键其实不是"路线 B 好、路线 A 不好"——路线 A 的长期价值一直存在，只是在当前阶段不是最紧的事。真正值得注意的判断是：在一个偏工程的项目里，识别出哪一段属于产品方向问题、并且愿意在产品方向上做压强选择。工程视角下两条路都很有价值，产品视角下必须选一条先做——这两种视角切换的能力在这个决策里被逼出来了。

真机评测：从粗粒度基线到多视角证据

处境

真机评测这件事的核心问题看起来很简单：模型放到真实机器人上，任务到底完成没有？ 但要把这个问题变成一条可以持续跑的评测链路，第一个坑就是"到底怎么判断完成没完成"。如果一上来就想精确分析模型每一步输出为什么错，评测本身就会变成一个无限复杂的工程问题——每次评测都要人工对着视频看半天，评测通量做不上去，闭环就闭不起来。

桌上的选项

一条路是从最一开始就上精细分析——模型每一步的输出、每一帧的动作、每一次抓取的准确度，全都拆开来打分。这条路给出的信息最丰富，但工程复杂度最高，短期内不可能跑起来。另一条路是先建立最粗粒度的基线——不管模型内部发生了什么，只看结果：这一个 Case 到底成功了还是失败了。粗但快，先把评测这件事变成一个可以持续跑的流程，再逐步加深。

我的选择

选粗粒度基线优先。具体做法是：机器人真实运行模型的时候，一边执行推理，一边同步录制视频；视频作为评测的核心输入交给 VLM / 大模型做自动判定；VLM 第一阶段只回答一个问题——这个 Case 是否成功？ 这样就把原本大量需要人工看视频的评测工作，转化为机器自动评测。

Robot 执行任务
     ↓
同步录制视频
     ↓
视频 → VLM / 大模型
     ↓
自动判定：Success / Failure

这条链路跑起来之后，发现了一个之前没预料到的问题——机器人自己的第一人称视角有时并不足以判断任务成没成。机器人摄像头视野里看到的是"我要抓的东西在哪里"，但机器人根本没抓到这件事，往往只有站在机器人外面的观察者才能看出来——从机器人自己视角看过去，画面里可能只有一个空掉的夹爪或者一个和目标重叠但没接触的动作。VLM 拿着第一人称视频判"成功"，其实是错判。

这个问题的解法不是让 VLM 更聪明，而是给 VLM 更好的输入——增加第三人称 / 俯视视角摄像头。同一个评测 Case 同时录制两路视频：机器人自己的第一视角 + 场外的第三人称/俯视视角。VLM 在判定的时候可以同时看到两路视频，"抓没抓到"这类需要外部视角才能判断的事情就有了充分依据。

最终一个评测 Case 不再是一个孤立的数字，而是一个可回放、可追溯的完整证据包：机器人第一视角视频 + 第三人称/俯视视角视频 + 原始机器人运行数据 + 模型运行信息 + 最终 Success/Failure 结果。得到的不只是"模型失败了"，而是"这个 Case 真实失败了，并且有可回看的证据"。

代价

粗粒度基线只回答"成没成"，"为什么没成"这一层需要靠后续的失败分类去补。第三人称视角这一层目前是设计和方案，摄像头部署和数据管道还没有全部铺开；多视角数据的存储、检索、和评测结果的绑定也在推进中。VLM 自动评判本身的准确性、边界、什么样的 Case 会误判，需要持续用真机数据校准。

结果

真机评测的粗粒度基线在 Demo 上已经跑通了——机器人执行任务、边推理边录制、视频送给 VLM 自动判定成功失败，闭环是通的。第三人称视角的必要性被这条链路发现并写进了后续方案。

回看

这一节最值得记的东西不是 VLM 或者第三人称摄像头本身，而是两个判断的组合：第一，评测这件事必须先有粗粒度基线，再谈精细分析——直接上精细分析等于永远跑不起来；第二，评测链路跑起来之后暴露的问题（第一人称视角不够），才是真正推动方案演进的信号，而不是坐在会议室里想。粗基线不是终点，是让后续问题能被看见的起点。

有了 Success/Failure 之后，才能进一步谈"为什么失败"。目前定义了四类失败原因：工程代码问题（机器人侧工程实现本身有缺陷）、模型参数问题（参数需要调整）、模型结构问题（模型本身或训练方式需要重新处理）、数据问题（训练数据的量不够或分布覆盖不到这个场景）。不同的问题类型对应不同的后续动作——工程问题走工程修复，参数问题走参数调优，模型问题走重新训练，数据问题走数据回流。数据回流这一段的链路架构已经设计（Failure Case → 确定需要补什么数据 → 到已有数据系统里找 → 重新组织 Dataset → 重新训练），但完整自动化还在推进中。AI 自动 Failure Analysis——让 VLM 直接看 Case、分析、给出问题分类和下一步建议——是下一步的调研方向，目前只是规划，没有实现。

技术架构：后训练评测链路

后训练评测链路

  训练完成 → 模型部署到真实机器人
       ▼
  ┌─────────────────────────────────┐
  │  真机执行任务                     │
  │  同时录制：                      │
  │  · 第一人称视角（机器人摄像头）    │
  │  · 第三人称视角（俯视/侧视固定机位）│
  │  · 原始运动数据                   │
  │  · 模型运行信息                   │
  └──────────────┬──────────────────┘
                 ▼
  ┌─────────────────────────────────┐
  │  VLM / 大模型自动判定            │
  │  输入：录制视频                   │
  │  输出：Success / Failure         │
  │  （粗粒度基线，不做精细步骤分析）  │
  └──────────────┬──────────────────┘
                 ▼
  ┌─────────────────────────────────┐
  │  Failure Case 分类（方案设计中）  │
  │  · 工程代码问题                  │
  │  · 模型参数问题                  │
  │  · 模型结构问题                  │
  │  · 训练数据不足                  │
  └──────────────┬──────────────────┘
                 ▼
  ┌─────────────────────────────────┐
  │  数据回流（架构设计中）           │
  │  确定数据缺口 → 数据系统补充     │
  │  → 重建 Dataset → 重新训练      │
  └─────────────────────────────────┘

当前状态
  ✅ 已落地：训练核心 + MLflow + Metrics
  ✅ Demo验证：真机评测 + VLM判定
  ◐ 设计中：第三人称视角 + Failure分类
  ○ 规划中：AI自动分析 + 数据回流自动化

落地与团队

训练系统这一部分从我独立完成 PoC 到工程化版本上线，一共大约 2 到 2.5 个月。PoC 阶段是我一个人从零把 GPU → 存储 → Training Job → SDK → Metrics → Artifact → Model 这一整条最小链路跑通——训练脚本用的是模拟脚本，不是真实 VLA，主要是验证平台流程本身。PoC 验证通过之后，进入正式工程化，团队构成是我 + 2 名系统研发 + 1 名 Infra 研发。这个阶段我的角色是架构和方案 Owner + PoC 和关键技术验证——Training SDK 是我亲自实现的，Runtime 分层是我给的设计、我实现了其中的控制/关联逻辑，MLflow / Metrics 的整体方案是我提出的，边缘计算的架构方案是我设计的；正式版的核心业务代码主要由其他研发实现。

后训练这一部分的状态需要诚实说明：训练可见性（MLflow 集成、Metrics 展示、数据/训练/模型的关联）已经落地，真机评测的粗粒度基线（Success/Failure + VLM 自动判定）在 Demo 上跑通，第三人称视角的方案已经设计但摄像头和数据管道还在推进；数据回流的架构已经设计但完全自动化仍在推进；AI 自动 Failure Analysis 仍然是规划方向。所以这一整块不能包装成"后训练闭环已经完整交付"，更准确的定性是训练可见性和真机评测第一版基线已落地 + 完整链路方向已设计 + 自动化能力仍在推进。

真实使用情况：训练系统当前使用者是 2 名内部算法研究员，专门训练 VLA 大模型，累计跑了大约 30 到 50 次真实训练任务。当前已经跑通的链路是"训练 → 模型产出 → 模型端侧推理"；机器人作为完整计算节点、直接在机器人本体上运行服务的部署链路正在落地。所以准确表达是"训练 → 模型 → 端侧推理"跑通，"训练 → 模型 → 真机任务闭环"还没有完成。

回看两个部分

训练系统这一层证明的是从零建立一个复杂系统的能力，以及在异构环境下做架构权衡的判断——不是"技术上更全的方案更好"，而是"用户使用成本最低、平台控制力足够"的方案更好，Sidecar-First 而不是 PID 1-First 就是这个判断的直接体现；Job → Artifact → Model 的完整关联把模型从一个孤立文件变成了一个可以回答"我是怎么训出来的"的对象，这个能力不是事后补的日志，而是从个人训模型的真实痛点直接固化进平台设计。

后训练这一层证明的是从工程视角切换到产品视角的能力——在训练系统建成之后主动识别出用户当下的痛点不是"数据自动化了没有"而是"模型评估看不看得清"，并且愿意在产品方向上做压强选择；真机评测这条链路展示的是把一个可能变成无底洞的复杂问题（怎么评估模型）先用粗粒度基线跑起来、再让链路自己暴露下一层问题的工程方法论。第一人称视角不够、必须补第三人称，这个判断不是拍脑袋想出来的，是评测链路跑起来之后自然显形的。

两个部分共同证明的一件事：在真实工程项目里，比"做出一个完备方案"更重要的能力，是识别当前阶段应该做到什么程度、哪一部分是可以标注为"仍在推进中"的。这一整块材料里几处需要压措辞的地方——一键复现没做、边缘训练是 Demo 验证、机器人本体部署未完成、后训练闭环整体是设计 + 部分落地、AI 自动 Failure Analysis 还在规划——都是刻意保留的诚实边界。工程判断力体现在方案的选择上，也体现在项目边界的自我认知上。