名老中医治疗肿瘤的经验，一直是中医学术里最珍贵也最棘手传承的一部分。说它珍贵，是因为这些经验往往凝聚了名家几十年的临证智慧，是教材上找不到的活知识；说它棘手，是因为这些经验散落在海量的纸质医案、跟诊笔记里，学生想看看不全，老师想教教不透。我这次做的项目——python基于Python的名中医肿瘤治疗教学案例库设计与实现，就是想用Python把这一摊子事儿捋顺，让名老中医的肿瘤治疗经验从纸质堆里走出来，变成学生能检索、能对比、能统计、能启发思维的教学资源。
先说清楚这个系统能干什么：它是一个基于Python Web框架构建的案例库平台，核心资产是经过结构化整理的名中医肿瘤治疗真实医案。学生可以按癌种、证型、治法、方药等维度检索历史案例，可以上传一段自己收集的病例描述，系统自动推荐最相似的名医诊疗方案，还能通过统计图表直观地看到某位名医治疗肺癌的高频药物组合、核心治法分布。适合三类人参考：一是中医药院校里做教学管理或课程建设的老师，二是想系统学习名老中医经验的硕博研究生，三是准备做中医药信息化方向毕设或课题的开发者。
1. 项目整体思路与设计拆解
先把需求想透了再动手，是我做这类项目的习惯。这个案例库表面上是“中医 + 数据库 + Web”，但真正跑起来后你会发现，最难的不是写代码，而是想清楚一个问题：名老中医的诊疗经验，到底应该用一种什么样的信息结构去承载？
1.1 核心需求解析
我最初接触这个需求，是来自某中医院校临床教学团队的反馈。他们的痛点是：经典医案存量不少，但都是扫描件、PDF、甚至手抄本，学生查阅时只能一通翻，翻完也不一定抓得住要点；教师想在课堂上讲解“某名医治疗胃癌的经验”，却很难快速组织出一套有代表性的案例链条。
所以我们把需求拆成了四个层级：
第一层是基础归档需求，也就是把零散医案转化成可检索的结构化数据。这个层级最底层的字段，像患者性别、年龄、癌种、病期、舌脉、辨证分型、治法、方剂药物、疗效转归等，都要存下来。
第二层是分析挖掘需求。光能查还不行，教学场景下学生经常问“为什么这位名医爱用这个方子”“为什么这两个药总是搭配出现”。这就需要系统能对结构化数据进行统计和关联分析。
第三层是学习辅助需求。学生手里可能有一段自己的生活采集案例，或者老师给的一段模拟病历，学生想知道名医遇到类似情况会怎么处理。这就是案例相似度匹配功能。
第四层是展示呈现需求。中医经验是有规律的，但规律埋在一堆案例里，不直观。系统要能生成药物频率表、药对关联网络图、证型分布饼图等，辅助课堂讲解。
这四个层级决定了我的技术选型方向，也决定了数据库表的划分方式。
1.2 为什么选择Python体系
这个项目核心语言选Python，我是有明确考虑的。技术栈始终要服务于业务逻辑，而中医医案处理这种场景，Python的三板斧实在太匹配了。
第一，Web框架成熟。Django自带Admin后台，案例录入人员不需要会写一行前端代码就能完成医案录入，团队里的中医师、研究生都能直接上手。这个优势在“数据录入量庞大”的项目里是决定性的。
第二，文本处理生态强。医案本质上是临床文本，里面全是“低热”“纳差”“夜寐欠安”“舌淡胖有齿痕”这类中文医学短语。Python下有jieba分词、HanLP等成熟工具，配合TF-IDF、Word2Vec做检索与相似度，开发效率极高。
第三，分析可视化一条龙。用pandas做数据统计，配合pyecharts生成交互图表，不需要额外搭建前端图表服务。
我还对比过用Java Spring Boot + Elasticsearch的方案。论搜索引擎性能ES确实强，但说实话，教学案例库的数据规模通常在几千条量级，ES有点杀鸡用牛刀，而且团队里做后期维护的人不一定是Java背景。Python方案从开发到维护全程可以一个人扛下来，这是团队实际情况决定的。
1.3 系统架构设计
整个系统采用典型的B/S三层架构：
数据层用MySQL存储系统数据，包括案例表、医生表、药物表、辨证表、关联关系表等。之所以不选SQLite，是因为教学场景存在多人同时读写的可能——学生端检索和教师端录入同时进行时，SQLite会有锁竞争问题，换成MySQL后这个隐患就消失了。
服务层用Django 3.2版本，按业务拆分成案例管理模块、检索模块、统计分析模块和用户权限模块。检索模块我做了两层：基础维度查询走Django ORM，直接查数据库字段；全文检索和相似案例推荐走自建的轻量级索引服务。
表现层采用Django模板 + Bootstrap + ECharts。Django模板负责渲染案例详情页，Bootstrap负责布局适配，ECharts负责图表展示。这里我没有强行上前后端分离架构，因为项目的核心用户是教师和学生，他们需要的就是快速访问、快速出结果，而不是极致的交互体验。
整个项目拆解下来，核心工作量集中在数据模型的建立和检索算法的工程化上，接下来我详细拆这两个部分。
2. 数据模型设计：如何把中医医案变成可计算的结构化数据
数据库表设计是整个项目的灵魂。医案是叙事性文本，数据库是结构化存储，这两者之间的映射关系如果设计不好，后面的检索和分析统统会跑偏。
2.1 核心实体与表结构
我设计了六张核心业务表，外加三张维表脏器配型映射。
第一张是名医信息表。字段包括医生编码、医生姓名的脱敏化标识（系统界面展示时用“某名医A”“某名医B”代替真名，避免隐私问题）、所属流派、擅长癌种标签、学术传承脉络简述。这里特别说明一下，真实的系统里医生姓名是录入后经过脱敏处理的，界面层不会暴露患者与医生的真实身份信息，这是医案类系统必须过的合规关。
第二张是患者基础信息表。字段包括患者编码、性别、年龄区间（具体出生日期属于敏感信息，教学场景下只需要年龄段）、肿瘤类型（按ICD编码归一化）、TNM分期、初诊日期、来源说明。
第三张是诊疗过程表，这是核心表。字段包括所属案例编码、四诊信息（主诉原文、现病史、舌象、脉象）、中医辨证分型（如气阴两虚、痰瘀互结）、治则治法（如益气养阴、活血化瘀）、西医诊断补充说明、整体辨证分析文本。
第四张是处方明细表。字段包括处方编码、所属案例编码、药物名称、炮制规格（如炒白术而非白术）、剂量克数、配伍角色标识（君/臣/佐/使）、煎服法说明。这张表是最值得下功夫的，因为后续做药物频次统计和药对关联分析，全靠它提供干净数据。
第五张是疗效随访表。字段包括随访时间点、肿瘤标志物数值变化、主要症状评分变化、卡氏评分、总体疗效评价（稳定/部分缓解/完全缓解/进展）、患者反馈记录。
第六张是标签索引表。每一条案例可以挂多个教学标签，例如“扶正培本经典思路”“解毒散结代表方”“放化疗后调理”，方便教师按教学主题组卷。
这三张维表分别是证型维表、药物维表和治法维表，作用是统一口径。医案录入的人不同，同样一个证型可能写“气阴两虚”也可能写“气阴亏虚”，维表就是把它们映射到统一标准词上。
2.2 表关系设计要点
这里有一个我踩过坑的点必须提醒：不要试图用一对多关系硬绑处方和药物。
最开始我把药物字段直接设计成处方案例表里的一个“药物名称+剂量”的长文本字符串，比如“黄芪30g、白术15g、茯苓15g”，当时图省事，结果做统计分析时候想统计黄芪出现的次数，还得从长文本里正则匹配，费劲不说，还容易把“土黄芪”这种相近词匹配错。后来老老实实拆成两张表——处方主表+处方明细表，每一味药一行记录，多对多关系通过中间表关联。
正确设计的查询能力是几何级提升的。比如你执行一条Python查询语句“查询所有含黄芪且剂量大于30g的肺癌案例”，在结构化设计下，只需要跨关联两张表就能精确返回结果，响应时间在毫秒级。而如果当初沿用长文本方案，这个查询就得写成模糊匹配，还得解析字符串，不仅慢还有可能漏掉数据。
疗效表设计上也做了版本化的考量。同一案例可能会有多次随访记录，每次随访对应一行，然后用案例编码关联回诊疗过程表。这样学生可以按时间轴看到一个案例从初诊到复诊、从方药调整到疗效变化的完整链条，这恰恰是名医经验的可视化价值所在。
2.3 中医文本字段的标准化处理
无论数据模型设计得多干净，录入环节还是会出脏数据。不同录入员对同一个舌象描述可能写成“舌暗红”“舌质暗而红”“暗红舌”，不作标准化归一化处理，后面统计一个证型下的舌象分布就全是碎片。
我设计了一个录入清洗流程：录入员提交医案后不能直接进正式库，先进入待处理区。系统用关键词映射表做一轮自动归一化，比如把“舌质暗而红”“暗红舌”统一映射成标准词“舌暗红”；映射不了的，由医学专业审核员人工判定后补进映射表。这套流程跑满两个周期后，归一化效率能达到百分之九十以上，剩下的高频人工干预集中在新词上。
这里给计划做类似系统的朋友一个建议：中医文本标准化一定要在系统上线前花两周时间把高频词表梳理出来，宁可前面慢一点，也不要上线后对着脏数据发愁。具体词表来源可以结合院校内部教材术语规范，也可以参考行业标准里的中医学基础名词术语。我实测下来，占数据总量百分之八十的高频词汇都能覆盖到。
3. 检索与相似案例推荐：让经验能被快速找到和联想
数据都规整进库以后，下一步就是让用户能快速找到需要的案例。我在这部分实现了三个层次的检索能力，分别应对不同教学场景。
3.1 多维度组合检索的实现
第一层是基础检索。学生在检索页点选“肺癌”“乳腺癌”之类的肿瘤类型，再点选“气阴两虚”证型，系统通过Django ORM生成条件查询，SQL底层走联合索引，数据量在五千条以内时响应时间基本在两三百毫秒以内，体感上是秒开。
这里我在数据库里为“肿瘤类型+证型+治法”这三个字段建了组合索引。放着单列索引不用的原因是，教学场景最常见的查询模式就是“先定癌种，再定辨证方向”，组合索引直接命中这种查询模式。
第二层是全文检索。有的案例里主诉写得非常详细，患者说“胃脘部隐痛，食后益甚，嗳气频作”，学生想搜“嗳气”这个词，精确字段匹配会漏掉，因为“嗳气”隐藏在长文本里。对这种情况我引入了中文分词后的倒排索引方案。每一条案例的核心文本字段在录入时就会被拆成词项，存入独立的索引表里，查询时直接查索引表，速度比数据库模糊匹配LIKE快一个数量级。
jieba分词默认词库里没有几百个中医专有名词，比如“癥瘕”“痰核”“脉沉细”“舌下络脉迂曲”，默认分词会把它们切成碎片，导致检索结果不准确。解决办法是在加载分词器时追加自定义中医词典。这个词典我磨了大概四个晚上整理出来，把《中医诊断学》里的证候词、症状词、舌脉词全部规范化收进来。追加词典后实测召回率提升了三倍，这是值得的。
3.2 基于TF-IDF的相似案例推荐
这个功能的教学价值最高，也是我最想讲的。使用场景是：学生拿到一个“以胁肋胀痛、口苦咽干、食少纳呆为主要表现”的模拟病例，想知道名医过去遇到类似症状组合时怎么辨证、怎么开方。
实现路径分三步。
第一步，对历史案例库中的文本字段做TF-IDF向量化。以“症状+舌脉+中医诊断”三个文本字段作为向量来源，用jieba处理后生成每个案例的特征向量。
第二步，对用户输入的新病例做同样的预处理和向量化，然后计算它与库内每一条案例的余弦相似度。
第三步，按相似度分值从高到低排序，返回最接近的前N条案例，同时展示这N条案例的关键字段摘要——证型是什么、治法是什么、用了什么方子，让学生直观看到相似病例的治疗思路。
这里有一个实操细节的重要性秒杀算法本身的调优：TF-IDF向量化前一定要把“患者”“主诉”“脉象”“症状”这类在案例里普遍出现的低频干扰词清洗掉。这些词在所有文档里出现频率都高，但没有区分度，如果不加过滤，计算出来的相似度会被它们稀释，导致推荐结果趋同，两类明显不同的病例分值拉不开。后来我在预处理管道里加了一个停用词表，把中医医案里出现频率极高但承载信息量极低的词全部纳进去，推荐区分度立刻上来。
用实际案例来检验效果：一个“肺癌术后气短乏力、自汗盗汗、舌淡胖、脉虚缓”的病例，系统推荐出的历史案例普遍集中在“气阴两虚、肺脾气虚”证型域内，处方高频出现生黄芪、党参、白术、麦冬、五味子组合，这与名医的常规扶正思路高度一致。让我比较欣慰的是，在这个问题上，最开始有一个推荐结果对应的是“痰热壅肺”证型，一看就是相似度误判，排查后发现是停用词表里漏了“肺部”这个词，“肺部”在肿瘤类案例里太常见了，干扰了特征计算。补上后误判消失。
第二层的基础检索直接做SQL条件过滤的主要限制在于，它能解决的只是“已知维度、精确匹配”的问题，而临床思维往往是“模糊联想”，相似推荐补上了这个短板，教学场景下两者互为补充。
3.3 案例推荐里加了什么“教学思维”
单靠算法返回相似案例还不够，我还加了一个隐性干预：推荐结果里如果涵盖多个不同医家对同类病例的不同处理方式，系统会将这些案例的“治法差异点”高亮展示。这么做是为了避免学生在学习时只看到单一解法，忽略了中医“同病异治”的核心思想。
举一个具体例子，同样是“中晚期胃癌”案例，某位名医强调“健脾和胃、降逆止呕”，组方以六君子汤加减为底；另一位名医则侧重“软坚散结、活血化瘀”，方中大量应用了莪术、八月札、藤梨根。从相似度算法看，这两条案例与模拟病例的距离很接近，但治法的方向路径完全不同。教学时把这两条案例并排展示，学生立刻能建立起“辨证是灵活的、治法是多维的”观念。
这个设计思路不只是工程问题，更是教育问题。案例库的本质是帮学生建立中医临床决策树，而决策树的分支越多样化，学生的思维弹性越好。
4. 教学场景中的统计分析：从案例库里挖掘名医用药规律
案例库如果只能查和推荐，充其量是个高级文档库。要让教学效果升级，统计挖掘能力是绕不开的一环。这一部分我重点实现了三个子模块，每一个都是结合平时老师们在教学中反复追问的问题来设计的。
4.1 药物频次统计
“某位名医治疗肺癌最爱用哪十味药？”这个问题在教学中基本每次都会被问到。实现并不复杂：对处方明细表按药物名称分组，执行COUNT计数后按频次降序排列，再用pyecharts生成柱状图。
这里的数据口径要特别注意——统计单位到底是“药物出现的处方数”还是“药物出现的总次数”？比如一个处方里某味药写了两条记录（分两次加减法各出现一次），总次数统计会把某一味药虚高一次。要做教学排行榜的话，应该按“出现该药物的处方数占所有处方数的比例”来计算，才是真正反映用药偏好度的指标。我当时在这块改了三版口径，最终确定统一以处方数为分母计算频率，一线教师反馈这样统计出来的结果和他们的临床直觉最吻合。
一个真实的统计结果：在库内近百例肺癌案例中，“生黄芪”以超过百分之六十的频率稳居首位，其次是白术、茯苓、白花蛇舌草、半枝莲。这个结果呈现出来后，在教研组引发了很好的讨论——为什么扶正药和清热解毒药会高频同时出现？这正是名医治疗肿瘤“扶正抗癌并重”学术思想的量化体现。
4.2 药对关联分析
频次统计只能回答“哪些药常用”，回答不了“哪些药经常搭在一起用”。针对“药对”这个需求，我用Apriori关联规则算法处理处方明细表。
算法参数上，支持度阈值设置为0.1，置信度阈值设置为0.6。这个阈值选择是有讲究的，调得太低会产生大量无效组合，比如某两个生僻药同时出现两次就算强关联，对教学没有任何参考价值；调得太高又会漏掉有意义的组合。我拿人工核对的三十组已知经典药对做了验证，在这个阈值下，像“白术+茯苓”“黄芪+当归”“半夏+陈皮”这种组合全部命中。
关联规则的输出结果我会做一个清洗：删除在同一首方剂里本来就属于基础框架药的组合。比如“甘草”和任何药搭在一起置信度都很高，但在教学里谈不上“药对特色”，这种噪音不去掉，输出的列表就会被“甘草+某某药”刷屏。清洗之后保留的有效药对，再去和文献里记载的经典药材配伍规律做对比，发现系统挖掘出的规律与文献高度吻合，这个结果拿到教研会上展示很有说服力。
4.3 证型-治法-用药的交叉分析
这个模块的出发点来自教研室里一位老师的原话：“学生光知道用哪些药不行，还得知道在什么证下用这些药。”这就需要一个交叉分析视图，按证型分组，展示每个证型下的高频药物和常用治法。
实现逻辑是，先从辨证分型维表取到所有证型，然后按证型编码去处方明细表和治法表关联统计。最后生成一个多维表格和四象限图：横轴是证型，纵轴是药物或治法，气泡大小代表案例数量占该证型的比例。
这里要处理的一个统计陷阱是案例数量太少的证型会自动产生高频假象。比如某个证型下只有两个案例，某味药出现两次，频率就是百分之百，直接画进图表会把学生带偏。我加了一个最小案例数筛选条件，案例数少于五个的证型不参与交叉分析图表渲染，避免小样本造成的误导。这个细节也是后期根据一线教师的反馈补上的。
5. 实际开发过程与核心环节实现记录
理论和设计讲清楚了，接下来说说实际开发过程中那些具体到代码的环节，以及我在过程中做过的关键决策。开发的整体顺序是：先搭数据模型，再做录入模块，最后做检索和统计展示。
5.1 数据模型落地与迁移工具配置
我用Django的模型层来定义表结构。这里直接贴一个核心模型的核心字段片段，方便理解实际编码时的结构：
from django.db import models class TreatmentCase(models.Model): """名中医肿瘤治疗案例主表""" case_code = models.CharField(max_length=32, unique=True, verbose_name="案例编号") doctor = models.ForeignKey("Doctor", on_delete=models.PROTECT, verbose_name="名医") cancer_type = models.CharField(max_length=64, db_index=True, verbose_name="肿瘤类型") cancer_stage = models.CharField(max_length=32, verbose_name="分期") tcm_syndrome = models.CharField(max_length=128, db_index=True, verbose_name="中医辨证分型") treatment_principle = models.CharField(max_length=128, verbose_name="治则治法") tongue_sign = models.TextField(verbose_name="舌象") pulse_sign = models.TextField(verbose_name="脉象") chief_complaint = models.TextField(verbose_name="主诉") analysis_text = models.TextField(verbose_name="辨证分析") created_at = models.DateTimeField(auto_now_add=True) class PrescriptionItem(models.Model): """处方明细表""" case = models.ForeignKey(TreatmentCase, related_name="prescriptions", on_delete=models.CASCADE) herb_name = models.CharField(max_length=64, db_index=True, verbose_name="药物名称") dose_gram = models.DecimalField(max_digits=6, decimal_places=1, verbose_name="剂量克数") role = models.CharField(max_length=8, choices=ROLE_CHOICES, verbose_name="配伍角色")迁移的时候我遇到一个数据库兼容问题：MySQL 5.7版本对中文字符串建立索引的字节长度有上限，默认是767字节，而按UTF-8计算，一个字符占三个字节，三十个字符以上的字段就会报“Specified key was too long”错误。解决方案是执行手动迁移SQL，将涉及索引的字符串字段设置为最大字符数不超过四十，并统一设置字段的字符集为utf8mb4且排序规则为utf8mb4_unicode_ci。对剂量字段用Decimal而不是Float，是因为中药剂量在临床教学中必须精确到小数点后一位，任何浮点误差都可能造成方药还原失准。
5.2 医案录入工作台设计与验证流程
录入端我用Django Admin做了定制改造。默认Admin界面虽然可以直接用，但中医医案的录入字段非常多，一屏展示不全，录入员容易漏填。
我在Admin里做了三个优化：一是把字段按“患者信息”“四诊信息”“辨证论治”“处方信息”“疗效随访”五个分组进行折叠展示；二是必填字段用醒目标注，达不到必填校验不允许提交；三是增加了一个“校验提醒”按钮，点击后系统自动检查几个常见问题，比如“辨证分型是否与治法一致”“处方剂量是否在常规范围内”等规则。
校验规则里最有价值的是“证法一致性”检查。比如辨证分型写的是“气阴两虚”，治法却填“活血化瘀”，系统会弹出提醒让录入员复核。这个规则并不是简单禁止，毕竟临床存在兼夹证型的情况，但它能倒逼录入员更严谨地梳理自己的逻辑，为后续数据挖掘的质量打底。
录入流程上设置了双人复核环节：第一遍由团队里的研究生初录，第二遍由资深医师抽查审核后确认入正式库。这一步极其重要，医案数据质量直接决定了对名医经验挖掘结论的可靠性，录入环节的容错率应该接近零。
5.3 相似案例推荐接口的工程化细节
相似度计算模块我封装成了一个独立的服务类，不直接放在视图函数里，这样既方便在后台单独跑批量更新任务，也方便将来做接口复用。
工程上有一个性能问题必须处理：如果每来一个查询请求，都对全库几千条案例重新分词、重建TF-IDF向量再计算余弦相似度，耗时会是四五秒甚至更久，这在教学场景下是不可接受的。我的做法是提前做离线向量化：每次新案例入库时触发增量更新，为该案例生成特征向量并缓存；查询时只需要对输入病例生成一次向量，然后与缓存向量批量做矩阵点积运算。矩阵运算交给NumPy处理，几千条案例的相似度计算在一秒内能跑完。
为了防止个别案例文本过长导致矩阵维度爆炸，我做了特征维度裁剪。TF-IDF向量化时设置的最大特征数是一万，超出部分的低频词直接丢弃。实际运行中，案例文本的核心信息主要集中在几百个有效特征上，裁剪掉尾部低频词对推荐效果影响极小，但对性能提升是成倍的。
5.4 可视化模块与前端集成
统计图表我用pyecharts生成HTML片段后嵌入Django模板。药物频次统计图和药对关联网络图是使用频率最高的两个图。
药对关联网络图花了些心思。节点是高频药物，连线越粗代表关联规则置信度越高，节点颜色深浅代表药物使用频率高低。这张图表在课堂上的教学效果出乎意料地好——老师讲解时可以直接指向图上某条粗连线说“大家看，丹参和莪术的配伍，在活血化瘀类案例里置信度极高”，学生视觉记忆比背条目深刻得多。
图表数据我做了一个七天的定时缓存。因为案例库录入是持续性的，每周可能新增几例到十几例，统计结果不需要每时每刻精确刷新，但课上使用时要保证不是两周前的旧数据。所以定时任务每周日凌晨重新生成一次图表数据缓存，星期一早上一线的老师打开系统看到的就是最新数据。
6. 常见问题与排查技巧实录
做这类系统最容易被绊倒的不是复杂的算法，而是工程细节和领域知识结合处的坑。我把开发过程中遇到的有代表性的问题整理了五条，每一条都对应一个可复现的解决方案。
6.1 中文医案分词不准导致的检索召回率低
这个问题在初测阶段表现得很明显：搜索“痰”字时，应返回“痰湿蕴肺”的案例没有返回，却返回了大量包含“肺”的案例。排查后发现jieba把“痰湿蕴肺”切成了“痰湿”“蕴”“肺”，而查询词“痰”被当作单字处理，“痰湿蕴肺”案例中被切出来的词是“痰湿”而不是“痰”，匹配失效。
这个问题的解法前面提过，是装载自定义中医词典。词典构建我会推荐一个思路，不要闷头自行收集，可以让团队里的临床医师每人整理二十个他们平时最常用却不在标准分词库里的中医词条，集中汇总后去重，一天之内就能获得一份质量相当高的专业词典。上线分词后要做一次全量案例的检索回归测试，用二十组高频检索词逐一验证，确认无漏检之后才能让学生开放使用。
6.2 编码问题导致的前端页面乱码
项目部署到服务器时，一线教师反馈部分案例详情页面的生僻字显示成问号。排查后发现是MySQL连接字符集配置缺失。Django默认数据库连接字符集是utf8，但医案里会出现一些超过基础中文范围的生僻字，比如药材炮制术语里的特殊字形，这三个字节的unicode字符用utf8存不了。
解决办法是在数据库连接配置里显式写入字符集参数“utf8mb4”，并且把建表时的默认字符集也统一改成utf8mb4。修改完成后，做了一遍全库字符回归检查，生僻字全部恢复正常。这里提醒一点，改完连接字符集后要记得重启服务进程，我第二次遇到乱码就是改了配置文件忘了重启。
6.3 关联规则算法跑出异常庞大的无效集合
初版Apriori跑出来的关联规则有上万条，其中一半以上是无效噪音。问题主要出在两处：一是没有对手下药物做标准化时就执行了计算，“炒白术”和“白术”被看成两种药；二是算法把同一处方框架内的基础组合也当成“关联规则”列出来了。
修复方案是两条并进：药物维度表里建立了“药材标准名”字段，录入时如果药材炮制方法不影响核心功效归属，统一归并到标准名；输出结果再配合“去框架化”清洗，手动整理了一张不同意包含的基础框架药清单，程序在输出前自动剔除包含框架药的组合。这两步做完，有效规则占比提升了百分之七十以上。
6.4 案例详情页加载速度慢
后期入库数量突破两千条以后，部分详情页面出现明显卡顿。检查后发现，渲染一个案例的详情页面要关联医生表、患者表、诊疗过程表、处方明细表、疗效表五张表，Django ORM的N+1查询问题导致每次详情页渲染产生几十条SQL，数据库往返耗时极高。
这个问题经典到没有技术含量，但我确实没有在开发阶段尽早暴露它。方案是在详情视图里加上select_related和prefetch_related，一次关联查询把关联数据全部取回内存，页面渲染时间从两秒左右降到三百毫秒内。这里给所有做Web开发的朋友一个忠告，ORM性能优化不是后期调优的工作，在写最开始几个视图时就应该把查询数量打印出来看一下。
6.5 相似度推荐结果被高危词干扰的误判
这个在之前提到过，我再补充一个排查方法。当怀疑推荐结果异常时，先打印出相似度最高的前十条案例的特征关键词列表，与查询字段的关键词做对比，确认哪些词在主导相似度计算。我们的误判案例里，“肺部”这个词同时出现在大量肺癌、肺结节、肺部感染案例里，由于频率高，两边向量中都占了比较大的权重，才把一个痰热壅肺案例拉近了距离。加入停用词表后问题迎刃而解。
这类问题的定期排查可以放在每周的缓存重建任务后面，额外增加一条统计语句，输出推荐结果中相同癌种占比的分布情况。如果某类癌种的推荐结果里出现了比例异常的跨癌种案例，基本可以判定存在干扰词，值得系统性排查一次。
7. 实操总结与后续扩展思路
项目上线运行两个学期，从教学效果数据看，确实达到了预期目标。最直观的反馈是，学生在案例研讨课上的讨论深度明显增加。过去学生讨论名医经验时，泛泛而谈“老师用药很灵活”的多，现在能说清楚“某名医在气阴两虚型肺癌中高频使用黄芪、白术、五味子，并且与文献报道的益气养阴核心配伍高度一致”。这种从朦胧感觉到实证分析的转变，是这个案例库最大的价值。
我个人实操中体会最深的一点是：做中医药信息化系统，技术永远是配角，对中医理论本身的理解深度才决定系统的上限。如果你只是想做个展示提纲，花两个月抄一套通用管理系统就行；但如果你想做出对教学真正有用的工具，必须花一半以上的时间去和一线教师、临床医生泡在一起，搞清楚他们到底怎么思考、怎么提问、怎么教。
这个系统后续扩展空间还很大。一是引入知识图谱技术，把药物、证型、症状、疾病这些实体抽取成节点，构建名中医经验的语义网络，学生可以像导航一样从“肺癌”节点跳到“百合固金汤”节点再到“阴虚内热”节点。二是加入基于LangChain的智能问答，让学生用自然语言提问“哪些名医倾向于用虫类药治疗脑瘤”，系统自动检索案例库并用解析后的逻辑回答。三是把数据规模扩大到多个流派多个癌种后，可以做流派间对比分析，量化对比不同名医群体的用药偏好差异。
做这个项目前我从来没想过，Python和中医能碰撞出这么大的空间。技术工具箱里的Python是旧的，中医文献也是旧的，但把它们以教学案例库的形式重新组织起来后，产生的东西对一线教学是新鲜的、有用的。这大概就是做中医药信息化最迷人的地方——每一次让知识的获取少一点障碍，都是往前迈了一步。
到close()的TCP通信与避坑指南)
