检查的价值在于可见，不在于代决

有条实操帖把一句狠话放在开头：不做数据检查就微调开源模型，等于白烧 GPU。作者的动作很朴素——先看数据，抓三类问题：重复、空输出、坏行；他的做法是让一个桌面 agent 几分钟内搭出本地检查器：检查 instruction/output 格式化 JSONL、把命中的行标出来、修完再导出干净的部分。

在 12 条样本上，检查器抓到两条重复指令、两条空输出、一条超过自定 300 字阈值的过长指令；修掉空输出后有效行从 7 变 8，导出结果再被程序验证一遍。（工具实测细节见原帖，附带的活动链接原样保留：qoder.com/activities?cod…

这段演示里最值钱的其实是他补的那两句限定：重复并不总是错的，300 字符也不是模型的硬限制——这些是"要检查"的理由，不是"要过滤"的理由。检查与过滤的分界，正是今晚数据质量线反复出现的那根弦：发现问题、标出来、交给人决定；一旦把阈值写成自动丢弃的规则，你省下的时间会以另一种方式还回来——丢掉的可能正是特殊但有效的样本。检查器的价值在于可见，不在于代决。

与昨晚"有数据不等于有对的数据"那篇合起来，一条完整的方法论浮出来了：那篇讲公共数据可能自带裂缝，这篇给出落地的三步——列出你的"坏"的定义、让机器去数、把判断留给人。世界模型的错会学进物理直觉、微调数据的错会学进权重，两者都不声不响；区别只在于前者靠社区标注、后者你自己五分钟就能搭好检查器。工具变了，纪律没变：训练之前先量数据。

"让 agent 几分钟搭出检查器"这个用法本身也值得单独表扬。它没有把 AI 当成微调的替代品，而是当成生产工具的工具——你需要检查器，就让 agent 造一个；这种"用 agent 造量具"的姿势，比"用 agent 直接干活"更稳：量具一旦立起来，它测的是数据本身，不依赖谁的判断。

这与今晚"给程序做判断的、给 agent 用的 Skill"那些篇目是同一种姿势的不同用法。

给要微调的人一句落地的：在碰任何训练框架之前，先花半天做三件事——写清你眼里"坏数据"的三个定义、让 agent 或手写一个只读的检查器、把命中的行全部过一遍再决定删留。三步做完再开 GPU；这半天的投入，通常能省下整轮白训的账单。