一个导航演示能够实时显示钻针，并不意味着产品研发已经完成第一步。真正需要先回答的是：谁在什么场景下使用，系统给出什么信息，信息失效时使用者怎样知道，以及团队准备承担哪些性能承诺。本系列第一篇从需求与边界开始，避免项目做到送检阶段才发现软件、附件、临床证据和销售描述讲的是四种不同产品。

系列定位：面向口腔手术导航设备研发与质量、注册团队，以非自主式导航辅助为主要讨论对象。资料检索日期为 2026 年 10 月 16 日，中国大陆监管语境为主。文中的流程、记录和试验情景为教学示例，未代表某一已注册产品，也不是患者手术操作指南。标准适用性、临床路径和指标需结合具体产品独立论证。

图 1：口腔导航研发01研发关系（原创研发示意）

一、把临床问题写成可观察场景

“提升精度”太抽象，难以直接成为设计输入。可以先描述工作场景：医生需要在既定影像与计划的参考下了解器械相对位置，助手需要完成附件准备，设备需要在有限空间内稳定工作。每种角色看到的信息和承担的操作不同，需求访谈不能只问最终决策者。

访谈应记录真实顺序、等待、返工与绕行方式。例如定位附件安装时间长，原因可能是固定方式、器械适配或信息引导，而不是算法速度。先保留观察事实，再形成问题假设，避免把最初想到的技术方案当成唯一需求。

二、预期用途决定证据边界

产品定义需要明确适用人群、解剖部位、手术类型、使用环境和目标使用者。普通种植导航与穿颧等复杂用途不能只通过增加一个软件按钮视为相同范围。预期用途扩大，可能同时影响性能试验、风险分析、临床评价与注册判断。

本文以非自主式导航辅助为主要讨论对象，医生仍进行手术决策和操作。若系统施加运动约束、驱动力或自动执行动作，需要重新分析控制权与失效后果。不要用“智能导航”这个宽泛名称掩盖技术与监管性质的变化。

三、导板、动态导航与机器人分别比较

静态导板、动态导航和机器人对工作流的影响不同。比较时可以看计划转移方式、术中反馈、附件准备、空间占用和失效处理，不应简单排列成技术等级。不同路径可能解决不同问题，也可能在特定场景互相补充。

需求分析应说明为什么选择当前路径，以及它新增了哪些负担。动态反馈依赖跟踪与配准有效，主动控制还会引入运动安全问题。若比较只记录优点、不记录准备和验证成本，后续商业假设与技术排期都会偏乐观。

四、系统边界包含附件与外部依赖

主机、跟踪器、参考架、标定组件、显示器、线缆和相关软件可能共同构成系统。牙科手机或影像设备是否属于产品组成、兼容设备还是外部输入，需要明确。边界不清会使接口故障在团队之间互相转移责任。

为每个外部依赖写出可接受条件，例如输入影像类型、定位数据字段、接口版本与兼容附件范围。更换电脑、相机固件或附件材料都可能改变系统表现。系统边界图应标注控制与数据流，而不只是列出采购清单。

五、把用户需要分解为设计输入

用户需要表达目的，设计输入表达产品必须满足的具体性质。一个需要可能对应多个输入：显示位置、数据新鲜度、失效提示、操作确认和记录能力。每条输入应能够找到验证方法，避免“界面友好”“定位稳定”长期停留在口号。

设计输入不必一开始就拥有最终数值，但未定指标需要责任人与关闭条件。团队可以先确定度量定义、试验环境和最差情况，再通过研究制定数值。先随便填一个漂亮指标，后面为了满足它不断改变测量口径，会破坏追溯。

六、性能承诺必须附带测量条件

“定位误差小于某值”需要说明测的是跟踪点、工具尖端、计划入口还是终点，采用何种坐标、样本与统计量。静态标记误差不能直接代表动态手术全过程。也要说明工作距离、姿态、负载和附件使用状态。

本系列不会给出通用临床合格阈值。研发团队应将性能要求与风险、用途和证据相连。对外表达时保留边界，不能把某次台架最佳结果升级成所有患者、所有医生和所有环境中的承诺。

七、失效场景是需求的一部分

遮挡、参考架松动、错误影像、旧标定和数据延迟都可能让界面仍有画面，却失去可靠导航含义。需求中应定义可检测异常、无效状态、恢复条件和用户提示。只写正常流程，会把最重要的安全交互留到最后补丁处理。

失效处理不能完全依赖用户记住说明书。需要结合本质安全设计、保护措施和信息提供分析控制顺序。对无法实时检测的失效，应明确剩余风险与核查流程，不能在界面上用一个绿色指示灯暗示所有误差都可被监测。

