夜雨聆风初衷是为了将我爱人从看完病人后填写病例的繁琐工作中解放出来，能更好的休息
背景
口腔门诊的日常工作有一个突出矛盾：知识要求高，但临床医生的时间有限。
一个全科牙医需要掌握的学科涵盖牙体牙髓、牙周、修复、种植、正畸、儿牙、口腔外科等 15+ 个方向。每个学科都有指南、决策树、鉴别诊断要点需要记忆。临床上遇到复杂病例时，医生要么靠经验硬扛，要么翻纸质资料——效率低，风险高。
更棘手的是病例书写规范。一份合格的口腔病历需要包含主诉、现病史、既往史、口腔检查、辅助检查、诊断、治疗计划，还要遵循 SOAP 等结构化模板。手写病历费时费力，口述又容易遗漏关键信息。
这篇文章介绍一个真实的使用场景：利用 OpenClaw 构建口腔门诊知识库，实现智能化病例编写辅助。 整个系统在 macOS 本地运行，数据完全可控。
一、知识库的整体结构
知识库存放在本地，按口腔医学学科分为 21 个子目录：
dental/├── 00-索引与总览├── 01-口腔解剖与组织学├── 02-牙体牙髓病学├── 03-牙周病学├── 04-口腔修复学├── 05-口腔种植学├── 06-口腔颌面外科学├── 07-口腔正畸学├── 08-儿童口腔医学├── 09-口腔黏膜病学├── 10-口腔放射学├── 11-口腔预防医学├── 12-口腔麻醉与镇痛├── 13-口腔材料学├── 14-口腔病理├── 15-诊所沟通与转诊指南.md├── 16-口腔用药规范.md├── 17-术后医嘱与复诊管理.md├── 18-病例分析与决策参考.md ← 核心文件├── 19-CBCT与口腔影像阅片规范.md├── 20-橡皮障与院感控制规范.md├── 21-口腔摄影与病例记录规范.md ← 核心文件├── 23-诊所标准化接诊与治疗计划模板.md ← 核心文件└── 诊所经营与患者管理.md学科知识以 Markdown 文件形式存储，结构清晰，便于索引和检索。每个文件都包含该学科的核心知识点——以 18-病例分析与决策参考.md 为例，文件包含：
常见症状鉴别诊断（牙痛、牙龈出血、口腔溃疡、牙松动、牙龈肿胀） 复杂病例决策树（保牙 vs 拔牙+种植、重度牙周炎治疗流程、种植决策） 临床检查清单（牙髓牙周联合病变检查7项、种植前评估10项） 转诊边界判定（牙体牙髓/牙周/修复/外科的转诊指征）
二、病例报告填写：一个真实的痛点
2.1 原始表单长什么样
门诊病例报告（口腔科门诊病历）包含以下区块：
基本信息：姓名、性别、年龄、日期、电话
主诉（CC）：患者自述的主要不适
现病史（HPI）：
部位（Location） 症状（Symptoms） 时间（Duration） 性质（Character） 加重因素（Aggravating factors） 缓解因素（Relieving factors）
既往史（PH）：
用药史 过敏史 手术史
口腔检查：
牙位、探、叩、松动度、牙龈、修复情况
诊断
治疗计划：次数 + 具体计划内容
每次看完病人，医生都需要手动填写这套内容——既费时，又容易遗漏。
2.2 实际对话：医生想要什么
每次看完病人之后，都需要手动填写其中的内容，现在需要借助AI来简化这个病例的填写过程。
表单复杂度分析：
三、解决方案：对话式病例收集
3.1 三种方案对比
以下是 AI 给出的三种方案，我这里接入的 IM 工具是 QQ：
推荐采用方案 A：纯对话式
工作流程：
医生（QQ） AI 最后─────────────────────────────────────────────────────────────────────────"患者牙疼三天了" → 引导补充关键问题 → 生成规范病历"左边上面疼" → 确认部位、程度 "喝冷水更疼" → 判断可能原因 生成完整病历 → 你复制到系统3.2 对话示例
医生输入：
张大爷 男 65岁 牙疼三天 左上后牙 喝冷水更疼 有高血压
AI 输出：
═══════════════════════════════════════【门诊病例】───────────────────────────────────────姓名：张XX 性别：男 年龄：65岁电话：/主诉：左上后牙疼痛3天现病史：患者3天前出现左上后牙疼痛，冷刺激加重， 无自发痛及夜间痛。既往史：高血压病史，否认药物过敏史口腔检查：26 牙合面探(+)，冷测敏感诊断：26 牙髓炎？治疗计划：RCT+冠修复═══════════════════════════════════════3.3 病例编写过程：从接诊到记录
标准化接诊流程（6步法）
基于 23-诊所标准化接诊与治疗计划模板.md，新患者接诊遵循以下流程：
SOAP 结构化病历
21-口腔摄影与病例记录规范.md 中定义了标准的 SOAP 病历格式：
S（Subjective）主观： 主诉： 现病史： 既往史： 系统回顾： 过敏史：O（Objective）客观： 口腔检查： 牙位检查： 牙周检查： 黏膜检查： 颞下颌关节： 咬合检查： 辅助检查： X线片： 模型：A（Assessment）评估： 诊断： 问题列表：P（Plan）计划： 治疗计划： 急性问题 → 必须治疗 → 建议治疗 → 择期治疗 →鉴别诊断决策树
以 18-病例分析与决策参考.md 中的牙痛鉴别为例：
文件中还包含了保牙 vs 拔牙+种植的评分决策表（≥3分倾向保牙）：
四、OpenClaw 在这个场景中的价值
4.1 实时检索与推理
医生临床遇到问题时，可以直接向 OpenClaw 提问：
"患者左下后牙咬合痛，叩（++），松动I度，X线显示根尖周大面积暗影，牙槽骨吸收达根尖1/3，36号牙，远中邻𬌗面深龋——这颗牙是保还是拔？"
OpenClaw 加载知识库后，可以基于 18-病例分析与决策参考.md 中的评分表给出分析：牙周支持1分（骨吸收1/3~1/2）+ 牙体剩余（缺损大，可能0分）+ 患者意愿/全身状况（未知）= 综合评分倾向拔牙+种植。
4.2 病例书写辅助
医生口述关键信息，OpenClaw 按照 SOAP 模板填充结构化病历。例如输入：
"李女士，35岁，左下后牙咬合痛3周，加重1周。曾于外院行根管治疗（具体不详）。检查：46远中邻𬌗面深龋洞，探（-），叩（++），松动I度，X线根尖周大面积暗影。"
OpenClaw 输出结构化 SOAP 病历，并标注需要补充的检查项。
4.3 决策参考与转诊边界
当病例超出本诊所能力范围时，OpenClaw 可以基于 18-病例分析与决策参考.md 中的转诊指征给出建议：
4.4 口腔摄影与病例记录规范
21-口腔摄影与病例记录规范.md 中定义了标准 9 张法口内摄影和 6 张法面相摄影体系，以及 medico-legal 风险管理要求。OpenClaw 可以在病例讨论时提醒医生拍摄必要照片，并按照规范存储。
五、技术实现
整个系统的架构如下：
┌─────────────────────────────────────────────┐│ OpenClaw（LLM + Tool） ││ ││ ┌──────────┐ ┌──────────┐ ┌──────────┐ ││ │ 检索工具 │ │ 文件读取 │ │ 格式化 │ ││ └────┬─────┘ └────┬─────┘ └────┬─────┘ │└───────┼─────────────┼─────────────┼────────┘ │ │ │ ▼ ▼ ▼┌─────────────────────────────────────────────┐│ 知识库文件（Markdown） ││ ││ 21个子学科 + 病例分析决策参考 ││ 口腔摄影规范 / 接诊模板 / 用药规范 ... ││ ││ 路径：/clawd/knowledge-base/dental│└─────────────────────────────────────────────┘工作流：
医生描述症状和检查结果（语音或文字） OpenClaw 检索知识库，匹配相关学科文件 基于决策树和评分表进行分析 输出结构化病历 + 诊断建议 + 治疗计划 医生审核、修改、签署
优势：
完全本地运行，数据不出诊所 Markdown 格式的知识库便于维护和更新 支持增量更新：新指南发布后，只需替换对应 .md 文件 无需训练自定义模型，基于已有 LLM + RAG 即可
六、总结
这个场景展示了 OpenClaw 在垂直领域知识管理方面的应用潜力：
知识结构化：15+ 口腔医学子学科的知识库，覆盖从接诊到转诊的全流程 临床决策支持：鉴别诊断、治疗计划、转诊边界判定 病例书写自动化：SOAP 模板 + 口述信息 → 结构化病历 规范执行：口腔摄影要求、medico-legal 合规
对于口腔诊所而言，这套系统的核心价值不是替代医生，而是降低知识调用成本——让医生把精力放在患者身上，而不是翻书查资料。对于 OpenClaw 而言，这是一个典型的本地知识库 RAG + 结构化输出的使用场景，具有可复制的范式意义。
