企业官网建设流程全解析

1. 项目概述：OpenResearch 到底在做什么

我这两年折腾最多的一个方向，就是 OpenResearch。乍一听这名字有点唬人，其实说穿了就一句话：把研究这件事从"关起门来自己做，最后丢一篇论文出来"变成"从选题、数据、方法到结论全程摊开给别人看"。不管是做技术调研、行业分析、产品验证，还是正儿八经的学术研究，这套思路都能用。它不是某个软件，也不是特定平台，而是一整套把研究过程"开源化"的操作方式。

我最早接触这个概念，是因为自己吃了太多"研究结果不可复用"的亏。以前做数据分析项目，折腾了两周得出结论，同事想复现却连原始数据在哪都找不到；写了半年的调研报告，里面的图表做得再漂亮，也没人知道数据来源和筛选逻辑。后来我开始尝试把整个研究项目当成一个开源项目来运营，过程和结果全部公开，反而发现几个意想不到的好处：问题暴露得更早、协作效率更高、结论可信度也能打。这篇文章就把我的完整实操经验和踩坑记录整理出来，适合以下几类人看：经常做数据分析但总觉得结果"说不清"的人，想在小团队里推行透明化协作的负责人，以及任何想把自己的研究过程沉淀成可复用资产的研究者。

1.1 从"封闭研究"到"开放研究"：转变的到底是什么

过去我们对"研究"的理解，很大程度上停留在"成果导向"。老板要一份行业分析报告，你花三周收集资料、做访谈、跑数据，最后交一个 PPT，里面全是结论和漂亮的图表。这个过程看起来很高效，但它有一个致命问题：研究过程中的每一个判断、每一次取舍都被隐藏了。PPT 上写着"市场增速放缓，建议保守策略"，可为什么这么说？数据口径是什么？样本有哪些偏差？没人知道。

OpenResearch 的核心就是把"隐藏的判断过程"全部显性化。它不要求你把每一步思考都直播出去，而是要求你做三件事：数据留痕、过程留痕、判断留痕。数据留痕指的是所有原始数据、清洗脚本、分析代码全部归档；过程留痕指的是研究日志、决策记录、版本变更全部可追溯；判断留痕指的是你在关键节点做的取舍要写清楚理由，比如为什么剔除某些异常样本、为什么选择某个时间窗口。

有人担心这样会拖慢进度，实际恰恰相反。我自己的经验是，把过程记录清楚，前期确实会多花 10% 到 15% 的精力，但后面复盘和复用的时候省下的时间远远超过这个数。更重要的是，公开过程会倒逼你提升研究质量——知道别人会看你的数据处理代码，你就不会随手改完变量忘记记录；知道要发布研究日志，你就会把"凭感觉判断"改成"基于数据的判断"。

1.2 什么人适合尝试 OpenResearch，什么人暂时不用碰

先说适合的。第一种是数据分析师和科研人员，这类人的工作天然需要讲证据，把过程公开是加分的。第二种是独立开发者和产品经理，做调研、做竞品分析、做用户访谈，把原始数据和结论一起发布，能建立个人影响力，也能让团队成员更快对齐。第三种是教育工作者和学生，用开放研究的方式做课程项目，一方面防止学术不端，另一方面让初学者看到"结论是怎么来的"。

不太建议马上尝试的，是涉及商业机密和隐私数据的研究，或者流程高度标准化、没有太多判断空间的例行工作。比如你们公司内部做了个用户流失分析，里面涉及大量用户隐私和商业策略，这部分内容没有必要公开。不过"不公开结果"不等于"不用开放方法论"，你依然可以用同样的方式做好内部留痕，只是发布范围限定在团队内部而已。

我见过不少人把 OpenResearch 理解成"把数据传到网上去"，这是个误区。OpenResearch 不等于"全部公开"，它更像是一套兼顾透明与隐私的动态策略。哪些内容公开、哪些只在小范围共享、哪些严格加密，都应该在最开始就设计好。这也是我接下来要详细讲的部分。

1.3 为什么这套思路值得你认真对待

说一个让我彻底转变观念的案例。去年我帮一个创业团队做竞品分析，按照以前的做法，我大概会输出一份 30 页的 PDF，里面有市场份额、功能对比、用户评价分析，然后收工走人。但那次我尝试了全程开放的方法：调研提纲、访谈记录（脱敏后）、数据清洗脚本、分析 Notebook 全部放到一个开源仓库里，连每周写的研究日志也发在公开渠道上。

