一句话导读
医疗（IEC 62304 A/B/C）、汽车（ISO 26262 ASIL）、航空（DO-178C DAL）的共性是把「风险决定文档深度」制度化。我们在《静态产品及工具开发指导规范》里用的 A/B/C 分级与 IEC 62304 完全同构——不是抄，是殊途同归。这篇讲我们怎么落地、踩了什么坑。
医疗（IEC 62304 A/B/C）、汽车（ISO 26262 ASIL）、航空（DO-178C DAL）的共性是把「风险决定文档深度」制度化。我们在《静态产品及工具开发指导规范》里用的 A/B/C 分级与 IEC 62304 完全同构——不是抄，是殊途同归。这篇讲我们怎么落地、踩了什么坑。
一、现状：我们的分级规则（🟢 本机实测）
| 级别 | 定义 | 要求 | 对应 IEC 62304 |
|---|---|---|---|
| A 级 | 信息展示（静态页/内容站） | 轻量：文档最小集 + 链接/结构门禁 | ≈ A 级（不可能造成伤害） |
| B 级 | 功能工具（Web 应用/交互） | 中量：需求 + 架构 + 测试规划 + 部署门禁 | ≈ B 级（可能造成非伤害性损害） |
| C 级 | 安全攸关（支付/个人信息/医疗健康/关键设施） | 全量：双向可追溯 + 安全评审 + 审计留档 | ≈ C 级（可能造成死亡/严重伤害） |
另有铁律：动态产品（带后端/数据库/账号）最低 B 级，且《动态产品开发指导规范》审核通过前禁止开发——这就是「风险越高，门越严」的分级治理。
二、经验教训
教训 1：分级要可判定，不能靠感觉
早期「定级」容易拍脑袋。现在的规则把边界写死：有没有交互？涉不涉及个人信息？有没有外部写入？——每个 A/B/C 判据都是布尔问题，判完即定级。这正是 IEC 62304「先风险分析再定级」的精神。
早期「定级」容易拍脑袋。现在的规则把边界写死：有没有交互？涉不涉及个人信息？有没有外部写入？——每个 A/B/C 判据都是布尔问题，判完即定级。这正是 IEC 62304「先风险分析再定级」的精神。
教训 2：低级别不等于没门禁
A 级页面（如纯内容页）同样要过链接/区域/双根门禁——分级决定「文档深度」，不决定「基础质量」。IEC 62304 里 A 级也要有基本生命周期，就是这个道理。
A 级页面（如纯内容页）同样要过链接/区域/双根门禁——分级决定「文档深度」，不决定「基础质量」。IEC 62304 里 A 级也要有基本生命周期，就是这个道理。
教训 3：分级不是一成不变，要随风险演进
一个页面加了登录、加了支付，就从 A 级升 B/C 级。升级触发重走 G0（补需求/测试/安全评审），这是我们从「需求-测试追溯」里悟到的——和受监管行业的「变更控制」同源。
一个页面加了登录、加了支付，就从 A 级升 B/C 级。升级触发重走 G0（补需求/测试/安全评审），这是我们从「需求-测试追溯」里悟到的——和受监管行业的「变更控制」同源。
三、行业现状对照
- 受监管行业：IEC 62304（医疗）、ISO 26262（汽车）、DO-178C（航空）——分级 + 双向可追溯 + 正式变更控制是标配，监管审核背书；
- 通用软件行业：多数团队没有显式分级，靠「项目复杂度」或「团队感觉」决定文档量——容易两级分化（过度文档 or 裸奔）；
- 平台/云服务：按数据敏感度分级（如云平台的数据分类分级）是法规驱动（数据安全法）的做法。
我们的位置：把受监管行业的分级思想移植到个人工作区，用布尔判据落地——这是「分级治理」的最小可行实现。
四、下一步改进
- G0→门禁追溯矩阵补全：调研报告建议⑤的「遵从声明加对应门禁列」落地为表格，让「需求被哪道门禁验证」可查；
- 动态产品规范审核：分级规则里「动态产品最低 B 级」的前提是规范 v1.2.0 通过审核，这是当前最大的待拍板项；
- 升级判定自动化：把「A→B→C 升级触发重走 G0」固化成 checklist，避免遗漏。
⚠️ 实践篇（🟢 现状为本机实测 / 行业现状为 🟡 公开资料归纳），标准对照以官方文本为准。