没有团队没有融资一个人从零搭建起一套制造业 MES 系统。这篇文章复盘我这 100 天的真实经历——包括技术选型、踩过的坑以及最重要的我是怎么活下来的。一、为什么是制造业2025 年初我还是一个在深圳写代码的程序员。有一天一个做印刷包装的朋友找我吐槽他们工厂还在用 Excel 管生产。几十台机器上百个工人每天的工单靠微信群发质检数据抄在本子上月底对账要翻三天。我问市面上没有现成的系统吗他说有一套几十万而且不贴合我们的流程。小厂根本用不起。那一刻我意识到——中国有几万家中小型制造工厂他们的数字化需求被严重忽视了。这就是 MqCode 的起点。二、技术选型为什么是这套组合拳决定做之后第一关是技术选型。我一个人开发时间就是生命。最终选定了这套技术栈层级技术理由后端Spring Boot 3 MyBatisJava 生态成熟企业客户信任度高前端Vue 3 Element Plus组件库完善开发效率高移动端uni-app (Vue 3)一套代码搞定 App 小程序 H5数据库MySQL 8 Redis经典组合运维简单脚手架若依框架开箱即用的后台管理省掉 70% 基础工作选若依框架是我做得最正确的决定之一。它的用户管理、角色权限、菜单管理、代码生成器让我跳过了所有重复造轮子的环节直接进入业务开发。第一周我就搭好了一个可用的后台骨架。独立开发者的第一原则不要重新发明轮子。用好开源框架把时间花在业务差异化上。开源声明本项目后端基于 RuoYi 进行二次开发前端基于 RuoYi-Vue 前端框架移动端基于 RuoYi-App。感谢若依开源社区及所有贡献者。三、第一个月搭骨架踩坑无数3.1 多数据源的噩梦印刷包装行业有个特点工厂往往已经有一套旧的 ERP 系统。我们的 MES 不能要求客户推翻重来必须和现有系统共存。这意味着——我需要同时连接 MySQL自己的系统、SQL Server客户的旧 ERP、甚至 Firebird某些老旧的印刷软件。Spring Boot 的多数据源配置比想象中复杂得多。不是配几个DataSourceBean 就完事了事务管理才是大坑。// 错误示范这样切换数据源事务根本不会回滚 Transactional // 默认走 master 的 TransactionManager public void syncOrder() { jdbcTemplate.execute(INSERT INTO ...); // 这是 SQL Server // 如果这里抛异常上面的 INSERT 已经提交了 } // 正确做法必须显式指定 TransactionManager Transactional(transactionManager hsmesTransactionManager) public void syncOrder() { // ... }这个问题让我卡了整整三天。最后翻遍了 Spring 官方文档才搞清楚每个数据源需要独立的DataSourceTransactionManager而且 MyBatis 的SqlSessionTemplate必须绑定正确的事务管理器。3.2 前后端权限的最后一公里若依框架自带 RBAC 权限模型用户-角色-菜单三级控制。但实际业务场景远比这复杂。比如一个质检员只能看到自己负责的机台数据一个车间主任只能看到本车间的生产任务。这是数据权限不是简单的菜单权限。我的做法是在 MyBatis 拦截器层面注入数据权限过滤条件DataScope(deptAlias d, userAlias u) public ListProductionOrder selectOrderList(ProductionOrder order);通过自定义注解DataScope在 SQL 执行前动态拼接WHERE条件实现对不同角色返回不同范围的数据。这个设计后来成为了整个系统的权限基石。四、第二个月死磕业务逻辑技术框架搭好后真正的挑战来了我不懂印刷包装行业。4.1 在工厂待了一周我搬了一张桌子坐到朋友的工厂车间里看工人怎么操作机器看质检员怎么记录数据看车间主任怎么排产。一周下来我画了 20 多张流程图。最大的收获是理解了MES 的核心不是技术是流程。印刷包装的典型流程接单 → 制版 → 印刷 → 覆膜 → 烫金 → 模切 → 质检 → 出货每一步都有不同的工艺参数、不同的质量标准、不同的报工方式。我需要设计的不是一个通用 MES而是贴合这个行业真实流程的系统。4.2 质检模块是最难啃的骨头印刷行业的质量控制特别复杂IPQC制程检验每道工序完成后都要抽检IPFQC制程最终检验关键工序的首件必须检验FQC成品检验出货前全检或抽检而且不同的产品有不同的质检标准——色差、套印精度、覆膜牢度、烫金位置……每一个指标都需要不同的判定逻辑。我花了两周设计质检模板系统允许工厂自定义质检指标、自定义判定规则、自定义缺陷分类。这成为了 MqCode 最有竞争力的功能之一。五、第三个月移动端从 0 到 1后台管理系统只能满足办公室人员。车间里的操作工、质检员、送货员他们需要的是手机端。5.1 为什么选 uni-app摆在面前的选择是原生 App成本高、小程序功能受限、H5体验差、uni-app。最终选 uni-app理由很直接我一个人开发必须一套代码覆盖所有端。uni-app 的 Vue 3 版本当时刚出不久坑不少。最让我头疼的是条件编译——同一套代码在不同平台表现不一致。// uni-app 条件编译不同平台走不同逻辑 // #ifdef APP-PLUS // App 端可以调用原生能力 plus.camera.getCamera() // #endif // #ifdef MP-WEIXIN // 小程序只能用 wx API wx.chooseImage() // #endif // #ifdef H5 // H5 用浏览器 API navigator.mediaDevices.getUserMedia() // #endif这段代码让我深刻理解了跨平台开发的本质不是写一套完美适配所有的代码而是管理好不同平台的差异。5.2 移动端 CRM 的设计取舍移动端我只做了 CRM 模块客户、商机、合同、售后没有把整个 MES 搬上去。原因很简单车间操作工用手机报工 → 体验太差不如扫码枪 PC但销售外出拜访客户 → 手机端是刚需做产品要学会做减法。不是功能越多越好而是每个端只做最适合的事。六、这 100 天我学到了什么6.1 技术不是最大的瓶颈坦白说MqCode 的技术架构没有特别炫酷的东西。Spring Boot Vue uni-app全是成熟技术。真正的难点在于理解行业不懂业务写不出好产品做减法一个人资源有限砍功能比加功能更需要勇气持续迭代第一版永远是垃圾关键是快速验证、快速修改6.2 不开源靠什么建立信任MqCode 目前没有开源——这是一个商业产品承载着公司的核心业务逻辑。但不开源不代表闭门造车。我选择了另一条路写技术文章分享开发过程中的思考和方案。比如这篇文章里提到的多数据源方案、质检模板设计、uni-app 条件编译经验——这些不涉及核心商业代码但能让同行看到你的技术深度。事实上公众号就是我的开源。代码不开源但思路可以公开。通过持续输出高质量的技术内容一样能建立行业影响力。已经有客户告诉我我是看了你的文章觉得你懂这个行业才联系你的。开源不是唯一的信任杠杆。持续公开的思考和输出本身就是一种信用资产。6.3 一个人也能做产品100 天前我以为做一套企业级系统需要至少 5 个人的团队。100 天后我一个人完成了后端、前端、移动端、数据库设计、行业调研、产品规划。不是因为我多厉害而是因为用了若依框架省掉 70% 基础工作量选了成熟技术栈不折腾新框架聚焦一个垂直行业不做大而全七、下一步MqCode 目前还在早期阶段。接下来我的计划Q3完善生产排程模块补齐 MES 最后一块拼图Q4接入 AI用大模型做质检缺陷自动识别明年从印刷包装扩展到其他离散制造业如果你也在独立开发产品或者对制造业数字化感兴趣欢迎关注这个公众号。我会持续分享从代码到产品的全过程——包括成功的经验也包括踩过的坑。一个人的产品之路不孤单。本文首发于微信公众号「MqCode」欢迎自由转载。作者MqCode全栈开发者印刷包装行业 MES CRM 系统独立开发者。
一个人做产品的 100 天：从想法到上线
没有团队没有融资一个人从零搭建起一套制造业 MES 系统。这篇文章复盘我这 100 天的真实经历——包括技术选型、踩过的坑以及最重要的我是怎么活下来的。一、为什么是制造业2025 年初我还是一个在深圳写代码的程序员。有一天一个做印刷包装的朋友找我吐槽他们工厂还在用 Excel 管生产。几十台机器上百个工人每天的工单靠微信群发质检数据抄在本子上月底对账要翻三天。我问市面上没有现成的系统吗他说有一套几十万而且不贴合我们的流程。小厂根本用不起。那一刻我意识到——中国有几万家中小型制造工厂他们的数字化需求被严重忽视了。这就是 MqCode 的起点。二、技术选型为什么是这套组合拳决定做之后第一关是技术选型。我一个人开发时间就是生命。最终选定了这套技术栈层级技术理由后端Spring Boot 3 MyBatisJava 生态成熟企业客户信任度高前端Vue 3 Element Plus组件库完善开发效率高移动端uni-app (Vue 3)一套代码搞定 App 小程序 H5数据库MySQL 8 Redis经典组合运维简单脚手架若依框架开箱即用的后台管理省掉 70% 基础工作选若依框架是我做得最正确的决定之一。它的用户管理、角色权限、菜单管理、代码生成器让我跳过了所有重复造轮子的环节直接进入业务开发。第一周我就搭好了一个可用的后台骨架。独立开发者的第一原则不要重新发明轮子。用好开源框架把时间花在业务差异化上。开源声明本项目后端基于 RuoYi 进行二次开发前端基于 RuoYi-Vue 前端框架移动端基于 RuoYi-App。感谢若依开源社区及所有贡献者。三、第一个月搭骨架踩坑无数3.1 多数据源的噩梦印刷包装行业有个特点工厂往往已经有一套旧的 ERP 系统。我们的 MES 不能要求客户推翻重来必须和现有系统共存。这意味着——我需要同时连接 MySQL自己的系统、SQL Server客户的旧 ERP、甚至 Firebird某些老旧的印刷软件。Spring Boot 的多数据源配置比想象中复杂得多。不是配几个DataSourceBean 就完事了事务管理才是大坑。// 错误示范这样切换数据源事务根本不会回滚 Transactional // 默认走 master 的 TransactionManager public void syncOrder() { jdbcTemplate.execute(INSERT INTO ...); // 这是 SQL Server // 如果这里抛异常上面的 INSERT 已经提交了 } // 正确做法必须显式指定 TransactionManager Transactional(transactionManager hsmesTransactionManager) public void syncOrder() { // ... }这个问题让我卡了整整三天。最后翻遍了 Spring 官方文档才搞清楚每个数据源需要独立的DataSourceTransactionManager而且 MyBatis 的SqlSessionTemplate必须绑定正确的事务管理器。3.2 前后端权限的最后一公里若依框架自带 RBAC 权限模型用户-角色-菜单三级控制。但实际业务场景远比这复杂。比如一个质检员只能看到自己负责的机台数据一个车间主任只能看到本车间的生产任务。这是数据权限不是简单的菜单权限。我的做法是在 MyBatis 拦截器层面注入数据权限过滤条件DataScope(deptAlias d, userAlias u) public ListProductionOrder selectOrderList(ProductionOrder order);通过自定义注解DataScope在 SQL 执行前动态拼接WHERE条件实现对不同角色返回不同范围的数据。这个设计后来成为了整个系统的权限基石。四、第二个月死磕业务逻辑技术框架搭好后真正的挑战来了我不懂印刷包装行业。4.1 在工厂待了一周我搬了一张桌子坐到朋友的工厂车间里看工人怎么操作机器看质检员怎么记录数据看车间主任怎么排产。一周下来我画了 20 多张流程图。最大的收获是理解了MES 的核心不是技术是流程。印刷包装的典型流程接单 → 制版 → 印刷 → 覆膜 → 烫金 → 模切 → 质检 → 出货每一步都有不同的工艺参数、不同的质量标准、不同的报工方式。我需要设计的不是一个通用 MES而是贴合这个行业真实流程的系统。4.2 质检模块是最难啃的骨头印刷行业的质量控制特别复杂IPQC制程检验每道工序完成后都要抽检IPFQC制程最终检验关键工序的首件必须检验FQC成品检验出货前全检或抽检而且不同的产品有不同的质检标准——色差、套印精度、覆膜牢度、烫金位置……每一个指标都需要不同的判定逻辑。我花了两周设计质检模板系统允许工厂自定义质检指标、自定义判定规则、自定义缺陷分类。这成为了 MqCode 最有竞争力的功能之一。五、第三个月移动端从 0 到 1后台管理系统只能满足办公室人员。车间里的操作工、质检员、送货员他们需要的是手机端。5.1 为什么选 uni-app摆在面前的选择是原生 App成本高、小程序功能受限、H5体验差、uni-app。最终选 uni-app理由很直接我一个人开发必须一套代码覆盖所有端。uni-app 的 Vue 3 版本当时刚出不久坑不少。最让我头疼的是条件编译——同一套代码在不同平台表现不一致。// uni-app 条件编译不同平台走不同逻辑 // #ifdef APP-PLUS // App 端可以调用原生能力 plus.camera.getCamera() // #endif // #ifdef MP-WEIXIN // 小程序只能用 wx API wx.chooseImage() // #endif // #ifdef H5 // H5 用浏览器 API navigator.mediaDevices.getUserMedia() // #endif这段代码让我深刻理解了跨平台开发的本质不是写一套完美适配所有的代码而是管理好不同平台的差异。5.2 移动端 CRM 的设计取舍移动端我只做了 CRM 模块客户、商机、合同、售后没有把整个 MES 搬上去。原因很简单车间操作工用手机报工 → 体验太差不如扫码枪 PC但销售外出拜访客户 → 手机端是刚需做产品要学会做减法。不是功能越多越好而是每个端只做最适合的事。六、这 100 天我学到了什么6.1 技术不是最大的瓶颈坦白说MqCode 的技术架构没有特别炫酷的东西。Spring Boot Vue uni-app全是成熟技术。真正的难点在于理解行业不懂业务写不出好产品做减法一个人资源有限砍功能比加功能更需要勇气持续迭代第一版永远是垃圾关键是快速验证、快速修改6.2 不开源靠什么建立信任MqCode 目前没有开源——这是一个商业产品承载着公司的核心业务逻辑。但不开源不代表闭门造车。我选择了另一条路写技术文章分享开发过程中的思考和方案。比如这篇文章里提到的多数据源方案、质检模板设计、uni-app 条件编译经验——这些不涉及核心商业代码但能让同行看到你的技术深度。事实上公众号就是我的开源。代码不开源但思路可以公开。通过持续输出高质量的技术内容一样能建立行业影响力。已经有客户告诉我我是看了你的文章觉得你懂这个行业才联系你的。开源不是唯一的信任杠杆。持续公开的思考和输出本身就是一种信用资产。6.3 一个人也能做产品100 天前我以为做一套企业级系统需要至少 5 个人的团队。100 天后我一个人完成了后端、前端、移动端、数据库设计、行业调研、产品规划。不是因为我多厉害而是因为用了若依框架省掉 70% 基础工作量选了成熟技术栈不折腾新框架聚焦一个垂直行业不做大而全七、下一步MqCode 目前还在早期阶段。接下来我的计划Q3完善生产排程模块补齐 MES 最后一块拼图Q4接入 AI用大模型做质检缺陷自动识别明年从印刷包装扩展到其他离散制造业如果你也在独立开发产品或者对制造业数字化感兴趣欢迎关注这个公众号。我会持续分享从代码到产品的全过程——包括成功的经验也包括踩过的坑。一个人的产品之路不孤单。本文首发于微信公众号「MqCode」欢迎自由转载。作者MqCode全栈开发者印刷包装行业 MES CRM 系统独立开发者。
