机器人项目评审时经常会遇到一种不太好判断的状态方案已经做出来了样机也能跑一部分大家都希望继续往前推进但它离“可以放心进入下一阶段”又还差一点。最难判断的往往不是完全没跑通的方案而是这种“已经能跑一点但还没有充分证明”的方案。它看起来有进展会议上也容易被描述成“基本可行”“问题不大”“后面再补”但如果支撑证据不够后面很可能会在联调、测试或现场阶段集中还债。工程决策不是要求所有风险都消失而是要知道哪些风险已经验证过哪些地方还缺证据哪些问题可以带着条件往前走哪些问题必须先停下来补验证。所以方案能不能进入下一阶段我会先看 6 类证据。这篇更适合用在方案评审、样机阶段评审、转阶段评审尤其是方案已经能跑一部分但还没有充分验证的时候。第一场景证据方案能不能继续先看它是在什么场景下成立的。很多机器人方案在会议室、台架、演示场地里看起来没问题但真实场景一变边界就会变。地面、光照、人员、空间、负载、节拍、维护动作、异常恢复都会影响方案是否成立。评审时要问这个方案已经在哪些场景下跑过哪些场景只是口头假设真实使用环境和当前测试环境差多少如果只是在演示环境里跑过就不能直接默认它已经适合真实现场。没有场景证据的方案很容易把演示成立误判成工程成立。第二性能证据性能证据不是只看最高指标而是看关键指标在真实条件下是否稳定。比如速度、精度、续航、负载、识别率、响应时间、温升、噪声、通信稳定性不能只拿最好一次结果说事还要看重复性、波动范围、最差工况和余量。评审时要问这个性能数据来自几次测试测试条件是什么有没有最差工况有没有重复运行结果指标波动范围是多少距离设计边界还有多少余量性能证据不是证明最好一次能做到而是证明关键指标在重复运行和边界工况下仍然站得住。如果一个指标只有在理想条件下好看换个工况就明显下降那它还不足以支撑下一阶段决策。第三接口证据很多方案单模块能成立到了整机就出问题原因往往在接口。机械接口、电气接口、通信接口、软件接口、控制接口、安全接口都要有证据说明它们不是只在纸面上能连而是在实际运行中能协同。评审时要问接口状态有没有闭合指令发出后有没有反馈异常状态怎么同步状态变化由谁触发、谁确认跨模块问题由谁记录、谁判断、谁关闭接口证据看的不是“线能不能接上”而是跨模块状态能不能闭合。比如一个控制指令发出去以后驱动有没有反馈软件有没有记录异常有没有上报恢复以后状态有没有重新确认。这些如果没有证据后面就会在联调阶段用时间补。第四风险证据方案继续往前走不代表风险不存在。关键是风险有没有被识别、分级和验证。比如电源余量不足、线束空间紧张、传感器受环境影响、散热风险、关键器件供应风险、维护空间不足、安全策略不完整这些都不能只写一句“后续关注”。风险不能只停在一句提醒里。放到方案评审里更要看它有没有变成可跟踪的证据。评审时要问风险清单在哪里每个风险的触发场景是什么影响范围是什么验证动作是什么谁负责跟踪什么时候关闭如果一个风险只是被提到但没有场景、影响、证据、动作和责任人那它还没有真正进入工程管理。没有风险证据的方案推进越快后面越可能集中还债。第五验证证据验证证据决定方案是不是只停留在“大家觉得可行”。评审时要看测试记录、波形、日志、视频、问题单、复测结果而不是只看“已验证”“基本通过”这类结论。尤其是机器人项目验证要覆盖动作组合、异常恢复、长时间运行、维护复装、环境变化和最差工况。只验证静态条件很难支撑整机阶段决策。评审时要问哪些需求已经验证哪些只是演示过哪些还没有验证条件测试记录在哪里问题修改后有没有回归异常恢复有没有复测最差工况有没有覆盖如果会议上只说“这个已经测过”但没有记录、日志、波形、视频或复测结果这个结论就很难被后续团队接住。后面问题发生时大家很容易重新争论“当时到底有没有测过”第六决策证据最后还要看决策本身有没有被记录清楚。一个方案进入下一阶段往往不是因为它完美而是因为团队接受了某些风险也明确了后续补验证和整改动作。这就需要把决策条件写清楚为什么允许继续带着哪些风险继续下一阶段必须补哪些证据谁负责补什么时候补完如果验证不通过回退条件是什么真正有效的评审结论不应该只写“通过”或“原则通过”。更应该写清楚在什么条件下通过哪些问题允许带入下一阶段哪些验证必须补哪些风险不能再往后拖如果哪些条件不满足就必须重新评审。没有决策证据后面问题出现时大家很容易回到一句话“当时谁同意的”看完证据后通常做三类判断看这 6 类证据不是为了把方案简单分成“通过”和“不通过”。真实项目里更常见的决策有三类。第一可以继续往前走。关键场景已经覆盖核心指标有重复数据主要接口已经闭合风险有跟踪动作验证记录能支撑当前阶段判断。这时候继续推进是有依据的不是因为“大家觉得差不多”而是因为关键证据已经能支撑当前阶段决策。第二可以带着条件往前走。方案方向成立但还有部分证据缺口。这种情况在项目里很常见问题不在于“带条件”而在于条件有没有写清楚带着哪些风险继续下一阶段必须补哪些验证谁负责什么时候完成什么条件下必须回退或重新评审。第三先暂停补证据。如果关键场景没有跑过核心指标只有演示数据接口没有闭合风险没有验证动作或者决策条件说不清就不适合继续靠推进来赌结果。暂停不是保守而是避免把问题推到更贵的阶段。评审结论也可以压成一句话基于当前【关键证据】本方案建议【继续推进 / 带条件推进 / 暂停补证据】仍需补充【证据缺口】由【责任人】在【时间】前完成如果【关键条件】不满足需要【回退、补充验证或重新评审】。不是证据越多越好而是关键证据不能缺工程评审不是为了把材料做厚也不是为了让团队多写文档。真正重要的是支撑下一阶段决策的关键证据不能缺。如果压缩成一张表我会这样看证据类型评审要问的问题缺了会怎样场景证据在哪些真实场景下成立容易把演示成立当工程成立性能证据关键指标是否稳定、有余量、可重复容易拿最好一次结果做决策接口证据跨模块状态是否闭合联调阶段用时间补接口风险证据主要风险是否识别并有验证动作推进越快后面越集中还债验证证据是否有测试记录、日志、波形或复测结果“已验证”变成口头结论决策证据为什么允许继续条件和回退是什么出问题后回到“当时谁同意的”这张表不是为了让评审变复杂恰恰相反它是为了让团队不要只靠汇报页、感觉和一句“差不多”做决策。真正有效的评审不是把方案讲得更顺而是把继续推进的依据讲清楚。方案能不能进入下一阶段不是看汇报页漂亮不漂亮而是看这些证据能不能支撑团队做一个知情决策。没有证据的推进本质上不是决策而是在把问题往后移。我是「机器人落地派」。欢迎留言聊聊你觉得方案评审里最容易缺的是哪一类证据