# Retro Data

> 数据处理复盘——从完整性验证、格式匹配、管道可靠性、异常处理等维度深度挖掘

- Skill: `kaixin1seu/retro-data` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kaixin1seu/retro-data`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kaixin1seu/retro-data/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kaixin1seu (https://skillmd.com/u/kaixin1seu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kaixin1seu/retro-data

---


# 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%"而非空洞的"如果数据有问题"）