这里面假设可太多了，也许在你对我的推断做出反应之前，可以先问问我的真实意思。
1 个赞
你并不孤单。我也希望能知道某个项目是否使用了大语言模型。
除了代码质量之外，围绕大语言模型还存在许多伦理问题。人们至少应该能够就他们安装的软件和支持的项目做出知情决定。有没有方法在使用大语言模型时足够谨慎，从而开发出优秀的软件？可能有。但在当前行业和政治状况下，是否存在合乎伦理的大语言模型使用方式？我认为这要困难得多。
但在我们在这里展开另一场冗长的辩论之前，请注意：这仅仅是关于透明度的问题，以便人们可以在安装某些东西之前做出自己的决定。
3 个赞
那么请解释一下我错在哪里？
或者：你的意思是什么？
这绝对是我想要的底线。我只是希望一开始就保持透明，让人们知道自己将要面对的是什么。就伦理问题而言：作为一个花了数月时间“投毒”大语言模型训练数据、并尽一切努力将这项技术排除在我的生活和所有代码库之外的人，如果我现在决定自己用它来开发应用，或者使用完全由大语言模型生成的应用，那无异于自相矛盾。
值得庆幸的是，做尽职调查并不难。我目前的政策是检查贡献者，如果我看到大量由大语言模型提交的代码，我就直接关掉，不再使用。我在这里只是建议添加一个小小的自我声明标签，以便让人们知情，但在这个帖子中确实有一些反对这一做法的合理观点。我完全理解它如何节省时间并让技术更易被大众获取，但我觉得想要远离它也并非不合理。
5 个赞
这事我就不掺和了，先观望一下局势发展。
显然有些人对结果很在意。我已经说完了自己的想法，也提了一些看法。
我不打算把自己的观点强加给别人，也不希望别人把自己的观点强加给我。
这事我不参与了，就等尘埃落定吧。
只是想补充一点：如果这是您担心的问题，那么您无需担心插件或主题，因为您根本无法再使用 Discourse 了。如今我们在开发过程中大量使用了 AI。
8 个赞
我知道，在理想的世界里，我根本不会使用任何由 LLM 编写的软件。可惜现实并不理想，我往往别无选择。正因如此，在仍有可能的情况下，更应努力保留这种选择权。
6 个赞
为了在这里把话说得清清楚楚：
我使用智能体（agents）来开发 Discourse。在过去大约 10 个月里，我手写的代码不超过几行。今年我开发了多项重要功能，并修复了大量缺陷。
如果你正在寻找一个禁止使用智能体编码的项目，恐怕你得另寻他处了。
7 个赞
我并没有要求禁止，OP（原帖作者）也没有。这个帖子的主题是“要求将 LLM 生成的主题和插件进行相应标注”。
2 个赞
既然核心功能可以免费使用，为什么主题还需要它？
1 个赞
我想，其中的逻辑是：我们无法避免核心部分由 AI 生成，但可以选择如何处理其余部分？
我理解他们正在询问什么（以及为什么问），但我认为，比起之前建议的做法，创建一个 AI-free（无 AI 参与）标签会更高效，供那些认为这一区分很重要的人使用。
4 个赞
那么问题就来了，什么才算“无 AI”？我在开发过程中确实会就具体问题向 Ask Discourse 或 Claude 提问，但我不会用 AI 来“氛围编程”整个项目。所以，这样一个名称在多大程度上涵盖了 AI 的使用？是字面意义上的 0%？还是允许使用 AI 聊天进行澄清？或者是完全由 AI 生成？我认为这一点应该被明确区分开来。
4 个赞
就我个人而言，AI-free（无 AI）意味着：
“我亲手编写了所有代码，如果任何人问我这个项目中任意一行代码的作用，我都知道它做什么——或者至少，如果我需要回忆一下，稍微读一遍就能弄清楚。”
但确实，定义必须清晰，而且我相信每个人的理解可能并不相同。
话又说回来，如果关注的是伦理或环境问题，那么即使只是向 AI 提问，也是问题的一部分……
真是个大坑。”
4 个赞
一个简单的起点就是“本项目不使用 LLM 生成的代码”。你大概无法做到百分之百的精确，这主要是一种意图的声明。我经常看到它与素食主义之间的相似之处：如果你把它推向极端，最终你会陷入矛盾和不可能做出的选择。但这不是重点。重点在于尽量减少不必要的伤害。
我看到 LLM 的使用带来了许多伤害：对长期代码质量、对我们的环境、对我们的社会，以及对我们自己的心理健康。当我审视一个我即将依赖的软件项目时，我想知道开发者是试图避免这些伤害，还是完全投入其中。如果他们觉得这个问题足够重要，以至于将项目标记为“无 AI”，那对我来说就已经是一个很有帮助的声明了。
2 个赞
这很令人遗憾，因为我对于 AI 公司如何基本上从互联网上窃取代码、破坏书籍，以及运行滥用爬虫程序而不尊重主机服务器（即使你忽略不必要的 DRAM 危机！）以在没人想要的 LLM 竞赛中抢先一步，仍然有着强烈的道德担忧。我已经停止使用很多应用，因为代码质量下降得太厉害了，比如 VS Code，它变得缓慢、内存效率低下且普遍存在 bug。Formbricks 的升级包停止工作，我的音乐播放器变得缓慢且臃肿（一旦添加功能变得如此容易，你就会开始失去项目范围并添加所有东西），而且有一半的时间停止播放音乐。
但问题是，我喜欢 Discourse，所以我不想停止使用它。它不像 IDE 或音乐播放器那样让我没有感情，甚至不像我的操作系统，因为我在 2024 年停止使用 Windows 之前就已经讨厌它了。除非软件因为 LLM 而变得极其有 bug 或缓慢，否则我不太可能决定停止使用它。
我并不想对这种情况持完全“非黑即白”的态度，但我无法克服使用 LLM 所带来的道德或隐私担忧。
2 个赞
我认同你的一些观点。作为一个重视隐私的人，我理解，如果想避免使用 AI，你就得停止使用明网（clearnet）。
无论技术本身如何，它都与那些在技术上支持互联网使用的一方有着固有的商业联系：Cloudflare、亚马逊、谷歌、Meta、微软。
我们正面临数字时代的转变，这一转变最终会使其光明面与阴暗面都进一步加深。只要我们还能够在无需身份验证的情况下浏览网页，我就认为我们可以选择中间道路，即有意识地使用 AI。
我认为 Discourse 就是这样做的，或者即使我属于你提到的那个群体——那些在设计插件或组件时甚至不知道如何下手的人——我自己在私下里也是这么做的。我在私下里进行开发，测试它们，并且不断学习，因为我正在做一个替代性的、去中心化的小众项目，这个项目好几年没拿到过资金，我也没找到任何人愿意以低于数千美元的报价来做这件事。
这里有许多细微之处需要分析，我不认为一个简单的标签能从根本上或从核心上解决这个问题。在我的人生哲学中，行动胜于言语，所以我想知道，最终在这一问题上，你们究竟是如何付诸行动的。
3 个赞
我不是想吹毛求疵，但你觉得对于由有能力的开发者开发的成熟软件来说，使用 AI 在技术上是否普遍存在问题？我指的仅仅是应用的效率、稳定性和安全性。
在大型语言模型（LLM）出现之前，我就见过大量应用变得缓慢、臃肿、带有恶意或损坏。
我在日常生活中使用许多应用程序，目前为止我还没有注意到任何据称是由其代码中使用 AI 导致的技术问题。而且我相当确定，如今这些应用中至少有 95% 都在某种程度上使用了 AI 进行开发。
如果我使用由不称职的开发者制作的应用，无论是否使用 AI，我的体验肯定都会很差。
和大多数人一样，我也见过像“看那个由著名开发者制作的著名应用，因为 AI 而崩溃了”这样的闹剧，我相信这确实发生过（并且还会再次发生）。
但我认为这种情况很罕见，我认为有才华的开发者不需要等到 AI 出现，他们的项目也早就因为各种原因在某些时刻失败过。
我因为许多原因（包括你提到的一些原因）对 AI 感到担忧（有时甚至感到厌恶），但我并不真正担心“我的音乐应用现在变差了，因为 AI”（再说一遍，我并不是说这种情况不会发生）。
6 个赞
这取决于自律。让 AI 去执行编写测试等琐碎任务，与构建整个应用（或在本例中是插件）并将其作为自己的作品发布，这两者并不相同。我确信，如果我明天醒来后决定“我刚才在想什么，LLM 超级合乎道德，而且真的能帮助我的工作流！”，那么是的，我就能克服职业倦怠，像其他一些更有经验的开发者那样更快地开发东西。但就我个人而言，这剥夺了编程和开发的乐趣。我享受编程，无论是作为爱好还是工作——把它外包给 LLM 会消除所有乐趣，因为你并没有真正在写代码；你只是一整天都在输入提示词。
这一直是个问题（Windows 10 于 2015 年发布），AI 变得流行并且在编程方面变得“擅长”只是加速了这一过程，因为它让向应用中添加臃肿功能变得太容易了。假设我有一款导航应用，某天我突然决定想添加一个内置的 FLAC 播放器，并附带大量集成。显然，这没有必要存在，对于导航应用来说完全超出了范围，而且会浪费我或我开发者的时间。但如果我只是去问 Claude：“给我的应用添加一个带有 x、y 和 z 的音乐播放器”，然后我就可以直接添加并发布了。原本是一个“这可能很酷但没用且浪费时间”的想法，现在变成了一个真实的特性，我想象中的用户现在都拥有了它，这增加了应用的占用空间，使其变得更慢，并占用更多的 RAM/存储空间。虽然这最终只是想象，但这个场景绝对真实存在，并且正在许多应用中发生。
无论有没有 LLM，制作一款好应用都是开发者的责任。一个粗心的开发者，无论是否使用 AI，要么会做出糟糕的应用，要么会做出还行的应用但得意忘形从而毁掉它。需要说明的是，我并不是像反对图像和视频生成模型那样严格反对 LLM，我只是认为它们有它们的位置，而且对于大多数无法负责任地利用该技术的人来说，这个位置并不是编程。
3 个赞
我还没跟上大家的讨论，脑子也转不动去查具体的参考资料，但我发现了几个「标签系统」或「披露框架」，如果你们还没关注到的话，或许值得研究一下。如今的问题与其说是 AI 是否被使用，不如说是它是如何被使用的。让 LLM 根据一段指令生成一个插件，然后告诉它「测试并修复错误」，这与保留对开发工作的整体方向把控和监督，并以受控的方式使用 LLM 来执行具体工作，之间有着巨大的差别。对我来说，要求提供代码的人主动披露相关情况，是一个值得考虑的方案。
（附注：当然，我对这些问题的熟悉程度更多是在写作领域，而非编程领域。）
3 个赞
我同意你的看法，这确实是个关注点 
1 个赞