乐于分享
好东西不私藏

AI 赋能售后管理:非技术人员独立开发 CRM 系统全记录

AI 赋能售后管理:非技术人员独立开发 CRM 系统全记录

一、项目背景

作为售后经理,日常工作中客户信息分散、服务记录难以追踪、合同到期无人提醒等问题一直困扰着团队。传统的 Excel 表格管理方式已经跟不上业务增长的节奏,于是决定开发一套专门的售后客户管理系统(CRM),将客户管理、服务跟踪、合同管理等核心业务数字化。

但摆在我面前的现实是——我不是专职开发人员,团队也没有额外的开发资源。如何在有限的技术能力下,快速交付一套可用的系统?WorkBuddy 成为了解决这个问题的关键。


二、技术选型:从需求出发

2.1 为什么选择这套技术栈

系统需要满足几个核心要求:

  • 开发门槛低
    :我是售后经理,不是程序员,需要选择上手快的技术
  • 维护成本低
    :系统上线后需要长期维护,不能依赖复杂的技术栈
  • 部署简单
    :需要部署到公司服务器,最好能一键部署
  • 成本低
    :项目预算有限,优先使用开源方案

最终确定的技术栈:

层级
技术选择
选择理由
后端
Python + Flask
语法简洁,适合快速开发
数据库
PostgreSQL
企业级,开源免费
前端
Bootstrap 5
响应式设计,组件丰富
部署
Ubuntu + Nginx + Gunicorn
成熟稳定,配置简单
代码管理
Gitee
国内访问快,团队协作方便

2.2 系统架构

┌─────────────────────────────────────┐ │         前端展示层 (Bootstrap 5)      │ ├─────────────────────────────────────┤ │       业务逻辑层 (Flask + Jinja2)    │ ├─────────────────────────────────────┤ │      数据访问层 (SQLAlchemy ORM)     │ ├─────────────────────────────────────┤ │       数据存储层 (PostgreSQL 16)     │ └─────────────────────────────────────┘

三、WorkBuddy:我的"AI 开发搭档"

整个开发过程中,WorkBuddy 不仅仅是一个聊天工具,更像是我的技术搭档。它帮我跨越了从"需求想法"到"代码实现"之间的鸿沟。

3.1 需求沟通:像跟同事讨论一样自然

开发的第一步,我不需要写 formal 的需求文档,而是直接用自然语言跟 WorkBuddy 描述我的需求:

"帮我做一个售后客户管理系统,需要客户管理、服务记录、合同管理功能,支持文件上传"

WorkBuddy 会主动帮我梳理功能清单,设计数据库表结构,甚至提醒我遗漏的场景。比如我最初没想到"合同到期提醒"这个功能,是 WorkBuddy 在讨论中提出来的:

"合同到期前30天自动提醒,这样可以避免合同遗漏续签"

这种对话式的需求分析方式,比我一个人对着屏幕苦思冥想高效得多。

3.2 代码生成:从零到可运行只需几轮对话

确定了需求后,WorkBuddy 直接生成了完整的代码:

后端代码(app.py):Flask 应用初始化和配置、SQLAlchemy 数据库模型定义、用户认证(登录/注册/权限控制)、各功能模块的路由和视图函数、文件上传处理。

前端页面(HTML 模板):登录/注册页面、Dashboard 数据看板、客户管理(列表+详情+增删改)、服务记录管理、合同管理(含附件上传)、用户管理。

数据库脚本:建表语句、初始数据(管理员账号)。

整个过程,我只负责"描述需求"和"确认结果",代码生成由 WorkBuddy 完成。对于我这样的非专业开发者来说,这种工作模式极大降低了开发门槛。

✅ 核心体会:AI 不会取代你,但会用 AI 的人会取代你。关键是把 AI 用在刀刃上——重复性编码交给 AI,业务理解和产品判断由自己主导。

3.3 部署上云:一步步引导完成

代码写完后,最让我头疼的是部署。我对 Linux 服务器运维并不熟悉,但 WorkBuddy 像一个耐心的导师,一步步引导我完成部署。

第 1 步:服务器环境搭建

安装 PostgreSQL → 创建数据库和用户 → 配置权限 安装 Python 虚拟环境 → 安装依赖包

第 2 步:应用部署

上传代码到服务器 → 初始化数据库表 → 创建管理员账号 配置 Gunicorn WSGI 服务器 → 配置 Systemd 服务

第 3 步:Web 服务器配置

安装 Nginx → 配置反向代理 → 配置静态文件

每一步,WorkBuddy 都会给出具体的命令,解释每条命令的作用,并在出错时帮我排查问题。

3.4 Bug 排查:快速定位问题根因

开发过程中不可避免地遇到了各种 Bug,WorkBuddy 在排查问题上展现了强大的能力。

典型案例 1:登录失败——环境变量丢失

现象:在服务器上直接运行 python3 app.py 时登录正常,但通过 Systemd 服务启动后登录失败,提示"用户名或密码错误"。

我的操作:把错误日志复制给 WorkBuddy。

WorkBuddy 的分析过程:

  1. 指出问题根因:Systemd 服务启动时没有加载 .env 文件中的环境变量,导致 Flask 连接到了默认的 SQLite 数据库而不是 PostgreSQL
  2. 给出解决方案:在 crm.service 配置文件中添加 EnvironmentFile=/home/ubuntu/crm-system/.env
  3. 解释原理:Systemd 的执行环境与终端 shell 不同,需要显式指定环境变量文件

修复后:服务重启,登录成功 ✅

典型案例 2:文件上传失败——目录不存在

