4月30日启动，5月3日主体跑通。这不是奇迹，是找对了路。
一、先说结论：我们为什么能跑这么快？
4月30日 立项（前后端同时开工）
5月3日 主体跑通（核心链路全部打通）
三天。一个人做架构，两个人写代码，主体功能就跑通了。
不是因为我们技术多牛，是因为我手里已经有了两样东西：
- 一套已经跑了两年的“脏代码” （21个模块、5种硬件、80人工厂验证过）
- 一份极其详细的“重构说明书” （前两篇文章发的整改方案文档）
我不需要从零思考“这个模块该怎么设计”。我只需要告诉AI：“把这个模块从老架构改成新架构，按照这份文档来。”
剩下的，DeepSeek帮我干了大半。
二、背景：为什么要重构？因为“一个人的代码”扛不住了
2.1 老代码能跑，但只有我能维护
之前写的Qt客户端，21个模块，在工厂跑了两年，很稳。
但问题也很明显：
- 变量名随意，API命名不统一
- 一个文件几千行，逻辑耦合严重
- 硬编码到处都是，IP、端口、业务规则全写在代码里
- 只有我能改，换个人接手等于重新学一遍
以前无所谓，因为只有我一个人开发。现在要商业化、要联营、要让合作方也能部署和维护，这套“个人风格强烈”的代码必须重构。
2.2 商业模式的转变倒逼技术升级
| 维度 | 单人模式 | 联营模式 |
|---|---|---|
| 维护者 | 只有我 | 合作方的技术人员 |
| 交付方式 | 定制开发 | 标准化产品+现场配置 |
| 修改业务逻辑 | 我改C++代码 | 改JSON配置 |
| 新增模块 | 写一整套代码 | 配置模板+拖拽 |
| 界面调整 | 改UI文件 | 用户自己拖拽+AI生成主题 |
核心目标：让软件从“我写出来的”变成“配置出来的”。
三、前后端新架构：怎么做到“可配置”？
3.1 整体思路：后端管配置，前端管渲染
text
复制下载
┌─────────────────────────────────────────────────────────────┐
│ 联营模式新架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌─────────────┐ │
│ │ ConfigServer │────▶│ Qt客户端 │────▶│ 用户界面 │ │
│ │ (配置中心) │ │ (配置驱动) │ │ (千人千面) │ │
│ └──────────────┘ └──────────────┘ └─────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌─────────────┐ │
│ │ JSON配置文件 │ │ 解析配置 │ │ 拖拽自定义 │ │
│ │ (业务逻辑) │ │ 动态生成UI │ │ AI换主题 │ │
│ └──────────────┘ └──────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
3.2 后端：DKERP_ConfigServer（配置中心）
核心职责：让业务逻辑离开代码，进入配置文件。
三个核心能力：
- 可视化API配置：不需要写C++代码，通过UI界面配置API的请求参数、SQL语句、返回格式，一键生成JSON。
- JSON驱动执行：服务端根据JSON配置动态执行API请求，支持
sql（数据库查询）/chain（链式调用）/static（静态返回）三种类型。 - 配置分发：客户端启动时自动拉取最新配置，版本比对、增量更新。
技术栈极简：C++ + Qt + SQLite + OpenSSL，树莓派能跑，换服务器更强。
3.3 前端：DKERP_Client重构（配置驱动客户端）
核心理念：UI与业务逻辑彻底解耦
| 模块 | 重构前 | 重构后 |
|---|---|---|
| 表格 | 硬编码列、本地分页 | 配置驱动、服务端分页/排序 |
| 表单 | 写死字段和验证 | 配置驱动、动态生成、可拖拽 |
| 搜索 | 固定条件 | 配置驱动、多条件组合 |
| 子表 | 只读展示 | 可编辑、修改追踪、批量保存 |
| 布局 | 内存缓存 | 加密存储、千人千面 |
| 主题 | 固定样式 | AI生成QSS、一键切换 |
双运行模式：
- 正常模式：做业务（查询、录入、审核）
- 编辑模式：调界面（拖拽控件、调整布局、AI换主题）
三个“不需要”：
- 不需要写C++代码来新增模块
- 不需要重新编译客户端来调整业务
- 不需要懂编程来自定义界面
四、这不是“拆迁重建”，是“照着图纸重新盖”
4.1 彻底放弃了老代码，一行都没复用
很多人重构，是把老代码一点点改。
我不一样。我彻底放弃了老代码。
一行都没复用。从0开始，新建Qt工程，新建文件，新写每一行代码。
4.2 那老代码去哪了？
老代码变成了两样东西：
- “需求说明书” ：业务流程、字段定义、边界条件——这些都是老代码里验证对的，我把它提取成文档。
- “验证标尺” ：新代码写完，和老代码跑同样数据，结果必须一致。
老代码不香吗？香，但它的“香”不在代码本身，在代码里沉淀的业务逻辑。
所以我的做法是：
- 老代码认真读、仔细拆、绝不抄
- 把业务规则提取成配置文件
- 把UI和逻辑的关联提取成配置Schema
- 然后用新架构、新规范、新命名，从0写新代码
4.3 为什么敢彻底放弃？
| 维度 | 老代码 | 新代码 |
|---|---|---|
| 架构 | 模块耦合、逻辑分散 | 配置驱动、四层解耦 |
| UI | 硬编码布局 | 动态生成+拖拽自定义 |
| 业务逻辑 | 写在C++里 | 写在JSON配置里 |
| 命名规范 | 随意 | 统一PascalCase/camelCase |
| 可维护性 | 只有我能改 | 合作方也能配 |
| 代码量 | 臃肿重复 | 精简规范 |
老代码的业务逻辑是对的，但它的表达方式不行。
我要的不是“把老代码改好”，我要的是用正确的方式重新表达一遍正确的业务。
这只有彻底重写才能做到。
4.4 重写没有想象中慢
为什么3天能跑通主体？
不是因为写代码快，是因为不需要想业务。
业务逻辑已经在老代码里跑通了两年，边界条件都踩过坑了。我要做的不是“设计”，而是翻译——把老代码里的业务逻辑，翻译成新架构里的JSON配置。
AI在这个过程里帮了大忙。我把老代码片段 + 新架构文档喂给DeepSeek，它能在几分钟内给出“这个业务逻辑该怎么配置化”的方案。
核心公式：
验证过的业务逻辑 × 配置驱动新架构 × AI加速翻译 = 3天跑通主体
五、联营模式：技术怎么支撑商业化？
5.1 合作方的痛点
合作方（行业服务商）面临的问题：
- 有客户资源，但没有技术团队
- 客户需求多样，每个工厂要的界面不一样
- 不想被某个软件公司绑定，希望有自己的交付能力
- 不懂C++，没法改我的代码
5.2 我的解法：交付“配置能力”，而非“代码”
合作方需要做的：
- 拿到我的客户端安装包
- 打开ConfigServer配置界面
- 根据客户需求，配置表格列、表单字段、搜索条件
- 保存JSON，发给客户
- 客户打开软件，自动加载配置
完全不需要写一行代码。
客户自己能做的：
- 进入“编辑模式”，拖拽调整控件位置
- 输入“我要蓝色科技感主题”，AI自动生成QSS
- 保存自己的专属布局，换电脑登录也能恢复
5.3 技术架构支撑的商业逻辑
text
复制下载
┌─────────────────────────────────────────────────────────────┐
│ 联营模式协作链 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 我（核心技术） │
│ │ │
│ ├── 维护 ConfigServer（配置工具） │
│ ├── 维护 Qt客户端（配置驱动引擎） │
│ └── 培训合作方如何使用 │
│ │ │
│ ▼ │
│ 合作方（行业服务商） │
│ │ │
│ ├── 用ConfigServer为客户配置专属JSON │
│ ├── 现场部署客户端 │
│ └── 收集客户反馈，迭代配置 │
│ │ │
│ ▼ │
│ 终端客户（工厂） │
│ │ │
│ ├── 使用配置好的客户端 │
│ ├── 编辑模式自定义界面 │
│ └── AI换主题 │
│ │
└─────────────────────────────────────────────────────────────┘
5.4 利润分配模式
| 角色 | 职责 | 收益 |
|---|---|---|
| 我 | 技术研发、产品迭代、核心支持 | 产品授权费+利润分成 |
| 合作方 | 市场开拓、现场交付、客户维护 | 销售毛利大头 |
| 终端客户 | 使用系统 | 降本增效 |
核心原则：
- 知识产权100%归我
- 合作方获得专属行业授权
- 签好退出协议，好聚好散
六、三天时间线：我们是怎么做到的？
| 日期 | 前端进度 | 后端进度 |
|---|---|---|
| 4.30 | 新架构搭建、ConfigManager实现 | ConfigServer项目初始化、配置Schema设计 |
| 5.1 | DataGridView配置化改造 | API配置编辑器主体、JSON生成/验证 |
| 5.2 | SearchPanel + FormView联动 | SQL构建器、配置热加载机制 |
| 5.3 | 前后端联调、主体流程跑通 | 配置分发接口、版本比对 |
核心经验：
- 有完整的设计文档，AI才能精准干活
- 模块独立，前后端可以并行开发
- 配置驱动，改JSON比改代码快10倍
- 彻底重写，不受老代码的技术债务拖累
七、踩坑与反思
7.1 最大的坑：配置版本的兼容性
改配置格式容易，但要保证老客户端还能用就难了。
解法：配置Schema加版本号，客户端加载时做兼容转换。不兼容的配置拒绝加载，提示升级客户端。
7.2 第二坑：AI生成的主题有时不可用
DeepSeek生成的QSS偶尔会有语法错误，直接setStyleSheet会让界面崩。
解法：先解析验证QSS语法，有问题降级到默认主题，同时记录失败案例用于优化prompt。
7.3 第三坑：拖拽编辑的精度问题
Qt的拖拽系统在复杂布局下容易错位，控件对齐困难。
解法：加了吸附对齐（snap to grid）和网格辅助线，体验好了很多。同时支持键盘微调（方向键移动1px）。
7.4 第四坑：“彻底重写”的心理门槛
刚开始很犹豫——两年代码说扔就扔？
解法：想清楚一件事——代码不值钱，代码里验证对的业务逻辑才值钱。只要业务逻辑提取出来了，重写只是换种表达方式。
而且重写之后，维护成本会降一个数量级。这笔账算得过来。
八、后续规划
8.1 短期（5-6月）
- 完善ConfigServer的可视化配置界面
- 跑通2-3个合作方的试点部署
- 收集反馈，迭代配置模板库
- 编写合作方培训手册
8.2 中期（6-12月）
- 积累各行业的配置模板（电子、五金、包装…）
- AI主题生成优化，支持更复杂的样式
- 硬件对接配置化（扫码枪、地磅配置也进JSON）
- 配置模板市场，合作方可分享/售卖自己的模板
8.3 长期
- ConfigServer进化成“AI配置助手”（你说需求，它生成配置JSON）
- 客户端支持WebAssembly，浏览器也能跑
- 最终目标：让任何工厂的数字化，能在1周内完成部署
九、给同行的一些话
9.1 关于重构
不要怕彻底重写，但不要为了重写而重写。
我重写是因为商业模式变了，单人维护扛不住了。如果你的系统跑得好、客户满意、就你一个人维护，重构的优先级没那么高。
但如果你决定重写，就彻底一点。不要“边改边跑”，那只会让技术债务越滚越大。
9.2 关于AI
AI是你的副驾驶，不是自动驾驶。
DeepSeek帮我写了很多代码，但架构设计、模块拆分、边界定义，还是我自己想清楚的。AI的价值是加速执行，不是替代思考。
另外，给AI喂完整上下文非常重要。我把整个项目的设计文档喂给DeepSeek，它才能给出符合架构的方案。如果只给零散的代码片段，它就会瞎猜。
9.3 关于商业化
做工业软件，产品化能力比技术能力更重要。
代码写得再好，如果每个客户都要重新定制，你也赚不到钱。想办法让90%的需求进配置，10%的需求才写代码——这是工业软件商业化的核心。
联营比代理靠谱。
代理是买卖关系，联营是利益共同体。让合作方深度参与、共享收益，他们才会真正投入。
9.4 关于“完美主义”
不要追求完美架构，追求“够用且能演进”。
我的新架构也不完美，但它比老架构好10倍，而且为下一步演进留了接口。这就够了。
等跑两年，发现新的问题，再重构一次。代码本来就是用来重构的。
十、写在最后
三天跑通主体，这不是终点，是起点。
接下来要做的是：优化细节、积累模板、跑通合作方试点。
我依然一个人写核心代码，但我不是一个人在战斗。DeepSeek帮我加速，合作伙伴帮我铺市场。
如果你也在做工业软件，如果你也面临“单人维护转联营”的问题，欢迎交流。
不是每个好软件都需要上市敲钟，但每个好软件都应该让维护它的人不那么累。
设计文档、架构图、核心代码实现，后续会陆续分享。
欢迎围观，欢迎验证。
项目启动: 2026-04-30
主体跑通: 2026-05-03
当前状态: 细节优化中
联营合作: 开放2-3个行业试点
相关阅读：
- 自主工厂底层操作系统：一个人从零搭建
- 后端核心：树莓派+Python协程，如何做到十几毫秒响应
- MES/ERP 工业软件架构大升级｜整套 Qt 客户端完全推倒重构
- 不要完美技术，要完美落地
- 从单兵自研到商业化破局：我的工业软件全新技术路线与落地规划
加个关注，后续更新不错过~
