设计评审

在门径管理（Stage-Gate，又称阶段门）流程中，产品开发被拆分为若干执行阶段，阶段之间以关口隔开；阶段负责执行，关口负责决策，二者交替推进，关口须输出继续、修正、搁置、终止四种决策之一。设计评审在流程中的位置，正是这类关口在“方案定型”这一节点上的具体化。^{33研发项目管理工具的评审节点：三道评审怎么设 - 禅道图书馆lib.zentao.net前往参考资料 ↓在新标签页中打开}

研发主线通常设置三道评审节点：需求评审守入口、设计评审守方案、交付评审守出口。设计评审被安排在需求评审之后、交付评审之前，其输入是已通过评审的需求条目与验收标准，其输出则成为后续开发与交付评审的输入，上一道评审的输出即为下一道的输入。^{33研发项目管理工具的评审节点：三道评审怎么设 - 禅道图书馆lib.zentao.net前往参考资料 ↓在新标签页中打开}

设计评审被置于“开发启动之前”这一时点：在方案尚未进入编码与实现、尚未产生大量不可逆投入时，对技术方案做可行性分析，覆盖模型设计、接口约定、流程编排与影响范围，从而在方案定型前拦截设计与接口错误。^{33研发项目管理工具的评审节点：三道评审怎么设 - 禅道图书馆lib.zentao.net前往参考资料 ↓在新标签页中打开}

把设计评审放在开发启动之前，依据的是“风险越靠前拦截，改动代价越低”的流程逻辑：越接近交付阶段才发现方案缺陷，返工所需的人力与工期成本越高，因此评审节点应尽量前移到不可逆动作之前。^{33研发项目管理工具的评审节点：三道评审怎么设 - 禅道图书馆lib.zentao.net前往参考资料 ↓在新标签页中打开}

在工程勘察设计领域，设计评审同样被绑定在特定的设计阶段节点上：方案设计阶段在方案设计过程中组织评审；初步设计和施工图设计阶段则在各专业第一次互提资料之前组织评审，即评审被安排在专业间资料交接这一不可逆动作之前。^{44PDF.js viewersdi.gzu.edu.cn前往参考资料 ↓在新标签页中打开}

工程勘察设计领域的设计评审以会议形式进行，由评审人员、定案人员对设计是否满足顾客需求、建设目的以及国家和地方相关建筑技术标准与规定提出优化意见、解决方案并做出定案结论，因此它在流程中同时承担“技术把关”与“方案定案”两个位置职能。^{44PDF.js viewersdi.gzu.edu.cn前往参考资料 ↓在新标签页中打开}

设计评审在流程中的位置并非孤立节点，而与需求评审、交付评审构成前后衔接的链条：需求评审确认需求完整、无歧义、可验证并产出验收标准与优先级，设计评审据此确认方案可行、接口与上下游对齐、变更点清楚、工期可信，交付评审再据此前成果把关质量与验收缺口。^{33研发项目管理工具的评审节点：三道评审怎么设 - 禅道图书馆lib.zentao.net前往参考资料 ↓在新标签页中打开}

设计评审与测试的核心区别在于介入时机与对象：设计评审在方案尚未实现或尚未冻结时，对设计文档、模型、原型等设计输出进行审查，目的是在缺陷产生之前发现并消除设计缺陷；测试则在实现产物（代码、样件、系统）上执行，通过运行来暴露缺陷。^{55IEEE Standard for Software Reviews and Auditsstandards.ieee.org前往参考资料 ↓在新标签页中打开|66Systems and software engineering — Software life cycle processesiso.org前往参考资料 ↓在新标签页中打开}

IEEE 1028 将评审（review）与测试（testing）区分为两类不同的验证活动：评审是对工作产品的人工检查，测试是对可执行软件或系统的动态验证；两者在 V 模型中被安排在不同层级，评审对应设计与需求阶段的静态验证，测试对应实现与集成阶段的动态验证。^{55IEEE Standard for Software Reviews and Auditsstandards.ieee.org前往参考资料 ↓在新标签页中打开}

设计评审与验收的区别在于判定性质与决策权限：设计评审是过程性的技术审查，结论通常是“通过/有条件通过/不通过”并形成改进项，由同行或技术专家作出；验收是阶段性的正式确认，由客户或授权代表依据合同与验收准则作出接收与否的决定，具有合同与法律效力。^{66Systems and software engineering — Software life cycle processesiso.org前往参考资料 ↓在新标签页中打开|77Systems and software engineering — System life cycle processesiso.org前往参考资料 ↓在新标签页中打开}

在 ISO/IEC 12207 与 ISO/IEC 15288 的过程框架中，评审属于技术管理或验证过程中的分析性活动，验收属于利益相关方需求与确认（validation）相关的活动，二者在过程目标、输入输出和触发条件上均不相同。^{77Systems and software engineering — System life cycle processesiso.org前往参考资料 ↓在新标签页中打开}

设计评审可以在没有可运行产品的情况下进行，这是它与测试、验收最本质的差别：评审依赖的是设计描述（图纸、模型、规格说明、原型说明），测试与验收依赖的是可执行或可测量的实物/系统。^{55IEEE Standard for Software Reviews and Auditsstandards.ieee.org前往参考资料 ↓在新标签页中打开|66Systems and software engineering — Software life cycle processesiso.org前往参考资料 ↓在新标签页中打开}

设计评审不能替代测试与验收：评审发现的是设计层面的缺陷与风险，无法验证实际运行行为、性能边界与集成效果；反之，测试与验收也不能替代设计评审，因为许多设计缺陷在实现后修复成本远高于设计阶段。^{55IEEE Standard for Software Reviews and Auditsstandards.ieee.org前往参考资料 ↓在新标签页中打开|66Systems and software engineering — Software life cycle processesiso.org前往参考资料 ↓在新标签页中打开}

从软件工程实践看，代码评审发生在编码完成之后往往为时已晚：此时开发者已写出大量代码，要求其推倒重写面临进度压力与人际阻力，评审者很难坚持否决。因此设计评审应当前移到编码之前，在编写第一行测试之前完成，以确保架构与设计决策合理。^{88Code reviews are too late, design reviews are betterlearn.microsoft.com前往参考资料 ↓在新标签页中打开}

在医疗器械等受监管行业，设计评审被定义为对产品设计方案进行评审以尽早发现设计错误或缺陷、进而优化设计并提高设计质量与稳健性的活动；它被视为贯穿设计输入、设计过程与设计输出的过程，而不仅是一个时间节点。^{99国际医疗器械展览会深度探讨设计评审：评什么，怎么评？medtecinnovation.com前往参考资料 ↓在新标签页中打开}

早期发现缺陷的价值在于缺陷修复成本随发现阶段后移而显著上升：设计阶段修正方案变更的代价通常远低于在样机、量产或上市后返工，因此设计评审被视为质量成本控制的前置手段。^{88Code reviews are too late, design reviews are betterlearn.microsoft.com前往参考资料 ↓在新标签页中打开}

设计评审的核心经济价值在于把缺陷拦截在方案定型之前：研发流程中方案一旦定型，后续的详细设计、开模、试制与验证都会以该方案为输入，此时再发现设计或接口错误，改动会沿着下游环节逐级传递并被放大，返工范围与代价随之上升。因此在方案定型前设置评审关口，是降低返工成本最直接的手段。^{33研发项目管理工具的评审节点：三道评审怎么设 - 禅道图书馆lib.zentao.net前往参考资料 ↓在新标签页中打开|1111以规范的技术评审模式促产品质量提升ep.cannews.com.cn前往参考资料 ↓在新标签页中打开}

门径管理（Stage-Gate，阶段门）把产品开发拆成执行阶段与决策关口交替推进的结构，关口须输出继续、修正、搁置、终止四种决策之一。设计评审即对应方案定型前的关口，其作用是在不可逆动作发生之前做出继续或修正的判断，避免带着未决问题进入下一阶段而造成返工。^{33研发项目管理工具的评审节点：三道评审怎么设 - 禅道图书馆lib.zentao.net前往参考资料 ↓在新标签页中打开}

只在里程碑节点开展设计确认的评审模式，被实践者认为难以及时发现设计过程中的问题：设计环节参与方多、内容交叉，任一环节的错误都会传递到后续所有环节，仅靠里程碑评审发现时，产品返工、资源浪费与成本增加的概率较高。^{1111以规范的技术评审模式促产品质量提升ep.cannews.com.cn前往参考资料 ↓在新标签页中打开}

将长周期的里程碑评审拆解为短周期的微技术环节评审，并配合评审专家制度、检查单与表单化的检查依据、评审问题的归零跟踪，是航空制造企业为从源头减少返工与资源浪费而采用的规范化技术评审做法。^{1111以规范的技术评审模式促产品质量提升ep.cannews.com.cn前往参考资料 ↓在新标签页中打开}

设计评审之所以能降低返工成本，前提是评审本身有效：反馈分散在多个系统与邮件、表格中，相关方参与不足，问题在后期才被发现，以及评审工具与研发工具链割裂，都会削弱评审流程的实际效果，使返工并未被真正拦截。^{1010What is a Design Review? | PTCptc.com前往参考资料 ↓在新标签页中打开}

产品复杂度上升使每一项设计决策都牵动成本、可制造性、合规性、性能与上市时间，因此领先组织依赖结构化的设计评审在问题变得难以解决、代价更高之前完成评估与相关方对齐。^{1010What is a Design Review? | PTCptc.com前往参考资料 ↓在新标签页中打开}

设计评审为跨职能参与者提供了一个结构化的知识交换场所：设计方在评审中阐述设计决策的依据、约束条件与权衡过程，而领域专家则带来制造、测试、运维、法规等视角的隐性经验，双方的知识在问答与质疑中双向流动，而非单向汇报。^{1212Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activitiesincose.org前往参考资料 ↓在新标签页中打开|1313Design Reviews: A Guide to Effective Practiceied.org.uk前往参考资料 ↓在新标签页中打开}

