网友征集明确避开 AI 的应用、公司与资源清单

• 76 你知道哪些“无 AI”的应用/公司/资源？ ☶ 提问 作者 brn 2026-11-11 07:13:51 | 33 条评论

你知道哪些“无 AI”的应用/公司/资源？

大家好，我想知道是否有任何有用的清单，列出那些避开 AI 的应用、公司或一般资源（它们不必大声或公开地“反 AI”，但至少明确避开 AI），你们知道的？

我不是想发起一场关于 AI 好/坏或（不）值得的讨论，也不是想讨论谁支持/反对，只是想要推广这种情绪/立场的链接和/或社区。

例如，https://www.rebeltechalliance.org 就是这样的资源之一。

• 20 nate30480 2026-11-11 07:39:39 https://codeberg.org/ethical-foss/ai-free-foss-alternatives 24 henrycatalinismith 2026-11-11 09:14:23 一个标题为“AI-free FOSS Alternatives”的列表最终变成了与其既定目标相反的东西，这真是太可惜了，顶层章节是“Tainted Software”，偶尔还零星地列出一些替代品。我喜欢那些坚定的反 AI 人士，尽管我并不真正属于他们中的一员，我希望他们能够蓬勃发展，并在网上开辟出一个持久的空间。更多地关注反 AI 愿景的积极面，少关注拒绝和排斥的东西，可能会对此有所帮助，而且我认为这是一个非常清晰的例子，说明信息的负面一面不必要地抢了风头。“tainted”列表是圈内人的东西，应该放在那里相当于 Wikipedia 讨论页的地方。11 jzb 2026-11-11 13:05:19 更多地关注反 AI 愿景的积极面，少关注拒绝和排斥的东西，可能会对此有所帮助，作为一般规则，我认为“关注积极面”是一个好的经验法则。作为一条 blanket rule，它并不奏效。有时它确实关乎负面。如果你试图说服人们，比如说，不要吸烟或吸海洛因……真的，“不沉迷于东西很棒”并不像“如果你吸烟你会得肺癌”或“这就是海洛因成瘾对人的影响”那样有说服力。（诚然，“just say no”作为一场运动也很糟糕，但原因不同。）我并不是说 AI 使用完全等同于海洛因使用，但我不确定“反 AI 愿景的积极面”是否像反对生成式 AI 的论点那样有说服力。信息的负面一面不必要地抢了风头，再说一次，我并不真正同意这一点。有些事情反对是有道理的。在我看来，这在生成式 AI 的情况下尤其如此，因为它在几年内传播并基本上席卷了整个行业。对我们中的一些人来说，它是软件界的黑霉或石棉。“哎呀，拥有一座没有黑霉的房子真是太棒了”并不完全等同于“这就是黑霉如果侵扰你的房子会对你做的事情”。10 dkl 2026-11-11 09:55:14 我强烈同意，为美好的事物而战比反对坏的事物更好。然而，我发现这个列表是一个非常有用的起点。研究它让我得出了（对我来说很惊人的）结论：GNU/FSF 的愿景是一个积极的愿景，包含了拒绝 AI。可能还有其他愿景，但至少从 GNU 开始不是从零开始。在 GNU 上翻转立场并不在我今年的个人哲学宾果卡上。10 sunshowers 2026-11-11 14:03:40 这个列表以前叫 Open Slopware。我在这里写了我个人与它的关系：https://lobste.rs/s/unpaan/arborium_is_ai_slopware_should_not_be#c_twqzh3。9 henrycatalinismith 2026-11-11 14:33:05 嗯，不幸的是并不太令人惊讶。我认为这是一种常见的未言明的伦理框架，如果你相当进步和/或在任何方面被边缘化，那么你在本体上就不可能虐待他人，因为你的糟糕行为实际上只是正义的愤怒和道德勇气，你收到的任何批评实际上只是特权者的语气警察。我曾经也认同这种思维方式，后来已经摆脱了它，但它在反 AI 活动领域目前特别流行。实际上前几天我写下了我的一些想法。公开的恶劣行为可能会让你一时感到活着，但它与任何有意义的现实世界目标相冲突，而且在反 AI 空间中如此正常化，以至于我得出的结论是，整件事更多的是在发泄对不想要的变化的集体悲伤，而不是实现任何具体的东西。~ hsivonen 2026-11-12 01:10:03 我觉得有趣的是，一些似乎喜欢这个 li

