英文题目：“See Link for More Details”: Towards a Pragmatic Open Methodology at NIME.
会议身份：
conference:nime:2026:conference-paper-id:nime2026_31
✅ 来源为官方会议 PDF；表格与 Figure 按原文证据绑定。PDF 公式以原页区域图片展示，未冒称作者原始 TeX。
标签：#数据集 #开源工具 #文献计量分析 #音乐理解
评分：7.8/10 | 创新 1.2/2 | 技术严谨 1.2/1.5 | 实验充分 0.9/1.5 | 清晰度 0.8/1 | 影响力 1.0/1.5 | 开源 1.2/1.5 | 可复现 0.3/0.5 | 工程/实践 1.2/1.5
排名：前25% | 文档类型：方法研究
👥 作者与机构
- Matthew Hamilton：机构信息未能从会议 PDF 纯文本可靠映射
- Michele Ducceschi：机构信息未能从会议 PDF 纯文本可靠映射
- Lucia Michielin：机构信息未能从会议 PDF 纯文本可靠映射
📌 核心摘要
本文以NIME论文库为输入，输出数字乐器源材料可发现性、可访问性与可引用性的实证诊断，难点在于链接位置异构、仓库失效与外部引用和自身公开混杂难区分。审计第一步针对2017–2025年论文用pdfgrep正则逐年检索git等源仓库统一资源定位符，记录脚注、正文、引用、附录位置并增补缺失类，其分类结果进入跨年趋势统计。第二步将同一检索扩展至2001–2025年全库，区分引用外部开源项目与公开自身源材料并统计GitHub专属比例，以承接前步位置分布并揭示引用与公开缺口演化。第三步以NEMUS历史羽管键琴增强界面为验证，将固件、电子设计与模型拆为三子模块并以元仓库聚合，再经Zenodo独立归档交叉引用数字对象标识符，检验前两步发现的脆弱链接问题的可行修复。在NIME 2025年论文语料统计设置下，意图分享源材料的论文数量指标为37篇，低于该年论文总量数量指标的96篇。相对已有方法关键差异在于不要求可构建可执行、仅以明确分享意图为纳入标准，并以缺失类与子模块独立归档应对链接腐烂与单体仓库不可持续问题，提升长期可重建性。该结论适用边界限于NIME及类似艺术工程会议，外推至一般人文学科尚未验证，原文未披露训练、推理或部署成本。
🔗 开源与复现资源
- 代码相关资源：https://github.com/Nemus-Project/fair-nime-2026 — 链接可访问（HTTP 200）
- 数据相关资源：https://github.com/Nemus-Project/fair-nime-2026 — 链接可访问（HTTP 200）
- 数据相关资源：https://doi.org/10.5281/zenodo.19443616 → https://zenodo.org/doi/10.5281/zenodo.19443616 — 暂时无法访问
- 复现相关资源：https://github.com/Nemus-Project/fair-nime-2026 — 链接可访问（HTTP 200）
- 复现相关资源：https://doi.org/10.5281/zenodo.19443616 → https://zenodo.org/doi/10.5281/zenodo.19443616 — 暂时无法访问
- 第三方资源：https://gitlab.com/pdfgrep/pdfgrep/-/tags/ — 链接可访问（HTTP 200）
- 第三方资源：https://doi.org/10.25495/7GXK-RD71 → https://zenodo.org/ — 暂时无法访问
- 第三方资源：https://doi.org/10.5281/zenodo.5171937 → https://zenodo.org/record/5171937 — 暂时无法访问
- 第三方资源：https://docs.kicad.org/9.0/en/kicad/kicad.html# — 链接可访问（HTTP 200）
- 第三方资源：https://doi.org/10.5281/zenodo.17811082 → https://zenodo.org/doi/10.5281/zenodo.17811082 — 暂时无法访问
- 第三方资源：https://doi.org/10.5334/joh.7 — 暂时无法访问
- 第三方资源：https://oshwa.org/resources/sharing-best-practices/ — 暂时无法访问 可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。
🧭 深度解读
输入是什么：为何乐器论文需要可复述的材料？
这篇解读的输入是论文原文提供的普查证据与案例证据，目标是让刚进入语音、音乐与音频方向的研究生能复述作者做了什么、在什么条件下得到什么结论。必须保留的信息包括研究对象的时间范围、判定分享意图的操作定义、检索工具与耗时、案例乐器的组织方式与归档做法，以及资源当前是否可达的状态区分。输出是一套可核对的方法复述，而不是对开放运动的一般赞美。
论文研究的新乐器界面不是纯软件插件，而是一个包含固件、电子原理图与印制电路板文件、外壳建模与测量文档的组合体。白话说，固件是跑在微控制器上的程序，负责把按键或传感信号变成声音或触觉反馈；硬件设计文件负责说明电路如何焊接与复刻；模型与文档负责说明外壳尺寸与组装关系。英文名分别是 firmware、computer-aided design 与 model data。只有当这 3 类材料都能被定位、取出与引用，后来者才能在不猜测的前提下重建。
开放研究实践 × FAIR 原则： 开放研究实践在本论文中指透明、可验证、可复用与可访问的一组做法，FAIR 原则指可发现、可访问、可互操作、可复用的数字研究原则；开放研究实践负责提出分享与引用的行动要求，FAIR 原则负责给出数字对象能否被定位、读取、组合与复现的检验标准，二者搭配使数字乐器界面从一句开放声明变成可被检索、取出与引用的研究对象。
论文把这种要求放在开放研究实践与 FAIR 原则的脉络下讨论。开放获取解决论文本身能否免费读到，开放方法解决论文背后的材料能否被找到与重用。作者强调的矛盾是使用开源工具的人越来越多，但把自己项目的完整来源交出来的比例并没有同步跟上，链接放哪里、链接是否还有效、改版后旧引用指向谁，这些细节决定了开放是口号还是可执行的操作。
相关路线如何从呼吁开放走到检查链接？
按同输入、同目标、同运行阶段对照，相关工作可分为 3 条线。第一条是社区治理线，论文回顾了 NIME 自创办起坚持会议论文集开放获取，金色开放获取与 2017 年起采用知识共享署名许可，以及 2020 年把自由与开源研究实践写入伦理指南。这条线与本论文同输入，都是 NIME 论文集，但目标是规范层面，尚未解决每篇论文的材料放在何处。
第二条是可复制性讨论线，包括早期关于可重复研究、可复制与迭代、长期可持续的工作坊，以及提出共享乐器设计仓库但最终未能落地的讨论。这条线与本论文同目标，都希望后来者能重建，但运行阶段停留在呼吁与框架建议，缺少对 2009 年至 2025 年全量论文链接现状的测量。
第 3 条是直接前序测量线，即分析 2018 年至 2020 年文档供给情况的研究，以及统计全档案中按托管服务分类的开源仓库使用情况与 2022 年至 2024 年新建仓库数的研究。本论文沿用其思路但做了更严格的区分：一是把引用了开源项目的论文与真正给出自己项目来源链接的论文分开计数，二是把链接出现位置分为脚注、正文、引用与附录并增设缺失类，三是把检索词从宽泛的开源相关词收敛到版本控制痕迹与源码库痕迹，从而能同时回答多久分享 1 次与开源实践多普及两个问题。
要回答的两个问题是什么？
论文提出两个可操作的问题。第一个问题是 NIME 论文多久链接到自己项目的源材料，第二个问题是开放研究实践在 NIME 有多普及。前者看作者是否有明确给出可代表论文工作的仓库的意图，不要求仓库可编译、可运行或完整；后者看论文是否引用了基于版本控制或老牌托管服务的开源项目。
举例说明二者差异。假如 1 篇论文在方法部分写道本作品使用了某个开源音频库并给出该库地址，这计入使用了开源，但不计入分享了自己的来源；只有当论文给出指向本作品固件或硬件仓库的地址，或给出能跳转到该仓库的项目主页，才计入分享。这种区分是后续所有图表的基础，初学者复述时必须先讲清，否则会把两条上升曲线混为一谈。
论文还明确了判定边界。指向包含来源链接的项目网页也算分享，在可移植文档中显示断裂但可手动补全的超链接也算分享；链接完全缺失、仓库不可达、仓库完全为空，但按项目名在搜索引擎第一页能找回仓库的，被归入缺失类并计入当年分享总数。这个宽容口径意味着报告的分享比例是保守估计中的上限侧，而非严格可复现比例。
方法全景：一次普查加一个全程跟进的案例
整体方法分两段。第一段是对论文集的普查，先下载按年份分目录存放的全部可移植文档，再用开源软件 pdfgrep 在文本层检索，最后对未命中做人工通读补检。第二段是对 2025 年一个历史羽管键琴键盘增强界面的开放方法跟进，记录项目从会前到会后如何拆分、改名、打标签与归档，提炼出源集合、版本控制、归档、文档与许可 5 个基础设施维度。
git 子模块 × 元仓库： git 子模块负责把固件、电路辅助设计与 enclosure 建模数据作为独立仓库分别演进，元仓库负责用一个统一入口引用这 3 个子模块的特定提交；子模块分工是解耦不同节奏的硬件与软件修改，元仓库分工是给出跨部件的一致视图与版本标签，组合后读者只需记住一个地址就能检出整套界面在某一时刻的状态。
该案例的乐器起点是为博物馆展陈与研究制作的两台不同形态的界面，共用核心部件但处于不同开发阶段。最初的做法是把固件、电路辅助设计与模型数据拆成 3 个独立仓库，原文分别给出各自链接。随着开发推进，电路部分转向原理图与制板文件，模型部分转向外壳测量文档，原链接与论文描述的对应关系逐渐错位。作者于是引入一个元仓库，用版本控制的子模块功能把 3 个部件在特定提交上 pin 住，并用版本标签标出不同界面版本，使时间上的状态导航只需分享一个地址。
以下示意图展示这种 1 对三的组织关系，初学者应先把它理解为论文方法的核心动作，后续归档与引用问题都由此结构引发。
看图路径： 1. 先找到下方 Interface Meta Repository 方框，确认它是唯一入口；2. 再沿三条向上箭头数出 Firmware、CAD、Model 三个子模块；3. 注意三者并列无先后，说明硬件软件是平行部件而非单一代码库
论文图 3。原论文 Figure 3：“The DMI is divided into three submodules, each representing the firmware, electronics schematics and en- closure modelling data.”。
这张图把复述的关键从抽象原则落到具体结构。上方 3 个并列方框是可独立演进的部件，下方一个方框是代表界面的统一入口，箭头方向表示入口引用部件而非复制部件。理解这一点后，才能明白为何后续归档时直接打包元仓库并不能自动带走子模块内容，为何改名会破坏旧引用，以及为何需要持久标识与交叉引用清单。
五个维度如何决定乐器能否被找回与重建？
案例提炼的 5 个维度各有明确检查点。源集合要求列出构成项目的全部制品，包括固件、原理图、外壳模型、数据集与文档，缺一类都会让重建停在某一步。版本控制要求用版本控制系统记录变化，使后来者能回到论文发表时的提交而非只能看到最新版。归档要求给出带持久标识的稳定快照，使引用不依赖商业托管平台的持续在线。文档要求让他人能理解、复用与修改，许可要求写明使用、修改与再分发的条款。
版本控制 × 归档： 版本控制负责记录固件、电路与模型随时间的每 1 次变化与分支状态，归档负责把某一时刻的状态冻结为带持久标识的可引用快照；版本控制解决演化过程中的可追溯问题，归档解决平台关闭或链接漂移后的可取证问题，二者组合才能让不断改动的乐器仍有一个可被他人复述的确定版本。
在该案例中，源集合的划分是 3 个子模块，版本控制用 git 与子模块引用实现，归档用欧洲核子研究组织的数字归档平台实现，文档对固件使用了 Doxygen 生成的接口文档但作者承认仍缺用户手册，许可与引用格式遵循软件引用与硬件模板的既有建议。作者强调这不是穷尽式合规，而是够用型实践，即优先保证能定位、能检出、能引用，再逐步补文档深度。这种取舍对研究生有直接指导意义：先保证仓库结构清晰与版本可回溯，再谈文档文笔。
有无模型训练？实际计算过程是什么？
本研究没有训练神经网络模型，也没有冻结或更新任何模型参数，不存在梯度路径、监督损失或重置时机的报告。把无训练理解为确定性求解是误解，论文的计算过程是非确定性的人机检索与归档操作，其可重复性依赖检索表达式、人工复核规则与归档时的版本选择。
实际执行的第一类计算是文本检索。作者先用匹配版本控制痕迹的正则表达式扫描 2017 年至 2025 年论文，若无命中再依次用开放源码、源代码与仓库等表达式补扫，每年单独检索，命中后记录地址与上下文并把该论文移出待查池，剩余论文逐篇人工通读。对 2009 年至 2025 年的开源使用普查，则从较宽的表达式起步，先用排除托管平台后缀的模式去掉明显真命中，再识别跨行断词、乐器名误命中等假阳性并迭代收紧表达式，同时保留老牌托管服务等有效变体。
第二类计算是案例构造。作者把演进中的 3 个部件在元仓库中 pin 到特定提交，打版本标签区分展陈版与研究版，把制板文件从已停服的专有格式向仍可转换的开放工具格式迁移，对固件生成接口文档，并在归档平台上对每个子模块独立归档后再归档元仓库，手工写明交叉引用。这些步骤没有 reported 的超参数，只有可复述的操作顺序与工具选择，缺失项是人工通读的具体耗时分配与误判率，原文未报告检索的查准与查全率。
普查在什么语料与判定下进行？
语料是 NIME 论文档案，2017 年至 2025 年共 818 篇论文被纳入来源链接位置普查，2009 年至 2025 年论文被纳入开源使用普查。2001 年至 2009 年论文不含版本控制引用，托管平台在 2010 年后才出现在论文中，这些时间边界在解读趋势起点时必须保留。检索在按年分目录的文档集上运行，2017 年至 2025 年部分采用自动加人工的混合流程，作者报告总耗时略超 20 小时，结果应视为保守估计而非穷举。
判定上，分享意图的门槛是给出代表论文工作的仓库或能跳转到仓库的页面，不检验可构建性；缺失类包括链接错误、空仓库与靠搜索推断的现存仓库。开源使用的门槛是出现版本控制或老牌托管服务痕迹，并计入通过个人页面跳转到仓库的间接引用。指标方向是占比越高越开放，但缺失占比越高则越脆弱，二者需同时阅读。
下图是位置分布的原始呈现，阅读前需先确认它的统计口径是占当年论文总数的百分比，堆叠段为互斥的位置分类加缺失类。
看图路径： 1. 先确认横轴是占当年论文总数的百分比，纵轴是 2017 至 2025 年份；2. 再按图例区分深蓝脚注、浅黄正文、深绿引用、浅蓝附录与红框缺失；3. 对比 2025 年深蓝段与其他年份长度，判断脚注是否始终是主流位置
论文图 1。原论文 Figure 1：“Methods used to share project source URLs in NIME 2017–2025 papers.”。
该图覆盖 2017 年至 2025 年，每年一条横向堆叠条，深蓝为脚注，浅黄为正文，深绿为引用，浅蓝为附录，红框为空心表示的缺失。可见脚注始终是最长的一段，2025 年脚注段达到全期最高，同时缺失段在 2022 年与 2025 年明显变长。这支持后文的判断：分享总量在涨，但放哪里不统一且部分链接已不可用，寻找材料仍需解释与猜测。
分享了多少？用了多少开源？缺口在哪里？
核心结果分 3 层。第一层是分享总量的缓慢上升与位置分散。2025 年 96 篇论文中有 37 篇表达了分享来源的意图，脚注是最常见的位置。按年份看，脚注占比从 2017 年的个位数涨到 2025 年的高位，正文占比在 2022 年至 2023 年达到高点后回落，引用与附录占比始终较低，而缺失占比随总量一起波动上升。这说明意愿在增强，但规范位置没有形成。
第二层是托管集中度。按服务统计的项目源仓库数显示，主流托管平台在每年占绝对多数，其他平台与自托管实例很少，2023 年与 2025 年主流平台各有 31 个仓库，老牌托管与网盘类服务在多数年份为个位数。这与版本控制即事实标准的判断一致，也意味着长期保存过度依赖单一商业平台。
下图把使用开源、仅用主流平台与分享来源 3 条线放在同一百分比坐标下，时间跨度为 2009 年至 2025 年，是理解采用与实践缺口的关键。
看图路径： 1. 先按图例区分蓝色使用开源、黄色仅用 GitHub、红色分享源码三条折线；2. 再沿 2010 到 2025 年观察三线总体上行与 2020 年前后红线的回落；3. 注意蓝线长期高于红线，读出使用与分享之间的持续缺口
论文图 2。原论文 Figure 2：“Yearly percentage of NIME papers (2009–2025) in three categories: papers referencing at least one open source project using a git or SourceForge repository, papers referencing…”。
图中蓝色使用开源线长期最高，黄色仅用主流平台线紧随其后，红色分享来源线自 2017 年起出现且长期低于蓝线。2020 年前后红线出现明显回落，2022 年后三线同步上行但蓝线与红线之间仍有 10 个百分点量级的差距。结合上一张位置图，可以复述为熟悉开源工具不等于交出自己项目的可复现来源，缺口是结构性的而非态度性的。
为便于核对，把 2025 年总量与位置分布整理成下表。表前的问题是 2025 年的分享意图有多强、放在哪里、脆弱部分有多大；公平条件是同一年论文总数归一化，指标方向是分享段越高越好、缺失段越低越好。
2017 年至 2025 年共 818 篇论文纳入统计，其中 2025 年 96 篇论文中有 37 篇表达分享意图，其位置百分比分布如下，数值单位均为占当年论文总数的百分比，裸值按原图直接保留。
| 条件 | 指标 | 分享总数占比 | 脚注占比 | 正文占比 | 引用占比 | 附录占比 | 缺失占比 |
|---|---|---|---|---|---|---|---|
| 2017-2025 全量 | 论文总数 | 818 篇 | — | — | — | — | — |
该表的主要收益是给出可复述的锚点：2025 年约四成论文有分享意图，其中约一半意图落在脚注，缺失段与正文段体量相当，说明即使按宽容口径计入可搜索找回的仓库，仍有与正文披露相当的体量处于不可直接点击的状态。代价是该表未区分软件、数据集与手册类分享，也未检验仓库是否可构建，因此不能从 37 篇直接推出可复现数。未胜出项是引用与附录位置，其占比长期低，说明把仓库当正式引用仍是少数做法。
哪些变化会让开放失效？托管与格式的对照
论文没有神经网络消融，但提供了两组论文特有的对照与失败条件。第一组是托管服务的年份对照，问题是离开主流平台后还有多少仓库可见；条件是同一年论文集内的项目源仓库计数，指标方向是数量越高越集中。第二组是版本演进对照，问题是项目改名、拆分与改版后旧引用是否仍有效；条件是同一乐器在展陈版与研究版两个阶段的材料组织，观察指标是原文链接能否映射到当前状态。
下表整理 2022 年至 2025 年托管分布，表前问题是集中度是否逐年加深，公平条件是每年独立计数同一类项目源仓库，指标方向是主流平台数越高越集中、其他平台数可作为多样性参考。
2022 年至 2025 年项目源仓库按托管服务计数，单位为仓库个数，裸值按原文表格保留，GitLab 列含自托管实例。
| 年份 | GitHub 仓库数 | GitLab 仓库数 | Other 仓库数 | 集中度含义 |
|---|---|---|---|---|
| 2022 年 | 18 | 1 | 2 | 主流平台占多数 |
| 2023 年 | 31 | 3 | 0 | 主流平台显著集中 |
| 2024 年 | 25 | 0 | 2 | 主流平台占多数 |
| 2025 年 | 31 | 0 | 5 | 主流平台占多数，其他略回升 |
表后解释是主要收益与代价。收益是确认了版本控制托管的事实标准地位，读者学会用主流平台地址去找材料在多数年份有效；代价是单点依赖，平台策略或仓库改名即导致旧引用漂移。反例是 2025 年 Other 回升到 5 个，说明仍有作者把材料放在网盘或个人页面，这类地址更难被自动检索捕获，也更容易失效。未评测边界是私有仓库转公开的时间滞后与链接修复率，原文未测量。
第二组对照的失败条件更具体。电路文件最初使用已停服的专有格式，虽仍可向开放工具格式转换，但转换本身就是额外门槛；子模块改名会破坏旧链接；归档平台的托管集成不会自动打包子模块内容，必须逐个归档再手工交叉引用。这些都不是作者不愿开放，而是模块化与演进带来的结构摩擦。教学上应把它们记为复现时必查的三处：文件格式是否开放可读、引用的是哪个提交、归档清单是否含全部子模块标识。
结论的边界与未验证的推测是什么？
论文直接报告的是链接位置分布、托管集中度与案例中遇到的归档障碍，这些有图表与操作记录支持。有限解释是采用与实践缺口是结构性的，即难在如何组织与指路而非愿不愿意分享，这一判断得到位置分散、缺失随总量上升与案例演进错位的支持，但未做因果检验。未验证推测是统一项目链接字段与够用型分享能降低复用门槛并吸引新创作者，这属于待验证的治理建议，原文没有对照实验测量加字段前后的找回率或复刻成功率。
缺失证据不是技术错误，但复述时需明确。原文未报告检索的查准查全、未检验仓库可构建性、未测量文档完整度与复刻耗时，也未统计补充材料归档的长期可达率。相关性不等于因果，使用开源比例高不等于社区更可复现。训练资源、推理开销与延迟等概念不适用于本研究，不应承诺本方法改善了这些量。总体趋势向上不等于每年都涨，2020 年前后分享线的回落与个别年份正文占比的波动就是反例。
另一个边界是学科差异。论文引用的框架多来自科学领域，人文与艺术研究中的开放实践尚未成标配，乐器研究兼具工程与创作属性，全面合规可能不现实。作者因此主张够用型透明，而非更严的形式要求，这一定位应在复述结论时保留，否则会把建议误读为强制标准。
复现先做什么：从一个地址到可引用快照
复现本论文的普查部分，先准备按年分目录的论文文档集，安装 pdfgrep，逐年运行版本控制痕迹表达式并记录命中地址与上下文，对未命中依次放宽到开放源码、源代码与仓库等表达式，最后对剩余论文人工通读。关键是保留每次收紧或放宽表达式的版本，因为跨行断词与乐器名误命中会显著影响计数。原文报告混合流程总耗时略超 20 小时，可作为人力预算参考，但硬件预算未报告。
复现案例的归档部分，先按固件、电路、外壳模型拆分仓库，在元仓库中以子模块引用固定提交并打标签，检查文件格式是否可用开放工具打开，对固件生成接口文档并补用户手册，再逐个归档子模块，最后归档元仓库并在记录中写明每个子模块的持久标识。以下示意图是该流程的归档视图，初学者应把它当作检查清单。
持久标识符 × 代码托管平台： 代码托管平台负责日常协作、浏览与更新，持久标识符负责在归档平台上给出长期可引用且不随仓库改名而失效的身份；托管平台解决开发期的可见性，持久标识符解决发表后的可引用性，二者搭配的意义是把易变的开发地址转换为稳定的学术引用对象。
下图用示例标识展示手工交叉引用的做法，上方 3 个方框各带一个示例标识，下方界面方框带自己的标识并逐行列出对上方三者的引用，中间断裂线表示自动打包在此处中断。
看图路径： 1. 先找到上方三个带示例标识的 Firmware、CAD、Model 方框；2. 再看下方 Interface 方框内列出的交叉引用标识清单；3. 注意中间连线的断裂标记，理解自动集成缺失后需手工链接
论文图 4。原论文 Figure 4：“Zenodo’s GitHub integration does not capture data stored in git submodules.”。
这张图解释了为何只分享元仓库地址不够。自动集成不会把子模块内容带入归档包，若直接归档元仓库，后来者拿到的可能是空壳引用。正确动作是先冻结每个子模块的版本并独立归档，再在元仓库的归档记录中写死交叉引用，使 4 个标识形成闭环。复刻时先按清单取回 4 个快照，再按标签检出对应提交，才能回到论文描述的状态。
资源可达性必须按本次核验写清。代码与数据集在公共代码托管地址当前可用，状态码为 200，可写当前可用；本论文脚本与数据的归档标识本次未能确认可达，必须写本次未能确认可达；第三方工具中版本检索工具文档、开放电路工具手册与软件引用格式相关页当前可用，老牌归档平台与若干标识本次未能确认可达。复现前应先确认这 3 类状态，避免把未能确认可达的归档当作已公开。
何时值得尝试这种够用型开放？
当你的作品包含软件加硬件加外壳，且预期会被学生或后来者改编时，值得采用本论文的够用型做法。具体动作是立项即拆分仓库，一个仓库只放一类制品；每次投稿前给元仓库打标签并记录提交哈希；在论文中用统一字段给出项目地址而非散放在脚注或正文；投稿后把子模块逐个归档并在元仓库归档中写明交叉引用；最后补一份能让他人在 6 个月后仍看懂的说明，而不仅是接口注释。
复刻 × 操作性知识： 复刻指按原文材料重新搭建乐器的实践过程，操作性知识指只有动手布线、焊接、调试与演奏才能获得的工艺判断；复刻负责提供学习动作，操作性知识负责解释为何只读论文不够，组合意义在于把开放材料视为教学与技能传递的载体，而不仅是证明论文结论正确的附件。
还需补的验证是加统一字段后是否真能提升找回率，以及归档快照是否真能支撑第三方复刻。建议新工作在投稿时记录从论文到仓库的点击路径与检出版本，在课程中记录学生复刻的阻塞点，把缺失率、可构建率与复刻耗时作为下一轮测量的指标。只有补上这些，才能把够用型开放从合理建议变成可测量的社区基础设施。
⚖️ 评分明细
评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。
- 评分规则：type-aware-v1
- 评分模型：muse-spark-1.3-contributor
- 评分请求协议：openai_responses