第五季客户 Demo 交付：从模糊目标到系统落地

补天石在 2025 年 10 月我入职的时候刚成立不久，对外讲的是具身智能领域的数据采集和后训练平台能力，但市场上没有任何客户真的验证过这件事——公司需要一个能拿出去说话的案例。我入职之后的第一件事不是写代码，而是先花时间写了业务规划文档和 PPT，然后跟着老板一起拜访了大约十多家具身智能相关企业，向潜在客户介绍公司的产品能力，同时直接与用户沟通需求。这是我第一次直接站在技术和客户之间——在 NIO 的时候我只需要接内部产品经理已经消化过的需求，而这一次，客户嘴里的模糊目标要靠我自己翻译成一份可以实施的技术方案。

十几家企业里，第五季形成了比较明确的合作意向。他们的需求描述得很直接但也很泛：他们要向宇树证明自己具备数据闭环能力，所以需要一个可以实际运行的 Demo，覆盖从数据采集到训练的全链路。他们不是在问"你给我做几个功能"，而是在问"你们能不能证明这条路走得通"。

我在这个项目里的角色，从头到尾基本就是一个人：前期参与业务规划、做对外 PPT、随老板拜访客户、直接和潜在用户沟通需求；中期把客户目标拆成技术方案、确定功能范围、独立完成全部开发；后期到客户现场部署、连接真实机器人、根据反馈迭代、完成交付。团队实际上有 3 个人，但另外两个人都投入在下一版 Research Box 的备战里，这个 Demo 我一个人拿下反而效率更高。

章一：从目标到系统

MVP 做减法

处境

客户给的是业务目标，不是功能清单。他们希望看到的能力是：机器人能在平台上执行模型、执行过程中能采到数据、数据能串到训练的完整闭环。但这句话怎么变成一套可以开发、可以现场演示、可以在一个月内交付的系统，是我要回答的问题。

而且我判断这里有一个根本性的判断题：客户此刻要的是"证明能力"，不是"交付产品"。这两件事对系统的要求完全不同——前者要求端到端链路能跑通、每个环节能演给你看，后者要求每个模块生产可用、稳定、可运维。如果按后者做，一个月做不完；如果按前者做，就必须主动砍掉大量成熟系统里"看起来该有但此刻没必要"的能力。

桌上的选项

一条路是把我在 NIO 智驾数据闭环体系里的那套完整能力搬过来——底层完整 K8s + Volcano 调度 + 多集群多节点训练、复杂的存储挂载体系(FUSE 挂载、跨节点数据共享)、生产级数据集(多层级结构、文件映射、版本控制、血缘关系、清理机制、存储映射)。这条路的优点是"看起来专业、看起来完整",但代价是工程量和一个月的窗口完全不匹配,而且客户根本用不上这些能力——他们要的是 Demo,不是生产系统。

另一条路是围绕"证明数据闭环能力"这个目标做一次彻底的减法,只保留链路跑通所必须的最小集合,把每个模块砍到"够用"的粒度,把节省下来的时间投在端到端串联和现场落地上。

我的选择

我选了减法。训练系统这一块,砍掉了完整 K8s 和 Volcano 调度机制,只用 K3s + Pod 级任务调度就够跑训练;砍掉了多集群、多节点分布式训练能力,单集群单节点足以支撑演示。存储这一块,砍掉了 FUSE 挂载、跨节点共享这些复杂能力,只用 MinIO 提供 S3 协议,数据访问统一走接口,不做挂载。数据集这一块砍得最狠——生产级数据集需要多层级结构设计、文件结构设计、底层存储映射、清理机制、血缘关系、版本控制,我在这个 Demo 里基本全砍了,只保留一个"裸数据集 + 挂载映射存储"的最小形态。

采集系统这一侧砍得反而最少,因为它是客户现场演示时最直观、最能证明"我们真的能做"的一环。这里的减法是选择性的:通用能力做薄,但用户可感知的实时性、多视角、交互流畅这些体验点必须做扎实。

