英伟达选Sharpa，看中的是它的灵巧手。但走进Sharpa在ICRA 2026的展位，你会发现这家公司的野心远不止于此。展位上摆着三台自研的North机器人：一台发牌，一台由人遥操作扮演接待员，一台备用。North采用轮式底盘，全身67个自由度，从2026年1月首发以来，已经做过和人类对打乒乓球、自主拍照、折纸风车等丰富演示。

我的疑问和很多行业观察者一样：既然灵巧手已经很出色，为什么要自研整机？这个问题背后，是一笔需要从工业设计角度来算的"全栈账"。

Sharpa方面的解释很直接：使用别人的本体容易受限制，难以按需调整反馈。只有自研本体，才能采集自有数据，形成硬件到算法再到数据的完整闭环。这个解释在技术层面是成立的，但从工业设计角度看，全栈路线的价值比"技术闭环"更深一层。

诺曼在讨论系统设计时指出了一个关键点：当一个产品由多个独立的子系统组成时，子系统之间的接口决定了整体体验的上限。如果接口设计得不好，即使每个子系统都很优秀，整体体验也会大打折扣。这就像一支乐队——每个乐手都是独奏大师，但如果指挥没有把他们的演奏协调好，观众听到的只是噪音，不是音乐。

Sharpa选择全栈路线，本质上是在为"系统接口"购买设计自由度。如果只做灵巧手，这只手要适配别人的整机——别人的通信协议、别人的电源管理、别人的安装接口、别人的控制节奏。每一次适配都是一次妥协，每一次妥协都在限制灵巧手可以发挥出的真实能力。而自研整机，意味着灵巧手和整机之间的接口可以由同一个团队定义，不需要妥协。

创品工业设计在服务装备类客户时，经常遇到类似的困境。一个客户找创品设计产品外观，但核心零部件来自第三方供应商，控制器来自另一家供应商，软件系统来自第三家。结果就是，创品设计的外观方案，在"适配"的过程中被不断修改，最终交付的产品和最初的设计方案相去甚远。这不是设计能力的问题，而是"系统接口"不在设计团队控制范围内的问题。

从创品的四力五维角度看，全栈路线对"控制力"的提升是根本性的。控制力意味着从概念到量产的全流程可预判。如果产品的关键子系统由外部供应商提供，控制力就打了折扣——供应商的交付节奏、技术路线变更、产品迭代方向，都不在你的控制范围内。全栈自研，则把控制力从"协调"层级提升到了"定义"层级。

全栈路线的另一个价值，是加速了"数据-模型-硬件"的协同迭代。Sharpa的CraftNet VTLA模型分为三层：System2推理脑、System1运动脑、System0交互脑。这个三层架构的设计，显然是在和硬件深度耦合的过程中迭代出来的。如果Sharpa只做灵巧手，模型中关于手部精细操作的部分就无法在和整机联动的环境中验证和优化。自研整机，等于为模型提供了一个"全场景测试环境"，每一行代码的改动都能在真实的整机环境中验证效果。

从"量产维"和"成本维"看，全栈路线的成本是前置的，但收益是后置的。前期投入的自研资源看起来很大，但避免了后期适配过程中的反复修改和性能折损。用帕帕奈克的话说，设计的真正成本不是设计师的费用，而是设计决策的后果。一个只做灵巧手的企业，今天省了自研整机的钱，明天可能要在适配过程中花更多的钱，而且最终的体验还打了折扣。

但全栈路线不是没有风险。最大的风险是"什么都做，什么都做不精"。Sharpa的策略是用"三层架构"来规避这个风险——System2做语义理解，System1做运动规划，System0做接触控制。每一层有明确的职责边界，不是"一个人做所有事"，而是"一个团队做自己的事，但团队的接口定义权在设计团队手里"。

在创品的"保障力"维度中，有一个核心理念：对最终用户体验的完整负责。如果灵巧手和整机来自不同供应商，当用户发现整体体验不好时，是灵巧手的问题还是整机的问题？这个责任界定本身就消耗了大量沟通成本。全栈路线，意味着责任边界清晰——体验不好，就是我的问题，不需要找别人。

Sharpa的全栈路线，不是"什么都想做"的野心膨胀，而是"想把一件事做透"的必然选择。在具身智能行业还处于早期的今天，标准化的分工体系还没有形成，不掌握全栈能力的企业，很难做出"最懂场景"的产品。而全栈路线的本质，是在为"精准的产品定义"购买设计自由度。
值得深思的是，Sharpa的案例还揭示了一个被行业长期忽视的规律：最好的产品定义，往往不是靠"做加法"来完成的，而是靠"做减法"来完成的。Sharpa的22个自由度，不是"能做多少做多少"，而是"需要多少做多少"。1:1人手比例，不是"看起来像人手"，而是"刚好能无缝承接人类动作数据"。直驱方案，不是"直驱比绳驱更先进"，而是"直驱在量产一致性和数据鲁棒性上更匹配目标场景"。每一个设计决策都有明确的目标场景对应，没有"为了做而做"的堆砌。这种克制的产品定义能力，在参数竞赛日益白热化的具身智能行业中，是一种稀缺资源。迪特拉姆斯说过，好设计是尽可能少的设计。Sharpa的灵巧手，恰恰体现了这种智慧——不是参数少，而是冗余少。创品在"好看维"的评估中始终坚持一个原则：好看不是"做了很多设计"，而是"做对了设计"。多余的设计语言是噪音，精准的设计语言才是价值。Sharpa的案例，为这个原则提供了一个来自前沿科技领域的绝佳注脚。