又到月底质控季。

桌上摊着几百份病案，每一份都要逐条核查ICD编码的合理性——主诊断和手术操作是否匹配、编码是否符合规则、有没有漏编错编。规则手册翻烂了，标准也整理了好几版，但执行的时候，依然全靠一双眼睛一行一行地看。

这不是什么新鲜事。做病案质控的同行都清楚，质控规则是明确的，但执行质控的方式几乎是纯手工的。重复性高，容易漏看，不同人看同一份病案结论还不一定一致。

质控规则是病案室的核心资产，但执行规则的方式不该是纯人工。

前段时间我尝试了一条不同的路：用手边的AI助手，基于一份现成的Python质控程序和两份Excel，逐步改造出一个能批量跑的质检工具。没有系统学过编程，也没有找开发人员协助，整个过程就是跟AI聊天。

六个改动，六次对话，没有一个改动需要我打开代码编辑器。工具跑起来了，质检结果直接出在Excel里。

一、我手头有什么

说"造工具"听起来有点夸张，但其实起步条件并不高。我当时手里就三样东西：

• 一份现成的Python质控程序
  ——之前写好的，能跑，但有些地方不符合我们科室的实际需要。
• 一份原始病案数据Excel
  ——从HIS系统导出来的，字段固定，但编码格式需要处理。
• 一份质控参数配置Excel
  ——里面写好了各种质检规则，但规则的解析有些小问题。

程序能跑但不够用，数据格式固定但字段需要处理，参数表有规则但解析有bug。三样东西都不是完美状态，但合在一起，恰好是一个可以改造的基础。

我跟很多同行一样，日常最熟练的工具就是Excel。Python程序是别人的，我看过但看不太懂。AI助手是最近开始用的，之前最多用来查查资料、写写公文。

起点就是这样。不高，但够用。

二、六个改动，一次对话

接下来是我要讲的核心部分。从拿到程序到工具真正能用，一共做了六个改动。每个改动的经过都差不多：我描述问题，AI给方案，我跑一下看效果，不行就继续说。

1提取主诊断和主手术编码

我们导出来的病案数据里，诊断编码不是单独一列一个编码，而是用斜杠把好几个编码拼在一起的，比如一格里写着"A01/B02/C03"。但质控实际上只需要看主诊断——也就是斜杠分开之后的第一项。

我跟AI说的

"诊断编码这一列，编码之间是用斜杠分开的，但我只要第一个。能不能帮我把每个格子里斜杠前面的那个编码单独提出来？"

AI怎么解决的

AI在程序里专门加了一段数据处理逻辑，在正式质检之前，先把这些拼在一起的编码按斜杠拆开，只取第一项作为主诊断编码。主手术编码也做了同样的处理。之后所有质检规则都基于提取出来的主编码来跑，结果就准确了。

这个改动看起来简单，但它解决了一个很实际的问题：如果不去掉后面的附加编码，很多质控规则会误判。比如规则检查"主诊断是否属于某个病种"，但程序拿到的是一串编码，匹配就会出错。

2多条件规则引擎的解析bug

质控参数表里有一些比较复杂的规则，条件之间用竖线分隔。但有些条件的描述内容本身就包含了竖线，导致程序在切分条件的时候"切多了"，规则解析直接出错，该检查的没检查到。

我跟AI说的

"条件之间的竖线分隔有时候会误切割，有些条件本身内容里也有竖线，能不能只按前两个竖线切？"

AI怎么解决的

AI把程序里原来"无限制地按竖线切割"的逻辑，改成"最多只切两刀"——切完之后，后面不管还有没有竖线，都当作一个整体保留下来。同时，还顺便支持了中文分号的分隔方式，因为我们的参数表里两种分隔符都有。

这个改动提醒我一件事：AI不只是在执行我的指令，它有时候会比我多想一步。我说"只切两刀"，它不仅做到了，还考虑到参数表里混用中英文分隔符的情况。

3列表字段的空值判断报错

程序跑到一半崩了。报错信息我看不太懂，但我能描述清楚出错的场景：有些病案字段是列表格式的——一个格子里存了好几个值，程序在检查这些字段是不是空的时候直接报错退出了。

我跟AI说的

"有些字段是列表类型的，就是一格里有好几个值的那种，程序检查空值的时候崩了，能帮我看看吗？"

AI怎么解决的

AI在空值检查的地方加了一个判断：先看看这个字段是不是列表，如果是列表，就检查列表里是不是没有任何内容；如果不是列表，再用原来的方式检查。相当于给两种不同类型的数据各准备了一套检查逻辑，不会再因为类型不匹配而报错了。

说实话，我到现在也不完全理解"列表类型"和"普通类型"在程序内部有什么区别。但没关系，我能准确告诉AI"一格里有好几个值"和"程序在这里崩了"，它就能定位到问题。

4错误明细加上出院日期

质检跑完之后，错误结果会生成一份Excel。但我发现一个问题：结果表里看不到出院日期。质控发现问题之后，我想去原始病案里溯源，但没有日期，找起来很费劲。

