Go 发布 AI 机器人 Oscar，解决开源项目的维护痛点！-技术圈

大家好，我是煎鱼。

前段时间我给大家介绍了 Go 核心团队负责人 rsc 开发的新 AI 轮子 @gabyhelp，目的是对各种 GitHub 日常的 Go 社区管理事项进行自动化管理。

他的 GitHub 账户长这个样子：

当我以为这个事就这样了。没想到 rsc 又搞了一发更大的，给出了更高的产品愿景。

Oscar：开源贡献者代理架构

实际上 rsc 表示 Gabyhelp 只是为开源维护的一个实验原型。

本次新的升级产品叫：Oscar。Oscar 是一个旨在通过为开源软件维护、创建、自动帮助，或 “代理” 来改进开源软件开发的项目。

rsc 相信有很多机会可以减少大大小小开源项目的维护工作量。可以将 Oscar 用在整个开源项目的生态中。

具体目标

简单来讲，Oscar 希望能够解决各大开源项目中的维护者的工作量，目的是让维护者的工作能够自动化。

使更多人成为高效的维护人员。

至少包含以下三个目标：

减少项目维护者解决问题的工作量
减少项目维护者处理变更列表 (CL) 或拉取请求 (PR) 的工作量
减少项目维护者处理社区问题的繁杂工作量

会实现的特性

开源项目的维护者的辛苦和重复工作并不是 Go 社区的项目所独有的。

因此目标是：建立一个任何软件项目都可以重复使用和扩展的架构。大家也可以根据自己项目的需要随时建立自己的代理。这就是 Oscar。

已经确定实现的特性有如下三个：

在贡献者互动期间索引和呈现相关项目背景。
使用自然语言控制确定性工具。
分析 issues 和 CL/PR，帮助在提交期间或提交后实时改进它们，并适当地标记和路由它们。

具体案例

向贡献者和维护者提示上下文索引：

1、面向贡献者：

在 Go 项目中，有社区贡献者在 issues 中反馈了新的问题和提案。

Oscar 的前身 @gabyhelp，直接反手甩给他一个关联 issues：

“贡献者” 表示：“好机器人 :)。根据这个问题的讨论，我明白可能无法按照这里建议的方式去做。”

@ianlancetaylor 出现后就直接移除这个 issues 的提案了。从这个例子上来讲，大大地提高了社区项目维护者的工作效率，贡献者直接自通了。

2、面向维护者：

当一个项目大了后，不可能有所有人可能记得住任何 issues 和历史。顶多就是记得探讨过，可能要花很多的时间去寻找。

更不用说有些是涉及人员离职等信息丢失的场景。这种更加的麻烦。

在 go/issues/67938 和 go/issues/67938 中，rsc 提了一些相关的问题（缺陷）。结果被 @gabyhelp 发现之前早已有类似的问题和答复。

如下图：

最终 rsc 对提出的问题缺陷有了更多的认知和思路。

3、与问题提出者快速交流：

由于是 AI 机器人，所以可以 24 小时全年无休与此刻提出问题的人做很多事情。

例如：进行添加详细信息以澄清建议，关闭报告作为重复，根据过去的报告提高错误优先级，或确定修复方案。

AI 机器人可以做到时效性在几分钟内就回答。而平时靠人的话，可能需要数天、数月。那么久后，可能问题提出者也不感兴趣了。

分析 issues 和 CL/PR

发布相关的 issues 是一种有限的分析形式，但 Oscar 计划添加其他类型的语义分析。例如：确定某个问题主要与性能有关，并应添加 “性能” 标签。

简单来讲，就是根据语义做一些事情，自动打标签，分发等事项。还有之前提到的，为 CL/PR 的不标准，进行链接补全等。

一些争议

有社区同学反馈类似的工具在 AI 大行其道之前几年就已经存在了。

他认为根本问题在于 GitHub 的搜索功能并不完善、易用性也有待改善。综合导致用户没法很好的搜索到问题。

其最担心的是，除了问题中的老机器人（指的是 gopherbot^[1] 外，可能很快还需要与新的 AI 机器人 Oscar 碰撞，并会在此过程中产生大量不相关的评论。

总结

本次 Go 核心团队对于 Gabyhelp 做了新的产品升级，新的产品名字为：Oscar。项目地址：golang/oscar^[2]，愿景是解决各大开源项目的繁杂工作和实施自动化。

这作为大佬们的创新项目，希望也能在这次浪潮中创出一片新的空间。也确实解决了一些维护的痛点。

Oscar 目前还在实验阶段，还无法确定最终会做成什么样，走到哪里去。大家可以持续关注一下！

Go 发布 AI 机器人 Oscar，解决开源项目的维护痛点！