就像许多开发者质疑 flomo 简单一样，没有什么复杂的技术，几天就能重写一遍。

自己在研究 AI 产品时亦不能免俗，比如总是关注其用了什么新的革命性技术，但对于其背后实现的工程能力鲜少研究，很容易将其打上「开源技术套壳」的标签就敬而远之，认为这套壳不过尔尔，待到某日想要做之时便能信手拈来。

但其实这是一种十足的傲慢。你可以说 POE 不过是一个各种套壳 AI BOT 合集，但又有几人能从头到尾实现出来；即使是实现了，又有多少人能成规模化地提供类似服务？即使解决了服务的稳定性和并发量，又有多少人能合法合规地来实现？这还没有对利润和成本进行灵魂拷问……

其实回到原点来看，对于创业团队来说，重要的不是技术研发能力，而是应用技术的工程能力。

而所谓「工程能力」，**就是能因地制宜，利用现有资源实现目标取得成果的能力。**其中包括但不限于技术能力、问题分析和解决能力、资源管理能力、沟通协作能力、学习适应能力等等。

举几个例子。

flomo 使用的都是比较「古老」的技术。如果要写一个给自己用的版本，确实花不了多少时间，甚至还能在许多功能上雕出花来。

但如果想要给许多人同时提供全端的云同步能力，就不是那么简单了。首先需要有各个客户端的基础开发，还需要多端版本冲突的问题，网络不好的同步错误问题，以及高并发下服务器的负载怎么解决等。

或许你会说，这并不复杂，毕竟那么多产品都支持同步功能。没错，单看这个技术来说并不复杂，甚至有许多成熟的解决方案。但是要知道当时我们创业也不过三四个人而已，没有一分钱融资，那么如何尽可能在保证体验的情况下，尽可能降低服务器成本，提高研发效率？这就不仅仅是一个技术问题了，而是一个工程问题，需要诸多的判断与思考 —— 比如同步的频率是多少？网络不好如何重试？每个端的并发数量是多少？

再比如，在一定数据规模之后，使用搜索的行为变多，势必导致服务器压力过大。虽然有不少新技术能解决这个问题，但代价是更高的云服务器成本，这时候选择先进的技术从工程的角度来看就不划算了。

我们的解法是，在满足用户离线使用的场景下，顺势将搜索请求优先放在本地数据库中。这样每个人搜索时，如果本地有数据就会优先展示，根本不用去请求服务器。所以这个功能上线之后，成本甚至还降了一大截。

工程能力并不仅仅是在代码层面。

最近在做新产品「习惯点点」的时候，由于需要绘制大量的图标，就意识到设计的工程化能力远比设计能力更重要。

比如最初设计师画的单个图标很漂亮，细节非常丰富，配色也好看。但是画到十几个的时候，发现了诸多问题，比如透视不一致，有俯视有侧视有成角透视；抽象维度不同，比如钢琴到底是该写实还是抽象为黑白键等等……

虽然我相信设计师根据自己的能力肯定能完成本次的需求，但是花费的时间可能要 N 倍于现在，且最终结果未必会更好。而如果把图标数量扩展到上百个的时候，没有从设计工程角度解决上述问题时，人力成本将会几何级上升，甚至最终无法完成。

除了身边的例子，还想起了 SpaceX 让人拍案叫绝的工程能力。

Dragon（龙）飞船为了减少重量和太阳能板的故障率，没有采用传统的折叠太阳太阳能板，而是选择将太阳能板放在圆柱形船体的一侧（黑色），而另一侧则是隔热板（白色），用来降低对大气层的摩擦 —— 虽然太阳能板利用率低了点，但是奈何没有展开的机械故障了，安全了不少。

哦，对了，龙飞船的触控UI，其实是基于 Chromium + JavaScript 技术栈开发的。从这个角度来看，flomo 的客户端也接近于「航天级技术研发」了（笑）

这些都无关技术的先进性，更多是在现实条件的制约下，如何应用与组合现有技术，来达成目标，取得成果。

写这个话题，其实是一些自我反省。

因为有些时候自己过于喜欢追求先进理念，而忽略了动手能力。以为知道之后就有了一些智力上的优势，甚至可以用来出去吹嘘和标榜一个「业内人士」的身份，获得关注。

但真正落地的时候，就会被嗑的头破血流。比如知道 stable diffusion 的原理，知道 control net 的作用，知道 Lora 炼丹的效果。但是却从未动手将其组合起来，亲自运行一下，看看实际效果是什么样的。

可能内心深处还是认可马克思说的：重要的不是解释世界，而是改变世界。

所以不要瞧不起那些没什么技术含量的「开源套壳」产品赚的盆满钵满，至少他们在工程能力上表现优异。