
从软体按钮到保龄球馆,软件正在把现实变成可操作的界面
Jelly UI、Airport Simulator、新宿站 3D、Gaussian Splat 教堂和 OpenLaneLink 共同显示:下一轮产品差异不只在信息,还在能否把触觉、空间、物理和运行状态直接交给用户操作。
先看结论
这一轮 Hacker News 热榜里,最有意思的几件作品都在做同一件事:它们把原本只能被观看、阅读或想象的关系,变成可以直接操作的对象。Jelly UI 让按钮和输入框出现软体物理,Airport Simulator 让玩家用手画出航线,新宿站 3D 把复杂的室内通道摊开成一张可旋转的拓扑图,Gaussian Splat 把教堂变成可以穿行和剖开的空间,OpenLaneLink 则把保龄球馆的机械设备重新接回一套自己能维护的软件系统。
这不是单纯追求「更真实」的视觉效果。它们都在回答一个产品问题:用户能否从反馈里理解系统此刻的状态,并据此做出下一步动作。只要规则、数据或边界有一处含糊,现实感就会从优势变成负担。
截至 2026 年 7 月 21 日 08:00,这些帖子在当前热榜的抓取快照如下。分数和评论数会继续变化,不能当成永久排名。
| 条目 | 热度快照 | 被软件直接表达的对象 | 评论区的主要分歧 |
|---|---|---|---|
| Airport Simulator | 669 分,134 条评论 | 空间中的动态冲突 | 流畅上手,还是规则不够真实、移动端不够顺 |
| Jelly UI | 296 分,123 条评论 | 控件的触觉反馈 | 有趣的物理隐喻,还是无障碍与性能负担 |
| Shinjuku Station in 3D | 132 分,26 条评论 | 室内通道与层级拓扑 | 适合导航训练,还是数据不完整、几何被夸大 |
| Grace Cathedral Gaussian Splat | 46 分,6 条评论 | 真实建筑的可穿行细节 | 细节惊人,但扫描过程与数据边界仍不透明 |
| OpenLaneLink | 2821 分,336 条评论 | 机械设备的运行状态 | 低成本自建的自由,还是硬件安全与维护责任 |
1. Jelly UI:按钮开始有了身体
Jelly UI 是一个零依赖的 Web Components 库,把原生 HTML 表单控件做成带软体物理效果的界面。项目页列出 40 个自定义元素、一个脚本标签、暗色模式、RTL 支持和 WCAG AA 色彩 token。它仍然使用真实表单控件,变化的是按下、拖动和切换时的形变反馈。1
HN 帖子由用户
baldvinmar 提交,页面未公开其职业背景;抓取时有 296 分、123 条评论。2 正面反馈很直白:它有趣、打破了同质化的 AI 生成界面,也可能让精细动作能力较弱的用户更容易点中变大的交互目标。负面反馈同样具体,评论者指出演示页曾用 scroll-snap 干扰触摸板和中键滚动,部分浏览器上的动画卡顿,持续动画还可能带来 CPU/GPU 开销。作者在评论中采纳了几项修正:移除页面滚动捕捉,修复鼠标移出后释放仍触发点击的问题,并为系统开启
prefers-reduced-motion 的用户增加提示和手动覆盖入口。2这件事说明,物理隐喻必须服从浏览器原本的交互契约。用户可以接受按钮像果冻一样变形,却不会接受滚动失去控制、点击边界变得含糊,或因为关闭动画而误以为页面坏了。触觉感不是视觉装饰,它要和键盘、辅助功能、拖动取消、低性能设备一起成立。
2. Airport Simulator:把流畅感做成冲突管理
Airport Simulator 的作者是 HN 用户 apunen,页面没有公开其职业背景。帖子在当前热榜抓取时有 669 分、134 条评论。演示本身只有一个很清楚的动作:在机场地图上画出航线,让进场和起飞的飞机不要撞在一起。站点页面的公开元信息把它描述成一个以耐力为挑战的机场游戏,页面配有俯视视角的跑道地图。3 4评论区喜欢它的原因,恰好不是复杂系统,而是规则很快就能被摸出来。有人把它称作直觉式的
learn by doing,也有人说画线的手感让游戏很容易上瘾。作者补充了实现和难度曲线:项目使用 SvelteKit 和 PocketBase;前五分钟里,飞机生成间隔大约从 5 秒收紧到 1.5 秒,同时屏幕上的飞机上限从 3 架提高到 12 架,并用起飞机制制造可预期的拥堵。3批评也集中在反馈规则上。离屏碰撞会让玩家觉得自己输得不明不白,起飞飞机会打断原本顺滑的航线规划,部分评论者认为飞机可以在接近跑道时做出过于突然的转向。移动端还有另一类问题:触摸操作会和浏览器的边缘返回手势冲突,排行榜占据地图空间,作者后来增加了隐藏排行榜的按钮。3
这里的产品教训很实际:模拟器不需要复刻现实的全部细节,但每一次失败都要让用户能回放出原因。规则可以简化,因果不能突然消失。所谓沉浸感,很多时候只是用户知道自己为什么赢、为什么输。
3. 新宿站 3D:复杂空间先要变成拓扑
「Shinjuku Station in 3D」由 HN 用户
Gecko4072 提交,帖子页未公开其背景。演示页说明,它使用日本国土交通省发布的「新宿駅周辺屋内地図データ」加工而成,项目以 Three.js 方式展示车站内部结构。5 6这类地图的价值不在于把车站做得像一栋漂亮建筑,而在于把人脑很难同时保持的几层关系摊开:哪条通道在上面,哪部电梯连接两层,哪些路径实际是行人网络,哪些地方只是数据里的连接。评论者希望它进一步变成第一人称导航训练,让第一次去新宿站的人先在虚拟空间里熟悉路线;也有人直接贴出源码,称它性能很好。5
反方指出,地图缺少部分站台、隧道和与新宿三丁目站相连的路径。一些斜坡和层间距离也更像是为了表达拓扑关系而做的视觉夸张,未必对应现实几何。5 这不是小瑕疵。导航场景中,数据缺口必须让用户看得见,否则漂亮的 3D 视图会给人一种比实际更完整的错觉。
空间产品的关键指标因此不是多边形数量,而是语义能不能被读懂。用户需要知道一条线代表通道、扶梯还是抽象连接,也需要知道哪些区域没有被建模。可旋转只是入口,能否据此规划行动才是产品价值。
4. Grace Cathedral:从照片到可以检查的地方
Grace Cathedral 的在线演示由 Vincent Woo 负责场景采集与重建,使用 PlayCanvas 运行;页面还列出了 Donovan Hutchence、World Labs 的早期原型支持,以及 Grace Cathedral 提供场地。7 HN 帖子由
akanet 提交,抓取时有 46 分、6 条评论。8评论里最受注意的是彩窗、玻璃反射和一个可以把建筑切开的
Peek 功能。有人问作者是怎样在没有明显伪影的情况下得到这么干净的模型,也有人把它和作者此前用无人机拍摄 Sutro Tower 的案例联系起来:那个案例公开描述了几千张照片、RealityCapture 对齐和 gsplat 生成模型的流程。评论者只是据此前案例推测 Grace Cathedral 可能采用相近路线,Grace Cathedral 页面本身没有公开完整的采集参数,因此不能把这套流程直接当成该项目的已证实细节。8这类数字重建与普通全景图的差别,在于它把「看过」推进到「检查过」。访客可以从不常见的角度观察空间,研究者可以把细节带离现场,场馆也多了一个数字保存入口。但保存并不等于完整复制,扫描范围、拍摄时的遮挡、模型的尺度和加载性能都会决定用户究竟看到了什么。
现实感越强,数据边界越应该显式。一个能让人相信自己已经进入现场的模型,如果没有告诉用户哪里来自扫描、哪里来自推断,反而比一张普通照片更容易制造错觉。
5. OpenLaneLink:最有价值的界面在设备之后
HN 用户
section33 自称是一名拥有保龄球馆的 SRE。他写道,自己的场馆买下时只花了 10.5 万美元,而一套替换 2008 年计分系统的商业方案通常要 8 万至 12 万美元,单是每两条球道的替换部件就可能要 4000 美元。9他的原型把 ESP32、ESP-NOW、RS485、树莓派、Redis 和状态机接在一起。按帖子里的估算,单个球道对的原型成本约 200 美元,配置更复杂时约 400 美元,最终标题中的 1600 美元对应整套 8 条球道的系统。作者说,真正难的是固件和协议,而不是把一个控制器接到继电器上。9
评论区支持自建系统的人,关注的是开放协议、可替换控制板和数据所有权。有人建议用 Art-Net 或 sACN 把灯光控制接入现有网络,也有人讨论怎样让同一种 ESP32 控制器通过 HTTP API 配置不同的球道。反方没有否认低价的吸引力,但提醒球道机械设备的冲击力会轻易损坏电子硬件,维修时还必须遵守锁定挂牌等安全流程。9
更值得注意的是,作者计划把场馆逐步做成自助系统,但他也明确回应了「自助会不会抹掉人与人的互动」的担忧:自助终端是为了减少来回操作,也要保留召唤服务员和机械师的入口。软件接管的是状态流转,不该顺手接管场所的社交功能。
现实感不是滤镜,是一套反馈契约
把这五条帖子放在一起,能看到一个清晰的变化:软件正在从「展示对象」转向「让对象对用户做出反应」。按钮会形变,飞机会冲突,通道会叠在一起,建筑会暴露细节,继电器会真的触发机器。它们的共同难点不是画面够不够漂亮,而是系统有没有把状态、规则和边界交代清楚。
对产品和工程团队,至少有四个问题值得在上线前逐项核对:
- 反馈是否符合用户预期? 动画、碰撞、拖动和物理效果不能只追求惊奇,还要让用户知道动作何时生效、何时取消。
- 数据是否完整且语义可见? 3D 地图需要标出缺失区域,空间抽象需要解释符号,重建模型需要交代扫描与推断的边界。
- 退化状态是否仍然可用? 关闭动画、低性能设备、小屏幕、触摸手势和浏览器兼容性都属于产品本体,不是发布后的补丁。
- 真实设备出了问题谁负责? 自建硬件可以把采购成本压低,但安全、备件、协议、日志和维修流程会重新成为产品的一部分。
下一批有竞争力的界面,未必会更像电影。它们更可能让用户直接操纵一个空间、一套规则或一台设备,同时把系统的限制也摆在手边。 实现越接近现实,错误就越不能藏在漂亮的表面下。
Fuentes de referencia
- 1Jelly UI 项目页
- 2Hacker News 原帖:Jelly UI: Soft-body physics for native HTML form controls
- 3Hacker News 原帖:Airport Simulator
- 4Airport Simulator
- 5Hacker News 原帖:Shinjuku Station in 3D
- 6Shinjuku Station Indoor
- 7Grace Cathedral 项目页
- 8Hacker News 原帖:Immersive Gaussian Splat tour of grace cathedral, San Francisco
- 9Hacker News 原帖:I replaced a $120k bowling center system with $1,600 in ESP32s
Contenido relacionado
- Inicia sesión para comentar.