同一项调查、同一个截止日期，月报写“满意率48%”，复盘会的图却是43%。这时最危险的做法不是选一张看起来更新的文件，而是继续用邮件时间、文件名里的“最终版”或某位同事的记忆判断。两个数字可能分别使用了不同的答卷快照、有效分母、清洗规则、权重或问卷版本；若不能逐层还原，任何一个都不能直接成为正式结论。
调研数据版本管理的最低合格线，是让报告里的每个关键数字都能反向追到：哪张图或表、由哪次分析运行生成、使用哪版处理规则、读取哪个不可变原始快照、对应哪版问卷和哪个回收批次。版本回答“对象在何时变成了什么”，血缘回答“这个结果由哪些输入经过什么活动产生”。二者需要一起设计。
先对48%和43%做一次数字取证
调查最初向所有完成者询问功能满意度，回收第二周增加了“过去30天使用过该功能”的筛选题。第一位分析者用截至8月20日的全量完成者作分母，未回答满意度的人按不满意处理；第二位分析者用截至8月22日的数据，只保留实际使用者并剔除特殊缺失，又应用了校准权重。两张图的标题都叫“功能满意率”，但估计对象已经不同。
要判断差异来自哪里，至少需要回答：
- 图表文件中的数字是复制粘贴，还是由某段查询或脚本生成？
- 那次运行读取了哪个分析数据集，过滤条件和权重参数是什么？
- 分析数据由哪些原始答卷批次合并，在哪一时刻截取？
- 清洗时怎样处理重复、质检失败、拒答与逻辑未展示？
- 每批答卷看到了哪一版题目、选项和跳转？
如果这些答案散落在聊天记录中，团队拥有的是个人记忆，不是数据血缘。最终处理可能是统一用“看到该题且给出有效量表回答的实际使用者”为分母，重新生成两期数据；也可能因为筛选题中途才加入，只能把8月20日标为口径断点。无论选哪种，都应形成新的、有说明的产物，不能覆盖旧文件后假装差异没有发生。
一条能审计的调研血缘包含六类产物
W3C 的PROV 入门模型用“实体、活动和责任主体”描述来源：数据文件或图表是实体，清洗与分析是活动，人或系统是责任主体。小团队不必部署专门的血缘平台，也可以用这个思路管理六类产物。
| 产物 | 必须稳定记录 | 典型关系 |
|---|---|---|
| 研究与分析方案 | 研究问题、指标、总体、排除与比较规则、批准版本 | 解释为何产生后续数据 |
| 问卷版本 | 题文、选项、逻辑、语言、发布时间和实质变更 | 决定每批参与者能看到什么 |
| 原始快照 | 导出时间、批次范围、文件标识、行数和校验值 | 作为处理活动的不可变输入 |
| 处理规则 | 质检、去重、编码、派生、关联和权重的版本 | 把原始快照变为分析数据 |
| 分析运行 | 输入标识、脚本版本、参数、运行时间与操作者 | 生成表格和图表所用数字 |
| 交付产物 | 报告版本、图表编号、数据截止点和访问级别 | 引用具体分析运行的输出 |
校验值只能帮助确认文件字节是否相同，不能证明数据内容正确；版本号只能区分对象，不能自动说明新旧是否可比。真正的血缘是这些标识之间的关系。例如图表 fig_retention_03@1.2 来自运行 run_20260902_1045，该运行读取分析集 analysis@2.1，分析集又由原始快照 raw_batch_01_04 和处理规则 clean@1.7 生成。
原始层不可变，修正通过新产物表达
原始答卷应按批次或时间形成只读快照，并保留采集系统中的项目、问卷和回收标识。发现一条记录编码错误时，不要在原始 Excel 中直接改掉；把修正规则写入处理步骤，生成新的清洗数据。这样既保留“最初收到什么”，也能解释“为什么后来不同”。
不可变不等于永久保存所有敏感数据。删除请求、保留期限和脱敏要求仍然优先。可以记录“某记录依照哪项政策在何时由谁执行删除”以及受影响的后续产物，重新生成允许保留的分析集；不能为了复现而私自保留本应删除的个人信息。血缘记录本身也应最小化敏感字段，使用内部标识而非姓名或联系方式。
每个原始快照建议至少有：项目标识、问卷版本、包含的回收批次、时间范围、导出时区、文件格式、记录数、字段数、生成者、生成时间和校验值。多渠道回收时再增加渠道与样本来源；外部合并 CRM 或行为数据时，记录数据提取时间、关联键、未匹配率和字段定义。
版本升级看“含义与可比性”，不看改了几个字
版本号可以简单，但升级规则要围绕数据含义。一处改动是否“重大”，不是由字符数决定，而是看它会不会改变谁能回答、受访者如何理解、值怎样编码或指标如何计算。
- 展示修订：修正不影响含义的错别字或样式，可保留主要数据口径，但仍记录发布时间和展示版本。
- 测量修订：参考期从30天变为90天、五点量表改成七点、选项含义变化，应创建新的测量版本，并评估是否能桥接，不得直接拼趋势。
- 总体修订：筛选条件、样本来源或配额改变，会影响结果代表谁。报告必须标出口径断点，即使题目完全没变。
- 处理修订：去重、质检、缺失、派生或权重规则改变，应生成新的分析数据版本，并列出受影响的指标与图表。
- 仅追加数据：问卷和规则不变、只增加新批次，可以产生新的快照版本；旧快照仍保留，以便复现当时发布的报告。
每次变更都补三项判断：哪些记录和变量受影响，新旧结果是否可比，已经发布的产物是否需要重算或更正。若答案暂时未知，就将兼容性标为“待验证”，而不是默认可合并。
用一份运行清单把文件夹变成证据链
小团队最容易落地的做法，是让每次正式处理或分析都输出一份机器可读或表格化的运行清单。它不需要复杂，但不能靠文件名猜测。例如：
{
"run_id": "run_20260902_1045",
"purpose": "生成8月功能满意度正式图表",
"inputs": ["raw_batch_01_04@sha256:…", "questionnaire@2.0"],
"rules": ["clean@1.7", "codebook@2.0", "weight@1.1"],
"parameters": {"cutoff": "2026-08-31T23:59:59+08:00"},
"outputs": ["table_sat@2.1", "fig_sat_01@1.2"],
"owner": "research-analytics",
"executed_at": "2026-09-02T10:45:00+08:00"
}脚本、查询和规则表应与运行标识关联；即便部分步骤暂时只能手工完成，也要把操作者、输入、操作内容和复核人写进清单。手工不是原罪，不可追踪的手工才是。后来自动化时，可以从这些高频且易错的手工步骤开始。
UK Data Service 关于研究数据归档与复用的材料特别提醒：缺少一致命名规则时，很难识别正确文件版本。命名可采用“项目—对象—日期—版本”，但应把它视为入口而不是全部机制；内容标识、变更记录和输入输出关系仍需另存。
报告图表也必须有版本，不能只追到分析表
很多团队能找到清洗数据，却无法解释 PPT 中的数字，因为分析者把单元格复制到图表后又手改筛选。解决办法是给关键表图稳定编号，并在图注或交付清单中记录数据截止点、分析基数、权重、生成运行和更新时间。标题负责说结论，图表元数据负责让结论可复核。
报告修订时不要静默替换。若新数据只改变小数位，可以升级报告版本并说明；若分母、方向或建议改变，应形成更正记录，列出旧值、新值、原因、受影响页面和通知对象。版本管理的目的不是让错误永远可见，而是让后来的人知道为什么同一问题曾出现不同答案。
十分钟逆向追踪，是最实用的发布门槛
正式交付前随机选一张影响决策的图，请未参与制作的人在十分钟内完成逆向追踪：找到图表编号与报告版本，定位生成它的分析运行，核对过滤与权重参数，找到分析数据及处理规则，再确认原始快照、问卷版本和回收范围。然后从同一运行重建数字，允许的差异范围应事先定义。
追踪失败时，记录断点属于哪一类：产物没有稳定标识、运行没有保存输入、规则只存在口头说明、原始快照被覆盖，或问卷版本无法对应到答卷。先补最靠近正式结论的断点，再向上游扩展。W3C 对来源信息的定义强调参与生成数据或数字对象的实体、活动与人员或机构；这正是判断质量、可靠性和可信度所需的信息，而不是为了画一张漂亮的流程图。
在问卷派中，项目、问卷版本和回收批次构成采集端的起点。数据进入团队数据库、统计软件或报告系统后，继续保留这些标识，并把每次导出登记为原始快照。若使用 AI 辅助清洗解释或报告撰写，还要记录所用数据范围、关键指令、输出版本和人工核改；自然语言流畅并不能替代数字血缘。最终应做到：任何正式结论都能回到证据，任何规则变化都能找到受影响的结论。