st 会因为人们不使用类似“sent from my iPhone”的 LLM 广告/免责声明来披露 LLM 使用而感到不满，但随后这份列表附带了这样的说明：“本列表不是用于骚扰其他开源开发者的资源。如果你希望在其他项目中倡导‘No AI’政策，我们要求以尊重和建设性的方式进行（并且不要提及本列表）。” ~ brn 2026-11-11 07:58:14 谢谢，我之前不知道这个列表，不过它显示出的替代方案非常少（我并不是说它们存在，但这几乎让人感觉更加无助）。 9 nate30480 2026-11-11 08:12:45 它还链接到其他资源，但我认为 https://noai.starlightnet.work/list.html 可能主要就是你要找的。 ~ dkl 2026-11-11 09:50:31 过去几个月我一直在研究这份列表。主要结果之一是我回到了 Emacs。这不是我第一次使用它，但我发现如今要让它达到类似 IDE 的可用状态比以往任何时候都容易得多。我以前使用的大多数东西在 Emacs 本身内部都有替代方案。我发现，一旦克服了最初的犹豫，它提供了一种以人为本、可塑的环境，而我之前并未意识到自己缺少这样的环境。 8 jzb 2026-11-11 13:07:50 主要结果之一是我回到了 Emacs。哎。我有些坏消息要告诉你…… ~ dkl 2026-11-11 15:49:51 我很难理解你链接的那篇文章，但我注意到它链接到一个可能满足我要求的 Emacs 分支，所以我认为你实际上给我带来了好消息。 ~ hsivonen 2026-11-12 01:30:02 通过列出最后一个“未受污染”的提交并列出分支，这份列表似乎鼓励使用存在已知安全漏洞的版本。上游很可能有 LLM 发现的已披露安全漏洞。除了运行带有已知漏洞的软件来配合这份列表之外，对安全性还有其他设想吗？ ~ kolja 2026-11-12 02:46:22 嗯，我们确实没有/无法真正为此做规划，对吧？一些项目正在被分叉，并自行修复漏洞，但突然之间有太多项目不再可供那些希望其软件尽可能符合道德来源的人使用。幸运的是，很多软件只是在本地运行，所以如果你只处理自己的文件，你基本上不会受到攻击，只需忍受偶尔出现的漏洞。但这令人心碎。 18 dustyweb 2026-11-11 08:48:03 嗯，我在那里工作，但我们既是一个 FOSS 非营利组织，也在 Spritely Institute 有坚定的禁止生成式 AI 政策，并且还做相当酷的去中心化网络技术 10 bsandro 2026-11-11 11:06:45 最近为此做了 https://braincoded.software ——它不是“反”，只是“不”。目前除了 IRC 频道之外那里没什么内容，但我正在为成员做一个仅限邀请的小型链接聚合器 + 公共 git 和 cvs 仓库。 ~ stephenr 2026-11-11 15:27:19 Git 和 Cvs 确实是一种选择。我理解提供 Git 替代方案。我认为 Mercurial 值得比现在多得多的喜爱。但为什么偏偏选 Cvs，而不是其他众多非 Git 替代方案中的任何一个？ ~ bsandro 2026-11-11 15:57:59 老实说我一直更喜欢 Mercurial 而不是 git，但某种程度上在某个时候放弃了，把我所有的东西都移到了 git，现在同时使用两者感觉很奇怪，尤其是因为 hg 相比 git 并没有给我任何可移植性上的好处。CVS 适用于你想使用某个旧系统（比如旧 Macintosh system7 或 9（尽管 @jcs 为它做了一个非常好的工具——Amend，甚至还有 amendhub.com！），或 *DOS）上的版本控制系统的时代和场景。 9 hoistbypetard 2026-11-11 11:35:48 我们几个想要避免它，或者至少对何时谈论它非常挑剔的人聚集在 imtiredboss.org。我们正在收集一些列表和链接，并有几个保持无生成式 AI 的讨论空间。 7 isagalaev 2026-11-11 12:23:09 还有一个：https://codeberg.org/brib/slopfree-software-index ~ bbbhltz 2026-11-11 08:09:56 https://noai

list.org/ ~ dsschnau 2026-11-11 08:11:42 “No AI” Webring 与此相关 - https://baccyflap.com/noai/ ~ brn 2026-11-11 09:23:55 谢谢，我的博客就是其中一员！😊 ~ sjamaan 2026-11-11 08:43:43 与 rebel tech alliance 类似，还有 trustworthy technology group。他们有一个 Zulip 聊天室，你可以加入进一步讨论。 ~ th0ma5 2026-11-11 13:19:55 这是一位学者收集的资料：https://olivia.science/ai/ ~ jakehamilton 2026-11-11 16:35:58 我正在组建一个软件合作社，其核心原则之一就是“反 AI”：https://conflagrate.software/ 我的想法是让它成为一个安全、舒适的空间，供人们创作与协作。 ~ Zurga 2026-11-11 08:50:02 你是否知道，你链接的那个资源是用一个站点构建器制作的，而该构建器在产品主视觉的第二句话里就提到了 AI？那个资源是手工制作的，但离 AI 并不远。 5 brn 2026-11-11 08:54:45 观察得好，但他们是在它变得“AI 驱动”之前使用的，这多少说明了我试图寻找替代方案时所面临的困难。 ~ Zurga 2026-11-11 09:18:41 是的，劣化无处不在。曾经正常的产品现在都带上了 AI…… ~ hwj 2026-11-12 01:11:11 最近，我在为 Go 挑选一个 SQLite 库。看起来 https://github.com/mattn/go-sqlite3/ 没有使用 AI。 ~ ItsFinishd 2026-11-11 17:01:41 与其回避 AI，为什么不选择负责任地使用 AI 呢？LLM 能加快速度，但代价是失去正确性，而我认为由于 LLM 的工作方式——统计匹配而非逻辑/直觉证明（这是人类擅长的）——很难轻易保证正确性。为了兼得两者之长，你会希望将 AI 用于更小、更易于审查的任务，然后用这些（也可以借助或不借助 AI）来构建更复杂的产品。我不介意不必写出一堆 AI 几乎能一模一样写出的代码。QA 和验证过程仍然是人类的工作，而且这大概也是你作为开发者大部分时间花的地方。实际编码的时间不超过 20%。在我看来，放弃像 LLM 这样的工具是个坏主意，如果它能帮助我们节省时间并提高输出质量，那就随它去吧。 17 seb 2026-11-11 17:18:35 从你所评论的帖子来看：我并不想开启一场关于 AI 好/坏或(不)值得、或谁支持/反对的讨论，只想要链接和/或推广这种情绪/立场的社区。在关于/面向不喜欢且不想使用 AI 的人的帖子下，发表相当于“你有没有考虑过 AI 其实并不全是坏事？”的评论是适得其反的，而且坦白说真的很累人。 13 khairo 2026-11-11 17:05:29 我只是不想用它。它不吸引我。我也不想用使用了它的东西。我不在乎它是否“效果更好”或“更高效”。做个卢德分子没什么不好。

