AI 辅助诊疗的边界与工程化落地：从一次“查药”争议谈起

一、争议的本质：不是“能不能用 AI”，而是“AI 是否可控”

近期一则讨论引发广泛关注：某医生在诊疗过程中使用通用 AI 对话工具查询药品信息，患者家属得知后拒绝接受其开具的处方。值得注意的是，讨论中真正刺痛公众神经的并非“医生用 AI”这件事本身，而是所用工具的行为特征与医疗场景的严肃性之间存在错配——当使用者期待的是一个能对结果负责、出错时有明确纠正机制的专业系统时，得到的却可能是一个语气轻松、对错误缺乏敬畏的通用聊天助手。

这个细节揭示了一个被长期忽视的工程问题：医疗场景对 AI 的要求，与通用对话场景对 AI 的要求，处于完全不同的可靠性等级。 前者属于高风险决策支持，后者属于低风险信息娱乐。把一个为后者设计的系统直接嵌入前者，即便偶有正确输出，其失败模式也是不可接受的。

因此，本文不讨论“该不该接受医生用 AI”，而是把它转换为一个更具建设性的技术命题：如何构建一个在医疗场景中可控、可审计、可复核的 AI 辅助组件？ 这才是开发者和企业用户真正需要回答的问题。

二、医疗场景对 AI 的四项硬性约束

要判断一个 AI 工具能否进入临床辅助流程，需要先明确约束条件。业界普遍认可的医疗 AI 应用原则，可以归纳为以下四点：

1. 准确性约束：错误代价不对称
在通用问答中，答错一次的代价接近于零；在用药咨询中，一次剂量或禁忌症的错误可能导致严重不良事件。这种代价不对称意味着，系统设计必须默认“宁可拒答，不可错答”，而非追求回答覆盖率。

2. 可解释性约束：结论必须可溯源
临床决策需要依据。一个只给出结论、不给出依据来源的系统，无法被专业人员审查，也无法在出现争议时自证。可溯源不是加分项，而是准入条件。

3. 责任归属约束：最终决策权在人
AI 在临床流程中的正确定位是“辅助”，而非“替代”。任何输出都必须经过具备资质的专业人员确认，系统设计上要保证这一环节不可被绕过。

4. 行为一致性约束：交互风格需匹配场景严肃性
这是本次争议中最直观的一点。一个在错误面前表现得轻描淡写的系统，会严重损害使用者对其输出严肃性的信任。交互层的语气、错误提示方式、不确定性表达，都属于系统可信度的一部分。

这四项约束共同指向一个结论：通用对话工具不能直接充当临床辅助工具，中间必须补齐一整套工程化能力。

三、工程化落地框架：把通用模型改造为可控组件

下面给出一套可复用的架构思路。该框架与具体厂商无关，属于通用技术方案，可在任意具备模型服务、向量检索与日志能力的平台上实现。

3.1 知识边界约束：用受控知识库限定回答范围

通用模型的参数化知识覆盖面广但不可控。医疗辅助场景应改为检索增强生成（RAG） 模式：模型不直接凭记忆作答，而是先从经过审核的权威知识库中检索证据，再基于证据生成回答。

示意性流程如下：

def answer_with_evidence(query, retriever, llm, threshold=0.82):
    # 1. 检索受控知识库中的权威条目
    candidates = retriever.search(query, top_k=5)
    # 2. 置信度过滤：低于阈值则不进入生成环节
    evidence = [c for c in candidates if c.score >= threshold]
    if not evidence:
        return {"status": "insufficient_evidence",
                "message": "未检索到充分依据，请转人工确认"}
    # 3. 仅基于证据生成，禁止模型自由发挥
    prompt = build_grounded_prompt(query, evidence)
    result = llm.generate(prompt, temperature=0.0)
    # 4. 强制附带回溯引用
    return {"status": "ok", "answer": result, "citations": [e.id for e in evidence]}

关键设计点有三处：置信度阈值前置过滤（证据不足时直接拒答）、低温度生成（减少发散）、强制引用（每条结论绑定来源条目）。这三者共同把“自由生成”压缩为“有据可查的受控生成”。

3.2 输出分级：用置信度驱动不同的交互策略

并非所有回答都需要同等强度的提示。可根据检索得分与模型自评，将输出分为三级，并匹配不同的交互行为：

置信等级	判定条件	系统行为
高	证据充分且一致	正常输出，附引用
中	证据存在但存在冲突	输出并显式标注分歧，提示复核
低	证据不足或缺失	拒绝作答，引导转人工

这一分级的意义在于：它把“不确定性”变成了系统的一等公民，而不是让模型用流畅的语气掩盖不确定性。这正是通用聊天工具最欠缺的能力。

3.3 审计日志：让每一次输出都可回溯

医疗辅助系统的日志不能只记录请求和响应，还需记录决策链路：

{
  "session_id": "xxx",
  "query": "某药物与某类药物的相互作用",
  "retrieved_ids": ["kb-1024", "kb-2048"],
  "confidence": 0.86,
  "model_version": "v3",
  "output_level": "high",
  "human_confirmed_by": " clinician_id ",
  "timestamp": "..."
}

审计日志的价值体现在三个层面：事后复盘可定位错误来源（是检索错了还是生成错了）、合规审查有据可依、模型迭代有真实样本。缺少这一层，系统就永远停留在“演示”阶段，无法进入生产。

3.4 人工复核闭环：把最终决策权固化进流程

系统层面应保证 AI 输出不直接触达最终决策，而是作为“建议”进入人工确认环节。工程上可通过状态机实现：AI 输出仅为 proposed 状态，必须由具备权限的人员将其转为 confirmed 后方可生效。这一机制把“人在回路”从口头原则变成了代码约束。

四、对开发者的实践启示

从这次争议中，开发者可以提炼出几条具有普适性的经验：

第一，场景严肃性决定交互设计。 在医疗、金融、工业控制等高风险领域，系统的错误提示、不确定性表达、拒答策略，与回答准确率同等重要。一个“嬉皮笑脸”的错误提示，在高风险场景中就是设计缺陷。

第二，可信度来自约束而非能力。 通用模型的能力上限很高，但可信度取决于你给它加了多少约束。检索约束、置信度约束、引用约束、复核约束，这些“减法”才是专业系统的核心价值。

第三，可审计性是生产化的分水岭。 没有决策链路日志的 AI 系统，无论效果多好，都无法通过合规与质量体系的检验。

第四，定位清晰比性能领先更重要。 AI 是辅助组件，不是决策主体。把这个定位用架构固化下来，既是对用户负责，也是对系统自身的保护。

五、结语

回到最初的问题：看诊时能否接受医生使用 AI 工具？从技术角度看，更准确的问法是——这个 AI 工具是否具备进入临床辅助流程的工程条件？ 是否限定了知识边界、是否分级表达不确定性、是否可溯源、是否有人工复核闭环、是否留下审计痕迹。

通用对话工具在这些维度上几乎全部缺位，这才是争议的真正根源。而对于开发者而言，这恰恰是一个明确的方向：把强大的通用能力，通过工程化约束，改造成特定高风险场景下可信赖的组件。 这件事的技术路径已经清晰，剩下的就是把它认真做出来。