CRM系统前端源码丢失后如何二次开发？AI分析API + Vue3/Vite重建前端实战-北京尧图网络

最近接手了一个比较典型的企业CRM二次开发项目。客户是一家200多人规模的外贸服务企业内部销售人员较多长期使用一套CRM系统管理客户、销售跟进、公海、客户归属等业务。这次客户原本只提出了几个业务调整取消部门公海将相关客户统一进入公共客户池增加批量转移客户功能增加批量共享客户功能。从CRM业务本身看这几个需求并不复杂。真正开始接手项目以后却发现一个更大的问题原Vue前端源码已经丢失。系统仍然能够运行数据库和后端源码也还在但是服务器上只保留了已经编译后的前端资源。这就使一个普通的CRM功能修改变成了一个典型的存量系统分析 API梳理前端重建原业务兼容新功能开发项目。一、项目现状接手时大致是这样的状态数据库完整后端源码基本完整后端API仍然可以使用现有系统正常运行前端编译文件存在 Vue原始工程丢失技术文档不完整原开发人员无法继续提供支持如果只是修改页面文字或者简单CSS可以尝试处理编译后的资源。但本项目要修改的是客户归属客户公海客户共享关系批量客户转移员工权限这些都属于真正的业务逻辑。继续在打包后的JavaScript上直接修改不利于长期维护。因此最终采用的方案是保留数据库和后端重新构建前端工程。二、为什么没有直接重做整个CRM企业系统二次开发中我一般不会轻易建议全部推倒重来。这套CRM已经有200多人使用里面不仅仅是一些页面还包含历史客户数据销售跟进记录用户账号部门数据客户归属关系权限体系公海规则业务记录如果整套系统重新开发就意味着还要处理历史数据迁移新旧系统切换权限重新设计用户重新培训业务流程重新验证上线风险所以这次的基本原则是能保留的尽量保留只重建已经失去维护能力的部分。也就是原数据库 ↓ 原后端业务 ↓ 原API接口 ↓ 重新构建Vue3前端这样改造风险会小很多。三、第一步不是写Vue而是先梳理后端API这是这次项目里最重要的一步。前端源码丢失以后不能一上来就按照现有页面重新画一套。因为我们首先需要知道后端到底提供了哪些接口每个接口是干什么的需要哪些参数返回什么数据当前权限怎么控制哪些接口还能继续复用因此先从后端源码入手。重点分析几类内容路由定义 Controller Service Model 权限校验请求参数响应结构客户相关业务代码四、AI在这里不是先写代码而是帮助“读代码”这次AI最大的价值并不是帮我生成一个CRM页面。而是帮助我快速理解一套陌生的旧系统。例如对现有后端代码进行分类后可以逐步整理出类似这样的接口表客户模块 GET /customer/list GET /customer/detail POST /customer/create POST /customer/update 客户关系 POST /customer/transfer POST /customer/share 公海模块 GET /pool/list POST /pool/receive POST /pool/release 用户模块 GET /user/list GET /department/list这里的接口名称只是为了说明梳理方式实际项目以原系统真实接口为准。AI可以辅助完成识别路由归类接口说明参数总结返回值分析模块关系整理接口文档寻找可能的调用关系这样就能快速形成一份旧系统API地图五、第二步把现有前端页面和后端API重新对应有接口还不够。还要知道现有系统里的页面到底如何使用这些接口。于是继续对照现有运行中的CRM。例如客户列表 ↓ 客户列表API ↓ 客户筛选API ↓ 客户详情API公海页面公海列表 ↓ 客户领取 ↓ 客户分配 ↓ 客户释放员工模块员工列表 ↓ 部门 ↓ 角色 ↓ 权限最终逐步建立页面 ↓ 功能 ↓ 操作 ↓ API ↓ 数据库业务这一层关系搞清楚以后才能真正开始重建前端。六、重新整理CRM功能结构通过API和现有页面两边对照重新整理出系统功能树。例如CRM │ ├── 登录 │ ├── 客户管理 │ ├── 客户列表 │ ├── 客户详情 │ ├── 客户编辑 │ ├── 客户转移 │ └── 客户共享 │ ├── 客户公海 │ ├── 公海列表 │ ├── 领取客户 │ └── 分配客户 │ ├── 员工管理 │ ├── 部门管理 │ ├── 权限管理 │ └── 系统设置这里最重要的一点是不要只是照着旧页面重新画页面。而是要重新确认哪些功能还需要哪些功能已经废弃哪些功能需要调整哪些功能需要新增比如这次客户明确不需要“部门公海”。那重建过程中就不应该机械复制原功能。七、Vue3 Vite重新搭建前端前面梳理完成以后才正式进入前端重建。这次采用Vue 3 Vite重建思路不是一次把整个系统全部写完。而是先搭基础框架。例如src ├── api ├── views │ ├── customer │ ├── pool │ ├── user │ └── system ├── router ├── store ├── components ├── utils └── layouts先完成登录 Token处理全局请求菜单路由权限列表分页表单弹窗这些基础能力。然后再逐步迁移业务页面。八、API层最好单独封装重建旧系统前端时我比较建议把API单独封装。不要在每个Vue页面里面直接写HTTP请求。例如可以按照模块分api/ ├── customer.js ├── pool.js ├── user.js ├── contract.js └── system.js逻辑上类似export function getCustomerList(params) { return request({ url: /customer/list, method: get, params }) }这样以后如果接口地址变化参数变化返回结构变化都比较容易统一调整。对于老系统重建这一点尤其重要。九、先恢复原功能再开发新功能我比较强调这个顺序。不要在前端重建的同时大量修改原业务。否则出了问题以后很难判断到底是新前端的问题还是旧API的问题还是新业务逻辑的问题所以先让客户列表正常客户详情正常查询正常分页正常权限正常公海正常然后再开发客户新增需求。这是降低风险非常有效的方式。十、批量转移客户怎么设计客户转移的本质是修改客户负责人。原来可能是客户A → 销售张三客户B → 销售张三客户C → 销售张三批量转移以后客户A → 销售李四客户B → 销售李四客户C → 销售李四前端交互大概是选择客户 ↓ 点击批量转移 ↓ 选择目标员工 ↓ 确认 ↓ 提交客户ID数组 ↓ 后台修改客户归属 ↓ 刷新列表请求结构逻辑上可以设计成{ customer_ids: [101,102,103], target_user_id: 18 }实际字段需要根据原系统数据结构确定。十一、批量共享客户和转移完全不是一回事这个地方容易做错。转移客户是修改所有权。共享客户则是增加一个访问关系。例如原本客户A 负责人张三共享以后客户A 负责人张三共享员工李四、王五所以客户共享最好不要简单修改owner字段。更合理的是建立类似customer_share关系。逻辑关系customer_id user_id share_permission created_at当然具体是否需要增加关系表要看原系统有没有现成的共享机制。如果原系统已经存在共享关系则优先复用原设计。十二、为什么CRM客户关系一定要区分“负责人”和“共享人”因为两者权限含义不一样。负责人通常拥有客户主要跟进权客户编辑权客户转移权客户成交归属共享人员可能只拥有查看客户添加跟进记录协同处理客户如果直接把两者混在一起后面销售统计和客户归属会非常混乱。这也是CRM二次开发时非常容易被忽略的一点。十三、公海调整不能只删一个菜单客户这次还要求取消部门公海。表面看好像把菜单删掉就行。其实不是。因为部门公海背后可能关联客户状态部门ID 员工权限自动掉公海规则客户领取权限客户分配权限客户查询条件所以修改这类功能前要确认“部门公海”只是UI概念还是已经进入了后端业务模型。如果后端逻辑依赖部门公海就需要一起调整。否则只删页面很容易留下隐藏业务问题。十四、AI为什么特别适合老系统二次开发经过这次项目我觉得AI在企业开发里有一个非常明显的价值帮助快速建立陌生项目的系统认知。传统接手老系统一般要做看目录看路由看Controller 看数据库找接口找页面看权限猜业务非常耗时间。AI可以在开发人员控制范围内辅助代码摘要模块分类 API归纳数据结构解释调用关系分析接口文档生成功能树整理它并不意味着开发人员可以不看代码。而是可以把大量机械阅读工作加速。十五、AI不能替代哪些事情这点同样重要。AI可以帮忙整理代码但是一些核心判断还是不能完全交给它。例如这个接口有没有安全问题原业务逻辑是否合理这个客户到底该属于谁共享权限应该开放到什么程度哪些数据不能被普通销售看到原接口能不能直接用于批量操作这些既涉及程序也涉及企业真实业务。最终必须由开发人员结合客户需求来判断。十六、老系统二次开发我现在更建议按这个流程做如果以后再遇到类似项目我会按照下面顺序处理1. 完整备份 ↓ 2. 判断源码完整性 ↓ 3. 分析数据库和后端 ↓ 4. 梳理API ↓ 5. 对照现有页面 ↓ 6. 建立功能地图 ↓ 7. 确定保留与重建边界 ↓ 8. 重建前端基础框架 ↓ 9. 恢复旧核心功能 ↓ 10. 开发新增需求 ↓ 11. 回归测试 ↓ 12. 分阶段上线这个流程比“看到页面以后直接开始改”稳定很多。十七、这次项目最后解决的其实不只是几个CRM功能客户一开始需要的是取消部门公海批量转移客户批量共享客户最后实际解决的是旧CRM前端源码丢失 ↓ 后端继续可用 ↓ AI辅助分析API ↓ 重新整理系统功能 ↓ Vue3 Vite重建前端 ↓ 恢复CRM基础能力 ↓ 继续完成新业务需求这其实是非常典型的企业存量系统改造案例。总结企业软件项目和从零写Demo完全不同。大量真实项目都是系统已经运行多年原开发人员离开文档不完整源码不完整企业仍然必须继续使用这种情况下不一定要全部推倒重做。更合理的方法可能是先把旧系统重新看懂保留还能继续使用的数据库和后端再重建失去维护能力的部分。这次AI在项目里的价值也不是“替我写一个CRM”。而是帮助完成了旧代码理解、API梳理、系统功能重构以及前端重建前的认知工作。最终再通过Vue3 Vite让这个已经失去前端源码的CRM重新具备了持续开发和维护的能力。我觉得这可能也是AI时代企业软件开发里一个越来越常见的场景不是AI帮我们从0做一个新系统而是AI帮我们把多年以前别人留下来的系统重新接起来。本文根据金雨科技实际CRM二次开发项目整理。项目技术实施由康天宇完成李东旭根据项目过程整理发布。

CRM系统前端源码丢失后如何二次开发？AI分析API + Vue3/Vite重建前端实战

相关推荐

Kubernetes集群——网络管理

Nginx 进阶（HTTPS / 动态站点 / PHP / 反向代理）与 ECshop 实战

CF2259B Minus Two

更多资讯

VSCode配置C++环境：从编译器安装到可调试工程的完整指南

编译原理期末试题解答：DFA最小化与LL(1)分析表手算模板

2026年技术交叉风口：AI智能体、6G、量子计算与碳纤维

深入理解C++ SFINAE：从enable_if到void_t，掌握模板编译期类型分发

开源能源管理系统MyEMS实战：部署、数据采集与告警全解析

职场心理博弈漫画创作指南

今日更新

声子晶体仿真：三角晶格与六角晶格的能带计算实战

度假村安保定岗定编：岗位梳理、编制测算与排班设计

COMSOL等离子体模块实战：氩气双层DBD仿真建模全解析

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？