• 20 nate30480 2026-11-11 07:39:39 https://codeberg.org/ethical-foss/ai-free-foss-alternatives 24 henrycatalinismith 2026-11-11 09:14:23 一个标题为“AI-free FOSS Alternatives”的列表最终变成了与其既定目标相反的东西，这真是太可惜了，顶层章节是“Tainted Software”，偶尔零星地列出一些替代品。我喜欢那些坚定的反 AI 人士，尽管我并不真正属于他们中的一员，我希望他们蓬勃发展，在网上开辟一个持久的空间。更多地关注反 AI 愿景的积极方面，而少关注拒绝和排斥的东西，可能会有所帮助，我认为这是一个非常清晰的例子，说明信息的负面方面不必要地抢了风头。“tainted”列表是内部的东西，属于那里相当于 Wikipedia 讨论页的地方。11 jzb 2026-11-11 13:05:19 更多地关注反 AI 愿景的积极方面，而少关注拒绝和排斥的东西，可能会有所帮助，作为一般规则，我认为“关注积极方面”是一个好的经验法则。作为一条 blanket rule，它并不奏效。有时它真的是关于负面的东西。如果你试图说服人们，比如说，不要吸烟或吸海洛因……真的，“不沉迷于东西很棒”并不像“如果你吸烟你会得肺癌”或“这就是海洛因成瘾对人的影响”那样有力。（诚然，“just say no”作为一场运动也很糟糕，但原因不同。）我并不是说 AI 使用完全等同于海洛因使用，但我不确定“反 AI 愿景的积极方面”是否像反对生成式 AI 的论点那样有说服力。信息的负面方面不必要地抢了风头 再说一次，我并不真正同意这一点。有些事情反对是有道理的。在我看来，这在生成式 AI 的情况下尤其如此，因为它传播的方式，并且在几年内基本上席卷了整个行业。对我们中的一些人来说，它是软件的黑霉或石棉。“哎呀，拥有一座没有黑霉的房子真是太棒了”并不完全等同于“如果黑霉侵扰你的房子，它会对你做什么”。10 dkl 2026-11-11 09:55:14 我强烈同意，为美好的事物而战比反对坏的事物更好。然而，我发现这个列表是一个非常有用的起点。研究它让我得出了（对我来说很惊人的）结论：GNU/FSF 的愿景是一个积极的愿景，包含了拒绝 AI。可能还有其他愿景，但至少从 GNU 开始不是从零开始。在 GNU 上翻转立场并不在我今年的个人哲学宾果卡上。10 sunshowers 2026-11-11 14:03:40 这个列表以前叫 Open Slopware。我在这里写了我个人与它的关系：https://lobste.rs/s/unpaan/arborium_is_ai_slopware_should_not_be#c_twqzh3。9 henrycatalinismith 2026-11-11 14:33:05 嗯，不幸的是并不太令人惊讶。我认为这是一种常见的未言明的伦理框架，如果你相当进步和/或在任何方面被边缘化，那么你在本体上就不可能虐待他人，因为你糟糕的行为实际上只是正义的愤怒和道德勇气，你收到的任何批评实际上只是特权者的语气警察。我曾经也认同这种思维方式，后来已经摆脱了它，但它在反 AI 活动领域目前特别流行。实际上前几天我写下了我的一些想法。公开的恶意可能会让你一时感到活着，但它与任何有意义的现实世界目标相冲突，而且在反 AI 空间中如此正常化，以至于我得出的结论是，整件事更多的是发泄对不想要的变化的集体悲伤，而不是实现任何具体的东西。~ hsivonen 2026-11-12 01:10:03 我觉得有趣的是，一些似乎喜欢这个 li

st 对人们不使用类似“sent from my iPhone”的广告/免责声明那样的 LLM 版本披露来公开 LLM 使用感到不满，但随后这份清单附带了这样的说明：“本清单不是用于骚扰其他开源开发者的资源。如果你希望在其他项目中倡导‘No AI’政策，我们要求以尊重和建设性的方式进行（并且不要提及本清单）。” ~ brn 2026-11-11 07:58:14 谢谢，我之前不知道这份清单，不过它显示出的替代方案非常少（我并不是说它们存在，但这几乎让人感觉更加无助）。9 nate30480 2026-11-11 08:12:45 它还链接到其他资源，但我认为 https://noai.starlightnet.work/list.html 可能主要是你要找的。~ dkl 2026-11-11 09:50:31 过去几个月我一直在研究这份清单。主要结果之一是我回到了 Emacs。这不是我第一次用它，但我发现如今让它达到类似 IDE 的可用状态比以往容易得多。我过去使用的大多数东西在 Emacs 本身中都有替代方案。我发现，一旦克服了最初的犹豫，它提供了一种以人为本、可塑的环境，而我之前并未意识到自己缺少这样的环境。8 jzb 2026-11-11 13:07:50 主要结果之一是我回到了 Emacs。哎。我有些坏消息要告诉你…… ~ dkl 2026-11-11 15:49:51 我很难理解你链接的那篇文章，但我注意到它链接到一个可能满足我要求的 Emacs 分支，所以我认为你实际上给我带来了好消息。~ hsivonen 2026-11-12 01:30:02 通过列出最后一个“未受污染”的提交并列出分支，这份清单似乎鼓励使用存在已知安全漏洞的版本。上游很可能有 LLM 发现的已披露安全漏洞。除了运行带有已知漏洞的软件来配合这份清单之外，对安全性还有什么设想吗？~ kolja 2026-11-12 02:46:22 嗯，我们并没有/也无法真正为此做规划，对吧？一些项目正在被分叉，并自行修复漏洞，但突然有太多项目不再可供那些希望软件尽可能符合道德来源的人使用。幸运的是，很多软件只是在本地运行，所以如果你只处理自己的文件，基本上不会受到攻击，只需忍受这里或那里的一个漏洞。但这令人心碎。

文章标题：你知道哪些“无 AI”应用、公司或资源？

正文： https://codeberg.org/ethical-foss/ai-free-foss-alternatives