代价

砍掉的这些能力,后来在 Research Box 版本里都要重新加回来——数据集的版本控制、血缘、清理机制,训练系统的分布式调度,存储的挂载能力,一个都不能少。但这些能力在第五季项目里做了没用,反而会拖慢交付节奏。所以这个代价我是接受的:Demo 阶段的简化和产品阶段的完整,是两件事,不应该混在一起做。

结果

一个月完成交付。系统在客户现场跑起来了,机器人接入了,采集链路走通了,数据落到 S3 了。60 万的合同签下来了。更重要的是,这个 MVP 的边界画得对——客户在现场看到的是"这条路真的能走通",而不是任何一个模块做得多深。他们的关注点从来就不是我们的存储引擎有多强、训练调度有多复杂,而是"机器人能不能真的接进来、数据能不能真的采出来、能不能看到全链路"。

回看

这个项目让我明确认识到一件事:成熟系统里的能力不是天然应该被复用的,判断哪些能力在新场景下根本不该做,和判断哪些能力必须做,是同一个能力的两面。我在 NIO 见过完整的智驾数据闭环体系,但在补天石的第五季项目里,那套体系的很多组件都是被主动砍掉的——不是因为我做不出来,而是因为在验证型 Demo 的场景下,它们的价值配不上它们的工程量。这个判断在后来的 Research Box 里又反过来适用一次:在那个项目里,被砍掉的能力要一项一项加回来,因为那时候的场景已经不再是 Demo 了。

功能清单定义权与技术选型

处境

客户给的是目标,不是功能列表。要把"证明数据闭环能力"变成一个能跑起来的系统,我必须自己决定:这套系统由哪些具体功能构成、每个功能做到什么粒度、模块之间怎么串起来、每一块用什么技术方案。这不是"接需求写代码",而是承担了产品/方案定义者的职责。而且我很清楚:如果我拿着一份含糊的方案就开始动手,一个月不可能交付;所以功能清单必须提前定义清楚,并且提前和客户对齐。

桌上的选项

一条路是先动手,边做边看,把最紧迫的模块先做起来,再根据情况补齐其他部分。这条路的问题是没有全局视角——单人交付一个跨越基础设施、训练、采集、数据、可视化的系统,如果没有提前的依赖梳理,后面一定会出现"某个模块做完发现依赖的下游还没建好"的浪费。

另一条路是先完成完整的功能清单和依赖梳理:功能清单 → 前端原型 → 系统依赖分析 → 工作量预估 → 按依赖顺序实施。这条路前期需要花时间"看起来什么都没做",但一旦清单和依赖梳理清楚,后面每一周的工作内容都是明确的。

我的选择

我把客户目标拆成了大约 24～26 个具体功能点,并且提前拿着这份清单去和第五季的 CTO 做过一次确认——这一步很重要,不是走形式,而是确保客户对"数据闭环"的理解和我对"数据闭环"的实现范围之间没有偏差。

清单大致覆盖这几层:

• 基础设施层:K3s 集群搭建、MinIO S3 存储、节点划分(训练节点 vs 推理/机器人节点)。
• 训练系统层:Training Pod 调度、PID 1 进程控制、训练指标向下输出、模型和产物输出、训练过程中的数据挂载、业务层的实验入口和训练入口。
• 模型部署层:训练完成的模型通过镜像服务重新部署回 K3s 集群,机器人以 K3s Worker 的形式加入集群成为推理节点。
• 采集层:机器人任务部署、遥操能力、WebRTC 视频推流、多视角实时监看、主视角切换、语音和键盘快捷键(开始/暂停/继续/停止录制)。
• 数据层:数据自动上传落盘到 S3、裸数据集管理、开源检索引擎、DSL 数据查询、点选拖拽和公式构建、VS Code 编写模式配合参数代码提示、检索结果重新组成新数据集。

