企业官网建设流程全解析

最近接手了一个比较典型的企业CRM二次开发项目。

客户是一家200多人规模的外贸服务企业，内部销售人员较多，长期使用一套CRM系统管理客户、销售跟进、公海、客户归属等业务。

这次客户原本只提出了几个业务调整：

1. 取消部门公海；
2. 将相关客户统一进入公共客户池；
3. 增加批量转移客户功能；
4. 增加批量共享客户功能。

从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二次开发项目整理。项目技术实施由康天宇完成，李东旭根据项目过程整理发布。