• 24 henrycatalinismith 2026-11-11 09:14:23 一个题为“AI-free FOSS Alternatives”的列表最终变成了与其既定目标相反的东西，顶层部分是“Tainted Software”，偶尔零星地列出一些替代品，这真是太可惜了。我喜欢那些坚定的反 AI 人士，尽管我并不真正属于他们中的一员，我希望他们蓬勃发展，在网上开辟一个持久的空间。更多地关注反 AI 愿景的积极面，少关注拒绝和排斥的东西，可能会有所帮助，我认为这是一个非常清晰的例子，说明信息的负面方面不必要地抢了风头。“tainted”列表是内部的东西，应该放在相当于维基百科讨论页的地方。11 jzb 2026-11-11 13:05:19 更多地关注反 AI 愿景的积极面，少关注拒绝和排斥的东西，可能会有所帮助，作为一般规则，我认为“关注积极面”是一个好的经验法则。作为一条 blanket rule，它行不通。有时它真的是关于负面。如果你试图说服人们，比如说，不要吸烟或吸海洛因……真的，“不沉迷于东西很棒”不如“如果你吸烟会得肺癌”或“这就是海洛因成瘾对人的影响”那样有力。（诚然，“just say no”作为一场运动也很糟糕，但原因不同。）我不是说 AI 使用完全等同于海洛因使用，但我不确定“反 AI 愿景的积极面”是否像反对生成式 AI 的论点那样有说服力。信息的负面方面不必要地抢了风头，再次，我不太同意这一点。有些事情反对是有道理的。在我看来，这在生成式 AI 的情况下尤其如此，因为它的传播方式以及在几年内基本上席卷了整个行业。对我们中的一些人来说，它是软件的黑色霉菌或石棉。“哎呀，拥有一座没有黑色霉菌的房子真是太棒了”与“如果黑色霉菌侵扰你的房子，它会对你做什么”并不完全相同。10 dkl 2026-11-11 09:55:14 我强烈同意，为美好的事物而战比反对坏的事物更好。然而，我发现这个列表是一个非常有用的起点。研究它让我得出了一个（对我来说很惊人的）结论：GNU/FSF 的愿景是一个积极的愿景，包含了拒绝 AI。可能还有其他愿景，但至少从 GNU 开始不是从零开始。今年在我的个人哲学宾果卡上，翻转对 GNU 的立场并不在其中。10 sunshowers 2026-11-11 14:03:40 这个列表以前叫 Open Slopware。我在这里写了我与它的个人关系：https://lobste.rs/s/unpaan/arborium_is_ai_slopware_should_not_be#c_twqzh3。9 henrycatalinismith 2026-11-11 14:33:05 嗯，不幸的是，这并不太令人惊讶。我认为这是一种常见的未言明的伦理框架，如果你相当进步和/或在任何方面被边缘化，那么你在本体上就不可能虐待他人，因为你的糟糕行为实际上只是正义的愤怒和道德勇气，你收到的任何批评实际上只是特权者的语气警察。我曾经也认同这种思维方式，后来已经不再这样了，但它在目前的反 AI 活动领域尤其流行。实际上前几天我写下了我的一些想法。公开的恶劣行为可能会让你一时感到活着，但它与任何有意义的现实世界目标相冲突，而且它在反 AI 空间中如此正常化，以至于我得出结论，整件事更多的是发泄对不想要的变化的集体悲伤，而不是实现任何具体的东西。~ hsivonen 2026-11-12 01:10:03 我觉得有趣的是，一些似乎喜欢这个列表的人，如果人们不使用类似“sent from my iPhone”的 LLM 广告/免责声明来披露

使用开源 LLM，但这份清单附有这样一段说明：“本清单并非用于骚扰其他开源开发者的资源。如果你希望推动另一个项目采取‘No AI’政策，我们要求以尊重和建设性的方式进行（并且不要提及本清单）。”

文章标题：你都知道哪些“无 AI”的应用、公司或资源？

一份题为“无 AI 的自由开源软件替代方案”的清单，最终却变成了与其既定目标相反的东西——顶层章节是“受污染的软件”，偶尔还零星夹杂着一些列出替代方案的小注记，这实在太可惜了。

我喜欢那些坚定的反 AI 人士，尽管我自己并不真的算其中一员，我希望他们能蓬勃发展，在网上开辟出一片持久的空间。更多地聚焦反 AI 愿景的积极面，少得多地聚焦于拒绝和抵制之类的东西，大概会有助于实现这一点，而且我认为这是一个非常清晰的例子，说明信息中的负面部分不必要地抢了风头。“受污染”清单属于圈内人才懂的东西，应该放在相当于维基百科讨论页的地方。

• 11 jzb 2026-11-11 13:05:19 更多地聚焦反 AI 愿景的积极面，少得多地聚焦于拒绝和抵制之类的东西，大概会有助于实现这一点，作为一般规则，我认为“聚焦积极面”是个不错的经验法则。作为一条 blanket rule（一刀切的规则），它行不通。有时候重点确实就在负面。如果你试图说服人们，比如说，不要吸烟或吸海洛因……真的，“不染上瘾真好”并不像“吸烟会得肺癌”或“海洛因成瘾会对人造成这样的后果”那样有说服力。（诚然，“Just say no”作为一场运动也很糟糕，但原因不同。）我不是说使用 AI 就等同于使用海洛因，但我不确定“反 AI 愿景的积极面”是否像反对生成式 AI 的论点那样有说服力。信息中的负面部分不必要地抢了风头，再说一次，我并不真的同意这一点。有些东西，反对它是有道理的。在我看来，生成式 AI 尤其如此，因为它传播的方式，在几年内基本上席卷了整个行业。对我们中的一些人来说，它是软件界的黑霉或石棉。“哎呀，拥有一座没有黑霉的房子真是太棒了”和“这就是黑霉如果侵染你的房子会对你造成什么”并不完全一样。

