结语：为过去与未来保留交互知识

即使 Proto UI 自身没有成为主流，这项工作还可能留下什么？

序章里，我们问过一个有些夸张、但确实反复发生的问题：我们还要发明多少遍 Button？

现在回头看，真正需要保留的当然不是某一份 Button 的代码。框架会改变，平台会更替，今天的最佳实践也可能成为未来的历史包袱。如果只是设法让一份旧实现永远运行，我们保存下来的很可能只是旧技术，而不是其中积累的交互知识。

Proto UI 想保留的是另一种东西：一个组件为什么仍然是这个组件，它与 User、Maker 和其他 Component 承担什么关系，它怎样保存状态、形成结构、经历时间，又允许具体 Host 在哪里作出不同选择。

我们把这些理解写进 Prototype，使它成为一份可以运行的当前近似；再通过翻译，让它进入具体技术；最后比较不同产物是否保留了应有的语义，并让实践中出现的失败反过来修正这份近似。

因此，Prototype 不是用来封存答案的时间胶囊。它更像是一份可以继续被询问的交互知识：当未来出现一种新的 UI 技术时，我们未必还能复用今天的 DOM、widget 或事件系统，却仍然可以询问同一个 Switch 应该保存什么状态、接受什么操作、给出什么反馈，以及向外界承担什么责任。

新的技术可能顺利承接这些责任，也可能证明其中一些定义过于依赖今天的经验。两种结果都有价值。前者让既有知识获得新的实现，后者则帮助我们看清，哪些内容从来就不该被当作跨技术的共同部分。

Proto UI 并不认为，技术历史必然会走向 Prototype，也不认为只有 Proto UI 才能完成这件事。

我们提出的某些分类可能不够准确，一些 Component 可能远比预想中更难移植；未来也可能出现另一种更简洁、更有解释力的模型，以完全不同的工程形式解决同一个问题。Proto UI 可能只是其中一次不完整的尝试，甚至不一定是最终被广泛采用的那一次。

但这不会让问题本身失去价值。

只要人们仍在不同技术中反复建设相似的交互，只要重要的无障碍经验、状态模型和组件协作方式仍会随着技术栈变化而被迫重写，那么“怎样保存这些知识”就仍然值得被实践。一次有边界的尝试可以为一些想法提供支持，也可以推翻另一些想法；另一套原型理论、另一个开源项目，甚至一个与 Proto UI 没有关系的技术，也可能把这条路走得更远。

我们在意的不是由谁垄断这个答案，而是这个问题最终能否得到更好的答案。

如果这些交互模型能够被长期维护，它们就有机会成为人类公共基础设施的一部分。

这里的“基础设施”并不意味着所有平台使用同一份代码，也不意味着 Host 的差异会消失。新的设备仍然需要新的输入适配，新的渲染技术仍然需要新的翻译工作，不同的交互媒介也会提出过去没有遇到过的问题。

我们希望改变的是工作的起点。

当一种新的技术或交互形式出现时，人们不必先从空白开始，重新发现一个组件最基本的状态、关系和责任。他们可以从已经保存下来的模型出发，判断哪些语义仍然成立，哪些需要翻译，哪些应该根据新媒介重新设计。新的发现也可以被带回这份公共知识，让仍在使用的旧技术和后来出现的新技术都有机会从中受益。

这样一来，更多精力就可以用于改善交互本身：研究一种新输入方式应该怎样反馈，细化它对不同障碍人群的无障碍要求，重新判断某种平台习惯是否真的适合 User，或者发现过去的模型遗漏了怎样的参与者和关系。技术实现仍然重要，但它不再需要独自承担保存全部交互知识的责任。

Proto UI 希望为这份基础设施提供一种可执行、可翻译，也允许被修正的形式。它能走多远，只能由今后的实现与使用来回答。

如果有一天，新的技术不再需要从重新发明 Button 开始，而能够从继续改善人与软件如何相处开始，那么无论完成这件事的名字是否叫 Proto UI，这项探索都值得。