这是一个由社区驱动的uBlock Origin黑名单，旨在阻止主要使用人工智能生成内容的网站，这些网站通常质量低下，充斥着广告的“内容农场”。创建者手动添加在浏览过程中遇到的，除了搜索引擎优化和潜在的错误信息之外几乎没有价值的网站。 该列表侧重于阻止人工智能生成垃圾信息的*来源*，无论是整个域名还是像Medium这样的平台上的特定博客。欢迎通过pull requests或issue报告进行贡献，特别是为了扩大覆盖范围，超越创建者自己的发现（目前偏向意大利网站）。 该项目避免使用自动检测，因为可靠地识别人工智能生成的内容具有困难。相反，它依赖于识别诸如过于冗长的介绍、通用标题（“终极指南”）、缺乏来源、过多的推荐链接以及快速发布大量文章等模式。目标不是阻止人工智能工具本身，而是过滤掉这些农场生产的低质量、潜在有害的内容。 该列表可在[https://raw.githubusercontent.com/alvi-se/ai-ublock-blacklist/master/list.txt](https://raw.githubusercontent.com/alvi-se/ai-ublock-blacklist/master/list.txt)处获取，以便导入到uBlock Origin中。
每日HackerNews RSS
这个Hacker News讨论围绕一个新的uBlock Origin黑名单（github.com/laylavish/uBlockOrigin-HUGE-AI-Blocklist），旨在专门针对内容农场和低质量的AI生成内容。它被认为是一个比更广泛的“反AI”黑名单更集中的替代方案。
用户们争论AI写作辅助的价值，一些人认为这凸显了“技能问题”，并更喜欢人类写作中不完美但具有个性的文字——即使翻译质量不高。另一些人承认他们使用像Grammarly这样的工具，正因为他们意识到自己写作方面的弱点。
对话中承认该列表可能针对的是大规模生产的AI内容，而不是帮助个人进行微小的写作改进。Reddit上的一个讨论（帖子中链接）详细介绍了用于识别黑名单收录网站的方法。
## 金融领域的转变：从界面操作到系统设计 多年来，作者——一位拥有软件开发背景的注册会计师——认为专业网络是通过实际工作建立的。然而，一场与软件发展相呼应的转变正在影响金融领域。正如人工智能已将编码从注重语法的操作转变为高级指导，它也即将重新定义金融角色的定位。 作者的经验证明了这种发展：人工智能最初辅助编码任务，然后管理项目，现在可以根据提供的规范自主构建和测试软件。同样的模式正在金融领域出现，在人工智能代理自动化这些任务后，精通像Excel这样的界面操作的专业知识变得价值降低。 新的杠杆在于设计能够快速提供*可审计的真相*的系统——利用与核心系统连接的人工智能代理自动化工作流程，例如发票验证和对账。这不仅仅是关于聊天机器人，而是关于结构化的、类似团队的人工智能部署。 未来取决于构建“情境系统”——在数据*周围*构建关键决策信息——以及为人工智能代理建立健全的权限控制，从而模拟人类治理。新兴的角色不是提示工程，而是管理人工智能劳动力，并构建优先考虑速度*和*责任的工作流程。
这次Hacker News的讨论集中在对当前人工智能在软件开发领域炒作的怀疑态度上。一位用户表达了对依赖人工智能生成的代码用于生产的担忧，引用了人工智能对C语言中整数截断的理解错误导致Python脚本出现微妙错误。这引发了关于人工智能编写代码中潜在的未被发现错误的争论，尤其是在金融等关键领域。
许多评论者表达了相同的观点，将宣传人工智能在软件方面应用的的文章称为“人工智能垃圾”，并批评它们重复、低质量的写作——很可能也是由人工智能生成的。核心问题在于，虽然人工智能可以用于简单的任务，但它缺乏复杂、生产级代码所需的可靠性和细致理解，并且其使用可能受到成本削减压力的驱动，而非真正的能力。
## 放弃云服务，使用个人 Git 同步 作者寻求一种在设备之间同步个人 Git 仓库（点文件、宏等）的方法，*无需*依赖 GitHub 等云服务，这些服务提供的功能过多且引发了隐私问题。与其探索 GitHub 的替代方案，他们意识到利用 Git 核心功能可以实现更简单的解决方案。 Git 仓库本质上是文件*加上*一个包含整个历史记录的 `.git` 文件夹。这个 `.git` 文件夹可以被复制和同步，但使用 Git 的 `push` 和 `pull` 命令更安全。关键在于利用“裸”仓库——仅包含 `.git` 历史记录，没有工作目录——作为中央同步点。 作者的设置包括一台始终开启的家用台式机，并使用外部驱动器托管裸仓库。然后，每个设备从该中央位置克隆，并推送到该中央位置，通过 SSH 实现。这消除了第三方托管，并提供了完全的控制权。 这种方法优先考虑简单性，模仿了代码的“静态网站”理念——专注于文件同步，而无需不必要的功能。作者还反思了广泛分享个人、未整理代码的价值有限，现在更倾向于专注于、文档完善的公共仓库。
## Git 超越 GitHub：回归去中心化
一篇关于同步 Git 仓库，而无需依赖 GitHub 等平台 的文章引发了 Hacker News 的讨论，突显了 Git 最初的去中心化设计。许多评论者回忆起早期使用 Git 的日子（大约 2008-2011 年），当时开发者通过 SSH 直接从彼此的机器上拉取代码，展示了一种实用且高效的工作流程。
对话指出 GitHub 如何成功地“占领了人们的思想”，导致许多人将该平台等同于 Git 本身，甚至缺乏基本的 Git 命令行理解。用户分享了替代方法，例如使用 USB 驱动器或 Tailscale 进行直接同步，强调了 Git 的灵活性。
一些评论者提倡自托管解决方案，如 Forgejo，或利用裸仓库和 `git mirror` 和 `pgit.pico.sh` 等工具。 还有人提到了鲜为人知的功能，例如通过 GitHub 进行 SSH 密钥管理，以及通过电子邮件贡献代码的能力——这种方法至今仍用于 Linux 内核开发。 总体情绪表明，人们越来越有兴趣夺回控制权并减少对集中式 Git 托管服务的依赖。
arXivLabs是一个框架，允许合作者直接在我们的网站上开发和分享新的arXiv功能。个人和与arXivLabs合作的组织都拥抱并接受了我们开放、社群、卓越和用户数据隐私的价值观。arXiv致力于这些价值观，并且只与坚持这些价值观的合作伙伴合作。您是否有为arXiv社群增加价值的项目想法？了解更多关于arXivLabs的信息。
一篇最近发表的研究论文（arxiv.org）强调了大型语言模型（LLM）在推理方面存在显著缺陷，引发了Hacker News上的讨论。核心论点，与评论者相呼应，是人们常常*高估* LLM 的能力，并将人类特征赋予这些系统。
该论文表明，LLM 在需要基本推理技能的任务上遇到困难——即使是幼儿也能做到的事情，比如准确计数——以及复杂的道德推理领域。这表明它们离通用人工智能（AGI）还很遥远。
这些失败源于 LLM 作为下一个词预测器的基本性质；它们擅长*表现出* 智能，但缺乏真正的理解。一个 GitHub 仓库（提供链接）汇集了这些失败的例子，提供了一个资源来降低期望，并使对 LLM 能力的认知保持客观。 基本上，现在还不要指望贾维斯。
Coccinelle 是一种用于对 C 代码执行复杂、保留风格的源代码到源代码转换的工具，能够实现重构和自动化代码修改。它通过 `spatch` 脚本访问，可以从源代码安装（参见 `install.txt`）或通过预编译包安装（[https://coccinelle.gitlabpages.inria.fr/website/download.html](https://coccinelle.gitlabpages.inria.fr/website/download.html)）。 Coccinelle 也可以直接从其下载目录运行，可能需要设置环境变量（`source env.sh` 或 `source env.csh`）。提供了一个测试用例：`spatch --sp-file demos/simple.cocci demos/simple.c -o /tmp/new_simple.c`。字节码版本需要 OCaml。 在 Debian/Ubuntu 下的依赖项包括 `ocaml-native-compilers` 或 `ocaml-nox` 用于 OCaml 脚本，以及 `python3-dev` 用于 Python 脚本（仅运行时）。 欢迎贡献，需要一行“Signed-off-by”声明，以证明贡献者有权以开源许可证提交代码，镜像 Linux 内核的贡献指南。运行 `make docs` 后可以获得详细文档。
## Coccinelle：一种强大但被低估的工具
最近的 Hacker News 讨论强调了 Coccinelle，这是一种代码的源到源转换工具，尤其因其在 Linux 内核中的实用性而备受推崇。它由 Julia Lawall 创建，尽管缺乏传统的学术认可，但被赞为一种非常实用的工具。用户指出，它的有效性超过了更复杂的形式化方法，且资源消耗更少，更具实用性。
虽然功能强大，但 Coccinelle 学习曲线陡峭，文档也可能具有挑战性。一些评论员提到了 `ast-grep` 和 `OpenRewrite` 等替代方案，但指出 Coccinelle 处理宏展开等复杂情况的独特能力。
对话还涉及了 BABLR 等较新的项目，旨在采用更现代、开放的方式进行语义补丁，以及构建健壮代码转换工具的挑战。最终，讨论强调了实用工具的价值，即使这些工具缺乏深入的理论基础，以及为了促进更广泛的应用而改进文档的必要性。
## std::shared_mutex: C++ 中的读写锁
本文探讨了 `std::shared_mutex`，这是 C++17 的一项特性，为主要读取的数据提供了改进的并发性。与提供独占访问的 `std::mutex` 不同，`std::shared_mutex` 允许多个读取者同时访问资源，同时确保写入者拥有独占访问权。
其核心优势在于，在频繁读取和不频繁写入的场景中（例如缓存、配置数据或统计信息），可以提高吞吐量。基准测试表明，在读取密集型工作负载中使用 `std::shared_mutex` 代替 `std::mutex` 可以显著提高性能（在某个示例中，运行时从 285 毫秒减少到 102 毫秒）。
关键注意事项包括避免递归锁定以及无法在潜在死锁的情况下将共享锁升级为独占锁。虽然 `std::shared_mutex` 会引入一些开销，但它仍然是一个有价值的工具，尤其是在优先考虑简单性时。
尽管 C++20 及更高版本引入了新的并发特性（例如 `std::jthread` 和信号量），但 `std::shared_mutex` 仍然是有效地管理主要进行读取操作的共享状态的实用解决方案。
## 理解 C++17 的 `std::shared_mutex` - Hacker News 讨论总结
这次 Hacker News 讨论围绕 C++17 中引入的 `std::shared_mutex`，这是一种读者-写者锁，专为大量读者和少量写者的情况设计。用户将其与 Rust 的 `RwLock` 以及更广泛的读者-写者锁概念进行比较。
一个关键点是 `shared_mutex` 不会与较低级别的并发原语（如原子操作、条件变量或 RCU（安全内存回收））*竞争*。虽然 RCU 有时可以替代 `shared_mutex` + 状态方法，但 `shared_mutex` 提供了同步机制，保证所有线程在写入后都能观察到新值。
对话深入探讨了性能方面的考虑。RW 锁可能会受到缓存争用的影响，但存在可以缓解这种情况的实现。还建议使用 seqlock 和 hazard pointer 等替代方案，因为没有一种并发原语是普遍最优的。
用户还讨论了 C++ 和 Rust 标准库锁定 API 的局限性，指出缺乏细粒度控制（例如设置读者/写者优先级），并且通常需要依赖外部 crate 或自定义实现来满足特定用例。
2026年2月，Andrej Karpathy 强调了一种新的AI发展趋势，他称之为“爪子”（Claws）。在LLM代理的基础上，“爪子”代表着更进一步的复杂性，改进了编排、调度、上下文管理和持久性。 本质上，“爪子”是设计在个人硬件上运行并通过消息进行通信的AI代理系统。Karpathy 注意到小型、开源“爪子”实现激增，例如 NanoClaw（仅4000行代码）以及 Nanobot 和 Zeroclaw 等。 他认为“爪子”将成为这个类别的定义术语，并对AI堆栈中这一新层的潜力感到兴奋，认为它是从LLM到LLM代理的自然演进。 这种受欢迎程度显而易见，据报道，Mac Minis 正在迅速售罄，许多爱好者渴望进行实验。
## “爪子”：一种新的AI代理方法
Hacker News上的一讨论围绕着Andrej Karpathy对“爪子”（Claws）的看法——一种由Peter Steinberger最初提出的新型AI代理概念。与专注于工具使用的传统代理不同，“爪子”被描述为利用LLM进行推理的*持久进程*，通过计划任务和代理间通信运作。
本质上，“爪子”是一种在计划下运行的自主代理，监控收件箱或其他触发器以执行操作，可能可以访问个人凭据。一位评论员将其比作“代理的cron”。虽然OpenClaw等工具展示了这种方法的可行性，但用户指出Pantalk等现有解决方案可以在没有它的情况下实现类似的功能。
鉴于这些代理可能拥有的访问权限，即使使用容器化，也存在数据安全方面的担忧。对话还涉及潜在的应用，例如电商机器人（“圣诞爪子”），以及对这些自主代理标准化接口和市场化的需求。这场讨论凸显了“AI污染”日益严重的趋势，以及仔细考虑其影响的必要性。
## 云边测试床经验：etcd 与存储性能 使用 Karmada 构建云边连续统演示，用于 MLSysOps（一个动态应用部署框架）时，揭示了一个关于分布式系统的关键经验：**etcd 对存储延迟非常敏感。** 该演示旨在展示基于性能遥测数据，实时对象检测从树莓派切换到 Jetson AGX Orin。然而，运行在 NUC 虚拟机上的 Karmada 集群频繁出现 Pod 崩溃。经过大量调查，问题并非与应用程序相关，而是源于**不稳定的 I/O 性能**影响了 etcd，Karmada 的状态存储。 etcd 的强一致性需要快速的 fsync 操作，而由于 NUC 上的共享存储，这些操作失败了。 增加超时阈值等解决方案不足以解决问题；修复涉及**优化 ZFS 设置**（禁用同步写入，启用 LZ4 压缩，禁用 atime，并调整 recordsize）以优先考虑速度。 这次经验强调了**优先考虑 etcd 的存储性能**的重要性。 监控 `etcd_disk_wal_fsync_duration_seconds` 等指标并主动基准测试存储至关重要。 虽然专用的存储对于生产环境来说是理想的，但仔细调整可以稳定演示环境。最终，团队成功演示了动态工作负载的切换，但只有在解决了这个基本基础设施依赖之后才得以实现。
启用 JavaScript 和 Cookie 以继续。
最近一篇来自The Document Foundation (LibreOffice) 的博文批评OnlyOffice与微软合作，声称这种合作旨在将用户锁定在微软生态系统中，尽管OnlyOffice声称是开源的。
Hacker News 的讨论强调了关于“虚假开源”软件的争论。虽然承认LibreOffice强大的使命，但一些用户更喜欢OnlyOffice，因为它具有更好的兼容性和用户界面，认为LibreOffice的界面过时，DOCX/XLSX格式存在问题。
然而，LibreOffice开发者正在积极努力提高与微软格式的兼容性，并鼓励用户通过他们的错误追踪器报告问题。 还有人指出，近年来LibreOffice在微软Office支持方面取得了显著改进，而OpenOffice则相对停滞不前。
## 24 Hour Fitness 无法使用的退订链接
24 Hour Fitness 因其营销邮件中持续无法使用的退订链接面临潜在法律问题，这个问题早在2019年就被报告。点击该链接会显示西班牙语错误信息，源于与OneTrust同意管理平台通信时，JavaScript代码中关于内容类型标头的一行错误——讽刺的是，OneTrust是一家专注于法规遵从的公司。
尽管该问题于2025年11月被报告，并提供了简单的修复方案，但至今仍未解决，导致作者收到了超过40封不想要的营销邮件。这违反了CAN-SPAM法案，该法案要求提供可用的退出机制，类似违规行为的近期罚款已达数百万美元。
作者对持续不断的无关营销“精神攻击”感到沮丧，因此自行构建了一个可用的退订页面作为替代方案。他们呼吁24 Hour Fitness的工程团队中的某人实施这一行修复代码，并为所有用户解决该问题。
一名 Hacker News 用户“daem”报告修复了 24 Hour Fitness 营销邮件中失效的退订链接。据称该公司阻止用户选择退出垃圾邮件。
评论区的讨论引发了对退订链接有效性的担忧， “imiric” 认为公司经常只是为了满足法律要求而使用它们，甚至可能使问题恶化，潜在地将数据出售给更多的垃圾邮件发送者。
“imiric” 提倡一种更强大的解决方案：使用自定义电子邮件域名，并为每个公司创建唯一的地址。这样可以在收到不需要的电子邮件时轻松阻止发件人，从而完全绕过不可靠的退订流程。 另一位用户“mattlondon” 指出 24 Hour Fitness 的设置可能存在服务器端安全问题（CORS）。