更多地聚焦反 AI 愿景的积极面，少得多地聚焦于拒绝和抵制之类的东西，大概会有助于实现这一点，

作为一般规则，我认为“聚焦积极面”是个不错的经验法则。

作为一条 blanket rule（一刀切的规则），它行不通。有时候重点确实就在负面。如果你试图说服人们，比如说，不要吸烟或吸海洛因……真的，“不染上瘾真好”并不像“吸烟会得肺癌”或“海洛因成瘾会对人造成这样的后果”那样有说服力。（诚然，“Just say no”作为一场运动也很糟糕，但原因不同。）

我不是说使用 AI 就等同于使用海洛因，但我不确定“反 AI 愿景的积极面”是否像反对生成式 AI 的论点那样有说服力。

信息中的负面部分不必要地抢了风头

再说一次，我并不真的同意这一点。有些东西，反对它是有道理的。在我看来，生成式 AI 尤其如此，因为它传播的方式，在几年内基本上席卷了整个行业。对我们中的一些人来说，它是软件界的黑霉或石棉。“哎呀，拥有一座没有黑霉的房子真是太棒了”和“这就是黑霉如果侵染你的房子会对你造成什么”并不完全一样。

• 10 dkl 2026-11-11 09:55:14 我强烈同意，为某种好的东西而战，比为反对某种坏的东西而战更好。不过，我发现这份清单是一个非常有用的起点。研究它让我得出了（对我来说很惊人的）结论：GNU/FSF 的愿景是一个积极的愿景，其中包含了对 AI 的拒绝。可能还有其他的，但至少从 GNU 开始并不是从零开始。今年在我的个人哲学宾果卡上，可没有在 GNU 上翻转立场这一项。

我非常同意，为美好的事物而奋斗胜过对抗丑恶的事物。不过，我发现这份清单是一个非常有用的起点。研究它让我得出了一个（对我而言颇为震惊的）结论：GNU/FSF 的愿景是一种积极的愿景，其中包含了对 AI 的拒绝。可能还有其他类似的例子，但至少从 GNU 开始并非从零起步。今年我的个人哲学宾果卡上可没有“在 GNU 立场上反转”这一项。

• 10 sunshowers 2026-11-11 14:03:40 这份清单以前叫 Open Slopware。我在这里写下了我与它的个人关系：https://lobste.rs/s/unpaan/arborium_is_ai_slopware_should_not_be#c_twqzh3。 9 henrycatalinismith 2026-11-11 14:33:05 嗯，不幸的是这并不太令人意外。我认为这是一种常见的不成文的伦理框架：如果你相当进步和/或在某种程度上处于边缘地位，那么你在本体论上就不可能具有虐待性，因为你那些糟糕的行为其实都只是正义的愤怒和道德勇气，而你收到的任何批评其实都不过是特权式的语气警察。我以前也认同这种思维方式，后来已经走出来了，但它在当下的反 AI 活动圈子里尤其流行。前几天我其实写下了自己的一些想法。公开表现出恶意或许会让你一时感到活着，但它与任何有意义的现实目标都相冲突，而且在反 AI 空间里这已经被如此正常化，以至于我得出结论：整件事更多是在宣泄对不想要的改变的集体悲伤，而非实现任何具体的东西。 ~ hsivonen 2026-11-12 01:10:03 我觉得有趣的是，一些似乎喜欢这份清单的人，如果别人不使用类似“发自我的 iPhone”那样的 LLM 广告/免责声明来披露 LLM 的使用，他们就会不高兴，但这份清单却附带了这样的说明：“这份清单不是用来骚扰其他开源开发者的资源。如果你希望从另一个项目倡导‘No AI’政策，我们要求以尊重和建设性的方式进行（并且不要提及这份清单）。”

这份清单以前叫 Open Slopware。我在这里写下了我与它的个人关系：https://lobste.rs/s/unpaan/arborium_is_ai_slopware_should_not_be#c_twqzh3。

• 9 henrycatalinismith 2026-11-11 14:33:05 嗯，不幸的是这并不太令人意外。我认为这是一种常见的不成文的伦理框架：如果你相当进步和/或在某种程度上处于边缘地位，那么你在本体论上就不可能具有虐待性，因为你那些糟糕的行为其实都只是正义的愤怒和道德勇气，而你收到的任何批评其实都不过是特权式的语气警察。我以前也认同这种思维方式，后来已经走出来了，但它在当下的反 AI 活动圈子里尤其流行。前几天我其实写下了自己的一些想法。公开表现出恶意或许会让你一时感到活着，但它与任何有意义的现实目标都相冲突，而且在反 AI 空间里这已经被如此正常化，以至于我得出结论：整件事更多是在宣泄对不想要的改变的集体悲伤，而非实现任何具体的东西。

嗯，不幸的是这并不太令人意外。

我认为这是一种常见的不成文的伦理框架：如果你相当进步和/或在某种程度上处于边缘地位，那么你在本体论上就不可能具有虐待性，因为你那些糟糕的行为其实都只是正义的愤怒和道德勇气，而你收到的任何批评其实都不过是特权式的语气警察。我以前也认同这种思维方式，后来已经走出来了，但它在当下的反 AI 活动圈子里尤其流行。

前几天我其实写下了自己的一些想法。

过于刻薄也许会让你一时感到痛快，但这与任何有意义的现实目标都相冲突，而且在反 AI 的圈子里这种做法被如此正常化，以至于我得出结论：整件事更多是在宣泄对不想要的改变的集体悲伤，而不是在达成任何具体的东西。

• ~ hsivonen 2026-11-12 01:10:03 我觉得有意思的是，一些似乎喜欢这份名单的人，如果别人不使用类似“sent from my iPhone”那样的 LLM 广告/免责声明来披露 LLM 使用情况，他们就会不高兴；但这份名单本身却带着这样一条说明：“本名单不是用来骚扰其他开源开发者的资源。如果你想在另一个项目中倡导‘No AI’政策，我们要求以尊重和建设性的方式进行（并且不要提及本名单）。”

