看得见的开源 | 记一次跨界产品研发小实验

stonstad

最近我们 SeedV 实验室用开源、免费、无广告的公益方式发布了一个家长可以和小朋友一起玩的算术认知小玩具——「看得见的计算器」：
这个小玩具的代码量不多，技术难度不大，但，这居然是一次非常有趣、超级跨界的开源项目小实验。我这就以主要技术贡献者的身份，聊聊这个好玩项目的来龙去脉。
“跨界”的缘起

我们一群六七个人，基本上是有 Google，Microsoft 等大厂工作背景的 CTO、技术总监、产品总监、设计总监，特别想在业余时间做些开源、公益的小事情，为我们喜欢的教育、科普领域免费做些小贡献，就商量着成立了一个叫 SeedV 实验室（http://www.seedv.cn）的创新创意团队。大家都无偿奉献，用 20% 时间来做点儿好玩的事儿。
其中一件事儿呢，就是这个「看得见的计算器」了。
故事是从我给我们家小朋友买了一个卡西欧计算器开始的。我发现，我家小朋友特别钟爱在计算器上乱按一气，然后看着屏幕上出现的各种结果——不管是超大、超小的数，奇怪的符号，还是溢出、除零等错误信息——或发呆，或欣喜，或大笑。当时就觉得，计算器可能是个有趣的儿童自我学习玩具。其实我小时候也有类似的经历。当年我拿着老爸或哥哥的科学计算器，总爱尝试一下计算器最大能算哪个整数的阶乘（ps, 有个简单的 IT 考古题：为什么很多科学计算机最大都只能算 69 的阶乘？大家有兴趣可以去钻研）。
计算器能扩展出哪些小朋友喜欢的功能呢？我就随手在 Unity 里（那段时间我特别愿意把 Unity 当作一个快速原型开发工具）写了几行代码，实现了一个把数字可视化的小程序。运行起来是下面这样的。


输入 5，就显示 5 只 Adobe Mixamo 开源角色库里跳舞的小老鼠。这想法太简单了，根本不能算个成熟的产品创意——直到我们 SeedV 实验室的几位同学一起看过这个小原型，一次超级跨界的科技产品研发才真正拉开序幕。
一开始的产品碰撞，我们就确定了”跨界“的主题——反正是做好玩的事儿嘛，为什么不把主题定得另类一些呢？于是，我们的”跨界“讨论集中在了下面几个议题上。
产品定义：天马行空

我们不想回答下面这些常见的产品经理必修问题：

• 这个产品如何赚钱？商业模式是什么？
  
• 这个产品的目标市场、目标用户是谁？
  
• 用户使用这个产品的主要情境、主要交互流程是什么？
  
• ……
  

我们特别想回答下面这些不着边际的”跨界“问题：

• 为什么输入 5 就展示 5 只小老鼠？为什么不能输入 5 就显示离银河系最近的 5 个河外星系的相对位置？
  
• 输入 4 x 5 就显示一个 4 米乘以 5 米的矩形，会是一个好主意吗？为什么不在输入 4 x 5 的时候显示正在与外星异种搏杀的五个坦克排，其中每个坦克排装备 4 辆光棱坦克？
  
• 用户一定要用手指、键盘或鼠标来输入吗？我们这群人里有搞 AI 的，有搞 AR 的。为啥不能让小朋友对着 iPad 的前置摄像头，一手比划 3，一手比划 8？点头加法，摇头减法，拨浪鼓一样晃脑袋就是 All Clear？
  
• 用户一定要在电脑屏幕里玩这个计算器吗？为啥不能在桌上撒一把黄豆，然后用手机拍照，计算每平方厘米里的黄豆分布？
  
• 或者，用户能直接戴上 VR 眼睛，亲身体验微观世界的 0.000000001 米有多矮，宏观世界的 8848 米有多高吗？
  
• ……
  

我们觉得，也许第一个版本做不到上面构思的每个东西。但，敢于构思以上产品设计命题的，才是最跨界的非主流产品经理。
当然，天马行空的梦想再多，也还是要回到产品落地的残酷现实里去。于是，做加法变成做减法。我们的产品总监在一个月的业余时间里搞了一大堆类似下面这样的功能与交互探索图。