美国国防部在 MIL-STD-1521B《技术评审与审计》中将设计评审定义为对设计活动进行正式、全面、系统的检查，其目的之一是确保设计参与各方对设计状态与决策依据形成共同理解，而不仅是发现缺陷。^{1414MIL-STD-1521B: Technical Reviews and Audits for Systems, Equipments, and Computer Softwarequicksearch.dla.mil前往参考资料 ↓在新标签页中打开}

在评审中形成的共识具有可追溯性价值：评审纪要中记录的决策、假设与遗留风险，为后续变更控制提供了基线，使团队在出现分歧时能够回溯到当初达成一致的具体依据，而不是依赖个人记忆。^{1212Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activitiesincose.org前往参考资料 ↓在新标签页中打开}

设计评审的共识建立功能依赖于参与者的多样性：若评审组由同一专业背景或同一汇报线的人员构成，评审容易退化为确认既有方案的形式，知识共享的广度与质疑的有效性都会显著下降。^{1313Design Reviews: A Guide to Effective Practiceied.org.uk前往参考资料 ↓在新标签页中打开|1515Design Review: A Practical Guidedesigncouncil.org.uk前往参考资料 ↓在新标签页中打开}

Pahl 与 Beitz 在《工程设计学》中将设计评审描述为设计过程中各阶段之间的衔接环节，其作用包括把上一阶段的设计知识传递给下一阶段的执行者，并使各专业对接口条件达成一致。^{1616Engineering Design: A Systematic Approachlink.springer.com前往参考资料 ↓在新标签页中打开}

软件工程领域的能力成熟度模型集成（CMMI）将同行评审列为一种验证手段，同时强调评审过程能够促进组织内最佳实践与经验教训的传播，属于过程改进的知识共享机制。^{1717CMMI for Development, Version 1.3resources.sei.cmu.edu前往参考资料 ↓在新标签页中打开}

设计评审中知识共享的效果与评审会议的节奏设计有关：将大段汇报压缩、把时间留给提问与讨论，并在会前分发材料，能够提高参与者对设计依据的理解深度，而不是只停留在结论层面。^{1313Design Reviews: A Guide to Effective Practiceied.org.uk前往参考资料 ↓在新标签页中打开|1515Design Review: A Practical Guidedesigncouncil.org.uk前往参考资料 ↓在新标签页中打开}

评审共识并不等于全体一致：实践中通常以「无重大异议且行动项责任明确」作为通过条件，允许保留少数意见并记录在案，这种处理方式既维持了决策效率，也保留了不同专业判断的痕迹。^{1414MIL-STD-1521B: Technical Reviews and Audits for Systems, Equipments, and Computer Softwarequicksearch.dla.mil前往参考资料 ↓在新标签页中打开}

有研究指出，设计评审在知识共享方面的价值往往被低估，因为其收益是间接的、延迟显现的，难以像缺陷发现数量那样被直接度量，导致组织在评审中更关注查错而忽视共识与知识传递。^{1515Design Review: A Practical Guidedesigncouncil.org.uk前往参考资料 ↓在新标签页中打开}

正式设计评审是设计复审的一种组织形式，指在预先安排好的议事日程下、以正式会议方式进行的评审；评审材料一般提前两周散发给与会人员，并要求会前返回书面评审意见。^{1818[科普中国]-设计复审- · 科普中国网kepuchina.cn前往参考资料 ↓在新标签页中打开}

正式设计评审的典型议程是：设计人员对设计方案作详细说明，答复与会者的问题，记录各项重要评审意见，并在会议结束前就应采取的纠正与弥补措施、以及是否需要重新提交评审作出决定。^{1818[科普中国]-设计复审- · 科普中国网kepuchina.cn前往参考资料 ↓在新标签页中打开}

正式设计评审因参加人员包括各方面代表，通常采取正式会议的方式，是概要设计复审常用的方式；与之相对的另一种做法是只召集少数设计人员和有关用户进行同行讨论，人数少、形式灵活，更适合详细设计复审。^{1818[科普中国]-设计复审- · 科普中国网kepuchina.cn前往参考资料 ↓在新标签页中打开}

在传统软件设计中，概要设计复审与过程（详细）设计复审应分开进行，不允许合并为一次复审。^{1818[科普中国]-设计复审- · 科普中国网kepuchina.cn前往参考资料 ↓在新标签页中打开}

正式设计评审的参加者构成有明确要求：除软件开发人员外，概要设计复审必须有用户代表参加，必要时可邀请相关领域专家；过程设计复审一般不邀请用户和其他领域代表。^{1818[科普中国]-设计复审- · 科普中国网kepuchina.cn前往参考资料 ↓在新标签页中打开}

正式设计评审的对象是设计文档而非设计者本人，评审中提出的问题应详细记录但不必谋求当场解决，评审结束前应作出本次评审能否通过的结论。^{1818[科普中国]-设计复审- · 科普中国网kepuchina.cn前往参考资料 ↓在新标签页中打开}

正式设计评审没有统一的行业规范，通常由公司或研发团队根据目标产品特点自行建立评审形式，明确评审所审视的系统组件与评审重点。^{1818[科普中国]-设计复审- · 科普中国网kepuchina.cn前往参考资料 ↓在新标签页中打开}

同行评审（Peer Review）是设计评审的一种常见类型，指由与设计者同级、同专业或相近专业背景的同事对设计成果进行系统性检查，以发现缺陷、评估设计质量并促进知识共享。^{1919IEEE Standard for Software Reviews and Auditsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|2020Software Engineering (10th Edition)pearson.com前往参考资料 ↓在新标签页中打开}

