一、ISO 9001:2015 8.3.4 标准原文

二、条款解读说明

2.1 8.3.4是设计开发阶段的“质量闸门系统”

如果8.3.2解决“怎么规划设计开发”，8.3.3解决“基于什么输入开始设计”，那么8.3.4解决的就是“在设计开发进行中，如何持续确认方向是对的、结果是可靠的、问题被及时收敛”。这也是为什么它成为整个8.3章节中最核心的控制条款之一。没有8.3.4，设计开发就很容易变成“做完再看”，问题只能在样机、试运行、量产、上线甚至顾客投诉阶段集中爆发。

因此，8.3.4本质上是在设计开发过程中设置一组质量闸门。组织不是等输出完成后才判断好坏，而是在关键节点通过评审、验证和确认三个层次不断检查：方向对不对、设计结果是否满足输入、形成的产品和服务是否真的适用于实际使用场景。三者组合，才能把设计缺陷尽可能挡在内部。

2.2 条款中的评审、验证和确认，关注点完全不同

2.3 “规定要达到的结果”是整个控制活动的前提

很多设计开发控制失效，不是因为团队没开评审会、没做测试，而是因为一开始并没有清楚定义“到底要达到什么结果”。若阶段目标、评审准则、验证通过标准、确认范围都不明确，控制活动就会变成主观判断和经验判断。8.3.4第一项要求其实是在提醒组织：控制活动必须围绕明确的目标和标准展开，而不是围绕形式动作展开。

这意味着，在每个关键设计开发阶段，组织都应清楚定义预期结果。例如，方案评审阶段要达到“需求转化完整、关键风险已识别、主要技术路线可行”；验证阶段要达到“关键功能、性能和接口满足输入”；确认阶段要达到“在真实或模拟真实使用条件下，结果满足预期用途”。没有这些定义，后续控制活动就缺乏客观抓手。

2.4 控制活动真正的价值，在于问题前移和闭环处理

标准不仅要求做评审、验证和确认，还要求对这些活动中发现的问题采取必要措施。这一点非常关键。设计开发控制的价值不在于“发现了问题”，而在于“发现后有动作、有责任、有关闭标准，并且必要时回溯前面的输入、策划或方案本身”。很多组织的问题是，评审纪要上写满意见，测试报告列了一堆问题，但项目仍然继续往前推进，问题没有得到真正关闭。

因此，8.3.4的成熟实施应包含问题台账、责任分配、整改验证、例外批准和再确认机制。否则，控制活动就会从质量防线退化为项目过程中的“形式存在”。

2.5 设计开发控制不等于“越晚发现问题越严格”

组织常犯的另一个错误，是把控制重心放在临近交付的阶段，前面较轻，后面极重。这样会导致问题在后期成批暴露，整改代价极高。更好的做法是前轻后不空、前期更关注方向和重大假设，后期更关注完整性和预期用途，形成逐级收敛的控制节奏。也就是说，控制不是越靠后越有效，而是越早发现越有价值。

三、实施要点

3.1 为每个阶段定义明确的评审目标和通过标准

设计评审不应只看“文件是否准备齐”，而应明确每个阶段究竟要判断什么。概念设计阶段看需求理解和技术路线，详细设计阶段看接口、参数和可实现性，试制或试运行前看转移条件和风险控制。评审目标清楚，评审才有真正价值。

• 按阶段建立评审清单，避免一次性泛泛而谈。
• 为关键评审项定义通过、附条件通过和不通过标准。
• 对未关闭问题明确禁止进入下一阶段的规则。

3.2 验证活动必须逐项对照输入要求

验证的核心不是“测过了”，而是“验证输出满足输入”。组织应建立输入和验证项的映射关系，确保每一条关键输入都能找到对应验证活动和验证结果。若输入无法被验证，往往说明输入定义不清；若验证项与输入脱节，则说明验证可能只是做了“看起来常规”的测试。

