Toward Linking Declined Proposals and Source Code: An Exploratory Study on the Go Repository
本研究针对被忽视的已拒绝提案，提出了一种基于大语言模型的溯源链接方法，在 Go 仓库中成功建立了已拒绝提案与源代码之间的关联，并分析了影响链接生成的因素及失败原因。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
这篇论文讲述了一个关于**“如何从被拒绝的提议中找回价值”的故事。为了让你更容易理解，我们可以把软件开发比作“建造一座巨大的城市”，而这篇论文就是关于如何整理这座城市的“废弃设计图”**。
1. 背景：被扔进垃圾桶的“好点子”
想象一下，在一个叫 Go 的开源软件项目（就像一座正在建设中的超级城市）里，每天都有很多工程师（贡献者）提交新的**“设计提案”**（Proposals）。
- 被采纳的提案：就像被市长（维护者）批准的图纸，最终真的变成了城市里的一座新大楼或一条新街道。这些图纸和最终建成的房子之间，有清晰的连线。
- 被拒绝的提案：就像那些被市长说“不行，这个想法不好”或者“现在时机不对”的图纸。它们被扔进了**“废弃箱”**。
问题出在哪里？
以前的研究只关心那些**“被批准并建成的大楼”。但是，那些“被拒绝的图纸”**其实非常有价值！
- 它们记录了为什么某些路不能修（设计理由）。
- 它们记录了大家争论了什么（社区共识）。
- 甚至，有些被拒绝的图纸，过段时间会被修改后重新提交，最终建成。
痛点：这些“废弃图纸”和现在的城市（源代码）之间没有连线。如果你现在站在城市里，想查“为什么这里不能修路”，你根本找不到当年的讨论记录。它们就像孤岛。
2. 核心任务：给“废弃图纸”和“现实城市”建立连线
这篇论文的目标就是：自动地把那些“被拒绝的提案”和它们当时想修改的“具体代码位置”（比如某个文件夹、某个文件、或者某个函数）连起来。
这就好比给每一张废弃的图纸，贴上标签，告诉后人：“这张图虽然没建成，但它当时是想修改A 区的B 栋楼里的C 房间。”
3. 解决方案：一位聪明的"AI 侦探”
作者设计了一个由**大语言模型（LLM）**驱动的“侦探流水线”，分三步走：
第一步：判断“侦探”该找多细的线索？（粒度决策）
有些提案很宏大，比如“我们要新建一个区”（对应目录级）；有些很具体，比如“我们要修一下 B 栋楼的窗户”（对应文件级）；有些更细，比如“我们要换掉 C 房间里的灯泡”（对应函数级）。
- AI 的作用：先读一遍提案，判断这个想法到底是要改“整个区”、“一栋楼”还是“一个房间”。这决定了侦探接下来该找多细的线索。
第二步：在城市的地图上定位（定位）
一旦确定了范围，AI 就开始在代码库（城市地图）里找对应的地方。
- 传统方法：像用搜索引擎搜关键词，容易搜错（比如搜“苹果”可能搜出水果，而不是科技公司）。
- AI 方法：像一位经验丰富的老侦探，它能理解上下文。它不看死板的关键词，而是看提案里说的逻辑，结合城市的结构，精准定位到“哦，原来他们想改的是这个文件里的这个函数”。
第三步：确认连线（决策）
最后，AI 会做一个判断题：“这个找到的代码位置，真的就是提案里说的那个吗？”
- 如果是，就建立连线。
- 如果不是，就放弃。
4. 实验结果：侦探干得怎么样？
作者用 Go 语言仓库里的真实数据测试了这个“侦探”：
- 判断范围：AI 判断“该找多细的线索”（是改目录、文件还是函数）的准确率达到了 83.6%。这就像侦探 8 成 3 的概率能猜对你要找的是“房间”还是“整栋楼”。
- 建立连线：在判断对了范围的前提下，它成功找到正确代码的准确率（精确率）是 64.3%。
- 对比：这个表现比传统的“关键词搜索”方法要好得多。
5. 为什么有时候会失败？（侦探的困惑）
作者也分析了为什么侦探有时会抓错人。主要有两个原因：
线索太模糊（“只说修窗户，没说哪扇窗”）：
- 很多被拒绝的提案只说了“我们要实现这个功能”，但没说“具体怎么实现”或者“改哪个文件”。
- 比喻：就像有人给侦探一张纸条说“把那个红色的东西修好”，但仓库里有成千上万个红色的东西，侦探根本不知道修哪个。
噪音太大（“废话太多，掩盖了重点”）：
- 讨论过程太长，充满了无关的争论、客套话，真正重要的技术细节被埋没在几千字的对话里。
- 比喻：就像侦探在听一个啰嗦的证人说话，证人讲了半小时的家常，最后才提了一句“窗户在二楼”，侦探很容易在听的时候走神，忘了重点。
有趣的是：研究发现，讨论的长度并不是导致失败的主要原因。哪怕讨论很长，只要重点清晰，侦探也能干得好；哪怕讨论很短，如果没说清楚“改哪里”，侦探也会抓瞎。
6. 总结与启示
这篇论文告诉我们什么？
- 不要浪费“失败”的价值：被拒绝的提议里藏着宝贵的“设计智慧”，我们应该把它们和代码联系起来，方便后人查阅。
- AI 很有用，但需要好素材：大语言模型（AI）能很好地理解复杂的软件讨论，自动建立这种联系。
- 未来的方向：为了让 AI 更聪明，我们需要：
- 如果提案里缺信息，试着去补充相关的背景资料。
- 如果讨论太啰嗦，试着先帮 AI 总结一下重点。
一句话总结：
这就好比给一座城市的**“废弃设计图”建立了一个智能索引系统**，让未来的建筑师能轻松查到：“哦，原来 10 年前大家曾在这里争论过，虽然没建成，但那个想法其实是想修改这个角落。”这不仅节省了时间，还保留了宝贵的历史经验。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。