一个丢了前端源码的CRM项目，我是怎么用AI重新把前端搭起来的？

最近做了一个挺有意思的CRM系统二次开发项目。

客户是一家做外贸服务的企业，员工大概有200多人。

他们自己的客户主要是那些有外贸需求的企业，所以内部销售人员很多，CRM也是他们日常工作里非常重要的一套系统。

这套CRM不是他们从零开发的，而是以前基于一套开源系统改出来的。

用了几年以后，随着公司自己的销售流程发生变化，他们发现原来的一些功能已经不太适合现在的业务了，所以找到我，希望在现有系统上继续修改。

一开始听起来其实并不复杂。

他们主要想改几个功能。

第一，是把原来的“部门公海”去掉。

普通CRM里面经常会设计公司公海、部门公海。所谓公海，可以简单理解为暂时没有具体销售人员负责的客户池。

但他们现在的销售管理方式不再需要部门公海，希望统一到一个公共客户池里面。

第二，是增加批量转移客户关系。

比如一个销售离职了，或者业务调整了，他名下有100个客户，不可能一个一个打开再修改负责人。

需要能够一次选择多个客户，直接转移给另外一个销售。

第三，是增加批量共享客户。

共享和转移还不一样。

转移以后，原来这个客户负责人可能就发生变化了。

而共享是：

这个客户还是我的，但另外一个同事也可以一起看到、一起跟进。

这些其实都是CRM里面非常典型的客户关系管理功能。

如果系统源码完整，这个项目本来并不算特别复杂。

真正的问题出在后面。

前端源码找不到了

我拿到项目以后才发现，他们现有系统虽然还可以正常运行，但是原来负责开发的人已经找不到了，而且公司内部员工本身也不懂程序。

最关键的是：

前端源码丢了。

原来的前端是Vue做的，但是现在服务器上留下的基本是已经编译好的文件。

这意味着什么？

页面还能打开。

系统还能用。

但是你要继续修改前端功能，就非常麻烦了。

因为编译后的JavaScript和原始Vue工程完全是两回事。

没有原来的组件结构，没有路由配置，没有完整页面源码，也没有原来开发人员的工程组织方式。

这时候如果只是改一个文字、改一点样式，也许还能想办法处理。

但客户现在要改的是客户关系、批量转移、批量共享这些真正涉及前后端交互的功能。

继续在编译文件上硬改，我认为意义已经不大。

所以最后我做了一个决定：

前端重新搭。

但是重新搭前端，又遇到第二个问题：

原来这个CRM到底有多少功能？

后台接口都有哪些？

哪个页面调用哪个接口？

权限怎么控制？

菜单怎么来的？

如果靠人工一个接口一个接口地看，再一页一页对照现有系统，工作量其实很大。

这个时候，我开始把AI真正放进开发流程里。

我没有先让AI“写页面”，而是先让它帮我读系统

我现在越来越觉得，AI写代码真正有价值的地方，不只是：

“帮我写一个登录页面。”

这种东西其实很简单。

AI在真实项目里更有价值的一件事，是：

帮你快速理解一个陌生的旧系统。

我先把现有后端代码进行整理。

从路由、Controller、接口定义以及相关业务代码入手，让AI帮助分析：

系统现在到底有哪些API；

每个接口负责什么；

需要哪些参数；

返回哪些数据；

哪些接口属于客户；

哪些属于联系人；

哪些属于销售；

哪些属于公海；

哪些涉及权限；

哪些能够直接继续使用。

然后我再把现有在线系统中的菜单、页面和功能跟这些接口进行对应。

慢慢就形成了一张新的系统功能地图。

原来很多散落在代码里的东西，开始变得比较清楚：

前端有什么页面，后台有什么接口，两边之间是什么关系。

这一步做完以后，我才开始真正重新搭前端。

用Vue3和Vite重新建立一套前端工程

这一次我没有继续照着原来的旧工程恢复。

既然已经没有源码了，我干脆重新建立了一套新的前端框架。

技术上采用了：

Vue3 + Vite。

然后按照前面已经整理好的系统功能和后端API，一块一块把原来的前端功能重新实现出来。

登录。

菜单。

客户列表。

客户详情。

公海客户。

销售人员。

权限。

查询筛选。

分页。

各种业务操作。

先保证原来应该有的核心功能能够恢复，再继续开发客户真正需要的新需求。