考虑到我们这群人个个是大忙人，能分在这个项目上的时间、精力很有限。减法做到最后，我们决定先把特别天马行空的创意都收拾到 TODO 箱子里，给 Ver 1.0 只留下一个简单、明快、好解决、好发布的小问题：

输入或计算得到不同数字时，如何用有趣的可视化方式，让小朋友理解每个数字的数量级？

为什么选这个问题？因为这问题有趣，小朋友也特别需要呀。我就有强烈的感觉，小朋友掌握整数和整数的四则运算不难，但理解不同数量级经常是个挑战。别说小朋友了，很多大人也经常搞不清细菌和病毒的大小差几倍，一吨水和一吨铁的体积为什么差别那么大，为啥月球和地球之间的距离差不多还能装得下 30 个地球……
目前刚刚发布，大家能体验到的「看得见的计算器」就是对这个问题的直接回答。我们使用了相邻数量级参考物体两两对比的方式，将计算器屏幕上的数字后加上长度基本单位“米”，再用参考线展示出来。微观可达原子尺度，宏观可达黑洞量级，数学上正好是 10 的 -10 次方到 10 的 +10 次方之间的一段数值区间。


先把数量级可视化的事情做了，发布出去再说。未来版本，也许可以给计算器做几个不同的标签页，一个标签页用于可视化数量级，一个标签页专门可视化四则运算的数学含义，还有一个标签页可视化一部现代计算器的构成和原理，再多一个标签页专门让小朋友用 VR/AR 方式来与计算器交互……
用户体验：打破次元壁

我们团队的用户体验设计总师是大厂设计总监背景，顶尖高校数字媒体与设计专业教授。他带领的视觉与交互设计小组上来就给自己一个超级有挑战的目标：

能不能把 2D 世界里的视觉与交互设计语言，与 3D 世界里的视觉与交互设计语言，用某种方式融合起来？

为啥提这个目标呢？
好像也没有啥特别的原因，就是有趣、好玩呗。既然大家都是业余时间奉献爱心，一起想做点儿既公益又好玩的小事情，那为啥还非要遵守平常工作中那些 所谓的规矩呢？好容易有个可以在工作之余换口新鲜空气的场合，干嘛非要和自己过不去，又费劲巴拉地去找回熟悉的工作状态呢？
解放思想，丢掉束缚，才能完成些小探索、小创意嘛。
回到这个「看得见的计算器」的具体设计：

• 首先，计算器本身是个非常 2D 的交互体验。即便在真实世界中，我们平常使用计算器时，主要的操作行为——揿按键——也基本是发生在一个二维的几何结构里，没有人会正面揿个键再翻转过来反面揿个键。为计算器本身增加一个维度，对改进交互的价值几乎为零。
  
• 其次，不同量级长度的对比，本身是个纯一维的东西。一根数轴所代表的一维空间，就足以表示不同长度了。
  
• 最后，小朋友们更喜欢看见活灵活现的动植物、星球、细胞、细菌……从这个意义上说，漫画风格，以 3D 呈现的形体和动画是最接近小朋友要求的。
  

瞧，“在计算器里生动展示不同数量级”这么个不起眼的需求，本身就涵盖 1D、2D、3D 一共三个次元的概念。打破次元壁——这既是我们自己开放思维的小追求，也是产品本身的刚需呀。
基于打破次元壁的考虑，我们在实际开发 Ver 1.0 的产品时，非常清晰地将用户交互区域分成不同次元的元素组：

• 参考对象都是有动画的 3D 模型，属于三维世界的。
  
• 计算器的屏幕和键盘使用纯 2D 设计规范，属于二维世界。
  
• 可视化数值大小的白色指示柱只有一维方向的伸缩变化，属于一维世界。
  

最后，用一个标准参考网格（依附于可变底色的展示板）将一维、二维、三维世界链接在一起。为了将一维网格的尺度与参考对象的长度或宽度精确对照起来，整个世界的摄像机使用了正交投影（Orthographic Projection）。最终的效果好像还不坏。
下一步，设计团队还有计划在打破次元壁上更近一步：比如，在适合正交投影展示的场景和适合透视投影展示的场景之间，寻求一种无缝切换的体验；或者，在虚拟次元壁和真实世界之间，用 AI、AR 做一个双向的映射。
技术实现：轮子车子一起造

