### 摘要

> 本文分享了轻排 PMClite 从“数据记录工具”升级为“PMC 决策中枢”的架构演进过程。重点探讨了如何通过**事件驱动模型**、**分层 AI 策略（算法主算，AI 主说）** 、**沙盘推演**和**移动端报工闭环**，解决中小制造企业 PMC 岗位的核心痛点。文章包含技术选型对比、核心模块设计思路及未来向 PMC 智能体演进的规划，适合关注制造业数字化、Tauri、Rust 及 AI Agent 落地的开发者与 PMC 从业者阅读。

### 正文

#### 一、缘起：为什么中小工厂的 PMC 依然在“人肉决策”？

在接触了数十家 10-200 人的中小制造企业后，我们发现一个普遍现象：ERP 管好了“账本”，但**排产决策层依然是断裂的**。

PMC（生产计划与物料控制）计划员的日常是这样的：打开三四个 Excel，从 ERP 导出数据，手动 VLOOKUP 核对物料，凭借经验在日期列里填数字。行业数据显示，**75% 的制造企业仍依赖 Excel 手工排产**，当产品种类超过 50 个时，一次完整的计划调整耗时超过 2 小时，且“一改就乱”。

真正的痛点不在于“没有数据”，而在于：

-   **异常发现太晚**：缺料要等开工才发现。
    
-   **影响不可预判**：插单会挤占谁？交期会不会崩？全靠猜。
    
-   **协同靠吼**：催采购、问车间，信息散落在微信和口头。
    

轻排 PMClite 的起点，就是为这群“不想上云、买不起重型 APS”的中小工厂，做一个**能辅助决策、而不仅是记录数据**的本地化工具。

#### 二、技术选型：为什么是 Tauri + Rust + SQLCipher？

“工厂电脑很多是五年前的老机器，装完不占资源、启动快，比什么都重要。”这是我们最早做的取舍。

| 维度 | Tauri (我们的选择) | Electron |
| --- | --- | --- |
| 安装包 | **~30MB** | ~150MB |
| 内存占用 | **~60MB** | ~200MB |

数据库选用 **SQLCipher**（SQLite 的加密分支），核心原因是用户明确要求“**数据不能出本机**”。对于成本价、客户名单这类敏感数据，本地加密存储是底线，而非可选项。

#### 三、核心升级：从“看数据”到“做决策”

这是本文的重点。我们并未止步于做一个功能齐全的表格系统，而是围绕 PMC 的**决策生命周期**，重构了系统的骨架。

##### 3.1 事件驱动引擎：让系统“推着人走”

我们引入了事件驱动的核心模型。系统会自动扫描数据，将**缺料、交期风险、产能过载**等情况派生为一条条“待决策事件”，汇聚到**决策台**。

rust

```bash
// 事件派生逻辑示意（Rust端）
// 系统定期扫描活跃工单，自动识别缺料并生成事件
fn derive_shortage_events(conn: &Connection) -> Vec<Event> {
    // 1. 查询所有活跃工单
    // 2. 对每个工单执行齐套检查 (check_kit_status)
    // 3. 若存在缺口，生成带指纹(fingerprint)的事件，防止重复
    // 4. 根据交期紧迫程度动态计算 severity (red/amber)
}
```

-   **效果**：PMC 打开软件的第一眼，不再是密密麻麻的表格，而是“今天必须处理的几件事”。处理完的事件会进入历史库，决策台永远只呈现“当前需要关注的”。
    