我觉得有意思的是，一些似乎喜欢这份名单的人，如果别人不使用类似“sent from my iPhone”那样的 LLM 广告/免责声明来披露 LLM 使用情况，他们就会不高兴；但这份名单本身却带着这样一条说明：“本名单不是用来骚扰其他开源开发者的资源。如果你想在另一个项目中倡导‘No AI’政策，我们要求以尊重和建设性的方式进行（并且不要提及本名单）。”

• ~ brn 2026-11-11 07:58:14 谢谢，我之前不知道这份名单，不过它列出的替代方案非常少（我不是说这些方案存在，但它几乎让人显得更加无助）。9 nate30480 2026-11-11 08:12:45 它还链接到其他资源，但我认为 https://noai.starlightnet.work/list.html 可能主要就是你要找的。~ dkl 2026-11-11 09:50:31 过去几个月我一直在研究这份名单。主要结果之一是我回到了 Emacs。这不是我第一次用它，但我发现如今要把它弄成可用的、类似 IDE 的状态比以往容易得多。我过去用的大部分东西在 Emacs 内部都有替代方案。我发现，一旦克服了最初的迟疑，它提供的那种以人为本、可塑的环境，正是我此前没意识到自己缺失的。8 jzb 2026-11-11 13:07:50 主要结果之一是我回到了 Emacs。哎哟。我有些坏消息要告诉你…… ~ dkl 2026-11-11 15:49:51 我看不太懂你链接的那篇文章，但我注意到它链接到一个可能满足我要求的 Emacs 分支，所以我觉得你其实给我带来了好消息。

谢谢，我之前不知道这份名单，不过它列出的替代方案非常少（我不是说这些方案存在，但它几乎让人显得更加无助）。

• 9 nate30480 2026-11-11 08:12:45 它还链接到其他资源，但我认为 https://noai.starlightnet.work/list.html 可能主要就是你要找的。

它还链接到其他资源，但我认为 https://noai.starlightnet.work/list.html 可能主要就是你要找的。

• ~ dkl 2026-11-11 09:50:31 过去几个月我一直在研究这份名单。主要结果之一是我回到了 Emacs。这不是我第一次用它，但我发现如今要把它弄成可用的、类似 IDE 的状态比以往容易得多。我过去用的大部分东西在 Emacs 内部都有替代方案。我发现，一旦克服了最初的迟疑，它提供的那种以人为本、可塑的环境，正是我此前没意识到自己缺失的。8 jzb 2026-11-11 13:07:50 主要结果之一是我回到了 Emacs。哎哟。我有些坏消息要告诉你…… ~ dkl 2026-11-11 15:49:51 我看不太懂你链接的那篇文章，但我注意到它链接到一个可能满足我要求的 Emacs 分支，所以我觉得你其实给我带来了好消息。

我过去几个月一直在研究这份清单。主要结果之一是我重新用回了 Emacs。这不是我第一次用它，但我发现如今要把它配置成接近 IDE 的工作状态比以往任何时候都容易。我过去常用的大部分东西，在 Emacs 内部都有替代方案。我发现，一旦克服了最初的抵触情绪，它提供的那种以人为本、可塑性强的工作环境，正是我此前没有意识到自己缺失的。

• 8 jzb 2026-11-11 13:07:50 主要结果之一是我重新用回了 Emacs。哎哟。我这儿有些坏消息要告诉你…… ~ dkl 2026-11-11 15:49:51 我看不太懂你链接的那篇文章，但我注意到它链接到了一个可能满足我需求的 Emacs 分支，所以我觉得你其实给我带来的是好消息。

主要结果之一是我重新用回了 Emacs。

哎哟。我这儿有些坏消息要告诉你……

• ~ dkl 2026-11-11 15:49:51 我看不太懂你链接的那篇文章，但我注意到它链接到了一个可能满足我需求的 Emacs 分支，所以我觉得你其实给我带来的是好消息。

我看不太懂你链接的那篇文章，但我注意到它链接到了一个可能满足我需求的 Emacs 分支，所以我觉得你其实给我带来的是好消息。

• ~ hsivonen 2026-11-12 01:30:02 通过列出最后一个“未受污染”的提交并列出各个分支，这份清单似乎在鼓励使用存在已知安全漏洞的版本。上游很可能存在由 LLM 发现并披露的安全漏洞。除了运行带有已知漏洞的软件来配合这份清单之外，对于安全性还有任何其他设想吗？ ~ kolja 2026-11-12 02:46:22 嗯，我们并没有、也无法真正为此做规划，对吧？有些项目正在被分支出去，并且自己在修复 bug，但突然之间，对于那些希望软件尽可能来源合乎道德的人来说，有太多项目不再可用了。幸运的是，很多软件只是在本地运行，所以如果你只处理自己的文件，基本上就不会受到攻击，只需忍受偶尔出现的一个 bug。但这令人心碎。

通过列出最后一个“未受污染”的提交并列出各个分支，这份清单似乎在鼓励使用存在已知安全漏洞的版本。上游很可能存在由 LLM 发现并披露的安全漏洞。除了运行带有已知漏洞的软件来配合这份清单之外，对于安全性还有任何其他设想吗？

• ~ kolja 2026-11-12 02:46:22 嗯，我们并没有、也无法真正为此做规划，对吧？有些项目正在被分支出去，并且自己在修复 bug，但突然之间，对于那些希望软件尽可能来源合乎道德的人来说，有太多项目不再可用了。幸运的是，很多软件只是在本地运行，所以如果你只处理自己的文件，基本上就不会受到攻击，只需忍受偶尔出现的一个 bug。但这令人心碎。