现象:上传合同时报 FileNotFoundError

WorkBuddy 的分析:定位到 save_attachment 函数,发现缺少目录创建逻辑,uploads/ 目录不存在时直接写入会失败;给出修复方案:在文件保存前添加 os.makedirs(app.config['UPLOAD_FOLDER'], exist_ok=True)

典型案例 3:缩进错误——Python 的"隐形杀手"

现象:服务启动后频繁崩溃,日志显示 IndentationError

问题根源:在服务器上使用 nano 编辑器修改代码时,混用了 Tab 和空格,导致 Python 缩进混乱。而且多次手动修复脚本导致 os.makedirs 被重复插入了多次,让问题越来越复杂。

WorkBuddy 的解决过程:

  1. 首先从 Git 恢复干净版本的 app.py
  2. 然后用 Python 脚本精确替换整个 save_attachment 函数,避免手动编辑引入新的缩进问题
  3. 最后用 python3 -m py_compile 验证语法正确性

3.5 界面美化:迭代式优化

初始版本的登录页面比较简陋,我截了一张图发给 WorkBuddy,说"登录框要在页面居中"。WorkBuddy 重新设计了整个登录页面:渐变背景、CSS Grid 完美居中、毛玻璃登录卡片、输入框带图标、按钮悬停动画、响应式适配。

整个过程就是:截图 → 提需求 → 生成代码 → 部署验证 → 再截图 → 再优化,几轮迭代就达到了满意的效果。


四、核心功能模块

4.1 客户管理

  • 客户信息录入(公司名称、联系人、电话、地址等)
  • 客户分类(按行业、规模、合作状态)
  • 多条件搜索和筛选
  • 客户详情页(关联服务记录、合同信息)

4.2 服务记录管理

  • 服务工单创建和跟踪
  • 服务状态管理(待处理、进行中、已完成)
  • 服务内容详细记录
  • 按客户、时间、类型统计

4.3 合同管理

  • 合同基本信息(编号、金额、日期)
  • 合同附件上传(PDF、图片、Office 文档)
  • 合同到期自动提醒
  • 合同续签记录

4.4 数据统计看板

  • 客户数量统计(总数、新增、活跃)
  • 服务工单统计(数量、完成率)
  • 合同状态统计(在效、即将到期、已到期)
  • 数据可视化图表展示

五、开发踩坑记录

坑 1:PostgreSQL 权限问题

PostgreSQL 15+ 默认限制了 public schema 的权限,创建表时报错 permission denied for schema public。解决:执行 GRANT CREATE ON SCHEMA public TO crm_user;

坑 2:Systemd 环境变量问题

Systemd 服务启动的进程无法读取 .env 文件,导致应用使用了错误的数据库配置。解决:在 service 文件中添加 EnvironmentFile 指向 .env 文件。

坑 3:Python 缩进问题

远程编辑混用 Tab 和空格,导致 IndentationError。多次手动修复反而引入更多问题。解决:使用 Python 脚本自动化替换整个函数,避免手动编辑。

坑 4:服务器系统选择

最初在 CentOS 7 上部署,但 CentOS 7 已 EOL,Python 3.12 无法安装。解决:重装系统为 Ubuntu 24.04 LTS,问题彻底解决。


六、WorkBuddy 使用心得

通过这个项目,总结了几条高效使用 WorkBuddy 的经验:

心得
说明
描述需求要具体
需求越具体,生成越准确,减少反复修改
出问题直接贴日志
不需要自己猜测原因,WorkBuddy 擅长排查 Bug
分步执行,逐步验证
不要一次性粘贴一大段命令,出错难定位
善用截图沟通
界面调整类的需求,一张截图胜过千言万语
保存关键信息
服务器 IP、数据库账号等记录下来,方便维护

七、项目成果

功能模块
完成状态
说明
用户认证
✅ 已完成
登录、注册、权限控制
客户管理
✅ 已完成
增删改查、搜索、详情
服务记录
✅ 已完成
工单管理、状态跟踪
合同管理
✅ 已完成
合同信息、附件上传、到期提醒
数据看板
✅ 已完成
统计图表、数据可视化
Excel 导出
✅ 已完成
客户列表、服务记录导出

八、总结

这个项目从零开始,到成功上线,总共用了不到两天时间。作为非专业开发人员,能够独立完成一套完整的管理系统开发,WorkBuddy 发挥了关键作用。

三条核心经验:

第一,AI 是放大器,不是替代品。WorkBuddy 帮我生成了代码,但需求分析、业务理解、测试验证还是需要我自己把关。AI 放大了我的能力,但决策权始终在我手上。

第二,分步验证,小步快跑。不要试图一次性把所有功能都做完。先实现核心功能,验证可用后,再逐步迭代。这样出了问题容易排查,心理压力也小。

第三,记录是最好的文档。每解决一个问题,就记录下来。这不仅是为了以后维护方便,更是一种知识积累。遇到类似问题时,不用从头再来。

开发这套系统的过程,让我对"AI + 低代码"的开发模式有了深刻的体会。它不代表你不需要学习技术,而是意味着你可以把更多精力放在需求理解产品设计上,把重复性的编码工作交给 AI 去完成。

对于像我这样的业务人员来说,这种模式大大降低了技术门槛,让"想法落地"变得前所未有的简单。


开发周期:2026年5月 | 开发工具:WorkBuddy(AI 辅助开发)

技术栈:Python + Flask + PostgreSQL + Bootstrap + Nginx

部署平台:腾讯云 Ubuntu 24.04 LTS

作者:诸葛铁蛋