外观
让 AI 替你跑一遍：一次真实搭建记录
本章解决：AI 到底能不能替你做 DRG/DIP 的活。 不讲原则，讲一次真实搭建——三条提示词、十个工具、十六次调用，以及每一步的原始返回。
1. 先给结论
- AI 不该负责"算"，只该负责"组织"。 分组、CC/MCC、结算这些必须由规则工具算，AI 的活是把输入整理好、把结果讲清楚。
- 提示词里必须写一句"没调用工具就明确说失败"。 不写这句，AI 会给你一个看起来对的结果——这是全章最重要的一条。
- 边界要写进提示词，不是写在报告末尾。 "不要推断真实结算"这种话放在事后声明里没有约束力，放在指令里才有。
- 原始返回必须留档。 AI 转述过的东西不算证据，工具调用的原始 JSON 才算。
- 能自动化的是流程，不能自动化的是判断。下面每条自动化的输出里都有一栏「待人工确认」。
2. 那次搭建的形状
三条自动化，一条比一条大：
| # | 任务 | 规模 | 用到的工具 |
|---|---|---|---|
| 01 | 出院病例联合复核 | 3 条病例 | batch_grouping + get_cc_status |
| 02 | 科室病组运营周报 | 一周病例 | batch_grouping + 与上周对比 |
| 03 | 多城市支付问题准备 | 2 条病例 × 3 地区 | get_city_list + DRG/DIP 分组 |
连接器一共 10 个工具，本轮实测 16 次业务调用。全程合成数据，输入文件里明写"不包含姓名、住院号或其他身份信息"。
3. 三条提示词，逐句拆
案例 01：出院病例联合复核
text
检查当前工作空间"案例输入/01-出院病例复核"文件夹。读取合成病例，
使用 MedGroup MCP 真实调用 batch_grouping 完成 CHS3.0试行版 DRG 批量分组，
再用 get_cc_status 复核其他诊断。
按"病例、病组、CC/MCC、待人工确认"输出简洁中文表格，并生成可浏览的 HTML 报告。
若未调用 MCP，请明确说明失败。这段话里有五个刻意的设计：
| 写了什么 | 为什么 |
|---|---|
真实调用 batch_grouping | 点名工具，不给"自己推算"留空间 |
再用 get_cc_status 复核 | 两个工具交叉验证同一批诊断，而不是信第一个结果 |
| 指定输出四栏 | 最后一栏是待人工确认——把"哪些不能自动定"变成必填项 |
| 生成 HTML 报告 | 产物要能给别人看，不是一段聊天记录 |
| 若未调用 MCP，请明确说明失败 | 见下 |
最后那句话是整条工作流的地基
不写它，AI 在工具不可用时会照样输出一份格式完整、看起来专业的报告——分组结果是推测的，CC/MCC 是猜的，而报告上没有任何痕迹说明这一点。
这是 AI 辅助 DRG/DIP 最危险的失败模式：它不报错，它给你一个像样的答案。
写了这句，工具没通就会明确告诉你"未调用成功"。你至少知道这份报告不能用。
案例 02：从单例到批量
text
……使用 MedGroup MCP 真实调用 batch_grouping 复核本周合成病例，
比较表中的上周记录病组。
输出"病组分布、变化病例、CC/MCC、下周待核查"四部分中文周报……
若未调用 MCP，请明确说明失败。变化只有一处：加了"与上周对比"。而这一处把任务性质变了——从"这批病例进了哪些组"变成"哪些病例的组变了"。
第二栏「变化病例」才是周报的重点。病组分布每周都差不多，变化的那几条才需要人看。
案例 03：多城市，先确认再分组
text
先用 MedGroup MCP 的 get_city_list 确认 CHS3.0试行版、广州市和上海市可用，
再结合对应 DRG/DIP 分组工具复核两条合成病例。
输出三个地区的"规则结果、差异提示、沟通问题"简表，
不要推断真实结算或产品价值；若未调用 MCP，请明确说明失败。两个新设计：
「先确认可用，再分组」 —— 城市清单是会变的。不先确认就分组，拿到的可能是回落到全国版的结果，而回落通常是静默的（见 A06）。
「不要推断真实结算或产品价值」 —— 这句是边界。放进提示词，报告里就不会出现"预计可节省 X 万"这类它无从判断的话。边界写在事后声明里没有约束力，写在指令里才有。
4. 十个工具都返回了什么
那次实测的完整记录，每一行都有一个对应的原始 JSON 文件：
| 工具 | 返回摘要 |
|---|---|
get_city_list | CHS3.0试行版、广州市、上海市均在列表中 |
search_icd | J18.900 = 肺炎；非灰码 |
find_code_info | MDC 为 MDCE、MDCP；ADRG 路径含 ES4 |
get_cc_status | E77.801=none；R64.x00=CC；E12.100=CC；三者 excluded 均为 false |
drg_grouping | MDCE → ES4 → ES4F；带 CC；目录分值 0 |
dip_grouping | 广州 J18.9；641 分；核心病种 |
get_rule_details | ES4F 的年龄与 CC 条件、广州 J18.9 规则均可返回 |
check_dip_rule | 返回 ok |
calculate_settlement | 641 分 × 点值 60 × 系数 1，费用 22000，模拟支付 38460 |
batch_grouping | CHS3.0、广州、上海各 5/5 成功 |
原始返回长这样（get_cc_status 那次）：
json
[
{ "code": "E77.801", "status": "none", "excluded": false },
{ "code": "R64.x00", "status": "CC", "excluded": false },
{ "code": "E12.100", "status": "CC", "excluded": false }
]为什么要留这个而不是留 AI 的转述：AI 会写成"两条诊断构成 CC，一条不构成"——这句话是对的，但无法被复核。原始 JSON 可以：任何人拿同样的编码再调一次，应该得到同样的三行。
注意 drg_grouping 那行的"目录分值 0"
这不是故障，是该地区版本没有配置分值。如果拿这个 0 去算支付标准，会得出"支付标准 0 元"。
正确处理是分值缺失时不做金额测算——见钱是怎么算出来的里"目录中的 0、缺失或占位值不能自动补成支付参数"。
这类"合法但不可用"的返回，恰恰是最容易被直接拿去算的东西。
5. 分工：什么给工具，什么给 AI，什么留给人
text
输入整理 → 规则计算 → 结果组织 → 判断与签字
AI 工具 AI 人| 环节 | 谁做 | 为什么 |
|---|---|---|
| 读文件、抽字段、对齐格式 | AI | 体力活，且错了容易发现 |
| 分组、CC/MCC、结算 | 工具 | 有确定答案的事不该让概率模型做 |
| 组织成表、写差异说明、生成报告 | AI | 它的强项是表达 |
| 编码该不该改、要不要申报、结论能不能对外 | 人 | 这些没有确定答案 |
中间两栏最容易被混淆。 AI 组织出来的表格看起来和工具返回一样权威，但前者可能重述错、漏单位、改了四舍五入。所以每份报告都要能追回到原始返回。
一个可以自己做的对照实验
把同一道题问两次：一次不给工具、一次给工具。
不给工具时，模型会给出一个格式完整的分组结果——而且往往是错的。这个实验做过几轮，跨不同模型，结论一致：裸模型在 DRG/DIP 分组上集体不可靠，因为分组依赖具体版本的规则表，那不是语言能力能覆盖的东西。
这个结论不随模型换代失效——它是任务性质决定的，不是模型强弱决定的。
还有一类问题，AI 会被它绕进去
有些病例看起来"分组规则有问题"，实际问题在别处：输入偏差、信息化处理环节、或者分组器版本不对。
AI 面对这种矛盾时容易越走越深——它会反复解释规则，因为它拿到的输入本身是错的，而它不知道。这时候需要人跳出来问一句"我们是不是在查错的东西"，这一步 AI 做不到。
排查顺序为什么要「先数据、再编码、再规则」，根源就在这里——见未入组排查。
6. 一条工作流的最小组成
照着这个搭，六项缺一不可：
| 组成 | 具体是什么 |
|---|---|
| 输入 | 一个文件夹，结构化的合成或脱敏数据，明写不含身份信息 |
| 提示词 | 点名工具、指定输出结构、写明边界、带"未调用就说失败" |
| 工具 | 确定性计算全交给它，AI 不代算 |
| 原始返回 | 每次调用存一个文件，与调用参数一一对应 |
| 产物 | 能给别人看的报告，不是聊天记录 |
| 待人工确认栏 | 输出结构里的必填项，不是可选的补充说明 |
7. 常见错误
| 错误 | 后果 |
|---|---|
| 提示词不写"未调用就说失败" | 工具不通时得到一份编造但格式完整的报告 |
| 让 AI 自己算分组或结算 | 结果不可复核，且会在边缘情况上错 |
| 只存 AI 的输出，不存原始返回 | 报告无法被第三方验证 |
| 边界写在报告末尾而不是提示词里 | 对生成过程没有任何约束 |
| 输出结构里没有"待人工确认" | 该由人定的事被静默自动化了 |
拿到 0 或空值直接参与计算 | 得出"支付标准 0 元"这类荒谬结论 |
| 不先确认城市版本就分组 | 静默回落到全国版，结果与本地规则不同 |
8. 读完你应该能
- 说出提示词里那句"未调用就说失败"为什么是地基。
- 分清哪一步该给工具、哪一步该给 AI、哪一步必须留给人。
- 说明为什么要留原始 JSON 而不是 AI 的转述。
- 认出"合法但不可用"的返回（例如分值为 0），并知道正确处理是不做测算。
- 搭一条六项齐全的工作流，并说清每一项缺了会怎样。
9. 来源
本章不直接引用政策文件条文；涉及的规则口径见各处内链指向的篇目。
本书的实测依据
下面这些不是政策文件，是本书自己跑出来的东西。可以用来理解方法，不要当规则引用。
- 一次完整的 MCP 自动化实测：三条提示词、10 个工具、16 次业务调用，全程合成数据，实测于 2026-07-20。工具返回摘要与原始 JSON 逐次留档，工具事实与模型解释分栏记录。
- 提示词的五处设计、四栏分工与六项组成属实务经验整理。
这一章的边界
工具返回的是系统结果，不是政策事实，也不是结算结论。 本章所有数值来自合成病例的一次实测，只用于演示工作流的形状。
模型与工具都在快速换代——本章刻意不写"哪个模型更强"，那类结论几个月就失效。这里写的是不随模型变化的部分：分工、提示词的约束设计、证据留档。
10. 下一步
- 规则和接口会变，怎么持续盯着：规则与接口怎么持续回归
- 数据要对外分享时怎么脱敏：一份盈亏报告的脱敏
- 交出去之前自己过一遍：A04｜交付前自检清单
- 把规则接进自己的流程：A06｜把工具接上