这个过程实际上有点像：

后台房子还在，但是前面的装修图纸丢了。

我先把房子里面所有水、电、管线重新查了一遍，然后根据现有结构重新画图，再重新装修前面这一层。

真正难的不是重新写一个页面，而是保持原业务能继续跑

如果只是重新写一个CRM前端，其实并不难。

真正麻烦的是：

客户已经有200多人在使用这套系统。

原来的数据还在。

原来的后台还在。

原来的业务还在每天运行。

所以不能说：

“我重新给你做一套CRM算了。”

那样意味着数据迁移、业务切换、员工重新学习，风险会一下变得很大。

这个项目真正合理的方式，是尽量保留原有后端和已有数据结构。

先理解它。

再利用它。

只把已经无法继续维护的前端重新建立起来。

然后在这个基础上做新的功能。

这样客户原来积累的数据和业务逻辑可以继续使用，同时前端又重新获得了可维护性。

前端重新搭起来以后，后面的修改反而简单了

前端工程重新建立以后，再去处理客户最开始提出来的需求，事情就变得正常很多了。

比如原来的部门公海逻辑需要调整，就重新整理客户池展示和相关权限。

批量转移客户，本质上就是：

前端选择多个客户，选择新的负责人，再调用对应的批量处理接口。

客户共享则要明确：

谁是原负责人，谁拥有共享跟进权限，哪些人可以看到这个客户。

这些功能本身并不算特别复杂。

这个项目真正费时间的地方，其实是前面的：

把一个缺失前端源码的旧系统重新搞明白。

这个项目也让我重新理解了一下AI编程

现在很多人讲AI编程，最容易展示的都是：

“输入一句话，AI给我做了一个网站。”

这种演示看起来很震撼。

但我自己真正做项目以后，反而觉得AI在企业软件开发里有另外一种更现实的价值。

比如这次。

我不是让AI凭空开发一套CRM。

而是让它参与：

分析旧代码；

梳理后端接口；

识别系统功能；

整理接口与页面关系；

辅助建立新的前端结构；

再帮助完成具体功能开发。

它更像一个可以快速阅读大量代码、帮助开发人员建立系统认知的助手。

特别是在接手别人留下来的项目、老系统、二次开发项目时，这种能力其实非常有用。

AI没有替代开发，而是改变了我处理旧项目的方法

如果没有AI，这个项目当然也可以做。

无非就是人工慢慢查。

一个接口一个接口找。

一个页面一个页面对。

一点一点建立对整个系统的理解。

但是有了AI以后，这个过程明显可以加快。

以前做这种二次开发，最大的成本之一，其实就是：

先搞明白别人当年到底写了什么。

而现在AI非常适合帮助处理这一段。

当然，最后哪些接口真的能用、权限逻辑对不对、数据有没有风险、客户业务到底应该怎么调整，这些事情还是需要人来判断。

所以我现在越来越不太喜欢说：

“AI会不会替代程序员？”

我更关注的是：

会用AI的开发人员，处理陌生系统和复杂存量项目的方式，已经开始发生变化。

写在最后

这个项目最后顺利完成并交付了。

从客户一开始只是想修改几个CRM功能，到后来发现前端源码已经丢失，再到重新分析后端接口、梳理完整功能、使用Vue3和Vite重新搭建前端，最后继续完成客户需要的公海、客户转移和客户共享功能。

整个过程其实很典型。

企业里的系统不会永远从零开始。

大量真实的软件项目都是：

别人开发过。

用了很多年。

开发人员走了。

文档没留下。

代码不完整。

企业还得继续用。

以前碰到这种项目，最怕的就是：

没人敢接。

但AI出现以后，我觉得这种老系统的维护、分析和二次开发，反而出现了一种新的工作方式。

不是推倒重来。

也不是让AI闭着眼睛重新写一套。

而是：

先用AI帮助理解旧系统，再由人判断怎么保留、怎么重构、怎么继续往前走。

对企业来说，这可能比“AI一分钟生成一个新网站”更有实际价值。

因为企业真正需要解决的，很多时候并不是：

再做一个新系统。

而是：

怎样把已经用了很多年的旧系统继续救活，并且让它重新具备持续开发的能力。

本文根据金雨科技实际CRM二次开发项目整理。项目技术实施由康天宇完成，李东旭根据项目过程整理发布。