结果出乎意料。首先，有个同行看了我的数据清洗脚本，帮我指出了一个样本选择偏差问题，这个偏差如果不被指出来，会直接导致两条核心结论站不住脚；其次，有个做产品的读者在 Issues 里分享了他们内部的类似数据，让我的样本量翻了一倍；最后，项目还没结束，就有三家公司来问我能否合作做类似的内部培训。这就是 OpenResearch 的杠杆效应：你投入一次，收获的却不只是一份报告，而是外部智慧的注入、传播渠道的搭建和专业信任的积累。

2. 核心设计思路：把研究当作产品来运营

聊完了理念层面的东西，咱们进入实操环节。我这些年做 OpenResearch 项目最大的感悟是：它本质上不是在"做研究"，而是在"运营一个开源项目"。所以我的整套方法论，大量借鉴了开源社区的成熟经验，包括版本管理、Issue 追踪、文档驱动开发、持续集成这些概念，搬到研究流程里都完全适用。

2.1 从选题阶段就开始设计"开放边界"

很多人在项目做了一半才想起来要"开放"，这是最尴尬的状态。数据可能涉及隐私没法公开，代码可能是临时写的堆满了硬编码路径，文档更是根本没写。所以我现在做任何一个项目，哪怕只是内部小分析，也会在一个新建仓库文件README开头写下三个问题的答案：这个项目要回答什么问题，这个问题为什么重要，我打算用什么样的数据和方法来回答。这段文字不需要太长，三五行就行，但它的作用很关键——它会逼你在动手之前想清楚边界。

边界设计里最重要的，是数据分层。我会把所有材料分成三类：可以完全公开的（比如公开市场数据、脱敏后的统计结果）、可以在一定范围内共享的（比如团队内部的访谈记录摘要）、只能自己或特定授权人查看的（比如含个人信息的数据、未公开的商业信息）。分类不是拍脑袋，而是根据数据来源和隐私要求来定。拿用户访谈来说，原始录音和聊天记录绝对不能外传，但你整理的逐字稿可以做一个脱敏版本，把姓名、公司、联系方式等识别信息全部替换掉，再把脱敏后的内容放进公开仓库。

这个阶段还要解决一个核心问题：用哪种协议来授权你的成果。我看到太多人辛辛苦苦做了研究，却随手在仓库里写个"仅供学习参考，禁止商用"，一句话就把所有可能性掐死了。开源协议的选择应该像做技术选型一样认真。学术研究常用的 CC BY 4.0 允许别人任意使用你的内容，甚至商用，只要求署名；如果你希望代码部分也能被人直接拿去用，那就加上 MIT 或 Apache 2.0 许可证；如果只想让大家看和评论，禁止商用和修改，那 CC BY-NC-ND 更合适。没有特殊需求的话，我一般推荐 CC BY 4.0，它最大程度降低了他人的使用门槛，传播范围最广。

2.2 让研究过程可视化：日志驱动的透明化

传统研究方式里，过程是藏在研究者脑子里的。OpenResearch 要做的，就是把脑子里的东西"倒"出来。我的做法是学习软件开发的"变更日志"模式，给每个研究项目建立一份独立的日志文件，按时间顺序记录每天的工作。格式不需要复杂，日期加两三句话就行，关键是把几个要素写全：今天做了什么，为什么这么做，发现了什么问题，明天计划做什么。

这份日志的作用，我后来体会得越来越深。一方面，它让外部协作者知道项目进行到哪个阶段、哪里需要帮助；另一方面，它也是你自己的"第二大脑"。有一次我隔了两周才继续一个分析项目，打开日志瞬间就找回了全部上下文。还有一次我需要向客户解释为什么某个数据结论和三个月前不一样，翻出日志后发现当时我就记录了数据口径调整的原因——如果没有日志，这种问题真的会变成"我是谁我在哪"的悬案。

除了文字日志，我更推荐把"研究环境"也公开出来。这里的核心工具是 Jupyter Notebook 或 R Markdown，它们能把代码、运行结果、图表和文字说明整合在一个文档里。写分析代码的时候，顺手在 Notebook 里加上 Markdown 注释，解释每一步在做什么、为什么这么做，读者就不需要去猜你的思路了。你还可以把 Notebook 放在 MyBinder 或者 Colab 上，让别人一键打开就能运行，这个体验跟"看一份静态 PDF"完全是两个级别。

