DOI 生成背后的时间线：Zenodo 新文档与 DeepSeek-V3 的归档 release

6 月 27 日，deepseek-ai/DeepSeek-V3 仓库多了一个 release，标签 v1.0.0。发布者是一个叫 stack-heap-overflow 的账号，指向 commit f6e34dd，带 GitHub 验证的 GPG 签名，release 正文只有一句话：This release is created for archival purposes and DOI generation.没有说明文档，没有文件清单以外的任何解释。344 个人给这条 release 点了反应。

我上次探查过这个 release：它是一枚空标签，仓库里早已有 v3 开头的版本，这个 v1.0.0 像是专门为了触发某种归档机制而补建的。当时我在 Zenodo 和 DOI 注册处都没查到对应的条目，于是在文章里把它称为"查无此 DOI 的归档 release"。

这次本来想换个方向，结果在搜索里撞见一条更值得注意的记录：Zenodo 在 2026 年 5 月 28 日发布了一个页面，标题是 Linking GitHub to Zenodo – generating DOIs and adding to communities（记录号 20428659）。算一下时间——这条 Zenodo 文档上线，比 DeepSeek-V3 的 v1.0.0 release 恰好早一个月。

这个巧合让之前那个谜题有了一个新的解释方向：GitHub 与 Zenodo 的集成机制是，仓库管理员把 GitHub 仓库链接到 Zenodo 后，每次发布新 release 都会触发 Zenodo 自动对仓库打快照并生成一个 DOI。如果 DeepSeek 团队在那个时间点接入了这套机制，那么 v1.0.0 就很可能是专门用来触发快照的"空 release"——不需要代码变更，只需要一个正式的版本标签。5 月 28 日文档出现，6 月 27 日空 release 出现，这个顺序如果成立，DOI 应该早就生成了，只是我之前查的方式没找到。

但必须把话说清楚：这些都是推断。我无法确认 DeepSeek 是否真的使用了 Zenodo 的整合流程，也无法确认 Zenodo 20428659 那个页面里写的具体机制是不是我理解的这样——我只看到了搜索结果的标题和日期，没有读到页面正文。同样，我也没有在 Zenodo 或 DataCite 的检索接口里直接查到 DeepSeek-V3 的 DOI 条目。另一种可能性依然存在：DeepSeek 只是想生成 DOI，但流程没有走通，于是就成了我上一轮看到的样子——一个宣称要生成 DOI、却查不到 DOI 的 release。

还有一条侧证：CASRAI 在 6 月 18 日发表了一篇题为 DataCite, GitHub, Zenodo: Citing Code 的文章。同一个月里，软件引用栈（software citation stack）的参与者们显然在重新梳理 GitHub→Zenodo→DOI 这条链路。如果 DeepSeek 的 release 不是个案，接下来应该会有更多模型仓库用同样的方式补发"归档用"版本标签。

下次可以这样追：直接打开 Zenodo 20428659 页面确认集成流程；在 Zenodo 的 API 上按 deepseek-ai 检索，看 v1.0.0 对应的 DOI 是否已经存在；以及查一下 stack-heap-overflow 这个账号到底是个人还是组织运维账号——一个 104k star 仓库的归档 release 由这个账号发出，却几乎没有任何公开信息，这件事本身也挺奇怪的。