一个周六下午，某三甲医院放射科医生打开Claude，输入了一段提示词：”帮我写一个Python脚本，读取我们科室的CT报告Excel表格，按照结节大小和密度自动分类，标记需要复查的患者。”

40分钟后，他得到了一个可以运行的脚本。第二个周末，他加入了数据库连接功能。第三个周末，他把它部署在科室的共享服务器上，供同事使用。

这个脚本没有经过任何监管审批。没有临床验证报告。没有软件版本控制。没有任何机构知道它的存在。但它每天在处理真实患者的数据，并在事实上影响着临床决策的优先级排序。

这不是假设场景。这是2026年临床一线正在发生的现实，而且规模远比任何监管机构意识到的要大。

第一章：AI编程民主化如何制造了一个新物种

门槛归零的技术拐点

理解这场变革需要先理解它的技术前提：AI代码生成能力在过去18个月经历了一次质的跃迁，而不仅仅是量的积累。

这种跃迁的核心不在于代码的语法正确率从85%提升到95%，而在于它跨越了一个关键门槛——非程序员用户可以通过自然语言描述需求，获得在特定场景下真正可用的代码，而不需要理解代码本身的逻辑。这两者之间的差距，在工程学上相当于从”计算器”到”自动驾驶”的跨越。

对于临床医生而言，这个拐点意味着什么？意味着他们不再需要雇用软件工程师，不再需要等待医院IT部门排期，不再需要填写采购申请，不再需要经历漫长的系统集成流程。他们需要的只是一个Claude订阅账号和一个周末下午。

Amazon Bedrock于2026年4月推出Claude Mythos Preview（受限研究预览），这一动作本身就是一个信号：更强大的模型能力正在持续向更广泛的开发者群体开放，而这里的”开发者”定义已经远超传统意义上的软件工程师（来源：Amazon Web Services官方公告，2026-04-14）。

临床医生的真实需求与现实痛点

要理解为什么临床医生会主动走上这条路，需要理解他们面对的系统性困境。

医院的正式IT系统通常存在3个结构性问题：

第一，响应周期与临床需求严重错配。 一个科室级别的数据分析需求，通过正式IT渠道通常需要3到6个月才能上线，而临床问题往往在数周内就需要答案。

第二，商业医疗软件的颗粒度无法满足亚专科需求。 市面上的医疗信息系统是为通用场景设计的，但一个专注于肺结节随访的放射科医生，或者一个专注于特定癌症队列管理的肿瘤科医生，需要的是高度定制化的数据处理逻辑，这些需求在商业产品中根本不存在对应模块。

第三，数据孤岛问题导致临床洞察无法自动化提取。 患者数据分散在HIS、PACS、LIS等多个系统中，没有任何现成工具能够按照医生的临床思维逻辑整合这些数据。

AI代码生成工具恰好精准命中了这3个痛点。它的响应周期是小时级别，它可以根据医生的自然语言描述生成高度定制化的逻辑，它可以帮助医生写出连接不同数据源的脚本。

从”个人工具”到”临床基础设施”的悄然演变

这里有一个关键的动态过程，也是整个问题的核心所在：医生自建工具不会停留在”个人工具”阶段。

一个有效的脚本会被分享给科室同事。一个被多人使用的脚本会被部署到共享服务器。一个稳定运行的共享工具会逐渐被纳入科室的日常工作流程。一个被纳入工作流程的工具会开始影响临床决策——哪些患者需要优先复查，哪些检查结果需要特别关注，哪些用药组合需要预警。

在这个演变过程中，工具的性质已经从”个人辅助”变成了”临床基础设施”，但它的监管状态从未改变——它始终是一个不存在于任何注册系统中的”个人脚本”。

这就是问题的起点。

第二章：SaMD监管框架的结构性盲区

FDA SaMD框架的设计假设

