作者｜毛心如
具身智能圈子里，大家总喜欢把问题变成一道 A or B 的选择题。
例如，机器人下一步究竟应该继续把本体做得更强，还是等待通用大模型变得更聪明。
前者决定机器人能做什么，后者决定它能理解多少。
但从听懂要做什么到在现实世界里把事情做好，两者之间还有一段不短的距离。
硬件再强，不意味着机器人就能理解复杂的需求；大模型再聪明，也不会自动获得稳定操作真实物体的能力。
星尘智能创始人兼 CEO 来杰并不想做这道选择题。
他既要本体，也要自研具身模型，还想通过 AOS 搭起一套协作机制，来吃下 GPT-6 Astra 之类通用模型带来的红利，让不同的智能和工具能够协同完成任务。
这是他的模型哲学：保持开放，既要又要。
来杰不认为具身模型和通用模型是对抗关系，也不认为它们是上下级、或简单分层关系。他更认可的是，它们是一种伙伴关系，有着同等价值，需要各司其职，携手共进。
最近结束的星尘智能 AOS 黑客松，作为全国最大规模机器人 App 黑客松，把这套思路进行了一次大胆尝试。
17 支队伍在 36 小时内开发机器人应用，16 个 App 完成了真机测试，上真机率达到 94%。有人想让机器人在 3D 打印结束后自动收料，也有人围绕台球、书法等场景开发应用。
比起只看这些 Demo 最终有多成熟，这场黑客松真正值得看的地方在于：当开发者开始借助自然语言和 AI 把创意变成机器人任务，机器人能力的创造方式是不是也在发生变化。
星尘智能想做的，是把更强的身体、更聪明的大脑之间的协作打通，让更多人有机会把机器人的能力用起来。
别让机器人只被厂商定义
今天不少机器人应用的开发方式，仍然带有传统工业自动化的印记。
厂商或开发团队先划定机器人的能力边界，将可执行的动作、支持的任务整理成相应的功能，再由用户在既定范围内选择。
这套方式在标准化产线中经过了长期验证，但放到家庭、办公等需求更加多样的场景里，先天存在局限。
真实世界的需求是分散、私人、充满细碎偏好的：有人希望机器人照料宠物的习惯贴合自家节奏，有人期待它承载轻量的创意互动，也有人只是想把工作中某个重复的环节交给机器完成。
这些散落的诉求，永远无法被少数产品经理和研发团队提前穷尽。
黑客松里那些看起来技术门槛不高的创意，恰好撕开了两类创作者的分野。
工程师更擅长解决轨迹规划、力控闭环、稳定性这类底层硬问题，思考的第一标尺是可行性；
普通创作者、终端用户更懂场景里细腻的体感与情绪，他们清楚自己想要什么样的体验，缺的是把主观构想映射到机器人躯体上的工具。
很长一段时间里，这两类群体之间横亘着厚重的技术壁垒，自然语言驱动的 AI 接口出现，才开始慢慢消融这道边界。
星尘智能 AOS 设想的「一句话生成机器人 App」，本质就是尝试弥合这道鸿沟。
当然，自然语言输入不等于一键交付可用程序。从一句口语指令到真机上稳定运行的应用，中间隔着现实世界的不确定性。
同一套逻辑在仿真里跑得通，落到真实场景，光照偏移、物体摆放的微小误差、接触面摩擦力变化，都可能让动作失效。
尤其是在机器人能力尚未经过充分验证时，直接在真实环境中反复尝试，不仅试错成本更高，还可能损坏机器人本体。
因此，AOS 和其他机器人开发系统一样，通常都需要先在仿真环境中调试，再通过真机验证。
仿真能降低试错成本，却无法完全替代物理世界中的测试。这是机器人开发的常规流程。
开发流程之外，还有产品节奏的问题。
星尘智能在绳驱机器人本体已经具备商业化基础之后，选择把软件能力进一步开放出来：AOS 不只服务于自有产品，也尝试把机器人的能力开放给更广泛的开发者。
于是问题落到第三层：先有生态，还是先有应用？开发者生态究竟是机器人成熟之后的奖励，还是应用生长过程中必须提前铺好的土壤？
来杰用大模型 Agent 的演进轨迹举了个例子。
早期大模型局限于纯文本对话，价值边界清晰；直到工具调用、多智能体编排框架逐步成型，大模型才从对话玩具，进化为能够调度外部系统的生产力载体。
物理 AI 的生长逻辑，也可以沿着这条经验理解。
机器人本体是承载能力的躯体，千千万万来自不同背景创作者的应用，才是赋予躯体身份、适配多元场景的灵魂。
只依靠厂商自研应用，产能永远追不上现实需求的多样性。如果开发门槛能够进一步降低，更多了解场景的人就有机会参与进来。
Design for AI：接口不仅要让人看懂，还得让模型用得上
三位一体，一直是星尘智能践行的全栈路径。其中包括自研具身基座模型 Lumo 系列、AOS 机器人操作系统，以及绳驱本体 T1 与 S1。
这套架构的内核，是其锚定的 Design for AI 理念：整套系统的能力封装、接口规范、资源调度逻辑，首要服务对象是 AI 智能体，人类程序员并非唯一受众。
传统机器人中间件与操作系统，典型地为人设计。接口文档、调用范式、状态反馈，全部以程序员为阅读主体，由人读懂规范之后，再翻译为代码调度机器人能力。
AOS 颠倒了这个优先级。
这里的 AI，既包括端侧本地运行的基座模型，也包括外部接入的通用大模型。它们本身就是可以自主决策、自主编排任务的执行主体，系统原生就要适配它们的理解方式、调用习惯和容错逻辑。
人类开发者、外部通用大模型，也都属于这套底座之上的使用者。
也正是这个底层设计，让 AOS 天然具备对接通用大模型的能力。
上层通用大模型读懂人的模糊意图之后，可以自主挑选、组合机器人的感知、抓取、移动、力控能力完成任务。
但这并不代表 AOS 是依附于外部大模型的配套层。
Lumo 系列作为星尘自研的端侧具身基座，本身就是这套 Design for AI 理念里最重要的 AI 载体，负责物理世界里毫秒级的闭环感知、力控、姿态调整。
其中 Lumo-2 是业界首个家庭隐式世界动作模型，技术路径和常见的 VLA 有所区别。先在隐空间预测环境会怎么变化，再生成动作。
眼下，GPT-6 Astra 这类通用模型给行业带来不少热议与焦虑，很多人会提到「吞噬论」：通用大模型的理解与规划能力持续跃升，专门的具身中间层、端侧具身模型，会慢慢失去存在意义。
但来杰认为，物理世界的底层约束，注定云端大模型无法包揽全部闭环工作。通用智能和具身智能不是对抗关系，而是一种伙伴关系，有着同等价值，需要各司其职，携手共进。
他常拿一个生活化的场景打比方：就算妈妈在远程视频里指挥他炒菜，能告诉他什么时候放盐、火开大一点、翻炒几下，却没办法替他感受锅铲碰到食材的阻力、微调手腕发力的轻重，也没法实时避开突然滑向锅边的菜。
用这个分工去对应机器人系统，通用大模型如同远端的决策者，擅长抽象推理、长期任务拆解、读懂人类模糊的诉求。
受限于网络延迟、带宽瓶颈、端侧算力与功耗约束，它很难高频处理力反馈感知、微姿态校正、毫秒级避障这类紧贴物理交互的闭环任务。
这部分本地化的感知、调整与控制，就是基座模型和控制系统承接的范畴。
好比一个人收到远方给出的行动方案，最终精细的手部操作、平衡维持，依旧依靠本体感知与小脑的即时调节，远端大脑很难代劳。
来杰对各家通用大模型保持开放兼容的态度，但并不把外部大模型当成唯一的核心。
反过来，机器人持续交互沉淀下来的物理因果数据，既是具身基座模型迭代的养料，也能供给通用大模型补齐文本数据缺失的物理因果认知短板。
与此同时，他对全栈的边界也很清楚：全栈不等于凡事自己做。
星尘智能坚持自研本体与具身模型基座，是因为物理执行层的实时闭环能力无法完全外包；高层意图理解、创意层面的规划，既可以交给自研基座模型，也可以交给目前更擅长这件事的外部通用大模型。
两者更像协作链路，谈不上零和博弈。
他并不忌惮大模型挤占自身空间，反而期待上层规划能力更快突破。上层智能越强，这套从一开始就为 AI 准备好的底座，价值释放的速度就越快。
别等什么都完美再做生态
从接口再往外看，绕不开生态。
来杰常拿苹果作参照，但他真正想借鉴的，并不是苹果同时做硬件、操作系统和应用商店这件事本身。
更重要的是，苹果逐渐建立起了一种关系：平台提供基础能力和开发工具，开发者创造应用，用户使用应用，创造者也有机会从中获得回报。
App Store 于 2008 年上线后，第三方应用逐渐成为苹果生态的重要组成部分。
那么，机器人行业能不能走出类似的路径？
很多人肯定会抱有疑问，现在机器人本体还不够成熟，成本、稳定性和场景适应能力都有待提升，这时候谈开放开发者生态为时尚早。
这个质疑当然是有道理的。
毕竟机器人要在真实环境中执行动作，硬件和控制能力如果不够可靠，应用再多也难以稳定交付。
但反过来看，如果所有功能都要等厂商逐一开发，机器人能够覆盖的场景也会受到限制。
星尘智能的想法，是让本体、模型和 AOS 同步演进，把开发者生态放进硬件成熟的过程里，不等硬件完全成熟后再补课。
这并不意味着现在就已经有了成熟的机器人应用市场。
目前，星尘智能的收入仍主要来自机器人本体、研发工具和面向商业客户的软件服务：既为研发用户提供 SDK 等开发工具，也为部分商业客户提供二次开发能力。
T1 起售价 8.99 万元，硬件毛利并不厚，软件和工具服务的毛利更高。
比如在导览应用中，客户可以利用工具记录地图、轨迹和动作，再根据实际运行情况进行补充和迭代。
这类业务说明机器人软件工具已经有比较具体的使用场景，但离开放的 App 生态仍有距离。
前者通常围绕明确的用户和需求展开；后者则要求更多开发者能够独立创造应用，用户也能找到并采用这些应用。
对于平台来说，除了让开发者更容易完成开发，还要让应用能够被发现、被使用，甚至让创造者获得合理的商业回报。
星尘智能希望未来能进一步连接这两端。用户提出需求，开发者尝试实现，平台提供工具和分发支持，让有价值的应用有机会沉淀下来。
不过，机器人生态并不能照搬手机应用市场的做法。
手机软件主要运行在相对标准化的数字环境中，机器人应用却必须面对具体的物体、动作和场景。
一个应用在仿真环境里运行顺利，不代表它换一个环境也能稳定工作；一次演示成功，也不等于它已经具备长期交付能力。
所以，AOS 能不能成为有价值的平台，不只取决于接口是否开放，还要看它能否让开发者更快地把应用做出来，并且在真实场景中持续运行。
对星尘智能来说，黑客松是一种测试方式。
开发者提出的需求、模型在开发过程中遇到的问题，以及应用从仿真迁移到真机时暴露的差异，都能反过来帮助平台迭代。
开发者不必等平台完全做好再进入，他们在使用过程中也在参与平台的完善。
这里也有一条现实的商业逻辑：不是每家公司都需要亲自为所有场景开发应用。
如果平台足够好用，第三方团队就有机会围绕特定需求做产品，机器人公司则可以从本体销售之外，获得开发工具和软件服务的持续价值。
但这条路还需要慢慢验证。
现阶段，星尘智能的开发工具已经服务于部分科研和商业客户，面向普通用户的大规模应用生态仍是远期目标。
它能否实现，最终要看有多少真实需求被满足，有多少开发者愿意持续投入，以及应用能不能带来足够明确的价值。
Demo 之后，
才是真正考验机器人的时候
从本质上看，黑客松上做出一个机器人应用，和把它变成长期可用的产品，中间还有不少问题要解决。
首先是需求能不能被真正理解。用户通常知道自己想要什么结果，却未必能说清楚每一步应该怎么做。
比如帮我收拾桌面，听起来很明确，但机器人还需要知道哪些东西不能动、物品应该放在哪里，以及用户喜欢什么样的整理方式。
来杰提过一个很生活化的设想：面对家里有点乱，机器人不应该马上动手，或者直接收拾成像军队里一样的整齐一致，而可以先问用户希望怎么整理、喜欢什么风格，再根据选择去完成任务。
更重要的是，机器人在执行之前先理解人的偏好。听懂指令只是第一步，理解偏好才决定体验。
其次是真机运行。仿真可以让开发者更快测试逻辑，却无法覆盖真实环境中的所有变化。
物体摆放、接触状态和动作偏差，都可能影响最后的执行结果。机器人既要知道下一步该做什么，也要能判断动作有没有成功、发现问题后如何调整。
最后是应用能否持续使用。某个 Demo 即使很有趣，也未必值得做成产品。
它是否解决了真实问题，用户会不会反复使用，执行是否稳定，以及后续维护成本是否合理，都会影响它的商业价值。
这几个问题也说明，降低开发门槛更像起点。
AOS 可以帮助用户把创意变成初步应用，但应用最终能不能成立，还取决于机器人本体和模型能否稳定地完成任务。
这也是为什么星尘智能不能只做软件。工具再好，也需要底层能力作为支撑；反过来，硬件能力再强，如果调用复杂、应用开发门槛过高，也很难自然延伸到更多场景。
来杰也提到，机器人本体的能力并不意味着应该不加限制地全部开放。速度、力度、损耗风险和安全边界，都需要根据产品形态与使用场景来考虑。
机器人真正变得有用，既要看它能做到什么，也要看它能否在合适条件下安全、稳定地做到。
对 AOS 来说，接下来要证明的也是同一件事：开发者能不能更容易地开发应用，模型能不能更准确地调用工具，真机执行能不能变得更可靠。
只有这些问题不断得到解决，黑客松里的创意才可能逐渐走出活动现场。
较早投入 AOS，与其说来杰已经看到成熟生态的全貌，不如说他相信开发工具和应用反馈会推动机器人能力继续进化。
开发者越能接触真实场景，平台越有机会发现自己的短板；平台越可靠，新的开发者和应用才越容易留下来。
这条路没有一个可以靠口号跳过去的阶段。它既需要硬件、模型和工具持续打磨，也需要真实的用户需求不断检验。
回到最初的 A or B 选择题，机器人本体和通用大模型当然都重要。
但如果只看谁的身体更强、谁的推理更聪明，仍然没有回答一个关键问题：这些能力如何在真实世界里配合起来，又如何被更多人用来解决问题？
星尘智能想借 AOS 补上的，就是这段距离。
它最终能不能搭起一座真正有用的桥，要看桥的两端是否足够可靠，也要看有多少人愿意走上来，并在上面创造新的东西。
