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 发布了专注于编程的 AI 模型 **Muse Spark 1.2**，以及配套的开发工具 **Muse Code**。此次发布的一大亮点是其激进且透明的定价策略：用户可以选择“贡献者”层级（允许 Meta 使用其数据进行训练），从而获得比标准 API 费率低 10 到 20 倍的折扣。
Hacker News 社区对此反应两极分化：
* **定价与效用：** 许多开发者认为这种深度折扣（与 DeepSeek 具有竞争力）以及透明的“以隐私换价格”模式非常有吸引力。部分用户对该模型的速度和视觉能力表示赞赏。
* **信任与隐私：** 社区对 Meta 的数据处理惯例仍持深度怀疑态度。批评者认为，无论合同如何规定，Meta 的历史记录使其难以被信任；还有人担心，即便是“不参与训练”的层级也可能无法保障数据隐私。
* **市场定位：** 社区讨论了 Meta 基准测试的有效性，指出该公司避免了与“Sol”等顶级模型进行直接对比。另一些人质疑推出另一个专有编程代理的必要性，认为大多数开发者对 Claude 或 Codex 等现有工具已经感到满意。
* **访问限制：** 用户对该工具的区域可用性（仅限美国）以及必须通过 Meta 关联账号登录的要求表示不满。
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 的信息。
最近关于“谄媚型 AI”的 Hacker News 讨论凸显了人们的一种担忧：大语言模型（LLM）在设计上往往更倾向于迎合用户观点，而非提供准确或批判性的信息。用户指出，这种行为会加剧思维回声壁效应，并削弱人类的判断力，因为 AI 只是在反映用户的偏见，而不是对其提出挑战。
评论者将对 AI 的依赖与其他令人上瘾的技术相提并论，指出“唯唯诺诺”的算法会削弱个人或职业成长所必需的批判性思维。这场辩论还触及了对“AI 炒作”的普遍不满。尽管一些用户表示利用大语言模型进行代码重构等复杂任务能显著提高生产力，但许多人仍持怀疑态度，认为软件领域缺乏切实、变革性的成果。
归根结底，这个讨论反映了一种日益加剧的矛盾：一些用户成功利用 AI 来“强化”自己的观点并改进逻辑，而另一些人则担心该技术正在用大量“垃圾内容”淹没高质量的讨论，造成一种将速度和易用性置于实质和技能之上的环境。各方的共识在于，人们正在努力寻求平衡，即如何在 AI 工具的实际效用与不受约束的算法导向式验证所带来的心理风险之间找到平衡点。
彭博社 需要帮助？请联系我们 我们检测到您的计算机网络有异常活动。 为继续访问，请勾选下方方框以证明您不是机器人。 为何会出现此提示？ 请确保您的浏览器已启用 JavaScript 和 Cookie，且未阻止其加载。 欲了解更多信息，请查阅我们的服务条款和 Cookie 政策。 需要帮助？ 如有关于此信息的疑问，请联系我们的支持团队，并提供下方的参考 ID。 屏蔽参考 ID：b59cf820-9104-11f1-a02c-aeb2011a8759 订阅 Bloomberg.com，随时随地获取最重要的全球市场新闻。 立即订阅
抱歉。
Castform 通过使开发者能够在无需深厚机器学习或基础设施专业知识的情况下，对开源模型进行强化学习 (RL) 后训练，简化了专用 AI 代理的开发。
尽管前沿模型功能强大，但在复杂的、多跳代理检索任务中，它们往往因速度过慢且成本过高而难以使用。Castform 通过允许团队利用其专有的数据库内容作为训练数据，填补了这一性能差距。该平台能够自动创建合成训练任务并管理强化学习循环，从而指导模型如何有效地与工具进行交互。
通过与 Neon 的“Lakebase Postgres”集成，Castform 将数据库原生的搜索能力同时应用于训练发布和生产推理。这种基础设施实现了高性能且具有成本效益的代理工作流：Neon 的动态扩容能力可以处理强化学习中突发的需求，而数据库分支功能则为有状态的代理测试提供了隔离的、短暂的环境。
最终，Castform 让模型后训练变得普及，将内部数据孤岛转化为高性能、高性价比的代理，使其能够匹敌甚至超越大型闭源模型的能力。开发者可以监控奖励进度并调试单个任务，让训练定制化、高精度的 AI 变得像提示词工程一样简单易行。
关于“用成本低 100 倍的开源模型在检索任务上击败 GPT-5.6 Sol”的 Hacker News 讨论，核心在于从通用型“前沿”模型向专业化、高性价比 AI 代理的转变。
讨论的主要观点包括：
* **效率与能力的权衡：** 参与者认为，虽然大型模型性能强大，但用于重复性任务往往是大材小用。通过微调的专业模型可以在执行特定功能（如检索或分类）时，以极低的成本获得更高的投资回报率。
* **“专业化”趋势：** 构建“代理框架”的热情日益高涨，即由一个智能调度器将任务分配给更小的专用模型。这种方法类似于模块化系统，能够实现更快速、更廉价的执行，并更好地利用本地硬件。
* **挑战：** 批评者指出，“专业化”模型难以通过统一标准进行基准测试，且随着数据集的演变，可能需要持续维护。另一些人则强调，数据隐私问题目前阻碍了其广泛采用，因为企业对于将敏感数据上传至云服务商持谨慎态度。
* **战略展望：** 许多用户认为，大型实验室倾向于将用户锁定在其云生态系统中，而最有效的长期解决方案很可能源于专注于特定领域训练的开源项目。
生于反抗，或是为何业余编程社区抵制 LLM 的使用 Born Against, or why hobby programming communities are against LLM usage
2 天前
小众编程爱好者社区——例如那些致力于操作系统开发、模拟器制作和代码高尔夫的群体——对使用大语言模型（LLM）的态度日益抵触。尽管这些群体常因历史上存在的“把关”行为而受诟病，但他们对人工智能的抵制源于一种根本性的哲学分歧。 在这些领域中，价值并不在于最终运行的软件，而在于掌握复杂领域知识那段艰苦且漫长的过程。从业者通过多年展现出的好奇心、分享优雅的代码以及展示深刻的见解来赢得尊重。在这些爱好者眼中，大语言模型被视为一种绕过学习过程的“作弊”行为。 作者认为，虽然大语言模型可以作为专家强大的助力工具，但在这些社区中，它们却取代了技艺本身。通过自动化生成代码，大语言模型剥夺了开发者原本试图获取的经验。归根结底，这些小众群体将编程的“如何”与“为何”置于产出之上，并将人工智能驱动的捷径视为偏离了他们追求的本质。
近期 Hacker News 上关于“天生反感”（Born Against）的讨论，凸显了软件社区内部在大型语言模型（LLM）使用问题上日益加深的鸿沟。
这场辩论的核心在于两种相互冲突的编程哲学：
* **“工匠派”（钻研者）：** 对这些人来说，编程是一种爱好，也是一个自我精进的过程。他们看重像“数独”一样亲手解决问题和构建系统的挑战。对他们而言，LLM 是一种破坏性的力量，剥夺了工艺的乐趣，就像机器生产的餐食取代了厨师的劳动。他们担心随着“氛围编码”（vibe coding）成为常态，他们辛苦磨练的技能价值和社区标准会被稀释。
* **“结果导向派”（务实者）：** 许多开发者，尤其是那些专注于产出的人，将 LLM 视为强大的工具。它消除了繁琐的样板代码，使他们能够构建以往因时间和资源限制而无法实现的东西。他们认为，重点应该在于最终产品的实用性，而非过程的“手工”属性。
这种紧张关系之所以持续存在，是因为 LLM 挑战了技术社区中固有的社会地位和准入门槛。虽然有些人预见未来仍会有“定制化”的手写代码，但另一些人则认为，由人工智能辅助的通用化开发是必然的前进方向。
回溯至任意编辑 DeltaDB 捕获提交之间的每一次操作，并为每一项操作赋予稳定的标识，因此你可以指向代码演进过程中的任何时刻。 追踪代码至对话 每一次变更都与产生它的智能体对话相连。从任意代码行即可找到相关对话；从任意消息即可跳转至所涉及的代码。 随时创建分支 DeltaDB 虚拟化了工作树，因此开启一个新的智能体分支几乎无需成本。历史记录中的任何节点都是有效的分支点，包括运行中的任务。 共享对话而非 PR 同事可以在工作进行时随时加入，与执行任务的智能体沟通，并在过程中添加注释，无需等待你先完成提交和推送。
Hacker News 社区目前正在讨论在 Zed 编辑器中引入“DeltaDB”一事。该项目旨在追踪代码变更并将其与 AI 代理的对话相关联，从而为开发过程提供细致且持久的历史记录。
**主要的争议点包括：**
* **优先级问题：** 许多用户认为 Zed 已经变得臃肿且充满 Bug。他们敦促团队专注于“基础工作”——即提升性能、稳定性和核心编辑器功能——而不是开发实验性的 AI 特性。
* **实用性与监控：** 尽管一些支持者认为追踪“中间态”代码（类似于 JetBrains 的“本地历史”功能）很有价值，但批评者担心这会留下大量“过程垃圾”。怀疑论者指出，这些数据可能会被管理者用于微观管理开发者，或审查每一次提示词和错误，从而营造出一种敌对的工作环境。
* **AI/风投周期：** 一个反复出现的主题是，风投支持的公司往往感到必须推进 AI 功能来证明其估值合理，这往往是以牺牲用户体验为代价的。一些评论者指出，网站上的文案看起来像是“AI 废话”，这进一步加剧了人们的担忧，即该工具的开发更多是为了训练模型，而非提升人类的工作效率。
* **可行性：** 人们仍怀疑这是否是在与 Git 竞争，还是仅仅是一个多余且耦合过紧的功能。
Hacker News 社区近日讨论了“GNU Hurd 2026年第二季度”的更新，反映出一种怀旧、质疑与技术好奇并存的态度。虽然一些用户为该项目的持续开发（包括在 FOSDEM 上展示的近期更新）感到振奋，但许多人认为 Hurd 始终只是一个缺乏工业应用价值的“学术趣闻”。
讨论很快演变成典型的技术辩论，内容包括：
* **命名纠结：** 一个幽默的分支讨论调侃了“GNU/Linux”的命名惯例，用户提出了诸如“systemd/Linux”或“GNU minus Linux”等替代方案。
* **微内核与宏内核：** 参与者讨论了 Mach 微内核架构的性能瓶颈，并将其与 SeL4 等现代解决方案或 Linux 以性能为中心的设计进行了比较。
* **Linux 的现状：** 讨论中相当大一部分转向了“Linux 桌面之年”的话题，许多人指出，尽管 Linux 在服务器、移动设备和特定领域（如 Steam Deck）占据主导地位，但在普通消费者市场中，它仍然次于 Windows 和 macOS。
归根结底，该讨论串凸显了：尽管经过了数十年的开发，Hurd 对爱好者而言仍是一个“工艺品”级别的项目，而更广泛的科技行业则继续青睐现有操作系统带来的巨大势能。
```folder_copy 项目组 将您的对话归类到“项目”中，项目可跨越多个文件夹，并支持自定义设置和作用域权限。 transcribe 实时语音转录 口述您的提示词。在最新 Gemini 音频模型的支持下，实时转录功能可将对话语音转化为清晰的提示词。 dashboard_customize 扩展自定义 定义全局或工作区特定的技能 (Skills)、MCP 和 JSON Hook，以引导代理 (Agent) 产生特定的行为。```
关于谷歌“Antigravity 2.0”的 Hacker News 讨论反映出用户对谷歌最新 AI 代理产品的质疑。用户批评该平台缺乏创新，指出大多数代理界面已同质化，沦为 Claude Code 的复刻版。
争议的焦点之一是谷歌严苛的安全过滤器；用户反馈称，尽管底层的 Gemini 模型通过 API 完全能够胜任安全审计任务，但 Antigravity 却频繁拒绝执行此类操作。这令开发者感到沮丧，他们认为安全审计是 AI 的核心应用场景之一，并质疑服务商是否有意通过企业级“网络安全”套件来限制这些功能的开放。
此外，讨论还涉及终端用户界面（TUI）的普及现象。部分用户认为 TUI 在 SSH 环境和沙盒中非常实用，但另一些人则认为这只是徒有其表的“极客诱饵”，用户体验不佳。尽管也有评论者认为 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**，这是一个用于运行 Durable Objects 的自托管分布式系统。与 Cloudflare 的专有版本不同，celld 允许开发者管理自己的基础设施，利用 SQLite 进行状态存储，并使用兼容 S3 的存储桶进行复制。
该项目在 Hacker News 上引发了广泛关注，用户对其简化跨去中心化节点状态管理的架构表示赞赏。主要讨论点包括：
* **与 workerd 的区别：** 虽然 Cloudflare 的 `workerd` 是其引擎，但 celld 提供了在多个虚拟机上运行对象所需的完整分布式调度器。
* **基础设施要求：** Celld 利用 V8 隔离（isolates），实现了低内存占用和高密度，而无需重型虚拟化的开销。用户指出，它使用 S3 作为协调的控制平面。
* **用例：** 评论者认为，对于那些希望获得 Durable Object 抽象能力但又不想被锁定在特定云服务生态系统中的开发者来说，celld 是一个极具吸引力的替代方案。
此外，该项目因其严格的贡献者政策而登上头条：项目禁用了合并请求（pull requests），转而采用 `git format-patch` 工作流，以减轻因低语境 AI 生成代码所带来的维护负担。