上市以后王兴兴需要反复向外界解释宇树“还不是什么”。这句话听起来像公关话术但在技术公司里它其实是一道严肃的技术产品管理题。当一家机器人公司从创业阶段进入资本市场视野外界对它的理解会迅速滑向两个极端要么认为它无所不能要么认为它不过如此。创始人反复解释的“还不是”恰恰是在校准技术预期把产品能力从想象拉回工程现实。这里不讨论股价和资本运作而是从技术产品化的角度拆解一个问题为什么科技公司越是被公众关注越要主动划清能力边界机器人企业又该如何用工程方法把“边界声明”变成可验证、可维护、可对外沟通的技术文档。1. 为什么技术公司上市以后要反复解释“自己还不是什么”1.1 预期差是技术公司上市后面临的第一道鸿沟上市以后公司要同时面对投资者、媒体、客户、开发者和普通用户。这些群体使用完全不同的信息模型。投资者关注增长空间媒体关注新闻性客户关注能用在哪开发者关注 SDK 和接口。同一个“我们的机器人具备自主导航能力”在不同听众那里会被放大成完全不同的含义。如果不主动解释边界市场会默认把“技术演示”等同于“产品交付”。在机器人行业这种预期差会被显著放大。四足机器人可以完成爬楼梯、跳跃人形机器人可以做动作展示这些视频传播很快但视频没有体现操作员干预率、场景约束、任务成功率、电池续航和前后失败次数。于是“可以完成”和“只能在该条件下完成”被混为同一个产品事实。上市以后任何一句不完整的表达都可能进入研报和会议纪要因此边界澄清不是谦虚而是风险控制。1.2 边界澄清本质上是一种技术债务管理技术债务不只是代码问题也包括产品承诺与工程实现之间的差距。团队对外说“支持室内外巡检”但真实系统只在特定场地、特定光照、特定网络条件下稳定工作这个承诺就会变成技术债务。售后团队、算法团队、测试团队都要为过宽承诺买单。上市以后这种债务的利息会变高因为外部用户和投资者会把承诺写进合同或预期。创始人说“我们还不是某个平台”听起来像是在回应质疑实际上是在主动降低技术债务。更稳妥的做法是在技术文档、产品手册、销售话术里同步使用边界声明让所有部门引用同一套事实。边界越模糊后续修复成本越高。边界越清晰研发、测试、销售、售后反而更容易对齐。1.3 机器人行业为什么更依赖边界表达机器人是软硬件一体的复杂系统能力边界由硬件规格、算法成熟度、场景数据共同决定。四足机器人可以在结构化工厂里执行巡检但未必能在泥泞工地连续工作八小时人形机器人可以完成抓取演示但未必具备持续操作的自主闭环。边界表达因此不是品牌包装而是系统能力的真实描述。如果没有边界表达用户会把通用人工智能的想象投射到专用机器人上后面所有技术沟通都会失真。技术团队需要明确告诉外界当前系统在什么条件下、完成什么任务、达到什么指标以及在什么条件下会失效。只有把“任务边界”讲清楚机器人的能力才能被正确使用。2. 产品定位先于代码先用“能力矩阵”画出当前边界2.1 能力矩阵的维度要讲清楚“是什么”和“还不是什么”团队内部需要一套共同语言。推荐使用能力矩阵。维度至少包括环境条件室内或室外、光照、天气、地面类型。运动能力行走、奔跑、爬坡、越障、上下楼梯。感知能力避障、建图、目标识别、语义理解。操作能力不带机械臂、带机械臂、抓取特定物体、精细装配。自主程度遥控、半自主、任务级自主、全自主。连续性单次演示、10 分钟任务、8 小时连续运行。这些维度不能写成形容词要写成可测试的边界条件。“复杂地形”必须改成“20 厘米台阶、30 度斜坡、碎石路面”。能力矩阵一旦形成产品边界就不会散落在销售话术里而是成为产品定义的一部分。2.2 示例四足机器人的能力矩阵下面是一个用于说明思路的能力矩阵示例实际项目需要根据产品形态重新填写。能力维度当前已确认部分验证明确不支持环境室内平坦地面、室外水泥路雨天短时运行泥泞湿地连续作业运动每小时 3-5 公里爬坡 15 度20 厘米以上台阶跳跃后稳定落地感知激光雷达避障、视觉导航动态人群密集区域夜间无光照环境自主按路线巡检、自主回充电桩多任务顺序执行未知环境自主探索这个矩阵不是最终答案。每一行都应该对应一份测试记录、一段测试日志和边界条件说明。这样“还不是什么”就不是一句口号而是记录在案的技术结论。2.3 从能力矩阵推导技术选型边界澄清会影响技术选型。如果产品定位是“工厂巡检”机械结构、传感器配置、算法优化都会围绕可靠性设计不需要追求全场景通用。如果定位是“科研平台”则要开放接口、允许二次开发甚至接受一定概率的不稳定。常见错误是希望一个产品同时满足行业客户、开发者、投资者三类人的需求结果边界过度膨胀。能力矩阵能帮助团队在需求评审时说出“不”这个需求在目标边界外本期不做。这是最高效的边界澄清。没有边界的选型最后一定会变成各个部门互相妥协的产物。3. 技术系统里“能做”和“还不能做”要靠什么证据支撑3.1 三层边界运动控制、感知、决策机器人系统的能力边界分布在三个层面。运动控制层决定能否保持稳定步态、能否完成轨迹跟踪感知层决定能否识别障碍物、目标和语义决策层决定能否在不确定环境中自主规划。三层成熟度通常不一致运动控制可能很成熟感知在特定场景过拟合决策还依赖人工确认。对外解释边界时要分别说明每一层达到了什么状态而不是笼统说“机器人能力很强”。例如四足机器人在实验室可以爬上特定高度的台阶但算法可能是针对该台阶尺寸调过参的。换一个台阶高度和材质感知层可能就会失效。团队必须把“我们做过这个环境”和“系统在新环境中能泛化”区分开泛化程度只能用跨环境测试数据回答。3.2 用指标而非形容词定义边界定义边界时应使用可量化指标包括但不限于任务成功率、平均干预次数、平均故障间隔时间、单次连续运行时长、目标识别准确率、定位误差、恢复时间。可以这样表述不要说“稳定运行”要说“在实验室标准场景下连续运行 4 小时全程人工干预不超过 1 次”。不要说“识别准确”要说“在自建 1000 张样本集上目标识别 F1 达到 0.92未见过的样本效果待测试”。不要说“自主充电”要说“在指定地图中电量低于 30% 时自动导航至充电桩测试成功率 100 次 / 100 次”。这些指标不是宣传文案而是边界证据。上市以后外部人会引用这些指标因此所有指标必须能追溯到测试环境、测试日期和测试记录。3.3 场景验收表把“演示成功”变成“稳定可用”演示成功只证明一个样本稳定可用需要一个验收表。下面是一个简化的场景验收表。项目测试条件验收标准当前结果室内巡检80 平米办公室固定路线光照 200-500 lux10 次任务 9 次成功无需人工干预待测试室外避障200 米跑道放置 5 个障碍物完成 3 次往返无碰撞待测试长时间运行连续 4 小时运行温度不超过阈值无宕机待测试每个“当前结果”必须来自测试记录可以通过基准测试、日志和录屏存档。对外说“我们支持”之前先确认有没有对应的场景验收表。没有就改口为“规划中”或“部分验证”。4. 从演示视频到工程承诺技术传播中的翻译规则4.1 演示视频为什么容易越过产品边界演示视频天然省略掉三个信息操作员干预、场景限制、失败样本。观众看到成功轨迹没看到后台有人随时准备停机。这个问题在机器人行业尤其突出因为机器人动作具有视觉冲击力观众很容易用“它能做到”替代“它在这个视频条件下能做到”。技术公司需要主动为视频加边界说明例如这段演示是否遥控、是否多机位剪辑、是否连续拍摄、失败了几次。很多“出圈”视频让公司获得关注也让技术边界被扭曲。上市以后视频传播的边际收益递减边界失控的边际成本递增因此技术团队要在外发前补上边界信息。4.2 把宣传语言翻译成工程语言的对照表宣传语言潜在含义工程语言应该补充具身智能与环境交互的智能体当前感知和决策的自主程度全球领先某项指标排名靠前具体指标、测试集、时间可以客户部署已有方案部署条件、现场改造成本自主任务无需人工定义任务范围给出干预率全地形许多地形列举通过的地形和边界条件这张对照表应该由市场部和技术部共同维护。对外宣传口径中的任何技术性断言都应能从工程文档里找到证据。找不到就降级为“目标方向”。4.3 对外文档中的边界声明怎么写对外技术文档建议包含三部分已经确认能力、正在验证能力、明确不支持场景。一个边界声明模板如下。当前版本边界声明版本v0.9 已确认 - 在室内结构化环境中可自动避障测试通过率 95% 以上。 - 支持 15 度坡面行走电池续航不低于 2 小时。 部分验证 - 室外夜间灯光条件下的避障能力测试样本有限。 明确不支持 - 不具备跨楼层自主建模与导航能力。 - 不保证在雨雪天气连续运行。这个声明需要随版本更新。每次发布新版本都要检查边界是否移动。无法继续支持的旧能力要在版本说明中明确写出。5. 上市以后技术团队会遇到的新约束与新的输入5.1 合规披露对技术宣传的约束上市以后公司对外披露需要更加谨慎。技术宣传中的过度承诺可能被理解为对客户的误导也可能引发监管关注。这不是说不能宣传技术而是所有技术能力必须有测试数据和版本编号作为支撑。公司需要建立“技术能力声明分级”哪些可以在官网写哪些只能写在白皮书里哪些只能在会议中口头确认。分级规则由法务、市场、技术共同维护。工程团队不必逐字审稿但要在源头上提供准确的边界清单。没有边界的宣传语越到后期越难纠正。5.2 投资人问题如何反向影响技术路线图上市以后投资人和分析师会问“什么时候量产”“什么时候盈利”“人形机器人什么时候进入家庭”。这些问题本质上是在问“边界什么时候扩大”。技术团队必须能够回答边界扩大的依赖条件需要多少数据、需要多少测试、生产良率多少、核心零部件成本如何变化。如果回答不了技术路线图就会变成拍脑袋时间表。比较可信的回答方式是先把当前边界列出来再说边界扩张需要完成哪些验证、预计在哪个版本实现而不是给一个乐观日期。从技术边界到时间表的推导逻辑比时间表本身更重要。5.3 建立内部技术边界审查机制建议在发布流程里增加边界审查。所有涉及外部传播的技术内容都先经过技术边界清单审核。责任人不只是市场部而应有一个技术传播负责人通常来自 CTO 办公室或技术管理部。审查内容包括是否有测试数据数据是否过期是否包含明确不支持的能力是否区分实验室与真实场景是否标注版本。这样当创始人在公开场合说“我们还不是 XX”时不是临场解释而是预设边界管理的一部分。6. 用文档、测试和接口定义支撑对外边界表达6.1 能力清单文档应包含哪些内容能力清单不是宣传册而是一个可追踪的工程文档。建议字段如下能力编号CAP-001能力名称室内点到点自主导航版本v0.9测试环境设备型号、传感器配置、地图、光照测试指标成功率、平均耗时、最大路径偏差测试记录链接边界条件不支持高动态场景、不支持地图快速变化负责人这个文档应当使用版本控制。对外宣传时引用能力编号公众可以查询对应的测试记录。不要让你的“能力清单”散落在聊天记录和邮件里。6.2 用基准测试数据固化边界证据为了支撑边界建议建立内部基准数据集和任务基准。基准集要包含标准场景、干扰项、失败样本和边缘条件。每次算法变更后跑同一套基准把指标变化记录到能力文档。这个做法可以让“边界变了”变得可见。例如某算法升级后夜间成功率从 70% 升到 90%边界声明就可以更新。同时基准集要防止过拟合如果团队只对着基准集调参指标会失真因此需要定期加入盲测场景。基准数据必须注明采集时间和采集环境。6.3 对外接口增加能力声明与错误码对外 SDK 或 API 设计也可以体现边界。一种做法是在接口返回中增加能力声明字段示例结构如下{ success: true, task_id: task_20250101_001, capability: { code: CAP-001, name: indoor_navigation, version: 0.9.0, boundary: { indoor_structured: true, max_floor_change: 0, need_given_map: true } }, message: task scheduled }返回中的boundary字段可以让调用方在运行时检查能力边界而不是等到任务失败才知道不支持。错误码也应有边界相关条目例如E_BOUNDARY_UNSUPPORTED请求任务超出当前能力清单。E_SCENE_UNVERIFIED当前场景未在验证列表中。E_MAP_NOT_FOUND需要地图但未提供。这样边界不只是文本声明而是接口契约的一部分。6.4 版本发布时同步更新边界声明每个技术版本发布时边界声明应该作为发布物料的一部分。参考做法是在 Release Notes 中新增一节“能力边界变化”列出新增能力进入 v0.10.0。能力增强指标从 X 变为 Y。能力收缩由于硬件变更暂时不支持 Z。边界声明与版本号绑定可以解决“同一个产品不同客户听到不同说法”的问题。对机器人公司尤其重要因为 OTA 升级后现场行为可能发生变化。7. 常见的边界模糊陷阱与排查路径7.1 典型问题现象与排查思路现象可能根因检查方式处理建议客户要求覆盖未承诺场景产品宣传过宽或未标注边界检查对外文档和销售话术补充边界声明提供现场验证方案演示成功但交付后频繁失败验收时没有覆盖真实场景对比测试条件与现场环境建立场景验收表运行小规模试点多个部门对“能不能做”说法不一没有统一能力清单查版本发布记录和能力文档建立单一事实源算法升级后旧能力消失没有版本回归测试跑历史基准集以基准集指标判断能力变化7.2 陷阱一只有演示没有验收标准很多团队在内部评审时只看演示视频然后默认产品目标已经满足。结果到了客户现场环境变化算法失效。原因是“试验成功”与“任务成功”定义不清晰。建议每个演示任务都写一个验收卡。测试时由非算法工程师操作记录干预次数、失败次数和环境参数。没有验收卡的演示不能作为能力声明的证据。演示视频可以用于内部沟通但不能直接进入对外承诺。7.3 陷阱二技术原型被当作支持的产品功能当技术原型在实验室表现好时销售和媒体会提前把它定义成产品功能。此时工程团队如果保持沉默边界就会失控。解决方案是在原型阶段使用明确标识例如 “research preview”“not for production”并在所有材料中加版本水印。对外可以说“我们看见了可能性”但不能说“我们支持这个功能”。原型与量产产品之间隔着可靠性、成本、工艺、认证和环境适应性没有完成这些验证之前能力边界不应扩大。7.4 陷阱三不同部门对“能实现”的理解不一致算法团队说的“能实现”是指在某个模型上跑通测试团队说的“能实现”是指有可重复的测试报告商务团队说的“能实现”是指能签进合同。三者在没有统一标准时会产生边界漏洞。建议定义三层语义POC 验证、受控场景可用、规模化交付可用。所有部门在沟通时先声明语义层级避免用同一个动词表达不同的边界。这样可以在源头上减少错位。8. 技术叙事管理最佳实践边界清晰反而更有竞争力8.1 对外叙事保持可验证边界清晰不等于弱化宣传。相反能把“支持什么、不支持什么、当前验证到什么程度”说清楚的团队比只会喊“全地形自适应”的团队更容易获得客户信任。技术产品采购决策往往依赖可验证证据。对外公布的每个能力都应该对应到能力编号、版本和测试指标。如果没有就不要写进官网。可验证的信息会积累信用而模糊的推销只会增加后续沟通成本。8.2 对内技术规划保持边界更新节奏边界不是静态的。建议每季度修订一次能力矩阵每次发布更新边界声明。修订时回答三个问题哪些边界被验证了哪些边界被推后了哪些边界因硬件换代而改变。这样“还不是什么”会随时间自然演化。创始人的对外解释也应该基于这份定期更新的文档而不是临时组织回答。边界更新也是技术规划的一部分不是市场部的文案工作。8.3 给研发团队一个“安全表达边界”的通道工程团队往往不敢说“这个不支持”因为担心被市场部认为是负面信息。实际恰恰相反越早承认边界越能避免过度承诺后的灾难。公司应建立“边界反馈”机制任何工程师发现演示条件与真实场景不一致可以直接向技术传播负责人报告。这个通道应该被保护和鼓励。边界管理是全员工作不只是管理层的事。来自一线工程师的反馈往往比高层判断更接近真实系统能力。8.4 上市技术公司边界管理检查清单这是一个可复用的自查清单适合在每个发布周期和对外宣传前使用官网能力页面是否能追溯到能力编号和版本所有对外产品视频是否标注是否遥控、干预次数、失败次数销售合同中的技术承诺是否经过技术边界审查是否有超过 6 个月未更新的能力清单文档所有算法升级是否都运行了历史基准集是否明确标注了“明确不支持”的场景每个版本的 Release Notes 是否包含边界变化研发团队是否有直接反馈边界过宽或过窄的通道创始人对外解释“我们还不是什么”时是否有内部文档支撑是否区分了 POC 验证、受控场景可用、规模化交付可用回到标题里的那句话。“上市以后王兴兴更要反复解释宇树‘还不是什么’”表面上看是回应外界预期本质上是一个技术公司在不同发展阶段必须练好的基本功。技术边界不是公司的短板而是产品能够持续演进的基础。对任何做机器人、AI 或复杂软硬件系统的团队来说把“是什么”和“还不是什么”同时讲清楚是一件长期有复利的事情。研发团队要带头用指标、测试记录和版本文档来支撑边界声明。创始人反复解释的那一句话背后应该有一整套工程体系作为底气。