八、范围冻结不等于永远不变

阶段冻结意味着团队对当前输入形成受控基线，之后的变化可以评估、批准和追踪。它不意味着拒绝真实需求。变化应同时检查软件、硬件、风险、验证、标签与注册资料，避免需求更新只停留在聊天记录里。

例如增加无线跟踪器，表面上减少线缆，实际上还可能影响供电、时延、网络安全、EMC 和维护。评审不能只由提出功能的人判断工作量。与用途或性能有关的变化，应让相关专业共同参与。

九、原型研究与确认产品分阶段

早期原型可以探索跟踪方案、配准可行性与界面表达，但原型通常缺少完整环境控制和生产一致性。原型结果有助于做决策，却不应直接当作最终定型产品的验证。需要明确哪些研究将被重做，哪些有条件能够引用。

阶段计划可按可行性、工程样机、设计验证、使用确认和转产组织，每一阶段有入口与退出条件。不要只用日期作为里程碑。到了某个月不代表风险已关闭，样机做出来也不代表证据链已经完整。

十、研发组织需要共同语言

临床、算法、软件、机械、电子、质量与注册团队可以使用不同工具，但关键对象必须有共同编号与定义。需求、风险控制、设计输出和验证之间能够双向追踪，才方便发现遗漏与评估变更影响。

会议结论应留下明确动作与证据，而不只是“大家同意”。谁补充兼容清单，谁确定最差姿态，谁提供输入异常样本，都应有交付内容。项目管理的价值在于关闭不确定性，不是让表格看起来全部变绿。

可直接用于研发评审的工作表

以下是示例工作表，内容用于说明记录粒度，不是监管部门规定的唯一格式。实际项目应填写文档编号、版本、责任人与原始证据位置；未完成项保持开放，不能以模板存在代替工作完成。

评审对象	应保存的输入与证据	判定与后续动作
预期用途	记录目标用户、成人或其他人群范围、解剖部位与手术类型；保留需求来源和限制条件。	由临床、研发、质量与注册共同确认；超出基线的新用途进入变更评估，不通过销售措辞暗中扩大。
工作流	保存准备、影像导入、计划、配准、导航、异常恢复与结束的角色步骤；标记等待和返工。	每项关键任务都有输入输出和错误后果；无法观察的环节安排模拟使用研究，不能靠访谈猜测全部行为。
系统组成	列主机、定位器、参考附件、标定件与必备软件，说明外部影像及兼容手机的关系。	边界图与组成清单一致；兼容性由具体型号或条件表达，不把所有标准接口设备自动判为可用。
性能定义	写清误差对象、坐标、单位、统计量、工作空间、姿态、样本量依据与测量系统。	指标未定时列开放项；已有数值必须能回到研究与风险依据，不能只因竞品宣传出现同一数字而采用。
异常处理	记录遮挡、松动、超时、错配与重启时界面状态、用户动作和恢复前提。	检查异常是否可检测、能否误恢复；不可检测部分进入剩余风险说明和使用确认。
追溯关系	使用稳定编号连接用户需要、设计输入、控制措施、输出与验证报告。	发现一条需求没有验证或一项测试没有来源时，先解释缺口；不以批量补编号代替内容检查。
阶段评审	保留原型与定型配置差异、未关闭风险、试验失败和下一阶段准入条件。	通过、条件通过与拒绝有具体理由；条件通过必须有责任人和关闭证据，不无限期转移问题。
变更管理	记录新增功能对用途、接口、性能、培训、维护和注册资料的影响范围。	受影响专业参与，批准后更新基线与验证；没有影响分析的快速修复不自动进入受控发布版本。

附：可复现的研发自检示例

需求追溯与孤立证据检查

将用户需要、设计输入和验证编号连接起来，故意加入没有验证的需求与没有来源的测试。脚本检查引用关系，不判断需求内容是否正确，也不替代人工评审。

将代码保存为demo.py执行。本系列实际使用Python 3.11；数值示例导入NumPy，旋转示例还需要SciPy，其他篇使用标准库。示例仅使用合成数据或临时文件，代码输出是本任务的实际执行记录。索引检查不能评价证据内容，数值模型也不能代替真实设备验证。

from dataclasses import dataclass

@dataclass(frozen=True)
class Requirement:
    identifier: str
    user_need: str
    risk_controls: tuple
    verification_ids: tuple

requirements = [
    Requirement('REQ-IDENTITY','NEED-CORRECT-CASE',('RC-01',),('V-ID',)),
    Requirement('REQ-FRESHNESS','NEED-CURRENT-POSE',('RC-02',),('V-TIME',)),
    Requirement('REQ-RECOVERY','NEED-VALID-RECOVERY',('RC-03',),()),
]
verification_records = {'V-ID','V-TIME','V-ORPHAN'}

