你的推理跨度有点大。
-
如果你雇个实习生，或者自己花 10 个晚上，也能给你的想象中的应用加上 FLAC 播放器。做出糟糕的产品决策并非 LLM 的固有属性，添加无用功能是否浪费开发精力，这向来都是值得讨论的话题。
-
额外的功能并不一定会让你的应用变慢或更占用内存，这个问题早在 40 年前就已经通过“动态加载”的概念解决了。
没错。重点是我加粗的部分 
3 個讚
不，不应该做这种区分。
- 软件安全吗？
- 它解决了我的问题吗？
再次回到我最初的论点：
如果我们在主题的安全性上存在问题，那就讨论一下审核机制；
如果我们在主题的质量上存在问题，那就讨论一下质量审核机制。
但是，我绝不会在帖子上贴上“在 Mac 上开发”、“在红色键盘上开发”或“93.2% 由 AI 开发”的标签，这绝不可能发生。
至于我使用了多少 AI，我很乐意在单独的帖子里分享我的工作流，但我已经不再用 vim 手动敲代码了。
7 個讚
仅仅因为插件是由 AI 生成的就全盘否定它们，这是一种“遗传谬误”。过去，AI 生成可能是一个判断内容是否粗制滥造的有效启发式标准，但随着模型的不断改进，区分人类输出和 AI 输出变得越来越困难。如果担心的是质量或安全性，我认为更安全的做法是假设所有代码都是不安全的，直到它们经过某种众包同行评审系统的审查。
我认为，分享如今团队如何使用 AI——从设计师、程序员，到法律、营销及其他领域——会吸引很多人的兴趣。
像我这样对 AI 略知一二，并不意味着真正了解并理解一家公司实际上是如何在日常工作中使用 AI 的。
6 個讚
我仔细阅读了这里的所有内容，也看到了双方的观点。我认为，人们可以随意在这里创建插件并发布它们，即使这些插件可能包含“潜在”的安全漏洞，从而危及 Discourse 的安装环境——这一点既有好处，也有坏处。
稍微有点跑题了。
比如，还有另一家论坛软件提供商（WoltLab）拥有插件商店。在发布之前，插件和主题都会经过团队的审核。也许我们可以考虑在这里实施类似的机制。然而，问题总是随之而来：谁来负责审核？我可以想象，这需要投入大量的时间和人力。
2 個讚
我可以百分之百肯定地说，让我们去审查每一个第三方插件和主题，这绝对不是一个可行的想法。（至少，不能靠人工手动完成）
那由团队监督、维护和更新的一套精选工具，用于测试 LLM 生成的插件或 TC，怎么样？
我知道每个人都可以自行运行测试，但说实话，并非所有人都知道该怎么做。
在我看来，一种简单且可靠的方法似乎是两全其美的选择。
这正是本主题的核心所在：
看到大家从道德和安全两个角度阐述为何这种透明度可能很重要，是一件很有趣的事。就我个人而言，我不在乎某个作品是由一位拥有 30 年经验、从 Ruby 诞生之初就开始写代码的软件工程师制作的，还是由一个毫无编程经验的小蒂米（Timmy）制作的。如果它是 100% 的“垃圾代码”[1]，我就不会使用它，否则对我来说就是自相矛盾的。我理解为什么它很流行，但这并不是我会支持的东西。如果这些模型是经过合乎道德的方式训练的，并且没有导致组件短缺以及 AI 生成媒体泛滥的流行病，我对这些模型的看法可能会没那么负面，但我们生活的现实世界并非如此。
全球范围内对插件的安全担忧也是合理的，而且不仅仅局限于“这是由 AI 制作的”这一点。这是一个难以解决的问题，超出了本主题的讨论范围；本主题仅仅是一个建议，要求对完全由 LLM 生成的资产进行标记。
我拒绝使用“氛围编程”（vibe-coding）或“代理开发”（agentic development）这类词汇 ↩︎
1 個讚
我仍然没看出这试图解决什么问题。有没有人能举一个例子，说明某个靠“感觉”写出来的插件质量很差、存在安全隐患或严重拖慢性能？那种根本不应该在这里推广、纯属垃圾、浪费大家时间的插件？
如果确实有这样的例子，它们足以构成一个问题吗？
1 個讚
在我看来，为主题制定某种自我认证清单可能同样有用：你做了多少测试？你是否准备好接收有关质量和安全的报告？你是否会对反馈做出积极响应？
或者，用不超过三句话描述你的开发流程。
这些回答的真实性可能价值有限，但对于正在考虑安装该主题的人来说，自我认证的主题与未认证的主题之间的差异，或许是一个值得关注的信号。
4 個讚
我个人从不使用“氛围编程”来开发任何应用程序、项目或软件。我会利用 AI 聊天来碰撞想法或寻求澄清，但绝不会用它来完成整个项目。这种方式虽然更手动，但我至少清楚自己在做什么，而不是盲目地将一切交给另一个实体。
不过，过去几个月里，我看到 AI 辅助编程有了长足的进步。起初，这类代码可能写得糟糕或充斥着漏洞，但我会说，自那以后它已经大幅改进了。那些“氛围编程”生成的设计仍然很容易辨认（渐变、边框、表情符号等），甚至在我在 Meta 上看到的一些插件中也是如此。但重要的是，作者分享这些内容是为了他们自己的兴趣以及社区的利益。不是为了让人去踩踏它并将其贴上“垃圾”的标签，而是因为他们确实在该插件中取得了成功，并希望将其分享给其他寻求相同功能的论坛。
我理解你对 AI 伦理问题的看法，但这似乎更多是针对 AI 整体的，比如公司拆解书籍、大量消耗水电等。你提到：
但这与使用 AI 制作的插件或 TC（主题配置）有何关联？如果你不喜欢 AI，当然可以不用。但随着 AI 的引入，编程领域已经发生了巨大的变化，插件和 TC 等事物也会随之改变。既然知道有些代码是借助 AI 编写的，你会因此完全停止使用 Discourse 吗？我不会，因为我知道背后仍然有人在维护。
所以，继续称其为“垃圾代码”并抵制“氛围编程”这个词（就我个人而言，我对后者这个词没有任何异议）是否仍然准确？也许不是。这是否太过苛刻？是的。尽管我认为你可能会不喜欢这一点，但有时候我们必须适应。这是否意味着我现在会制作并分享 AI 生成的 TC？对我来说，不会。但这是否意味着我会将其视为一种选择，而不是去排斥或轻视它？是的。我正在努力不这样做。所以我希望你能做到这一点。
5 個讚
分享一篇与此主题相关的精选文章：
Trail of Bits 认为，AI 智能体在审计中最有价值的用途是构建自定义工具，而不仅仅是发现漏洞。在对 Miden zkVM 的审计中，他们使用 Claude 和 Codex 创建了一个 LSP 服务器、反编译器、静态分析器以及 Lean 模型，从而发现了一个高严重性的签名伪造漏洞，并通过 95 个 Lean 证明捕获了两个细微问题。
由于智能体使得雄心勃勃的副业项目成本更低，审计的经济模式已转向以工具驱动的审查，能够比以往更彻底地保障复杂系统的安全性。
我使用 AI 来辅助开发我的插件和组件。请自行评估风险使用它们，但我不会为此添加任何免责声明或标签，这与 Discourse 核心代码的做法并无二致。我控制着这些智能体，审查代码（有时会借助另一个智能体或大语言模型来帮忙审阅），并进行测试。你可以选择不使用它们，但我见过更多完全由人类编写的糟糕代码，而不是由 AI 编写的。
5 個讚
确实，我认为传统上判断某样东西质量的方法，就是查看制作该产品的实体（或人）的声誉。当一个人活跃于开源社区时，个人声誉往往非常有效。通常来说，如果某人过去做过出色的工作并且响应及时，他们未来也会继续保持这种状态。
2 個讚
你仍然需要付出大量的实际工作。即使使用大语言模型（LLM）来创建确定性工具，你也必须验证这些工具确实执行了正确的操作，而不仅仅是执行那些在统计上经常正确的操作。使用 LLM 来创建确定性工具，比仅仅通过 Markdown 文件向 LLM 发送提示并期望得到相同的结果要好（尽管后者在法律和伦理上仍然存在争议）。然而，如果盲目地使用 LLM 来维护该确定性工具，新版本就有风险随着时间的推移而丧失其确定性行为。
正如 Snyk 在其 VulnBench 报告中所示，使用 LLM 进行审计并不可靠：