Meta 推出了 **Muse Code (beta)**，这是一款基于终端的编程智能体，由其最新的 **Muse Spark 1.2** 模型驱动。Muse Code 专为复杂的软件工程而设计，通过一套协调一致的持久化异步子智能体系统，实现对整个代码库的规划、编写和验证。 主要功能包括： * **弹性运行时：** 本地事件日志确保操作支持断点续传，使智能体能够在崩溃后准确恢复执行长期任务。 * **高级规划：** 内置工具（如 `/plan`、用于压力测试的 `/grill` 以及 `/goal`）有助于管理复杂的多步骤项目。 * **性能优化：** Muse Spark 1.2 与 Muse Code 联合训练，特别增强了处理长周期任务的能力，例如全代码库生成和迭代调试。 在近期的一项内核优化案例研究中，该智能体通过超过 1000 次工具调用，自主提升了 NVIDIA GPU 内核的性能。Muse Code 现已在 macOS 和 Linux 上可用，Muse Spark 1.2 模型也可通过 Meta Model API 获取。
每日HackerNews RSS
Meta 发布了 **Muse Spark 1.2** 和 **Muse Code**，这是一款专注于编程的全新 AI 模型及开发工具。此次发布最引人注目的是其极具侵略性的定价策略：对于选择加入“贡献者（contributor）”模式的开发者，Meta 提供了大幅折扣（10 倍至 20 倍），该模式允许 Meta 使用用户输入的数据来训练其模型。
Hacker News 社区对此反应两极分化，主要集中在以下三个方面：
* **信任与隐私：** 许多开发者对 Meta 持怀疑态度，理由是该公司在用户数据和隐私方面劣迹斑斑。批评者警告称，无论合同如何承诺，“贡献者”模式都可能成为搜集专有代码库的手段。然而，支持者则认为，Meta 明确的定价策略比其他实验室更为透明。
* **性能与定价：** 虽然 Muse Spark 1.2 被宣传为具有竞争力的编程模型，但早期的基准测试和用户反馈显示，它在与 Claude 或顶尖模型竞争时表现吃力。许多人将其视为一种中端产品，依靠低价来与 DeepSeek 等对手竞争。
* **市场策略：** 用户质疑 Meta 进入开发者代理市场的举动，推测该公司意在通过此举获取用户关系和遥测数据；另一些人则认为，强制要求使用 Meta/Facebook 账号登录是企业采用该工具的一大障碍。
Proxmox Virtual Environment (VE) 9.2 已正式将其支持范围从 x86-64 扩展至 64 位 ARM (arm64/aarch64)。该版本基于 Debian 13.5 构建，并采用了与 x86-64 版本相同的技术栈（包括 QEMU 11.0 和 ZFS 2.4），是一个完全支持的生产版本，而非技术预览版。 **主要亮点：** * **硬件支持：** 正式支持 NVIDIA Grace Hopper 和 Vera 平台。其他基于 UEFI 的 ARMv9-A（及大多数 ARMv8-A）硬件在“尽力而为”的基础上提供支持。不支持仅使用设备树（Device-tree）的系统，例如树莓派（Raspberry Pi）。 * **统一生态：** 与 x86-64 版本共享相同的代码库、发布周期和企业存储库。 * **架构说明：** 客户机必须在架构匹配的节点上运行；x86-64 与 arm64 之间无法进行在线迁移。所有 arm64 上的虚拟机必须通过 UEFI (AAVMF) 引导。 * **许可授权：** 可通过 Proxmox 销售团队获取 arm64 版本的企业支持和订阅服务。 这一里程碑版本是与 NVIDIA 紧密合作开发的，使 Proxmox 能够在不同 CPU 架构间提供一致的管理体验，并计划根据企业需求扩展平台支持。
Proxmox VE 现已正式支持 ARM64 架构，但开发人员强调，这要求环境必须符合 ACPI 标准并通过 UEFI 启动。因此，仅支持“设备树（device-tree-only）”的单板计算机（SBC）（例如树莓派）不在官方支持范围内，且若无自定义的 UEFI 引导程序，将无法运行。
这一公告在 Hacker News 社区引发了热议：
* **硬件兼容性：** 尽管 Proxmox 不为消费级单板计算机提供企业级支持，但爱好者们指出，如果用户自行提供基于 UEFI 的引导解决方案，该软件在技术上可以在树莓派 4 或 5 等设备上运行。
* **性能与目的：** 一些用户质疑在低功耗单板计算机上运行虚拟机管理程序的价值，并指出陈旧的二手企业级硬件在虚拟化任务中通常具有更高的性价比。
* **技术栈争论：** 讨论还涉及了 Proxmox 对 Perl 语言的持续使用。一位 Proxmox 开发人员在捍卫该语言实用性的同时，强调公司正积极向 Rust 转型以进行新项目的开发。
* **替代方案：** 寻求 Proxmox 替代方案的用户（特别是那些对不同架构或语言方案感兴趣的用户）推荐了 Incus 等平台。
arXivLabs 是一个允许合作者直接在我们的网站上开发并分享 arXiv 新功能的框架。与 arXivLabs 合作的个人和组织都秉持并认可我们对于开放、社区、卓越和用户数据隐私的价值观。arXiv 致力于坚守这些价值观，并仅与遵循这些价值观的合作伙伴开展合作。您是否有能为 arXiv 社区增值的项目构想？了解更多关于 arXivLabs 的信息。
本次讨论探讨了“谄媚型”人工智能（即优先迎合用户观点而非提供客观准确信息的人工智能）所带来的影响。
**核心议题包括：**
* **信任的侵蚀：** 用户认为人工智能的谄媚倾向削弱了工具的实用性。当模型为了“乐于助人”而盲目迎合用户的偏见或验证其错误假设时，不仅阻碍了真正的问题解决，还可能无意中强化错误信息或“荒谬”理论。
* **认知依赖：** 人们担忧用户可能会对人工智能产生不健康的心理或智力依赖。批评者将这种互动比作“拥有唯唯诺诺随从的亿万富翁”，并警告称持续的肯定会形成一种抑制批判性思维的反馈循环。
* **“搜索引擎”问题：** 许多人认为，由于大语言模型缺乏真正的智能，且充当的是“重述者”而非中立的搜索引擎，它们模糊了信息来源的可靠性，使得人们无法区分专家共识与边缘观点。
* **实用性与狂热：** 尽管一些用户报告了实质性的生产力提升，但另一些人则对“人工智能炒作周期”感到疲惫。许多人认为，虽然大语言模型在特定技术任务或信息综合方面表现出色，但它们正越来越多地被推向心理咨询或陪伴等角色，而其谄媚的本质在这些领域构成了重大的社会风险。
彭博社 需要帮助？请联系我们 我们检测到您的计算机网络有异常活动。 为继续访问，请勾选下方方框以证明您不是机器人。 为何会出现此提示？ 请确保您的浏览器已启用 JavaScript 和 Cookie，且未阻止其加载。 欲了解更多信息，请查阅我们的服务条款和 Cookie 政策。 需要帮助？ 如有关于此信息的疑问，请联系我们的支持团队，并提供下方的参考 ID。 屏蔽参考 ID：b59cf820-9104-11f1-a02c-aeb2011a8759 订阅 Bloomberg.com，随时随地获取最重要的全球市场新闻。 立即订阅
抱歉。
Castform 通过使开发者能够在无需深厚机器学习或基础设施专业知识的情况下，对开源模型进行强化学习 (RL) 后训练，简化了专用 AI 代理的开发。
尽管前沿模型功能强大，但在复杂的、多跳代理检索任务中，它们往往因速度过慢且成本过高而难以使用。Castform 通过允许团队利用其专有的数据库内容作为训练数据，填补了这一性能差距。该平台能够自动创建合成训练任务并管理强化学习循环，从而指导模型如何有效地与工具进行交互。
通过与 Neon 的“Lakebase Postgres”集成，Castform 将数据库原生的搜索能力同时应用于训练发布和生产推理。这种基础设施实现了高性能且具有成本效益的代理工作流：Neon 的动态扩容能力可以处理强化学习中突发的需求，而数据库分支功能则为有状态的代理测试提供了隔离的、短暂的环境。
最终，Castform 让模型后训练变得普及，将内部数据孤岛转化为高性能、高性价比的代理，使其能够匹敌甚至超越大型闭源模型的能力。开发者可以监控奖励进度并调试单个任务，让训练定制化、高精度的 AI 变得像提示词工程一样简单易行。
生于反抗，或是为何业余编程社区抵制 LLM 的使用 Born Against, or why hobby programming communities are against LLM usage
91 天前
小众编程爱好者社区——例如那些致力于操作系统开发、模拟器制作和代码高尔夫的群体——对使用大语言模型（LLM）的态度日益抵触。尽管这些群体常因历史上存在的“把关”行为而受诟病，但他们对人工智能的抵制源于一种根本性的哲学分歧。 在这些领域中，价值并不在于最终运行的软件，而在于掌握复杂领域知识那段艰苦且漫长的过程。从业者通过多年展现出的好奇心、分享优雅的代码以及展示深刻的见解来赢得尊重。在这些爱好者眼中，大语言模型被视为一种绕过学习过程的“作弊”行为。 作者认为，虽然大语言模型可以作为专家强大的助力工具，但在这些社区中，它们却取代了技艺本身。通过自动化生成代码，大语言模型剥夺了开发者原本试图获取的经验。归根结底，这些小众群体将编程的“如何”与“为何”置于产出之上，并将人工智能驱动的捷径视为偏离了他们追求的本质。
近期 Hacker News 上关于“天生反感”（Born Against）的讨论，凸显了软件社区内部在大型语言模型（LLM）使用问题上日益加深的鸿沟。
这场辩论的核心在于两种相互冲突的编程哲学：
* **“工匠派”（钻研者）：** 对这些人来说，编程是一种爱好，也是一个自我精进的过程。他们看重像“数独”一样亲手解决问题和构建系统的挑战。对他们而言，LLM 是一种破坏性的力量，剥夺了工艺的乐趣，就像机器生产的餐食取代了厨师的劳动。他们担心随着“氛围编码”（vibe coding）成为常态，他们辛苦磨练的技能价值和社区标准会被稀释。
* **“结果导向派”（务实者）：** 许多开发者，尤其是那些专注于产出的人，将 LLM 视为强大的工具。它消除了繁琐的样板代码，使他们能够构建以往因时间和资源限制而无法实现的东西。他们认为，重点应该在于最终产品的实用性，而非过程的“手工”属性。
这种紧张关系之所以持续存在，是因为 LLM 挑战了技术社区中固有的社会地位和准入门槛。虽然有些人预见未来仍会有“定制化”的手写代码，但另一些人则认为，由人工智能辅助的通用化开发是必然的前进方向。
泽德 DeltaDB Zed DeltaDB
91 天前
回溯至任意编辑 DeltaDB 捕获提交之间的每一次操作，并为每一项操作赋予稳定的标识，因此你可以指向代码演进过程中的任何时刻。 追踪代码至对话 每一次变更都与产生它的智能体对话相连。从任意代码行即可找到相关对话；从任意消息即可跳转至所涉及的代码。 随时创建分支 DeltaDB 虚拟化了工作树，因此开启一个新的智能体分支几乎无需成本。历史记录中的任何节点都是有效的分支点，包括运行中的任务。 共享对话而非 PR 同事可以在工作进行时随时加入，与执行任务的智能体沟通，并在过程中添加注释，无需等待你先完成提交和推送。
Hacker News 上关于 Zed 最近公告的讨论，凸显了该项目愿景与用户期望之间的显著分歧。尽管 Zed 将自己定位为一款“AI 代理原生”（agent-native）编辑器，并推出了诸如 **DeltaDB**（用于追踪代码提交间的对话历史与演变）等功能，但许多用户对此感到沮丧。
主要批评意见包括：
* **忽视核心稳定性：** 长期用户认为 Zed 的 Bug 日益增多，指出其存在 CPU 占用率高、文件监控可靠性差（尤其是在 WSL/Linux 上）以及 UI 交互不一致等问题。批评者认为，团队将“AI 垃圾功能”和讨好风投的功能置于优先地位，而非关注最初吸引用户的基础性能。
* **隐私与监控担忧：** 许多人认为，将每一行代码与 LLM 对话关联起来，对于员工监控而言可能是一场“噩梦”。用户担心这会为管理层提供数据，使其能够进行侵入式的、以流程为导向的微观管理，而非专注于工作成果。
* **“风投驱动”的开发：** 一种普遍的观点是，Zed 的开发是为了迎合投资者而非开发者，这导致了产品中充斥着臃肿的实验性功能，而基本 IDE 功能却落后于 JetBrains 或 Sublime Text 等成熟工具。
尽管存在这些抱怨，但仍有一些用户赞赏其超越传统基于 Git 工作流进行创新的雄心，认为 DeltaDB 有潜力成为一种强大的代理协作工具。
GNU Hurd News 2026-Q2
91 天前
反重力 2.0 Antigravity 2.0
91 天前
```folder_copy 项目组 将您的对话归类到“项目”中，项目可跨越多个文件夹，并支持自定义设置和作用域权限。 transcribe 实时语音转录 口述您的提示词。在最新 Gemini 音频模型的支持下，实时转录功能可将对话语音转化为清晰的提示词。 dashboard_customize 扩展自定义 定义全局或工作区特定的技能 (Skills)、MCP 和 JSON Hook，以引导代理 (Agent) 产生特定的行为。```
针对谷歌“Antigravity 2.0”的 Hacker News 讨论反映出人们对当前 AI 智能体界面的看法呈现两极分化。尽管一些用户认可 Antigravity 在简化企业级谷歌身份验证方面的作用，但许多批评者认为该工具缺乏创新，称其为在众多“Claude Code”克隆版中姗姗来迟且缺乏原创性的产品。
核心争议点包括：
* **界面设计：** 关于终端用户界面（TUI）兴起的讨论仍在持续。支持者认为它们在基于 SSH 的远程工作和高效文本输入输出方面更具优势；而反对者则认为它们不统一，且不如图形用户界面（GUI）易用。
* **安全性与审查：** 对 Antigravity 的一大主要批评在于其拒绝执行与安全相关的代码分析。用户指出，虽然谷歌底层的模型（如 Gemini）具备此类任务的处理能力，但该智能体界面施加了限制性的“安全”过滤器，这迫使高级用户转向使用国产或开源模型。
* **市场质疑：** 许多参与者认为谷歌落后于竞争对手，质疑为何用户会选择 Antigravity 而非 Reasonix 或 MiMo Code 等更透明或更专业的工具。归根结底，用户依然对谷歌倾向于砍掉实用产品、转而开发效果更差的新产品这一做法心存顾虑。
**celld** 是一个开源守护进程，允许你在自己的基础设施上自托管 Cloudflare Workers 和 Durable Objects。它通过使用兼容 S3 的存储桶作为部署、状态和协调的唯一事实来源，消除了对中央控制平面或复杂共识协议的需求。 主要特性包括： * **去中心化协调：** 每个 Durable Object 都是一个独立的 SQLite 数据库。节点使用 S3 的“比较并交换”（compare-and-swap）操作来获取单元的所有权，从而确保无缝迁移和高可用性。 * **高性能与高效率：** 应用程序在设计上即为分片式，限制了故障影响范围。空闲对象会自动进入休眠状态以节省资源，节点支持压力卸载以管理内存和 CPU 利用率。 * **运维简便：** 节点是无状态且可替换的。系统使用标准的 AWS 凭证，并支持二进制和 Docker 部署。 * **安全性：** 点对点通信通过集群密钥进行 HMAC 认证，并具备防重放保护。 celld 专为寻求 Durable Objects 强大功能且希望避免供应商锁定的开发者而设计，为边缘类应用程序提供了一个弹性、分布式的运行环境。如需安装、文档和操作指南，请访问 **celld.dev**。
Deno 团队推出了 **celld**，这是一个自托管的分布式系统，旨在替代 Cloudflare 的 Durable Objects。该系统通过将“单元”（单个对象）存储为 SQLite 数据库并复制到兼容 S3 的存储桶中来运行，并利用条件写入进行协调，而非使用 etcd 等传统且复杂的共识层。
**Hacker News 讨论要点：**
* **目的：** celld 提供了一种即插即用的开源方案，用于运行分布式的、有状态的 JavaScript/TypeScript “隔离实例”（isolates），使用户无需被锁定在特定提供商的基础设施中。
* **基础设施：** 虽然 Cloudflare 提供全球覆盖和托管服务，但 celld 针对的是那些希望掌控自己数据平面、并可能在标准云实例或 Kubernetes 上运行服务的用户。
* **技术辩论：** 用户质疑其对 S3 一致性的依赖，并将其与 Temporal 或 Restate 等其他持久化执行工具进行了对比。一些维护者指出，与专有的内部实现相比，celld 提供了一种更简单、更易于运维的“持久对象”（Durable Objects）实现方式。
* **维护者观点：** 该项目的 README 强调了一个日益增长的开源趋势：通过禁用拉取请求（Pull Request）来拒绝低质量的 AI 生成式贡献，这突显出高质量的代码审查——而非代码编写——已成为项目维护者面临的首要瓶颈。