目前，有些人可能会上传完全由大语言模型（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 的内容实施全面禁令……我只是希望它们能被正确标记，这样那些不想打开这个“潘多拉魔盒”的人就不会误入其中。
我对基于大语言模型（LLM）的工具（及其结果）有很多顾虑。不仅仅是安全、法律、可靠性和环境问题，但这并非本文讨论的重点。
这里真正重要的是广义上的“安全”问题，无论代码是否由 AI 生成。
CDCK 使用哪些工具来进行安全检查？其中许多工具对于第三方创作同样至关重要。
但需要检查的内容远不止于此。第三方创作与哪些外部系统进行交互？大多数安全分析工具会默认软件与外部服务器通信，且无需心跳检测。然而，一个纯粹用于外观主题的组件不应该向任何外部服务器发起调用。因此，第三方创作可能包含安全漏洞，或者存在可能损害可用性的问题。此外，它们还可能窃取数据。
我 95% 同意这个观点。而且我们现在谈论的是 Discourse，想象一下如果我们在 WordPress 的世界里会是什么样子！
（那缺失的 5%：我认为这并非“狂野西部”——安全问题会通过 meta 报告给那些第三方开发者，而且通常修复得相当迅速）。
但与此同时，我的经验是，LLM（如今）生成的代码比平均水平的插件作者更安全可靠。你可以把任何插件扔给任何合格的 LLM，让它“查找并修复任何安全问题”，它都能做到，即使人类对安全知识知之甚少。
过去十年里，我一直手动审查插件，见过很多情况：SQL 注入（由那些认为 ActiveRecord 太花哨的人造成）、API 密钥设置中带有 client: true、完全缺乏授权和访问控制、缺乏速率限制。这些问题都能被 LLM 迅速且毫不费力地发现并修复。
所以再次强调：我认为 LLM 让情况变得更好了，而不是更糟。
你仍然将 LLM 生成的代码与“潘多拉魔盒”联系在一起，这未免太非黑即白了。
Jack McDade 在 Statamic 插件目录中采用了这种方法
我欢迎这种做法，发现它对于确认我们已知需要完成的工作很有用。它也有助于增强对代码的信心。
似乎 Team 可以在此处实施类似的措施，而不会过于牵强。
我也很担心低质量的插件和组件，尤其是当它们 99% 是由不懂编程的人凭感觉（vibe coding）编写时，我实在不太敢信任它们。
不过，我也相信这里有些经验丰富的程序员说过，在 AI 出现之前，糟糕的程序员就已经存在很久了[1]。粗糙、不可靠、充满缺陷的代码，自古以来就是人工手写的。
真正让我担心的是，当我看到一个凭感觉编写的应用/插件/whatever，并且怀疑作者并没有审查过代码时。
虽然我对编程有一些基础知识，但我已经很久没有写代码了，而且以前也从来没写好过。我尝试用“凭感觉编程”的方式做了一些项目。
起初我非常犹豫要不要在 meta 上正式发布它们，但最终还是发布了。在此之前，我花了时间去审查和理解每一段代码的作用，并在我的主题中公开说明了我的做法。虽然我不记得发布前读过所有细节，但至少在我发布这些作品时，我能确保其可靠性和安全性。
我有一个很好的例子，可以说明“凭感觉编程”如何可能导致我发布一个非常不安全的插件。
在开发 🖼️ Topic Gallery 之前，我先在这里做了一个类似插件的概念验证：A way to monitor user-uploaded files 🖼️ - #2 by Canapin
它运行得很好，AI 也遵循了我的指令。
但问题是：虽然这个功能明显是一个管理功能，但 AI 并没有考虑权限问题：任何用户，包括访客，都可以打开这个页面并查看所有用户上传的文件。对我来说很明显这应该仅限管理员访问，但 AI 并没有“想到”这一点。而且因为我没有明确要求，它默认生成了一个公开页面。
所以我一直告诉自己，如果连我和 AI 都疏忽了这样一个安全漏洞，那么那些不懂代码却凭感觉编写 TC 和插件的人，不幸地可能会犯同样的错误。
关于软件中 AI 代码的看法两极分化严重。你只需要看看任何流行的开源项目，只要 Claude 被列为最近提交的共同作者，就能看到某些人发出的大量仇恨言论。
我确信我们应该谨慎对待这些事情，我们的观点应该更加 nuanced（细致/有层次）。
我特别不赞成添加某种 vibe-coded 标签，因为这可能会不必要地损害那些编写良好且安全的自定义插件及其作者的声誉。
我知道现在任何人都可以制作自定义插件，未来每天可能会有越来越多这样的插件出现，而审查它们的人手却不够。
AI 审查也许是解决方案。出于各种原因，我的直觉并不太喜欢这个想法，但我相信如果 Sam 提出这种解决方案，那它很可能是一个好方案，因为我非常信任他的技能和判断力。毕竟我自己也一窍不通。
也许这里有些懂编程和 Discourse 生态系统的开发者可以拥有一个明确显示其在该领域专业性的头衔，这样即使是那些只是来寻找自定义插件而未注册的访客，也能将他们视为值得信赖的开发者。这与 darkpxlz 的要求正好相反。我们不是要“羞辱”那些可能不可信的自定义插件，而是要突出那些值得信赖的插件。
这只是抛砖引玉，仅供参考。
我对此深有体会，我当年就是其中之一！ ↩︎
完全有可能我陷入了媒体消费和日常交往对象所构成的反 AI 回声室。我原本几乎肯定这个请求不会像现在这样不受欢迎，但如果这里的每个人实际上都喜欢使用 LLM 进行编码，并且不希望仅仅为了透明度而添加标签，那我又能阻止谁呢？检测 LLM 代码目前仍然相当容易，所以如果任何人（比如我自己）真的想避免使用它，他们可以像我之前建议的那样，通过检查贡献者列表中是否有 LLM 自我标记来做到这一点。
鉴于这是一个有争议的话题，我个人支持你最初的请求，因为这能服务于社区中目前持怀疑态度（这完全可以理解）的那部分人。
不过，我怀疑我们最终会给几乎一切都贴上标签，这岂不是本末倒置了吗？
我也同意其他人的观点，即并非所有 AI 生成的代码都同等质量——有些是由较新、更昂贵的模型生成，并由经验丰富的开发者指导编写的；而在另一些情况下，可能只是经验较少的人使用能力较弱的模型一次性生成的，且该仓库可能并未遵循最佳实践——你只能通过检查仓库本身以及观察人们是否频繁遇到问题来判断这一点。
我认为，对于任何重要的软件，无论其最初是由人类还是 AI 编写的，由人类和 AI 共同进行彻底审查都是一个好主意。如果能有更好的工具来审查软件并跟踪谁审查了哪些包的哪些版本，那就更好了。目前，Rust/Cargo 生态中已经有一些类似的东西：Crev、cargo-vet 和 Thirdpass。我还在 Swift 论坛上发起了一场讨论。