目前的开源领域，做 APP 类产品开源的很少，做基础架构、云服务组件、基础工具开源的极多。那我们为啥要把「看得见的计算器」这个明显是客户端 APP 的东东开源呢？
首先，我们做这个给小朋友用的计算器不是为了赚钱，何必藏着掖着，开源多好。
但另一方面呢，我们这个 APP 本身的功能，特别是 Ver 1.0 版本的功能挺有限的，开源出来也不过是一个小几千行代码的量级，对大家的参考意义不大。但这个 APP 所揭示的一些通用需求，是不是可能暗示着某些更值得开源的基础架构、基础工具类项目呢？
都说技术人员“尽量不要自己造轮子”。但我们既然想在业余时间做些有趣的事儿，为啥要在乎大家怎么说呢？
开源一个完成特定功能的「看得见的计算器」，这在代码和技术层面实在是没啥挑战。但如果开源一个方便未来开发类似产品的基础架构，那对码农来说，是不是就很有成就感？
于是，我们决定违背惯常的技术规律，轮子车子一起造！
对这个项目来说，所谓“车子”，比较好理解，就是完成计算器和数字可视化功能的一坨 Unity 代码。之所以用 Unity，也是因为 Unity 是同时满足以下三点的最顺手可用的工具：

• 很方便地开发 2D/3D 的跨界应用。这次我们的 Unity 代码在 3D 场景中，大量使用 UI 图层来混合 2D 场景、控件和描述文字。
  
• 简单实现一套代码，输出到多个平台。比如这次 Ver 1.0 我们就发布了 iOS（iPad）、macOS、Windwos 共三个平台。
  
• 未来在各个平台都比较方便连接我们计划的 VR、AR、AI 功能。
  

这些与“车子”相关的 Unity 代码，并不复杂，大家可以在「看得见的计算器」的开源项目中找到：
那，这个项目的“轮子”又是什么呢？
我们觉得，这个「看得见的计算器」，其实代表了一大类应用的两个抽象需求：

• 应用中有一个可以解析用户输入，完成计算的模块或虚拟机。例如，「看得见的计算器」内部必须拥有一个全功能的仿真“计算机”，或直接与宿主计算机的计算逻辑连接，否则如何完成四则运算？
  
• 应用中需要将计算模块或虚拟机正在处理的数据及处理数据的过程用可视化的方式展现出来。例如，在「看得见的计算器」里，我们需要用虎鲸、恐龙等对计算器上显示的数据做可视化。
  

如果只去实现「看得见的计算器」，那上面两个抽象需求完全可以用简单的代码，三下五除二加以实现。这没有任何问题。
但是，如果我们想挑战一下自己，去专门考虑考虑下面这些同类型，但复杂度远超计算器的需求呢？

• 例如，想象一个教学 APP，它可以接受计算机专业的学生输入一段《数据结构》习题答案，比如”实现红黑树“的代码，然后一边尝试运行代码，一边画出一棵真正的红黑树，并显示红黑树上每个节点的实时变化情况——如果学生的代码有错误，这个 APP 就能一目了然地指出学生代码到底为什么错了。
  
• 或者，再想象一个拥有数字孪生功能的自动化工作流系统，比如典型的 RPA 系统。当系统管理者或开发者为系统增加一个新的流程定义时，自动质检模块可以一边运行新的流程定义，一边在数字孪生世界用可视化的方式模拟一下每个工位如何在新流程中参与业务——如果新流程设计有瑕疵，一眼就可以从可视化的界面中定位瑕疵位置。
  
• 还可以想象一个由卷积神经网络驱动的自动驾驶视觉模块。当我们改进卷积神经网络的超参数并重新训练模型后，系统能不能在数字世界里模拟一下这个新的 AI 模型对车辆、行人、交通标志等对象的识别过程，并用可视化的方式将神经网络做推断（Inference）时的正向传播路径展示出来，尝试为开发者理解 AI 模型的行为逻辑提供帮助？
  

