重要的不仅是技术,还有工程能力
date
Apr 4, 2024
slug
20240404
status
Published
tags
科技
summary
不要瞧不起那些没什么技术含量的「开源套壳」产品赚的盆满钵满,至少他们在工程能力上表现优异
type
Post
有不少开发者质疑 flomo 简单一样,没用什么复杂的技术,几天就能重写一遍。其实自己在研究 AI 产品时亦不能免俗。
比如总是关注其用了什么新的革命性技术,但对于其背后实现的工程能力鲜少研究,很容易将一些产品打上「开源技术套壳」的标签就敬而远之,认为这不过尔尔,待到某日想要做之时便能信手拈来。
但这是一种十足的傲慢。你可以说 POE 不过是一个各种套壳 AI BOT 合集,但又有几人能从头到尾实现出来;即使是实现出来了,又有多少人能成规模化地提供类似服务?即使解决了服务的稳定性和并发量,又有多少人能合法合规地来实现?这还没有对利润和成本进行灵魂拷问……
其实回到原点来看,对于创业团队来说,重要的不仅是技术研发能力,还有应用技术的工程能力。
而所谓「工程能力」,就是能因地制宜,利用现有资源实现目标取得成果的能力。其中包括但不限于技术能力、问题分析和解决能力、资源管理能力、沟通协作能力、学习适应能力等等。
举几个例子。
如果 flomo 想要给许多人同时提供全端的云同步能力,该怎么选择?是写一个同步一下,还是用户点击保存之后同步一下?那么草稿箱同步不同步?如果网络不好怎么办?如果版本冲突了怎么办?
或许你会说,这并不复杂,毕竟那么多产品都支持同步功能。没错,单看这个技术来说并不复杂,甚至有许多成熟的解决方案。但是要知道当时我们创业也不过三四个人而已,没有一分钱融资,那么如何尽可能在保证体验的情况下,尽可能降低服务器成本,提高研发效率?从这个视角看,同步功能就不仅仅是一个技术问题了,而是一个工程问题,需要诸多的判断与思考,没有标准答案 —— 而这些答案,如果没有实践,有什么坑,是从外部如何都不会知道的。
再比如,在 flomo 有一定数据规模之后,用户使用搜索的行为变多,导致服务器压力开始增加。虽然有不少新技术能解决这个问题,但代价是更高的云服务器成本,这时候选择先进的技术从工程的角度来看就不划算了。我们的解法是,在满足用户离线使用的场景下,顺势将搜索请求优先放在本地数据库中。这样每个人搜索时,如果本地有数据就会优先展示,根本不用去请求服务器。所以这个功能上线之后,成本甚至还降了一大截。
工程能力并不仅仅是指代码层面。
最近在做新产品「习惯点点」的时候,由于需要绘制大量的图标,就意识到设计的工程化能力远比设计能力更重要。
以上图前两行为例,最初设计师画的单个图标很漂亮,细节非常丰富,配色也好看。但是画到十几个的时候,发现了诸多问题,比如透视不一致,有俯视有侧视有成角透视;抽象维度不同,比如钢琴到底是该写实还是抽象为黑白键等等……
虽然我相信设计师根据自己的能力肯定能完成本次的需求,但是花费的时间可能要 N 倍于现在,且最终结果未必会更好。而如果把图标数量扩展到上百个的时候,没有从设计工程角度解决上述问题时,人力成本将会几何级上升,甚至最终无法完成。
除了身边的例子,还想起了 SpaceX 让人拍案叫绝的工程能力。
Dragon(龙)飞船为了减少重量和太阳能板的故障率,没有采用传统的折叠太阳太阳能板,而是选择将太阳能板放在圆柱形船体的一侧(黑色),而另一侧则是隔热板(白色),用来降低对大气层的摩擦 —— 虽然太阳能板利用率低了点,但是奈何没有展开的机械故障了,安全了不少。
哦,对了,龙飞船的触控UI,其实是基于 Chromium + JavaScript 技术栈开发的。从这个角度来看,flomo 的客户端也接近于「航天级技术研发」了(笑)
这些都无关技术的先进性,更多是在现实条件的制约下,如何应用与组合现有技术,来达成目标,取得成果。
写这个话题,其实是一些自我反省。
因为有些时候自己过于喜欢追求先进理念,而忽略了动手能力。以为知道之后就有了一些智力上的优势,甚至可以用来出去吹嘘和标榜一个「业内人士」的身份,获得关注。
但真正落地的时候,就会被嗑的头破血流。比如知道 stable diffusion 的原理,知道 control net 的作用,知道 Lora 炼丹的效果。但是却从未动手将其组合起来,亲自运行一下,看看实际效果是什么样的。
可能内心深处还是认可马克思说的:重要的不是解释世界,而是改变世界。
所以不要瞧不起那些没什么技术含量的「开源套壳」产品赚的盆满钵满,至少他们在工程能力上表现优异。