不可能机器：物理世界的声明式编程原型（Show HN）

不可能机器是一个浏览器原型，它将声明式编程应用于物理世界：用户描述一个机制应产生的行为，系统则生成一个产生该行为的机制。它由@bhaprayan作为Show HN帖子提交到Hacker News，在页面被抓取时获得了36分和9条评论。

不可能机器实际做什么

不可能机器是一个设计画布，在这里首先指定期望的物理结果，然后从中推导出机械设计。原型自身的描述直接陈述了前提：

这是声明式编程在物理世界中可能呈现样子的一个原型。向系统展示你想要什么，然后观察一个机制出现。移动水槽，放置障碍物，改变形状。描述世界，不是它本来的样子，而是你希望它成为的样子。

同一页面将这项工作归功于“由@bhaprayan进行的思维实验”。

世界的词汇：源、修改器、障碍物、水槽和目标

界面展示的是零件与目标的词汇表，而非代码编辑器。被抓取页面快照中可见的标签有：

源和运动部件： 曲柄、重物
修改器和约束： 挡块、制动器、导轨
环境： 障碍物、水槽
目标： 铃铛、门

通过选择目标对象并告诉它要做什么来声明期望的行为。页面指示用户“点击铃铛以显示你希望它做什么”，并提供“敲响铃铛”作为可选目标。设定目标后，页面会呈现一个“工作设计”以及“其他设计”下的一组替代方案。

这是原型核心的可观察行为：用户在对象上设定意图，系统提供多个候选机制来满足该意图。被抓取的页面没有记录每个单独部件的语义，因此曲柄与重物，或导轨与挡块的确切作用，在可用源材料中未作说明。

挑战与自由工作台

不可能机器附带三个命名挑战以及一个开放沙盒。挑战列表如下：

绕道而行
战胜制动器
引导转弯

旁边还有一个“自由工作台”，用于在没有挑战目标的情况下进行构建。挑战框架表明该系统被定位为一个可探索的谜题空间，而非专业CAD工具：每个挑战都隔离了用户必须通过描述目标并接受或拒绝生成的设计来实现的特定机制行为。

界面要求横向方向

该网站以纵向渲染并带有限制。其方向通知写道：

不可能机器在横向模式下效果最佳，那里有空间来探索机制。

提供了“继续以纵向模式”选项，这意味着布局是围绕一个宽阔画布设计的，机制部件、障碍物和水槽可以并排放置和检查。

为什么“声明式”是有趣的主张

声明式编程意味着用户陈述什么应该是真的，而不是如何使其为真。不可能机器将该框架应用于运动部件：用户不是手动将连杆拖到位，而是声明一个结果——敲响铃铛、到达水槽、避开障碍物——然后该结果被转化为机械布置。

被抓取的页面没有描述底层方法，抓取时Hacker News线程中也没有链接技术文章。可观察到的是，该工具呈现一个主要的“工作设计”和额外的“其他设计”，这与对候选机制的搜索一致，而不是每个谜题的单一硬编码解决方案。这一区别对任何评估该原型的人都很重要，因为生成多个有效设计在本质上比解决一个设计更难。

Hacker News评论者将其与什么比较

该线程最有实质性的贡献是将原型置于先前工作的谱系中。评论者指出了三个参考点。

《不可思议的机器》。 评论者@pshc给出了最短且最易识别的比较：

有《不可思议的机器》的感觉。

《不可思议的机器》是1990年代的谜题系列，玩家在其中用零件组装鲁布·戈德堡式的装置。这一比较将不可能机器框定为相反的命题：不是组装机器并观察会发生什么，而是你陈述结果，机器为你组装。

迪士尼研究机构的连杆合成。 评论者@mcphage指出了关于生成追踪绘制路径的连杆的学术工作：

迪士尼的研究实验室几年前做过类似的事情，让一个点沿着路径移动。你绘制一条路径，它生成尽可能匹配该路径所需的连杆。从那以后他们有很多后续工作，但我记得这个视频：https://youtu.be/DfznnKUwywQ?si=F-5NZxKu4hP_mand

这是线程中提出的最接近的技术先例。绘制目标路径并让系统求解近似它的连杆，与不可能机器应用于敲铃和到达水槽目标的相同设计工作流反转，@mcphage指出这条工作线此后一直在继续。

微软研究院的运动工作。 评论者@jdw64引用了一份微软研究院的出版物，写道一个启发他们的过去项目“也有类似的实现”，并链接到一个URL以“motion-”开头的微软研究院出版物页面。被抓取评论中的URL被截断，因此无法从可用来源确认具体论文。

总的来说，线程的立场是声明式或逆向机制设计并非新研究，但基于浏览器的、立即可玩的表现形式是使该原型与众不同的地方。

最有力的具体功能请求：随时间的行为

最可操作的批评来自@skinfaxi，他观察到当前世界模型仅支持瞬时、二进制的目标：

这很酷！我认为扩展世界的语言会很有趣。目前与铃铛或门的交互是有限的（基本上是二进制的）。即使是二进制的，说敲铃三次或演奏“剃须与理发”也会很酷，然后一个能产生该频率的机械装置就会被创建（例如，一个简单的做法是跳过每隔一次的敲铃）。我想这需要世界/对象在某个记录周期内考虑交互。

这是一个有意义的架构点，而非表面请求。像“敲响铃铛”这样的目标是终端状态：机制要么达到它，要么没有。像“敲铃三次”这样的目标是时间序列，满足它需要系统在记录窗口内推理交互历史，而不是关于单一最终状态。正如@skinfaxi所指出的，交替敲铃的示例解决方案——门控每隔一次的敲击——在机械上很简单，但表达目标本身需要世界模型将时间作为一等维度来表示。

换句话说，当前原型的声明式语言涵盖了事物应该在哪里结束。将其扩展到涵盖事物应如何随时间展开是自然的下一步，这将改变系统可以搜索的机制类型。

线程中提出的开放问题

实现细节未披露。 线程中的首要问题来自@donalddominko，他玩了演示并询问源代码：

这实际上是一个非常有趣的想法。我看了演示并玩了它，我在寻找仓库链接——我想知道你是如何实现系统达成结果的。

被抓取的线程中没有出现仓库链接，评论集中也没有作者的回复。

参与信号薄弱。 该提交获得了36分和9条评论，但被抓取线程中每条可见评论的分数都是0，且一条评论被标记并未显示。因此，该线程最好被解读为一小组有见地的比较和一个强有力的功能请求，而非广泛的共识。

结论

不可能机器是一个提出特定问题的原型：如果你描述世界如你所愿而非其本来面目，物理机制的编程语言会是什么样子？它的答案是一个由源、修改器、障碍物、水槽和目标组成的画布，在其中选择结果——例如，告诉铃铛敲响——会返回一个工作设计及替代方案。Hacker News评论者将其置于从《不可思议的机器》到迪士尼研究机构的路径跟踪连杆合成的谱系中，最尖锐的批评是它的语言目前处理最终状态而非序列，因此像“敲铃三次”这样的目标超出了世界模型所能表达的范围。