用 WorkBuddy 从零搭建生产管理大屏：Flask + K3 ERP 数据集成实战

用 WorkBuddy 从零搭建生产管理大屏：Flask + K3 ERP 数据集成实战

本文记录了笔者使用腾讯云代码助手 WorkBuddy，从零开发一套生产管理大屏系统的完整过程。系统涵盖缺件分析、在途跟踪、成品库存等核心模块，数据源对接金蝶 K/3 WISE ERP，部署在内网 Windows 服务器上，大屏实时展示车间生产状态。

一、项目背景

我所在公司是山东金大丰机械有限公司，主要生产农业收割机等大型农机设备。生产计划涉及 33 个机型、274 个配置，涵盖割台类型、行距、发动机品牌、驱动方式等多个维度。

管理痛点很直接：

• 生产计划在 Excel 里，缺件情况靠人工数
• K3 ERP 有库存数据，但没有可视化
• 在途物料（已发货未入库）缺乏跟踪手段
• 车间需要一个实时大屏看生产状态

目标：做一个大屏，把生产计划、缺件、库存、在途数据统一展示。

二、技术选型

架构非常简单：

K3 SQL Server → core.py (数据导出) → .xlsx 文件
.xlsx 文件 → server.py (Flask API) → bigscreen_v2.0.html (前端大屏)

三、WorkBuddy 辅助开发全过程

3.1 项目初始化

第一步，我告诉 WorkBuddy 需求：

"帮我搭建一个 Flask 项目，需要提供 REST API 读取 Excel 数据，前端是大屏展示页面"

WorkBuddy 直接生成了项目骨架：

• server.py：Flask 路由和 API 定义
• core.py：数据处理和 Excel 读取逻辑
• bigscreen_v2.0.html：大屏前端页面

关键体验：不需要从空文件开始，框架搭建 + 基础代码一次到位。

3.2 K3 数据对接

这是整个项目最复杂的部分。K3 的数据结构比较特殊：

在途数据的定义：收料通知单已审核但未推生成入库单的数据（即到货未入库）。K3 的流程是：

采购订单 → 收料通知单 → 入库单
                  ↑            ↑
              已审核         已审核+关闭

只有收料通知单已审核、且对应入库单未审核+关闭的，才算在途。

我把这个业务规则告诉 WorkBuddy，它帮我写了 export_zaitai.py，核心 SQL 逻辑：

python

复制

# 查询收料通知单与入库单的差额
# 关键表：ICStockBill（出入库）、t_ICItem（物料规格）
# 关键字段：FModel（物料规格）、ICStockBillEntry.FEntrySelfA0239（大架号/发动机号/配置）

关键体验：K3 的表结构很复杂（几百张表），我只需要描述业务逻辑，WorkBuddy 帮我翻译成 SQL。

3.3 大屏前端开发

大屏需要展示多个 Tab：

WorkBuddy 的帮助：

1. Tab 切换逻辑：一次生成，不需要手写事件监听
2. 表格样式：告诉我配色需求（缺件红色、在途橙色），直接出 CSS
3. 数据刷新：API 轮询机制，大屏自动刷新最新数据

javascript

复制

// 大屏核心：定时刷新数据
setInterval(function() {
    fetch('/api/quejian').then(r => r.json()).then(updateTable);
    fetch('/api/zaitai').then(r => r.json()).then(updateZaitai);
}, 60000); // 每分钟刷新

3.4 在途列 & 在线编辑

需求迭代阶段：

• 在途数量列：橙色加粗显示，0 也显示（让采购员知道哪些没有在途）
• 采购员/到位时间在线编辑：双击单元格编辑，自动保存到后端
• 导出缺件表：一键导出当前缺件数据为 Excel

这些功能我都是用 WorkBuddy 的 Craft 模式，描述需求后直接生成代码。

在线编辑的核心代码（WorkBuddy 生成）：

javascript

复制

// 双击编辑 → 保存到后端
cell.addEventListener('dblclick', function() {
    const original = this.textContent;
    this.contentEditable = true;
    this.focus();
    this.addEventListener('blur', function() {
        const newValue = this.textContent;
        if (newValue !== original) {
            fetch('/api/update_field', {
                method: 'POST',
                body: JSON.stringify({id: rowId, field: fieldName, value: newValue})
            });
        }
    });
});

3.5 成品库存模块

成品库存表当前 13 列：大架号、打印配置、产品编码、产品名称、发动机编号、仓库、切碎机、还田机、轮距、割幅、滚筒、驱动、轮胎。

这个模块的特殊之处在于大架号数据来自 K3 的 ICStockBillEntry.FEntrySelfA0239 字段，里面同时包含大架号、发动机号和配置信息，需要解析拆分。WorkBuddy 帮我写了解析逻辑。

四、自动化运维

4.1 在途数据自动导出

用 Windows 计划任务 + Python 脚本实现：

计划任务：K3_Zaitai_Export
触发器：每 30 分钟运行一次
执行：python export_zaitai.py
输出：在途_明细.xlsx → 大屏自动读取

4.2 数据文件管理优化

初期问题：数据文件按日期堆积（03.01.xlsx、03.02.xlsx...），管理混乱。

优化方案：改为固定文件名覆盖写入，不做堆积。大屏始终读取最新文件。

五、最终效果

系统运行在 172.16.30.104:9876/bigscreen，车间端口 9877。

大屏展示内容：

• 生产计划 Tab：33个机型的计划与完成情况
• 割台计划 Tab：割台配置的专项跟踪
• 缺件明细 Tab：缺件数量 + 在途数量（橙色）+ 采购员 + 到位时间
• 成品库存 Tab：含大架号的完整库存信息

关键数据流：

K3 ERP (172.16.30.177) ──SQL查询──→ export_zaitai.py (每30分钟)
                                        ↓
                              在途_明细.xlsx
                                        ↓
生产计划 Excel ──→ core.py ──→ server.py (Flask) ──→ bigscreen_v2.0.html
K3 库存数据  ──→ core.py ──→    ↑ API
缺件表 Excel ──→ core.py ──→    ↓
                              车间大屏 (9876/9877)

六、开发效率对比

总体效率提升约 3-4 倍。

七、踩坑记录

坑1：K3 流程理解偏差

K3 的收料通知单 → 入库单不是一对一关系，一个收料通知单可以分多次入库。最初我按一对一计算在途，数据对不上。WorkBuddy 帮我重新梳理了关联逻辑。

坑2：大屏数据不自动刷新

TAP 生产计划更新后大屏没同步，排查发现是前端缓存问题。解决：API 响应加 Cache-Control: no-cache，前端用 Ctrl+F5 验证。

坑3：数据文件命名混乱

早期按日期命名导致大屏读取逻辑复杂。改为固定文件名后，核心代码简化了一半。

八、总结

WorkBuddy 在这个项目中的核心价值：

1. 降低 K3 对接门槛：不需要熟记几百张表的字段，描述业务即可
2. 加速迭代：需求变更时，改描述比改代码快
3. 减少重复劳动：项目骨架、CRUD 接口、表格样式等模板代码秒出
4. 学习成本低：Flask + 原生 JS，团队都能维护

如果你也有类似的内部系统开发需求，强烈建议试试 WorkBuddy——特别是需要对接老旧 ERP 系统的场景，AI 帮你处理数据逻辑，你专注于业务本身。