kaixin1seu retro-data — 数据处理复盘透镜
适用范围与边界
本 skill 覆盖数据获取、预处理、管道管理和完整性验证。
与其它 skill 的区分：
- 实验中的数据处理选择（如选择了哪种归一化）→
retro-experiment - 数据处理代码的 bug →
retro-coding - 数据异常导致的调试过程 →
retro-debugging
不适用场景：纯数据可视化/报表生成、数据库选型决策、API 设计中的数据格式定义（用 retro-design）。
评估维度
1. 数据完整性验证
- 下载/获取数据后，是否验证了文件大小？（不只是文件数量！这是用户真实踩过的重大坑）
- 行数是否与预期一致？（源 vs 目标）
- 是否有截断文件或缺失分区？
- 关键字段是否有非预期的 NULL？
2. 数据格式与匹配
- 数据格式是否与下游（模型/算法）期望匹配？
- Schema 是否一致？（列名、类型、编码）
- 特殊字符、分隔符是否正确处理？
- 时间戳/日期格式是否统一？时区是否正确？
3. 管道可靠性
- 管道是否可能静默成功？（状态显示成功但数据实际有问题）
- 上游 schema 变更是否会被及时发现？（列被重命名/增删后管道还是"成功"的）
- 部分失败是否会导致整体状态仍为"成功"？
- 增量逻辑是否正确？（
>vs>=的边界）
4. 预处理正确性
- 每个预处理步骤的效果是否经过验证？（不是"应该有效"，而是"验证过有效"）
- 抗混叠/LPF 等信号处理参数是否匹配数据特性？（用户教训：decimate 前的抗混叠有效，bandpass 反而有害）
- 归一化/标准化的统计量是否从正确的集合计算？（train 的统计量，不能从 test 算）
5. 数据来源与质量
- 数据来源是否可靠？
- 许可证/使用权限是否清楚？
- 数据时效性是否符合要求？（是否过期？）
- 训练/测试分布是否一致？
常见反模式
| 反模式 | 检测信号 |
|---|---|
| 只看文件数量不看文件大小 | 下载后立即说"数据下载完成"，没有检查文件大小 |
| 数据格式不匹配就直接训练 | 套用开源代码不检查数据格式差异（用户 KID-PPG 教训） |
| 静默的数据处理错误 | 预处理后没有抽样检查中间结果 |
| 管道"成功"但数据不对 | 只看管道状态不看实际数据内容 |
| 训练/测试数据泄漏 | 预处理在划分之前做，或用到了测试集的统计信息 |
| SSL/下载问题被忽略 | 下载失败但脚本继续执行，产生空文件 |
| 数据来源不可靠/过期 | 未检查数据来源的可信度、时效性和使用许可证 |
| 增量边界错误 | 增量拉取时 >/>= 边界定义不清，导致行重复或遗漏 |
| 数据版本未记录 | 处理后未保存原始数据版本号/快照，后续无法回溯到同一状态 |
| 硬编码路径/配置 | 换个环境就跑不了 |
已固化模式
| 模式 | 适用信号 | 验证 | 来源 | |------|----------|------| | （待复盘时自动追加） | | | |
关键追问
挑刺式（找改进空间）
- 数据下载后做了哪些完整性验证？（数量？大小？格式？）
- 数据处理链路的每一步，有没有检查中间输出？
- 如果数据有问题，是不是能尽早发现？（越早发现成本越低）
- 下个实验开始前，需要先检查哪些数据假设？
- 这次有没有"数据看起来没问题但实际上有问题"的情况？
- 数据版本是否被记录？（下次能否回到完全一样的数据状态？）
正向式（找值得复用的）
- 这次数据处理哪个环节做得特别靠谱？有什么做法下次可以直接复用？ （信号：某个检查步骤在关键时刻拦截了问题、某个预处理 pipeline 被多次复用无故障）
- 有没有发明了某个好用的检查/验证方法，值得固化为流程？ （信号：这个方法在不止一个数据集上被验证有效、比之前的检查方法更省时/更可靠）
- 数据管道的哪部分设计/结构特别经得起折腾？（换了数据源、加了新字段也没出问题）
反证条件指引
对于数据的完整性假设，追问：什么具体信号会提示数据实际有问题？ （引导写出可操作的反证条件——如"如果下次文件大小偏差 > 10%"而非空洞的"如果数据有问题"）