未来产品开发的新架构：AI Product Builder 的九阶段证据模型
从机会识别到规模化，说明 AI 产品每一阶段应交付什么证据，并以医学影像检查推荐为贯穿案例，区分工程验证与临床验证。
AI 产品的原型越来越容易做出来，但原型能回答的问题很有限。一次流畅的演示只能说明某条路径跑通，不能说明数据在别的医院也能用、错误结果会被拦截，或医生愿意在真实工作流中采纳它。
我把产品开发拆成九个阶段：Opportunity → Research → Hypothesis → Prototype → Validation → Build → Evaluation → Iteration → Scale。这不是规定每个团队必须照顺序走的流程，而是一张证据地图：每向前一步，都要说明已经知道什么、还不知道什么、谁负责判断是否继续。
九个阶段，各有一道问题
| 阶段 | 需要回答的问题 | 可审查的交付物 |
|---|---|---|
| Opportunity | 哪个具体工作环节存在损失或机会？ | 场景、目标用户、当前流程与问题基线 |
| Research | 数据、临床流程、制度和系统接口的真实边界是什么？ | 访谈记录、数据字段盘点、风险与权限清单 |
| Hypothesis | 产品改变哪一个决策或动作？怎样证伪？ | 使用场景、成功标准、失败和退出条件 |
| Prototype | 最小闭环能否运行？ | 可演示原型、输入输出样例、异常路径 |
| Validation | 真实用户能否理解并完成任务？ | 医生反馈、流程观察、修订记录 |
| Build | 能否稳定接入现有系统？ | 接口契约、版本记录、权限与审计设计 |
| Evaluation | 系统在预定人群与场景中是否可靠？ | 评测集、错误分类、分层结果与审核结论 |
| Iteration | 失败如何进入下一轮改进？ | 脱敏失败集、根因、变更和回归结果 |
| Scale | 多机构扩展后什么会变化？ | 本地映射方案、运维责任、漂移监测与回退计划 |
这些交付物有意把“做完功能”和“证明功能适用”分开。NIST 在 2023 年 1 月 26 日发布的 AI Risk Management Framework 1.0，以 Govern、Map、Measure、Manage 组织 AI 风险管理活动；它提供治理参考，而不替代具体产品的验收标准。NIST AI RMF 1.0
用检查推荐说明证据如何接力
假设产品目标是辅助医生选择医学影像检查项目。下面是设计示例，不是已经完成的临床试验或产品成绩。
在 Opportunity 阶段，不能只说“医生需要 AI”。应明确是哪类申请单难以选项：项目命名不统一、复杂扫描组合拆分困难、历史检查是否可用，还是临床问题与标准项目之间存在断层。不同问题需要不同解法，也需要不同的观察指标。
Research 要同时看三个现场：医生如何提出临床问题，RIS/HIS 如何维护本地项目，影像科如何审核检查方案。若手中的数据只有 RIS/PACS 检查记录而没有主诉、病史和禁忌信息，就不能据此宣称系统已经具备完整的临床检查推荐上下文。
Hypothesis 可以写得可证伪一些：在指定科室、指定模态和版本化标准目录下，系统为申请提供候选项目、理由和可追溯依据；遇到证据不足、项目不存在、规则冲突时停止自动推荐或交由医生判断。Top-1、Top-3、P95 等应先作为目标和测量口径，实际结果要等固定样本和测试环境验证后才能公布。
Prototype 的最小闭环可以是：输入临床问题 → 检索适用证据 → 匹配存在于当前标准库的项目 → 核查禁忌和组合规则 → 输出候选及拒绝理由 → 医生确认。原型必须展示“检索不到”和“检索到错误项目”这两条失败路径；证据不足时不应为了凑满三个候选而编造项目。
Validation 观察医生能否理解推荐理由、发现错误、修改选项并保留最终决定。Build 再解决真实接口、权限、日志、超时、恢复和幂等写入等工程问题。医生确认前的建议与确认后写入医嘱，属于不同风险等级的动作，不能把一次模型输出直接当成正式医嘱。
Evaluation 要分清三种证据
第一种是工程证据：结构化输出、标准编码、引用、延迟、重试和审计是否符合设计。
第二种是任务证据：在固定病例集上，候选项目及理由是否被专家接受；哪些部位、模态、人群或异常情形表现较差。这里需要说明样本来源、标注规则、可接受答案集合及分歧仲裁。
第三种是临床使用证据：目标人群和实际工作流中，系统是否产生预期的、可重复的临床价值，并且风险得到控制。IMDRF 于 2017 年 9 月 21 日发布的 SaMD 临床评价文件将临床关联、分析验证和临床验证分开讨论。这是评价思路的参考，不意味着所有检查推荐功能在各司法辖区具有相同的监管分类。IMDRF SaMD Clinical Evaluation
因此，“离线 Top-3 达到某个值”即便属实，也不能自动推出“已经完成临床验证”。
迭代与规模化的真正资产
一次失败至少应留下五项记录：输入条件、所用标准与知识版本、检索及规则决策、医生处理结果、归因和修复结论。随后将脱敏的最小复现样本放进回归集，验证修改是否修复原问题，又是否破坏其他病例。
跨院推广时，本地检查目录、收费关系、设备能力、接口和审批责任都会变化。可复用的是标准语义、规则与评测方法；需要逐院确认的是本地映射、数据质量、权限和工作流。没有这些证据，“在一家医院跑通”还不能等于“可以规模化复制”。
一张实际可用的发布卡
每次准备扩大试点或上线时，团队至少应提交：
- 范围：适用医院、科室、人群、模态与排除情形；
- 版本：模型、Prompt、标准目录、知识库、规则与接口；
- 结果：样本量、分层指标、高风险错误和失败处理；
- 责任：医生确认点、异常升级路径、回滚与监测负责人；
- 结论：通过、限制范围试用、补充验证，或暂不发布。
AI Product Builder 的职责，是让产品问题、工程实现和临床证据在同一张卡上对齐。每一阶段的目标不是产出更多文档，而是让下一步决策有足够依据，也让尚未得到证明的部分保持可见。
本文提出产品开发方法和设计示例，不报告既有项目的临床验证结果，也不提供个体诊疗建议。