注册资料里的可用性工程文档,到底从哪写起?

一位做第三类高频电刀的硬件工程师，跟我复盘过一段真实经历。

去年年底，他牵头准备注册资料。样机功率拉到400W，CEO高兴得请全组吃火锅，说下一步就送注册检验。他一个画板的，哪懂什么体系文件？注册代理甩过来一张清单：设计输入输出、风险管理报告、可用性、有效期、软件描述文档……他全懵了。

真正让他崩的是体考那天。审核老师要设计开发追溯表，问到第3版电源改版记录。他硬着头皮把前面记录的模板改了改，补了一张签好字的风险评审。老师翻了两页，突然问：“这张评审跟上一张的签字笔迹怎么一样？”

他脸一下就白了。体系核查开了3个不符合项，注册申请被退回，几万受理费退不了，原来送检的第三方检测也要重新做。

这个场景，做过注册的人应该都不陌生。尤其是可用性工程文档——很多团队一听“可用性”三个字就头大：用户界面确认、形成性评价、总结性评价，到底怎么做？写什么格式？问谁谁摇头，查标准又看不懂。最后只能到处找模板，可模板里的公司编号和人名，替换比重新写还难受。

问题出在哪儿？一句话：你把可用性工程文档当成“写”出来的了。

为什么你写不出可用性文档？

带我的大姐说过一句话，我记到现在：“注册资料不是写出来的，是干出来的。”

那时不懂，直到自己补文档补到凌晨三点，对着模板发愁——填什么、谁来签、什么时候签，没人说得清。后来才明白，文件只是过程的影子。过程是空的，影子就只能靠编。编的东西，体考老师一眼就能看出来。

可用性工程文档不是一张表格，而是一条完整的证据链：证明你理解用户、识别了使用风险、迭代优化过设计、最终验证了产品的安全性。它应该跟着设计开发过程一起“长”出来，而不是最后一个月憋出来。

说到依据，要看两份文件。医用电气设备要提交可用性工程文档，依据是GB 9706.1-2020 和 YY/T 1474-2016。GB 9706.1 管的是通用安全，定义了“可用性工程文档”的概念；YY/T 1474 给的是过程框架，从使用规范到形成性评估、再到总结性评估，一步步都有章法。两者互补，缺一不可。（具体以最新法规为准。）

第一步不是写文档，而是定义“谁在用”

很多人拿到可用性文档提纲，第一条是“用户界面规格”，于是直接去画界面、写按钮说明。错了。

可用性工程的第一步，是写使用规范（use specification）。就三件事：谁用、做什么任务、在什么环境。

使用者是医生还是护士？是专业操作者还是患者自己？任务是一次性设置，还是连续监测？环境是手术室、ICU，还是家庭？这些没想清楚，后面的风险分析、任务分析全是空中楼阁。

YY/T 1474-2016 也把“应用规范”放在整个过程的起点。别嫌它简单，很多发补就是栽在适用范围描述不清晰、目标用户没写明白。你的产品是给经过培训的医生用，还是给没有医学背景的患者用，设计逻辑和文档写法完全不同。

形成性评估：不是考试，是草稿纸

使用规范定好了，先别急着写总结性报告——先做形成性评估（formative evaluation）。

形成性评估的目的不是“通过”，而是“发现问题”。拿原型或样机给代表性用户试，看他们会不会按错、看漏、误解。发现的问题记下来，改设计，再测。如此反复，直到用户能安全完成关键任务。

这个环节最容易犯的错，是把它当成走过场。有的团队找几个同事假装用户，随便点两下就算完成——这等于自己骗自己。

形成性评估的数据不需要有多漂亮，它的价值恰恰在于暴露问题。你发现的问题越多、改得越认真，后面的总结性评估才越可能一次通过。跳过形成性直接做总结性，失败的概率极高，重做一次测试的时间和成本，往往是翻倍的。

总结性评估：最容易被发补的环节

总结性评估（summative evaluation）是设计冻结前，对最终用户界面做的一次正式验证。它要回答一个问题：真实用户在真实场景下，会不会犯导致伤害的错误？

这一步有几个硬要求，踩中任何一条都可能被发补：

- 受试者不能用内部员工。必须找代表目标用户的外部人员，国内审评对此要求很明确。

- 方案里要有预先设定的接受准则（acceptance criteria），比如“严重使用错误为零”“关键任务完成率≥95%”。没有接受准则，测试结果无法判定。

- 主持人只能观察，不能引导。用户手里只有设备和说明书，你得像空气一样在旁边。一旦你开口提示，数据就废了。

- 测试要覆盖所有危害相关使用场景，说明书、标签、培训材料也要一并评估。

很多团队栽在没提前设定接受准则，或者受试者代表性不足，被发补后只能重做测试。时间、预算、信心，全被击穿。

文档怎么组织？让审评老师好找

经历完以上步骤，文档组织是个体力活。但体力活也有技巧。

一个比较好用的做法是：把整个设计过程中的可用性活动摘要、输出结果，汇总成一份可用性工程文件，结构类似风险管理报告。可以单独成册，也可以并进设计文件，关键是让审评老师顺着一条线找到证据。

建议按YY/T 1474 的框架来组织：

- 可用性工程计划

- 使用规范（用户、任务、环境）

- 用户接口规格说明

- 与使用相关的风险分析

- 形成性评估方案与报告

- 总结性评估方案与报告

- 剩余风险可接受性评价

提交国内注册时，还要对照《医疗器械可用性工程注册审查指导原则》，看审评视角的额外要求。指导原则和YY/T 1474 一个管审评、一个管过程，不能偏废。

再提醒一句：收到发补通知后，补充资料时限是365个自然日，不是工作日，而且必须一次性交齐。日子算错，注册失败，前面全白干。（以最新法规为准。）

这套做法怎么落地？

说实话，把上面这套流程走一遍，对初创团队来说并不轻松。尤其是那些项目已经跑到一半、历史文件散落各处的项目——网盘一份、微信聊天记录一份、离职同事电脑里一份，根本拼不齐完整的追溯链。

我见过最快的补救方式，是用AI 先把底子理顺：把散落的文件自动去重、按时间线排序，识别正式版和过程稿，生成一份缺漏清单——哪份原理图缺了对应的风险分析，哪次评审记录没有签字，一目了然。然后再按标准条款生成文档模板，标好需要谁签、附件放什么。两个星期，能补齐过去三个月憋不出来的体系骨架。

这正是唯智通Vizy Copilot 在做的事情。它是一款面向医疗器械行业的智能质量与注册文档辅助平台，公开能力包括：根据法规标准生成体系文档模板、梳理历史数据形成缺漏清单、按角色管理文档权限、全程留存审计日志，让设计开发过程真正可追溯。

说白了，就是帮你把“过程数据”变成“合规文档”。让可用性工程文档不是最后一个月憋出来的，而是整个研发过程自然长出来的。

AI 能帮你把文件管明白，但可用性工程的灵魂还是人：对用户的理解、对风险的敬畏、一次一次迭代的耐心。别指望 AI 替你思考，它能帮你的，是把你已经做过的事，清清楚楚地讲给审评老师听。

如果你也在为可用性工程文档发愁，不妨去唯智通Vizy Copilot看看。好工具的意义，是让你把时间花在真正重要的地方——设计好每一个按键，写清每一句说明书。

可用性的最终检验不在文档里，而在每天使用你设备的那双手上。