Data Pipeline Manager 是一个用于机器学习研究的数据管线管理技能，核心目标是在训练开始之前做出有据可查、刻意设计的数据决策，从而避免实验效度中最常见的失败：未文档化的预处理、存在泄漏的划分、被污染的测试集以及不可复现的数据管线。
适用场景
当需要决定如何获取、访问或下载数据集时；当需要设计或审计 train/val/test 划分协议时；当预处理选择需要在影响结果之前被文档化时；当数据质量问题可能破坏基线或消融实验时；当训练数据与评估数据之间的污染构成审稿风险时；当数据集版本、随机种子和管线步骤需要为复现性而固定时；当论文结论依赖某个特定的数据协议而该协议尚未被写下来时，可使用本技能。
本技能不用于运行实验——管线验证后应使用 run-experiment；也不用于撰写结果章节——结果产生后应使用 experiment-story-writer。可与其配合的技能包括：experiment-design-planner（确保划分协议与实验设计的评估标准一致）、baseline-selection-audit（当数据集选择或协议影响基线可比性时）、research-project-memory（把数据决策记录为 claim、evidence 和 risk）、result-diagnosis（当意外结果可能源于数据痕迹而非方法失败时）、paper-evidence-board（当数据协议细节需要出现在论文的方法与证据槽位时）、init-python-project（当需要搭建项目的 data/ 布局与管线脚本时）。
技能目录结构
<installed-skill-dir>/ 下包含 SKILL.md、references/（其中 split-protocols.md、contamination-guide.md）以及 templates/（其中 pipeline-plan.md）。
渐进式加载规则
设计与审计划分协议时始终读取 references/split-protocols.md；处理 LLM 评估、预训练模型探测、检索基准或任何模型可能见过测试相邻数据的场景时读取 references/contamination-guide.md；撰写管线计划前读取 templates/pipeline-plan.md；当数据决策需要关联论文 claim 时读取 memory/claim-board.md 与 memory/evidence-board.md；当已存在基准协议时读取 code/.agent/benchmark-plan.md 或等价文件。
核心原则
把数据决策当作实验控制而非实现细节；在预处理运行之前而非结果出现之后记录每一步；从评估目标反推划分设计，即测试集必须回答什么问题；绝不让模型、超参数搜索或任何由论文驱动的决策触碰测试集；污染是论文的责任，应假定审稿人会追问并准备好答案；处理后的数据集应与其创建代码一起做版本管理；对每个影响复现性的 shuffle、采样步骤和数据增强固定随机种子；训练之后才发现的数据质量问题，其代价是训练之前的十倍。
工作流程
第 1 步收集上下文：定位项目根目录（data/、datasets/、code/data/ 或用户指定路径）、已有管线脚本（data_utils.py、preprocess.py、scripts/prepare_data.sh 等）、已有文档（docs/data/、data/README.md 等）、实验设计（code/.agent/benchmark-plan.md、memory/claim-board.md）、论文方法草稿（paper/sections/experiments.tex 等）。记录正在使用或计划使用的数据集、是否已有划分、已应用或计划的预处理、是否做过数据质量审计、是否检查过污染。若什么都不存在，则产出一份草稿管线计划并把不确定字段标为 TBD。
第 2 步选择管线模式：audit（审计已有管线的完整性、可复现性与审稿风险）、split（设计或验证 train/val/test 划分协议）、quality（运行或规划数据质量审计，包括缺失值、标签噪声、分布偏移、类别不平衡）、contamination（检查划分之间以及预训练/检索数据之间的数据泄漏）、versioning（固定数据集版本、哈希、下载脚本与处理种子）、plan（为新数据集创建覆盖以上全部内容的完整管线计划）。默认：已有管线时用 audit，没有时用 plan。
第 3 步设计或审计划分协议：读取 references/split-protocols.md。对每个数据集划分记录：Split（train | val | test | held-out）、Size（样本数及占总数的百分比）、Stratification（按类分层 | 按时间排序 | 随机 | 分组 | 按域分离）、Overlap policy（无 | 显式允许并说明原因）、Leakage controls（泄漏控制列表）、Assignment seed（整数）、Purpose（该划分回答什么假设或指标）、Forbidden use（在最终评估前什么不得触碰该划分）。标记任何在方法已被部分调优之后才设计的划分——这是审稿可见的风险；标记任何把验证集当作代理测试集使用的划分。
第 4 步数据质量审计：检查缺失值（是有意义的掩码还是错误，填补或排除策略是什么）、标签噪声（已知标签错误率、标注协议、适用的标注者间一致性）、类别不平衡（不平衡比例、基线是否等价处理）、分布偏移（train 与 test 之间，或本数据集与所引用先前工作之间）、重复或近似重复样本（去重策略及其对划分边界的影响）、离群值（排除了什么、依据什么标准、是否可复现）、来自预处理的数据泄漏（归一化仅在 train 上拟合、测试时不做增强）。每项发现归类为 blocker（会导致无效结果或比较失败）、risk（应在论文局限或实验设置中披露）或 note（值得跟踪但不阻塞）。
第 5 步污染检查：读取 references/contamination-guide.md。对于 LLM 评估、检索或预训练模型探测，检查基准测试样本是否出现在常见预训练语料中（例如通过 n-gram 重叠、精确哈希或已知污染审计）、模型选择是否直接或间接使用了测试性能、测试时检索到的上下文是否可能包含测试集答案、数据增强是否生成了测试相邻样本。对于标准监督任务，确认去重后没有样本同时出现在 train 和 test 中、确认分组或分层尊重自然数据边界（如说话人 ID、文档 ID、患者 ID）、确认任何留出保留集从未用于阈值选择或模型比较。对每项污染发现记录严重程度与可用缓解措施。
第 6 步版本与复现记录：管线计划必须包含数据集名称与版本（<name>==<version> 或 commit/hash）、下载来源（<url 或 repo>，已验证校验和或哈希）、原始数据哈希（sha256=<hash>）、处理脚本（<path/to/script> at git commit <sha>）、处理种子（每个随机步骤的整数）、处理后数据哈希（最终划分的 sha256=<hash>）、存储位置（<path 或 remote>）、排除的样本（规则与数量）、已知问题（列表）。若任一字段无法填写，标为 TODO 并加入 memory/action-board.md。
第 7 步撰写管线计划：使用 templates/pipeline-plan.md，保存到 code/.agent/data-pipeline-plan.md；若不存在 code/ 目录则保存到 .agent/data-pipeline-plan.md。更新时保留稳定决策并添加简短的变更说明。
第 8 步记忆写回：将影响 claim 的数据决策写入 memory/claim-board.md；将污染风险写入 memory/risk-board.md；将未解决的数据质量问题作为 action 写入 memory/action-board.md；当数据集特征被论文引用时将其证据写入 memory/evidence-board.md；当数据集版本或划分协议变更时更新 memory/current-status.md。
第 9 步后续路由：experiment-design-planner（使实验设计与最终划分协议对齐）、baseline-selection-audit（划分或预处理变更后复查基线可比性）、result-diagnosis（诊断可能源于数据问题的意外结果）、paper-evidence-board（把数据集协议细节加入论文证据槽位）、init-python-project（搭建 data/ 布局与管线脚本）。
最终检查
定稿前确认：每个划分都有文档化的用途与禁止使用策略；每个预处理步骤都可用固定种子和版本固定脚本复现；数据质量发现已归类为 blocker、risk 或 note；污染检查已显式完成，或显式推迟并带有风险条目；数据集版本、哈希与下载来源已记录或标为 TODO；记忆写回覆盖受影响的 claim、风险与 action；下一步行动明确。