FDA对医疗器械软件（Software as a Medical Device，SaMD）的监管框架建立在一套明确的假设之上：开发者是具有质量管理体系的企业实体，开发过程遵循IEC 62304等软件生命周期标准，产品在上市前经过临床验证，上市后存在持续的不良事件监测机制。

这套框架的核心逻辑是”企业开发—注册审批—上市后监测”的线性流程。FDA的SaMD分类体系基于”intended use”（预期用途）和”significance of information”（信息的重要性）两个维度，将SaMD分为四个风险等级，对应不同强度的监管要求。

这套框架在设计时面对的是一个清晰的对象：有组织、有资源、有商业动机的企业开发者。

中国NMPA的医疗器械软件监管框架同样建立在类似的假设基础上，其《人工智能医用软件产品分类界定指导原则》明确要求申请者提供软件版本说明书、临床评价资料和软件描述文档，整个框架的隐含前提是申请者是一个具有法人资格的企业。

“个人工具”的灰色地带

现在，一个放射科医生用Claude生成了一个Python脚本，用于辅助肺结节分类。这个工具是否属于SaMD？

从技术定义来看，答案很可能是”是”。FDA对SaMD的定义是”intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device”——一个用于辅助临床决策的脚本，完全符合这个定义的字面含义。

但现实中，这个工具永远不会进入任何监管视野，原因有以下几点：

第一，没有申报主体。 FDA和NMPA的监管体系以企业注册为前提，一个个人医生不是监管对象，也没有申报义务的法律依据。

第二，”个人使用”的豁免空间。 监管框架通常对”个人使用”或”机构内部使用”存在某种程度的豁免或灰色地带，但这种豁免从未被设计用来覆盖事实上影响多个患者临床决策的工具。

第三，监管执法的可见性问题。 即使监管机构想要介入，他们也没有任何机制能够发现这些工具的存在。没有注册，没有上市公告，没有市场流通记录，这些工具完全在监管雷达之外运行。

第四，”intended use”的主观性。 一个医生可以声称他的脚本只是”个人学习工具”或”数据整理辅助”，而不是”辅助诊断工具”，这种定性的边界极其模糊，难以从外部判定。

监管真空的规模估算

截至本文发布时暂无公开数据能够精确量化全球范围内医生自建临床工具的数量和使用规模。但我们可以从几个维度推断这个问题的量级：

全球顶级医学中心和三甲医院中，具备基本数据分析能力的临床医生比例在过去5年显著提升，这一群体是最早采用AI代码生成工具的临床用户。AI代码生成工具的普及进一步将这个群体的边界向”零编程基础”的医生延伸。当工具的开发门槛降至接近零，”潜在开发者”的数量等于所有对数据分析有需求的临床医生，而这个数字以百万计。

这不是一个可以忽略的边缘现象。这是一个正在快速扩张的平行临床信息系统，它运行在正式监管体系的完全盲区之外。

第三章：AI可靠性危机如何将风险指数级放大

底层模型的不稳定性：一个被系统性低估的风险

医生自建临床工具的风险不仅仅来自监管缺失，还来自一个更基础的问题：这些工具所依赖的底层AI模型本身的可靠性存在根本性不确定性。

2026年4月，Anthropic面临大规模用户投诉浪潮。用户反映Claude的性能出现显著下降，包括推理能力退化、输出质量不稳定等问题，而Anthropic被指责在应对这些问题时缺乏透明度（来源：Fortune，2026-04-14）。The Register的报道更为直接，标题是”Claude is getting worse, according to Claude”——该报道指出，Claude自身在被询问时也承认了性能下降的问题（来源：The Register，2026-04-13）。

这不是一个孤立事件，而是揭示了AI模型作为基础设施的一个结构性弱点：模型性能不是静态的，它会随着模型更新、服务器负载、推理优化策略的调整而动态变化，且这种变化对用户而言几乎是不透明的。

临床场景下的风险放大机制

在一般软件应用中，底层AI模型性能下降意味着用户体验变差，这是一个可以接受的商业风险。但在临床工具的场景下，这个风险的性质发生了根本性变化。