def inspect_traceability(items, available):
    identifiers = [item.identifier for item in items]
    if len(identifiers) != len(set(identifiers)):
        raise ValueError('Duplicate requirement identifier')
    missing_links = [item.identifier for item in items
                     if not item.verification_ids]
    referenced = {v for item in items for v in item.verification_ids}
    missing_records = sorted(referenced-available)
    orphan_records = sorted(available-referenced)
    return missing_links, missing_records, orphan_records

missing, broken, orphan = inspect_traceability(requirements,verification_records)
assert missing == ['REQ-RECOVERY']
assert broken == [] and orphan == ['V-ORPHAN']
fixed = requirements[:-1] + [Requirement(
    'REQ-RECOVERY','NEED-VALID-RECOVERY',('RC-03',),('V-RECOVERY',))]
assert inspect_traceability(fixed,{'V-ID','V-TIME','V-RECOVERY'}) == ([],[],[])
print('PASS: missing requirement links and orphan evidence are distinguishable')
print('Scope: identifiers only; evidence quality and clinical relevance need review')

PASS: missing requirement links and orphan evidence are distinguishable
Scope: identifiers only; evidence quality and clinical relevance need review

图 2：典型研发问题与证据检查（原创研发示意）

把方案落到项目：三次阶段评审

第一次：确认问题与范围

用真实角色和流程形成需要清单，逐项区分观察事实与方案假设。给预期用途、系统组成与不包含功能建立基线，并检查它们在产品说明、研发任务书和注册策略中是否一致。此时不追求填满所有数值，而应把尚未知晓的指标、测量方法和临床问题列为有负责人管理的开放项。

第二次：确认设计输入可验证

围绕每条输入问四个问题：测什么、在什么条件测、谁提供独立真值、失败后改变什么。同步检查风险控制是否进入输入，而不是停留在风险表。对于原型得到的结果，说明它与定型产品的配置差异，避免将早期演示结论直接作为后续放行依据。

第三次：确认变更与阶段出口

进入下一阶段前，复核未关闭项是否阻止下一步工作，以及是否需要限制使用。把试验失败、兼容性例外与临床反馈加入评审，而不只展示成功演示。每次范围变化都重新检查证据是否足够，确保团队交付的仍是同一款被定义和验证的产品。

四个容易被忽略的失败情景

需求只有“更精准”

算法团队优化配准残差，临床团队关注终点偏差，两者都认为完成任务，但度量对象不同。项目最终无法解释一个误差数字代表什么。

先统一入口、终点、角度或工具尖端等对象及测量条件，再分配模块指标。保留端到端验证，避免模块成绩替代整机结论。

新增功能被当成小改动

临时增加另一类手术计划，却沿用原有适用范围和验证样本，软件实现工作量小，证据缺口却很大。

将用途、算法、附件和临床路径同时纳入影响评估；功能开关不能替代范围论证，未支持功能不进入对外承诺。

原型演示被当作确认完成

实验室由开发者操作成功，实际用户在复杂环境中重复准备与配准仍频繁失败。

分别安排设计验证与面向预期用户的确认活动，纳入学习、错误恢复与团队配合，保留失败原因而非只统计成功时间。

附件不在研发责任范围内

手机夹具由外部供应，主机精度通过，但附件重复安装改变工具坐标，现场表现不稳定。

把附件与兼容关系纳入系统输入、风险和验证。供应商报告可以作为证据输入，但不能替代整机条件下的接口与重复安装检查。

本篇交付与适用边界

本篇交付的是产品定义和需求追溯方法，没有完成某款设备的分类界定、注册咨询或性能验证。分类与注册路径必须结合具体预期用途和组成确认。原型、台架、临床与获准上市属于不同证据层级，任何单一层级都不能自动替代其余工作。

对研发结论应区分：设计已经说明、验证已经通过、临床证据已经支持、注册已经获准和市场假设已经被检验。这些状态不能相互替代。失败原始记录、异常处置和版本差异应与成功结果一并保存，便于后续设计更改和上市后调查。

参考资料与查阅方式

医疗器械监督管理条例（国务院令第739号）

YY/T 0316-2016 标准题录与范围

医疗器械软件注册审查指导原则（2022年修订版）发布信息

引用的法规、标准题录与官方政策按所列来源核对。指导原则提供审评思路，不能直接等同于强制性标准；标准题录核对也不代表已经完成全文条款适用性分析。涉及具体申报或采购时，应复核届时有效版本及所在地执行要求。

写在最后

“纸上得来终觉浅，绝知此事要躬行。”

—— 陆游《冬夜读书示子聿》