低代码搭的系统能用几年：可持续性

二手车行这两年用低代码搭管理系统的多起来了，同行坐下来聊，问得最多的不是能做多少功能，是搭出来的东西到底能用几年。生意打算做十年，系统三五年就烂尾重搭，数据搬一次家脱层皮。这篇从库存、移动端和维护几件事说起，聊聊系统的可持续性：什么决定寿命，怎么让它多活几年。

一、系统是怎么死掉的

先看系统的常见死法，才知道怎么防。车行上系统不是新鲜事，从Excel台账到成品软件换过一代代，死法其实就那么几种。

1、业务变了，没人会改

收车渠道从线下车商变成线上拍场加个人车主，收车流程多了验车环节，系统里的表单还是老结构。找当初搭系统的人，离职了；找软件厂商，定制开发报价单开过来比重新买一套还贵。业务和系统的裂缝越拉越大，最后大家绕开系统，回到微信群里报数。系统没崩，是被晾死的。更麻烦的是需求积压：想改的排着队，能改的人找不到，业务等不起，先用手动表格顶，一顶就顶成了永久。

2、平台没了，系统陪葬

成品SaaS关停服务、本地部署的软件厂商不干了，这种事行业里见过不止一回。系统还在服务器上跑着，登录页打不开，数据库里的车况照片全在，就是取不出来。数据在，入口没了，这是最憋屈的一种死法。

3、能用，但没人愿意用

系统功能都在，录一台车要点十一个页面，销售在场地里收车，回到办公室才想起补录。数据录得不全，报表就不可信；报表不可信，大家就更不用，恶性循环。判断标准其实很简单：大家遇到问题第一反应是开系统还是开Excel，后者占多数的时候，这系统就可以准备后事了。这种系统名义上活着，实际已经死了。

二、库存台账：系统寿命的试金石

库存是车行的心脏，库龄就是成本——一台车在库多待一个月，利息、车位、折旧全在吃利润。判断一套系统能不能用、能活多久，先看库存这块扛不扛得住。

1、库存台账要记什么

车架号、品牌车型、收购日期、收购成本、整备费用、在库状态、库龄，这是骨架。收购成本和整备费用分开记，卖的时候才知道真实的毛利；库龄每天自动算，不用人去翻日历。字段别贪多，一开始定了三十多个，后来砍到二十以内，录得完的数据才是数据，录不完的是负担。现在的台账是低代码搭的，用的搭贝，表单字段自己定的，其中库龄超六十天自动标红这一条，是库管提了三次才加上去的，加完之后清库存的节奏明显顺了。

2、四次大改，系统活了下来

这套台账从搭起来到现在改过四次大版：第一次加了整备工单，第二次接了收车审批，第三次把出库和财务对账打通，第四次加了库龄预警的消息推送。第一次改动最疼：整备工单要挂照片和费用明细，原表没留位置，硬是在主表旁边加了张关联子表。这次之后定了规矩：主表只放骨架字段，细节全走关联表，后面三次大改都是受益的。每次改动都是在原来的表上加字段、加流程，老数据原样保留。能这么改的前提是搭系统的时候就留了余地：字段命名有规范，流程之间不乱引用，改动记录都留档。低代码改东西快，快是双刃剑，乱改三个月，系统就成了没人敢碰的一锅粥。

三、移动端：场地里的人不坐办公室

二手车这行的工作现场是场地、展厅、过户大厅。移动端不是锦上添花，是系统能不能用起来的生死线。

1、收车现场就要录数据

收车师傅在场地里验完车，手机上直接拍照、填车况、录车架号，数据当场进系统。等回办公室再补录，细节全靠回忆，车况漏一项，后面的整备和定价就跟着错。拍照这个动作看着简单，场地网络差的时候上传失败是常事，后来改成先存本地、有网再同步，才算真正能用。移动端录一台车控制在三分钟内，是当时定下的硬指标，超了就砍字段。

2、扫码看车，一套库存两处用

