字数统计：3904 字 预计阅读时间：约 8 分钟
设想这样一个试运行场景：一台人形机器人能够把物料搬到指定工位，也能够按照指令完成取放动作，测试报告中的任务成功率看起来不错。但真正与它一起工作的员工却发现，它有时突然靠近，有时迟迟没有回应，遇到异常后也不清楚是在等待、重新规划，还是已经停止工作。任务最终完成了，人却始终不敢把注意力从它身上移开。
这时，一个问题就出现了：机器人原本是来减轻工作负担的，为什么反而增加了人的照看负担？
日本VeriServe研发团队在《通用人形机器人的评价元模型》中提出，将安全与可靠性、任务执行表现、交互质量、人的印象与信任，以及实际使用情况放在一起考察。这是一项企业提出的研究性评价框架，而不是国际标准，但它提供了一个值得讨论的视角：评价机器人，不仅要看机器完成了什么，还要看人如何与它共同工作。
对TPP而言，这也引出了一个供应链质量管理问题：当整机质量不再只是零部件性能与动作结果的组合，企业应该如何定义质量目标，又如何把这些目标转化为设计要求、供应商责任和验证证据？
假设一台机器人进行了100次搬运，其中95次把物料送到了目的地，便得到95%的任务成功率。这个数字当然有价值，但在评价之前，还需要问几个问题：这95次是否都在规定时间内完成？有没有损伤物料？过程中是否有人调整位置、重复下达指令，或者远程接管？测试对象、光照、通道和负载，是始终不变，还是覆盖了预期的使用条件？
如果一台机器人能够独立完成任务，另一台需要工程师反复介入后才能完成，两者即使被记录为相同的“成功率”，也不能直接作出相同的能力判断。类似地，在固定环境下重复成功，与面对变化条件仍能成功，证明的也不是同一件事。
美国国家标准与技术研究院NIST提出的人形机器人基础性能基准，正是尝试通过共同的移动、操作及全身协调任务，建立可量化、可比较的能力评价基础。该项目仍处于协同开发过程中，并不是一套现成的通用验收标准。
因此，TPP建议，企业在确定成功率目标之前，先明确任务边界、测试条件、人工介入规则和结果判定。质量评价的第一步，不是把成功率做得更高，而是让“成功”具有清楚、一致、可追溯的含义。
继续用一个假设作比较：两台机器人都完成了95次任务，另外5次没有完成。一台在无法识别物料时退出动作并请求确认，另一台则在判断错误后继续抓取，造成物料跌落。两者的任务成功率相同，但失败的性质与后果显然不同。
这意味着，质量评价不能把所有失败都装进一个“不成功”的统计栏。没有完成任务、造成物料损伤、出现危险动作、需要人工介入，是不同的问题，需要不同的分析和处置。反过来，一次基于正确风险判断的任务拒绝，也不应与失控或误动作混为一谈。
从工程评价看，操作性能与接触安全也需要不同的证据。NIST的相关机器人研究既涉及抓取能力、操作性能等测试，也涉及人机接触时力与压力的测量，并不是用一个动作成功率覆盖所有问题。
可靠性同样不能被短期成功率替代。企业还应追问：连续运行一个班次以后，原有表现能否保持？经历规定的使用循环和维护周期后，是否仍然满足要求？这些问题不能靠一次演示或一份短期测试记录作答。
在评价机制上，关键安全要求应当成为放行前提，而不是可以被高成功率、高效率或者用户好评抵消的扣分项。综合评价可以帮助识别改进方向，但不能把性质不同的风险平均掉。
对于需要与人协作的机器人，交互不应被理解为增加一块屏幕、几句语音，或者一个更亲切的外观。
真正需要评价的是：人能否理解它正在做什么，能否知道自己的指令是否被接受，能否判断下一步应该等待、避让、确认，还是接管。
例如，员工要求机器人暂停，它虽然停止了动作，却没有任何状态反馈。员工无法判断它是否真正收到指令，便可能再次操作。又例如，机器人因路线受阻而重新规划，却没有告知原因，员工只能站在旁边猜测。这些情形中，最终任务未必失败，但协作过程已经出现了额外负担。
NIST的人机交互研究将信息共享、状态反馈、界面有效性以及减少用户对机器人意图的疑惑，纳入了评价和方法开发范围。其关注对象不只是机器人自身的动作能力，也包括人与机器人组成的协作系统。
由此出发，企业可以把“交互自然”进一步转化为可验证的问题：关键状态是否清楚可辨？指令存在歧义时是否需要确认？非计划中断后，用户能否知道原因和后续操作？这些问题不应只在交付后归为“体验建议”，而应在设计阶段进入需求与验证计划。
好的交互，不是让机器人显得更像人，而是让人不必不断猜测机器人。
讨论用户信任时，需要避免另一个误区：认为只要用户更喜欢机器人、更相信机器人，质量就更好。
人机协作研究指出，信任不足可能导致用户弃用自动化系统，过度信任则可能使用户依赖存在缺陷的系统。因此，需要关注的是信任与系统实际能力之间的匹配，而不是单纯提高信任程度。
对人形机器人而言，这意味着，企业不应只问用户“你觉得它可靠吗”，还应检查用户是否正确理解它能做什么、不能做什么，在什么条件下需要确认，以及遇到什么情况应当停止使用或请求帮助。一个能够清楚说明能力边界的产品，未必最擅长制造惊喜，却更有利于建立有依据的使用预期。
同样，“看起来让人放心”不能替代安全验证，“暂时让人感到陌生”也不能直接证明产品不安全。主观感受与客观证据都值得评价，但不能相互冒充。
真正值得追求的，不是让用户相信机器人什么都能做，而是让用户准确知道，哪些事情可以交给它，哪些事情还不能。
假如一台机器人通过了验收，使用一段时间后，员工却把复杂任务重新交给人工，只让它完成最简单、最稳定的一小部分工作。如果企业只查看仍在执行的那些任务，成功率可能依然很好；但原先希望实现的使用价值，实际上已经缩小了。
因此，TPP建议，把交付后的评价从“有没有故障”延伸到“实际怎样使用”。除了任务成功率，还可以按场景观察非计划人工介入次数、异常恢复时间、重复指令次数、有效作业时间，以及原定任务中实际交给机器人完成的比例。
这里需要区分必要的人类监督与产品问题带来的额外照看：前者可能就是系统设计的一部分，不能简单视为缺陷；后者则值得追查，究竟源于操作难度、状态不清、性能不稳定，还是任务范围定义不合理。
持续使用情况也不能直接等同于产品质量。员工减少使用，可能与排产、培训、维护安排或组织流程有关；使用频繁，也不自动证明风险已经受控。使用数据更适合作为发现问题的入口，而不是脱离情境给产品打分的终点。
这些要求，最终要进入供应链，而不是停留在整机体验报告里
如果用户提出“机器人靠近时让人紧张”，供应商质量部门应该如何处理？要求所有供应商改善“用户满意度”，显然不够；把问题全部交给软件团队，也过于简单。
TPP建议，从具体场景反向分解。例如，在人与机器人共享的通道中，企业希望实现清楚、可预期且风险受控的避让行为，就需要进一步明确：感知系统在规定条件下能否及时识别人？控制系统如何判断冲突并协调动作？执行机构能否实现要求的运动与停止表现？交互系统能否让人理解它的状态？不同系统之间的数据、时序和异常处理是否一致？
随后，才是把可分配的要求落实到相应供应商，明确适用条件、接口责任、测试方法和变更后的复验范围。具体阈值应来自场景分析、风险评估及适用要求，而不是随意借用另一款产品的数据。
这里还必须保留整机责任：即使每个供应商都完成了约定的部件验证，也仍然需要通过系统集成验证，确认这些部件共同工作时能够实现目标。不能把“用户信任”直接分摊给某一家零部件供应商，也不能用供应商报告替代整机证据。
供应链质量管理真正需要连接的是：使用场景、整机目标、系统要求、供应商交付和实际使用反馈。否则，用户说的是“不好用、不放心”，企业检查的却始终只是“尺寸合格、参数达标、报告齐全”。
任务成功率回答的是，机器人在规定条件下把事情做成了多少次。而完整的质量评价，还需要回答：它是否在风险受控的前提下完成任务，能否持续保持表现，能否让人理解并有效协作，以及是否在实际工作中实现了预期价值。
这不是降低对硬件、精度和可靠性的要求，而是把这些要求放回完整的使用场景中。人形机器人的质量，不应止于证明“它能做”，还应进一步证明“它在什么条件下，值得被交付使用”。
TPP持续关注研发质量、供应链能力与数字化质量管理的结合，支持企业从使用需求出发，开展质量策划、要求分解、供应商能力提升和问题闭环。对于机器人这类跨机械、电子、软件与人机交互的产品，真正有价值的质量体系，不只是增加几份检查表，而是让用户提出的问题，能够一路追溯到设计、过程和供应链，并最终得到验证与解决。
如果需要了解更多内容，欢迎与我们联系，我们将提供专业的管理咨询和数字化解决方案帮助我们的顾客。
邮箱:Marketing@tppconsultancy.com
电话：400 102 1300
TPP 微信公众号
TPP软件免费体验申请