考虑以下场景：一个医生用Claude生成了一个脚本，用于根据实验室检查结果计算某种风险评分。这个脚本在生成时被验证过，逻辑是正确的。但三个月后，医生在Claude的帮助下对脚本进行了”优化”，而此时Claude的推理能力已经出现了某种程度的退化，生成的”优化”代码引入了一个微妙的逻辑错误——比如一个边界条件的处理错误，导致某个风险等级的患者被错误分类。

这个错误不会立即显现。它会在临床流程中沉默地运行，直到某个患者因为被错误分类而受到伤害，或者直到某个细心的医生在对比数据时发现了异常。

更危险的是，这种风险的传播路径与传统医疗软件完全不同。传统医疗软件有版本控制，有变更记录，有测试流程。医生自建工具通常没有这些。一个”优化”过的脚本可能已经被分享给了10个同事，而没有人知道它在什么时候被修改过，修改了什么，是否经过验证。

透明度缺失的双重困境

Anthropic在处理性能下降投诉时被用户批评缺乏透明度，这一问题在临床场景下具有特殊的严重性。

在临床工具的使用链条中，存在两层透明度缺失：

第一层是模型服务商的透明度缺失。 当底层模型发生变化时，用户（包括用这个模型生成代码的医生）通常不会收到任何通知，更不会知道这种变化是否影响了他们已经生成并部署的代码的可靠性。

第二层是工具本身的透明度缺失。 医生自建工具通常没有任何文档记录其生成过程、所用模型版本、验证方法和已知局限性。这意味着当问题出现时，无法进行任何有意义的根因分析。

这两层透明度缺失叠加，创造了一个在传统医疗软件监管框架中从未出现过的新型风险模式。

第四章：治理框架的萌芽——来自非医疗领域的启示

AWS Agent Registry：集中式治理的基础设施雏形

2026年4月14日，AWS宣布Agent Registry在AgentCore中进入预览阶段，提供集中式Agent发现与治理能力（来源：Amazon Web Services官方公告，2026-04-14）。

这个产品的核心功能值得仔细拆解：Agent Registry允许组织对其部署的AI Agent进行集中注册，包括Agent的能力描述、权限边界、调用记录和审计日志。它解决的问题是：当一个组织内部存在大量AI Agent时，如何知道它们的存在，如何管理它们的权限，如何在出现问题时进行追溯。

这与临床AI工具面临的核心问题高度同构。医院作为一个组织，面临的挑战是：如何知道内部存在哪些医生自建的AI工具，这些工具在访问哪些数据，它们的行为是否在可接受的范围内，当出现临床不良事件时如何追溯工具的影响。

AWS Agent Registry的技术架构提供了一个可能的参考模板：不是通过审批前置来控制工具的开发，而是通过注册和监控机制来管理工具的运行。这种”先注册后运行”而非”先审批后开发”的逻辑，与临床AI工具监管改革所需要的方向高度契合。

Nava于2026年4月获得830万美元种子轮融资，其核心产品定位是防止AI金融Agent”失控”，通过构建行为护栏来控制Agent的操作边界（来源：Fortune，2026-04-14）。

金融Agent与临床AI工具的类比并不完美，但在风险控制逻辑上存在重要的结构性相似性：两者都面临AI系统在高风险决策场景中自主行动的问题，两者都需要在不完全限制AI能力的前提下建立有效的安全边界，两者都需要在出现问题时具备快速识别和干预的能力。

Nava的商业逻辑揭示了一个重要信号：AI Agent治理正在从”技术问题”演变为”商业机会”。这意味着有专业团队在投入资源解决这类问题，解决方案正在被商业化和标准化，而不是停留在学术讨论层面。

这对临床AI工具治理的启示是：不需要等待监管机构从零开始构建治理框架，可以借鉴和迁移其他高风险领域正在形成的治理工具和方法论。

Anthropic Project Glasswing：关键软件安全的技术路径

