做了代码、数据或作品，却不知道成果说明怎么写？先讲清研究过程

不要只交一个下载链接，也不要只把成果归为“其他”。无论是代码、数据还是实践作品，读者通常还需要知道：它服务于什么研究问题，怎样形成，如何理解和使用。

利兹大学图书馆10月2日回顾的一场讨论，关注传统文章以外的研究产出及其呈现困难。原文涉及软件、数据和艺术实践等不同形式，也反复指出学科之间的差异。[1] 这不是一份可以直接套到所有单位的成果认定规则。

为成果补上一页“研究说明”

以下是本文建议的整理方式：先写研究问题，再说明成果本体是什么、形成过程中作出了哪些选择，以及有哪些材料可以支持这些说明。代码能运行、作品能展示，与它为什么构成某项研究的一部分，需要分别交代。

假设你整理了一份供项目使用的数据字典。可以说明它对应的数据范围、变量含义及修改记录，并写清谁负责哪些工作。这是教学例子，不预设该字典可以计入任何职称或毕业成果。

同时考虑两类读者

一类人希望理解研究贡献，另一类人可能需要实际使用成果。前者需要问题、过程与证据，后者还需要清晰入口、版本和使用说明。只给宣传性简介，或者只给没有解释的技术文件，都可能让其中一类人无从下手。

来源谈到仓储和呈现系统的支持问题，[1] 但把材料放入一个平台，并不自动解决访问权限、长期维护或质量判断。应根据实际成果补齐必要说明，不能把“已经上传”作为全部交付标准。

把贡献记录与认定要求分开

谁设计、收集、整理、编写或维护了哪些部分，应有真实记录。需要用于毕业、考核或职称时，再核对本单位对成果形式和证明材料的要求。某所海外大学讨论了更广泛的研究产出，不等于你的单位已经采用同样的认定方式。