外观
规则和接口会变，怎么持续盯着
本章解决：规则每年换版、目录每年调整、接口随产品更新。你怎么在它悄悄变了之后，第一时间知道。
1. 先给结论
- 规则变化很少通知你。 目录换版有文件，但接口行为变化、字段含义微调、静默回落到全国版——这些都不发通知。
- 回归的核心不是"跑通了没有"，是"和上次比变了没有"。 前者天天都过，后者才是信号。
- 一组固定的金标用例，定期重跑。 用例要小到能天天跑，覆盖到能发现问题。
- 变化本身不是问题，不知道变了才是。 发现变化后判断它合不合理，那是下一步的事。
- 这一章和规则包验收互补：那一章管新拿到一份包时怎么验，这一章管已经在用的东西怎么持续盯。
2. 哪些东西会悄悄变
| 变化 | 会不会通知你 | 怎么表现出来 |
|---|---|---|
| 目录换版 | 会（有文件） | 分组结果变，但你知道原因 |
| 权重/分值调整 | 会 | 同上 |
| 城市静默回落到全国版 | 不会 | 结果"正常"，但用的不是本地规则 |
| 接口字段含义微调 | 通常不会 | 数值还在，含义变了 |
| CC/MCC 排除关系调整 | 文件里有，但很少被注意 | 同一个其他诊断的 CC 状态变了 |
| 分组器版本更新 | 不一定 | 同一输入不同结果 |
中间三项是这一章的重点。 它们的共同点：结果看起来是对的，你不主动比对就发现不了。
3. 一组最小金标用例
实测里那条回归自动化，输入只有五行：
text
城市版本：CHS3.0试行版
主要诊断：J18.900
其他诊断：E77.801、R64.x00、E12.100
期望：确认城市版本仍可用，并复核三条其他诊断的 CC/MCC 状态与排除标记。就这么小。 但它同时盯住了三件事：
| 盯什么 | 怎么盯到的 |
|---|---|
| 城市版本还在不在 | 先查城市清单，不在就直接失败 |
| CC/MCC 判定变没变 | 三条其他诊断，一条 none 两条 CC，是一组有区分度的组合 |
| 排除关系变没变 | 每条都看 excluded 标记，不只看 status |
上次跑出来的基线：
json
[
{ "code": "E77.801", "status": "none", "excluded": false },
{ "code": "R64.x00", "status": "CC", "excluded": false },
{ "code": "E12.100", "status": "CC", "excluded": false }
]这九个值就是金标。 下次重跑，任何一个变了都要查为什么。
为什么用例要小
小用例能天天跑。一组三条诊断的检查，几秒钟出结果；一批两万条病例的全量回归，跑一次要十几分钟，于是变成"季度跑一次"——而季度跑一次意味着你可能已经用错了三个月。
覆盖度靠挑选，不靠数量。 上面那三条诊断的价值在于：一条不构成 CC、两条构成，且都未被排除——任何一处判定逻辑变化都会打破这个组合。
4. 怎么挑金标用例
按这四个维度各挑一两条：
| 维度 | 挑什么 | 为什么 |
|---|---|---|
| 本院高频 | 病例量最大的三五个病组 | 变了影响最大 |
| 边界附近 | 刚好卡在 CC/MCC 分界、刚好触发倍率阈值的 | 边界最容易被调整 |
| 曾经出过问题 | 历史上排查过的疑难病例 | 出过一次的地方容易再出 |
| 跨体系 | 同时准备 DRG 与 DIP 各一条 | 两边的变化节奏不同 |
总数控制在十条以内。 超过十条就跑不动，跑不动就不会定期跑。
不要用真实病例做金标
金标用例会被反复运行、结果会被存档、可能被同事传看。用合成病例——把真实病例的结构抄下来，字段值换掉。
上面那条用例就是合成的，输入文件里明写"不包含姓名、住院号或其他身份信息"。
5. 每次重跑要记什么
text
一、跑的时间与规则版本标识
二、每条用例的实际返回（原始，不是转述）
三、与上次基线的逐项对照：一致 / 不一致
四、不一致项的初步判断：规则变化 / 数据问题 / 接口变化 / 未知
五、结论：基线是否更新第五项最容易被跳过，但它决定这套机制会不会腐烂。
发现不一致后有两种处理：
- 确认是合理的规则变化 → 更新基线，并在记录里写清"从什么变成什么、依据是什么"
- 原因未查明 → 不要更新基线。保留旧基线，把这条标为待查
未查明就更新基线，等于把问题洗掉了。 下次再跑就"一致"了，而错误还在。
6. 频率怎么定
| 什么时候跑 | 为什么 |
|---|---|
| 每周一次（常规） | 小用例成本低，一周的窗口能接受 |
| 换版前后各一次 | 这是变化最集中的时刻，且要能对比出差异 |
| 接口/产品更新后 | 版本号变了就跑，不管它说改了什么 |
| 发现异常时立刻 | 排查的第一步就该是"金标还过不过" |
最后一条常被忽略但很有用：遇到一条奇怪的病例，先跑一遍金标。 金标不过说明是系统性问题，金标过了说明是这条病例自己的问题——这一步能省掉半天的错误方向。
7. 常见错误
| 错误 | 后果 |
|---|---|
| 只看"跑通了"，不与上次比 | 变化全部漏掉——而变化才是信号 |
| 用例太多跑不动 | 从"每周"退化成"想起来才跑"，最后不跑 |
| 用真实病例做金标 | 反复运行、多处存档，隐私暴露面变大 |
只存 status 不存 excluded | 排除关系变化发现不了 |
| 原因未查明就更新基线 | 把问题洗掉，下次显示"一致" |
| 不记规则版本标识 | 发现差异时不知道该和哪一版比 |
| 排查疑难病例时不先跑金标 | 可能在追一个系统性问题的个例表现 |
8. 读完你应该能
- 说出三类"不会通知你"的变化，以及它们为什么难发现。
- 用四个维度挑出十条以内的金标用例，并说清每条盯什么。
- 说明为什么用例要小到能每周跑。
- 说明"原因未查明不更新基线"这条规矩为什么重要。
- 遇到异常病例时，知道第一步是先跑金标。
9. 来源
本章不直接引用政策文件条文；涉及的规则口径见各处内链指向的篇目。
本书的实测依据
下面这些不是政策文件，是本书自己跑出来或整理的东西。可以用来理解方法，不要当规则引用。
- 第 3 节的金标用例与基线返回来自一次真实的 MCP 回归实测，2026-07-20，输入为合成病例。
- 用例挑选的四个维度、基线更新规矩与频率建议属实务经验整理。
10. 下一步
- 新拿到一份规则包怎么验：别人给你一份规则包，怎么验它对不对
- 变化算出来之后怎么用：规则切换影响测算
- 工作流怎么搭：让 AI 替你跑一遍