我跟AI说的

"错误明细的表头里加一列出院日期，方便我溯源。"

AI怎么解决的

一句话的事。AI在导出结果的时候，把原始数据里的出院日期字段一并写进去了。

这是六个改动里最简单的一个，但它让我意识到一个关键点：你离数据最近，你就最清楚需要什么。开发人员可能觉得"报出错误就行了"，但做质控的人知道，没有日期的错误清单，回去找原始病案的时候要多花好几倍的时间。

5多进程并行加速

前面的改动做完之后，功能上没什么问题了。但数据量一大——几百上千条病案——单线程跑起来确实慢，要等好一会儿。

我跟AI说的

"数据太多了跑得慢，能不能同时用电脑的多个核心一起跑？"

AI怎么解决的

AI给程序加了一个"分块并行"的功能：把病案数据分成若干块，每块交给电脑的一个核心同时处理，最后把结果合并在一起。同时它还加了一个自动判断——如果数据量少，就用单线程跑，省得启动多进程反而浪费时间；数据量大了才自动切换成多进程。

改完之后，同样的数据量，跑的时间缩短了一大半。这个改动让我特别有感触：如果是我自己学编程，"多进程"这种概念可能要学很久才能用到。但通过AI，我只是说了一句"能不能同时用多个核心"，它就帮我实现了。

6双击运行闪退

最后一个问题很"低级"但很影响使用体验。在Windows电脑上双击程序文件运行，程序执行完之后窗口一闪就关了，根本来不及看结果提示。

我跟AI说的

"双击运行的时候窗口一闪就没了，什么都看不到。"

AI怎么解决的

AI在程序最后加了一行"暂停"的指令——程序跑完之后，窗口会停留在那里，等你按一下回车才关闭。这样就能看到运行结果了。

就这么一个小改动，让整个工具从"只有懂命令行的人才能用"变成了"双击就能用"。

AI不是替你写代码，是替你把业务语言翻译成机器语言。

三、整个过程我没有写过一行代码

回顾这六次对话，有一个共同的模式：

我描述问题（用日常语言）→ AI生成代码 → 我运行测试 → 有问题继续描述 → AI修改 → 直到满意。

我不需要知道什么是"字符串分割"，不需要知道什么是"多进程"，不需要知道什么是"空值检查的异常处理"。我只需要能准确地说出三个东西：现在是什么情况，我期望是什么效果，出错的时候是什么表现。

打个比方：你不需要会修发动机，但你可以准确告诉修车师傅"加速的时候有异响，大概八十码的时候最明显"。修车师傅听到这个描述，就知道该检查哪里。AI对我来说，就是那个"修车师傅"。

我不会写Python，但我能准确描述我需要什么——这比会写代码更重要。

仔细想想，这背后真正需要的能力是什么？不是编程能力，而是：对业务逻辑的清晰理解，对数据结构的熟悉程度。我知道诊断编码是怎么拼的，知道质控规则应该怎么拆分，知道错误清单里缺了什么字段不方便溯源。

这些恰好是病案室工作人员的强项。我们每天跟这些数据打交道，比任何程序员都更清楚业务逻辑长什么样。

四、这套思路能不能复制

能，但有前提条件。根据我的经验，至少需要满足三件事：

• 有一份现成的Python程序或模板
  ——不要求完美，能跑就行。完全从零开始让AI写一整个程序，对没有编程基础的人来说还是太难了。
• 有结构化的病案数据
  ——Excel也好，数据库导出的也好，关键是字段规整、格式统一。
• 有明确的质控规则
  ——你自己心里清楚"该查什么、怎么算对"，只是之前靠人眼查。规则越清晰，AI理解起来越准确。

坦白说，如果你的起点是"什么都没有，连Excel都不太熟"，那起步会难一些。但我建议的路径是：先从最简单的单规则检查开始——比如先只做"主诊断编码是否为空"这一条，跑通了再加第二条、第三条，逐步增加复杂度。

对于病案室的工作场景来说，Python加上Excel这个组合其实已经足够了。不需要数据库，不需要部署服务器，不需要跟信息科提需求排期。一份程序、两份Excel、一个AI助手，就是全部的工具链。

病案室的人离数据最近，离规则最近，反而最适合成为工具的"产品经理"。

质控员的武器不该只有Excel

我们病案室的人，花了大量时间在设计质控规则、培训编码员、跟临床沟通编码质量。这些是真正有价值的部分。

但"逐条比对编码"这件事，本质上是一个可以用机器完成的重复性劳动。质控员的精力，应该花在设计更好的规则、分析质控结果的规律、改进临床编码质量上，而不是花在用肉眼一条一条地对编码。

AI降低了自动化门槛。它不要求你变成程序员，只要求你清楚地知道自己的业务需求。而这一点，做了几年病案质控的人，其实都具备。

如果你也在做类似的ICD编码质控工作，也在用Excel一行一行地查，不妨试试这条路。找一个AI助手，把你的规则和需求用大白话告诉它，看看能走多远。

也许你会发现，造工具这件事，没有你想的那么难。