嗯，我们并没有、也无法真正为此做规划，对吧？有些项目正在被分支出去，并且自己在修复 bug，但突然之间，对于那些希望软件尽可能来源合乎道德的人来说，有太多项目不再可用了。幸运的是，很多软件只是在本地运行，所以如果你只处理自己的文件，基本上就不会受到攻击，只需忍受偶尔出现的一个 bug。但这令人心碎。

• 18 dustyweb 2026-11-11 08:48:03 嗯，我在那里工作，我们既是一个 FOSS 非营利组织，也在 Spritely Institute 有坚定的禁止生成式 AI 政策，并且还做相当酷的去中心化网络技术

嗯，我在那里工作，我们既是一个 FOSS 非营利组织，也在 Spritely Institute 有坚定的禁止生成式 AI 政策，并且还做相当酷的去中心化网络技术

• 10 bsandro 2026-11-11 11:06:45 最近为此做了 https://braincoded.software —— 它不是“反”，只是“不”。目前除了 IRC 频道之外没什么内容，但我正在做一个仅限邀请的小型链接聚合器，以及面向成员的公开 git 和 cvs 仓库。 ~ stephenr 2026-11-11 15:27:19 Git 和 Cvs 确实是个选择。我理解提供 Git 的替代品。我觉得 mercurial 值得比现在多得多的喜爱。但为什么偏偏是 Cvs，而不是其他众多非 Git 的替代品？ ~ bsandro 2026-11-11 15:57:59 老实说我一直更喜欢 Mercurial 而不是 git，但某种程度上放弃了，把所有东西都迁到了 git，现在两个都用感觉很奇怪，尤其是 hg 相比 git 并没有给我任何可移植性上的好处。CVS 是用于某些时候和某些场景的，比如你想在某个更老的系统上使用版本控制系统，像老式 macintosh system7 或 9（尽管 @jcs 为它做了一个非常好的工具——Amend，甚至还有 amendhub.com！），或者 *DOS。

最近为此做了 https://braincoded.software —— 它不是“反”，只是“不”。

目前除了 IRC 频道之外没什么内容，但我正在做一个仅限邀请的小型链接聚合器，以及面向成员的公开 git 和 cvs 仓库。

• ~ stephenr 2026-11-11 15:27:19 Git 和 Cvs 确实是个选择。我理解提供 Git 的替代品。我觉得 mercurial 值得比现在多得多的喜爱。但为什么偏偏是 Cvs，而不是其他众多非 Git 的替代品？ ~ bsandro 2026-11-11 15:57:59 老实说我一直更喜欢 Mercurial 而不是 git，但某种程度上放弃了，把所有东西都迁到了 git，现在两个都用感觉很奇怪，尤其是 hg 相比 git 并没有给我任何可移植性上的好处。CVS 是用于某些时候和某些场景的，比如你想在某个更老的系统上使用版本控制系统，像老式 macintosh system7 或 9（尽管 @jcs 为它做了一个非常好的工具——Amend，甚至还有 amendhub.com！），或者 *DOS。

Git 和 Cvs 确实是个选择。

我理解提供 Git 的替代品。我觉得 mercurial 值得比现在多得多的喜爱。

但为什么偏偏是 Cvs，而不是其他众多非 Git 的替代品？

• ~ bsandro 2026-11-11 15:57:59 老实说我一直更喜欢 Mercurial 而不是 git，但某种程度上放弃了，把所有东西都迁到了 git，现在两个都用感觉很奇怪，尤其是 hg 相比 git 并没有给我任何可移植性上的好处。CVS 是用于某些时候和某些场景的，比如你想在某个更老的系统上使用版本控制系统，像老式 macintosh system7 或 9（尽管 @jcs 为它做了一个非常好的工具——Amend，甚至还有 amendhub.com！），或者 *DOS。

老实说我一直更喜欢 Mercurial 而不是 git，但某种程度上放弃了，把所有东西都迁到了 git，现在两个都用感觉很奇怪，尤其是 hg 相比 git 并没有给我任何可移植性上的好处。

CVS 是用于某些时候和某些场景的，比如你想在某个更老的系统上使用版本控制系统，像老式 macintosh system7 或 9（尽管 @jcs 为它做了一个非常好的工具——Amend，甚至还有 amendhub.com！），或者 *DOS。

• 9 hoistbypetard 2026-11-11 11:35:48 我们中有几个人想避开它，或者至少对何时谈论它非常挑剔，我们聚集在 imtiredboss.org。我们正在收集一些列表和链接，还有几个不涉及生成式 AI 的讨论空间。

我们中有几个人想避开它，或者至少对何时谈论它非常挑剔，我们聚集在 imtiredboss.org。我们正在收集一些列表和链接，还有几个不涉及生成式 AI 的讨论空间。

• 7 isagalaev 2026-11-11 12:23:09 还有一个：https://codeberg.org/brib/slopfree-software-index

还有一个：https://codeberg.org/brib/slopfree-software-index

• ~ bbbhltz 2026-11-11 08:09:56 https://noailist.org/

https://noailist.org/

• ~ dsschnau 2026-11-11 08:11:42 “No AI” Webring 与此相关——https://baccyflap.com/noai/ ~ brn 2026-11-11 09:23:55 谢谢，我的博客就是其中一部分！😊

文章标题：你知道哪些“No AI”应用/公司/资源？

“No AI” Webring 与此相关——https://baccyflap.com/noai/

• ~ brn 2026-11-11 09:23:55 谢谢，我的博客是其中一员！😊

谢谢，我的博客是其中一员！😊

• ~ sjamaan 2026-11-11 08:43:43 与 rebel tech alliance 类似，还有一个 trustworthy technology group。他们有一个 Zulip 聊天室，你可以加入进一步讨论。

与 rebel tech alliance 类似，还有一个 trustworthy technology group。他们有一个 Zulip 聊天室，你可以加入进一步讨论。