-   ![](https://developer.qcloudimg.com/http-save/yehe-12799380/2a758b79e760e3cdcfe59a8733ff6623.png)
    

##### 3.2 分层 AI 策略：算法主算，AI 主“说”

在 AI 的引入上，我们非常克制。制造业的排产是确定性计算，容不得大模型的“幻觉”。

-   **算法层（确定性）** ：BOM 展开、齐套计算、产能负荷、排程求解，全部由 **Rust 端的确定性代码**完成，保证结果可复现、可审计。
    
-   **AI 层（解释性）** ：大模型被严格限定在**“解释”和“归纳”** 的角色上。例如，点击事件的“🤖 AI 解释”按钮，系统会先通过工具查询结构化的数据（缺料明细、在途采购、历史报工），再让 AI 基于这些**真实数据**生成一段人话解释。**AI 不生成任何新的数字**，所有数字必须可追溯、可核对。
    

这种“人在环中”的模式，比全自动 AI 排产更容易让中小工厂的资深 PMC 接受——**系统是副驾驶，不是自动驾驶**。

![](https://developer.qcloudimg.com/http-save/yehe-12799380/86abc785b4bc36786ac5bf3861b22faa.png)

##### 3.3 沙盘推演：改了之后会怎样，先算给你看

这是 PMC 场景的“杀手锏”。传统排产软件是“改了就改了”，但 PMC 最怕的就是“改出连锁反应”。

我们的**沙盘推演**允许用户在不落库的情况下，将一张工单调整到新的产线或日期。系统会基于 `calcResourceHours` 等核心算法，**实时计算出**：

-   目标工单的预计完工日期；
    
-   被挤占工单的顺延天数；
    
-   关联销售订单是否会因此逾期。
    

只有用户确认“影响可接受”后，才会真正写入数据库。**把黑盒的“系统建议”变成了透明的、PMC 可干预的“决策沙盘”**。

![](https://developer.qcloudimg.com/http-save/yehe-12799380/f7e0dc6374c24f4ac24a5d3c3a20e50f.png)

##### 3.4 移动端闭环：让数据从车间回流

我们利用 Tauri 的跨平台能力，在主机上内置了一个**轻量级 H5 报工服务**（端口 8766）。车间工人用手机扫码（或浏览器输入网址），即可完成**报工**。

-   **动态推送**：主机启动后，会自动将访问链接推送到钉钉/企微群，工人无需记录 IP。
    
-   **事件联动**：手机端提交的异常报工（如数量与计划偏差 >10%），会**自动在桌面端决策台生成“报工确认”事件**，等待 PMC 审核。正常报工则直接更新工单进度，不打扰 PMC。
    

这打通了“**计划 → 执行 → 反馈**”的最后一环，让 PMC 的决策有了来自车间一线的实时依据。

#### 四、数据治理：如何应对“历史数据爆炸”？

事件驱动的副作用是数据量增长快。我们设计了三层机制：

1.  **决策台只加载活跃事件**，历史再多也不影响日常使用。
    
2.  **历史事件独立查询**：提供分页、筛选的历史事件入口，用于复盘。
    
3.  **自动归档**：超过 90 天的已闭环事件，系统会将其**聚合为月度统计**（保留趋势价值），原始明细在备份后删除，确保数据库体积长期可控。
    

#### 五、未来规划：向 PMC 智能体演进

我们下一步的进化方向，是让系统从一个“决策辅助工具”逐步成长为“**PMC 智能体**”。

1.  **从“解释”到“建议”** ：让 AI 基于历史决策数据（哪类问题通常怎么处理），主动给出可执行的操作建议。
    
2.  **受限自主执行**：在明确授权的边界内（如“标准品的周计划微调”），Agent 可以直接执行并记录日志，PMC 只需事后审计。
    
3.  **数据资产化**：工厂在长期使用中沉淀的“排产规则”、“异常处置经验”，将形成该工厂专属的、可复用的知识库，数据真正成为资产。
    

#### 六、结语

轻排 PMClite 的这次升级，核心不在于堆砌 AI 功能，而在于**用工程化的思维，把 PMC 的决策过程结构化、可计算化、可协同化**。算法守住了确定性的底线，AI 提升了信息处理的效率，而“人在环中”的设计保证了系统的可控与可信。

对于中小制造企业的数字化，我们的体会是：**“轻”不是功能简陋，而是精准地解决核心问题，同时不带来新的负担**。这条路我们还在走，欢迎同行交流指正。

### 正文

#### 一、缘起：为什么中小工厂的 PMC 依然在“人肉决策”？

在接触了数十家 10-200 人的中小制造企业后，我们发现一个普遍现象：ERP 管好了“账本”，但**排产决策层依然是断裂的**。

PMC（生产计划与物料控制）计划员的日常是这样的：打开三四个 Excel，从 ERP 导出数据，手动 VLOOKUP 核对物料，凭借经验在日期列里填数字。行业数据显示，**75% 的制造企业仍依赖 Excel 手工排产**，当产品种类超过 50 个时，一次完整的计划调整耗时超过 2 小时，且“一改就乱”。

真正的痛点不在于“没有数据”，而在于：

-   **异常发现太晚**：缺料要等开工才发现。
    
-   **影响不可预判**：插单会挤占谁？交期会不会崩？全靠猜。
    
-   **协同靠吼**：催采购、问车间，信息散落在微信和口头。
    

轻排 PMClite 的起点，就是为这群“不想上云、买不起重型 APS”的中小工厂，做一个**能辅助决策、而不仅是记录数据**的本地化工具。

#### 二、技术选型：为什么是 Tauri + Rust + SQLCipher？

“工厂电脑很多是五年前的老机器，装完不占资源、启动快，比什么都重要。”这是我们最早做的取舍。

| 维度 | Tauri (我们的选择) | Electron |
| --- | --- | --- |
| 安装包 | **~30MB** | ~150MB |
| 内存占用 | **~60MB** | ~200MB |

数据库选用 **SQLCipher**（SQLite 的加密分支），核心原因是用户明确要求“**数据不能出本机**”。对于成本价、客户名单这类敏感数据，本地加密存储是底线，而非可选项。

#### 三、核心升级：从“看数据”到“做决策”

这是本文的重点。我们并未止步于做一个功能齐全的表格系统，而是围绕 PMC 的**决策生命周期**，重构了系统的骨架。

##### 3.1 事件驱动引擎：让系统“推着人走”

我们引入了事件驱动的核心模型。系统会自动扫描数据，将**缺料、交期风险、产能过载**等情况派生为一条条“待决策事件”，汇聚到**决策台**。

rust

```bash
// 事件派生逻辑示意（Rust端）
// 系统定期扫描活跃工单，自动识别缺料并生成事件
fn derive_shortage_events(conn: &Connection) -> Vec<Event> {
    // 1. 查询所有活跃工单
    // 2. 对每个工单执行齐套检查 (check_kit_status)
    // 3. 若存在缺口，生成带指纹(fingerprint)的事件，防止重复
    // 4. 根据交期紧迫程度动态计算 severity (red/amber)
}
```

-   **效果**：PMC 打开软件的第一眼，不再是密密麻麻的表格，而是“今天必须处理的几件事”。处理完的事件会进入历史库，决策台永远只呈现“当前需要关注的”。
    

##### 3.2 分层 AI 策略：算法主算，AI 主“说”

在 AI 的引入上，我们非常克制。制造业的排产是确定性计算，容不得大模型的“幻觉”。

-   **算法层（确定性）** ：BOM 展开、齐套计算、产能负荷、排程求解，全部由 **Rust 端的确定性代码**完成，保证结果可复现、可审计。
    
-   **AI 层（解释性）** ：大模型被严格限定在**“解释”和“归纳”** 的角色上。例如，点击事件的“🤖 AI 解释”按钮，系统会先通过工具查询结构化的数据（缺料明细、在途采购、历史报工），再让 AI 基于这些**真实数据**生成一段人话解释。**AI 不生成任何新的数字**，所有数字必须可追溯、可核对。
    

这种“人在环中”的模式，比全自动 AI 排产更容易让中小工厂的资深 PMC 接受——**系统是副驾驶，不是自动驾驶**。

##### 3.3 沙盘推演：改了之后会怎样，先算给你看

这是 PMC 场景的“杀手锏”。传统排产软件是“改了就改了”，但 PMC 最怕的就是“改出连锁反应”。

我们的**沙盘推演**允许用户在不落库的情况下，将一张工单调整到新的产线或日期。系统会基于 `calcResourceHours` 等核心算法，**实时计算出**：

-   目标工单的预计完工日期；
    
-   被挤占工单的顺延天数；
    
-   关联销售订单是否会因此逾期。
    

只有用户确认“影响可接受”后，才会真正写入数据库。**把黑盒的“系统建议”变成了透明的、PMC 可干预的“决策沙盘”**。

##### 3.4 移动端闭环：让数据从车间回流

我们利用 Tauri 的跨平台能力，在主机上内置了一个**轻量级 H5 报工服务**（端口 8766）。车间工人用手机扫码（或浏览器输入网址），即可完成**报工**。

-   **动态推送**：主机启动后，会自动将访问链接推送到钉钉/企微群，工人无需记录 IP。
    
-   **事件联动**：手机端提交的异常报工（如数量与计划偏差 >10%），会**自动在桌面端决策台生成“报工确认”事件**，等待 PMC 审核。正常报工则直接更新工单进度，不打扰 PMC。
    

这打通了“**计划 → 执行 → 反馈**”的最后一环，让 PMC 的决策有了来自车间一线的实时依据。

#### 四、数据治理：如何应对“历史数据爆炸”？

事件驱动的副作用是数据量增长快。我们设计了三层机制：

1.  **决策台只加载活跃事件**，历史再多也不影响日常使用。
    
2.  **历史事件独立查询**：提供分页、筛选的历史事件入口，用于复盘。
    
3.  **自动归档**：超过 90 天的已闭环事件，系统会将其**聚合为月度统计**（保留趋势价值），原始明细在备份后删除，确保数据库体积长期可控。
    

#### 五、未来规划：向 PMC 智能体演进

我们下一步的进化方向，是让系统从一个“决策辅助工具”逐步成长为“**PMC 智能体**”。

1.  **从“解释”到“建议”** ：让 AI 基于历史决策数据（哪类问题通常怎么处理），主动给出可执行的操作建议。
    
2.  **受限自主执行**：在明确授权的边界内（如“标准品的周计划微调”），Agent 可以直接执行并记录日志，PMC 只需事后审计。
    
3.  **数据资产化**：工厂在长期使用中沉淀的“排产规则”、“异常处置经验”，将形成该工厂专属的、可复用的知识库，数据真正成为资产。
    

#### 六、结语

轻排 PMClite 的这次升级，核心不在于堆砌 AI 功能，而在于**用工程化的思维，把 PMC 的决策过程结构化、可计算化、可协同化**。算法守住了确定性的底线，AI 提升了信息处理的效率，而“人在环中”的设计保证了系统的可控与可信。

对于中小制造企业的数字化，我们的体会是：**“轻”不是功能简陋，而是精准地解决核心问题，同时不带来新的负担**。这条路我们还在走，欢迎同行交流指正。

本文分享了轻排 PMClite 从“数据记录工具”升级为“PMC 决策中枢”的架构演进过程。重点探讨了如何通过事件驱动模型、分层 AI 策略（算法主算，AI 主说） 、沙盘推演和移动端报工闭环，解决中小制造企业 PMC 岗位的核心痛点。文章包含技术选型对比、核心模块设计思路及未来向 PMC 智能体演进的规划，适合关注制造业数字化、Tauri、Rust 及 AI Agent 落地的开发者与 PMC 从业者阅读。

从记录工具到决策中枢：轻排 PMClite 的 PMC 数字化升级实践

本文分享了轻排 PMClite 从“数据记录工具”升级为“PMC 决策中枢”的架构演进过程。重点探讨了如何通过事件驱动模型、分层 AI 策略（算法主算，AI 主说） 、沙盘推演和移动端报工闭环，解决中小制造企业 PMC 岗位的核心痛点。文章包含技术选型对比、核心模块设计思路及未来向 PMC 智能体演进的规划，适合关注制造业数字化、Tauri、Rust 及 AI Agent 落地的开发者与 PMC

人工智能

轻排PMClite以Tauri+Rust+SQLCipher实现本地化架构，通过事件驱动引擎、分层AI策略、沙盘推演及移动端报工闭环，升级为PMC决策中枢。文章详解技术选型与模块设计，解决中小工厂排产痛点，并规划向PMC智能体演进，适合制造业数字化开发者参考。

数据治理

自动驾驶

代码解释

敏感数据

数据库

智能体

SQLite

Agent

腾讯云双十一大促

oceanus

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

从记录工具到决策中枢：轻排 PMClite 的 PMC 数字化升级实践-腾讯云开发者社区-腾讯云

从记录工具到决策中枢：轻排 PMClite 的 PMC 数字化升级实践

从记录工具到决策中枢：轻排 PMClite 的 PMC 数字化升级实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