YikaiLiu 关于技能作品经历 Blog 联系

Digital Sales Map

化工销售数据管理系统

7 天内独立完成从需求调研到部署上线的全栈数据管理平台，利用 AI 辅助开发（Vibe Coding）为传统化工企业构建可视化销售管理工具，现已在内部试点团队使用。

类型

企业内部工具（真实业务场景）

周期

约 7 天（从需求调研到部署上线）

团队

1 人（独立完成全部工作：需求分析、产品设计、全栈开发、部署运维）

成果

已上线 · 客户内部试点团队使用中

技术栈

React + TypeScript + TailwindCSS + ECharts（前端）/ Node.js + Express + Prisma + PostgreSQL（后端）/ Nginx + PM2 + 阿里云 ECS（部署）

我的角色

产品经理全栈开发部署运维AI 辅助开发（Vibe Coding）

Live Demo · system.kaixingwuliu.com GitHub

一、

项目背景（Why）

业务场景

化工贸易企业，3 品类 / 5 销区 / 31 省市

xx 化工企业（客户要求保密）是一家化工产品贸易公司，主营纯碱、尿素、小苏打三类产品，全国设有 5 个销售区域，覆盖 31 个省市，销售团队分布在不同大区。本次受邀协助制作可视化销区管理系统。

问题

Excel 表格管理的三大痛点

公司的销售数据管理长期依赖 Excel 表格——客户信息、区域分配、销量统计全部靠手动维护的电子表格。随着业务增长，这种方式暴露出明显的痛点：

数据分散：不同销区的数据各自为政，没有统一视图，管理层难以快速了解全国业务全貌
更新滞后：Excel 手动维护效率低，数据更新不及时，销区之间信息不对称
可视化缺失：纯数字表格无法直观展示区域分布和销售热度，管理决策缺乏数据支撑

核心判断

简单 > 功能多，能用 > 好看

这不是一个需要复杂功能的系统——业务方需要的是一个简单、直观、能快速上手的工具，把散落在 Excel 里的数据变成一张「看得见」的全国销售地图，同时保留他们熟悉的 Excel 导入方式作为数据录入通道。

二、

需求调研与产品定义（How）

业务调研

组织架构 + 数据特点 + 特殊业务规则

与销售团队沟通后，梳理了现有的业务结构和数据流：

组织架构

全国分为 5 个销区，每个销区设大区经理 1 名
销区下设业务经理、办公室 / 内勤、业务员
每个省 / 市有对应的业务员负责，部分客户跨多个区域

数据特点

三类产品（纯碱 / 尿素 / 小苏打）各自独立管理客户
一个客户可能在多个城市有业务，需要按城市分别记录销量
销售团队习惯用 Excel 维护数据，任何新工具都需要兼容这一习惯

特殊业务规则

内蒙古自治区按城市级别拆分归属两个不同销区（东部归销区三，西部归销区五）；部分客户只知道省份不知道具体城市，系统需要兼容这种「省级精度」的录入场景。

产品设计

6 个核心功能模块

功能模块	用户价值
全国销售地图	一目了然看到全国各省 / 市的销售分布，颜色深浅代表销量大小
省份下钻	点击省份进入该省地图，查看各市的销售详情和客户列表
三产品切换	纯碱 / 尿素 / 小苏打一键切换，各自独立的数据视图
客户管理后台	增删改查客户信息，支持多地区关联、批量操作
Excel 批量导入	保留业务方熟悉的 Excel / CSV 工作方式，上传即可自动解析入库
销区配色地图	5 个销区用不同颜色标注，含业务员 hover 信息

三、

AI 辅助开发实践（Vibe Coding）

为什么

PM 背景 + AI = 最高效的全栈交付方式

作为一个产品经理背景的开发者，我选择用 AI 辅助开发（Vibe Coding）来完成这个项目。核心考虑是：

时间约束极强：从需求确认到公司需要使用，只有约 1 周时间
需求明确但技术面广：涉及地图可视化、前后端开发、数据库设计、服务器部署，单人全栈开发效率挑战大
PM 的优势在于需求理解：我能精确描述「要什么」和「为什么」，AI 擅长快速生成「怎么做」的代码

我的角色

Vibe Coding 不是「让 AI 写代码我什么都不做」

需求侧（AI 做不到的）

与业务方沟通，理解真实场景和痛点
判断功能优先级——先做地图可视化和数据管理，设置页面等低优先级后做
定义业务规则——如内蒙古拆分逻辑、客户多地区关联模型、产品类型映射

产品设计侧

定义交互流程——地图点击→信息面板→省份下钻→客户卡片→详情弹窗
发现 AI 实现与需求的偏差并及时纠正——如「颜色应该填充在地图内而不是 hover 才显示」、「反馈数字被误显示为温度值」等
把模糊的业务需求转化为精确的技术需求——「一个客户可能对应多个地区」→数据库的一对多关联模型设计

质量控制侧

