我最近在一个开源项目的讨论区里看到一段争论有人用生成式 AI 写了一个功能完整的 Pull Request提交之后被维护者直接关闭理由是“代码不像这个项目会有的样子”。随后评论区分成两派一派觉得维护者思想守旧另一派认为 AI 生成的代码根本没有经过真正理解不应该混进社区项目。这其实不是我第一次看到类似场面。如果你也在做编程相关的爱好项目或者经常混迹 GitHub、开源社区、技术论坛应该能明显感受到近一两年关于 LLM 的态度正在成为社区里最容易被点燃的话题之一。“Born Against, or why hobby programming communities are aggressively against LLM”这个标题翻译过来更像是“天生反着来或者为什么爱好者编程社区如此强烈地反对 LLM”。它绕开了企业级大规模落地那种宏大的叙事直接把目光聚焦到一个更具体、也更拧巴的现象上在很多人用大模型辅助写代码已经成为习惯的今天为什么仍然有一批开发者、维护者、爱好项目组织者对 LLM 的参与保持警惕甚至直接拒绝。这篇文章我想站在一个长期维护过开源项目、也用过不少 AI 辅助工具的技术博主角度把这股“反对声音”拆开来讲。它到底在反对什么有哪些反对是合理的有哪些其实是对 LLM 的误伤更关键的是如果你自己正在维护社区项目或者想在社区项目里用 LLM 做贡献到底应该怎么做才能避免成为那个被关闭 PR 的人。我先把核心判断放在前面爱好者编程社区反对的从来不是“大模型这个技术”而是“LLM 参与社区协作时暴露出来的三种失控——代码来源失控、责任归属失控、社区互动失控”。理解了这三个失控你才能理解很多看似激烈的反对言论背后其实是一套很朴素的社区自我保护逻辑。1. 先理清楚社区抵制的到底是大模型还是大模型带来的协作问题1.1 多数人并不讨厌“自动补全”讨厌的是“突然丢来一大坨陌生代码”我在很多相关讨论里发现一个奇怪的现象同一个开发者可能自己日常用 IDE 的 AI 补全用得很顺手但只要一看到有人往开源项目里提一个“AI 生成的完整 PR”立刻就会表现出明显的反感。这说明什么说明很多人反对的并不是技术本身而是技术在不同边界下引发的不同后果。本地代码补全和提交 PR 之间的本质区别在于“所有权和责任”。你用自己的编辑器配合 AI 写一段你自己看得懂、改得动的代码责任在你代码逻辑你负责出了问题你知道去哪里查。但如果你把一个 AI 自动生成的 800 行新功能直接塞给一个陌生人维护的项目维护者面临的第一个问题是代码风格是否匹配项目第二个问题是这些代码里有没有隐藏的设计意图第三个问题是如果以后出了 bug提交者会不会回应这三点在传统社区协作流程里都有对应的保障机制。提交者写代码维护者审代码有问题在评论里来回讨论直到双方都认可代码合并。AI 生成的 PR 往往绕过了这种互动。它看起来功能完整但缺少设计取舍的痕迹缺少对项目历史约定的理解也常常缺少后续维护的承诺。所以维护者产生的第一反应往往不是“这代码好不好”而是“这人不按协作规则来”。1.2 “反对 LLM”的背后是对社区劳动伦理的维护这里有个词可能听起来有点大但确实是核心劳动伦理。爱好者编程社区并不是靠代码本身存活的它靠的是持续的人与人之间的沟通、解释、互相帮助。很多人维护开源项目不拿钱唯一的回报就是社区感、成就感以及技术交流带来的成长。当越来越多的人开始用 LLM 一键生成长文、生成代码、生成 issue 回复甚至生成“看起来好像在参与”的评论时社区里那种真实的人类互动就会变得稀薄。一篇完全由 AI 生成的 issue虽然格式规范措辞礼貌但它没有真实的困惑也没有真实的背景信息。维护者回复之后提问者甚至可能根本不理解答案。这种体验对任何当过维护者的人来说都非常消耗心力。所以你会看到不少社区开始提高门槛要求 issue 必须填写项目名、版本、日志、可复现步骤甚至直接关闭没有按要求填写的提问。这不是技术倒退恰恰是社区对 LLM 化表达泛滥的一种防御机制把“看起来像人写的”和“真的是人写的”区分开。1.3 还有一个容易被忽略的点非法与灰色内容进入社区的风险这个话题可能比较敏感但值得提一提。很多爱好社区会提供免费 API 代理、模型下载、工具分享这类资源一旦对所有人开放就很容易被滥用。有些人用 LLM 批量生成内容再通过社区资源去跑各种不可描述的任务这种场景一旦出现对社区就是毁灭性打击。不只是服务器承受不住还可能导致项目被服务商停用、域名被封、维护者被追究责任。所以很多维护者对“AI 生成内容”保持警惕某种程度上也是在保护自己的基础设施和生产环境。他们不是在哲学层面反对 AI而是见过太多“用 LLM 生成的格式完美但内容失格”的垃圾内容导致他们下意识地把“LLM 参与”等同于“风险输入”。2. 为什么偏偏是“爱好者编程社区”而不是企业研发团队反应最激烈2.1 企业看重效率和产出社区看重信任和长期相处企业研发团队引入 LLM 的理由很直接它能降低重复劳动成本能快速生成初稿能在代码审查时提供辅助。企业对代码的容错来自流程——有测试用例、有 CI、有产品经理兜底、有文档审阅。即使 AI 生成的代码质量一般后续还有一整套质量门禁等着它。爱好者编程社区不一样。很多中大型开源项目的核心维护者其实只有三五个人甚至只有一个人。CI 可能只是最基础的编译检查很多项目没有完善的自动化测试。代码合入之后真正的测试是“用户拿去用”。在这种环境下一段“看起来能用但不知道能不能维护”的代码风险远比收益大。这也是为什么很多社区项目宁愿自己写工具脚本也不愿意引入一个看起来很强大的 AI 代码生成服务。他们要的不是“生成速度快”而是“出了问题能找到人负责有人能解释设计意图”。在资源有限的社区里维护成本远比开发重要。这是我见过很多社区决策里最共性的一条逻辑。2.2 爱好项目里维护者是“时间最不值钱也最值钱”的人说时间最不值钱是因为大部分维护者不拿报酬说时间最值钱是因为他们每天能贡献给项目的时间上限就那么一两个小时。在这点可怜时间里他们要读 issue、回复邮件、合并代码、发布版本还要抽空看点技术新闻。如果你用 LLM 生成一个格式正确、语法没问题、但是实际上没有理解项目约束的 PR 送过来维护者可能要先花半小时理解你的意图再花 20 分钟指出问题然后等一周等不到你回复最后还得自己动手改或者直接关掉。我见过很多开源维护者的疲惫不是因为没人提代码而是因为提代码的人不想参与后续讨论。AI 强化了这种“甩代码就走”的行为模式。一旦形成风气社区就会变得像无人维护的垃圾场。这就是为什么看起来“高效率”的 AI 贡献在爱好社区里会被如此激烈地对抗。2.3 很多社区是在和“自动化垃圾信息”斗争多年后才变得敏感的如果你管理过有公开表单、公开邮箱或者公共聊天频道的小项目你就知道垃圾信息一直是个很头疼的问题。从爬虫抓邮箱发广告到用脚本批量注册账号再到现在的 AI 生成营销文案形式一直在变内核始终是“不想和你交朋友只想利用你的资源”。LLM 出现之前垃圾信息至少有明显的格式特征一眼能认出来。LLM 出现之后垃圾信息在表面格式上和真人写作几乎无法区分。很多维护者被迫发展出一套“嗅觉”看到措辞精美、结构完整但明显没有细节内容的文本马上会把它当作垃圾信息处理。这种习惯扩散到代码里就是看到“看起来完整但缺少上下文痕迹”的提交直接产生“这是 AI 生成的”的直觉然后启动防御机制。所以不是说爱好者们固执而是他们长期暴露在信息污染的环境里不得不变得敏感。3. LLM 参与社区时的三种实际摩擦每一个都足够让维护者头疼3.1 摩擦一生成代码无法回答“为什么是这个方案”我在这几年的开源协作里最深的感受是代码 review 的本质不是审查语法而是审查决策过程。为什么用这个库而不是另一个为什么给这个函数加缓存为什么这个边界条件只处理了 A 情况传统提交者在提交代码时通常能回答这些问题因为代码是他们自己思考的结果。即便实现里有问题review 讨论也是一个互相学习和修正的过程。但 LLM 生成的代码提交者往往只知其然而不知其所以然。审查者提出“为什么这里用并发但没有任何锁机制”时提交者可能完全答不上来因为他没写过这段代码他只是粘贴过这段代码。这种体验对 review 者来说非常糟糕。一次两次还好如果大量 AI 提交都是这种状态维护者会变成一个免费的代码检查机器人还是单向输出的那种。没有人愿意做这种工作。3.2 摩擦二版权和许可问题的灰色地带LLM 训练数据里包含大量开源项目代码这已经是公开事实。很多公司和个人对“AI 生成代码是否涉嫌侵权”的讨论在法律上还没有统一结论。但在社区层面维护者往往采取更保守的态度如果你的 PR 里的代码来源不明或者你无法证明你有权按项目许可证分发这些代码我就不敢合入。这不是小心眼这是现实的法律风险。项目引入一段背后有版权争议的代码可能让整个仓库陷入麻烦。所以有些项目会在 CONTRIBUTING 文档里明确要求“提交者必须保证代码是原创或者有权以当前许可证发布。” LLM 生成的代码在这一点上天然处于灰色地带维护者为了自保最稳妥的做法就是先冷处理。我一般情况下不建议把这种风险说成“绝对不行”因为实际上有些项目已经开始接受 AI 生成代码并要求提交者明确标注。但这个趋势在各社区里并不一致所以最好先看项目的贡献文档再决定用不用 AI。3.3 摩擦三AI 批量生成的内容污染了讨论空间现在很多社区已经在处理一个非常现实的问题QQ群、Discord、Telegram 频道里开始出现 AI 自动回复讨论区开始出现格式完美但内容空洞的“知识帖”GitHub issue 里开始出现用翻译模型生成的歪曲原意的提问。这些内容单看每一条都不算恶意。但累积起来它们会稀释真实讨论的浓度。当你想找一篇有人踩过坑的文章翻了几页全是泛泛而谈的 AI 总结当你收到一个 issue 回复发现对方答非所问只是因为 LLM 没有真正理解你的环境上下文。这种体验会极大降低社区参与感。对比一下人类贡献者写出的粗糙但真实的笔记和 AI 生成的漂亮但空洞的教程长期来看前者对社区的价值反而更高。因为它藏着真实的问题环境、真实的报错日志、真实的解决路径。这些东西恰恰是 LLM 最难生成的。4. 哪些情况下“抵制 LLM”是合理的哪些情况下其实是误伤4.1 合理抵制一不接受“未经消化的代码贡献”这是最正当的抵制理由。社区不是让你上传练习作品的地方。即使你用 LLM 写了一百行代码但自己从头到尾没有理解那它就是一段需要别人二次消化的债务。维护者要求提交者能解释每一段自己提交的代码这不是苛求这是最基本的要求。如果你想让 LLM 快速生成初稿完全可以。但提交前请像检查自己写的代码一样逐行审查、修改、跑测试直到你能自信地说“这是我的代码”。到这一步LLM 只是辅助工具没人会因为它抓着你吵。4.2 合理抵制二不接受用 LLM 生成“看起来像参与”的评论和 issue我见过一些人用 AI 生成大量 issue 去“帮助项目完善需求”结果是每个 issue 都洋洋洒洒上千字但根本没有针对项目的实际场景。这种内容让维护者又气又笑。气的是一次要处理这么多无关事项笑的是提交者根本没意识到这种“帮助”正在消耗维护者原本就不多的精力。所以很多社区开始限制 issue 的最小信息要求比如必须包含复现步骤、日志、系统环境。如果你的 issue 无法提供这些细节哪怕措辞再完美维护者也会先标记为待补充甚至直接关闭。这个规则背后跟 LLM 关系不大它只是想让提交者必须真实地接触过问题环境。4.3 误伤一把“使用 AI 写代码”直接等同于“劣质贡献”这是我一定要纠正的偏见。并不是所有 AI 生成代码都是垃圾。我自己用 LLM 写脚本、写小工具、写一次性分析代码的频率就很高其中相当一部分质量甚至可以超过我手写。关键在于使用方式。一个经历思考、审查、修改、测试的 AI 辅助开发者与一个把问题抛给 AI 然后盲目提交的开发者虽然都用到了 LLM但在社区眼里的可信度天差地别。如果你只会看“是不是 AI 生成”来决定是否接受其实和只会看“是不是用某个编辑器”来评价代码一样都是刻板印象。4.4 误伤二把所有“生成式辅助”都当敌人我以前见过一个社区争论有人提议在文档翻译里用 LLM 做初步翻译然后人工校对。结果被一些人强烈反对认为这是在“给 AI 铺路”。这其实是误伤。LLM 在文档规范化、接口注释补全、日志分析这些低风险任务里效果很不错而且能大幅降低人力成本。社区真正要限制的应该是高风险、低透明度的使用场景而不是一刀切。我之前看过一个开源项目的做法他们为 LLM 使用立了几个可执行标准——生成内容必须人工确认、改动必须增量提交、禁止用 LLM 自动生成 issue 或评论、禁止把 LLM 生成的代码以“纯原创”身份提交。这套规则既没有拒绝工具又守住了协作底线我觉得是值得借鉴的样本。5. 想在爱好社区里合理使用 LLM我建议按这套顺序来5.1 进入社区前先找到项目的“劳动规则”第一步是在提交任何东西之前先读一遍项目的 README、CONTRIBUTING、CODE_OF_CONDUCT。这些文档里往往藏着维护者对“协作方式”的态度。如果里面明确写了“不接受 AI 生成代码”那你最好尊重这条规则。如果没有写我建议你不要默认它有边界而是先在 issue 里或者社区频道里询问维护者看他们对 LLM 辅助贡献的接受度。不要怕问。维护者宁愿你多问一句也不愿你花三天生成一个完全不符合项目要求的 PR然后又被秒拒。这种挫败感是双向的。5.2 先做小任务建立可信度再做大改动很多 AI 使用者刚进入项目时就想去解决最大的 issue改最核心的模块。这是一个新手很容易踩的坑。我一般会建议先找一个简单的文档错误、一个明确的 bug 或者一个独立的测试用例去修。目的是先让维护者认识你知道你有基本的代码能力和沟通能力。当你积累了两三次高质量、可合入的提交记录后再尝试更复杂的任务这时候即使你用了 LLM维护者也不会第一时间怀疑你不负责任。因为他已经基于过去几轮互动建立了对你这个人的信任。这种信任不是靠代码生成的而是靠真实协作积累的。5.3 提交时明确标注 AI 辅助并主动说明修改范围我知道有些开发者担心标注“AI 辅助”会被一票否决所以选择隐瞒。但从我见过的所有案例来看隐瞒后被发现后果远比一开始说明严重得多。维护者最不能接受的不是 AI而是欺骗。如果你确实用 LLM 写了初稿提交时一句话就能解决问题“这份实现用了 AI 生成初稿但我逐行审阅过修改了以下几处缓存策略、异常处理、变量命名。测试已跑过本地运行结果附在 PR 描述里。” 这种坦诚反而会让维护者觉得你靠谱。因为你在主动交付上下文而不是把审查责任全部丢给对方。5.4 不要用 LLM 批量生成内容尤其不要碰 issue 和评论这条我觉得不需要解释太多。批量生成 issue 是对维护者时间的直接抢劫批量生成评论则会让你在社区里的所有发言变得不可信。一旦你的账号被打上“AI 灌水”的标签下一个真人提问也会被放进垃圾箱。失去信誉之后你想恢复之前的贡献都会变成减分项。在技术社区里发言质量比发言数量重要得多。如果你没有想清楚一个问题不如先不发如果你真的想回应就用自己的话哪怕逻辑不够严谨只要真实维护者会愿意和你一起捋清楚。5.5 把 LLM 当成“理解代码的助手”而不是“写代码的替身”这里提供一个我个人在用的话术。我会让 LLM 帮我解释一个陌生模块的结构帮我列出某个函数的调用链或者帮我生成测试数据的示例代码。但涉及核心逻辑、公共接口、数据格式的设计我一定会自己写或者至少自己重写一遍。原因很简单核心逻辑一旦写错你要花的时间远远超过手写的时间。你自己写的代码出错你知道从哪里查AI 生成的代码出错你可能连错误在哪一层都不知道。如果只是一个临时脚本跑完就扔用 AI 没问题。但如果是贡献给社区长期维护的代码建议保守一点。6. 网络热词与技术趋势里LLM 在编程领域的真实定位是什么6.1 LLM 不等于“取代编程”更准确的说法是“可交互的知识压缩库”最近网上关于 LLM 的热搜词和框架讨论很多什么 LLM Wiki、LLM Agent、LLM 编排框架、函数调用、RAG、MCP看起来似乎 LLM 已经在编程领域无处不在。但我把这些信息汇总起来看发现它们的共性并不是“AI 代替人写所有代码”而是“AI 把零散知识转译成人能更快理解的形态”。例如 LLM Wiki 这个思路本质就是把大模型当成一个动态输出的知识图谱它能在你需要的时候把文档、代码片段、项目历史提炼成符合上下文的解释。ComfyUI 配合 LLM 的讨论解决的是图形化工作流和自然语言指令之间的桥接问题。这些场景并不要求大模型全知全能而是要求它能理解局部上下文、生成候选方案、暴露不确定性。这和社区反对 AI 生成的“黑盒代码”并不冲突甚至可以说这些用法正在帮助开发者更好地控制代码而不是失去控制。6.2 编排框架和 Agent 模式反而把“人为负责”重新放回中心很多人担心 Agent 和编排框架会进一步加速 AI 对编程的侵蚀我的观察恰好相反。Agent 要真正跑起来必须定义清晰的目标、输入、输出边界、失败策略和人工确认点。这等于把传统软件工程里的接口设计、错误处理和审计机制重新搬回 AI 任务里。我最近在调试一个基于 MCP 的本地工具时最大的感受是真正难的不是让大模型回复一段文字而是让它在多工具协作时保持状态一致、遇到异常能及时回退、操作记录可追溯。这些约束条件恰好和编程社区对代码质量的要求高度一致。也就是说工程经验反而能让 LLM 使用变得更可控。6.3 精度问题、显存、模型体积这些热词折射的是“本地化落地的焦虑”网上关于 FP32、FP16、BF16、量化、模型体积、推理引擎的讨论非常多。这类话题背后是一种现实压力不是所有人都有条件在云端跑最新版大模型也不是所有项目都能承受 API 调用成本。越来越多开发者在研究本地部署研究怎么用消费级显卡跑一个可用的小模型研究怎么在数据不出机器的情况下完成代码辅助。这种本地化趋势其实对编程社区是友好的。因为本地模型意味着代码和上下文不会外流许可证风险相对可控使用者更有机会真正“检查”模型的输出。它也降低了“AI 生成内容”的神秘感。当你亲自部署、亲自量化、亲自对比输出差异之后你会发现 LLM 并没有想象中那么聪明它的输出高度依赖于提示词、上下文和知识库质量。这样一个祛魅的过程比争论“要不要用 AI”更有价值。7. 如果社区已经对 LLM 产生抵触维护者可以做哪几步来缓解7.1 把规则从“禁止 LLM”改成“明确 LLM 的使用边界”如果你是在社区里有决策权的人我建议你不要用“全面禁止 LLM”这种一刀切的管理方法。因为 LLM 以后一定会越来越普及你禁止不了它只会把真相逼到地下。更有效的做法是定义“什么情况下可以用、什么情况下必须人工负责”。比如文档翻译可用 LLM 初译但必须人工校对并保留校对痕迹。代码生成可以用 LLM 辅助但提交者必须能解释每一段代码并且本地跑通测试。issue 与评论禁止用 LLM 自动生成。要发就发自己真正思考和遇到过的问题。PR 提交鼓励直接说明哪些部分用了 AI 辅助以及自己做了哪些人工修正。安全关键代码不建议用 LLM 直接生成除非后续有完整的测试覆盖和人工 review。这套规则的好处是它把“人是否负责”作为判断标准而不是“是否用了 AI”。这样的社区态度即使在 AI 能力继续进化之后也不会过时。7.2 提供更友好的人类贡献入口有些社区对 LLM 的强烈抵制其实暴露了一个问题原来的人工贡献门槛太高了。新手进来不知道该改什么不知道代码风格是什么不知道测试怎么跑所以他才会转向 AI 求得一个“看起来合格的答案”。如果社区能提供清晰的标签位、低门槛任务、友好回复模板很多人就不会再依赖 LLM 去硬凑内容。我见过一个项目会专门维护一个 “good first issue” 列表每个 issue 里都写清楚涉及的文件、期望改动、可能的实现路径。这种项目里AI 生成的垃圾 PR 反而很少因为真人提交者发现自己直接读文档花半小时就能搞定没必要让 LLM 生成后还要花更多时间解释。7.3 让“真实的互动”比“完美的输出”更有回报最后一点也是很难量化的一点社区的激励结构决定了成员的参与方式。如果你总是手动合并那些措辞严谨、格式完美的 PR而对那些有真实上下文、但也伴随粗糙和犹豫的贡献者冷眼相对你实际上是在鼓励“看起来合格”的内容生产而不是“真实参与”的协作行为。我并不是说要降低代码或者文档质量而是建议维护者在评价贡献时加上一条“是否愿意参与后续维护”的维度。一个愿意在 PR 合并后继续跟进 bug 的贡献者比一个提交 500 行精美化代码后就消失的账号长期价值高得多。当你公开重视这种价值社区的风气就会慢慢转向真实协作而不是内容生产竞赛。8. 对普通开发者来说怎样判断 LLM 参与社区的“安全线”8.1 三个可操作的问题清单我把自己在社区里使用 LLM 前的自检流程整理成三个问题第一个问题这个任务如果完全不用 LLM我需要多少时间如果不到 20 分钟那就别用 LLM自己写。不值得为了省二十分钟引入无法解释的代码。第二个问题如果 LLM 生成的答案最终被证明是错的我有能力自己定位和修复吗如果能说明你只是在借用 AI 的初稿能力如果不能说明你在依赖一个自己没有验证的黑盒这种情况不要提交给社区。第三个问题如果维护者追问这段代码的设计思路我能用自己的话讲清楚吗如果讲不清那要么是代码本身有问题要么是你还没有真正把它变成“你的代码”。无论哪种情况都不适合提交给协作项目。8.2 在公开社区里减少“AI 痕迹”的通用做法这里不是教你隐瞒而是让输出更符合协作语境。既然 AI 生成的内容在语法上往往过于规整我的建议是先说明输入材料里有什么、缺什么。如果某个结论来自 AI 的推测直接标注“这一点需要后续验证”。回答问题时先讲自己如何定位再讲解决方案不要只丢一个答案。如果是从 AI 得到的建议建议再补一句“我用本地环境试跑了一下结论如下”。这些做法并不是在掩盖 AI而是在主动交代你的推理路径。维护者并不追求零 AI 痕迹只希望得到可验证、可追问、可进一步讨论的信息。9. 长期来看爱好编程社区和 LLM 的关系会走向哪9.1 从“非此即彼”走向“分层共识”我判断未来三五年之内社区里会形成比较稳定的分层共识。对高风险任务、核心架构、公共接口大多数项目仍然会要求人工主导对文档、测试、样板代码、翻译、数据整理这类低风险任务LLM 会逐渐变成日常工具。到了那个阶段人们讨论的将不再是“要不要用 LLM”而是“这套自动化流程的审计点在哪里”。这个过程会很不舒服。老一代维护者会觉得工具侵入社区文化新一代开发者会觉得规则过时。但技术社区本来就是这么演化过来的从邮件列表到即时通讯从单体仓库到微服务从手动部署到 CI/CD每一轮技术冲击都会重构协作方式最终留下适应者。9.2 社区规范会逐渐沉淀成模板化文本我比较乐观的一个点是越来越多项目正在把“AI 使用规则”写进贡献文档而不是靠维护者个人情绪判断。这是很明显的进步。当规则变得显式贡献者就知道边界在哪里维护者也就不用一个一个去消耗心力解释。未来的 CONTRIBUTING 文件里也许会出现这样一段话“本项目允许使用 AI 辅助工具但提交者必须对提交内容负责。禁止直接提交未经人工审查的 AI 生成内容禁止使用 AI 自动生成 issue 或评论建议在 PR 描述中说明 AI 辅助范围。若不确定请先提交一个说明 issue 与维护者沟通。”这段文字不复杂但它能解决相当大一部分冲突。它把判断依据从“是否用了 AI”转换成“是否有人负责”。这正是社区协作最核心的一条原则。9.3 对个人开发者来说最重要的不是选边站而是建立自己的判断体系说到底无论是强烈反对 LLM 的维护者还是热衷于用 LLM 提效的开发者都不是铁板一块。“用不用 LLM”其实不是一个技术选择而是一个劳动伦理、责任边界和社区价值观的综合判断。我的建议是不要因为一个人反对 LLM 就觉得他顽固也不要因为一个人拥抱 LLM 就觉得他先进。多看看他反对或支持的具体场景是什么多看看他在那个场景里是否愿意承担责任。判断一个开发者是否靠谱最根本的标准依然是他能不能理解代码背后的决策、能不能沟通、能不能在出错时站出来处理。这个标准不会因为 AI 出现而改变。10. 如果只能记住一点我希望是这条回到开头那个被关闭的 PR。我想那个提交者大概率不是坏人他只是用了一个看起来更快的工具却忽略了他正在进入一个需要长期维护关系的社群。维护者也不是坏人他只是想在有限精力里守住项目最后一点可维护性。这场冲突不是“人和 AI 的冲突”而是“两种完全不同速度的生产方式在同一个时空里相遇时的摩擦”。LLM 生产内容的速度太快快到不需要经历思考、犹豫、失败和修正而社区协作最珍贵的部分恰恰是那些看起来低效的过程——讨论、试错、互相解释、甚至争吵。我现在写任何涉及社区贡献的文章都会先提醒自己一句话技术的价值不在于它生成得有多快而在于它最终能不能被另一个人理解、维护和信任。这一点对 LLM 同样适用。如果一个 AI 生成的东西连提交它的人自己都解释不清那它走不进一个负责任的社区。如果你能解释清甚至能为它负责那 LLM 就只是一个工具和编辑器、调试器、搜索引擎没有什么本质区别。希望这篇讨论能帮你更冷静地看待“社区对 LLM 的抵触”。下次看到有人愤怒地关闭一个 AI 生成的 PR你可以先别急着站队试着想一想这个维护者想保护的是不是他最珍视的协作环境而那个提交者缺的是不是对社区规则的敬畏答案往往比表面上的技术之争更有意思。