在软件工程领域，同行评审的典型形式包括代码评审（Code Review）、设计评审（Design Review）、走查（Walkthrough）和审查（Inspection），其中审查是最正式、最结构化的形式。^{1919IEEE Standard for Software Reviews and Auditsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|2121Design and code inspections to reduce errors in program developmentieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

同行评审的正式化程度可以从非正式的桌面检查（Desk Check）到高度结构化的正式审查（Formal Inspection）连续变化，组织可根据项目风险、规模和资源选择适当的形式。^{1919IEEE Standard for Software Reviews and Auditsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|2121Design and code inspections to reduce errors in program developmentieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

迈克尔·费根（Michael Fagan）于1976年在IBM系统期刊上发表的论文中提出了正式的软件审查流程，该流程后来被称为Fagan审查（Fagan Inspection），成为同行评审的经典范式。^{2121Design and code inspections to reduce errors in program developmentieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

Fagan审查通常包括规划、概述、准备、审查会议、返工和跟进六个阶段，并强调审查主持人的角色和基于检查表的缺陷发现方法。^{2121Design and code inspections to reduce errors in program developmentieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

同行评审的有效性依赖于评审者的独立性和专业性，以及评审过程的组织质量；研究表明，结构化的同行评审能显著提高缺陷发现效率并降低后期修复成本。^{1919IEEE Standard for Software Reviews and Auditsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|2222Peer Reviews in Software: A Practical Guideinformit.com前往参考资料 ↓在新标签页中打开}

在敏捷开发实践中，同行评审常以轻量级形式嵌入日常活动，如结对编程（Pair Programming）和拉取请求（Pull Request）评审，强调快速反馈和持续改进。^{2222Peer Reviews in Software: A Practical Guideinformit.com前往参考资料 ↓在新标签页中打开}

同行评审与用户评审、管理评审的区别在于：同行评审由技术同行主导，聚焦技术质量与设计合理性，而非业务价值或项目决策。^{1919IEEE Standard for Software Reviews and Auditsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|2020Software Engineering (10th Edition)pearson.com前往参考资料 ↓在新标签页中打开}

同行评审的常见挑战包括评审者时间不足、缺乏培训、评审意见主观性强以及团队社交压力导致不敢提出批评；这些因素可能削弱评审效果。^{2222Peer Reviews in Software: A Practical Guideinformit.com前往参考资料 ↓在新标签页中打开}

在智能座舱设计中，同行评审可用于评估人机交互设计、界面布局、功能逻辑等，通常由交互设计师、视觉设计师、软件工程师和测试工程师共同参与。^{2323Automotive User Interfaces: Creating Interactive Experiences in the Carlink.springer.com前往参考资料 ↓在新标签页中打开}

走查（walkthrough）与启发式评估（heuristic evaluation）同属可用性测查（usability inspection）方法族，其共同特征是由评审者依据既定任务或原则对界面进行检查，而不是通过招募真实用户做可用性测试来发现问题。^{2424如何通过设计评审？来看这份深度总结！_手机网易网m.163.com前往参考资料 ↓在新标签页中打开}

启发式评估通常由数名交互设计或可用性专家分别以角色扮演的方式，按预设任务独立走查界面，再汇总各自发现的问题；其优点是成本低、速度快，适合在资源有限时快速获得一批可用性问题。^{2424如何通过设计评审？来看这份深度总结！_手机网易网m.163.com前往参考资料 ↓在新标签页中打开}

启发式评估的主要局限在于：合格的交互专家在团队中往往稀缺，且不同专家对同一界面给出的可用性问题判断一致率较低，很多结论带有个人主观见解，难以清晰说明某个问题为何构成体验缺陷。^{2424如何通过设计评审？来看这份深度总结！_手机网易网m.163.com前往参考资料 ↓在新标签页中打开}

为缓解单人启发式评估的主观性与低一致率，实践中常采用协作式启发式评估：由多名评审者先各自独立检查、再集中讨论合并问题清单，用多人交叉来提升问题覆盖度与判断可信度。^{2424如何通过设计评审？来看这份深度总结！_手机网易网m.163.com前往参考资料 ↓在新标签页中打开}

走查与启发式评估的选用应视评审成员构成与评审目的而定：成员以交互专家为主时更适合启发式评估，成员包含产品、开发、测试等多角色时更适合以任务场景为主线的走查。^{2424如何通过设计评审？来看这份深度总结！_手机网易网m.163.com前往参考资料 ↓在新标签页中打开}

在设计评审的整体方法体系中，走查与启发式评估属于依赖专家判断的测查类方法，与依赖真实用户行为的可用性测试形成互补，前者用于早期低成本筛查，后者用于验证。^{2424如何通过设计评审？来看这份深度总结！_手机网易网m.163.com前往参考资料 ↓在新标签页中打开}

跨职能评审与单一职能的内部评审（如设计团队内部的设计走查）区别在于：前者关注跨专业的接口与权衡（如设计可行性、实现成本、合规风险），后者更关注本专业内的质量与一致性。^{11Design reviewen.wikipedia.org前往参考资料 ↓在新标签页中打开}

跨职能评审的有效性依赖参与者在评审前获得可读的材料（如设计说明、原型、风险清单），否则不同职能代表难以在同一信息基础上形成判断，评审易流于形式。^{11Design reviewen.wikipedia.org前往参考资料 ↓在新标签页中打开}

在硬件与汽车等受监管行业，跨职能评审常被纳入产品开发流程的质量门（quality gate），需要研发、质量、制造、采购、法规等多职能共同签署，以满足可追溯性与合规要求。^{2525ISO 9001:2015 Quality management systems — Requirementsiso.org前往参考资料 ↓在新标签页中打开}

评审准备阶段的核心产出是评审包（review package），通常包含待评审的设计稿、需求或用户研究依据、变更说明以及评审检查单；评审组织者应在会前把材料分发给参与者，使其有时间预读。^{2626Software Design Reviews: A Practical Approachieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

在软件与产品设计评审的实践中，材料提前分发被视为提高评审有效性的关键前提：参与者在会前完成预读，会议时间才能用于讨论与决策，而不是用于现场阅读文档。^{2727Peer Reviews in Software: A Practical Guideprocessimpact.com前往参考资料 ↓在新标签页中打开}

评审准备需要明确评审目标与范围，并据此确定参与者角色（如主持人、记录人、设计负责人、领域专家），避免把不同目标的评审混在一次会议中。^{2626Software Design Reviews: A Practical Approachieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|2727Peer Reviews in Software: A Practical Guideprocessimpact.com前往参考资料 ↓在新标签页中打开}

评审检查单（checklist）是准备阶段的常用工具，把过往评审中反复出现的问题固化为检查项，帮助评审者在预读时聚焦高风险区域。^{2626Software Design Reviews: A Practical Approachieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

评审准备还应包括对上一轮评审遗留问题的跟踪：把未关闭的问题项及其处理状态列入材料，使评审者能判断设计是否已收敛。^{2626Software Design Reviews: A Practical Approachieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|2727Peer Reviews in Software: A Practical Guideprocessimpact.com前往参考资料 ↓在新标签页中打开}

在跨职能评审中，材料提交的时间窗口需要与参与者排期协调；材料发出过晚是评审流于形式、意见质量下降的常见原因之一。^{2727Peer Reviews in Software: A Practical Guideprocessimpact.com前往参考资料 ↓在新标签页中打开}

设计评审会议不是孤立的一次会议，而是一个由会前规划、会中实施、会后跟进三个阶段构成的闭环过程；评审能否真正促进设计开发而不流于形式，取决于这三个环节的组织质量。^{2828医疗器械成功进行设计评审的技巧_检测资讯_嘉峪检测网anytesting.com前往参考资料 ↓在新标签页中打开}

会前规划阶段的核心是确定评审在哪些阶段进行、评审什么内容、由谁参加，并形成书面的策划安排；ISO 要求在设计开发的适宜阶段，按计划且形成文件的安排开展系统性的设计评审。^{2828医疗器械成功进行设计评审的技巧_检测资讯_嘉峪检测网anytesting.com前往参考资料 ↓在新标签页中打开}

美国 FDA 的设计控制要求在设计开发的适当阶段，对设计结果进行有计划、有文件记录的正式评审，与 ISO 一样强调评审应分布在设计开发的多个阶段而非只在结束时进行一次。^{2828医疗器械成功进行设计评审的技巧_检测资讯_嘉峪检测网anytesting.com前往参考资料 ↓在新标签页中打开}

评审会议应明确输入材料（如设计输出文档、验证数据、风险分析结果）在会前分发给参会者，使会议时间用于讨论与决策而非现场阅读材料，这是避免评审沦为走过场的关键做法之一。^{2828医疗器械成功进行设计评审的技巧_检测资讯_嘉峪检测网anytesting.com前往参考资料 ↓在新标签页中打开}

评审会议中应逐项记录发现的问题、判定结论（通过、有条件通过、不通过）以及对应的责任人和完成期限，形成可追踪的评审记录，而不是只留下会议签到表。^{2828医疗器械成功进行设计评审的技巧_检测资讯_嘉峪检测网anytesting.com前往参考资料 ↓在新标签页中打开}

会后跟进是评审流程中最容易被弱化的环节：评审提出的整改项需要被逐条关闭并验证，未关闭的问题应在下一次评审或阶段放行前重新核查，否则评审结论无法转化为设计改进。^{2828医疗器械成功进行设计评审的技巧_检测资讯_嘉峪检测网anytesting.com前往参考资料 ↓在新标签页中打开}

评审会议的参与者应覆盖设计、测试、制造、质量、法规等与设计结果相关的职能，必要时引入不直接参与该设计的独立评审人，以降低团队内部视角固化带来的盲区。^{2828医疗器械成功进行设计评审的技巧_检测资讯_嘉峪检测网anytesting.com前往参考资料 ↓在新标签页中打开}

设计评审中的问题记录与跟踪，指把评审会上识别出的指摘事项（指摘事項）逐条登记为可指派、可设定截止日期、可更新状态的任务，并持续跟踪至关闭；Asana 指出「指摘事项管理不到位」是设计评审流于形式的典型失败模式之一，因此主张用任务管理工具统一管理指摘事项与审批流程。^{2929デザインレビュー (DR) とは？目的・種類・効果的な進め方を解説 [2026] • Asanaasana.com前往参考资料 ↓在新标签页中打开}

问题记录与跟踪的起点是评审结论的结构化输出：每条问题应记录问题描述、提出者、责任人与处理期限，并区分「必须修改后才能进入下一阶段」与「可延后处理」两类，以便与阶段放行判断挂钩。Asana 强调设计评审的本职是判断能否进入下一阶段，而非进度确认，因此问题清单必须能支撑这一放行决策。^{2929デザインレビュー (DR) とは？目的・種類・効果的な進め方を解説 [2026] • Asanaasana.com前往参考资料 ↓在新标签页中打开}

跟踪环节需要为每轮修改编号（轮次编号），并指定唯一核准人，避免修改轮次无人计数、责任分散导致的反复返工；Quire 将「没人计数的修改轮次」列为设计核准流程时间流失的两大来源之一。^{3030设计核准流程：6 个阶段 + 免费模板 | Quirequire.io前往参考资料 ↓在新标签页中打开}

问题记录应放在任务管理软件而非聊天群组中，因为聊天中的需求与问题「只在有人记得时才存在」，缺乏到期日期与状态字段，无法形成可审计的闭环。^{3030设计核准流程：6 个阶段 + 免费模板 | Quirequire.io前往参考资料 ↓在新标签页中打开}

对质量保证角色而言，问题记录与跟踪的产物同时承担审计证据功能：审批记录与指摘事项的关闭状态构成 ISO 及企业内部规范合规性的证据链，因此记录需保留可追溯的审批留痕。^{2929デザインレビュー (DR) とは？目的・種類・効果的な進め方を解説 [2026] • Asanaasana.com前往参考资料 ↓在新标签页中打开}

问题跟踪的闭环判定标准是「关闭有据」：每条指摘事项须有明确的处理结果（修改完成、判定为不修改并说明理由、或转为变更请求），并由评审方确认后才能标记关闭，未关闭项应作为下一阶段评审的输入。^{2929デザインレビュー (DR) とは？目的・種類・効果的な進め方を解説 [2026] • Asanaasana.com前往参考资料 ↓在新标签页中打开|3030设计核准流程：6 个阶段 + 免费模板 | Quirequire.io前往参考资料 ↓在新标签页中打开}

设计评审的闭环指评审结论必须落实到明确的行动项（action item），每项指定责任人、截止日期与验证方式，并在关闭前由提出方或独立角色确认完成，否则评审只产生意见而不产生设计变更。^{1919IEEE Standard for Software Reviews and Auditsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

复评（re-review）通常在两类情形触发：一是上一轮评审中被判定为“有条件通过”或“不通过”的问题项完成整改后，需对整改结果做针对性确认；二是设计发生基线变更（需求、接口、安全相关约束变化）后，需重新走完整或裁剪后的评审流程。^{1919IEEE Standard for Software Reviews and Auditsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|3131ISO/IEC/IEEE 24765:2017 Systems and software engineering — Vocabularyiso.org前往参考资料 ↓在新标签页中打开}

在受监管的硬件与汽车电子开发中，评审记录、行动项状态与关闭证据属于设计历史文件（Design History File）或配置管理记录的一部分，需可追溯、可审计，复评记录同样要保留版本与签署信息。^{3232ISO 26262-2:2018 Road vehicles — Functional safety — Part 2: Management of functional safetyiso.org前往参考资料 ↓在新标签页中打开}

闭环与复评的有效性依赖评审问题的分级：将问题分为阻断级（必须关闭才能进入下一阶段）、重要级（限期关闭）与建议级（可记录不强制关闭），可避免复评被大量低优先级意见拖长。^{1919IEEE Standard for Software Reviews and Auditsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

复评不应简单重复首轮评审的全部内容，而应聚焦于变更影响分析与整改验证；对未变更部分沿用首轮结论，可显著降低复评成本，这一做法在迭代式开发与敏捷硬件流程中被广泛采用。^{3131ISO/IEC/IEEE 24765:2017 Systems and software engineering — Vocabularyiso.org前往参考资料 ↓在新标签页中打开}

评审闭环的度量指标通常包括：行动项按期关闭率、平均关闭周期、复评触发率与复评一次通过率；这些指标用于判断评审是否真正驱动了设计改进，而非仅作为流程合规的打卡。^{1919IEEE Standard for Software Reviews and Auditsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|1717CMMI for Development, Version 1.3resources.sei.cmu.edu前往参考资料 ↓在新标签页中打开}

若评审结论未与配置管理或需求管理工具联动，行动项容易在文档与邮件中散落，导致复评时无法准确判断哪些问题已关闭、哪些变更已生效，这是闭环失效的常见原因。^{1717CMMI for Development, Version 1.3resources.sei.cmu.edu前往参考资料 ↓在新标签页中打开}

对于安全相关设计（如 ISO 26262 功能安全开发），复评还需确认安全机制、诊断覆盖与验证证据是否随设计变更同步更新，否则原有安全论证可能失效。^{3232ISO 26262-2:2018 Road vehicles — Functional safety — Part 2: Management of functional safetyiso.org前往参考资料 ↓在新标签页中打开}

启发式评估（Heuristic Evaluation）由 Jakob Nielsen 与 Rolf Molich 于 1990 年提出，是一种让少量评估者依据一组可用性原则独立检查界面、再汇总发现问题的专家评审方法，属于「启发式原则」类方法中最具代表性的一种。^{22Heuristic evaluation of user interfacesdl.acm.org前往参考资料 ↓在新标签页中打开|333310 Usability Heuristics for User Interface Designnngroup.com前往参考资料 ↓在新标签页中打开}

Nielsen 提出的十条可用性启发式原则包括：系统状态可见性、系统与现实世界匹配、用户控制与自由、一致性与标准、错误预防、识别优于回忆、灵活高效使用、美学与极简设计、帮助用户识别诊断并从错误中恢复、帮助与文档；这套原则被广泛用作界面评审的检查依据。^{333310 Usability Heuristics for User Interface Designnngroup.com前往参考资料 ↓在新标签页中打开|3434How to Conduct a Heuristic Evaluationnngroup.com前往参考资料 ↓在新标签页中打开}

Nielsen 建议启发式评估由 3 至 5 名评估者分别独立执行，因为单个评估者通常只能发现约三分之一的可用性问题，而多名评估者的发现合并后覆盖率显著提升；评估者之间不交流，最后再汇总去重。^{333310 Usability Heuristics for User Interface Designnngroup.com前往参考资料 ↓在新标签页中打开|3535Finding usability problems through heuristic evaluationdl.acm.org前往参考资料 ↓在新标签页中打开}

检查表（checklist）式评审把原则或规范逐条转成可勾选、可判定的条目，使不同评审者对同一界面的判断趋于一致，并便于在多次评审之间复用与统计；其代价是条目容易僵化，可能漏掉清单之外的新问题。^{3636Usability Inspection Methodswiley.com前往参考资料 ↓在新标签页中打开|3737Usability evaluation methods: a systematic reviewtandfonline.com前往参考资料 ↓在新标签页中打开}

在可用性工程实践中，启发式评估常与用户测试配合使用：前者成本低、可在设计早期快速迭代，后者能提供真实用户行为证据，两者互补而非互相替代。^{333310 Usability Heuristics for User Interface Designnngroup.com前往参考资料 ↓在新标签页中打开|3838Usability Engineeringsciencedirect.com前往参考资料 ↓在新标签页中打开}

ISO 9241-110 以对话原则（dialogue principles）的形式给出了交互系统可用性的高层判据，包括任务适宜性、自描述性、符合预期、可学习性、可控性、容错性、可定制性等，可作为检查表条目的标准化来源。^{3939ISO 9241-110:2020 Ergonomics of human-system interaction — Part 110: Dialogue principlesiso.org前往参考资料 ↓在新标签页中打开}

检查表条目应随产品形态演进持续维护，例如针对移动端、语音交互、车载场景补充触控目标尺寸、驾驶分心、语音反馈时机等专门条目，否则通用检查表会遗漏场景特有的风险。^{4242Mobile Usabilitynngroup.com前往参考资料 ↓在新标签页中打开}

评审工具方面，问题记录通常采用结构化模板：位置、问题描述、所违反的原则或条目、严重度评级、改进建议，以便汇总排序并跟踪闭环；严重度分级常参考 Nielsen 的五级严重度量表。^{333310 Usability Heuristics for User Interface Designnngroup.com前往参考资料 ↓在新标签页中打开|4343Severity Ratings for Usability Problemsnngroup.com前往参考资料 ↓在新标签页中打开}

认知走查（Cognitive Walkthrough）由 Clayton Lewis、Peter Polson、Cathleen Wharton 和 John Rieman 于 1990 年在论文《Cognitive Walkthroughs: A Method for Theory-Based Evaluation of User Interfaces》中正式提出，最初用于评估面向“探索式学习”用户的界面可用性。^{4444Cognitive Walkthroughs: A Method for Theory-Based Evaluation of User Interfacesdoi.org前往参考资料 ↓在新标签页中打开}

认知走查的核心是让评审者扮演特定用户角色，针对完成一个具体任务所需的每一步操作，依次回答四个问题：用户是否会尝试达成正确目标、用户是否注意到正确的操作控件、用户是否会把该操作与期望效果关联起来、以及操作后的反馈是否让用户确认进展。^{4545Cognitive Walkthroughinteraction-design.org前往参考资料 ↓在新标签页中打开|4646The Cognitive Walkthrough Method: A Practitioner's Guideresearchgate.net前往参考资料 ↓在新标签页中打开}

Wharton 等人在 1994 年的论文中把认知走查的四个核心问题明确表述为：用户是否会尝试达成正确目标、用户是否会注意到正确的操作控件、用户是否会把该操作与期望效果关联起来、以及操作后的反馈是否让用户确认进展；该表述成为后续实践的标准模板。^{4646The Cognitive Walkthrough Method: A Practitioner's Guideresearchgate.net前往参考资料 ↓在新标签页中打开}

认知走查属于分析式（专家评审）可用性评估方法，不需要真实用户参与，通常在界面原型或早期设计阶段即可执行，成本低于用户测试，但无法替代基于真实用户行为的可用性测试。^{4545Cognitive Walkthroughinteraction-design.org前往参考资料 ↓在新标签页中打开|3636Usability Inspection Methodswiley.com前往参考资料 ↓在新标签页中打开}

Nielsen 与 Mack 在《Usability Inspection Methods》一书中将认知走查列为一种主要的可用性检查方法，并指出其优势在于能在设计早期发现学习性问题，局限在于评审者难以可靠预测真实用户的知识与行为。^{3636Usability Inspection Methodswiley.com前往参考资料 ↓在新标签页中打开}

认知走查的典型执行流程包括：确定评审范围与目标用户画像、定义代表性任务、组建评审小组（通常 2–6 人）、逐步骤走查并记录问题、汇总分析并给出设计改进建议。^{4545Cognitive Walkthroughinteraction-design.org前往参考资料 ↓在新标签页中打开}

在智能座舱场景中，认知走查常被用于评估驾驶场景下高频任务（如导航设定、媒体切换、空调调节）的步骤可发现性与反馈清晰度，尤其适合在 HMI 原型阶段替代部分实车用户测试。^{4747Applying Cognitive Walkthrough to Automotive HMI Evaluationsae.org前往参考资料 ↓在新标签页中打开}

认知走查与启发式评估（Heuristic Evaluation）常被并列使用：前者聚焦任务步骤层面的学习成本，后者聚焦界面整体是否符合通用可用性原则，两者互补而非替代。^{4545Cognitive Walkthroughinteraction-design.org前往参考资料 ↓在新标签页中打开|3636Usability Inspection Methodswiley.com前往参考资料 ↓在新标签页中打开}

评审记录与缺陷跟踪工具的核心作用是把设计评审中发现的缺陷（defect）从发现、分派、修复到验证关闭的全过程记录下来，形成可追溯的闭环，避免评审结论停留在口头或会议纪要层面。^{1919IEEE Standard for Software Reviews and Auditsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|4848Software Engineering Body of Knowledge (SWEBOK) Guide, Version 4.0computer.org前往参考资料 ↓在新标签页中打开}

IEEE 1028-2008《软件评审与审计》把评审的输出定义为记录在案的评审结果，包括发现的问题、评审结论与后续措施，并要求对评审中发现的问题进行跟踪直至解决，这为评审记录与缺陷跟踪工具提供了标准层面的依据。^{1919IEEE Standard for Software Reviews and Auditsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

在缺陷跟踪工具中，缺陷记录通常包含标识、标题、严重程度、优先级、发现阶段、责任人、状态与关闭依据等字段；状态机一般覆盖新建、已分派、修复中、待验证、关闭与重新打开等状态。^{4848Software Engineering Body of Knowledge (SWEBOK) Guide, Version 4.0computer.org前往参考资料 ↓在新标签页中打开|4949Bugzilla Documentationbugzilla.readthedocs.io前往参考资料 ↓在新标签页中打开}

Bugzilla 是历史悠久的开源缺陷跟踪系统，提供缺陷生命周期管理、查询与报表功能，常被用作评审问题跟踪的落地工具之一。^{4949Bugzilla Documentationbugzilla.readthedocs.io前往参考资料 ↓在新标签页中打开}

Jira 是广泛使用的商业问题与项目跟踪工具，通过可配置的工作流、字段与看板支持缺陷与任务的跟踪，在评审问题闭环管理中被大量团队采用。^{5050Jira Software Documentationsupport.atlassian.com前往参考资料 ↓在新标签页中打开}

评审记录工具与缺陷跟踪工具在实践中常被合并使用：评审会议中逐条记录问题并当场分类（如缺陷、改进建议、疑问），会后统一录入跟踪系统并指定责任人与期限，下次评审或验证环节核对关闭情况。^{1919IEEE Standard for Software Reviews and Auditsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|4848Software Engineering Body of Knowledge (SWEBOK) Guide, Version 4.0computer.org前往参考资料 ↓在新标签页中打开}

缺陷跟踪数据可用于评审度量，例如按发现阶段统计缺陷分布、计算评审发现缺陷数与后续阶段逃逸缺陷数的比例，从而评估评审的有效性并指导改进。^{4848Software Engineering Body of Knowledge (SWEBOK) Guide, Version 4.0computer.org前往参考资料 ↓在新标签页中打开|5151Software Inspectionpearson.com前往参考资料 ↓在新标签页中打开}

仅记录缺陷而不做根因分类与趋势分析，会使评审记录沦为流水账，难以支撑过程改进；因此成熟的实践会在跟踪工具中附加缺陷类型、根因与引入阶段等字段。^{5151Software Inspectionpearson.com前往参考资料 ↓在新标签页中打开}

对于设计评审这类以文档和模型为对象的评审，记录工具还需支持对具体文档位置（章节、图元、需求标识）的引用，以便缺陷可定位、可复核。^{1919IEEE Standard for Software Reviews and Auditsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|4848Software Engineering Body of Knowledge (SWEBOK) Guide, Version 4.0computer.org前往参考资料 ↓在新标签页中打开}

在设计评审中，主持人（facilitator）通常被建议由不直接负责该设计的人担任，例如项目经理或产品经理；其核心职责是确保讨论聚焦于主题，并让每位参与者的意见都能被听到。^{5252UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开|5353UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

设计评审开始前应明确澄清每个人的角色，并在逐个点评时重申角色，以避免有人感到被遗忘；理想情况下演示者、主持人、记录者三类角色由不同人担任，但实践中往往难以完全做到。^{5252UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开|5353UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

主持人需要与演示者（负责提案并解释设计思路、回答提问的人）和记录者（负责记录讨论内容、确保评审结论在会后清楚传递的人）配合，形成分工明确的评审组织方式。^{5252UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开|5353UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

主持人在评审中应维护尊重氛围：如果参与者是在批评而非尊重台面上的意见和他人的技能，评审会迅速形成敌意，因此主持人需要把讨论引导到对设计本身的评价上。^{5252UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开|5353UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

主持人应在评审开始时快速提醒参与者项目目标与本次评审涉及的范围，使讨论集中在手头任务上，避免偏离话题；同时提醒参与者他们并非产品的目标用户，帮助评审回到真实用户视角。^{5252UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开|5353UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

在设计评审中，设计者（designer）是提交设计方案、接受质询并负责后续修改的责任主体；评审的输入物（如草图、线框图、高保真原型、设计规范）通常由设计者准备并预先分发，以便评审者在会前形成判断。^{5454Design Critique: A Guide to Giving and Receiving Feedbackinteraction-design.org前往参考资料 ↓在新标签页中打开}

设计者在评审会上的核心职责是陈述设计意图与约束条件（用户需求、技术限制、业务目标），而不是为自己的方案辩护；把评审当作说服会而非质询会，会显著降低评审发现问题的能力。^{5454Design Critique: A Guide to Giving and Receiving Feedbackinteraction-design.org前往参考资料 ↓在新标签页中打开}

设计者需要在评审前明确写出待决问题清单（open questions），把需要评审者拍板或提供信息的事项与仅需知会的事项分开，否则会议时间容易被细节讨论吞没。^{5454Design Critique: A Guide to Giving and Receiving Feedbackinteraction-design.org前往参考资料 ↓在新标签页中打开}

设计者不应同时担任自己方案的主持人（facilitator）；由独立角色主持、设计者只负责陈述与答疑，可以降低设计者主导讨论走向、压制反面意见的风险。^{5454Design Critique: A Guide to Giving and Receiving Feedbackinteraction-design.org前往参考资料 ↓在新标签页中打开}

设计者在评审中的准备程度（是否提前分发材料、是否标注设计假设、是否准备备选方案）与评审产出质量正相关；临时展示未整理稿件的评审更容易退化为风格偏好之争。^{5454Design Critique: A Guide to Giving and Receiving Feedbackinteraction-design.org前往参考资料 ↓在新标签页中打开}

设计评审开始前应明确界定每位参与者的角色，并在逐项点评时重申这些角色，以免有人感到被忽略；理想情况下演示者、评审者与主持人应由不同的人担任，但实践中往往难以做到。^{5252UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

评审者（reviewer）是设计评审中承担点评与质询职责的角色，与负责提案并解释设计思路的演示者相对；评审者的职责是对台面上的方案与论据提出意见，而不是评判提案者本人的技能。^{5252UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

评审中的批评应针对方案与论据而非个人，一旦评审者把批评指向他人能力，评审会迅速演变为敌意氛围，因此尊重被列为适用于任何设计评审的通用原则之一。^{5252UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

评审者提出的问题应由演示者回答，或由演示者指出能够回答该问题的人；这意味着评审者的质询需要落到具体责任人，而不是在会议中悬置。^{5252UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

评审者在点评具体设计细节前，应先就点评所依据的信息与意图达成共识，即明确为何需要某项信息、对获取该信息设定了哪些预期、以及将如何使用它，然后再讨论各元素的优劣与不同意见。^{5252UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

设计评审应在整个产品设计与研发过程中持续或至少定期开展，这在需要多次迭代的敏捷或精益流程中尤为必要；评审者因此需要在多轮评审中反复参与，而非只做一次性把关。^{5252UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开}

在设计评审中，记录员（recorder）是与演示者、主持人并列的三类基本角色之一，其职责是侧重记录讨论内容，尤其确保会议相关结论在评审结束后能够被清楚地传递出去。^{5252UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开|5353UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

记录员不应被排除在讨论之外：尽管记录职能倾向于促使他人更清晰地表达观点，但记录员本身仍属于评审讨论的参与者，而非旁听或纯事务性人员。^{5252UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开|5353UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

理想状况下演示者、主持人、记录者三类角色应由不同的人担任，但在实际评审中这一理想往往难以实现，角色合并是常见现实。^{5252UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开|5353UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

评审开始之前就应澄清每个人在设计评审中的角色，并在逐个点评时重申角色，以避免有人感到被遗忘；这一做法被建议作为适用于任何设计评审的标准原则之一。^{5252UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开|5353UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

记录员的工作重点不是逐字速记，而是把评审中形成的结论沉淀为可传递的记录，使未参会者也能获知评审结果，从而支撑后续的设计迭代。^{5252UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网zpedu.com前往参考资料 ↓在新标签页中打开|5353UI 设计评价方法和原则_产品设计_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

智能座舱是融合信息娱乐、驾驶信息、车身控制与网联服务的多模态人机交互系统，其设计评审需同时覆盖视觉、语音、触控、手势等多种交互通道，单一职能团队无法独立完成全面评估。^{5555智能座舱人机交互设计与评价方法综述qichegongcheng.com前往参考资料 ↓在新标签页中打开}

智能座舱涉及车载信息娱乐系统与高级驾驶辅助系统（ADAS）的联动，设计评审需引入功能安全（ISO 26262）与预期功能安全（SOTIF，ISO 21448）视角，要求系统安全工程师参与评审。^{3232ISO 26262-2:2018 Road vehicles — Functional safety — Part 2: Management of functional safetyiso.org前往参考资料 ↓在新标签页中打开}

智能座舱的语音交互设计评审需要语音识别、自然语言处理与声学工程专家参与，以评估唤醒率、误唤醒率、方言覆盖与噪声环境下的鲁棒性等指标。^{5656车载语音交互系统设计与评测ceaj.org前往参考资料 ↓在新标签页中打开}

智能座舱的OTA升级与网联服务设计评审需网络安全专家参与，以评估攻击面、数据隐私与远程更新安全，符合UN R155/R156等法规要求。^{5757UN Regulation No. 155 - Cyber security and cyber security management systemunece.org前往参考资料 ↓在新标签页中打开}

智能座舱的显示与光学设计评审需要光学工程师与显示技术专家参与，以评估HUD、曲面屏、防眩光与不同光照条件下的可读性。^{5858车载显示与HUD光学设计评审要点gdjs.org.cn前往参考资料 ↓在新标签页中打开}

在智能座舱的设计评审中，安全约束首先来自功能安全标准 ISO 26262（道路车辆功能安全）。该标准要求对数字仪表、抬头显示等安全相关人机界面（HMI）元素进行危害分析与风险评估（HARA），并据此确定汽车安全完整性等级（ASIL）。评审需验证 HMI 设计是否满足对应 ASIL 等级对故障探测、降级模式和驾驶员警示的要求。^{3232ISO 26262-2:2018 Road vehicles — Functional safety — Part 2: Management of functional safetyiso.org前往参考资料 ↓在新标签页中打开}

ISO 26262 对 HMI 的安全目标通常体现为：在显示或交互系统发生故障时，必须通过视觉、听觉或触觉方式向驾驶员发出明确警示，并进入安全状态（如切换至备用显示、限制非安全功能）。设计评审需检查这些降级策略是否在界面设计层面得到落实，而不仅是系统架构层面的声明。^{3232ISO 26262-2:2018 Road vehicles — Functional safety — Part 2: Management of functional safetyiso.org前往参考资料 ↓在新标签页中打开}

可用性约束方面，智能座舱设计评审需参照 ISO 9241-210（人机交互的人类中心设计）所倡导的用户参与和迭代评估原则。该标准要求在设计早期引入真实驾驶员进行可用性测试，并将测试结果作为评审输入，而非仅依赖专家走查。^{5959ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

车载 HMI 的可用性评审常采用 NHTSA（美国国家公路交通安全管理局）发布的驾驶员分心指南作为约束依据。该指南建议单次视线离开道路的时间不超过 2 秒，总视线离开时间不超过 12 秒，并要求对涉及手动输入的任务进行分心评估。设计评审需对照这些量化阈值检查交互流程。^{6060Visual-Manual NHTSA Driver Distraction Guidelines for In-Vehicle Electronic Devicesnhtsa.gov前往参考资料 ↓在新标签页中打开}

中国国家标准 GB/T 26773-2011《智能运输系统 车道偏离报警系统 性能要求与检测方法》对报警系统的可用性提出了要求，但该标准主要针对车道偏离报警，并非直接覆盖智能座舱全部 HMI。在评审中引用时需注意其适用范围，避免将其误用为通用座舱可用性标准。^{6161GB/T 26773-2011 智能运输系统 车道偏离报警系统 性能要求与检测方法openstd.samr.gov.cn前往参考资料 ↓在新标签页中打开}

智能座舱中的语音交互设计评审需考虑驾驶场景下的可用性约束：语音系统应在高噪声环境下保持可懂度，并避免因误唤醒或过长语音反馈而增加驾驶员认知负荷。相关评审可参考 ISO 15005（道路车辆 交通信息和控制系统的人机工程学原则）中关于对话管理的要求。^{6262ISO 15005:2017 Road vehicles — Ergonomic aspects of transport information and control systems — Dialogue management principles and compliance proceduresiso.org前往参考资料 ↓在新标签页中打开}

在安全与可用性约束的评审中，常见误区是将 ISO 26262 的 ASIL 等级直接等同于 HMI 的可用性等级。实际上 ASIL 针对的是功能安全（故障行为），而可用性关注的是正常使用情境下的效率与满意度，两者需分别评审，不能互相替代。^{3232ISO 26262-2:2018 Road vehicles — Functional safety — Part 2: Management of functional safetyiso.org前往参考资料 ↓在新标签页中打开|5959ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

设计评审中应区分“安全约束”与“可用性约束”的验证方法：安全约束通常通过危害分析、故障注入测试和降级模式检查来验证；可用性约束则通过驾驶员在环测试、任务完成时间和主观负荷量表（如 NASA-TLX）来评估。两者在评审检查表中应分列，避免混淆。^{5959ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开|6060Visual-Manual NHTSA Driver Distraction Guidelines for In-Vehicle Electronic Devicesnhtsa.gov前往参考资料 ↓在新标签页中打开}

对于智能座舱中的触控交互，NHTSA 指南建议将单次触控操作时间控制在 2 秒以内，且要求触控目标尺寸足够大以减少误触。设计评审需检查触控区域布局是否满足这些约束，尤其是在行驶状态下允许操作的控件。^{6060Visual-Manual NHTSA Driver Distraction Guidelines for In-Vehicle Electronic Devicesnhtsa.gov前往参考资料 ↓在新标签页中打开}

ISO 15005 规定了道路车辆中交通信息和控制系统的人机工程学原则，包括对话管理、信息呈现和控件设计。该标准为智能座舱 HMI 设计评审提供了可用性约束的框架，但本身不规定具体的量化阈值，评审时需结合其他指南（如 NHTSA）使用。^{6262ISO 15005:2017 Road vehicles — Ergonomic aspects of transport information and control systems — Dialogue management principles and compliance proceduresiso.org前往参考资料 ↓在新标签页中打开}

智能座舱的多模态交互通常同时涉及语音、触控、手势、视线与物理按键等多种通道，因此其设计评审不能按单通道分别验收，而必须把「同一意图在不同通道间的一致性与可预期性」作为独立评审项。^{6363Multimodal interaction: A reviewsciencedirect.com前往参考资料 ↓在新标签页中打开|6464In-car multimodal interaction and driver distractionsciencedirect.com前往参考资料 ↓在新标签页中打开}

在评审语音通道时，应把唤醒成功率、误唤醒率、端到端响应时延与打断（barge-in）行为列为可量化的验收指标，而不是仅凭评审者主观试听判断。^{6565Voice user interface design guidancedeveloper.amazon.com前往参考资料 ↓在新标签页中打开|6666Voice Interaction Design Guidelinesdevelopers.google.com前往参考资料 ↓在新标签页中打开}

车内语音交互的评审必须在真实噪声条件下进行，因为行驶噪声、空调风噪与媒体音量会显著改变识别与唤醒表现，安静会议室中的演示结果不能代表实车可用性。^{6565Voice user interface design guidancedeveloper.amazon.com前往参考资料 ↓在新标签页中打开|2323Automotive User Interfaces: Creating Interactive Experiences in the Carlink.springer.com前往参考资料 ↓在新标签页中打开}

触控与手势通道的评审要点包括目标尺寸、可达性（是否在驾驶员不大幅度前倾或侧身的情况下可触及）、行驶中的误触率，以及在颠簸路况下命中稳定性的验证。^{6464In-car multimodal interaction and driver distractionsciencedirect.com前往参考资料 ↓在新标签页中打开}

分心与视线离路时间是智能座舱多模态评审的核心安全指标，评审中应把操作某一功能所需的视线离开道路时长与总交互时长作为通过与否的判据之一，而不仅是任务能否完成。^{5959ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

多模态交互的评审需要覆盖通道冲突与降级场景：当语音不可用、麦克风被占用或网络中断时，系统应能平滑回退到触控或物理按键，且回退路径本身要作为评审用例显式列出。^{6363Multimodal interaction: A reviewsciencedirect.com前往参考资料 ↓在新标签页中打开|6666Voice Interaction Design Guidelinesdevelopers.google.com前往参考资料 ↓在新标签页中打开}

反馈一致性是常被忽略的评审点：同一操作经由语音、触控或手势触发时，视觉、听觉与触觉反馈的时序、强度与语义应保持一致，否则用户难以建立稳定的心智模型。^{6363Multimodal interaction: A reviewsciencedirect.com前往参考资料 ↓在新标签页中打开|6464In-car multimodal interaction and driver distractionsciencedirect.com前往参考资料 ↓在新标签页中打开}

由于多模态交互涉及语音、视觉、HMI、座舱系统与安全等多个团队，评审组织上通常需要跨职能参与，并把安全相关项与体验相关项分开设定通过标准。^{2323Automotive User Interfaces: Creating Interactive Experiences in the Carlink.springer.com前往参考资料 ↓在新标签页中打开|5959ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

在评审工具上，实车或高保真模拟器中的场景化走查比静态界面评审更适用于多模态交互，因为通道切换与反馈时序只有在动态任务流程中才会暴露问题。^{6464In-car multimodal interaction and driver distractionsciencedirect.com前往参考资料 ↓在新标签页中打开}

多模态交互评审还应包含对隐私与数据采集的检查，例如语音唤醒是否在本地处理、车内摄像头与麦克风的工作指示是否对乘员可见，这类问题在功能评审中容易被遗漏。^{6666Voice Interaction Design Guidelinesdevelopers.google.com前往参考资料 ↓在新标签页中打开|2323Automotive User Interfaces: Creating Interactive Experiences in the Carlink.springer.com前往参考资料 ↓在新标签页中打开}

设计评审流于形式，通常表现为评审会变成汇报、演示和走过场：评审者被动听取设计者讲解 PPT，缺少对设计方案的实质性质疑与风险识别，评审结论以“通过”为主，评审记录简略甚至缺失。^{6767瀑布开发中设计评审流于形式，我们改了worktile.com前往参考资料 ↓在新标签页中打开}

评审流于形式的根本原因常被归为团队不重视或瀑布模型本身，但实践者指出更关键的是评审缺乏“工程化思维”——没有定义清晰的输入输出、没有设计可执行的流程、没有设定度量指标，导致评审无法复制和稳定。^{6767瀑布开发中设计评审流于形式，我们改了worktile.com前往参考资料 ↓在新标签页中打开}

把评审当作软性的沟通环节而非硬性的质量关口，是评审形式化的典型认知误区；一旦按工程化方式拆解评审（分层评审、明确角色、压缩时间、设定度量），评审的可复制性和稳定性会显著提升。^{6767瀑布开发中设计评审流于形式，我们改了worktile.com前往参考资料 ↓在新标签页中打开}

评审流于形式会直接削弱其作为风险过滤和技术对齐最后一道关的作用，使设计缺陷在后续阶段才暴露，推高返工成本；有团队报告在将评审工程化改造后，一个迭代周期内因设计缺陷导致的返工率从34%降至不到9%。^{6767瀑布开发中设计评审流于形式，我们改了worktile.com前往参考资料 ↓在新标签页中打开}

评审会中角色不清、参会者泛化，是形式化的常见诱因：架构、契约、实现等不同维度的评审混在一起开，参会角色无法聚焦，时间被拉长而实质讨论被稀释。^{6767瀑布开发中设计评审流于形式，我们改了worktile.com前往参考资料 ↓在新标签页中打开}

设计评审中，部分设计者会把针对作品的批评直接理解为对个人能力的否定，从而产生防御反应：把评审意见当作冒犯，并以情绪化的方式逐条反驳。这种反应被从业者与行业媒体反复描述为设计评审的典型失效模式之一。^{6969Designers! Don't let harsh feedback completely destroy your sense of self worththenextweb.com前往参考资料 ↓在新标签页中打开|7070I once dreaded design reviews. Now, I use them as a tool. All of us go through this shift. Negative feedback, constructive or not, made me defensive. It felt like an insult. I took it personally… | Matt Przegietka | 60 条评论linkedin.com前往参考资料 ↓在新标签页中打开}

防御心理的一种典型表现是：设计者不再针对设计目标与约束进行讨论，而是陷入逻辑不严密的争辩，为在整体方案中并不重要的细节辩护，导致评审偏离原本要解决的问题。^{6969Designers! Don't let harsh feedback completely destroy your sense of self worththenextweb.com前往参考资料 ↓在新标签页中打开}

有从业者把面对负面反馈时的防御反应描述为类似哀伤的五个阶段：否认（认为对方误解了设计）、愤怒（认为对方不懂自己的构想）、讨价还价（只改一处以换取整体方案被认可）、沮丧（怀疑自己不适合做设计）、接受（同意修改）。这一描述属于个人经验总结，不是经过验证的心理模型。^{7070I once dreaded design reviews. Now, I use them as a tool. All of us go through this shift. Negative feedback, constructive or not, made me defensive. It felt like an insult. I took it personally… | Matt Przegietka | 60 条评论linkedin.com前往参考资料 ↓在新标签页中打开}

能否以建设性方式接收并落实反馈，被视为区分优秀设计者与一般设计者的职业能力之一，而不仅是性格问题；因此防御心理常被归入个人职业素养与评审文化建设的问题，而非单纯的评审流程缺陷。^{6969Designers! Don't let harsh feedback completely destroy your sense of self worththenextweb.com前往参考资料 ↓在新标签页中打开|7070I once dreaded design reviews. Now, I use them as a tool. All of us go through this shift. Negative feedback, constructive or not, made me defensive. It felt like an insult. I took it personally… | Matt Przegietka | 60 条评论linkedin.com前往参考资料 ↓在新标签页中打开}

机械工程师学会（Institution of Mechanical Engineers）在关于如何用好设计评审的建议中指出，设计评审要真正发挥作用，所有参与者必须对评审的目的与规则达成一致，并做好以积极方式接收反馈的准备；这从组织侧说明防御心理并非设计者单方面的责任。^{6868This site uses cookies.imeche.org前往参考资料 ↓在新标签页中打开}

设计评审中“问题跟踪不闭环”指评审识别出的问题在记录后未被持续追踪至关闭，表现为无责任人、无截止日期、无状态更新，导致问题在评审结束后流失。^{7171Software Review and Inspection: A Practical Guidecomputer.org前往参考资料 ↓在新标签页中打开}

问题跟踪不闭环的直接后果是同类问题在后续评审中重复出现，评审投入的工时无法转化为设计质量的持续改进，形成“评审—发现问题—遗忘—再评审”的循环。^{7171Software Review and Inspection: A Practical Guidecomputer.org前往参考资料 ↓在新标签页中打开|1717CMMI for Development, Version 1.3resources.sei.cmu.edu前往参考资料 ↓在新标签页中打开}

IEEE 1028-2008 将评审输出定义为包括问题清单、处置记录和跟踪状态，明确要求对评审发现的问题进行记录、分类和后续跟踪，直至关闭。^{1919IEEE Standard for Software Reviews and Auditsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

CMMI 模型在“验证”和“同行评审”过程域中要求建立并维护评审问题的跟踪记录，对问题的处置状态进行监控，直至问题关闭。^{1717CMMI for Development, Version 1.3resources.sei.cmu.edu前往参考资料 ↓在新标签页中打开}

问题跟踪不闭环的常见成因包括：评审会议结束即视为评审完成、问题记录分散在个人笔记或邮件中、缺乏统一的问题状态定义、以及未将问题关闭率纳入评审有效性度量。^{7171Software Review and Inspection: A Practical Guidecomputer.org前往参考资料 ↓在新标签页中打开|1717CMMI for Development, Version 1.3resources.sei.cmu.edu前往参考资料 ↓在新标签页中打开}

在智能座舱等跨学科设计评审中，问题涉及硬件、软件、人机交互等多领域，责任边界模糊会加剧跟踪不闭环，需要明确跨团队的问题归属和升级机制。^{7272Human Factors in Automotive User Interfaces: A Reviewsciencedirect.com前往参考资料 ↓在新标签页中打开}

将评审问题导入缺陷跟踪系统（如 Jira、Bugzilla）并设置必填的责任人、优先级和截止日期，是防止问题流失的常见实践。^{1717CMMI for Development, Version 1.3resources.sei.cmu.edu前往参考资料 ↓在新标签页中打开}

定期回顾评审问题的关闭率和平均关闭周期，可以作为度量评审闭环程度的指标，用于识别跟踪过程中的瓶颈。^{7171Software Review and Inspection: A Practical Guidecomputer.org前往参考资料 ↓在新标签页中打开|1717CMMI for Development, Version 1.3resources.sei.cmu.edu前往参考资料 ↓在新标签页中打开}

设计评审的有效性可以从过程指标和结果指标两个维度度量：过程指标关注评审活动的执行质量（如缺陷发现密度、评审覆盖率、评审效率），结果指标关注评审对最终产品质量的影响（如缺陷逃逸率、返工成本、上市时间）。^{7373Software Review Metrics: A Systematic Literature Reviewsciencedirect.com前往参考资料 ↓在新标签页中打开|7474Metrics for Software Design Reviewsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

缺陷发现密度（Defect Detection Density）是评审有效性最常用的过程指标之一，定义为评审中发现的缺陷数与评审投入工作量（如人时）或评审文档规模的比值，用于衡量评审发现问题的效率。^{7373Software Review Metrics: A Systematic Literature Reviewsciencedirect.com前往参考资料 ↓在新标签页中打开|7575An Empirical Study of the Impact of Review Rate on Defect Detection Effectivenesslink.springer.com前往参考资料 ↓在新标签页中打开}

缺陷逃逸率（Defect Escape Rate）是衡量评审结果有效性的关键指标，指在评审后阶段（如测试或生产环境）发现的、本应在设计评审阶段被捕获的缺陷数量占缺陷总数的比例，该比例越低说明评审越有效。^{7474Metrics for Software Design Reviewsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|7676Software Quality Metrics: Defect Escape Rate and Review Effectivenesssciencedirect.com前往参考资料 ↓在新标签页中打开}

评审覆盖率（Review Coverage）指实际经过评审的设计文档或设计元素占应评审总量的比例，是评估评审过程完整性的基础指标，覆盖率不足会直接削弱评审对缺陷的拦截能力。^{7373Software Review Metrics: A Systematic Literature Reviewsciencedirect.com前往参考资料 ↓在新标签页中打开|7777Design Review Effectiveness Measurement in Complex Systems Engineeringonlinelibrary.wiley.com前往参考资料 ↓在新标签页中打开}

评审效率（Review Efficiency）通常以单位评审时间内发现的缺陷数或单位缺陷所需的评审时间来度量，用于评估评审活动的投入产出比，但需注意效率指标可能诱导评审者追求数量而忽视缺陷严重性。^{7575An Empirical Study of the Impact of Review Rate on Defect Detection Effectivenesslink.springer.com前往参考资料 ↓在新标签页中打开}

评审有效性指标应结合评审目标设定，并避免单一指标驱动导致的局部优化；例如仅追求缺陷发现数量可能忽视高严重度缺陷的识别，因此建议采用平衡计分卡式的多指标组合。^{7474Metrics for Software Design Reviewsieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

在工业实践中，设计评审的有效性改进常采用PDCA（计划-执行-检查-处理）循环，通过定期回顾评审指标数据、识别薄弱环节并调整评审流程（如评审准备时间、评审人员构成、检查单更新）来实现持续改进。^{7676Software Quality Metrics: Defect Escape Rate and Review Effectivenesssciencedirect.com前往参考资料 ↓在新标签页中打开|7777Design Review Effectiveness Measurement in Complex Systems Engineeringonlinelibrary.wiley.com前往参考资料 ↓在新标签页中打开}

软件工程领域的研究表明，设计评审的缺陷发现效率与评审速率（每小时评审的文档页数）存在相关性，过高的评审速率通常伴随缺陷发现率的下降，因此建议将评审速率控制在合理范围内以保障评审有效性。^{7575An Empirical Study of the Impact of Review Rate on Defect Detection Effectivenesslink.springer.com前往参考资料 ↓在新标签页中打开|7878Automated Collection of Review Metrics: A Case Studydl.acm.org前往参考资料 ↓在新标签页中打开}

设计评审有效性指标的数据收集应尽可能自动化，例如通过评审工具记录评审时间、缺陷数量、缺陷类型和严重程度，以减少人工统计偏差并支持趋势分析。^{7878Automated Collection of Review Metrics: A Case Studydl.acm.org前往参考资料 ↓在新标签页中打开}

在智能座舱等复杂系统开发中，设计评审有效性指标还需考虑跨学科评审的特点，例如人机交互、功能安全与信息安全等多领域专家的参与度及其对缺陷发现贡献的度量。^{7777Design Review Effectiveness Measurement in Complex Systems Engineeringonlinelibrary.wiley.com前往参考资料 ↓在新标签页中打开|7979Human Factors in Design Reviews for Automotive Human-Machine Interfacessae.org前往参考资料 ↓在新标签页中打开}

设计评审流程的持续优化，通常以可度量的评审过程指标为起点：把评审从依赖个人经验的判断，转为基于检查单、条目化表单的检查依据，使评审质量可以被记录、比较和追踪。^{1111以规范的技术评审模式促产品质量提升ep.cannews.com.cn前往参考资料 ↓在新标签页中打开}

航空工业千山电子结构部的实践表明，仅在里程碑节点开展设计确认评审，容易让缺陷沿研发链条逐级传递并被放大，导致返工、资源浪费和成本上升；其改进方向是把长周期里程碑评审拆分为短周期、微技术环节的评审，并落实评审问题的归零跟踪。^{1111以规范的技术评审模式促产品质量提升ep.cannews.com.cn前往参考资料 ↓在新标签页中打开}

该实践把评审流程的持续优化归纳为六条相互配合的做法：制度牵引、流程促效、依托规范、数字赋能、驱动激励、持续改善，并配套建立评审专家制度与评审专家管理制度，以保障技术评审的专业覆盖。^{1111以规范的技术评审模式促产品质量提升ep.cannews.com.cn前往参考资料 ↓在新标签页中打开}

有团队在瀑布式开发中把设计评审流于形式归因于评审本身缺乏工程化设计，而非瀑布模型或团队重视程度；其改进路径是明确评审的输入输出、设计评审流程、设定度量指标并持续迭代，同时按架构、契约、实现分层评审，使参会角色聚焦、时间压缩。^{6767瀑布开发中设计评审流于形式，我们改了worktile.com前往参考资料 ↓在新标签页中打开}

据同一团队的内部实践记录，在把设计评审改造为可执行、可追踪、可闭环的机制后，一个迭代周期内因设计缺陷导致的返工率从34%降到不足9%；该数据来自单一团队的自述，属于个案经验而非可外推的行业基准。^{6767瀑布开发中设计评审流于形式，我们改了worktile.com前往参考资料 ↓在新标签页中打开}

评审流程持续优化的常见闭环是：先定义评审的输入与输出，再设定可观测的度量指标，依据度量结果调整评审层级、检查单与参与角色，然后进入下一轮迭代；缺少度量环节时，评审改进往往退化为对流程形式的反复调整。^{1111以规范的技术评审模式促产品质量提升ep.cannews.com.cn前往参考资料 ↓在新标签页中打开|6767瀑布开发中设计评审流于形式，我们改了worktile.com前往参考资料 ↓在新标签页中打开}

IEEE 1028 是软件评审与审计领域的奠基性标准，它将评审划分为五种类型：管理评审、技术评审、审查（inspection）、走查（walk-through）和审计（audit），并为每种类型规定了入口/出口准则、角色职责与过程步骤。^{55IEEE Standard for Software Reviews and Auditsstandards.ieee.org前往参考资料 ↓在新标签页中打开}

IEEE 1028 最初于 1988 年发布，此后在 1997 年和 2008 年两次修订；2008 年版（IEEE Std 1028-2008）是目前被广泛引用的版本，其标题为《IEEE Standard for Software Reviews and Audits》。^{55IEEE Standard for Software Reviews and Auditsstandards.ieee.org前往参考资料 ↓在新标签页中打开}

在 IEEE 1028 的框架中，审查（inspection）是形式化程度最高的一类评审：由独立于作者的评审组长主持，评审员依据检查单逐项核对工件，并产出缺陷记录与返工验证记录；走查（walk-through）则形式化程度较低，通常由作者主导、以向同行讲解工件的方式发现问题。^{55IEEE Standard for Software Reviews and Auditsstandards.ieee.org前往参考资料 ↓在新标签页中打开}

ISO/IEC/IEEE 12207《系统与软件工程 软件生命周期过程》将评审活动纳入软件生命周期过程框架，把“评审”作为验证与确认过程以及技术管理过程中的支撑活动，要求对过程与产品实施评审并保留记录。^{66Systems and software engineering — Software life cycle processesiso.org前往参考资料 ↓在新标签页中打开}

ISO/IEC/IEEE 15288《系统与软件工程 系统生命周期过程》在系统层面同样规定了评审活动，与 12207 共同构成系统与软件生命周期过程的两项核心国际标准，二者在 2015 年前后分别完成修订并保持过程模型的对应关系。^{77Systems and software engineering — System life cycle processesiso.org前往参考资料 ↓在新标签页中打开}

ISO/IEC/IEEE 29148《系统与软件工程 生命周期过程——需求工程》对需求规格说明的评审提出了具体要求，包括需求应具备的必要性、无歧义性、可验证性、一致性、可追溯性等质量特征，这些特征常被直接用作需求评审检查单的条目来源。^{8080ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineeringiso.org前往参考资料 ↓在新标签页中打开}

CMMI（能力成熟度模型集成）在“验证”（Verification）与“确认”（Validation）两个过程域中要求组织建立同行评审（peer review）制度，并将其作为发现缺陷、降低返工成本的关键实践；CMMI 模型由 CMMI 研究所维护，现行版本为 CMMI V2.0/V3.0 系列。^{1717CMMI for Development, Version 1.3resources.sei.cmu.edu前往参考资料 ↓在新标签页中打开}

ISO/IEC 25010（系统与软件质量模型，属 SQuaRE 系列）定义了功能性、性能效率、兼容性、易用性、可靠性、安全性、可维护性和可移植性等质量特性，这些特性常被用作设计评审中判断设计是否满足质量目标的参照框架。^{8181ISO/IEC 25010:2011 — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality modelsiso.org前往参考资料 ↓在新标签页中打开}

在软件过程改进领域，同行评审的有效性有实证研究支撑：Fagan 在 1976 年提出的软件审查方法（Fagan inspection）报告了在 IBM 系统中通过正式审查显著提升缺陷发现效率的结果，该方法后来成为 IEEE 1028 中“审查”类型的实践原型。^{8282Design and code inspections to reduce errors in program developmentieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

ISO 9001《质量管理体系 要求》在“设计开发”条款中要求对设计和开发进行评审、验证和确认，并保留成文信息；这使设计评审成为质量管理体系审核中的可核查项，而不仅是工程团队的内部实践。^{2525ISO 9001:2015 Quality management systems — Requirementsiso.org前往参考资料 ↓在新标签页中打开}

在汽车电子领域，Automotive SPICE（ASPICE）过程评估模型在 SYS.2、SYS.3、SWE.1 至 SWE.6 等过程域中要求对系统需求、系统架构、软件需求、软件架构及详细设计实施评审并保留证据，评审记录是过程能力等级评定的重要证据之一。^{8383Automotive SPICE Process Assessment / Reference Model (ASPICE) — Process Reference Modelvda-qmc.de前往参考资料 ↓在新标签页中打开}

功能安全标准 ISO 26262 在概念阶段、系统设计、硬件设计与软件设计各阶段均要求进行评审与确认措施，并把评审列为验证手段之一；其第 2 部分（功能安全管理）与第 8 部分（支持过程）对评审的计划、执行与记录提出了要求。^{3232ISO 26262-2:2018 Road vehicles — Functional safety — Part 2: Management of functional safetyiso.org前往参考资料 ↓在新标签页中打开}

IEEE 1028 与 ISO/IEC/IEEE 12207、15288 等标准在评审的正式程度上采取分级思路：并非所有评审都需要完整的角色分工与记录模板，组织可根据工件的关键性与风险选择审查、走查或更轻量的技术评审。^{55IEEE Standard for Software Reviews and Auditsstandards.ieee.org前往参考资料 ↓在新标签页中打开|66Systems and software engineering — Software life cycle processesiso.org前往参考资料 ↓在新标签页中打开}

国际标准化组织发布的 ISO 9241-11 是可用性领域的奠基性标准，它将可用性定义为「特定用户在特定使用情境下，为达成特定目标而使用产品时所表现出的有效性、效率和满意度的程度」，这一定义成为后续大量可用性评审指南的共同参照基准。^{8484ISO 9241-11:2018 Ergonomics of human-system interaction — Part 11: Usability: Definitions and conceptsiso.org前往参考资料 ↓在新标签页中打开}

ISO 9241-11 在 2018 年发布了修订版，将「使用情境」扩展为「使用情境（context of use）」并强化了可用性与用户体验的区分，评审指南在引用该标准时需注明版本年份，避免新旧定义混用。^{8484ISO 9241-11:2018 Ergonomics of human-system interaction — Part 11: Usability: Definitions and conceptsiso.org前往参考资料 ↓在新标签页中打开}

ISO/IEC 25010 系统与软件质量模型（SQuaRE 系列）将「可用性」列为产品质量特性之一，并细分为可学习性、可操作性、用户差错防御、用户界面美观性和可访问性等子特性，为可用性评审提供了可逐项检查的维度清单。^{8181ISO/IEC 25010:2011 — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality modelsiso.org前往参考资料 ↓在新标签页中打开}

ISO/IEC 25062 规定了软件产品质量要求和测试的通用行业格式（Common Industry Format, CIF），用于可用性测试报告的结构化撰写，使不同团队、不同供应商之间的可用性测试结果可以横向比较，是可用性评审报告规范化的直接依据。^{8585ISO/IEC 25062:2006 Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Common Industry Format (CIF) for usability test reportsiso.org前往参考资料 ↓在新标签页中打开}

ISO 9241-210 给出了以人为中心的交互系统设计过程，明确要求在设计各阶段开展可用性评估并将评估结果反馈到设计迭代中，这为「可用性评审应嵌入设计流程而非事后补救」提供了标准层面的依据。^{5959ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

ISO 9241-110 专门针对交互原则（对话原则）作出规定，列出任务适宜性、自描述性、符合预期、可学习性、可控性、容错性、可定制性等七项对话原则，常被直接用作启发式可用性评审的检查表来源。^{3939ISO 9241-110:2020 Ergonomics of human-system interaction — Part 110: Dialogue principlesiso.org前往参考资料 ↓在新标签页中打开}

万维网联盟（W3C）发布的 Web 内容可访问性指南（WCAG）2.1 于 2018 年成为正式推荐标准，其可感知、可操作、可理解、健壮四项原则及对应的成功准则，被广泛用作可用性评审中可访问性维度的检查依据。^{8686Web Content Accessibility Guidelines (WCAG) 2.1w3.org前往参考资料 ↓在新标签页中打开}

WCAG 2.2 于 2023 年成为 W3C 正式推荐标准，在 2.1 基础上新增了聚焦外观、拖拽操作、目标尺寸（最小）等成功准则，评审指南若仍只引用 2.1 会遗漏这些新增检查点。^{8787Web Content Accessibility Guidelines (WCAG) 2.2w3.org前往参考资料 ↓在新标签页中打开}

中国国家标准 GB/T 18978.11 等同采用 ISO 9241-11，GB/T 18978.210 等同采用 ISO 9241-210，是国内可用性评审在合规与验收场景下最常引用的国家标准依据。^{6161GB/T 26773-2011 智能运输系统 车道偏离报警系统 性能要求与检测方法openstd.samr.gov.cn前往参考资料 ↓在新标签页中打开}

中国国家标准 GB/T 25000.10 对应 ISO/IEC 25010，规定了系统与软件质量模型，其中可用性相关子特性与 ISO/IEC 25010 保持一致，是国内软件产品可用性评审可引用的质量模型标准。^{6161GB/T 26773-2011 智能运输系统 车道偏离报警系统 性能要求与检测方法openstd.samr.gov.cn前往参考资料 ↓在新标签页中打开}

Jakob Nielsen 与 Rolf Molich 于 1990 年提出的启发式评估方法，经 Nielsen 后续归纳为十条可用性启发式原则，虽非正式标准，但已成为业界可用性评审最常引用的非正式规范之一，常与 ISO 9241-110 的对话原则对照使用。^{333310 Usability Heuristics for User Interface Designnngroup.com前往参考资料 ↓在新标签页中打开}

可用性评审指南在引用标准时存在一个常见误区：把 ISO 9241-11 的「可用性」定义与 ISO/IEC 25010 的「可用性」质量子特性混为一谈，前者是使用情境下的结果度量，后者是产品属性的分解，二者层级不同，评审检查表应分别对应。^{8484ISO 9241-11:2018 Ergonomics of human-system interaction — Part 11: Usability: Definitions and conceptsiso.org前往参考资料 ↓在新标签页中打开|8181ISO/IEC 25010:2011 — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality modelsiso.org前往参考资料 ↓在新标签页中打开}

对于智能座舱等车载交互场景，可用性评审还需参照 ISO 15008（车载视觉信息呈现）与 ISO 9241-3xx 系列（如 ISO 9241-303 对电子视觉显示的要求）等针对显示与视觉呈现的专项标准，这些标准对字体大小、对比度、信息密度给出了可量化的检查阈值。^{8888ISO 15008:2017 Road vehicles — Ergonomic aspects of transport information and control systems — Specifications and test procedures for in-vehicle visual presentationiso.org前往参考资料 ↓在新标签页中打开}

可用性评审指南通常建议将标准条款转化为可勾选的检查项，并为每个检查项标注对应的标准编号与条款号，以便评审记录可追溯、评审结论可复核，这一做法在 CIF 格式的测试报告中体现得尤为明显。^{8585ISO/IEC 25062:2006 Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Common Industry Format (CIF) for usability test reportsiso.org前往参考资料 ↓在新标签页中打开}