Anthropic推出的Project Glasswing聚焦于AI时代关键软件的安全保障（来源：Anthropic官方博客，2026年）。

“关键软件”（critical software）这个定语在临床AI工具的语境下具有特殊意义。医疗软件是最典型的关键软件之一——它的失效可能直接导致人员伤亡。Glasswing项目所关注的安全保障问题，与临床AI工具面临的安全挑战存在技术层面的交集：如何确保AI辅助生成的代码在关键应用场景中的可靠性？如何建立AI生成代码的安全验证机制？

这些问题目前没有成熟答案，但Glasswing项目的存在表明，AI公司自身也在认识到AI生成代码在关键场景中的安全问题，并开始在技术层面寻求解决路径。

对立视角的碰撞：开放还是管控？

在这个问题上，存在两种截然对立的立场，都有其内在逻辑。

支持开放的立场认为：医生自建工具是临床创新的重要来源，过度监管会扼杀这种创新能力，而临床医生本人对工具的局限性有足够的专业判断能力，不需要外部监管机构来替他们做风险评估。更重要的是，现有的正式医疗软件采购流程本身就是一种低效的官僚主义，它阻止了大量有价值的临床改进。

支持管控的立场认为：医生对软件工程风险的判断能力并不等同于他们的临床判断能力，一个优秀的临床医生完全可能对代码的边界条件错误、数据处理偏差或模型性能退化毫无察觉。患者无法对自己接受的临床决策中是否使用了未经验证的AI工具做出知情同意。当出现医疗不良事件时，现有法律框架无法追溯AI工具的责任。

我的判断是：这两种立场都在用错误的框架思考问题。问题不是”开放还是管控”，而是”什么样的治理机制能够在不扼杀创新的前提下建立最低安全标准”。现有的SaMD监管框架是为企业开发者设计的，将它直接应用于个人医生开发者是错误的工具选择。需要的是一套全新的治理框架，而不是在旧框架和无框架之间二选一。

第五章：监管真空的深层结构与系统性影响

为什么这个问题现在才变得紧迫？

医生自建临床工具并不是新现象。在AI代码生成工具出现之前，也有少数具备编程能力的医生会自己写脚本处理数据。但这个群体的规模非常小，因为编程能力本身就是一个高门槛筛选器。

AI代码生成工具的出现移除了这个筛选器。这不是线性增长，而是指数级扩张——潜在的工具开发者从”会写代码的医生”扩展到了”有临床数据需求的医生”，两个群体的规模差异可能是2到3个数量级。

这种规模的跃变使得一个原本可以被监管机构忽略的边缘现象，变成了一个需要系统性应对的结构性问题。

责任归属的法律真空

当一个医生自建的AI辅助工具导致临床不良事件时，责任归属是一个完全未解决的法律问题。

可能的责任主体包括：使用工具的医生（作为工具的开发者和使用者）、提供AI代码生成服务的公司（如Anthropic）、部署工具的医疗机构（如果机构知晓工具的存在）、提供底层数据的医院信息系统。

在现有法律框架下，每一个潜在责任主体都可以提出合理的免责理由。医生可以说工具只是辅助参考，最终决策是他本人做出的。AI公司可以说他们提供的是通用代码生成服务，不对具体应用场景负责。医疗机构可以说他们不知道工具的存在。这种责任归属的模糊性，在实践中意味着没有人对工具的安全性承担实质性责任。

这种法律真空不仅仅是一个理论问题。它意味着没有任何经济激励驱动工具的开发者（医生）去主动建立安全验证机制，因为不承担责任的人不需要为安全投资。

AI性能波动对临床工具的系统性影响

Anthropic Claude近期遭遇的性能下降投诉，揭示了一个在临床工具场景下具有特殊危险性的系统性问题：基于AI模型的工具存在隐性的”依赖性漂移”风险。

