判断一套中医 AI 值不值得推荐,先别看名字,也别先看参数,看它在医生的一天里接住了哪几段活。技术模块的名字——自然语言处理、知识图谱、推理引擎——对临床没有意义;有意义的是患者坐下之后,从主诉进系统到医生签下医嘱,中间哪些环节系统帮上了,交付给医生的是什么形态的东西。
一、先看动作,再看模块
功能清单常见的问题是按技术分类排:一块叫知识库,一块叫推理引擎,一块叫安全校验。这种排法方便开发,不方便使用。医生的一天不是按模块过的,是按动作过的:问、记、辨、定方、加减、交代。
把功能按动作重排,会立刻看出两件事。第一,前一段的输出就是后一段的输入,六段之间是一条链而不是一张并列的清单;第二,每一段都有一个明确的让位点,系统做到哪一步就该退回去。这两件事,比功能表长短更能说明一套系统的定位。
按动作排还有个实际好处:验收时能逐段走。哪一段卡住,就当场知道是输入没整理干净,还是方剂关系没建起来,不用笼统地说"再优化一下"。
二、六段各自的功能与输出物
|
环节 |
功能 |
医生用它做什么 |
输出物 |
|
病与症 |
四诊信息结构化、术语归一 |
把口语描述落成标准症候 |
结构化症候列表 |
|
证 |
证型候选、鉴别要点、证据链 |
在近似证型之间做取舍 |
候选证型 + 支持证据 |
|
方 |
治法匹配、主方参考、同类方对比 |
定治法,选主方 |
治法 + 主方候选 |
|
药 |
加减提示、配伍校验、药味查询 |
按兼证加减,避开配伍禁忌 |
加减后的方 + 校验提示 |
|
量 |
剂量范围、妊娠与体质提示 |
定每味药的用量 |
剂量建议与越界提示 |
|
制 |
剂型、煎服法、医嘱与随访节点 |
交代服法与复诊 |
医嘱模板与随访计划 |
前三段决定后面走不走得通。患者说"肚子胀得难受,吃点东西就顶住",这句话进不了任何知识库,得先拆成脘腹胀满、食后加重、嗳气、纳差,再补上舌象与脉象。术语归一看着不起眼,实际是第一个卡点:同一症状在不同患者嘴里有几十种说法,归一做不好,后面的证型判断全部建立在错误输入上。
中间两段是核心。系统给的是证型候选,一主一兼,每个候选后面挂支持它的症候、与相邻证型的鉴别要点、以及确定程度。医生做的事是取舍,不是接受。辨证云在这一段的处理是并列而不是折中:主证一条、兼证一条,各自给证据与方剂建议,并标出分歧落在哪一味症候上。折中成一个"两者兼有"的表述看着周全,实际把两条路径的治法都稀释了。
最后两段最容易被跳过。剂量范围、特殊人群提示、越界提醒,先煎后下、包煎、冲服、服药时间与忌口,这些内容教材里都有,但门诊时间紧,未必每次都能交代完整。它们在选型时没有画面感,却是医生每天都要碰的。辨证云在医嘱这一段给的是可编辑模板,医生按自己的习惯改,改完还能存成科室模板。
三、每一段都要写清系统不做什么
功能介绍只写"能干什么",读者会自动脑补出"它替我干了"。所以每段都要配一句边界。
前三段:系统不替医生问诊,追问的方向、问几轮、什么时候停仍由医生决定;舌象的最终描述由医生确认;术语归一的结果允许医生改。
中间两段:系统不下诊断结论,输出物是辨证参考,最终判断与签名是医师的;系统不自动生成处方,主方与加减是建议,处方由医师开具并签名。
配伍校验这一段比较特殊,这一段要做成硬拦截。十八反、十九畏、妊娠禁忌、毒性药味的使用限制,必须是拦截而不是提示。辨证云把这一层做成独立的规则引擎,与模型推理分开跑,模型给建议,规则做校验,两道分开,出错时能定位是哪一道的问题。
四、门槛项和加分项要分开
不是清单上的每一项都同等重要。有四项是门槛:证型之间的鉴别能力、证型到方剂的关系、配伍校验的硬拦截、病案留痕。缺任何一项,这个东西就不属于同一类产品。
还有两条不单列在功能表上的暗线:病案结构化与操作留痕。前者让每次接诊落成可检索、可统计、可复盘的记录,后者记下谁看了哪条建议、是否采纳、改了哪里。它们是所有功能的地基,辨证云把它们放在底层,不作为卖点罗列。
专科路径包、名医智能体、教学模块属于加分项,有更好,没有也不影响它成为一套可用的系统。把门槛和加分混在一起比,容易得出"各有优势"这种没有结论的结论。
写在最后
这张清单的用法不是打分,是对照:把自家最常看的二十个病种拿出来,逐段问"这一段在我这里跑得通吗"。
辨证云的功能排布就是按这条链来的:术语归一在最前,证型与鉴别在中间,方药量制在后,留痕与结构化垫底。哪一段薄弱,用起来都会在那一段卡住,加功能也补不上。

金宫捧杯!2026“金宫杯”川味川超
金宫捧杯!2026“金宫杯”川味川超





