企业官网建设流程全解析

上市以后，王兴兴需要反复向外界解释宇树“还不是什么”。这句话听起来像公关话术，但在技术公司里，它其实是一道严肃的技术产品管理题。当一家机器人公司从创业阶段进入资本市场视野，外界对它的理解会迅速滑向两个极端：要么认为它无所不能，要么认为它不过如此。创始人反复解释的“还不是”，恰恰是在校准技术预期，把产品能力从想象拉回工程现实。这里不讨论股价和资本运作，而是从技术产品化的角度拆解一个问题：为什么科技公司越是被公众关注，越要主动划清能力边界；机器人企业又该如何用工程方法把“边界声明”变成可验证、可维护、可对外沟通的技术文档。

1. 为什么技术公司上市以后要反复解释“自己还不是什么”

1.1 预期差是技术公司上市后面临的第一道鸿沟

上市以后，公司要同时面对投资者、媒体、客户、开发者和普通用户。这些群体使用完全不同的信息模型。投资者关注增长空间，媒体关注新闻性，客户关注能用在哪，开发者关注 SDK 和接口。同一个“我们的机器人具备自主导航能力”，在不同听众那里会被放大成完全不同的含义。如果不主动解释边界，市场会默认把“技术演示”等同于“产品交付”。

在机器人行业，这种预期差会被显著放大。四足机器人可以完成爬楼梯、跳跃，人形机器人可以做动作展示，这些视频传播很快，但视频没有体现操作员干预率、场景约束、任务成功率、电池续航和前后失败次数。于是，“可以完成”和“只能在该条件下完成”被混为同一个产品事实。上市以后，任何一句不完整的表达都可能进入研报和会议纪要，因此边界澄清不是谦虚，而是风险控制。

1.2 边界澄清本质上是一种技术债务管理

技术债务不只是代码问题，也包括产品承诺与工程实现之间的差距。团队对外说“支持室内外巡检”，但真实系统只在特定场地、特定光照、特定网络条件下稳定工作，这个承诺就会变成技术债务。售后团队、算法团队、测试团队都要为过宽承诺买单。上市以后，这种债务的利息会变高，因为外部用户和投资者会把承诺写进合同或预期。

创始人说“我们还不是某个平台”，听起来像是在回应质疑，实际上是在主动降低技术债务。更稳妥的做法是：在技术文档、产品手册、销售话术里同步使用边界声明，让所有部门引用同一套事实。边界越模糊，后续修复成本越高。边界越清晰，研发、测试、销售、售后反而更容易对齐。

1.3 机器人行业为什么更依赖边界表达

机器人是软硬件一体的复杂系统，能力边界由硬件规格、算法成熟度、场景数据共同决定。四足机器人可以在结构化工厂里执行巡检，但未必能在泥泞工地连续工作八小时；人形机器人可以完成抓取演示，但未必具备持续操作的自主闭环。边界表达因此不是品牌包装，而是系统能力的真实描述。

如果没有边界表达，用户会把通用人工智能的想象投射到专用机器人上，后面所有技术沟通都会失真。技术团队需要明确告诉外界：当前系统在什么条件下、完成什么任务、达到什么指标，以及在什么条件下会失效。只有把“任务边界”讲清楚，机器人的能力才能被正确使用。

2. 产品定位先于代码：先用“能力矩阵”画出当前边界

2.1 能力矩阵的维度

要讲清楚“是什么”和“还不是什么”，团队内部需要一套共同语言。推荐使用能力矩阵。维度至少包括：

• 环境条件：室内或室外、光照、天气、地面类型。
• 运动能力：行走、奔跑、爬坡、越障、上下楼梯。
• 感知能力：避障、建图、目标识别、语义理解。
• 操作能力：不带机械臂、带机械臂、抓取特定物体、精细装配。
• 自主程度：遥控、半自主、任务级自主、全自主。
• 连续性：单次演示、10 分钟任务、8 小时连续运行。

这些维度不能写成形容词，要写成可测试的边界条件。“复杂地形”必须改成“20 厘米台阶、30 度斜坡、碎石路面”。能力矩阵一旦形成，产品边界就不会散落在销售话术里，而是成为产品定义的一部分。

2.2 示例：四足机器人的能力矩阵

下面是一个用于说明思路的能力矩阵示例，实际项目需要根据产品形态重新填写。

这个矩阵不是最终答案。每一行都应该对应一份测试记录、一段测试日志和边界条件说明。这样“还不是什么”就不是一句口号，而是记录在案的技术结论。

2.3 从能力矩阵推导技术选型

边界澄清会影响技术选型。如果产品定位是“工厂巡检”，机械结构、传感器配置、算法优化都会围绕可靠性设计，不需要追求全场景通用。如果定位是“科研平台”，则要开放接口、允许二次开发，甚至接受一定概率的不稳定。

常见错误是希望一个产品同时满足行业客户、开发者、投资者三类人的需求，结果边界过度膨胀。能力矩阵能帮助团队在需求评审时说出“不”：这个需求在目标边界外，本期不做。这是最高效的边界澄清。没有边界的选型，最后一定会变成各个部门互相妥协的产物。

3. 技术系统里，“能做”和“还不能做”要靠什么证据支撑

3.1 三层边界：运动控制、感知、决策

机器人系统的能力边界分布在三个层面。运动控制层决定能否保持稳定步态、能否完成轨迹跟踪；感知层决定能否识别障碍物、目标和语义；决策层决定能否在不确定环境中自主规划。三层成熟度通常不一致：运动控制可能很成熟，感知在特定场景过拟合，决策还依赖人工确认。

对外解释边界时，要分别说明每一层达到了什么状态，而不是笼统说“机器人能力很强”。例如，四足机器人在实验室可以爬上特定高度的台阶，但算法可能是针对该台阶尺寸调过参的。换一个台阶高度和材质，感知层可能就会失效。团队必须把“我们做过这个环境”和“系统在新环境中能泛化”区分开，泛化程度只能用跨环境测试数据回答。

3.2 用指标而非形容词定义边界

定义边界时应使用可量化指标，包括但不限于：任务成功率、平均干预次数、平均故障间隔时间、单次连续运行时长、目标识别准确率、定位误差、恢复时间。可以这样表述：

• 不要说“稳定运行”，要说“在实验室标准场景下连续运行 4 小时，全程人工干预不超过 1 次”。
• 不要说“识别准确”，要说“在自建 1000 张样本集上，目标识别 F1 达到 0.92，未见过的样本效果待测试”。
• 不要说“自主充电”，要说“在指定地图中，电量低于 30% 时自动导航至充电桩，测试成功率 100 次 / 100 次”。

这些指标不是宣传文案，而是边界证据。上市以后，外部人会引用这些指标，因此所有指标必须能追溯到测试环境、测试日期和测试记录。

3.3 场景验收表把“演示成功”变成“稳定可用”

演示成功只证明一个样本，稳定可用需要一个验收表。下面是一个简化的场景验收表。

每个“当前结果”必须来自测试记录，可以通过基准测试、日志和录屏存档。对外说“我们支持”之前，先确认有没有对应的场景验收表。没有，就改口为“规划中”或“部分验证”。

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 或复杂软硬件系统的团队来说，把“是什么”和“还不是什么”同时讲清楚，是一件长期有复利的事情。研发团队要带头用指标、测试记录和版本文档来支撑边界声明。创始人反复解释的那一句话，背后应该有一整套工程体系作为底气。