传统软件工具的行为是确定性的——相同输入产生相同输出，工具的行为不会因为时间推移而自发改变。但基于AI的工具（包括用AI生成代码的工具，以及工具本身调用AI API的场景）存在非确定性：底层模型的更新、服务质量的波动、推理参数的调整，都可能在用户不知情的情况下改变工具的实际行为。

在临床场景中，这种”隐性漂移”的危险性在于它很难被发现。一个风险评分系统的输出偏差，如果幅度不大，可能在很长时间内都不会触发任何警报，但它对患者群体的影响是累积性的。

数据安全的另一重危机

医生自建工具还带来了一个经常被忽视的数据安全问题。当医生将患者数据输入Claude或其他AI工具以生成处理脚本时，这些数据的隐私保护状态是模糊的。更危险的是，当脚本本身调用外部AI API时，患者数据可能在医生不完全理解的情况下被传输到外部服务器。

这不仅仅是技术问题，还涉及HIPAA（美国）、GDPR（欧盟）和中国《个人信息保护法》的合规问题。医生通常对这些法规的技术实现要求没有深入了解，他们可能在完全无意的情况下创造了数据合规漏洞。

第六章：解决路径——民主化不可逆，监管必须进化

为什么传统SaMD监管框架无法解决这个问题

在提出解决方案之前，需要明确为什么直接将现有SaMD框架应用于医生自建工具是行不通的。

现有SaMD框架的核心机制是”注册前审批”——工具必须在获得监管批准后才能上市使用。这个机制对企业开发者有效，因为企业有商业动机等待审批，有资源支付审批成本，有法律主体资格承担监管责任。

对于医生个人开发者，这些前提条件都不成立。一个医生不会为了在科室内部使用一个数据分析脚本而申请SaMD注册，就像他不会为了在Excel里建立一个计算公式而申请注册一样。强制要求注册的结果只有两种：工具继续在地下运行，或者医生放弃使用AI工具——后者对临床效率的损害可能大于前者对患者安全的风险。

注册制而非审批制：一个可行的替代框架

一个更现实的监管路径是建立”临床AI工具注册制”，其核心逻辑是：不要求事前审批，但要求事后可追溯。

这个框架的基本要素包括：

强制注册而非强制审批。 任何在临床流程中使用的AI辅助工具（无论是个人开发还是商业产品）必须在机构级别的注册系统中登记，记录工具的基本信息、使用范围、开发者身份和使用记录。注册不需要审批，但不注册的工具不得在临床流程中使用。

最低技术标准而非完整质量体系要求。 对个人开发工具设定一套简化的最低技术标准，例如：必须有版本记录、必须有基本的输入验证、必须有错误处理机制、不得在没有人工审核的情况下直接写入患者医疗记录。这些标准不需要像IEC 62304那样复杂，但能够防止最基本的技术失误。

机构级别的治理责任。 将监管责任从个人医生转移到医疗机构。医疗机构有义务建立内部AI工具治理流程，包括工具注册、使用监控和不良事件报告。这与医疗机构在其他领域（如医疗器械管理、药品管理）承担机构责任的逻辑一致。

模型服务商的透明度义务。 要求AI模型服务商（如Anthropic、OpenAI）在模型发生影响代码生成能力的重大更新时，向企业客户发出通知，并提供模型版本的稳定性承诺。这与软件行业的API版本管理实践类似，但需要在合同层面明确化。

AWS Agent Registry模型的医疗迁移

AWS Agent Registry的集中式治理架构为医疗机构内部的AI工具治理提供了一个可以直接参考的技术模板（来源：Amazon Web Services官方公告，2026-04-14）。

一个医院级别的”临床AI工具注册中心”可以参考Agent Registry的架构设计：提供工具注册接口，记录工具的元数据（开发者、用途、数据访问范围、版本历史），监控工具的运行状态和数据访问行为，提供审计日志供机构管理层和监管机构查阅。

这种架构的优势在于它不需要改变工具的开发流程，只需要在工具的部署和运行阶段增加一层治理层。对于医生开发者而言，注册一个工具的成本远低于申请SaMD注册，但对于机构和监管机构而言，这提供了足够的可见性来管理风险。