这些例子分别属于非常不同的领域，也都比「看得见的计算器」复杂千百倍，但他们确实共享了“可以解析用户输入并完成计算的模块或虚拟机”和“需要将被处理数据和处理过程用可视化方法展示出来”这两个特征。
基于这样的考虑，我们要不要搭建一个可以完成“全栈可视化”的计算框架呢？
“全栈可视化”是我们自己提的名词儿，意味着一个计算模块或一个负责计算的虚拟机，可以将内部每个层级的状态，实时、方便地输出到外部的应用级代码中，以便应用级代码将内部状态转换成用户容易理解的 2D、3D 语言。
大家可以将程序员熟悉的调试器（Debugger）想象成一个在程序运行时对运行过程做可视化的工具。我们的“全栈可视化”的概念类似一个增强版的 Debugger 框架，一方面比调试器输出的可视化标的更多，另一方面也更方便应用层级的 APP 集成或扩展相关功能。
于是，这项旨在构建低代码、全栈可视化的计算环境的任务，也已经启动了。项目的名字叫 SeedLang，目前刚刚开始很小很小的迭代。
这个项目需要的研发周期远长于「看得见的计算器」，目前只是积累了一个初步的设计框架。虽然已经可以编译、解释、运行一小部分脚本语言代码，然后将编译、解释、运行中的状态通过回调函数、事件等输出到外围应用，但已实现的功能集还非常有限。毕竟 SeedLang 的工作刚开始不久，目前除了可以完整支持一个四则运算计算器的可视化（你猜对了，「看得见的计算器」使用的计算引擎及可视化框架就是 SeedLang）之外，还不具备支持全功能脚本语言的能力。
下图是 SeedLang 一个初步的设计架构：


贴一段代码吧，用一个简单例子看看以前必须利用类似Debugger的接口才能做的数据检查及可视化的事情，如何利用SeedLang简单完成：
  private class Visualizer :
      IVisualizer<UnaryEvent>, IVisualizer<BinaryEvent>, IVisualizer<EvalEvent> {
    private int _step = 0;

    public void On(UnaryEvent e) {
      _step++;
      string operand = NumberInApples(e.Value.Number);
      string op = _unaryOperatorToString[e.Op];
      string result = NumberInApples(e.Result.Number);
      Console.WriteLine(
          $"STEP {_step}: {op} {operand} = {result}");
    }

    public void On(BinaryEvent e) {
      _step++;
      string operand1 = NumberInApples(e.Left.Number);
      string operand2 = NumberInApples(e.Right.Number);
      string op = _binaryOperatorToString[e.Op];
      string result = NumberInApples(e.Result.Number);
      Console.WriteLine(
          $"STEP {_step}: {operand1} {op} {operand2} = {result}");
    }

    public void On(EvalEvent e) {
      string result = NumberInApples(e.Value.Number);
      Console.WriteLine($"Result: {result}");
    }
  }
这个基于 SeedLang 的 Visualizer 可以把计算器解析和计算四则表达式的过程用红苹果来展示：


因为目前的 SeedLang 是 C# 实现的，类似上面的 Visualizer 可以很容易嵌入到 Unity 这样的 2D/3D 开发环境里，把命令行的红苹果变成侏罗纪的恐龙，或者浩瀚宇宙里的奥妙天体。
一切皆可能，万事皆有趣

总结起来，我们这个 SeedV 实验室肯定不是一个商业项目团队，也算不得正式的创业项目。目前，SeedV 实验室的使命就是聚集一批爱创新、爱探险的工程、科研、产品、设计老手。大家一起用“边玩边做事”的心态，探索我们觉得有趣的科技事物，跨界产品，未来场景，并长期坚持为开源社区或少儿教育等公益领域贡献我们的业余时间。
我们是一群不按常理做研发，不跨界不开心的非典型科技人。
我们的口号是：一切皆可能，万事皆有趣。
如果你觉得自己有类似的心态，喜欢做同样好玩的事儿，同时又有扎实的研发或设计根基——那就别犹豫了，快私信我，来一起玩耍，一起嗨！