那天下午，我把一份脱敏后的四千多条病案数据扔给了AI，让它先帮我跑一轮质控看看效果。几秒钟后，屏幕上弹出了一个触目惊心的数字——错误率26.48%。

四千五百六十五条ICD编码记录，一千五百七十九个错误。我盯着这个数字看了很久。但我脑子里想的不是"这些错误怎么改"，而是另一件事——"如果每个月都要做这种质检，人工逐条看根本不现实。那，能不能让机器来替我干这件事？"

这就是整个故事的起点。这不是一个技术教程，而是一个真实的记录——一个非技术人员如何通过和AI的多轮对话，把一个模糊的想法变成一份清晰的架构设计，再一步步迭代成真正能用的工具。不美化过程，不省略波折。

4565条数据，1579个错误

我在病案室工作，日常工作里有一块叫ICD编码质检——简单说，就是检查医生填写的疾病诊断编码和手术操作编码有没有问题。这件事听起来简单，做起来特别磨人。每一条病案都要对照规则逐项核查，规则多、分类细，人工检查又慢又容易漏。

那天我手头有一批脱敏的数据，四千五百六十五条记录。我把它上传给了AI，想看看机器能发现什么问题。

更细的分布是这样的：格式校验抓出了875条错误，占了大头；文本合理性校验有574条；业务逻辑校验只有5条；完整性校验是0条。

这个分布本身就很有意思。格式错误最多，说明数据标准化程度不高——很多编码在书写规范上就出了问题。逻辑错误最少，只有5条，但这恰恰是最严重的那类——比如一个男性患者被编码了女性专属的疾病分类，这种错误一旦漏出去，病历质量直接不合格。

那一刻我做了一个判断：如果这件事能让机器来做，每个月的质检效率至少能提升一个量级。问题在于，我是一个完全不懂编程的人，这个工具从哪里来？

一个外行人的第一次"产品会议"

我没有去找程序员，而是直接跟AI聊了起来。现在回想，这大概是我人生中第一次开"产品会议"——只不过坐在桌子对面的不是产品经理，是一段对话窗口。

AI听完我的需求之后，很快给出了一套方案。它提出要建四大校验模块：完整性校验、格式校验、业务逻辑校验、文本合理性校验。每个模块下面又细分了不少子项。说实话，"正则""引擎"这些词我当时听着跟天书差不多，但整体的逻辑链条我是能判断的——先检查有没有填、再检查填得对不对格式、然后检查内容合不合理，这个顺序没毛病。

接着，AI画出了一个五模块的架构：配置文件、数据读取层、通用校验引擎、错误汇总输出层、扩展接口。还讨论了两种使用模式——业务人员用打包好的程序直接双击运行，技术人员用源码继续迭代。

到这里为止，我都是顺着AI的思路在听。直到有一个问题我觉得不对劲。

我说："数据、参数、结果都放Excel行不行？"

这句话改变了整个项目的走向。

为什么？因为我太清楚我们科室的工作场景了。同事们不会装什么开发环境，也不懂命令行。但他们都会用Excel，打开、填数据、保存、关掉——这是所有人的肌肉记忆。如果这个工具需要任何超出"打开Excel"和"双击运行"的操作，它在我们科室就活不过一个星期。

AI很快调整了方案。新的设计变得非常清晰：两个输入Excel文件——一个是病案原始数据，一个是质控参数配置（分八个工作表）；一个Python主程序；一个自动生成的输出Excel报告（包含六个工作表）。运行流程就四步——替换数据、修改参数、双击运行、自动出报告。

一个不懂技术的人，通过对话把自己的需求讲清楚，并且得到了一个自己能判断对错的方案——这是我跟AI合作的第一课。

131条规则的"翻译"工程

方案定了，接下来是规则。

我手头有一份质控规则文件，是我之前整理的。我一直以为里面大概就十条八条核心规则，撑死不超过二十条。结果AI读完之后告诉我：你这里有131条规则。

131条。覆盖诊断类110条、手术操作类、患者信息类、费用合规类。我之前以为的"十条规则"，只是我脑子里印象最深的那几条，实际上日常工作中需要遵守的规则远比我想象的要多。

接下来的工作，是把这131条用自然语言写成的质控规则，逐条"翻译"成程序能够读懂的结构化参数。每条规则都要拆解成九个字段：一级分类、二级分类、规则名称、触发条件、校验逻辑、错误提示、错误等级、规则依据、启用状态。

举个例子。"肝细胞癌的主诊断编码必须使用C22.0"——这条规则在我们科室人尽皆知，但如果让程序来执行，就得拆成：触发条件是"主要诊断包含肝细胞癌相关文本"，校验逻辑是"主诊断编码是否为C22.0"，错误提示是"肝细胞癌应编码为C22.0"，错误等级是"严重"，规则依据是"ICD-10编码手册"。

再比如"男性患者禁止使用女性专属编码"——触发条件是"患者性别为男"，校验逻辑是"是否存在女性专属编码分类下的条目"，错误提示要写清楚具体是哪个编码出了问题。

