上个月我们团队的镜像视界空间智能体项目进入终期评审。上午十点三位评审专家坐定投影仪上已经打出系统的运行界面我面前摆着一沓测试报告。事先说好的流程是先演示十五分钟再问答结果演示刚结束第一位专家就抛出了问题之后整整六个半小时几乎没有停过。我们做的这套系统简单说就是给机器人装上一套会思考的空间感知系统——它不只知道自己在哪、墙在哪还要能回答这个房间里有什么、这些东西能不能用、怎么用。目标场景是室内服务机器人、数字孪生巡检和复杂环境下的人机协作。三位专家分别来自计算机视觉、机器人系统、人机交互安全三个方向等于三把不同角度的刀把系统从感知层到决策层到合规层全部拆开审了一遍。评审结束后我们把这18个问题和当时的回答整理成了这份18问18答。里面不少回答是硬着头皮讲完的现在回头看看恰恰成了整个项目最值钱的素材。1. 评审是怎么发生的镜像视界的定位与专家阵容1.1 镜像视界空间智能体到底做了什么镜像视界空间智能体名字里最容易被误会的部分是镜像两个字。很多人以为它是做3D重建的把物理空间扫描成点云和网格做成数字孪生模型。这只是一部分而且是相对基础的一部分。我们真正要解决的是空间理解问题。传统空间感知只回答几何问题墙在哪、障碍物在哪、我当前位姿是多少。镜像视界要在此基础上叠加两层能力。第一层是语义镜像把几何空间里的点云、栅格变成这里有张桌子、那边是厨房区域、地面材质是深色反光地砖这样的结构化描述。第二层是关系镜像回答物体之间什么关系、能拿来做什么这张椅子面对着桌子可以拉出来坐这个抽屉是关着的可以打开这扇门通向走廊but门把手在右侧。三层加在一起才配叫视界。这套系统并不只是算法Demo而是跑在真实机器人平台上的完整方案包括感知端、决策端、执行端三块。感知端负责建图和语义标注决策端负责导航规划和任务拆解执行端负责把高层指令落到电机和机械臂的关节运动上。评审现场演示的核心场景是让机器人听懂把桌上的杯子放到厨房台面上这句自然语言自主完成目标识别、路径规划、抓取和放置。演示本身成功了但接下来的问答才是真正的考验。1.2 评审规则、专家构成与18问的分布这次评审虽然没有严格的不许答错的考核机制但专家的提问方式本身就是压力测试。他们事先看过了我们的技术报告和测试数据所以问的问题几乎全部指向报告里的薄弱环节和未写明的假设。三位专家的分工很清晰。做计算机视觉的专家盯感知真实性专挑反光、遮挡、动态场景这些视觉老问题下手。做机器人系统的专家盯执行可靠性关心导航失败、重规划时机、传感器故障这类工程问题。做人机交互安全的专家盯边界问题问的是隐私、责任、降级策略和伦理兜底这一类问题是现场气氛最凝重的部分。18个问题的分布如下问题组别问题数量专家关注点现场感受空间感知4问建图方式、场景更新、大场景管理、恶劣环境自信心尚可个别回答被追问到细节导航与交互4问指令拆解、路径规划、冲突决策、安全执行压力最大因为每一个都是真实场景高频问题架构与部署4问端云协同、传感器选型、模型压缩、领域鸿沟被反复问为什么考验选型逻辑边界与合规6问幻觉纠正、降级路径、数据隐私、责任边界多数时候在诚实说我们做得不够问答从上午十点持续到下午四点半中间只有午饭的二十分钟。我把每一问都还原成了原始语境包括专家提问时的前置铺垫因为脱离语境的问答会丢掉一半信息量。2. 空间感知答辩四个问题决定镜像成色2.1 问1你和传统SLAM的本质区别在哪里专家第一个问题没有问算法细节而是问了一个看起来像是送分题的问题市面上成熟的SLAM方案那么多你们这套东西跟它们到底有什么本质区别如果只是多挂了一个语义分割网络那叫锦上添花不叫空间智能体。我当时的回答分了三层。第一层传统SLAM输出的是一张几何地图点云、栅格、位姿机器人拿着它能回答我在哪儿。第二层我们对这个几何地图做了结构化语义注入让地图的每个区域、每个物体都有了标签和属性机器人能回答这儿有什么。第三层是关系层这也是最关键的一层我们把物体之间的空间关系、功能可供性直接建模进地图里机器人能回答这个东西能拿来做什么。举个现场例子说明这三层差距同一张办公室地图普通SLAM告诉机器人前方1.2米处有一组点云高度0.45米语义地图告诉它前方有一张椅子而镜像视界的关系层告诉它这是一张带滚轮的办公椅可以推离桌边坐下后承重正常但不建议站在上面。最后这句话才是空间智能的体现因为它是可计算的、可推理的不是预先写死的规则。专家接着追问了一句关系层的知识是标注出来的还是自动学习的这个问题问到了关键。我如实回答一部分来自预训练模型的常识推理一部分来自人工标注的规则库。专家点头没再追问但我自己知道关系层的自动化推理能力目前只覆盖了室内常见家具超出这个范围就会退化这是后话。2.2 问2动态场景的状态更新怎么保证实时第二个问题来自机器人系统方向的专家你的语义地图是离线建好的现场一旦有人移动家具、有人走来走去这个地图多久能反映变化如果更新太慢机器人会按照旧地图撞上刚搬来的箱子。我们采用的是区域差分更新机制不是全图重新推理。系统持续做轻量级的场景变化检测比较当前帧与地图快照的差异。一旦某个区域被判定为发生了显著变化就把这个区域裁剪出来单独重新做语义推理更新局部地图同时向后端同步一个场景变更事件。这样做的好处是把更新成本从整张地图降到变化的那一小块。实测数据是单人从一个房间走到另一个房间这类常规动态局部区域更新延迟大约150到300毫秒大件家具搬移这类大面积场景变化会把整个房间标记为待重推理耗时一到两秒。专家对这个数字没有不满但追问了一句如果机器人本身在快速移动边移动边更新还能保证这个延迟吗答案是做不到。速度超过每秒两米时动态场景的语义更新会出现明显滞后我们目前的策略是优先保证几何避障语义更新放到低速或停稳后再做。这是写在产品说明书里的已知限制至少我们没藏着。2.3 问3大场景数据超预算了怎么收场第三个问题很工程化一栋大型展馆的原始空间数据可能有几十个GB你的语义地图要在嵌入式设备上常驻内存怎么扛得住这是每个做空间智能的团队都会被问到的现实问题。我们的答案是分层空间记忆思路类似于人脑的海马体。全局拓扑地图只保留房间节点、走廊连接、区域语义摘要这一层很小几十KB就够。局部稠密地图按需加载机器人靠近哪个区域就把哪个区域的细粒度语义数据调入内存离开之后非热点区域压缩落盘而不是一直占着内存。关键帧管理也在做同样的取舍对位姿优化贡献很小的冗余帧会被合并掉只保留信息量最高的关键帧。当时现场给专家的数字是某大型展馆场景原始点云和RGB-D帧数据加起来约40GB经过分层压缩后常驻内存约2.8GB可以在中端边缘设备上跑。这个数字不算漂亮但胜在诚实。专家听完只提醒了一句热点区域调度要做好预取策略别等机器人到了门口才开始加载地图否则每次跨区域都是一次卡顿。这个提醒我们后来真的踩了坑后面细说。2.4 问4镜面反光、暗光、雨雾里镜像还成立吗第四个问题扎在名字上你们叫镜像视界那镜面反光这种场景你们天然应该是强项才对吧结果呢我硬着头皮承认镜面恰恰是我们最大的短板之一。镜子会产生幽灵几何深度传感器在镜面上测到的距离会被反射物干扰算法会把镜子里的走廊误判成真实存在的通路导航直接撞向镜面。玻璃幕墙则是另一个极端透明材质导致深度空洞明明有墙却测不到。这两个问题我们内部处理了很久目前的对策是三板斧置信度地图标记低可信区域多视角融合让不同角度互相验证时间序列滤波把一闪而过的假几何剔除掉。暗光和雨雾的情况类似。RGB-D相机在暗光下深度噪声急剧上升雨雾环境则直接失效。我们的选择是明确声明适用边界室内照明正常环境是主战场暗光场景降级为保守导航模式雨雾场景不做承诺。专家对这个回答的评价是能说清楚哪里不行比含糊地说都可以更让人放心。但她也补了一句希望看到我们针对镜面场景做专门的反射判定模块而不是只靠通用滤波兜底。这个建议最终进了我们的迭代清单后面真的做了。2.5 这组问题背后专家在验证什么四个空间感知问题问完我大概摸清了视觉方向专家的套路她不关心你的网络结构有多新关心的是你的空间表征到底可不可信、更新的代价有多大、边界在哪里。这其实就是在验证一件事——镜像是不是一个可以被工程化的现实系统而不是论文里的一堆框图。从我们的角度这组问答最大的收获是明确了几何层、语义层、关系层这套分层设计的说服力。专家没有质疑分层的必要性反而一直在追问每一层的可信度和维护成本。这让我意识到空间智能体的核心难点从来不是单点算法而是如何让不同层级的空间表征保持一致、及时更新、可验证。3. 导航与交互答辩专家盯得最紧的执行链路3.1 问5一句自然语言指令如何变成机器人的动作第二组问题从演示场景切入。专家问刚才演示那句把桌上的杯子放到厨房台面上系统内部到底是怎么一步步执行的如果桌上有两个杯子你怎么知道用户指的是哪个我把执行链路拆成了六步指令解析、实体与空间锚定、行动原语生成、前置条件校验、执行、后置条件校验。指令解析阶段生成结构化的语义框架杯子是目标物体厨房台面是目标区域。实体锚定阶段系统在语义镜像中查找最匹配的杯子实例并且要求这个实例必须位于桌子的支撑区域内。行动原语生成阶段把高层指令拆成抓取原语、导航原语、放置原语三段。前置条件校验会检查杯子当前是否可抓取、目标台面是否还有空位、路径上有没有障碍。执行完成后还要做一次后置条件校验确认杯子确实离开了原来的桌子、放到了厨房台面整个任务才算闭环。至于两个杯子怎么区分我承认目前主要靠语义消歧的补充机制如果空间里存在多个同类候选系统会在交互界面上让用户确认或者结合用户的视线方向、手势指向来缩小范围。专家听完说了一句很中肯的话语义锚定是空间智能体从Demo走向产品的分水岭你现在能用场景约束缩小范围但下一步要处理的是说完指令后用户补一句不是那个是旁边的这种对话式纠偏能力目前还没有。她说得对这个能力排在我们下一阶段的计划里。3.2 问6长距离导航的分层规划与重规划时机第六个问题依旧很工程穿过多间房的远距离导航一个房间一个房间地规划还是直接来一条全局路径中途障碍物变化了多久重新规划一次我们的方案是三层规划。全局层用拓扑图计算房间级别的最优路径这条路径很粗不关心室内的桌椅。局部层在机器人进入每个房间后用稠密语义地图计算细致的通行路径绕开桌椅、门框、临时障碍。反应层是最后一道防线实时避障处理突然出现的人或移动物体。三层之间是级联关系全局路径给出方向约束局部路径负责具体走位反应层处理意外。重规划时机是评审讨论比较深的地方。我们的触发条件有三个局部代价地图里的障碍物占据预测路径超过一定时间、预测路径上的代价突变、机器人累计偏差超过阈值。专家追问重规划太频繁会不会导致路径抖动机器人原地转圈这个问题我们踩过坑。早期版本确实出现过绕来绕去的情况后来加了重规划冷却时间和代价平滑才把抖动压下去。实测数据是某写字楼一层约3000平方米的导航任务路径终点误差控制在15厘米以内全程重规划次数一般不超过五次。3.3 问7指令互相冲突时到底听谁的第七个问题很刁钻如果用户说全速冲过去但安全传感器检测到前方有人系统听谁的如果视觉观测和语义地图冲突比如视觉说走廊尽头是门地图说那是墙又听谁的我们制定了明确的优先级安全层高于任务约束任务约束高于用户指令。所以全速冲过去这句指令在被解析的瞬间就会因为前方有人而被降速执行系统会播报检测到前方行人正在减速而不是机械地执行最高速度。视觉观测和语义地图冲突时默认采信时间戳更新的观测数据同时在图上标记一处冲突等待后续帧投票解决。再往后如果冲突持续存在系统会把它判定为地图过期触发局部重推理。专家对这个优先级序表示认可但补充了一条这个谁说了算的规则要用可验证的方式写进系统不能藏在代码逻辑里。她是做安全和交互研究的说话委婉但意思很明确——你的安全决策过程需要可审计。这个意见直接影响到了评审后期关于责任边界的讨论。3.4 问8人机协作场景的安全底线从哪里开始第八个问题把气氛带向严肃你们的安全机制是AI模型的一部分还是独立于AI的如果AI的感知错了安全还能不能兜底我们强调了一条原则安全层必须是独立于AI的物理和逻辑防线。硬件上有急停按钮和碰撞传感器软件上有安全速度场和保持距离场这些机制不依赖语义模型的置信度只依赖最基本的几何测距。人机共存区域里机器人默认速度上限设为每秒0.5米在人员密集区域还会进一步压低。导航决策层做的事只是建议速度安全执行层有最终否决权这是两套独立的代码路径不会因为AI模型的更新而互相影响。专家的评价是思路对了但没有给出第三方验证手段说服力有限。她建议我们把安全层做成可独立测试的模块用单独的安全测试用例集去验证而不是和AI功能混在一起出测试报告。没人能否认安全这件事不能靠自我声明要靠独立的验证链。3.5 这组问题背后专家在验证什么第二组问答的核心词是可靠。机器人系统方向的专家全程都在追问一个问题从自然语言到电机转动的整条链路上任何一环坏了会怎样他不在乎你某个环节单独跑有多好在乎的是链路整体的失败率和失败恢复能力。坦白讲这组问答是全场压力最大的区域。因为导航和交互直接面向真实用户任何一个偶尔失败都会被放大成这个系统不靠谱。专家的很多问题其实没有标准答案他们要的是你有没有想过这些情况、有没有对应的预案。这本身就是一种考核方式——预案的存在比预案的完美更重要。4. 架构与部署答辩被追问为什么最多的一组4.1 问9端云协同是不是在给自己挖坑第三组问题从架构选型开始。专家开门见山你们为什么不做纯端侧算力不够就用更小的模型现在不少方案都是端侧部署你搞端云协同多了一堆网络依赖和同步问题图什么我的回答是我们一开始也做过纯端侧原型但发现两个绕不开的瓶颈。第一个是算力全局语义地图的更新、大模型语义理解、跨场景的经验共享这些任务在端侧设备上要么跑不动要么慢得影响体验。第二个是数据闭环我们希望机器人A在某栋楼里学到的新空间知识能够帮助机器人B更快地理解相似的场景这个能力如果不上云就只能在局域网里慢慢同步。所以架构上选了端云协同但做了严格分工感知、安全、实时避障必须在端侧因为它们有硬实时要求语义理解、地图全局优化、知识共享走云端。专家没有全盘否定但追问了端云同步的版本一致性问题端侧地图和云端地图不一致时怎么办我只能承认这是我们早期真实踩过的坑曾经出现过机器人A更新的地图把机器人B顶下线的情况。后来加了版本号校验和增量同步协议这个问题才算解决。断网场景我们也有降级方案这部分在第五组问题里详细回答了。4.2 问10为什么没用纯视觉方案第十个问题关于传感器选型现在的视觉方案进步很快你们为什么还要上深度传感器和IMU是纯视觉不够用还是你们对自己的算法没信心我给出的答案是够用但不可靠。纯视觉方案在光照充足、纹理丰富的环境里表现不错成本也确实低但一旦遇到白墙、暗光、镜面反射、雨雾天气深度估计就变得极不稳定。对于空间智能体来说深度值的准确性直接决定碰撞安全事故的概率这个风险不值得省。所以我们选了RGB-D相机加IMU加轮式里程计的融合方案深度传感器负责稠密几何IMU负责姿态短时预测轮式里程计兜底三个来源做动态权重融合。专家追问融合权重怎么定我说是根据置信度动态调整的光照条件好时视觉权重升高光照退化时深度传感器权重升高。她还问了一句成本问题这套传感器组合会不会让整机成本失去竞争力我算了一笔账放在现场深度相机的成本大概是纯视觉方案的三到五倍但对比高线数激光雷达方案又低了一个量级对室内场景来说是性价比最高的中间态。专家没有继续追问这个决策至少在逻辑上是自洽的。4.3 问11模型要压到什么程度才敢上嵌入式设备第十一个问题直指部署你们的语义分割和场景理解模型压到什么程度才敢往嵌入式设备上放压完精度还剩多少我们项目的实测链路是先剪枝再量化顺序不能反。如果先做量化再做剪枝两种误差会叠加精度损失明显更大。原始模型大小约200MB经过通道剪枝加INT8量化后压到45MB推理延迟从服务器端的120毫秒降到边缘设备上的35毫秒左右。代价是语义分割的mIoU掉了大约两到三个百分点主要体现在物体边缘的细节损失比如椅子腿和桌脚容易被切割得不够干净。这个损失我们通过后处理做了部分补偿包括边缘细化网络和时序融合。专家指出精度数字本身可以接受但要搞清楚代价具体落在哪些类别上。我们做过类别层面的误差分布分析发现细长物体和透明物体下降最明显而这两类恰恰是空间操作任务最怕出错的。所以现在部署策略是做分层端侧轻量模型负责常规场景的快速响应云端大模型在任务对精度敏感的时段做二次校验。这个混合推理模式增加了系统复杂度但换来了可接受的精度。4.4 问12实验室的漂亮数据为什么到现场就缩水第十二个问题是我们内部天天在吐槽的话题实验室环境跑得好好的一到真实场地就各种问题领域鸿沟到底有多大我给了两个具体数字实验室环境的任务成功率接近95%到了某个真实写字楼场地后掉到六成左右。缩水的原因很典型——实验室浅色木地板到了现场变成深色高反光地砖实验室里没有人走动现场人来人往实验时的静物场景在现实中几乎不存在。还有一个隐蔽问题现场的自然光随时间变化上午的走廊和下午的走廊在语义模型眼里完全是两个环境。我们解决领域鸿沟的办法是做仿真加真实双轨数据仿真渲染数据负责覆盖多样性真实场景采集数据负责贴合目标环境再加上在线自标注数据回流闭环。但我跟专家强调了一个更根本的教训目标场地应该在项目立项阶段就锁定从第一天就把开发环境放在目标场景附近而不是实验室全链路跑通后再拉去现场适配。后者的代价是返工式适配时间成本翻倍。专家听完说这个教训比项目本身的技术更有价值。4.5 这组问题背后专家在验证什么第三组问答可以说是选型审问。专家不关心你的方案听起来多先进关心每一项技术选择背后的理由、代价和取舍逻辑。这种问法给我最大的触动是做系统的人必须把每个为什么准备到一追问到底的程度否则答辩现场很容易被问穿。同时我也意识到技术选型没有绝对的对错只有是否匹配场景。端云协同也好多传感器融合也好只要你能说清楚在什么条件下做这个选择、这个选择的代价是什么、什么情况下你会推翻这个选择专家就会认可你的工程判断力。5. 边界与合规答辩六连问暴露出真实短板5.1 问13空间幻觉怎么发现、怎么纠正第十三问开始进入边界区域。专家问你们称为空间智能体那空间模型出错的时候比如幻觉出一堵不存在的墙、把镜子里的倒影当成真实空间系统自己能不能发现怎么纠正我们的设计里每个语义实体都带一个置信度分数低于阈值的对象不会进入任务决策。发现错误的机制有三层跨帧几何一致性检查会比对连续帧的几何观测是否自洽多视角交叉验证用不同角度的观测互相印证用户纠正反馈是最直接的手段用户说那里没有门系统就会把对应区域标记为待重推理。纠正动作是局部区域重新推理并回滚与该区域耦合的拓扑关系和路径缓存。评审现场举了一个很应景的案例我们把落地镜里的假走廊当真机器人导航直接冲向镜面。这个问题我们后来专门做了镜像反射判定模块用偏振信息加多视角视差双重验证把镜面区域从可通行空间里剔除。这个模块是在评审前两周才紧急加上的属于被真实场景逼出来的功能。专家说了一句我记到现在的话空间幻觉这种东西不是消灭了就完事而是要有机制让它持续暴露否则你会以为它不存在。5.2 问14断网、断电、内存爆了系统往哪退第十四问是系统级的压力测试云端挂了网断了边缘设备内存不够了系统分别怎么表现降级路径是什么我们定义了三级降级模式。第一级是全功能模式端云协同正常。第二级是受限导航模式断网后云端语义能力关闭端侧轻量模型接管语义理解系统保留导航和避障能力但不再执行需要复杂语义推理的任务机器人会选择一个安全中断点停下等待网络恢复。第三级是安全驻停模式发生在端侧模型也无法保证安全时系统直接驻停并通知运维人员。断电场景做了掉电前的状态持久化重启后能从任务上下文恢复执行。内存方面有内存看门狗和热点区域驱逐策略超限时把最不活跃区域的压缩数据落盘。专家在这个问题上强调了一句降级路径不能只在文档里画要在现场真演练。我们承认断网演练做过一次是在评审前的项目现场模拟的当时发现轻量模型加载时间比预期长导致机器人多停了十几秒。这就是不演练不知道的问题。5.3 问15空间数据是谁的数据隐私怎么办第十五问把话题转向数据合规。专家问得很直接你们的空间数据里含有人的面部、车牌、物品布局信息这些数据归谁用户要删除怎么办你们打算怎么处理隐私问题我们的原则是本地优先加最小必要采集。默认所有原始空间数据不出设备云端只接收脱敏后的语义结果。具体手段是在端侧做人脸检测和车牌检测检测到就先打码然后再进入空间模型从源头掐断敏感信息外流。原始帧数据保留24小时自动删除语义地图按项目期限留存到期清理。用户要求删除时提供按人或按区域的数据遗忘接口。这个接口我们做了但说实话做得很狼狈因为空间数据里的人和物是纠缠在一起的遗忘一个区域很容易连带影响其他人的空间使用记录。专家听完没有批评只是提醒空间数据合规这件事不能项目上线后再补要在架构层面就预留数据生命周期管理能力。她还追问了一个尖锐的问题如果用户的隐私偏好和系统功能需要冲突比如有人不想被建模但系统要识别他才能避让他你们怎么办我们的回答是提供一个不被建模模式系统只保留他的实时位置用于避碰不进入长期语义地图。这个设计我们确实有只是还没完全落地。5.4 问16训练数据从哪来偏见有多少第十六问是关于训练数据构成的你们空间理解模型的训练数据是什么有没有做多样性分析是不是全是在办公室里拍的数据我们当时的数据构成是合成场景渲染约占六成真实场景采集约占四成。合成数据的好处是标注便宜、场景覆盖广但坏处是风格偏移合成环境里训练的模型到了真实世界总有一层塑料感。真实数据质量高但采集成本大而且我们确实有严重的场景偏见——办公室环境占比过高工业厂房、户外园区、仓储物流这些场景的表现明显偏弱。专家没有纠结于数据量而是提示了一个更隐蔽的问题合成数据会放大现实世界里的不常见配置比如渲染引擎生成的完美厨房台面上永远干干净净但真实的厨房台面堆满了锅碗瓢盆。模型在完美厨房上训练碰到真实的杂乱厨房就懵。我们后来做了一件事就是定向采集杂乱场景数据用风格迁移做增强再在目标场景微调。这是评审后立行立改的事项之一。5.5 问17空间模型出了错责任算谁的第十七问是全场最哲学的问题如果你们的空间模型判断错了机器人做错了动作造成了损失责任算谁的是算法工程师的是操作员的还是机器人自己的我如实说这是全行业都没完全解决的问题我们只能讲清楚自己目前的边界。我们的系统设计上分了三层AI决策层负责给出建议安全执行层负责兜底限制操作员负责最终确认。所有空间决策都有可追溯的推理链记录下来哪个模型、哪个输入、哪个置信度做出的判断出事后可以完整回放。但责任到底归谁这个问题涉及产品形态、合同条款和行业共识不是技术团队单方面能定下来的。专家的点评让我印象深刻你们至少承认了边界存在没有直接把责任推给AI自己。但她补充目前这套决策审计机制还太模糊建议我们把它做成可验证的产物——每个决策都要留结构化审计记录而不只是日志文本。现在回头看这个意见是我们整场评审里得到的最有前瞻性的一个。5.6 问18最让专家不满意的一个回答第十八问来得措手不及。专家拿着我们的测试报告问你们报告里写的导航成功率是98%那剩下的2%失败是什么场景什么后果有没有发生过碰撞请把失败案例拿出来。这一问成了全场最难堪的时刻。我们发现项目组过去只重视统计成功率却没有系统性记录失败案例。早期的失败场景基本都是口头记录——上次在走廊那儿差点撞到门框、实验室里椅子位置变了导致卡住——但没有结构化的失败日志没有场景快照没有当时模型置信度的存档。也就是说我们可以说出成功率98%却说不清失败的2%具体长什么样。这个回答让专家很不满意我也能理解她的不满。一个没有失败证据链的系统它的成功指标就是个没有分母的分数无法分解、无法复现、无法持续追踪。她说了一句让我坐立不安的话指标如果不能分解到具体场景那就只是用来安慰自己的数字。这一问直接决定了评审后我们的第一优先级任务。5.7 六连问里藏着的评审逻辑边界与合规的六连问单看每一问都是不同话题幻觉、降级、隐私、数据、责任、失败案例。但把它们连起来看逻辑线索非常清晰——专家在验证的不是你们系统有多强而是你们对自己的系统有没有诚实的认知。每一个问题背后都有一个潜台词你知不知道自己的系统会在哪里失效失效了怎么办由谁负责拿什么证明。这种问法让我学到很多。做空间智能体这种涉及物理动作的系统能力证明很重要但失效证明更重要。你可以不完美但你必须知道自己在哪些场景不完美并且有机制去量化这种不完美。诚实面对失败案例不是评审的负担反而是整个项目最加分也最缺的素材。6. 评审落幕后的迭代清单与个人反思6.1 三个立刻改掉的毛病评审结束后的第一周我们开了三天的复盘会列出的第一优先级任务有三个。第一个就是补建失败日志系统。现在每一次导航任务、每一个抓取动作无论成功失败都会自动记录场景类型、传感器原始数据快照、模型置信度、执行结果和后果标注。失败场景有了结构化档案测试报告里的98%终于有了分母。第二个是把镜像反射判定模块从前置方案变成正式功能。评审前它是紧急补丁现在它进了核心感知管线并且增加了针对玻璃幕墙、亚克力板、金属反光面的专项测试集。第三个是降级路径的全流程演练断网、断电、内存告警、云端响应超时每个场景都做成自动化测试用例确保降级不是文档里的一句话而是真实可触发的路径。6.2 两个暂时搁置但绕不开的问题有两个问题我们决定暂时搁置但心里清楚它们绕不开。第一个是决策审计机制的完善。评审专家建议的结构化审计记录技术上能做但它牵扯到产品形态和合同责任划分需要业务侧一起参与制定规则不是纯算法团队闭门能定的事。第二个是合成数据和真实数据的持续校准流程。这个需要长期投入我们排进了下一季度目标是建立每周自动跑一遍的合成-真实漂移检测。搁置不代表不管只是优先级排序问题。我自己心里给它们立了时间线决策审计机制必须在首次对外商用前落地合成数据校准流程必须在扩大场景覆盖前跑通。这两件事没有回头路。6.3 给同类项目团队的评审备战建议如果你也在做空间智能、机器人、数字孪生类项目有一句评审后的经验送给你准备失败案例比准备成功案例更能赢得尊重。专家评审真正想看的是你对系统边界的认知深度而不是你有多能吹。我在评审前花了大把时间整理成功演示的素材结果专家问的全是最不愿意面对的角落。如果重来一次我会从项目第一天就建立失败案例库给每个失败场景打标签、存档截图、记录当时的置信度和推理链。另外两件事也要提前做一是把所有技术选型的为什么写成一页纸从算法到传感器到端云架构都要能一口气讲清楚理由和代价二是把降级路径和边界条件当成一等公民写进测试计划而不是放在附录里。评审专家可能记不住你系统最强的三个功能但一定会记住你承认短板时的诚恳程度以及你针对短板有没有真正的补救机制。评审结束那天傍晚我们收拾会议室投影仪还亮着屏幕上停着最后一页系统边界声明。我盯着那页看了很久。团队里的某个成员走过来说了一句我至今记得的话——这18个问题才是这个项目真正完整的地方。方案是纸上的问答才是我们跟真实世界对过话的证据。我当时没接话但心里认同。空间智能体这个方向跑得快的方案到处都是真正稀缺的是愿意停下来跟专家把每一个失效点掰扯清楚的团队。如果你手上也有类似的系统别急着展示它多聪明先试着回答自己18个最尖锐的问题你会有惊喜也会有冷汗。
