与ChatGPT合作惹众怒!怕代码被AI窃取,大量开发者删帖抗议,不料竟遭平台封号?...

3868877d8b9a1c1a221b58d1473f0bda.gif

整理 | 郑丽媛

出品 | 程序人生(ID:coder_life)

本周,OpenAI 宣布与知名在线编程问答论坛 Stack Overflow 达成技术合作:

  • ChatGPT 将能使用来自 Stack Overflow 可靠准确、高度技术性的知识和代码——这些数据”由 15 年来为 Stack Overflow 平台做出贡献的数百万开发人员“所提供。

  • 同时,Stack Overflow 也能利用 OpenAI 模型作为其 OverflowAI 开发的一部分,并通过内测最大限度地提高 OpenAI 模型的性能。

在官宣博文中,Stack Overflow 表示:“这将使开发者能利用世界领先的高技术内容知识平台的集体优势和世界上最流行的 LLM 模型进行 AI 开发。”

然而,不同于 Stack Overflow 和 OpenAI 的乐观,众多 Stack Overflow 用户得知此消息后,强烈反对平台与 OpenAI 合作,并火速删除或修改了他们发布的各种帖子和答案,以免被 AI 拿去训练。

结果没想到,Stack Overflow 不仅恢复了被删掉的帖子和答案,还把这部分抗议的用户直接封号禁言了。

ad0668d5b331444231e19253ee3e1c91.jpeg

b88d50235fc6b785d96ae0fa6e4be2fc.png

用户提出抗议+删帖,便被封号禁言

提起 Stack Overflow,相信多数程序员都不陌生。这是一个成立于 2008 年、面向开发者的问答网站,用户可提出并回答任何有关编程的技术问题。在过去 15 年中,Stack Overflow 逐步拥有了一个庞大的开发者社区,成为了许多开发者解决常见编码难题的首要选择,也积累了相当多的优质解答和代码。

自从与 OpenAI 合作的消息公布以来,Stack Overflow 用户社区中便引发了巨大争议,许多人无法接受他们贡献的答案被用来支持和训练 AI 模型,对此表示愤怒和抗议,并试图修改或删除他们在 Stack Overflow 上发表的帖子。

一位用户写道,"我讨厌这样,我要把我的答案一个个删除。"他指出,他不在乎这是否违反了 Stack Overflow“愚蠢的政策”:“你们的政策可以在不事先征求利益相关者意见的情况下随意更改。既然你们不关心用户,那我也不关心你们。”

据悉,这位用户所说的“愚蠢的政策”,是指 Stack Overflow 的服务条款规定:帖子一旦发布,就会成为其他贡献者“集体努力的一部分”,只有在特殊情况下才能删除——也就是说,Stack Overflow 对用户在该平台上提供的所有内容,都拥有不可撤销的所有权。

听起来似乎过于强势?但事实证明,在这方面 Stack Overflow 确实如此强势。

近日,一位名叫 Ben 的 Stack Overflow 用户在 Mastodon 上分享了他发布抗议信息后被禁言的经历:

Stack Overflow 宣布他们将与 OpenAI 合作,于是我想删了我评价最高的答案。

Stack Overflow 不允许你删除已接受答案并获得许多赞的问题,因为这样做会删除社区中的知识。

因此,我把评分最高的答案改成了抗议信息。

不到一个小时,Mods 就把问题改回来了,并把我的账户暂停了 7 天。

06a23f4f7abfedecc85f3f129cd13d82.png

在这个线程下,Ben 继续补充道:“我只是想提醒大家,你们在某些平台上发布的所有信息都可能被用来牟利。例如你在 Discord、Twitter 等平台上发布的信息,迟早都会被收集起来,输入到一个模型中,然后再卖给你。”——Ben 的这个说法虽然不太中听,但很大程度上代表了加入抗议行列的 Stack Overflow 用户的想法。

还有许多用户提出:既然是合作,为什么 ChatGPT 不能分享它提供的答案来源,这样既能注明来源,又能增加答案的可信度。理论上来说,这个提议较为合理,因为 Stack Overflow 虽然拥有用户帖子的所有权,但网站使用的是知识共享 4.0 许可,即要求注明出处。不过目前来看,ChatGPT 未来是否会遵循这一许可还未可知。

32435c45690acb0bdaf5101411d93184.png

对于 AI 的立场,突然转换

事实上,除了反对 Stack Overflow 不经用户同意便将数据提供给 AI 训练的决定外,很多用户还对 Stack Overflow 在生成式 AI 政策上的急转直下尤为愤慨。

还记得 2022 年底 ChatGPT 刚上线不久,Stack Overflow 就反其道而行,发布了封禁通知:禁止在 Stack Overflow 上发布 ChatGPT 生成的文本。当时 Stack Overflow 给出的理由是,ChatGPT 生成的答案正确率太低,而发布由 ChatGPT 生成的答案对网站和查询正确答案的用户来说非常有害,从而会对 Stack Overflow 的质量管理造成冲击。

自此之后,Stack Overflow 也一直坚持这项政策,即禁止使用生成式 AI 编写或改写发布的任何问题或答案,违规者最多封号 30 天,同时鼓励版主在审核帖子时用 AI 检测软件。当时还有不少报道称,ChatGPT 的出现严重降低了 Stack Overflow 的流量。

然而从上周开始,Stack Overflow 突然就改变了对 AI 的说法。其 CEO Prashanth Chandrasekar 在博文中赞扬了生成式 AI 的优点,还说“GenAI 的崛起对 Stack 来说是一个巨大的机遇”。然后很快地,平台管理人员就接到指示,停止删除论坛上 AI 生成的问题和答案。

