人工智能论文怎么规范引用开源代码？顶会审稿人认可的引用指南

在AI领域写论文，几乎绕不开开源代码这件事。要么你用了别人的代码做基线对比，要么你把自己的代码开源出来让别人用。但很多人在这件事上栽过跟头——参考文献里随便贴个GitHub链接就被审稿人打了回来，或者代码开源了却没被正确引用，白白损失了应得的学术credit。

我自己就遇到过这种情况。投一篇会议论文的时候，方法部分用了一个GitHub上的开源实现，当时觉得在脚注里写个网址就行了。结果审稿意见回来，专门有一条说“代码引用不规范，缺少版本信息和永久标识符”。那会儿才意识到，引用代码和引用论文完全是两码事，不能图省事。

这篇文章就把AI论文里引用开源代码的规范和方法整理一下，希望能帮大家少踩点坑。

为什么一定要规范引用开源代码？

很多人觉得代码就是工具，用了就用了，没必要像引用论文那样正式。但实际在学术圈，代码引用已经成了硬性要求。

CVPR的投稿指南里就明确说了，论文应该像引用前期工作一样，引用在稿件创作过程中使用过的代码或数据集等资产。这可不是建议，是要求。NeurIPS、ICML这些顶会也都有类似的规定。

从更实际的角度看，规范引用代码有几个实实在在的好处：

保证可复现性。一篇附带代码的论文，会迅速成为后续研究的事实标准基线。如果基线不开源或者引用不清楚，后续工作的比较就会变得不公平且难以验证。很多Nature Portfolio旗下的期刊，从2021年起就实现了100%的代码共享合规。

给代码作者应得的credit。开源作者花了很多精力维护代码库，规范的引用是对他们工作的尊重和认可。有业内人士指出，代码引用还能追踪代码的重复使用情况，强化非传统学术产出（如代码、数据集、软件）的学术价值。

避免学术不端的嫌疑。用了别人的代码却不注明，轻则被指引用不规范，重则可能被认定为学术不端。现在很多期刊和学校对这方面的审查越来越严，别在这种事上翻车。

引用开源代码需要哪些信息？

引用代码和引用论文不一样，代码仓库里不一定有现成的“引用格式”等你复制。通常需要自己从仓库里搜集以下信息：

作者姓名（个人或机构）、代码的发布日期或最后更新日期、代码/程序的完整名称、版本号、代码类型（源代码、包、可执行文件、库等）、访问地址（URL）或永久标识符（如DOI）。

这些信息不一定都在一个地方。作者信息通常在README里能找到，版本号看仓库的Release标签，发布日期看仓库的创建或最新Release时间。需要自己拼凑，但缺了任何一项，引用都可能不完整。

不同引用格式怎么写？

不同期刊和会议要求的引用格式不一样，下面列几个AI领域最常见的。

IEEE格式

IEEE是工程和计算机科学领域最常用的引用格式。引用代码的基本模板是：

[#] 作者名. (日期). 代码名称. (版本号) [代码类型]. URL或出版社.

举个例子：

[1] A. Smith and B. Jones. (2024). PyTorch-UNet: A Lightweight Implementation. (v2.1.0) [Source code]. https://github.com/example/pytorch-unet

注意IEEE用的是方括号编号，参考文献按正文中出现的顺序排列。

APA格式

APA第7版在计算机科学领域也越来越常见。模板是：

作者. (年份). 代码名称 (版本号) [计算机软件]. URL

举个例子：

Research Infrastructure Team. (2025). Elixir AI Research Framework (Version 0.1.0) [Computer software]. https://github.com/example/elixir-ai

BibTeX格式

用LaTeX写论文的朋友应该最熟悉BibTeX。引用软件或代码可以用@software或@misc类型。一个完整的BibTeX条目大概是这样：

@software{作者姓氏_年份,
author = {作者全名},
title = {代码名称},
year = {2024},
version = {2.1.0},
url = {https://github.com/example/repo},
note = {[源代码]}

不管用哪种格式，全文保持一致是最基本的要求。别IEEE和APA混着用。

善用GitHub的引用功能

GitHub这几年一直在改进代码引用的支持，现在有好几个实用功能可以用。

CITATION.cff文件。从2021年开始，GitHub支持在仓库根目录放一个CITATION.cff文件。仓库主人可以在里面指定作者姓名、ORCID、首选软件名称、DOI、版本等信息。配置好之后，仓库页面会自动生成一个“Cite this repository”按钮，访客点击就能看到APA和BibTeX格式的引用。用别人的代码时，优先看看仓库有没有这个按钮，有的话直接复制就行。

DOI集成。GitHub和Zenodo有合作，可以把代码仓库的特定版本存档到Zenodo，然后获得一个永久的DOI。Springer Nature的政策也明确说了，代码应该存放在能分配永久标识符的仓库里，光给一个GitHub链接是不够的。所以如果你是自己开源代码，强烈建议走一下Zenodo的流程，给你的代码一个DOI。

引用代码时要注意的几件事

别只贴链接。这是最常见的错误。很多人觉得在正文里写个“代码见https://github.com/xxx”就算引用了。这在学术规范里是不合格的——链接可能会失效，而且没有版本信息，别人不知道你用的是哪个版本的代码。

注明版本号。代码是不断迭代的，你论文里用的是v1.0还是v2.3，必须说清楚。否则别人想复现你的实验，可能拿到的已经是另一个版本了。

区分“用了”和“改了”。如果你只是调用了别人的代码库，正常引用就行。但如果你在别人的代码基础上做了修改或二次开发，除了引用原代码，还必须说明你和原代码之间的差异。这在方法部分要写清楚。

检查许可证。开源不等于可以随便用。GitHub上的代码有各种许可证——MIT、Apache、GPL等等。使用前看一下许可证条款，确保你的使用方式（特别是商业用途）是合规的。

代码可用性声明怎么写？

现在很多期刊要求在论文里加一段“代码可用性声明”（Code Availability Statement）。Springer Nature的统一政策要求所有原创研究文章，只要开发了新的代码，就必须包含这个声明。

声明的内容一般包括：什么代码是可用的、在哪里可以找到、任何适用的访问条款。举个例子：

代码可用性：本研究所使用的所有代码已存放在Zenodo仓库（https://zenodo.org/record/xxxxx），DOI为10.5281/zenodo.xxxxx。代码采用MIT许可证，可自由获取和使用。

如果因为某些原因（比如涉及隐私数据）不能公开代码，也要在声明里说明原因和访问条件。

AI辅助生成的代码怎么引用？

这是一个越来越常见的新问题。如果你用ChatGPT、Copilot这类AI工具生成了代码片段，怎么处理？

目前IEEE还没有针对AI生成内容的正式引用格式。但通行的做法是：在致谢或方法部分披露AI的使用，说明用了什么工具、什么版本、用来做了什么。

如果AI生成的是完整的代码片段且被你直接用到了论文里，应该在代码注释或正文中注明。比如在代码上方加一行注释：# 此函数由ChatGPT-4 (2025-03-12) 生成，经人工修改后使用。

需要特别注意的是，不要把AI生成的内容当作原始文献来引用。AI不是你引用的“作者”，它只是一个工具。

最后说几句

引用开源代码这件事，说复杂也复杂，说简单也简单。核心就两条：给够信息、给对格式。作者、时间、名称、版本、URL/DOI，这五样东西凑齐了，基本就不会出大问题。

如果你是代码的作者，建议在仓库里放好CITATION.cff文件，再绑定一下Zenodo生成DOI。这样别人引用你的代码会方便很多，你自己的学术影响力也能被更准确地记录下来。

如果你是代码的使用者，花几分钟认真把引用信息整理好，别让它成为审稿人挑刺的理由。毕竟论文都写了几千字，不差这点功夫。