2.3 可复现是第一目标：环境与依赖管理

做完 OpenResearch 之后，最常被问到的问题就是"你这个结果我为什么跑不出来"。绝大多数情况下，不是代码写错了，而是环境不对。Python 版本不同、依赖库版本不同、甚至系统平台不同，都会导致结果差异。要解决这个问题，必须在项目一开始就做环境锁定。

我的标准配置是 conda 或 pipenv 加 requirements.txt 或 environment.yml。每次新增依赖，都运行命令把当前环境完整导出并提交到仓库。这里有个小技巧：依赖文件宁可多写几个版本约束，也不要只写包名不写版本。比如 "numpy>=1.20,<2.0" 这种写法，既给了系统灵活性，也避免了过大的版本跳跃。另外，一定要固定随机种子，否则你跑十次结果可能十次不同，别人更没法复现了。

如果项目涉及到数据，我强烈建议引入数据版本管理工具 DVC。DVC 可以理解为"面向数据的 Git"，它不会把大数据文件直接存进 Git 仓库，而是记录这些文件的版本、存储位置和校验值。团队里有人更新了数据集，其他人只要拉一下 DVC 元数据，再执行 dvc pull 就能把新数据同步下来。这个工具解决了很多开放研究项目的通病：代码在 GitHub 上公开了，数据却在百度网盘里，想复现的人根本找不到完整的依赖链。

3. 实操流程拆解：从一个真实项目看 OpenResearch 全流程

光讲方法论难免有点虚，我拿一个我最近完整跑完的项目来拆解。这个项目叫"社区团购用户行为分析"，是我给自己练手用的，数据来源是几个公开数据集加上我自己做的一份小问卷，整个项目完全公开在 GitHub 上。下面我把每个环节的关键操作和踩过的坑都讲清楚。

3.1 项目初始化阶段的具体动作

第一步是在 GitHub 创建仓库，名字就叫community-group-buying-analysis。初始化的时候我会写一个比较完整的 README 文件，里面包含四块内容：项目背景、数据来源说明、研究问题清单、目录结构。这个目录结构看上去有点啰嗦，但它是整套 OpenResearch 的骨架，我强烈建议你直接照抄：

/data/ raw/ # 原始数据，只读 processed/ # 清洗后的数据 external/ # 外部参考数据 /notebooks/ # 分析和建模的 Notebook /scripts/ # 数据清洗和处理的 Python 脚本 /results/ # 输出的图表和结果文件 /docs/ # 研究日志、方法论说明、报告文档

这个结构有几个讲究。raw 目录一旦写入就尽量不修改，保证原始数据可追溯；processed 目录允许覆盖，但每次清洗结束要更新数据版本；scripts 目录放所有可复用的代码，Notebook 里只放分析和可视化代码，不放数据处理逻辑，这样别人复现时更容易定位问题。我早期吃过一个亏：把所有代码全写在 Notebook 里，一个项目的数据分析脚本拆成了 8 个 Notebook，文件之间互相依赖全局变量，别说别人了，我自己运行两遍都报错。

初始化时还要立刻配置好 .gitignore 文件，把所有可能包含个人信息或有风险的文件排除掉。我惯用的是把.env文件、临时缓存目录、本地数据备份目录加进去。很多人到这一步会忽略掉操作系统自带的一些临时文件，比如 Mac 上的.DS_Store、Windows 上的Thumbs.db，这些文件虽然无关紧要，但提交到仓库里就很业余了。

3.2 数据采集与清洗阶段的透明化处理

这个项目的数据来源有两个：一个是从某数据平台下载的社区团购订单公开样本，一个是自己发的调研问卷。公开样本没什么争议，但调研问卷涉及个人信息，必须做严格的脱敏处理。

我的操作流程是这样的：问卷平台导出的原始数据先存到/data/raw/survey_raw.csv，然后写一个scripts/data_clean.py脚本，负责完成以下任务：删除姓名和联系方式字段，将用户 ID 替换为随机生成的匿名 ID，把手机号、地址等敏感文本用正则表达式剔除或打码。清洗后的数据输出到/data/processed/survey_clean.csv。整个过程记录在 Notebook 的文件说明里，注明每一步的清洗规则和原因。