技术选型的每一个决策都是刻意的,不是拿最先进的方案,而是拿最匹配"验证 Demo"这个场景的方案。K3s 而不是完整 K8s,是因为客户不需要企业级调度能力,K3s 的轻量部署反而更适合客户现场环境。MinIO 提供 S3 协议而不上复杂存储引擎,是因为数据访问的抽象层用 S3 就够了,不需要挂载语义。Pod 级任务调度而不是完整的训练编排,是因为 Demo 阶段只需要证明"训练任务能起来",不需要处理复杂的多任务资源竞争。

其中有一个决策我事后觉得价值最大——云控制面和本地数据面的拆分。

具体的场景是:我们的平台服务部署在云端,但客户的机器人设备在本地机房,客户的操作员用的电脑也在本地。机器人产生的数据主要有两类:一类是控制信令(任务状态、心跳、指令),数据量小,对实时性要求一般;另一类是实时视频流,数据量非常大,对实时性要求极高。如果所有数据都统一走"机器人 → 云端 → 用户浏览器"的路径,一是延迟感受会很明显,二是——这一点更关键——会遇到客户现场网络拓扑的不可控性。

真实的客户环境里,工厂和管理人员的位置不一定在一起,即便在同一个厂区,机器人、操作员、管理人员也可能处于不同的路由器、不同的 Wi-Fi 网段。这种情况下,大流量的实时视频如果统一走云端绕行,任何一段外部网络链路都会成为瓶颈,直接压垮用户体验。

所以我的设计是:云端只负责控制和管理(任务部署、状态同步、身份、鉴权、数据元信息),实时视频流不走云端——机器人通过 WebRTC 直接推送到本地浏览器,数据面完全在客户内网里跑。同时,采集的原始数据落盘到 S3 是异步过程,不占用实时链路。云端负责慢的、稳的、需要集中管理的;本地网络负责快的、大流量的、对实时性敏感的。

这个判断不是照搬 NIO——两个领域的数据形态、设备类型、用户诉求都不一样,车端场景里大部分数据链路本来就是先在车上落盘再统一回传,和机器人现场遥操作+实时监看的场景完全不同。这套云边职责划分是我在具身智能场景里独立设计的,后来直接影响了我做机器人数据链路和视频基础设施的思路——在后来的 Research Box 和双目设备项目里,实时数据面走本地、控制/管理面走云端,这个原则一直被沿用。

采集侧还有一个专门为具身智能设计的点:多视角视频的数据分流。机器人身上有多个摄像头,数据要一边给操作员看(用于遥操决策)、一边落到 S3(用于后续训练)。我把这两条链路做成了独立的数据流——一路走 WebRTC 实时推到监视器,一路走上传通道落到 S3——避免了"实时观看和存储互相拖累"的问题。这个设计也不是车端的直接迁移,车端场景里视频通常先落盘再统一上传,不需要实时观看;而具身智能的遥操场景里,操作员必须能看到低延迟的实时画面才能操作机器人,所以数据分流是必需的。

代价

功能清单提前定义、技术选型都是刻意做减法,意味着这套系统不能作为产品直接给下一个客户用——每一个客户的场景都需要重新评估。而且清单和 CTO 对齐这一步是有前置代价的——如果 CTO 后期改主意,或者他理解的"数据闭环"和 R&D 团队理解的不一致,前面的功能定义就要返工。好在这一次没出这个问题。

结果

24～26 个功能点在一个月里全部完成开发并现场演示。前期的清单+依赖梳理让开发节奏很清楚:第 1 周做 K3s 集群和训练基础设施(底座和训练任务是所有上层能力的依赖);第 2 周做任务部署和采集能力(采集依赖任务调度,顺序不能颠倒);第 3 周做可视化、多视角、数据集和检索;第 3 周周五开始现场交付。