据了解,Stack Overflow 并非唯一一家为了利益而改变对 AI 立场的公司:Valve 也悄无声息地取消了其在 Steam 上的 AI 禁令,并允许 1000 多款 AI 游戏涌入店面。

如此看来,Stack Overflow 选择改变立场与 OpenAI 合作似乎也是一种顺势而为。只不过,对于许多反对的用户来说,这样突然的立场转换,某种程度上来说也是一种“背叛”。

参考链接:

https://www.tomshardware.com/tech-industry/artificial-intelligence/stack-overflow-bans-users-en-masse-for-rebelling-against-openai-partnership-users-banned-for-deleting-answers-to-prevent-them-being-used-to-train-chatgpt

https://arstechnica.com/information-technology/2024/05/stack-overflow-users-sabotage-their-posts-after-openai-deal/

推荐阅读:

▶突发!阿里游戏核心人员云风离职,自曝原因:“Ant Engine项目被关停”

▶iOS 越狱开发者反被苹果“招安”:不得再碰“越狱”,便转身开源了 10 款工具!

▶火爆外网的「十亿行挑战」,国外大神用C++应战:从67s到0.77s,速度狂飙87倍!

56a6e4d2be29ea6ef389a42d9376270d.png

<think>嗯,用户问的是在C/C++编程时,把多个预处理指令揉在一起会不会被同事“追杀”。首先,我需要理解“追杀”在这里是夸张的说法,指的是同事的不满或者抱怨。接下来,要分析预处理指令合并可能带来的问题。 预处理指令比如#include、#define、#ifdef等,通常每个都单独一行。如果把它们揉在一起,可能会影响代码的可读性。比如,多个#define写在一行,或者夹杂在代码中间,别人阅读时不容易快速找到需要的部分,增加理解难度。 然后,维护性也是一个问题。比如条件编译如果都挤在一起,修改的时候容易出错,尤其是在处理嵌套的#ifdef时,可能导致逻辑错误,调试困难。此外,预处理指令的合并可能违反公司的编码规范,很多公司对预处理的使用有明确的规定,比如每个指令单独一行,甚至要求顺序和分组,比如先包含系统头文件再包含本地头文件。 再考虑团队协作方面,统一的代码风格很重要。如果有人不遵守规范,会增加团队协作的摩擦,尤其是在代码审查时,这样的问题可能被指出甚至要求修改,长期下去可能影响同事关系。 不过,用户的问题可能也有玩笑的成分,可能实际是想了解合并预处理指令的后果有多严重。需要举一些例子,比如把多个#include写在一起,或者宏定义和条件编译混合,导致代码混乱。 还要考虑是否有特殊情况允许合并,比如某些宏必须在一行内完成,但这种情况较少。大部分情况下,保持指令的清晰和独立是更好的做法。 最后总结,合并预处理指令虽然可能不会导致严重的后果,但确实会影响代码质量和团队协作,所以最好遵循规范,保持代码整洁。</think>在C/C++编程中,如果将多个预处理指令(如 `#include`、`#define`、`#ifdef` 等)强行“揉”在一起(例如挤在一行或混乱排列),是否会引起同事的“追杀”取决于具体场景和团队规范,但大概率会引发以下问题: --- ### **1. 代码可读性问题** 预处理指令通常需要单独成行,**明确表达意图**。例如: ```cpp // 规范的写法 #include <vector> #include "my_header.h" #define MAX_SIZE 100 #ifdef DEBUG // ... #endif // 混乱的写法(可能被追杀) #include <vector> #include "my_header.h" #define MAX_SIZE 100 #ifdef DEBUG /*...*/ #endif ``` 混乱的写法会让代码难以阅读,尤其是当条件编译(`#ifdef`)、宏定义(`#define`)和头文件包含(`#include`)混杂时,同事可能需要花费额外时间理解逻辑。 --- ### **2. 维护性风险** - **宏定义混乱**:如果将多个宏挤在一起,可能导致宏作用域不清晰,甚至引发意外的替换行为。 - **条件编译陷阱**:例如 `#ifdef` 和 `#endif` 如果未对齐或跨行混乱,可能引发逻辑错误,且难以调试。 - **头文件依赖问题**:如果头文件包含顺序混乱(例如系统头文件和自定义头文件混杂),可能违反编码规范或引发隐式依赖问题。 --- ### **3. 违反编码规范** 大多数公司对预处理指令有严格规范,例如: - **头文件分组**:系统头文件在前,本地头文件在后。 - **条件编译注释**:要求对 `#ifdef` 添加注释说明意图(如 `#ifdef FEATURE_A // 启用特性A`)。 - **宏命名和格式**:例如全大写、下划线分隔等。 如果随意揉合预处理指令,可能直接违反团队约定,导致代码审查不通过。 --- ### **4. 极端案例:可能真会被“追杀”** - **导致编译错误**:例如宏定义未正确换行时,可能直接破坏代码逻辑。 - **引发团队矛盾**:若代码因预处理指令混乱导致项目构建失败或产生隐蔽Bug,可能会严重拖累团队进度。 --- ### **结论** - **轻度揉合**(例如合理换行但未严格分组):可能被同事吐槽或要求修改。 - **重度揉合**(例如挤在一行、破坏逻辑):大概率引发众怒,甚至被要求“重构代码谢罪”。 --- ### **建议** 1. **遵循团队规范**:预处理指令的格式通常是编码规范的“高压线”,务必遵守。 2. **保持简洁明确**:每行一个预处理指令,合理分组(如头文件、宏、条件编译分开)。 3. **添加必要注释**:尤其是条件编译和复杂宏,帮助他人理解意图。 总之,预处理指令看似简单,实则是代码可维护性的重要一环。为了同事关系和项目质量,请谨慎对待它们! 😉
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值