这里有个重要细节，清洗脚本必须可以随时重新运行，而且每次运行结果要可验证。我在脚本里加了一行数据完整性检查，比如清洗前后的行数要一致、删除字段前先做备份、匿名 ID 的映射表单独存到外部加密文件里（不进 Git 仓库）。有一次我做别的项目图省事，直接在原始 CSV 上改了几行数据，后果就是后来想追溯的时候根本不知道哪些记录被改过，整个项目的数据可信度直接崩塌。从那以后我给自己定了一条死规矩：原始数据永远是只读的，一切修改必须通过脚本完成。

数据清洗还有一个很容易被忽视的点：要记录"数据质量报告"。清洗完数据，我会用 pandas-profiling 或 ydata-profiling 生成一份探索性分析报告，统计字段缺失率、唯一值数量、数据类型、取值分布。这份报告是研究过程的重要参考，公开出去也能让读者快速了解数据的整体情况。这个项目里我就发现的一个问题是问卷中"月收入"字段缺失率高达 23%，这个信息如果不记录，后续做任何收入相关的分析都可能是片面的。

3.3 分析阶段的版本控制与实验记录

分析阶段是 OpenResearch 最需要纪律性的时期。我的做法是每完成一个分析主题，就保存一份 Notebook 到/notebooks/目录，并在文件命名上加上序号和主题，比如01_数据探索_样本概况.ipynb、02_用户分群_聚类分析.ipynb。文件名里带着序号，可以确保别人按顺序阅读时不会被跳跃的信息搞晕。

每个 Notebook 的第一格我固定放一段文字，说明这个分析要回答什么问题、依赖哪些上游数据文件、输出了什么结果。这样做有几个好处：如果有人想跳过前面的分析直接看某个结果，只需要通过文件名和开头的说明快速定位；如果代码因为数据更新跑挂了，也可以根据依赖说明快速排查到底哪个环节出了问题。

说到实验记录，我强烈推荐用一个轻量级的工具记录每次实验的触发条件、重要参数、结果和问题。我自己比较习惯用 Markdown 写实验日志，放在/docs/experiments/下面。格式也不复杂：

# 实验日志 2025-06-12 ## 实验1: 聚类参数调整 - 目标：测试不同聚类数 k 对用户分群结果的影响 - 参数：k=4, distance=euclidean, init=kmeans++ - 数据版本：dvc-data-20250610 - 结果：轮廓系数从 0.21 提升到 0.29，分群稳定性较好 - 发现：高收入低活跃用户与中等收入高活跃用户的特征更接近，需要进一步验证

你可能会觉得这不是平白增加工作量吗？前期确实是，但到了写报告或者被别人质疑结论的时候，这份日志就是你的"免死金牌"。有一次网友在 Issues 里问我某个分群结论为什么跟另一个公开报告不一致，我打开实验日志，发现我的数据版本比他参考的早两个月，样本量差了三千多条，根源在于数据源更新。没有日志的话，这个质疑我根本答不上来。

3.4 发布环节：报告、代码与数据的三位一体

研究做到最后，输出物不再是一份孤零零的报告，而是一个"结果包"。我的标准配置是：一份主报告（Markdown 或 Quarto 生成）、若干分析 Notebook、清洗和分析代码、处理好的数据集、实验日志、环境依赖文件。这些内容统一放进同一个仓库，主报告的末尾要清楚地写明所有相关文件的路径。

发布过程中最重要的环节，是"复现测试"。我自己的习惯是发布前找一个干净的目录，把仓库克隆下来，用 README 里的命令从头到尾跑一遍，看能否复现报告中的所有数据和图表。这个过程很像软件工程里的持续集成，但因为没有现成的 CI 流程，纯靠手工跑。跑了三轮之后我总结出一个规律：只要环境下错、路径写错、相对路径命名不规范，都会在复现测试里现原形。所以现在我把所有代码路径都设定为相对于项目根目录的路径，而不是绝对路径，这样任何人克隆下来都能直接用。

关于发布渠道，我会把代码和数据放 GitHub，主报告也会同步发布到我的个人技术博客上，同时写一篇摘要发到知乎和相关技术社区。GitHub 仓库的 README 就是整个项目的入口，必须写得足够友好，让人一眼看懂项目在做什么、怎么复现、目录怎么组织。我一般还会在 README 的开头放一个项目状态徽章链路，标注"数据收集完成""分析进行中""结论待验证"这类状态，信息更新及时对建立信任感很有帮助。

4. 工具选型：这些年我留下来的组合方案

OpenResearch 不绑定固定工具，但选对工具能省掉八成的麻烦。我前后试过十几种组合，最后留下来的是一套偏轻量化的方案。不是说它是最优的，但应该能给你一些选型参考。

4.1 文档、代码与版本协作的黄金组合

GitHub + Markdown是整套方案的底座。GitHub 的意义不仅在于免费托管代码，更在于它提供了 Issues、Projects、Actions 这些协作基础设施。我把 Issues 当任务看板用，把需求、问题、建议、Bug 全部记录下来，每个 Issue 打上标签（比如"数据问题""方法讨论""报告修改"），处理完就关闭并关联到对应的 Commit。这样外人看仓库的时候，能从 Issue 列表直接了解项目的历史脉络。

Markdown 作为内容载体也是经过了长期验证的。它不像 Word 那样充满格式干扰，又比纯文本更适合结构化写作。我所有的研究日志、方法论说明、最终报告都用 Markdown 写，配合 Git 完成版本管理。写文档的时候只要记住一条原则：一个文件只负责一个主题，不要试图把所有内容塞进一个超长文档。

Python 科学计算生态是数据分析项目的核心支撑。这里我列一下我的标准依赖清单给你参考：pandas 负责数据处理，numpy 做数值计算，matplotlib 和 seaborn 做可视化，scikit-learn 做建模，statsmodels 做统计分析，jupyterlab 做交互式分析环境。项目管理的辅助工具方面，我用 DVC 管数据，用 conda 建虚拟环境，用 pre-commit 做代码规范检查，基本覆盖了日常需求。

4.2 数据版本管理的 DVC 实战配置

DVC 这个词听起来有点进阶，但实际配置起来非常简单。初始化阶段执行dvc init生成.dvc目录，然后运行dvc add data/raw/survey_raw.csv，DVC 会生成一个.csv.dvc元数据文件，里面存有文件的 MD5 哈希值和路径信息。这个元数据文件是轻量文本，可以直接提交到 Git；原始数据本身则通过dvc remote add配置存储位置，我一般用阿里云 OSS 或者腾讯云 COS，也可以用本地 NAS。

使用 DVC 后，最明显的变化是数据更新的可追踪性。以前同事更新了 Excel 数据，我根本不知道他改了什么；现在 DVC 每次都会生成新的哈希值，Git 提交信息里能看到"数据更新至 2025-06-12 版本"。更重要的是，别人想复现的时候不再需要手动去下载数据，只要执行dvc pull就会自动从远端拉取对应版本的数据文件。

4.3 套件之外，我还推荐这些轻量辅助工具

如果你觉得 GitHub + DVC + Jupyter 这套已经够用了，那下面的工具可以按需增补。Quarto 是我目前最推荐的报告生成工具，它能同时输出 Markdown、HTML 和 PDF，直接在文档里嵌入 R 或 Python 代码块，执行后把结果和图表直接渲染进报告，特别适合需要"代码+结果+文字"三位一体的情景。你写一次，改动数据后整个报告自动重新生成，不用手动去粘贴截图。

还有一个很多人容易忽略的工具是nbconvert，它能把 Jupyter Notebook 转换成独立的 HTML 文件。我发布结果包时常会用这个命令，把带完整输出的 Notebook 转成 HTML 放到网站上，这样不熟悉 Python 的读者也能直接看结果。对极简主义者来说，Jupyter Book 也是个不错的选择，它能把多个 Notebook 组织成一本可导航的在线书，展示效果比单独丢文件好很多。

不过工具永远是服务目标的。我见过有人花大量时间折腾文档系统和自动化流水线，研究本身却没什么进展，这是本末倒置。我的建议是：先用最朴素的 GitHub + Markdown 跑通一个项目，再用 DVC 解决数据问题，遇到报告生成麻烦再引入 Quarto。每个工具都要等到"痛得受不了了"再上，这样你才能真正理解它的价值。

5. 常见问题与排查技巧实录

做 OpenResearch 这两年踩过不少坑，我把出现频率最高的问题和对应的解决方案整理成一个速查表，希望对你有用。

5.1 被别人质疑数据问题时怎么回应