行业自律的可能性与局限性

除了监管层面的改革，行业自律也是一个值得探索的路径。医学学会和专科委员会可以制定”临床AI工具开发最佳实践指南”，为医生开发者提供技术规范和伦理框架。这种自律机制的优势是响应速度快、专业针对性强，不需要等待立法和监管机构的行动。

但行业自律有其固有局限性：它没有执行力，无法约束不遵守规范的个体，也无法解决责任归属的法律问题。行业自律最多能够提升工具质量的平均水平，但无法消除尾部风险——而在医疗场景中，尾部风险往往是最重要的。

因此，行业自律和监管改革需要并行推进，而不是相互替代。

结语：一场无法回避的制度性重构

这篇文章描述的问题没有简单的解决方案，因为它的根源是两种不可逆转的技术趋势的碰撞：AI代码生成能力的民主化（不可逆）和医疗临床决策的高风险性（不可改变）。

AI编程民主化的趋势不会因为监管机构的担忧而停止。Amazon Bedrock持续向更广泛的用户群体开放更强大的模型能力，AI工具的开发门槛将继续下降。试图通过技术限制来阻止医生使用AI工具，既不现实，也不正确——这些工具确实在提升临床效率，在某些场景下可能真正改善患者预后。

但”不可逆转”不等于”不需要治理”。核能的民用化是不可逆转的，但这并不意味着核电站不需要监管。互联网的普及是不可逆转的，但这并不意味着网络安全不需要法规。AI编程民主化同样如此——它的不可逆转性恰恰要求我们更认真地思考如何建立与之匹配的治理框架，而不是用旧框架勉强应付或者干脆放弃治理。

Anthropic Claude面临的性能下降危机和透明度批评，AWS Agent Registry的集中式治理探索，Nava在金融AI Agent领域的护栏实践，这些看似分散的事件，实际上都是同一个更大问题的不同侧面：我们正在进入一个AI系统深度嵌入高风险决策流程的时代，而我们的治理框架还没有为这个时代做好准备。

对于临床医生：继续使用AI工具提升临床效率，但需要理解你不仅仅是工具的用户，你同时也是工具的开发者，这意味着你对工具的可靠性承担着超出传统医疗实践的额外责任。

对于医疗机构：不要等待监管机构制定规则。现在就开始建立内部的AI工具治理流程，至少要知道你的机构内部存在哪些AI辅助工具，它们在访问什么数据，它们的行为是否在可接受的范围内。

对于监管机构：SaMD框架需要一个新的类别——不是为了降低对高风险商业AI医疗产品的监管标准，而是为了给医生自建工具提供一个现实可行的合规路径。注册制而非审批制，机构责任而非个人责任，透明度要求而非能力限制，这是改革的方向。

对于AI公司：你们的用户中包含大量临床医生，他们正在用你们的工具构建影响患者安全的临床工具。这不仅仅是一个监管合规问题，也是一个产品设计问题——你们有能力在工具层面提供更好的安全护栏，而不是把所有风险都推给下游用户承担。

这场制度性重构不会在一夜之间完成。但它必须开始，而且必须现在开始——因为在监管机构还在讨论框架的时候，那个放射科医生的脚本已经在运行了。

参考资料

  1. Anthropic is facing a wave of user backlash over Claude performance issues — Fortune, 2026-04-14

  2. Claude is getting worse, according to Claude — The Register, 2026-04-13

  3. AWS Agent Registry for centralized agent discovery and governance is now available in Preview — Amazon Web Services, 2026-04-14

  4. Nava raises $8.3 million in seed funding to keep AI financial agents from going off the rails — Fortune, 2026-04-14

  5. Project Glasswing: Securing critical software for the AI era — Anthropic, 2026年

  6. Amazon Bedrock now offers Claude Mythos Preview (Gated Research Preview) — Amazon Web Services, 2026-04-14

主题分类：企业AI落地