云控制/本地数据面的架构在客户现场表现得很好——机器人推的高清多视角实时视频在浏览器里几乎没有延迟,遥操作起来手感很稳。客户 CTO 在第一、第二周的时候就跟我说"你这个能力很牛逼、感觉很酷",但那个时候我很清楚系统还远没到完整,所以并没有把这句话当成结论,只是当成一个阶段性的鼓励。

回看

功能清单的定义权就是方案定义权。客户给目标、我拆清单、拿着清单和 CTO 对齐,这个过程里我承担的其实不是"实现者"的角色,而是"这个 Demo 由哪些能力构成"的定义者。这一点后来在补天石的很多项目里反复出现——面对模糊的业务目标,谁能把它翻译成一份可以对齐、可以执行的技术清单,谁就承担了方案定义的责任。

技术选型的判断标准也是这次形成的:不追求"最先进"或"最完整",追求"最匹配当前场景的复杂度"。K3s、MinIO、Pod 级调度、云控制/本地数据面拆分,每一个选择的背后都是"客户此刻真正需要什么"的判断,而不是"业界标准是什么"的照搬。

技术架构：Demo 系统分层与云边分离

把这一章涉及的技术选型和架构判断落到系统层面，整体分层与云边职责划分如下：

基础设施层
  K3s 集群（非完整 K8s，砍掉 Volcano/多集群/复杂调度）
  MinIO / S3 存储（非 FUSE 挂载，接口访问）

计算层
  训练节点：GPU Pod 调度，Pod 级任务管理
  推理节点：机器人作为 K3s Worker 接入集群
  模型部署：训练产物 → 模型镜像 → K3s 部署

数据集层（大幅简化）
  裸数据集 + 存储映射（砍掉版本控制/血缘/清理机制）
  DSL 检索 → 数据筛选 → 重组数据集 → 训练

云边分离架构
  ┌─────────────┐          ┌─────────────┐
  │   云端       │          │   客户现场    │
  │  · 控制面    │          │  · 机器人     │
  │  · 任务管理  │◄────────►│  · 操作员     │
  │  · 数据管理  │  控制指令  │  · 浏览器     │
  │  · 训练调度  │          │              │
  └─────────────┘          └──────┬───────┘
                                   │
                            WebRTC 直连（不经云端）
                            机器人 → 本地浏览器
                                   │
                            数据落盘独立链路
                            机器人 → S3

核心判断：控制面云端，数据面本地。视频等大流量不绕云端，适应客户现场不可控的网络拓扑（工厂/管理位置分离、路由器/网段分裂）；云端只做慢的、稳的、需要集中管理的事，本地承担快的、大流量的、对实时性敏感的事。这套云边职责划分后来在 Research Box 和双目设备项目里被反复沿用。

章二:从系统到交付

单人端到端与迭代节奏

处境

一个月的交付窗口,一个人完成从架构到现场落地的所有环节。客户希望有可见的进展,而不是一个月之后突然给一个"惊喜"。同时,我自己也需要确认每一周的产出方向和客户预期是对齐的——功能清单是提前定义的,但客户的关注点可能在实际演示时才会真正暴露出来。

桌上的选项

一条路是闭门开发,一个月后一次性交付演示。这样开发效率最高,不用被中间的沟通打断,但风险是最后一次演示如果和客户的实际期望有偏差,整个项目的评价就要塌。另一条路是每周一次现场演示,把开发节奏和客户反馈节奏对齐——每周把当周做出来的能力拿到客户现场演示,现场收集反馈,再回来迭代。这样开发效率会因为差旅和沟通被稀释一部分,但可以持续校准方向。

我的选择

我选了每周一次现场演示的节奏。具体的迭代节奏是这样的:

