[Paper] 走向将被拒提案与源代码关联：对 Go 仓库的探索性研究

Source: arXiv - 2602.09467v1

概述

本文探讨了开源开发中一个长期被忽视的领域：被拒绝的提案——在 GitHub 上讨论过但最终被否决的 issue。通过自动将这些被丢弃的讨论链接到 Go 语言源码的相关部分，作者揭示了隐藏的设计理由和决策标准，帮助开发者理解为何某些想法会被否决。

关键贡献

• 首次系统性尝试 在大型开源软件项目中创建 已关闭（declined）GitHub issue 与源代码之间的可追溯链接。
• 基于大语言模型的链接流水线，能够选择适当的代码粒度（文件、函数或模块）并生成候选链接。
• 实证评估 在官方 Go 仓库上进行，粒度选择准确率达到 83.6 %，生成链接的平均精确率为 64.3 %。
• 失败分析，识别链接失败的常见原因（例如，讨论线程模糊或冗余）。
• 开放数据集与工具（issue‑code 对、流水线脚本），供其他研究者和实践者复用。

方法论

1. 数据收集 – 作者从 Go 仓库中收集了所有被拒绝的提案（GitHub Issues），重点关注功能或语言变更请求。
2. 预处理 – 对 Issue 的标题、正文和评论线程进行清洗，并划分为简洁的“讨论摘要”。
3. 基于 LLM 的粒度预测 – 通过提示大型语言模型（LLM），根据 Issue 中的文本线索判断相关代码位于文件、包还是函数层级。
4. 候选检索 – 利用预测的粒度，流水线在 Go 代码库中进行查询（通过词法搜索、AST 分析和语义嵌入），检索最可能的代码元素。
5. 排序与过滤 – 对检索到的候选项使用 LLM 重新打分，考虑上下文相似度以及讨论中出现的显式引用（例如文件名）。
6. 人工验证 – 作者手动检查了一部分链接，以计算精确率、召回率和粒度选择准确率。

整个工作流完全自动化，只需提供 Issue 文本和仓库的源码树即可。

结果与发现

数字含义

• LLM 能够可靠地推断出在代码中的位置，即被拒绝的提案会产生影响，即使该问题从未转化为补丁。
• 大约 64 % 的精度表明，约三分之二的建议链接确实相关，这为一个前所未有的任务提供了有希望的基准。
• 失败案例通常源于模糊的讨论（例如，“我们不需要此功能”）或冗余的评论线程，这些内容提供的具体技术细节很少。

实际意义

• 设计动机挖掘 – 团队可以自动呈现被拒绝特性的“原因”，帮助新贡献者了解项目标准，避免重复的提案。
• 入职与文档 – 将被拒绝的议题链接到代码后，可转化为可搜索的文档，让开发者快速查看与特定模块或函数相关的历史决策。
• 工具集成 – 该流水线可以封装为 GitHub Action 或 IDE 插件，当维护者将议题标记为 declined（已拒绝）时，建议相关的代码位置以供后续参考。
• 风险与安全审计 – 被拒绝的提案有时会标记安全隐患；自动将其链接到受影响的代码可以帮助审计员追踪潜在漏洞。
• 跨项目知识转移 – 其他语言或框架也可以采用相同方法，从各自的议题跟踪系统中构建“决策知识库”。

限制与未来工作

• Domain Specificity – 本研究仅聚焦于 Go 仓库；对于讨论结构较为松散或使用不同编程范式的项目，结果可能有所不同。
• LLM Dependency – 准确性取决于底层 LLM 对技术语言的理解能力；更新或更专业的模型可能提升性能。
• Granularity Scope – 仅考虑了三种粒度层级；更细粒度的链接（例如具体行或 AST 节点）不在本研究范围内。
• Manual Validation Overhead – 将评估扩展到更大语料库需要半自动化或众包的验证方法。
• Future Directions – 将流水线扩展到 accepted 提案以实现端到端可追溯性、加入代码变更历史，并探索多模态输入（如设计图）是有前景的后续步骤。

Source: …

作者

• Sota Nakashima
• Masanari Kondo
• Mahmoud Alfadel
• Aly Ahmad
• Toshihiro Nakae
• Hidenori Matsuzaki

论文信息

• arXiv ID: 2602.09467v1
• 分类: cs.SE
• 发表时间: 2026年2月10日
• PDF: 下载 PDF