在一家机器人公司里的两年半——除了机器人,别的都是我建的

我上一份工作在斯坦德机器人(Standard Robots)——深圳的一家工业 AMR(自主移动机器人)厂商,我是这家公司全部内部系统的唯一开发:把一台机器人从一张 BOM 变成一台已交付、有人管的机器,靠的就是这些软件。我没有写他们的车队调度软件,也不会声称写过。我得到的是另一样更稀有的东西——而且如果你自己就是造机器的人,它更有用:两年半,从内部看一家机器人公司怎么运转。

我在那里真正做的

这家公司赖以运转的、除机器人之外的一切。作为内部系统的唯一开发,这包括:带 BOM 结构的供应链平台、替换掉外购产品的 CRM、报销系统、文件存储引擎,以及发版流水线。具体地:

• 一层让平台迁移变成零成本的中间件。公司系统和钉钉深度绑定,却要迁到飞书。我没有重写每一个集成,而是做了一层:对上模拟钉钉的规范,对下调用飞书 API——文件处理、事件回调、响应格式全部兼容。迁移最后变成改一行。
• 发版从数小时到一分钟。十几个系统靠手工发布,每次一小时到半天。我把它换成脚本化、区分环境的自动部署,前面挂一个内部页面。
• 一次谁都不希望需要的恢复。有人误删了某个系统里最底层的大分类,两天后才被发现。直接回滚会毁掉这两天的新数据。我读代码找出所有受影响的表、从日志定位到误操作时刻、用 MySQL binlog 复原当时状态,再写了一个幂等、可撤回的修复程序。数据全部找回,业务没有停。
• 更快的文件中心。把 S3 兼容的对象存储换成对小文件更友好的方案——小文件性能提升 50% 以上。

如果你造机器,这段经历为什么有用

这些系统是一家机器公司的神经系统,所以我用两年半读完了它的整个身体。一份配置怎么变成一张 BOM。一个机型变体怎么裂变成一堆料号。销售承诺了什么、生产实际能出什么。售后电话都从哪来、接电话的人最希望手里有什么信息。这些问题里,哪些最后用软件解决了,哪些只是被人忍着。

这才是我带进你项目里的东西,也是大多数外包开发者没有的东西。只写过应用的人会向你要一份需求文档。而一个从内部看过机器公司的人,已经知道那份文档为什么还不存在。

相邻的工程能力,说准确

两个人们理所当然会问的问题,不拉伸地回答。车队调度:他们的不是我做的。但我在别处做过一套任务依赖调度器:把多级依赖抽象成有向无环图,在执行前就识别出环路而不是死锁在里面,再按拓扑序执行——从结构上说,这和"把一个复合任务拆成有序子任务"是同一个问题,只是领域不同。设备协议:我动手做的协议工作(Modbus、OPC UA、MQTT、PLC)来自我自己的合同项目和本站的 demo,不是来自那份工作。如果你需要的是特定机器人厂商 SDK 的经验,直接问我,我会告诉你我的经验边界具体在哪。

证明

还能用在哪

如果你造设备,而且需要一个不用别人给他解释车间的人:随机出货的界面、设备对接,以及那些决定一台机器能不能按期出厂的内部系统。我当过那家公司里的那个人,我知道动手之前该先问哪些问题。

← 全部案例