• 第 1 周:搭 K3s 集群、跑通训练流程(Pod 调度、指标输出、产物落盘)。这一周产出的是最底层的基础设施,现场演示的时候展示"训练任务能在集群里跑起来"。
• 第 2 周:做模型和任务部署、采集能力的建设、启动/停止控制。采集能力依赖任务调度,所以顺序上必须先有第 1 周的成果才能做这一周。现场演示的时候展示"机器人任务能部署下去、采集能被启动和停止"。
• 第 3 周:做可视化交互——包括可视化窗口的快捷切换、视角切换(类似飞书会议那种多视角同时可切换主视角的方式)、数据集的整套实现、DSL 检索、点选拖拽和公式构建、VS Code 编写模式和参数代码提示。这一周的产出是最直接影响用户体验的部分。
• 第 3 周周五~第 4 周周二:客户现场驻场,把第五季的真实机器人设备实际接入我们的系统,把整个流程跑通。第 3 周周五去一趟,第 4 周周一和周二各去一趟,主要的现场交付集中在这几天。
• 后续:又去了客户现场两次,处理后续的问题和调整,才算是一个完整的一个月出来。

这套节奏之所以能跑成,是因为开发前的准备工作已经做完了——功能清单、前端原型、系统依赖分析、工作量预估都在开始前完成,每一周做什么、下一周做什么、依赖谁是清楚的。我没有做甘特图、没有开 Jira 排期,因为只有一个人做,不需要形式化的项目管理;但依赖顺序和工作量预估在我自己脑子里是明确的。最后实际完成速度比我自己预估的还要快一些。

客户侧的反馈也在这个节奏里逐步演进:

• 第 1、2 周:客户 CTO 看到基础能力跑起来,说"你这个能力很牛逼、感觉很酷"。这个时候我知道系统还远没到完整,所以对这种早期反馈保持谨慎——CTO 看到的是一个漂亮的开头,不代表整个 Demo 已经站住脚了。
• 第 3 周:客户的具体 R&D 工程师开始过来对接,进入技术细节的沟通。这个时候的反馈更实,他们会问"这个模块怎么用、那个接口怎么调",说明他们开始把这套系统当成一个真的可以使用的东西看待。
• 第 3、4 周:客户开始 challenge 工作量和复杂度——"这个是不是没那么复杂?真的需要这么多工作量吗?"这个转变很关键,后面单独讲。

代价

每周现场演示意味着差旅和沟通占掉一部分时间,开发窗口比闭门开发要短。但这个代价换来的是每一周都在校准方向,不会在最后一周才发现"客户想的和我做的不是一件事"。

结果

一个月完成交付,现场把真实机器人接入了系统,把从任务部署 → 遥操 → 多视角实时采集 → 数据上传/落盘 → 数据组织/检索的链路跑通了。开发节奏的可控性让我在客户现场演示的时候没有出现"某个模块还没准备好"的情况——每一周的演示都是真的能演出来的,不是 PPT。

需要诚实说的一点是:训练那一环没有闭上。我搭好的训练基础设施是完整的,K3s 集群、训练 Pod、指标输出、模型部署都能跑,但客户侧没有准备好实际的训练任务和真实的模型训练脚本,所以"真实采集数据 → 客户模型训练 → 新模型部署回机器人"这最后一圈没有用真实数据跑一遍。这一步的责任不在我们——训练任务的准备本来就是客户侧的事——但事实上这个 Demo 没有完成"完整闭环"的严格定义。诚实的说法是:采集到数据侧的全链路完整跑通了,训练链路本身建设完成但没有用真实数据端到端验证。

回看

单人端到端的效率优势在这次项目里体现得很明显——沟通成本为零,决策链路极短,任何一个模块出问题都可以在自己脑子里直接改。但代价也很清楚:一个人的深度和精力有上限,当项目跨越基础设施、训练、采集、可视化、数据检索这么多层的时候,每一层都不能做得太深,只能保证功能层面的正确。这也是我事后判断"MVP 是唯一正确路径"的另一个理由——如果任何一层想做深,一个人一个月做不完。