手动测试每个功能，发现 AI 代码的 bug 并指导修复
产品类型切换后客户列表未同步更新、批量删除功能异常等，都是我在测试中发现并推动修复的
部署后的端到端验证——本地能跑 ≠ 服务器能跑，处理了大量 Prisma 配置、Nginx 反向代理、数据库连接等部署层面的问题

关键决策

开发过程中的判断时刻

决策点	背景	我的判断
数据库从 SQLite 迁移到 PostgreSQL	项目初期用 SQLite 快速验证，但上线需要生产级数据库	数据量不大且都是演示数据，迁移成本低，果断切换
客户数据模型重构	最初一个客户只能对应一个地区，业务方反馈一个客户可能在多城市有业务	引入一对多关联（Customer → SalesCoverage），重构数据库 schema

四、

产品设计（What）

系统架构

React 前端（ECharts 地图可视化）
       ↓
Node.js 后端（Express + Prisma ORM）
       ↓
PostgreSQL 数据库

全国概览（Dashboard 首页）

中国地图热力图，颜色深浅代表各省销量大小
顶部产品切换（纯碱 / 尿素 / 小苏打），地图数据实时切换

省份下钻 + 客户详情

点击任意省份，地图切换为该省各市的地图
信息面板显示该省销售汇总 + 客户列表卡片（按销量排序）
点击客户卡片弹出详情弹窗（联系方式、备注、各地区销量明细）

管理后台（Admin Panel）

按产品类型分 Tab 管理客户数据（纯碱 / 尿素 / 小苏打）
客户表格支持展开查看多地区子记录
新增 / 编辑客户：省市联动下拉选择，支持添加多个地区
批量操作：全选 / 多选 + 批量删除
Excel / CSV 导入：上传文件自动解析，同名客户智能合并

五、

项目时间线

阶段	时间	工作内容
需求调研	Day 1	与销售团队沟通，收集销区划分、组织架构、数据格式等业务信息
V1：销区地图	Day 2	完成基础中国地图 + 5 销区配色 + 销区信息面板 + 内蒙古城市级拆分
V2：全栈系统	Day 3-4	搭建 Node.js 后端 + 数据库，实现客户管理 CRUD、地图热力图、省份下钻、产品切换
V3：功能完善	Day 5	客户多地区关联重构、Excel 批量导入、批量删除、UI 美化
部署上线	Day 6-7	阿里云 ECS 部署、Nginx 配置、子域名方案、PostgreSQL 迁移、CI/CD 配置

六、

技术实现亮点

技术点	实现方式	解决的业务问题
中国地图可视化	ECharts + 阿里 DataV GeoJSON	直观展示全国销售分布，替代 Excel 数据表
省份下钻	动态加载省级 GeoJSON + 后端 API 联动	支持从全国 → 省 → 市的逐级查看
客户多地区模型	Prisma 一对多关联（Customer → SalesCoverage）	支持一个客户在多个城市有业务的真实场景
Excel 智能导入	Multer + xlsx.js + 自动 adcode 映射	保留业务方熟悉的 Excel 工作方式，同名客户自动合并
生产级部署	Nginx 反向代理 + PM2 进程管理 + GitHub Actions CI/CD	子域名访问、后端自动重启、push 自动部署

七、

反思与收获

做得好的地方

极快的需求 → 上线闭环：7 天内从调研到上线，且系统已投入实际使用。这得益于：① 需求理解精准，没有做多余功能；② AI 辅助开发极大提升了编码效率；③ 遇到问题快速决策
业务理解驱动产品设计：内蒙古城市级拆分、客户多地区关联、Excel 导入等功能都来自对真实业务场景的深入理解，而非技术驱动
Vibe Coding 的正确姿势：AI 辅助开发的核心不是「不写代码」，而是让 PM 把更多精力放在需求理解、产品判断和质量控制上。AI 生成代码，我负责「对不对」和「好不好」

可以改进的地方

部署经验不足：部署阶段花了较多时间处理 Nginx 配置、Prisma 在 Linux 上的二进制兼容、数据库连接等问题。如果有更多 DevOps 经验，部署可以更高效
缺少正式的用户测试：由于时间紧迫，直接交付给业务方使用，没有组织正式的可用性测试。后续可以收集使用反馈进行迭代
数据安全与权限：当前系统没有用户登录和权限管理，所有人都可以修改数据。作为内部工具可以接受，但如果用户范围扩大需要加入权限控制

对我的成长

这个项目让我验证了一个重要的认知：产品经理 + AI 辅助开发是一个非常高效的组合。PM 的核心能力——理解业务、定义需求、做取舍判断——在 AI 时代不仅没有被替代，反而变得更加重要。因为 AI 能写出代码，但它不知道该写什么代码、为谁写、以及写出来的东西对不对。这正是 PM 的不可替代价值。

同时，具备技术理解力的 PM 在与 AI 协作时效率远高于纯技术背景的开发者——因为我能同时从业务和技术两个视角审视 AI 的输出。

← 返回所有作品