一、先把数据分四类定归属

1. 原始数据：谁采集谁负责，归属看项目约定

观测记录、实测结果、采集的样本数据属于这一类。归属通常由项目任务书或合作协议决定，可能归单位、归项目组共有、或归委托方。使用前要写清三件事：版权与使用权归谁、对外发布是否需要审批、项目结束后由谁保管。

这类数据的基本原则是不覆盖、只追加。任何加工都另存新版本，原始文件永远保留一份只读副本。

归属还要落到书面。口头约定在人员变动后基本失效，建议在项目启动材料里附一页数据归属说明，组内成员与新加入者各签阅一次，省去后来的争议。

2. 过程与结果：项目共有，个人有署名

清洗后的数据、分析结果、图表、模型属于这一类。归项目组共有，参与者对本人完成的部分有署名权与说明义务。使用规则要明确：跨项目引用需经项目负责人同意，对外交流时按约定处理。

3. 账号与身份数据：归个人，能少收集就少收集

姓名、学号工号、联系方式、登录记录属于这一类。收集范围要控制在必要项，存储与使用要符合学校的个人信息管理要求。这类数据不宜放在科研数据集里混存，应单独隔离。

身份数据要单独一层，不与科研数据混在同一目录，权限也只给真正需要的人。混存的后果是导出数据时一并不小心带走，处理起来很麻烦。

4. 日志与审计记录：归管理方

谁在什么时候访问了什么、改动了什么，属于运行记录，由管理方保存并在合规期限内留存。个人不应随意清理这类记录，管理方也不应用它做与安全无关的用途。

四类数据的归属不同，存储位置与访问规则自然不同。把它们混在一个目录里，是后续所有混乱的源头。

二、本地与云端各自放什么

1. 本地的三个合理用途

一是正在处理的热数据：分析过程中反复读写，放本地响应快。二是受限与涉密数据：不允许出实验室的，只能留在本地受控设备上。三是大文件缓存：原始影像、长时间序列，先落本地再按需上行。

本地的问题在于易失：硬盘坏了、机器报废、学生毕业带走，数据就断了。所以本地只作工作副本，不作单一存放处。

本地设备的访问也要管。共用工作站设独立账号，不共用同一个登录名，否则出问题时无法判断是谁改的、改了什么。

2. 云端的三个合理用途

一是主副本：作为权威版本，多人看到的都是这一份。二是协作共享：跨组、跨校合作时，共同目录比来回传文件可靠。三是长期留存：配合保留期策略，做定期归档。

云端的问题在于边界模糊：谁都能往里放，久了就没人清理。所以要配合配额、目录规范与保留期。

3. 三个判断问题

一是这份数据几个人用：多人用放共享目录，一人用可放个人空间。二是要留多久：超过项目周期的，进归档区。三是敏不敏感：敏感的只放本地或受控目录，不上通用协作目录。

三个问题各答一句，位置基本就定了。

还有延伸一问：这份数据能不能重建？可重建的可以只留过程记录，不可重建的必须有独立副本，这一问往往比前三个更能决定放哪。

三、同步与冲突怎么处理

1. 单向同步优于双向

本地工作副本向云端同步，云端作为权威版本；需要修改时从云端取回，改完再同步。双向同步看着方便，一旦两端都改过同一个文件，冲突处理会让普通人头疼。

单向同步要配合「取回再改」的纪律。有人图省事直接在本地改，改完才发现共享副本已被别人更新过，两边的差异只能靠人工比对，费时还容易改错。

2. 命名与版本号要能自证

文件名里带上日期与版本号，防止出现「定稿版」「改后」「新的」这类命名。命名规则统一之后，冲突时至少能判断哪一份更新。

3. 冲突让谁赢，规则要提前定

常见规则有两种：以云端为准，或以修改时间较晚为准。两种都不完美，关键是提前约定并让成员知道。涉及多人同时编辑的文档，改用可追溯修改记录的方式，比互相覆盖安全。

冲突规则要写清例外：涉及定稿文件时，一律以负责人确认的版本为准，不按修改时间判断。规则里没有例外，早晚会因为一份稿子吵起来。

四、协作与可见性

1. 权限按目录给，不按人给

目录级权限便于管理，人员进出只调成员归属，不逐个改权限。权限分三档足够：可读、可写、可管理。对外部合作者给限期可读，到期自动失效。

2. 外发要留痕

数据对外提供时，记录接收方、范围、用途、期限。这不是形式主义，一旦后续出现争议，这份记录是关键凭据。

外发记录用一个简单表格维护就够，字段固定：时间、接收方、内容、用途、期限、经办人。格式统一才便于核对，随手记在聊天记录里的东西，过半年基本找不回来。

3. 敏感数据不外发原件

需要给合作方看结果时，给汇总表或脱敏样本，不给原始文件。确需提供原始数据的，走审批并单独约定保管责任。

五、退出与迁移

1. 学生毕业

毕业前完成三件事：把手上的数据整理归位到项目目录，写一份数据说明，确认没有把项目数据私自带出。个人空间的资料按规则清理或转为归档。

交接时留一份数据地图：哪个目录放什么、哪些是核心结果、哪些可以删。后来的同学接手时不必从零摸索，也少走「以为删了没事、其实是仅有的中间结果」这类弯路。

2. 项目结题

按任务书要求处理：需上交的整理打包，需保留的设置保留期，需清理的按程序清理。清理前做一次全量清单核对，防止误删仍在被引用的数据。

3. 更换工具

换工具前先确认导出能力：数据能否整份导出、格式是否通用、元信息是否保留。换工具造成的数据丢失，往往不是文件没了，而是关联关系与元信息丢了。

换工具还容易丢权限设置与共享关系。导出数据的同时把共享清单一起导出，重建时按清单重设，防止漏掉合作方，出现「数据在、人进不来」的尴尬。

六、把归属写成四条约定

1. 一份数据清单

列清每个目录放什么、属于哪一类、归谁负责、放本地还是云端、保留多久。一页纸足够，但要与实际目录一致。

2. 一份权限表

写明哪些角色能读、能写、能管理，外协人员与访客的有效期。权限表每学期复核一次，把离校人员及时清出。

3. 一份保留期规则

按类别定：原始数据长期保留、过程文件按项目周期、日志按合规要求。保留期满的处理方式写清，是归档还是清除。

4. 一位责任人

课题组指定一人负责数据管理，职责包括目录维护、权限复核、清理执行。责任人变动时要交接清单，不能只交接账号。

七、三份清单的实际样子

清单不必复杂，关键是可核对。数据清单三列：目录、类别与级别、负责人。权限表三列：角色、可做的操作、有效期。保留期规则三行：长期保留、按项目周期、限期清理，各自写清适用范围与处理方式。

三份加起来两页纸，放在项目空间首页。新成员进来先看这三页，就知道东西该放哪、自己能看什么、什么时候要清。清单每学期复核一次，把离校人员、已结题项目及时更新掉。

结语

数据存在哪里，是个技术选择；归谁、谁能看、怎么带走，是项目治理的一部分。四类数据分开定归属，本地与云端各司其职，同步规则提前约定，退出路径事先想好——这四件事在开题时花两小时谈清，胜过结题时花两周翻找。判断是否定得到位，有个简单测试：随便问一位成员「你手上这批数据放在哪、谁能看、毕业时怎么处理」，如果三问都能立刻答上来，这套约定就是有效的。