目前，有些人可能会上传完全由大语言模型（LLM）生成的插件、主题或组件，却未对此进行说明。了解某项内容是否完全由 LLM 生成有许多好处，而目前并没有强制要求披露此类插件的生成方式。就我个人而言，我希望提前知晓这一点，以免最终安装了一个质量低下且存在诸多性能、优化或用户体验问题的 LLM 插件。
当然，这依赖于用户如实且坦诚地说明情况（而拥有 AI 生成主题的用户可能并不比 AI 本身更清楚其内容），但为那些主要由 AI 生成的资源添加一个如 #ai-generated 的标签，将对所有人都有益。
我不同意“LLM 生成的插件天生质量低，或者必然存在性能、优化或用户体验问题”这种观点。最终结果的质量很大程度上取决于引导 LLM 的人以及对其输出进行审查的人。
在过去 40 年里，我一直为自己开发的软件感到自豪，而将 LLM 纳入我的工作流程提高了我工作的质量，而不是降低了它。
相反，我也见过许多手写插件充斥着安全漏洞、性能问题和不良的设计决策，那时我真希望作者能使用 LLM。归根结底，重要的是开发者的质量以及最终生成的代码，而不是编写过程中是否涉及了 LLM。
我想知道，对于像我这样刚开始尝试“氛围编程”（vibe-coding）以实现新功能或定制现有已发布功能的人来说，你们建议如何审查和/或更新由大语言模型（LLM）生成的代码？
我知道在公共仓库中进行集体审查是最理想的，但我希望先做好自己的功课，只发布那些已经超出我当前能力范围、无法进一步优化的版本。
我同意上一条评论的观点：我并不是反AI，但同时我也意识到，它们生成的所有内容都必须由人类进行审计、验证和更新。
一个相关的有趣现象：
这完全合理。归根结底，我只能代表我自己说话。我的观点基于对大量低质量“垃圾”应用的观察，这些应用看起来都大同小异，且在功能和安全方面普遍质量低下。此外，还有一些现有应用，自从开始大量将工作外包给 LLM 后，质量也严重下滑（例如 Visual Studio Code 和 Formbricks；我目前已经停止使用这两款软件）。即使你的应用是完美的，仍然存在伦理方面的担忧，因此如果能有某种形式的通知来标识这些由 AI 生成的内容（如建议的那样）会非常好。这并不意味着任何人必须根据该标签做任何事情，但如果你希望如此，那么提供这个选项是很好的。
正如我所说，这本质上是一个基于信任的系统，确保代码被正确标记是开发者个人的责任。当然，在某些情况下，LLM 会在 git 日志中自我标记（大多数情况都是如此），因此 TL3 及以上级别的人员如果愿意，可以通过查看 GitHub 来采取相应措施。
感谢您的回复。我的提问也是面向所有人的，涉及目前存在的用于验证 LLM 生成代码的工具。
我并不是开发人员，但我成功实现了 Discourse 中原本不存在的功能。我希望以尽可能好的方式做到我力所能及的事情。
如果我最终决定发布我的代码仓库，我会考虑添加标记；目前它们是私有的，正是因为我在进行测试，而且我希望在分发给社区之前确保一切正确无误。
如果大多数 Core 代码（包括核心插件）现在不是由编码智能体（Coding Agents）构建的，我会感到极其惊讶，因为开发方式已经发生了如此巨大的变化。
在我看来，现在很难为在大多数工作中不使用编码智能体找到合理的理由，因为效率的大幅下降在商业上根本说不通。
我完全不在乎“插件是如何编写的”，也不关心开发者用的是铅笔还是钢笔。
“这里没有 AI”这种说法，在我安装主题或插件时，并不能给我带来哪怕一丁点额外的信心。
然而……我们在 CDCK 上需要解决一个更严重的问题。
Discourse 的核心插件和源代码会定期进行安全扫描，当用户安装受支持的频道时，他们对代码的安全性是有信心的。
但这里的第三方插件和主题却像是“狂野西部”，任何人都可以提交内容，我们既不对其进行安全扫描，也不确保它们遵循最佳实践。这让社区处于风险之中。
我希望达到这样一个状态：主题的“XYZ 版本”至少能经过自动扫描，从而让自托管用户至少获得一些信心。
因此，我这里的愿景恰恰相反 
要求第三方主题和插件的特定版本在在此处展示之前，必须通过某种形式的 AI 扫描。
在我看来，至少从伦理角度来看，由 LLM 进行代码审查与“让 Claude 给我构建这个应用并且不要犯任何错误”，然后几乎不经过验证或编辑就直接发布输出结果，这两者是完全不同的。不幸的是，你无法真正强迫终端用户承担责任，而且无论你多努力，总会有人找到下载恶意软件的方法。但无论如何，LLM 的伦理问题是一个单独的议题，与本帖的主题并不太相关。
这完全没问题！我并不是建议在 Customization 版块对任何涉及 AI 的内容实施全面禁令……我只是希望它们能被正确标记，这样那些不想打开这个“潘多拉魔盒”的人就不会误入其中。