每周现场演示这个节奏后来在其他项目里没有再用过,因为后面的项目要么规模更大、要么客户不在同一个城市。但这个节奏让我认识到一件事:面对模糊需求的项目,持续和客户对齐的节奏本身就是风险控制——每周一次的现场校准,比最后一次交付时的一次性验证要可靠得多。

商业角色边界

处境

第 3、4 周开始,客户的态度发生了微妙的变化。R&D 工程师对接完技术之后,客户 CTO 那边(应该是受到 CEO 授意)开始过来找我说:"你这个是不是没那么复杂啊?真的需要这么多工作量吗?"这个问题的意思很清楚——他们在讲价,在试探我们报价的合理性。当时我们给的报价是 120 万打五折,也就是 60 万。

这个时候我面临的问题不是技术问题,而是商业问题:我要不要参与这场价格博弈?我是这个项目的实际开发者,我最清楚这套系统每一块的复杂度和工作量,如果我不出来说话,客户可能就会用他们对系统的直观感受来判断价值;但如果我直接下场谈价格,又超出了我的角色边界——我不是销售,不掌握公司的报价策略、成本结构、后续合作规划。

桌上的选项

一条路是完整参与商务谈判——不只是解释技术复杂度,还要主动进入价格讨论,和客户直接谈"这个价钱值不值"、"哪些环节可以让步"、"后续合作可以怎么绑定"。这条路的价值是完整覆盖商业闭环,但风险是我掌握的信息不足以支撑这种谈判——公司的成本结构、报价逻辑、销售策略这些我都不清楚,贸然进去很可能把事情搞砸。

另一条路是严格守住技术角色的边界——客户只要问技术问题,我就从技术角度回答;不问技术问题只问价格,我就不出面。这条路的代价是"商业闭环"这个能力在我这里就变成了"参与",而不是"独立完成"。

我的选择

我选了后者。客户不是直接问我"你这个有点贵",他们的问法是"你这个没那么复杂吧",这本质上是一个技术问题的包装。所以我只从技术立场回答:这套系统具体复杂在哪里、底层的技术复杂度是什么、每一块工作对应的工程量是什么。我从头到尾没有和客户 CTO 直接谈过价格,也没有参与报价调整。

这个判断的依据是:客户是在试探,不是在实锤。他们没有明确抛出"我觉得贵、我要砍价"的诉求,而是用一个技术包装的问题来看我们的反应。既然客户没有把实锤抛出来,我也没有必要主动去回答一个客户没直接问的问题——那样反而会把不需要谈判的场合变成谈判场合。而且价格问题本来就有销售和老板处理,他们比我更清楚公司的谈判空间和策略。

后续的商务处理确实是销售侧和老板侧接手的——他们和客户之间的具体沟通细节我没有参与,只是从销售那边听说客户有讲价的想法。

代价

"商业闭环"这个能力在这个项目里的表述不能写成"独立完成商务谈判",只能写成"参与并贯穿商业交付链路"。项目的商务价值判断、报价调整、回款推进都不在我的角色内。

结果

• 报价 120 万,合同金额最终 60 万(打五折),成为公司的第一笔商业收入。
• 客户回款并不顺利:交付后约 1~2 个月收到首笔约 15 万,剩余约 45 万在之后 3~4 个月才收回。整个回款过程比较缓慢,没有形成很顺畅的正式验收。
• 客户实际使用了这套系统,主要用于对外展示;我和宇树的工程师有过技术沟通,但最终并没有借此进入宇树的供应商体系,宇树最终应该是选择了其他方案(据了解是阿里)。
• 关于"客户拿系统对外宣传后融到数千万投资"这件事,我掌握到的是客户后来完成了一轮融资,但融资是否和这个 Demo 有直接因果关系,我不能作为事实来陈述——这只是时间上的接近,不足以证明因果。