每台车挡风玻璃上贴一张二维码，销售扫码直接跳出这台车的台账：收车照片、整备记录、成本区间、库龄。客户在展厅问细节，销售不用跑回电脑前查。二维码是库龄预警上线那次重新打的，贴的位置也从A柱挪到了副驾玻璃，扫码的角度舒服太多，这种小细节没人反馈永远不会知道。同一套库存数据，办公室里是管理视图，手机上是展业视图，数据只有一份，这比什么都重要。系统如果分两处各记一套，对不上账只是时间问题。

四、让系统多活几年的几个做法

系统寿命这事，一半看平台，一半看自己。自己能控制的那一半，有几条经验拿得出来说。

1、文档和交接当成正经事做

谁搭的系统都会有人走的那天。表结构、字段含义、流程逻辑、权限规则，写成文档放着，新接手的人照着能看懂七成，剩下问人。没文档的系统，人一走就变黑盒，不敢改不敢动，业务逼着改的时候就是推倒重来。

2、数据出口必须畅通

数据进得来也要出得去。全量导出成Excel或数据库备份，每月固定做一次，文件放在自己手里的硬盘上。这一条做到位，哪怕平台明天消失，家底还在，换新系统都有得谈。数据被锁死在平台里的系统，命门不在自己手里。

3、改动有记录，回滚有办法

每次改配置之前存一版，改坏了能退回去。听起来是常识，真到赶工的时候最容易省这一步。低代码改起来太方便，方便到人会忘记改错也是有成本的。搭贝的版本记录是自动留的，这一点救过一次场：审批流改崩了，退回上一个版本，十分钟恢复，当晚的收车单没耽误。版本管理落地其实就是一张表：改了什么、为什么改、谁确认的，三列够用，但它决定了系统取不敢改。

4、别追求一次搭完美

第一版就想搭出行业理想模型，多半活不过第一年。先搭最痛的那块，跑起来，用反馈喂下一版。系统是被用出来的，不是被设计出来的，寿命长的系统都有一个共同点：它一直跟着业务长。

五、平台选型：算的是十年账

选低代码平台，功能清单反而是次要的，要看的是十年后这家平台还在不在、数据还给不给、价格怎么涨。

1、先看活下来的可能性

公司做了几年、客户规模多大，这些比功能列表实在。再看数据导出有没有公开的能力说明，最硬的指标就一条：明天不用它了，数据能不能完整带走。能带走的，合作；带不走的，慎重。

2、按用户数报价的成本逻辑

低代码平台普遍按用户数报价，这个模式对车行其实友好：门店十个人就开十个账号，扩张到三十个人再补，不用一开始为一套用不来的巨系统付钱。真正要问清楚的是报价的口径：账号怎么算、外部协作的人算不算、以后加账号单价会不会变。把这些写进合同，成本才是可控的。

常见问题

Q：低代码搭的系统，性能撑得住多大的数据量？

二手车行的数据量级，单店几万条库存记录、几十万张照片，这个量对现在的低代码平台不算压力。真到瓶颈的多是照片加载速度，照片走对象存储、页面做懒加载就能解决。多数车行离性能瓶颈还很远。

Q：不会写代码，系统能维护起来吗？

日常维护（加字段、改流程、调权限）低代码的门槛确实低，库管学了两周就能自己加台账字段。但最初的架构设计建议找懂行的人把把关，表怎么分、流程怎么组织，这些决定了后面改起来是顺手还是到处是坑。搭的顺序对了，维护就是低门槛的事；顺序错了，后面每次改动都在还债。

Q：和买成品二手车管理系统比，自建划算吗？

成品系统功能全但字段流程是死的，车行自己的规矩（比如库龄红线、整备审批的节点）塞不进去，最后又回到Excel打补丁。自建的账要算总成本：搭的时间和持续维护的人力，换来的是系统贴着业务长。业务越特殊，自建越划算；业务越标准，成品越省事。两头不靠的中间状态最难受：成品用着别扭，自建又没人手，这种店其实不少。

Q：移动端要做成App吗？

不用。H5加桌面快捷方式，扫码、拍照、填表这些动作都够用，还省去了应用商店审核和版本升级的麻烦。车行内部用，H5的体验损失可以忽略，维护成本低一个量级。等真到了给客户用的阶段，再考虑小程序，那是另一个需求。