## 网页的隐藏复杂性与对“可塑性”网页的呼唤 我们通过手机轻松访问服务——轻点一下就能叫车或预订公寓——掩盖了网页开发者令人沮丧的现实。在2026年构建和*分享*一个功能性的网络应用程序，感觉更像是不断修复一团乱麻的“管道”，而不是创造，需要应对状态同步问题、模式锁定以及部署和安全等无休止的运维复杂性。这种在创造性构建和调试之间不断切换，会破坏流畅性，并常常导致项目停滞。 作者认为，这源于一个根本性的分歧：用户看到的精美的“表面”体验，是由一个脆弱而复杂的机器支撑的。现有的框架试图简化这一点，但最终仍然会使开发者陷入底层基础设施。 解决方案？转向“可塑性”软件——可分享的体验，它们*本身*就是编辑环境，就像Google表格。这种方法优先考虑统一的表面，消除了仅仅为了分享一个创作成果而构建整个系统的需要。受到HyperCard和Webstrates等工具的启发，作者设想一个建立在个人、本地构建的软件之上的未来网络，从而恢复早期互联网那种富有创造力、混乱和互联互通的精神。
每日HackerNews RSS
一个黑客新闻的讨论围绕着文章“日常魔法的管道”（hyperclay.com），该文章哀叹了现代Web开发的日益复杂。
用户们争论这种复杂性是内在的还是构建更复杂应用的结果。一位评论员认为，使用今天的工具仍然可以实现简单的网站，并举例说明了免费的静态托管。另一位则强调了权衡：用户友好的工具*隐藏*了复杂性，但限制了功能——构建真正新颖的东西需要直接解决这种复杂性。
另一个提出的观点是*使用*工具（由于标准化使用而可靠）和*创造*事物（本质上不同且全新）之间的根本区别。然而，像早期的Web浏览器、HyperCard，甚至Minecraft这样的例子表明，使用和创造之间的界限模糊，提供了易于使用的构建体验。核心问题似乎是对一个像使用一样直观可构建的Web的渴望。
## Java 26：面向未来的坚实基础
Java 26 带来了一系列集中的更新，暗示着更大的特性即将到来——可能包括今年晚些时候 Project Valhalla 项目的第一个元素。虽然规模小于之前的某些版本，但 Java 26 引入了多项改进，并继续孵化关键项目。
**主要变化包括：** 将提前编译 (AOT) 对象缓存扩展到适用于所有垃圾回收器 (JEP 516)，通过减少同步来提高 G1 垃圾回收的吞吐量 (JEP 522)，以及为 HTTP 客户端 API 添加 HTTP/3 支持 (JEP 517)。 多个特性继续作为预览版提供，包括结构化并发 (JEP 525)、延迟常量 (JEP 526) 以及向量 API 的改进 (JEP 529)。 模式、`instanceof` 和 `switch` 中的原始类型也获得了第四次预览 (JEP 530)。
值得注意的是，由于安全问题和缺乏浏览器支持，已弃用的 Applet API 被**移除** (JEP 504)，并为强制执行 final 字段不可变性做准备 (JEP 500)。
Java 26 优先考虑稳定性，并为未来的创新奠定基础，在继续开发 Valhalla 等雄心勃勃的项目的同时，提供增量改进。 这是一个旨在巩固平台并为未来的重大进步做好准备的版本。
## 速度的幻觉 一位VP兴奋地宣布，由于新的AI编码助手，代码产出提高了40%，但一个关键问题被忽略了：朝着*什么*方向加速？仅仅加快代码创建，而不解决系统性瓶颈，适得其反，这正是约束理论所强调的教训。 优化非瓶颈区域会产生库存，增加交付周期，并使真正的约束不堪重负。这表现为PR泛滥，让审查者不堪重负，导致仓促批准、不稳定的测试和延迟部署——最终*降低*软件交付速度。 真正的瓶颈通常不在于编码：不明确的需求、冗长的审查流程、部署焦虑以及缺乏发布后分析。关注这些问题——绘制价值流图，测量周期时间，减少等待状态，限制在制品，并积极倾听开发人员的意见——至关重要。 真正的改进不是编写更多的代码，而是高效地向用户交付价值。将产出置于流程之上，会制造一个生产出未使用的库存的工厂，被误导性的乐观仪表盘所掩盖。关键在于识别并解决*实际*的瓶颈，而这很少是键盘。
## 黑客新闻讨论总结：AI 编程与真正瓶颈
最近黑客新闻上的一场讨论集中在观点上：软件开发的主要问题不是编码速度，而是理解*要构建什么*。许多评论者同意，最大的瓶颈不是打字更快，而是确保上游决策是合理的。即使是快速的代码生成，如果构建的是错误的东西也是无用的。
对话强调，更快的迭代*可以*帮助完善理解，但只有在紧密的反馈循环和验证下才能实现。仅仅快速地构建东西而不进行仔细评估，可能会导致精力浪费并强化不正确的假设。 几位用户指出，组织问题——一种优先考虑速度而非质量的倾向，以及缺乏有效的代码审查——会加剧这些问题。
最终，讨论表明，AI 的潜力不仅仅在于加速代码*编写*，而在于实现更快的原型设计和实验，*前提是*它与一个强大的验证假设和理解核心问题的流程相结合。 许多人认为，如果组织不解决规划和沟通方面的问题，AI 工具可能会放大现有问题。
伊利诺伊州议会提供谷歌翻译™服务，仅为访客提供便利。不应将其中任何内容的翻译视为准确。鼓励伊利诺伊州议会网站的访客使用互联网上提供的其他翻译服务。本网站的英文版本始终是官方和权威版本。注意：要返回原始英文版本，请选择窗口顶部谷歌翻译™菜单栏上的“显示原文”按钮。
启用 JavaScript 和 Cookie 以继续。
## 阅读征兆：解读手相的历史 几个世纪以来，人类一直试图通过解读外部特征来理解内在性格——这种做法源于古希腊的“相面学”。虽然我们承认外表具有欺骗性，但我们本能地从面部、姿势甚至手部推断性格。历史上，诸如颅相学（通过头骨凸起解读）和手相学（解读手相）之类的实践试图将生理特征与心理特质科学地联系起来。 这种追求并非仅仅是占卜。手相学，从古代传统发展到19世纪的“手相术”，提供了心理洞察，甚至预示了现代人格概念。然而，它也与有问题的种族理论纠缠在一起，被用来为社会等级制度辩护。 科学的兴起——用于身份识别的指纹识别，揭示疾病染色体起源的遗传学——似乎“破除”了这种做法的魔力。然而，手相学仍然存在，现在通常被视为自我发现而非预测。即使在今天，从在线人工智能解读到专业手相师，我们继续在手部的线条和形状中寻找意义，这表明我们渴望通过可见的迹象来理解自己和他人。因此，手相学的故事不仅仅是关于人体的某一部分，而是关于我们不断演变的自我认知追求。
一场关于Hacker News的讨论围绕着《伦敦书评》(LRB)的一篇文章展开。一位评论员指出，这篇文章是对颅相学和手相学的冗长探索，几乎不具备传统书评的功能。
其他人纷纷发表意见，解释了《伦敦书评》的风格：书评通常是更广泛主题的扩展文章的跳板。一些读者认为，《伦敦书评》的质量近年来有所下降，变得更加关注政治，而学术性则有所降低，而另一些人则为其一贯的质量和独特的方法辩护。《伦敦书评》被描述为一种类型的一部分——与《纽约书评》等出版物一起——“书评”实际上是对书籍引发的思想的延伸探索。
## 秘密特工：一部巴西充满矛盾的惊悚片
巴西的奥斯卡参赛作品《秘密特工》是一部视觉上引人注目的政治惊悚片，故事背景设定在1977年的累西腓，那是军事独裁统治的最后几年。影片讲述了马塞洛的故事，他是一位前教师和技术专家，被迫隐藏身份成为政治异见者，同时绝望地试图与他的儿子团聚。
摄影师叶夫根尼娅·亚历山德罗娃在实地拍摄时，使用了鲜艳、饱和的色彩——与黑暗的主题形成鲜明对比——旨在捕捉巴西复杂的二元性：一种欢乐、色彩缤纷的文化与根深蒂固的苦难和不平等并存。她利用Arri Alexa 35和老式Panavision镜头，拥抱不完美和动态影像，创造出一种有质感、近乎梦幻的美学。
影片采用了缓慢燃烧的节奏，以在加油站的冗长开场场景为例，并呈现了精心制作的片段，例如马塞洛沉浸在狂欢节庆祝活动中，将光与影融合在一起，象征着潜伏在迫在眉睫的危险中的生命。《秘密特工》不仅仅是一部惊悚片，它更是一次对一个国家在挣扎中寻找自身认同的视觉探索，也是一个提醒，苦难可能降临到任何人身上。
## “特工” 在黑客新闻上引发讨论
电影《特工》（2025年），背景设定在20世纪70年代巴西的军事独裁统治时期，正引发各种反应。许多评论员称赞其身临其境的摄影和将观众带入那个时代的能力，一位观众提到影院座无虚席，甚至有影迷引用了电影中的细节。
然而，人们对它的节奏和叙事存在分歧。一些人认为开头缓慢而令人困惑，但最终会得到回报，而另一些人则将其描述为“催眠节”。一个共同的主题是电影的刻意模糊以及对那个时期记忆和真相破碎性的关注。
讨论还涉及电影的政治主题及其在巴西电影中的地位，与其他探讨独裁统治的作品进行比较。几位评论员强调了导演克莱伯·门多萨·菲尔霍的风格，以及其他电影，如《巴库劳》和《我依然在这里》。电影通过拨款和国家机构获得的资金也值得注意，以及关于奥斯卡奖和电影质量的争论。
展示 HN：Crust – TypeScript 和 Bun 的 CLI 框架
Show HN: Crust – A CLI framework for TypeScript and Bun
9 天前
一个TypeScript优先、Bun原生CLI框架，具有可组合的模块。文档 • 贡献 • 问题 • Discord
Crust目前为beta版本，直至v1.0。1.0之前的版本不严格遵循语义化版本控制。核心API在0.1版本之后应该相对稳定，但预计在小版本发布之间会有破坏性更改。
bun create crust my-cli
cd my-cli
bun run dev
## Crust：一个用于TypeScript & Bun的新CLI框架
Crust (https://crustjs.com/) 是一个全新的、TypeScript优先、Bun原生CLI框架，旨在弥合极简参数解析器和重量级的Node时代框架之间的差距。它最初由内部开发，现已开源，拥有零运行时依赖（gzip压缩后约3.6kB），并专注于开发者体验。
主要特性包括完整的类型推断、编译时验证、具有生命周期钩子的插件系统，以及用于诸如提示和样式等功能的模块化组件。它专为Bun设计，避免了Node兼容层。
用户对其潜力赞不绝口，尤其是对于Bun用户而言，但也有人对其相对较大的二进制文件大小（58-109MB）表示担忧，与Go CLI等替代方案相比。开发者正在积极处理反馈，包括改进README和解决有关帮助插件格式的错误报告。“Hello World”示例会创建一个非常小的二进制文件（几十KB）。
该项目在GitHub上可用：https://github.com/chenxin-yan/crust.
## 从代码审查到 AI 生成代码验证 本次实验探讨了在生产环境中使用 AI 生成代码，*无需*人工逐行审查的可能性。作者将重点从“审查”代码转移到“验证”其正确性，无论如何实现。 核心方法是让 AI 解决一个简化的 FizzBuzz 问题，然后对解决方案进行严格的自动化检查：基于属性的测试（确保代码在各种输入下都能按预期工作）、变异测试（识别测试套件中的弱点）以及副作用检查。还实施了标准的 Python 代码风格检查和类型检查。 结果表明，这些约束可以建立对生成代码的足够信任，可能使可读性变得不那么重要——将输出视为更像编译后的二进制文件。目前，设置这些约束比简单的代码审查更费力，但作者认为 AI 代理和工具的改进最终将使这种方法可行。 该实验强调了向自动化验证的转变，并承认了形式化验证和“软件工厂”相关的工作，旨在实现零人工代码审查。代码和测试可供实验使用。
## AI 生成代码与验证：总结
讨论的中心是验证 AI 生成代码的挑战，从最初的兴奋转向更务实的观点。虽然 AI 可以快速*生成*代码，但确保其正确性和可维护性却很困难。
一个关键点是，AI 生成的代码并不比人工代码更或更不可信——它需要同样严格的审查。仅仅*与*代码一起生成更多的测试并不能解决问题；事实上，它可能会掩盖问题，因为即使逻辑存在缺陷，AI 也可能为了通过测试而“作弊”。
许多人认为，重点应该放在在代码生成*之前*清晰地*规划*和*明确*需求，并仔细审查这些需求和生成的测试，而不是代码本身。担忧不仅限于功能正确性，还包括安全漏洞（如硬编码凭据）和可维护性。
最终，共识倾向于将 AI 视为一个潜在的强大但仍然容易出错的初级开发人员——需要监督、测试和健康的怀疑态度。核心的工程挑战正在转向强大的测试策略和架构考虑，而不是仅仅关注代码生成速度。
8万 - 10万美元•0.10% - 0.50%•旧金山，加州，美国
职位类型全职
角色产品
经验任何（欢迎应届毕业生）
签证美国公民/签证
直接与YC资助的最佳初创公司创始人联系。
申请职位 ›
Richard Kreger
创始人
Richard Kreger
创始人
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
Spice Data (YC S19) 正在招聘产品专家 (ycombinator.com)
1天前 | 隐藏
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：