回溯至任意编辑 DeltaDB 捕获提交之间的每一次操作，并为每一项操作赋予稳定的标识，因此你可以指向代码演进过程中的任何时刻。 追踪代码至对话 每一次变更都与产生它的智能体对话相连。从任意代码行即可找到相关对话；从任意消息即可跳转至所涉及的代码。 随时创建分支 DeltaDB 虚拟化了工作树，因此开启一个新的智能体分支几乎无需成本。历史记录中的任何节点都是有效的分支点，包括运行中的任务。 共享对话而非 PR 同事可以在工作进行时随时加入，与执行任务的智能体沟通，并在过程中添加注释，无需等待你先完成提交和推送。
每日HackerNews RSS
Hacker News 上关于 Zed 最近公告的讨论，凸显了该项目愿景与用户期望之间的显著分歧。尽管 Zed 将自己定位为一款“AI 代理原生”（agent-native）编辑器，并推出了诸如 **DeltaDB**（用于追踪代码提交间的对话历史与演变）等功能，但许多用户对此感到沮丧。
主要批评意见包括：
* **忽视核心稳定性：** 长期用户认为 Zed 的 Bug 日益增多，指出其存在 CPU 占用率高、文件监控可靠性差（尤其是在 WSL/Linux 上）以及 UI 交互不一致等问题。批评者认为，团队将“AI 垃圾功能”和讨好风投的功能置于优先地位，而非关注最初吸引用户的基础性能。
* **隐私与监控担忧：** 许多人认为，将每一行代码与 LLM 对话关联起来，对于员工监控而言可能是一场“噩梦”。用户担心这会为管理层提供数据，使其能够进行侵入式的、以流程为导向的微观管理，而非专注于工作成果。
* **“风投驱动”的开发：** 一种普遍的观点是，Zed 的开发是为了迎合投资者而非开发者，这导致了产品中充斥着臃肿的实验性功能，而基本 IDE 功能却落后于 JetBrains 或 Sublime Text 等成熟工具。
尽管存在这些抱怨，但仍有一些用户赞赏其超越传统基于 Git 工作流进行创新的雄心，认为 DeltaDB 有潜力成为一种强大的代理协作工具。
```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 生成式贡献，这突显出高质量的代码审查——而非代码编写——已成为项目维护者面临的首要瓶颈。
在人工智能评估中，一个常见的挑战是“数据污染问题”：模型获得高分往往不是因为具备真正的推理能力，而是通过回忆训练过程中接触过的信息。这在药物研发等领域尤为棘手，因为测试案例往往基于模型训练数据中已有的知名公开成果。
Francesco Moramarco 指出了数据泄露的三种主要途径：
1. **输入泄露**：模型在测试过程中获取了包含答案的文档。
2. **基准测试泄露**：模型在训练时直接使用了特定的测试问题。
3. **结果泄露**：模型将“正确”答案（如临床试验结果）作为通用世界知识进行了记忆。
虽然实时基准测试（在未来未知的成果上进行测试）是最干净的解决方案，但对于药物开发等长期流程而言并不切实际。因此，研究人员必须采用多方面的检测和预防方法，例如日期限制、实体遮蔽，以及最重要的——评估推理过程（即“收据测试”）而非仅仅关注最终答案。由于没有哪种方法是绝对万无一失的，最可靠的方法是结合多种技术对结果进行三角验证，以区分模型是靠记忆还是真正的智能。
Hacker News
最新 | 往日 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
你的模型已经知道答案了：基准测试答案是如何泄露进大模型的 (elman.ai)
14 点 | fran-mora 发布于 1 天前 | 隐藏 | 往日 | 收藏 | 讨论 | 帮助
考虑申请 YC 2026 年秋季班吧！申请截止日期为 7 月 27 日。
准则 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
为了将大脑活动解码为文本，我们正在应用人工智能领域的“苦涩教训”：与其依赖人工设计的算法，不如通过扩大计算规模和数据采集来提升模型性能。尽管侵入式脑机接口仍然不切实际，但经济实惠的非侵入式硬件的进步，使我们能够以前所未有的规模收集数据。 我们的研究展示了清晰的缩放定律，即模型准确率随着训练数据量的对数增长而线性提升。我们目前正处于大脑解码的“GPT-2时代”，预测结果与目标文本之间的语义相似度正不断增加。 至关重要的是，现实应用并不要求完美的解码。就像嘈杂的GPS信号在结合地图与路线后会变得高度准确一样，我们利用大语言模型（LLM）和上下文信息，将嘈杂的脑电信号提炼为有意义的输出。随着我们持续扩大规模，这些系统正变得越来越有效。若想了解更多关于我们数据采集过程的信息，或参与我们的研究，请访问 Conduit 博客。
前 OpenAI 员工娜奥米·巴什坎斯基（Naomi Bashkansky）宣布离职，并创立了一家名为“Conduit”的初创公司。该公司旨在开发“心灵感应”技术——一种脑机接口，允许用户仅通过思想与人工智能进行交流。
这一消息在 Hacker News 上引发了激烈争论。持怀疑态度的人大多将其斥为“雾件”（vaporware）或“AI 空话”，理由是非侵入式脑部扫描技术面临巨大的技术障碍。许多评论者对这一前景表达了深层的本能恐慌，警告称未来可能出现一种“反乌托邦”局面：企业 AI 可以监控、利用甚至操纵人类的思想。
这场讨论迅速演变为对硅谷文化的广泛批评。批评者认为该项目是“科技精英狂妄自大”的典型表现，暗示这些脱离普通生活的精英创业者正与现实渐行渐远，且沉迷于操控人类的体验。相反，少数用户为这项技术的发展进行了辩护，指出其在辅助残障人士方面的潜力，并对能够绕过传统交流的“枯燥”过程表示了由衷的兴奋。归根结底，这一讨论串成为了当前关于 AI 文化分歧的缩影：一方看到了人类超越自我的路径，而另一方则看到了一个监视与自我丧失的“苦难深渊”（Torment Nexus）。
在这个作家愈发频繁被指控使用人工智能的时代，证明人类创作已成为一种令人倍感压力的必要之举。由于文风“习惯”已不再是可靠的证据，作家兼开发者艾里斯·杨（Eris Young）开发了 **VellumProof**，旨在为写作过程提供“凭证”。
受 GitHub 版本控制和热图的启发，VellumProof 会追踪手稿的演变，记录逐字修改内容和时间戳，而非仅仅记录代码行。通过可视化每日字数统计，该工具为作者的创作进度创建了一份可核实、透明的历史记录。尽管作者承认没有任何系统能完美防止恶意使用者伪造数据，但该工具的目标是将证明负担从主观的“感觉”转移到客观的记录成果上。
归根结底，VellumProof 是创作者的“测谎仪”，让作家能够提供其作品的创作延时过程。它是对被无端指控使用人工智能这一恐惧的积极回应，并建立在这样一种信念之上：大多数作家都是诚实的，且理应拥有验证其创作成果的方式。
抱歉。
该注入攻击操控 Rovo 将 Jira 工单和 Confluence 文档提交至攻击者的网站。Rovo 的 URL 获取工具存在安全隐患：对于由智能体动态生成的 URL，系统缺乏相应的防护措施。在此攻击中，Rovo 被操纵，将敏感数据附加到攻击者的 URL 后。当 Rovo 调用该不安全的工具打开链接时，攻击者的站点会记录下包含敏感数据的请求。Rovo 通过注入攻击被操纵，从而将 Jira 和 Confluence 数据提交至攻击者的 URL。注意：即使组织禁用了 Rovo 的网页搜索功能，该攻击依然能够成功。这是因为“网页搜索”设置并未移除用于打开搜索结果的工具。即使组织层面的 Rovo“启用网页搜索”设置已关闭，攻击依然有效。如果用户随后返回聊天界面，他们会看到智能体建议的工单更新，但察觉不到任何攻击迹象。当用户稍后重新打开聊天时，所有攻击证据都会消失，输出显示一切正常。
威胁行为者正越来越多地利用 Cloudflare Workers、Vercel、GitHub Pages 和 IPFS 等合法云平台来托管复杂的钓鱼基础设施。通过利用这些服务的高信誉度和内置安全功能，攻击者能够绕过传统的检测机制，同时为受害者提供逼真的体验。
这些活动通常采用多阶段的中间人（AitM）攻击。攻击者通过使用一次性中转站点来收集电子邮件地址，并部署“浏览器内浏览器”（BitB）技术，创建令人信服的伪造登录窗口，从而绕过多因素身份验证（MFA）。2025 年 8 月至 2026 年 7 月期间，此类钓鱼页面被识别出超过 390,000 个。
报告强调，基于域名的黑名单等传统安全措施往往无效，因为其父域名本身是合法的。目前的防御需要基于内容的分析以及更高的用户警惕性。专家建议用户仔细核查浏览器真实的地址栏（而非弹出窗口），并在遇到意外请求时，手动导航至目标服务而非直接点击链接。各机构应采取分层安全防护措施，在威胁到达用户之前将其化解。
最近的一场 Hacker News 讨论指出，钓鱼者正越来越多地利用 Azure、GitHub 以及各类无服务器（serverless）提供商等合法云基础设施来托管恶意载荷。由于这些平台受到网络过滤器和安全软件的信任，它们成为了规避检测的理想环境。
讨论的焦点在于安全与平台可访问性之间的冲突。一些用户主张对 Vercel 和 Netlify 等平台采取激进的 DNS 封锁以降低风险，但另一些人认为这会破坏互联网的正常功能。争论的一个重要点在于云服务提供商是否应实施更严格的“了解你的客户”（KYC）协议来遏制滥用。
批评者认为，Cloudflare 等公司为了增长和降低准入门槛而忽视了滥用防范，实际上充当了犯罪分子的“防弹托管”。相反，另一些人则认为强制身份验证是对合法用户的一种侵入性且无效的负担，罪犯完全可以通过窃取的凭证绕过这些限制。目前普遍的共识是，虽然云服务提供商受益于宽松的反滥用政策，但解决方案仍难以捉摸，需要在阻止复杂的欺诈行为与维护一个无需许可、开放的互联网之间寻求平衡。
作者描述了一次排查搜索后端间歇性“无可用上游”（no healthy upstream）错误的历程。起初，团队遵循了一个看似合理但并不正确的根本原因分析（RCA），将其归咎于 CPU 节流。
作者没有将 RCA 视为事实，而是将其当作一个假设，并最终找到了推翻该 CPU 理论的证据——具体而言，故障与部署边界无关，且与 CPU 使用率并无关联。日志最终揭示了罪魁祸首：工作进程因无限制的 I/O 等待和激进的重试而陷入停滞，从而引发了饱和工作池并导致级联故障的反馈循环。
修复方案包含三个关键步骤：为下游调用添加明确且严格的超时时间；将无条件重试替换为令牌桶式的“重试预算”；以及确保截止时间传递。这防止了缓慢的依赖项阻塞整个服务。
作者总结道，依赖“整齐”的解释可能是危险的。最重要的经验是让证据胜过直觉：有效的 RCA 必须能够做出可验证的预测。当证据与理论矛盾时，必须放弃“好故事”，深入挖掘——通常在于资源限制、超时和重试策略之间的相互作用。