技术侧的最终结果也需要诚实描述:在客户现场实际跑通的是"机器人任务部署 → 遥操 → 多视角实时采集 → 数据上传/落盘 → 数据组织/检索"这段链路;训练基础设施建设完成,但客户没准备好真实训练任务,所以真实数据的模型训练和"新模型部署回机器人"这一步没有在项目周期内完成。

回看

守住角色边界这件事在事后看是对的。如果一个人的信息不足以支撑一个决策,那么这个决策就不应该由这个人来做——价格问题涉及公司的成本、销售策略、后续合作规划,这些我都不掌握,即便我下场也未必谈得比销售好,反而可能把公司的谈判空间挤压掉。技术角色能做的事是把"这个系统值多少钱"这个问题的技术基础打扎实——让客户清楚每一块工作的复杂度和价值——然后把商业判断留给有信息、有权限的人。

这个项目的"商业闭环"因此更准确的表述是:从业务规划、客户拜访、需求沟通、方案设计、技术实现、现场部署到最终交付的完整链路里,我都是主要执行者;但商业谈判、报价调整、回款推进不在我的角色内。这样的表述比"独立完成商业闭环"更诚实,也更能体现我实际承担的责任范围。

落地与延伸

这套系统在客户现场跑起来了,但它的长期价值远不止一份 60 万的合同。

代码本身没有留下——第五季项目的代码所有权属于客户,我们没有保留使用权,后来做 Research Box 的时候所有代码都是重新写的。但技术设计沉淀下来了。第一版 Research Box 就是以这个项目为技术蓝本重新设计的,继承下来的东西包括:可视化展示、交互处理、标注能力、设备管理、K3s 底层体系、训练任务相关的设计。再往后的采集系统又是以 Research Box 为蓝本继续演进的。

所以这个项目实际上是我在补天石这一年所有系统的起点——不是通过代码复用,而是通过架构认知的沉淀。代码是给具体客户的,认知是长期属于自己的。

云控制/本地数据面的拆分思路后来在双目设备的接入、视频基础设施的重构里都反复被印证。MVP 做减法的判断在 Research Box 里被反过来用了一遍——那个项目里,被砍掉的能力要一项一项加回来,因为客户从"要 Demo"变成了"要产品"。功能清单定义权和技术选型这两件事,后来在每一个新项目里都是我首先要做的动作。

回看这个项目

这个项目连起来看,不是"一个月做了一个牛逼的 Demo",而是一次从模糊目标到系统落地的完整走通:客户给业务目标,我承担方案定义,主动做 MVP 取舍,单人完成从基础设施到现场落地的所有环节,最终在客户现场把真实机器人接入了系统,跑通了采集到数据侧的全链路。

值得诚实标注的边界有几条:

• 训练那一环没有用真实数据端到端验证——训练基础设施建设完成,但客户侧没准备好实际训练任务。所以严格意义上不能写成"完成从采集到训练的完整闭环",应该写成"覆盖采集→数据→训练→部署的端到端平台能力,现场实际验证了采集到数据侧的全链路"。
• 商业角色边界是"参与并贯穿商业交付链路",不是"独立完成商务谈判"。价格问题我从技术角度做过解释,但没有直接参与谈判和报价调整。
• 客户融资和这个 Demo 之间没有直接因果证据,只是时间上接近,不能作为项目结果来写。
• 我们没有借此进入宇树的供应商体系。

这些边界之所以要说清楚,是因为如果不说清楚,这个项目看起来就会像一个"完美闭环、独立完成、商业成功"的故事,而实际的故事比这个更真实、也更有价值:面对模糊需求,一个人在一个月里把系统从设计到交付跑完;技术上做出了在架构层面被后续项目反复复用的判断;商业上参与了完整链路但守住了角色边界;结果上有 60 万收入但不夸大成公司融资和宇树供应链的成绩。

这个项目真正证明的是:从模糊业务目标到可现场演示的完整系统之间的翻译能力,以及在这个过程中做架构取舍、守角色边界、沉淀长期资产的判断力。