• ~ th0ma5 2026-11-11 13:19:55 这是一位学者收集的资料：https://olivia.science/ai/

这是一位学者收集的资料：https://olivia.science/ai/

• ~ jakehamilton 2026-11-11 16:35:58 我正在组建一个软件集体，其核心原则之一就是“anti-ai”：https://conflagrate.software/ 我的想法是让它成为一个安全、愉快的空间，供人们创作和协作。

我正在组建一个软件集体，其核心原则之一就是“anti-ai”：https://conflagrate.software/

我的想法是让它成为一个安全、愉快的空间，供人们创作和协作。

• ~ Zurga 2026-11-11 08:50:02 你是否知道，你链接的那个资源是用一个站点构建器制作的，而该构建器在产品主视觉的第二句话中就提到了 AI？该资源是手工制作的，但离 AI 并不远。5 brn 2026-11-11 08:54:45 观察得好，但他们是在它“AI-powered”之前使用的，这在一定程度上说明了我试图寻找替代方案时所面临的困难。~ Zurga 2026-11-11 09:18:41 是的，sloppification 无处不在。曾经正常的产品现在都有了 AI……

你是否知道，你链接的那个资源是用一个站点构建器制作的，而该构建器在产品主视觉的第二句话中就提到了 AI？该资源是手工制作的，但离 AI 并不远。

• 5 brn 2026-11-11 08:54:45 观察得好，但他们是在它“AI-powered”之前使用的，这在一定程度上说明了我试图寻找替代方案时所面临的困难。~ Zurga 2026-11-11 09:18:41 是的，sloppification 无处不在。曾经正常的产品现在都有了 AI……

观察得好，但他们是在它“AI-powered”之前使用的，这在一定程度上说明了我试图寻找替代方案时所面临的困难。

• ~ Zurga 2026-11-11 09:18:41 是的，sloppification 无处不在。曾经正常的产品现在都有了 AI……

是的，sloppification 无处不在。曾经正常的产品现在都有了 AI……

• ~ hwj 2026-11-12 01:11:11 最近，我在为 Go 挑选一个 SQLite 库。看起来 https://github.com/mattn/go-sqlite3/ 没有使用 AI。

最近，我在为 Go 挑选一个 SQLite 库。看起来 https://github.com/mattn/go-sqlite3/ 没有使用 AI。

• ~ ItsFinishd 2026-11-11 17:01:41 与其回避 AI，为什么不选择负责任地使用 AI 呢？LLM 能加快速度，但代价是失去正确性，而我认为由于 LLM 的工作方式——统计匹配而非逻辑/直觉证明（后者正是人类擅长的）——人们很难轻易保证正确性。为了兼得两者之长，你应该把 AI 用于更小、更容易审查的任务，然后用这些成果（同样可以借助或不借助 AI）去构建更复杂的产品。我不介意不必亲手写出一大堆代码，因为 AI 能写出几乎一模一样的代码。QA 和验证过程仍然是人的工作，而且这大概本来就是开发者花费大部分时间的地方。实际编码所占的时间不超过 20%。在我看来，放弃 LLM 这样的工具是个坏主意，如果它能帮我们节省时间并提高产出质量，那就随它去吧。17 seb 2026-11-11 17:18:35 来自你正在评论的帖子：我并不想发起一场关于 AI 是好是坏、有没有价值，或者谁支持谁反对的讨论，我只想要推广这种情绪/立场的链接和/或社区。在关于/面向不喜欢、不想使用 AI 的人的帖子下，发表诸如“你有没有考虑过 AI 其实并不全是坏事？”之类的评论，是适得其反的，而且说实话真的让人精疲力竭。13 khairo 2026-11-11 17:05:29 我就是不想用它。它不吸引我。我也不想用那些用过它的东西。我不在乎它是否“效果更好”或“更高效”。做个 luddite 也没关系。

与其回避 AI，为什么不选择负责任地使用 AI 呢？LLM 能加快速度，但代价是失去正确性，而我认为由于 LLM 的工作方式——统计匹配而非逻辑/直觉证明（后者正是人类擅长的）——人们很难轻易保证正确性。为了兼得两者之长，你应该把 AI 用于更小、更容易审查的任务，然后用这些成果（同样可以借助或不借助 AI）去构建更复杂的产品。

我不介意不必亲手写出一大堆代码，因为 AI 能写出几乎一模一样的代码。QA 和验证过程仍然是人的工作，而且这大概本来就是开发者花费大部分时间的地方。实际编码所占的时间不超过 20%。

在我看来，放弃 LLM 这样的工具是个坏主意，如果它能帮我们节省时间并提高产出质量，那就随它去吧。

• 17 seb 2026-11-11 17:18:35 来自你正在评论的帖子：我并不想发起一场关于 AI 是好是坏、有没有价值，或者谁支持谁反对的讨论，我只想要推广这种情绪/立场的链接和/或社区。在关于/面向不喜欢、不想使用 AI 的人的帖子下，发表诸如“你有没有考虑过 AI 其实并不全是坏事？”之类的评论，是适得其反的，而且说实话真的让人精疲力竭。

来自你正在评论的帖子：

我并不想发起一场关于 AI 是好是坏、有没有价值，或者谁支持谁反对的讨论，我只想要推广这种情绪/立场的链接和/或社区。

在关于/面向不喜欢、不想使用 AI 的人的帖子下，发表诸如“你有没有考虑过 AI 其实并不全是坏事？”之类的评论，是适得其反的，而且说实话真的让人精疲力竭。

• 13 khairo 2026-11-11 17:05:29 我就是不想用它。它不吸引我。我也不想用那些用过它的东西。我不在乎它是否“效果更好”或“更高效”。做个 luddite 也没关系。

我就是不想用它。它不吸引我。我也不想用那些用过它的东西。我不在乎它是否“效果更好”或“更高效”。做个 luddite 也没关系。