有不少开发者质疑 flomo 简单一样，没用什么复杂的技术，几天就能重写一遍。其实自己在研究 AI 产品时亦不能免俗。

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

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

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

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

举几个例子。

如果 flomo 想要给许多人同时提供全端的云同步能力，该怎么选择？是写一个同步一下，还是用户点击保存之后同步一下？那么草稿箱同步不同步？如果网络不好怎么办？如果版本冲突了怎么办？

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

再比如，在 flomo 有一定数据规模之后，用户使用搜索的行为变多，导致服务器压力开始增加。虽然有不少新技术能解决这个问题，但代价是更高的云服务器成本，这时候选择先进的技术从工程的角度来看就不划算了。我们的解法是，在满足用户离线使用的场景下，顺势将搜索请求优先放在本地数据库中。这样每个人搜索时，如果本地有数据就会优先展示，根本不用去请求服务器。所以这个功能上线之后，成本甚至还降了一大截。

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