## 自动驾驶出租车竞赛：愿景 vs. 传感器融合 自动驾驶出租车的未来正在像德克萨斯州奥斯汀这样的城市中塑造，Waymo和特斯拉的自动驾驶出租车已经在街道上行驶。这些车辆代表了截然不同的自动驾驶技术方法：Waymo利用全面的“传感器融合”方法，使用激光雷达、雷达和摄像头构建周围环境的详细3D地图，而特斯拉则倡导仅依靠摄像头和强大人工智能的“仅视觉”系统。 这场争论源于历史性的转变。早期的自动驾驶系统倾向于使用传感器融合以确保安全和冗余。然而，特斯拉在2016年提出了挑战，认为足够的计算能力和摄像头可以复制人类的驾驶能力——并且成本更低。 虽然特斯拉最初在其车辆中移除了雷达，但它悄悄地重新引入了雷达，这表明可能正在向传感器融合方法靠拢。两家公司现在都在大力投资人工智能并简化他们的系统。关键区别现在不是*使用*哪些传感器，而是系统*有多安全*。 最近的安全数据表明，Waymo的传感器融合方法目前优于特斯拉的方法，脱离和事故明显更少。最终，这场竞赛的胜者不会仅仅由技术决定，而是由社会对安全标准的接受程度决定——我们将满足于*与*人类驾驶员一样安全，还是要求*更好*？答案将决定自动驾驶出租车的部署速度和规模，并重塑交通的未来。
每日HackerNews RSS
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
像轿车一样看待 (asteriskmag.com)
4 分，由 surprisetalk 1小时前发布 | 隐藏 | 过去 | 收藏 | 讨论 帮助
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
## 恶魔城：一场跨国热潮
1986年，卡普空（Capcom）的《恶魔城》取得了一项罕见成就：同时在日本和英国的销量排行榜上名列前茅。通过日本杂志《Famitsu》（1986年创刊）的销售数据，可以探究这一成功的背后原因。虽然任天堂的Famicom/NES主导了美国市场，但英国的游戏市场当时主要以电脑游戏为主——收入是主机游戏的六倍。
尽管存在这种差异，《恶魔城》仍然在双方玩家中引起共鸣。游戏的开发，源于藤原 Tokuro 对具有挑战性和视觉吸引力的游戏玩法的追求，将街机动作与一丝可爱元素相结合。英国公司Elite Systems迅速获得了移植权，在卡普空Famicom版本发布的同时，甚至在游戏登陆美国NES之前，就发布了Commodore 64和ZX Spectrum的版本。
这些移植版本虽然受到硬件限制的影响，但仍然很受欢迎，展示了全球游戏场景的互联互通，尽管存在区域差异。《恶魔城》的成功表明街机游戏作为共同点，影响了家用主机和电脑游戏，并对游戏设计和叙事模式留下了持久的影响。
一篇关于臭名昭著的困难游戏《恶魔城》的链接引发了 Hacker News 的讨论。用户们回忆了具有挑战性的 NES 版本及其严苛的平台跳跃。
一位评论员提到之前 HN 上关于老游戏中“空中控制”的讨论，认为远离这种机制（存在于《恶魔城》中）是一种积极的改变。另一位用户强调 PSP 版本虽然令人沮丧的敌人“随机生成”会扰乱精确跳跃，但仍然很享受。
最后一条评论简单地分享了一种传统的民间疗法：“砍一根粗壮的黑刺来驱逐鬼怪。” 该帖子总体上反映了对游戏难度的怀旧欣赏，以及对不断发展的游戏设计原则的讨论。
## Rivet Actors：无服务器状态化工作负载 Rivet Actors 是一种新的无服务器基础组件，专为构建状态化应用程序而设计。每个 actor 作为一个独立的、可扩展的单元，内置状态管理、存储（SQLite/JSON）、WebSockets、工作流和调度功能——无需复杂的后端基础设施。 Actors 提供即时读写速度，具有内存状态和持久化存储，并且可以从零扩展到数百万，高效处理突发工作负载。它们非常适合 AI 代理（具有持久化内存）、协作文档、聊天应用程序，甚至每个租户的数据库等用例。 Rivet 提供灵活的部署方式：使用 Rust 二进制文件或 Docker 自行托管，或利用其完全托管的全球边缘网络，与 Vercel 和 AWS 等现有云提供商集成。它是开源的（Apache 2.0），并支持 Hono、Elysia 和 tRPC 等流行框架，提供 JavaScript、React 和 Next.js 的客户端。
## Rivet Actors 添加 SQLite 存储
Rivet Actors，一个开源的 Cloudflare Durable Objects 替代方案，已推出 SQLite 存储，从而实现了一种独特的数据管理方法。每个“actor”（代表一个代理、租户或文档）都会收到其*自身*的专用 SQLite 数据库。
这允许大规模扩展（数百万个数据库），并具有标准 SQL 的灵活性，避免了像 Cassandra 或 DynamoDB 这样的系统中的模式限制和迁移难题。与 Cloudflare Durable Objects 或 Turso 等闭源替代方案不同，Rivet 是完全开源的，并优先通过其单写者 actor 模型实现本地、新鲜的读取。
SQLite 在每个 actor 的进程内运行，持久性由 FoundationDB 或 Postgres 处理。Rivet Actors 还提供实时通信（WebSockets）、React 集成和自动扩展等功能，使其适用于 AI 代理、多租户 SaaS 和协作文档等应用程序。
[https://github.com/rivet-dev/rivet](https://github.com/rivet-dev/rivet)
## 验证规格驱动开发 (VSDD) – 摘要 VSDD 是一种新颖的软件工程方法，将规格驱动开发 (SDD)、测试驱动开发 (TDD) 和验证驱动开发 (VDD) 结合到一个 AI 编排的流程中。它优先考虑一个严格、可追溯的过程，其中规格定义了软件 *做什么*，测试强制执行 *如何构建*，而对抗性验证确保 *不会遗漏任何内容*。 该过程涉及一名人类架构师监督 AI “构建者”和“对抗者”代理，并通过 Chainlink 进行跟踪以确保完全的责任追溯。第一阶段侧重于“规格提炼”，在编码 *之前* 创建严密无缝的规格，包括可证明的属性和将可验证的核心逻辑与外部效应分隔开的“纯度边界”。第二阶段实施严格的 TDD 循环 (红→绿→重构)，由 AI 构建者引导。第三阶段将代码置于 AI 对抗者的严格审查之下，识别规格、测试和实现中的缺陷。第四和第五阶段整合反馈并执行形式化验证，而第六阶段确认“收敛”——当规格、测试、实现和证明都能经受住对抗性审查时。 VSDD 强调“规格至上”，验证优先的架构和无情的否定态度以消除“漏洞”。它专为需要高正确性、长期可维护性和强大安全性的项目而设计，利用 AI 来增强而非取代人类的战略决策。最终，VSDD 旨在创建具有可证明存在理由和可靠保证的代码。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
验证的规格驱动开发 (VSDD) (gist.github.com)
8 分，by todsacerdoti 32 分钟前 | 隐藏 | 过去 | 收藏 | 讨论 帮助
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
格奥尔格·康托尔通常被认为是集合论的创始人，并在1874年证明了存在不同大小的无穷。然而，最近的研究揭示了一个更复杂的故事。播客制作者Goos最初认为康托尔是一位孤独的天才，但后来发现康托尔严重依赖数学家理查德·戴德金。 在1872年的一次关键会议之后，康托尔不断寻求戴德金的建议，最终提出了一个引发突破性进展的问题：实数和整数是否可以“一一对应”？戴德金提供了关键的见解，甚至简化了康托尔最初的证明。康托尔怀着强烈的使命感和对无穷肯定上帝存在的信念，旨在彻底改变数学。 然而，由于担心受到有影响力的数学家利奥波德·克罗内克尔的拒绝——一位坚决反对无穷的学者——康托尔有策略地发表了他的发现。他向《克雷莱杂志》提交了一篇关于代数数（克罗内克尔喜欢的课题）的论文，巧妙地包含了关于实数的革命性证明，并淡化了其重要性。至关重要的是，康托尔声称是唯一的作者，抹去了戴德金的贡献。几十年后被艾米·诺特发现的信件揭示了戴德金曾向康托尔发送了核心证明，这些证明几乎原封不动地以康托尔的名义出现。虽然戴德金私下注意到这个问题，但他和诺特都选择让通信本身说话，维护了专业的沉默准则。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
一个偷走无穷大的人 (quantamagazine.org)
8 分，来自 rbanffy 1 小时前 | 隐藏 | 过去 | 收藏 | 1 条评论 帮助
leephillips 15 分钟前 [–]
“诺特尔，她是犹太人，逃离德国前往美国，两年后在那里死于癌症”
事实并非两年，也并非癌症。这些细节对这篇（相当有趣）故事来说并不重要，但这个错误表明作者从不可靠的二手资料中复制信息，这让文章中的其他事实也令人怀疑。
文章首次发表时，我曾给他写信指出这个错误，但他没有回复。
诺特尔的真实故事见 https://amzn.to/3YZZB4W。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## Obsidian Sync 获得无头客户端
Obsidian Sync 现在提供无头客户端，实现自动同步和访问库，无需完整的 Obsidian 应用程序。这为自动化备份、网站发布以及与 AI 工具集成等带来了可能性。
用户已经分享了使用案例，包括通过开源替代方案与 Synology NAS 同步，以及将其与远程 EC2 实例一起使用。无头客户端解决了桌面之外的需求，允许同步用于移动访问和在 Neovim 等工具中编辑。
讨论集中在其相对于 Git 的易用性和安全性优势，尤其是在自动化任务和维护 Obsidian 本机功能方面。虽然有些人更喜欢 Dropbox 等更简单的解决方案，但 Obsidian 的 CEO 强调了速度、隐私、加密和针对各种自动化场景的可定制性等优势。
## Claude 上下文模式：延长 AI 会话时长 Claude 代码使用 MCP 工具时，常常会迅速填满其 200K 上下文窗口，例如，Playwright 快照会占用 56KB，20 个 GitHub issue 占用 59KB。这限制了会话时长，仅 30 分钟后便会损失 40% 的上下文。**上下文模式** 通过充当 Claude 与工具输出之间的服务器，大幅减少数据大小——从 315KB 减少到仅 5.4KB（减少 98%）来解决这个问题。 它通过一个安全的 **沙箱** 实现这一点，在隔离的进程中执行工具调用。只有 *输出* (stdout) 会传递给 Claude，从而防止大型原始数据（如日志或 API 响应）膨胀上下文。支持十种语言运行时，包括通过 Bun 优化的 JavaScript/TypeScript。 内置的 **知识库** 使用 BM25 搜索索引 markdown 和网页内容，返回精确的代码块——而不是摘要——而无需将原始页面内容发送到上下文。 在实际场景中的测试表明，输出大小显著减少（例如，56KB 快照减少到 299B）。这使可用会话时间从约 30 分钟延长到约 3 小时，45 分钟后保留 99% 的上下文。上下文模式易于安装为插件或直接通过 MCP，并且不需要更改现有工作流程。
## Claude 代码上下文窗口优化
一位开发者 (mksglu) 详细说明了他们如何使用一种名为“上下文模式”的系统将 Claude 代码的 MCP 输出减少了 98%，相关细节在 GitHub 仓库 ([https://github.com/mksglu/claude-context-mode](https://github.com/mksglu/claude-context-mode)) 中概述。
核心思想是将工具调用隔离到子进程中，*仅*将它们的标准输出输入到 200K 的上下文窗口中。这避免了因原始数据转储而使上下文膨胀。它利用 SQLite FTS5 和 BM25 排名来实现对相关信息的有效搜索和检索。
主要改进包括自动升级 Bash 子代理以及在依赖 LLM 筛选“噪声”之前预先过滤信息。该系统通过精选的环境变量允许列表处理凭据传递，确保安全性，且在工具调用之间没有持久状态。
评论者强调了这种方法对于管理复杂的、多步骤的工作流程的重要性，在这些工作流程中，累积的工具输出会迅速超出上下文限制，从而迫使做出次优决策，例如手动摘要或截断。
## 从噪声到图像：AI如何创造视觉内容 AI图像生成，例如扩散模型，在难以置信的巨大图像可能性空间中运作——估计为10<sup>400,000</sup>。这些模型并非从零开始*创造*；它们从随机噪声开始，并根据你的提示逐步将其提炼成连贯的图像。 这个过程发生在更易于管理的“潜在空间”中，这是所有可能图像的压缩表示。文本提示也被转换成高维的“嵌入空间”，作为引导模型旅程的指南针。 关键因素会影响结果：**随机种子**决定起点，**步数**控制提炼频率，而**引导比例**则决定模型遵循提示的程度。更详细的提示提供更清晰的方向。 有趣的是，模型甚至可以在提示*之间*生成图像，探索嵌入空间中不对应特定词语的区域。最终，AI图像生成是对巨大可能性的复杂导航，将混沌转化为视觉上有意义的结果。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 工作 | 提交 登录
从噪声到图像 – 扩散的交互指南 (lighthousesoftware.co.uk)
8 分，由 simedw 1 小时前发布 | 隐藏 | 过去 | 收藏 | 2 条评论 帮助
whilefalse 35 分钟前 | 下一个 [–]
我是作者，感谢分享！ 这篇指南刻意写得通俗易懂，不涉及技术细节，因为我的想法是，大多数对技术/人工智能不感兴趣的人不太关心训练过程，或者系统是如何达到现在的状态的。但他们对输入提示后系统实际运作方式有兴趣。 很高兴回答任何问题或接受反馈。回复
K2h 35 分钟前 | 上一个 [–]
在手机上滑动浏览图片很困难。 想看全部 29 步，但无法可靠地滑动。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系方式
搜索：
与一位747飞行员的对话引发了对职业发展本质的思考。这位飞行员精通他的技艺，但感叹经过数十年后，“没有进步”——他已经掌握了关于驾驶747的一切知识。这引起了作者（一位软件工程师）的共鸣，因为人工智能编码代理正在迅速改变他们的工作环境。
这些代理最初被用作高级搜索工具，现在通常在极少的人工干预下完成整个功能。虽然提高了生产力，但这种转变带来了一个挑战：与传统编码不同，依赖人工智能并不能培养对系统和问题解决的相同深度理解。作者发现，随着每个任务的完成，他们学到的东西越来越少，可能面临着与飞行员停滞不前的相似的未来。
尽管承认人工智能辅助的好处和必然性，作者强调了继续重视基础知识的重要性。提示代理很容易，但真正的成功依赖于*理解*问题领域——随着人工智能处理更多实现工作，这项技能正变得可选。他们建议有意识地练习手工编码，以保持和建立这种关键的专业知识。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
747 和编码代理 (carlkolon.com)
9 分，由 cckolon 1小时前发布 | 隐藏 | 过去 | 收藏 | 1 条评论 帮助
flyinglizard 18分钟前 [–]
这就是我至今仍未在工作中采用代理，而是坚持使用半手动流程，借助aider的原因。这是我能保持代码库所有权的唯一方式。也许这会改变，因为代码所有权将不再具有任何价值，但我感觉我们还没有到那一步。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
## AI辅助开发中认知债务的兴起
AI辅助编码极大地提高了开发速度，但也引入了一种隐藏的成本：**认知债务**。虽然交付的功能和DORA分数看起来很亮眼，但代码生成的速度超过了我们*理解*代码的能力。这种生产与理解的脱钩造成了一个危险的差距。
传统上，编写代码需要理解——摩擦会产生知识。现在，工程师生成代码的速度比他们批判性地审查或真正理解其影响的速度更快。这会导致不确定性，甚至对自己的工作也会产生不确定性，并最终表现为更长的恢复时间和更改失败——这些是掩盖日益严重问题的滞后指标。
当前的性能指标是为输出意味着理解的时代设计的，无法捕捉这种差距。代码审查成为瓶颈，经常为了速度而被牺牲，从而加剧了问题。这并非因为*做*得太多而导致的倦怠，而是因为一种脱节——生产却没有真正理解结果。
最终，组织面临失去关键的内隐知识的风险，创建出没有人完全理解系统如何运作的系统。这会导致脆弱的系统、昂贵的调试以及经验丰富的架构师人才管道的减少。核心问题在于？我们正在优化可衡量的速度，而忽略了不可衡量——并且日益关键的——对理解的需求。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
认知债务：速度超过理解时 (rockoder.com)
16 分，作者 pagade 22 分钟前 | 隐藏 | 过去 | 收藏 | 1 条评论 帮助
bwestergard 4 分钟前 [–]
相关讨论：https://news.ycombinator.com/item?id=47194847
“合适的AI量不是零，也不是最大。” 回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：