夜雨聆风在线下数据清理场景里，借助 offline listing 频繁核查数据、找出 EDC 中存在问题的记录，一直是 DM 绕不开的一项繁重工作。
怎样设计一套流程，让AI 可以理解规则、查询数据、分析问题，甚至直接输出质疑文本，真正分担 DM 的工作量？
下面我想谈一谈我的构想，以及思路历程。
当然，这个构想有两个前提条件：
Markdown 文件天然适合 AI 输入，因此数据集必须转为 Markdown 格式。
AI 输入的数据集范围要尽可能做到“小而全”，不要超出 AI 的上下文边界。
一开始构思了方案 V0.1：
最初的方案：按受试者拆分数据，让 AI 逐个理解
最开始的思路是这样的：
先用 SAS 程序按受试者拆分原始数据集，分别放在各自的目录下。每个受试者目录下面，包含所有的数据表，比如 SV.xlsx、DM.xlsx、VS.xlsx 等。随后，再把这些 XLSX 文件统一转换成 Markdown 文件。
这样一来，AI 需要的数据原料就准备好了。
在交互过程中，用户输入某一条核查规则后，AI 会先理解并判断，为了完成这条核查需要读取哪些数据集，然后去读取指定受试者下对应的数据表，例如 HEM.md、AE.md，并根据用户给出的规则判断这个受试者是否存在数据问题。如果发现异常数据或矛盾数据，就输出结构化 JSON，最后再汇总为结果表，交由人工审核。
这个流程是成立的，优点也很明显：
数据按受试者拆开，边界清晰
Markdown更适合模型直接读取
模型可以结合自然语言规则，对跨表关系做一定程度的判断
JSON 输出便于后续汇总
但这个方案没有充分考虑到，生产环境中受试者的数据量往往非常大，而公司内部部署的蒸馏模型能力又相对有限，因此很快暴露出了下面几个短板。
短板一：单个受试者的信息量依然太大
真正进行核查时，模型通常需要同时读取多个 Markdown 文件，还要在这些表之间做上下文关联。而且受试者每张表的行数、列数往往都很大，三期试验中更是如此。
这样一来，单个受试者的上下文体积依旧很大。这会带来几个直接问题：
Token 消耗非常高
推理速度会明显下降
上下文一长，模型更容易出现信息遗漏
跨表关联复杂，容易发生语义理解偏差
也就是说，Markdown 解决了“能否读入”的问题，却没有真正解决“能否高效、稳定地读懂”的问题。
短板二：Markdown 无法进行数据的排序、分组、连接
Markdown 里的数据虽然看起来是表格，但对模型而言，它本质上仍然是文本。
这就意味着，模型很难像操作数据库那样，对这些数据执行稳定的排序、聚合、筛选、关联和清洗。比如：
按日期先后重排同类记录
在多张表之间做类似 VLOOKUP 的操作
这些事情如果完全交给模型在 Markdown 文本里“边读边推”，成本高、误差大，而且越复杂越不稳定。
短板三：不利于批量核查 offline
这个方案更像一种对话式模式，也就是“用户给一条规则，模型跑一次”。但真实场景下，往往有上百条 offline 需要核查。难道用户要和 AI 对话 100 次，并且每次都要等待结果返回后才能进行下一轮吗？
此时，我意识到，如果处理单位始终是“单个受试者 + 多个 Markdown 表 + 一次用户输入规则”，那么无论怎么调 prompt、怎么压缩文本，都很难从根本上解决性能、稳定性和批量化的问题。
所以后来的优化，核心不再是继续围绕“受试者”组织流程，而是换了一个思路。
既然目前 DM 本身就是依据 SAS 输出的 offline listing 来核查数据，那么为什么不能让 AI 直接读取 offline listing，再根据规则输出需要的结果呢？
下面是优化后的方案：V0.2。
优化后的方案：切割转换 offline listing，再让 AI 做精准判读
第一步：按传统模式跑 offline listing
所有能够用确定性逻辑判断的内容，先交给 SAS 去做。
offline listing 的本质，就是先把“可能有问题的数据”筛出来。这样，AI 后面接收到的就是疑似问题数据片段。这会立刻带来两个收益：
输入规模显著缩小
模型注意力更集中，不会被大量无关数据干扰
第二步：按 List 和 batch 重新组织任务
把每个 List 的结果单独放在一个 List 文件夹下。为了进一步降低输入压力，最好再把每个 List 的结果拆成多个 batch，比如一个 batch 内最多放 20 条记录。
当然这里还有一个细节：同一个受试者的记录最好放在同一个 batch 里，否则在做数据交叉验证时，很容易发生错误。
第三步：转Markdown 中间文件
这里依然会做 XLSX 到 Markdown 的转换，但它承担的角色已经不一样了。
在初版方案里，Markdown 承载的是“一个受试者的大量原始数据”；而在优化方案里，Markdown 承载的是“经过规则初筛后的小批量数据片段”。
也就是说，Markdown 仍然是模型的阅读介质，但它不再承担过重的上下文负担。
第四步：为每个 List 配置独立规则文件
在模型正式检查某个 batch 之前，会先读取该 List 对应的规则文件。这样可以确保 AI 明确规则，对已经筛出的疑似问题数据做进一步判断和归因，从而提高输出的准确度和一致性。
第五步：AI 输出结构化 JSON，再统一汇总
当模型完成判断后，输出仍然是结构化 JSON，包括受试者编号、访视、表单、行号、query 文本等字段。
这些 JSON 会被统一解析，最终导出成标准结果表，再进入人工审核。
整个流程明确了人机分工，让任务更聚焦、模型负担压力更小，同时实现了流程化、批量化，初期一旦跑通，基本上就是一劳永逸～～
那么实操上应该怎么做呢？
我觉得一个比较可行的落地方案是：每两天将最新的数据交由 AI 处理，由 DM 审核 AI 输出的结果；如果有需要发质疑的内容，就及时让 CRC 解决。这样等到 DM 进行人工月度数据清理时，dirty data 的密度会大大降低，整体工作量也会明显下降；而对于 AI 查漏的数据，也可以及时发现和补充。
结语：
如果说 V0.1 证明了 AI“可以参与” offline 核查，那么 V0.2 真正解决的，就是 AI“如何稳定参与、批量参与、持续参与”的问题。
AI 日常核查与人工月度核查并行，不只是让错误数据被更早发现，也是在用一种更可落地的方式，逐步降低 DM 的工作负荷。这或许才是 AI 在数据管理场景里真正有价值的地方：不是替代人工，而是把原本高频、重复、耗时的核查工作，变成一套可以持续运转的协同机制。