Google vs. FFmpeg¶

那什么..¶

事儿就是这么个事儿:Google vs. FFmpeg — 大厂用AI自动发现 bug 摧开源社区及时修好...

大家在愤怒的讨论开源软件中的bug 修复责任归属, 其实,

问题焦点不在这儿... 而是拥有大模型的大厂们, 已经开始真正的自动化逼迫社区来为自己义务劳动了... 以往好歹有个活人工程师, 老老实实发个邮件创建个 Iusse 来阐述自己发现 bug 的过程以及建议;

这种行为在如何成为黑客, 以及更加著名的如何智慧的提问中都是提倡的.. 不是简单的促进了代码质量, 也给社区提供了情绪价值;

现在 LLMs 们将过往所有工程师的知识片段提炼焠取为一个冷静的毫无情绪的高效自动机, 用标准格式海量反馈 bug 给社区, 并单方面规定修订死线来逼迫开源社区成员们更加努力的劳动... 这种决策的脑洞比 1984 还要三体哪..

其实, 问题的解决很简单: 开源软件嘛, 任何人都可以加入开始贡献, 也不应该限制/要求/控制/..任何人的贡献节奏和效率..

所以, Google 们如果对于上游开源软件/系统的代码质量高度关注, 并有资源有手段可以提高质量,

那就躬身入局嘛:

0: 用 grmini 定期扫描所有自己系统中使用的所有开源项目的代码
1: 公开发现的 bug
2: 配套报酬:
- 2.1: 谁用LLMs 完成修复, 成功合并, 根据 bug 的复杂和严重度, 自动奖励 gemini 订阅月数, 从一个月到42年不等;
- 2.2 谁是自己真人完成, 成功合并, 根据 bug 的复杂和严重度, 提供奖励选择, 现金或是 gemini 订阅月数量;
- 2.3 如果是 google 内部工程师完成修复, 成功合并, 根据 bug 的复杂和严重度, 提供奖励选择, 现金或是 gemini 订阅月数, 或是带薪假期, 从一周到42年不等等..

其它有大模型的大厂, 也都可以这么确立赏格; 这时, 就可以非常明确的看到各个大模型受欢迎程度了...

毕竟不可能有用 Claude 解决 bug 后去讨 gemini 订阅月数的吧...

|> 251111 日糟:
¼(每天吐糟不应超过4次)

        _~~|-~_
    () /  o ◶  \ \/
      '_   ▽   _'
      ( '--.--' /

...act by ferris-actor v0.2.4 (built on 23.0303.201916)

旧[utteranc.es]注释: