一个人做产品的 100 天：从想法到上线

没有团队，没有融资，一个人从零搭建起一套制造业 MES 系统。这篇文章复盘我这 100 天的真实经历——包括技术选型、踩过的坑，以及最重要的：我是怎么活下来的。

一、为什么是制造业？

2025 年初，我还是一个在深圳写代码的程序员。

有一天，一个做印刷包装的朋友找我吐槽：他们工厂还在用 Excel 管生产。几十台机器，上百个工人，每天的工单靠微信群发，质检数据抄在本子上，月底对账要翻三天。

我问："市面上没有现成的系统吗？"

他说："有，一套几十万，而且不贴合我们的流程。小厂根本用不起。"

那一刻我意识到——中国有几万家中小型制造工厂，他们的数字化需求，被严重忽视了。

这就是 MqCode 的起点。

二、技术选型：为什么是这套组合拳？

决定做之后，第一关是技术选型。我一个人开发，时间就是生命。最终选定了这套技术栈：

选若依框架是我做得最正确的决定之一。

它的用户管理、角色权限、菜单管理、代码生成器，让我跳过了所有"重复造轮子"的环节，直接进入业务开发。第一周我就搭好了一个可用的后台骨架。

独立开发者的第一原则：不要重新发明轮子。 用好开源框架，把时间花在业务差异化上。

📌 开源声明

本项目后端基于 RuoYi 进行二次开发，前端基于 RuoYi-Vue 前端框架，移动端基于 RuoYi-App。感谢若依开源社区及所有贡献者。

三、第一个月：搭骨架，踩坑无数

3.1 多数据源的噩梦

印刷包装行业有个特点：工厂往往已经有一套旧的 ERP 系统。我们的 MES 不能要求客户推翻重来，必须和现有系统共存。

这意味着——我需要同时连接 MySQL（自己的系统）、SQL Server（客户的旧 ERP）、甚至 Firebird（某些老旧的印刷软件）。

Spring Boot 的多数据源配置比想象中复杂得多。不是配几个 DataSource Bean 就完事了，事务管理才是大坑。

// 错误示范：这样切换数据源，事务根本不会回滚
@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 List<ProductionOrder> 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 天后，我一个人完成了后端、前端、移动端、数据库设计、行业调研、产品规划。

不是因为我多厉害，而是因为：

1. 用了若依框架，省掉 70% 基础工作量

2. 选了成熟技术栈，不折腾新框架

3. 聚焦一个垂直行业，不做大而全

七、下一步

MqCode 目前还在早期阶段。接下来我的计划：

• 🎯 Q3：完善生产排程模块，补齐 MES 最后一块拼图

• 🎯 Q4：接入 AI，用大模型做质检缺陷自动识别

• 🎯 明年：从印刷包装扩展到其他离散制造业

如果你也在独立开发产品，或者对制造业数字化感兴趣，欢迎关注这个公众号。我会持续分享从代码到产品的全过程——包括成功的经验，也包括踩过的坑。

一个人的产品之路，不孤单。👇

本文首发于微信公众号「MqCode」，欢迎自由转载。 作者：MqCode，全栈开发者，印刷包装行业 MES + CRM 系统独立开发者。