在这个过程中，AI还纠正了我一个关键误解。我一开始以为规则配置表里，一个工作表就是一个独立的校验引擎。AI告诉我不是这样——是同一类工作表共用一个校验函数。比如肿瘤业务匹配规则下有两个子表，但它们共享同一套校验逻辑。这个区别很重要，因为它直接决定了后续程序怎么写、怎么扩展。

我们也讨论了扩展模式。AI告诉我，以后如果要新增规则，90%的情况只需要在Excel里加一行就行，完全不用碰程序。只有当需要一种全新类型的校验逻辑时——比如从"格式校验"扩展到全新的"关联校验"——才需要写新代码。这个"九一开"的比例让我很安心，因为这意味着日常维护是我自己能搞定的。

我喊了"暂停"

方案有了，规则有了，架构也有了。按照正常的节奏，下一步应该就是让AI开始写代码了。但我在这个节骨眼上做了一件让很多人可能觉得奇怪的事——我喊了暂停。

我对AI说："我怕你一次生成的代码有问题。"

这不是因为我不信任AI。恰恰相反，正因为我打算认真用这个工具，我才对它可能出的问题格外警惕。一个有bug的程序比没有程序更可怕——它会给你一种"一切正常"的错觉，让你放松警惕，然后在你最想不到的地方出问题。病案质控这件事，宁可慢，不能错。

AI没有反驳我，也没有急着让我放心。它做了一件让我后来觉得非常专业的事——它提出了一套分五个阶段的渐进式落地方案。

第一阶段，先把131条规则全部标准化，填入设计好的Excel模板。这一步不涉及任何代码，纯粹是整理工作。第二阶段，做一个最小的测试Demo，只跑两三条规则，验证整个流程能跑通。第三阶段，分模块逐个开发校验引擎，做完一个测一个。第四阶段，把所有模块整合起来，加上主循环和病历分类逻辑。第五阶段，全量数据试运行。

除此之外，AI还配套设计了好几个"安全网"：详细的日志打印，让你能追溯每一条记录是被哪条规则判错的；开关配置，可以随时关闭某条规则或某个模块而不影响其他部分；隔离设计，各模块之间互不干扰，一个出了问题不会牵连别的；还有可回滚的设计，随时可以退回上一个稳定版本。

后来我反复回味这件事。作为一个不懂技术的人，我本能地做了一件产品管理里非常重要的事——风险管理。我没有能力去审查每一行代码，但我有能力去管理开发的节奏和容错机制。这个判断不需要技术背景，它需要的是对"事情可能出错"的清醒认知，以及"出错了怎么办"的预案思维。

AI帮我把这些本能的直觉，翻译成了可执行的方案。

五轮对话之后，我得到了什么

让我盘点一下这五轮对话的产出。

第一，一份标准化的规则模板Excel。八个工作表，每条规则九个字段，131条质控规则全部结构化完毕。第二，一套完整的架构设计——输入什么、输出什么、中间怎么处理、模块之间怎么衔接。第三，一个分五个阶段的渐进式开发计划，每个阶段的目标、验证方式、回退策略都写得清清楚楚。第四，一份131条规则的结构化清单，每一条都从"人话"翻译成了"程序能理解的语言"。

但我必须诚实地说一句：五轮对话之后，我没有得到一个能运行的程序。

我得到的是一张施工图纸。

这就好比你找设计师画完了房子的全套图纸——地基打多深、承重墙在哪、水电怎么走、每个房间的功能是什么——全都定好了。但房子一砖一瓦都还没开始盖。真正的编码工作，是在后续的对话中一轮一轮完成的，也就是前两篇文章里讲过的那个故事。

可别小看这张图纸。一个非技术人员，花了几天的工夫，通过跟AI的对话，完成了通常需要产品经理和架构师合作才能完成的工作——需求规格说明和系统架构设计。这是AI辅助开发最让我受用的环节。不是替你写代码，而是帮你把脑子里那个模糊的、不成形的想法，变成一个结构清晰、别人能看懂、你自己也能检验的蓝图。

第一版"垃圾"其实一点都不垃圾

后来这个工具真的做出来了。第一版跑起来的时候，说实话，问题很多——有些规则没覆盖到，有些判断逻辑有漏洞，输出报告的格式也不够好用。我当时跟同事开玩笑说，这玩意儿就是个"垃圾初稿"。

但这个"垃圾"一点都不垃圾。因为它定义了整个产品的骨架。后续所有的迭代、修bug、优化性能，都是在这个骨架上做的。如果没有前面那五轮对话打下的基础，第一行代码都不知道该往哪里写。

如果你现在也有一个模糊的想法——也许是一个工作中的痛点，也许是一个一直想做但觉得"我不懂技术所以做不了"的小工具——我建议你先别急着学编程。不妨先跟AI聊几轮，把你的想法说出来，让它帮你梳理、拆解、结构化。先把蓝图画出来。

画蓝图这件事，不需要你会写代码。你需要的只是清楚地知道自己想要什么，以及愿意花时间去把想法讲明白。

剩下的，交给对话。