这是 OpenResearch 实践中最容易让人心态爆炸的场景。你辛辛苦苦做完了分析，公开发布后，评论区跳出来一个人说"你的数据来源不可信""你的样本量太小""你的清洗方法有问题"。我早年的第一反应是防御，后来发现正确的处理方式应该分三步走。

第一步，查看对方的具体论据，判断他看的是不是旧版本的数据或者分析逻辑。如果你的仓库做了完整留痕，直接定位到对应版本，确认对方是否基于新版本提出的质疑。第二步，如果质疑确实有道理，那就公开承认并展示你如何修正问题，这恰恰是开放研究的优势所在——错误可以被快速发现和修复。第三步，如果只是对方理解偏差，用研究日志和实验记录里的证据心平气和地解释即可。别怼人，因为开放交流带来的正面收益远远大于一时的嘴仗快感。

5.2 隐私与开放的边界到底怎么划

这是我在实战中最常被问到的问题。我的经验是遵循"最小可用公开"原则：公开的数据必须是支持结论和复现所需的"最小必要集合"，而不是把能公开的都丢出来。凡是涉及能定位到个人的信息，都必须做脱敏处理；脱敏也不是简单地把姓名替换成"用户A"，还要考虑间接识别风险——一个城市加上年龄段加上职业描述就完全可能定位到某个人。

实操层面，我的做法是建立隐私检查清单：数据脱敏是否完成了名字、联系方式、地址、设备指纹的清理；是否对所有唯一识别符做了重映射；删除字段或模糊化是否影响核心分析结论；如果影响，是否可以在不公开原始数据的前提下，发布聚合统计结果。拿社区团购项目举例，我最终公开的数据集去掉了用户 ID 和精确地址，只保留到街道级别的区域代码，年龄段使用了五岁一个区间的粗粒度划分。这组数据跑完所有分析后，结论跟全量数据几乎没有差异。

5.3 时间精力不够用怎么办

开放研究确实比"自己闷头搞"多花一些时间，所以我反思过这个问题。后来我发现，多花的时间主要集中在前期的数据整理和文档记录，而这些工作本质上不是额外成本，而是把原本必须做却没做的事补上了。传统研究方式里，你写完报告后可能要花更多时间向同事解释、被别人追问数据来源、甚至被客户来回反推逻辑，这些隐形成本算进去，开放研究的额外开销并没有想象中那么大。

另外，可以大幅压缩不必要的形式化内容。研究日志不用长篇大论，每天三五行即可；README 也不用一开始就写得很完美，能跑通就行，后续慢慢补充。我自己也在实践"文档的持续集成"理念：不是集中两天写完所有文档，而是每天花二十分钟随手补充，这样总时间反而更少。

5.4 别人会不会拿着你的成果去抢发

聊到开放研究，几乎每个人都会问这个问题：我辛辛苦苦收集的数据、跑出来的结论，全公开了，别人抄袭怎么办？我的回答是，开源世界里"抢发"这件事的难度远比你想象的高。因为公开仓库里的 Git 提交历史、Issues 讨论记录、实验日志共同构成了一条完整的时间线，这些散落的信息本身就有法律和事实层面的证明力。假如真的有人拿你的东西去抢发论文，仓库的提交记录就是你是原始作者的最好证明。

更重要的是，开放带来的"先发优势"往往比保守更强。你的研究过程公开后，会有更多人在你之前提到的工作基础上做扩展研究，形成持续的引用和讨论链，而这种被引用的价值通常会被忽视。反过来，如果你把所有东西都藏起来，等到论文发表了再公开，你收获的只是一个孤立的结果，大概率不会有人主动在你的研究上进行延伸。这两年的亲身经历让我确信，开放研究的护城河不是保密，而是"迭代速度+社区参与度"。你要做的不是防止别人抢跑，而是让自己跑得更快，并让越来越多的人愿意陪你一起跑。

写在最后：一个小建议

如果你看完这篇文章只打算做一件事，我建议你把手头正在做的某个小研究项目，试着开源出来。不用立刻做完整套配置，先把分析 Notebook 和原始数据放到 GitHub，然后在 README 里简单写三行：项目是做什么的、数据从哪来、当前结论是什么。就这么简单。跑完一轮之后，你再回来体会"研究过程被全透明保存"是什么感受，大概率会跟我一样，再也回不去那个只有结论没有过程的时代了。