• 建立输入-验证矩阵，防止遗漏关键要求。
• 对法规和安全类输入设置更严格验证。
• 对异常验证结果保留偏差处理和再验证记录。

3.3 确认活动要尽量接近真实使用场景

确认的核心是预期用途，而预期用途往往只有在真实或足够接近真实的场景下才能被证明。组织可通过顾客现场试用、试产、试运行、用户验收测试、场景压力测试、长周期稳定性观察等方式进行确认。若确认脱离使用场景，即使内部测试结果很好，也无法真正证明结果在顾客环境中可行。

• 识别关键使用环境、用户行为和接口条件。
• 对服务类设计增加真实交互和场景确认。
• 对高风险项目将顾客或最终使用者纳入确认环节。

3.4 对发现的问题建立分级闭环机制

评审、验证和确认中发现的问题应根据严重度、影响范围和阶段位置进行分级处理。重大问题可能要求返回前一阶段重做输入或方案，中等问题可在当前阶段闭环，轻微问题可进入改进清单但需明确截止时点。没有问题分级，团队往往会陷入“小问题很多、大问题也被淹没”的状态。

• 建立问题分级标准和关闭责任。
• 重大问题关闭前不得进入下一阶段。
• 对重复出现的问题反向修订评审和验证机制。

3.5 将控制证据纳入项目节奏，而不是事后补记录

8.3.4明确要求保留这些活动的形成文件的信息。最好的做法不是在项目结束后补评审纪要和测试记录，而是把证据生成嵌入活动本身。例如，评审会议自动生成纪要，测试平台保留原始结果和版本，确认活动形成签认和问题清单。这样证据既真实，也能服务后续追溯和改进。

• 对评审、验证和确认活动使用标准记录模板。
• 尽量保留原始数据和关键判断依据，而非只留最终结论。
• 将问题闭环和阶段放行证据关联保存。

四、常用工具与实施方法

五、典型案例

案例一：医疗器械样机验证覆盖不足的修复

1. 背景：样机通过了功能测试，但在后续场景试验中暴露出关键安全问题。
2. 问题：验证活动没有逐项覆盖高风险输入要求。
3. 8.3.4行动：建立输入-验证矩阵，并将高风险项与DFMEA结果联动。
4. 结果：后续项目验证覆盖率明显提升，重大问题前移发现。
5. 启示：验证若不对照输入要求，容易测得很多却漏掉最关键的东西。

案例二：SaaS平台上线前缺少真实场景确认

1. 背景：新功能内部测试通过，但顾客一上线就出现权限和流程适配问题。
2. 问题：确认阶段没有纳入真实用户角色和实际业务场景。
3. 8.3.4行动：在上线前增加用户验收测试和典型业务流程确认。
4. 结果：上线稳定性和顾客接受度提高。
5. 启示：内部验证不能替代真实场景确认。

案例三：设计评审问题无人关闭导致返工

1. 背景：多个评审会上都提出同一接口风险，但项目仍推进到试产。
2. 问题：评审意见没有分级和关闭机制，只记录不跟踪。
3. 8.3.4行动：建立问题分级台账和阶段放行规则，重大问题未关闭不得放行。
4. 结果：关键问题被迫前移解决，后期返工下降。
5. 启示：没有闭环的问题记录，只会成为项目历史噪音，而不是控制措施。

六、成文信息管理要求

8.3.4明确要求保留设计评审、验证和确认活动的形成文件的信息。组织不仅要保留结果结论，还应在必要时保留关键输入、原始数据、问题记录和关闭依据，确保控制活动经得起追溯和复盘。

6.1 建议保留的核心记录

6.2 管控建议

• 关键验证和确认活动建议保留原始数据，而不仅是总结性报告。
• 评审问题应与后续更改和验证记录关联，形成闭环链条。
• 重大问题的例外放行应有清晰批准依据和补充控制措施。
• 确认活动若涉及顾客或最终使用者，建议保留参与和反馈证据。

七、常见误区及踩坑提醒