# 数控机床精度保持性评估系统：项目成果说明（详细审阅版）

## 一页总结

本项目面向数控机床整机及功能部件的精度保持性验证与评价，将周期性精度检测、循环试验和制品抽样数据组织为时间序列，并按整机与部件两类评价逻辑输出精度保持度、精度保持时间、分层得分、薄弱环节和状态信息。

项目的核心不是记录“某次测得多少精度”，而是回答两个工程问题：整机长期运行后精度保持得怎样？功能部件在预设循环内能保持有效精度多久？系统通过趋势、保持能力、波动度、失效阈值和权重汇总，将离散测量数据转化为可解释的评价结果。

现有代码与运行逻辑文档可核实：系统采用 Vue 前端、FastAPI 后端、PostgreSQL 数据库和 psycopg2 数据访问，提供项目/资产/指标/记录/制品/用户/评价等接口。项目存在本地 Git 仓库，但当前工作区有未提交改动；尚未发现独立自动化测试文件。因此应突出真实运行逻辑和数据模型，不应夸大为已完成完整工程化测试或已生产部署。

相较早期以 C# WinForms 为代表的本地桌面工具，本版以 Web 架构为核心，并保留 Electron 桌面封装入口：既能支持集中数据与多角色协作，也可在需要桌面交付时复用同一套 Vue 界面，为现场录入、后台配置、分析评价和多终端访问提供更灵活的使用方式。

---

## 1. 项目定位与业务问题

### 1.1 业务背景

精度保持性评价不是一次检测合格与否的简单判断。对于数控机床及主轴、刀架、回转台、刀库、铣头等功能部件，更重要的问题包括：

- 多次检测中精度是稳定、缓慢退化还是快速恶化；
- 精度是否已接近或超过失效阈值；
- 整机的几何精度、位置精度、加工精度哪一层是短板；
- 部件在预设循环内是否已失效；若失效，实际保持时间是多少；
- 最终评价结果是否能够追溯到指标配置、原始测点和时间序列。

### 1.2 系统目标

系统面向两类对象建立不同但可衔接的评价逻辑：

1. **整机评估**：以几何精度、位置精度、加工精度为三大准则层，对整台数控机床进行综合评价。
2. **部件评估**：以功能部件循环试验记录为基础，先判断是否达到失效阈值；未失效时评价保持度，已失效时评价保持时间。

### 1.3 目标用户与输出价值

依据系统功能，可服务于中试验证、设备研发、质量检测、试验管理和工程技术人员。用户可基于系统结果：

- 查看整机和部件当前精度状态；
- 识别长期退化趋势、波动问题和短板指标；
- 区分“仍可保持多好”与“已经能保持多久”；
- 将试验和抽样记录转化为可解释的工程评价结果；
- 支持后续验证、改进和数据补采。

### 1.4 专用评价定义与知识产权边界

本系统中的“精度保持性”“退化率”和整机综合评价不能全部按广义或通用定义理解。整机评价体系及其中多个评价量，是课题组针对数控机床特定指标和验证场景共同拟定、并形成专利成果的专用定义。

需要区分：

- **通用数学工具**：时间序列、均值、标准差、最小二乘拟合、残差、归一化等属于通用方法；
- **专用评价定义**：如何根据机床指标定义 ARDR、ARD、AFD、ACD、AD，如何解释退化速率、保持度、波动度、加工一致性与系统偏差，以及如何组合权重并逐层汇总，属于课题组面向机床精度保持性评价建立的专用方案；
- **业务分支规则**：部件达到失效阈值后从保持度切换为保持时间评价，也属于该类专门评价场景中的业务定义。

候选人参与了相关专利方案的研发及软件实现，但专利所有人并非候选人，不能表述为个人独立提出或个人拥有专利。推荐口径是：

> 参与课题组机床精度保持性专利评价方案的研发，并参与将专用指标定义、权重关系和失效判断写成软件的数据结构、计算程序与展示功能。

这表明项目不是把普通统计公式包装成页面，而是把研究型评价方法写成了可操作的工程软件。

---

## 2. 项目差异化价值

通用资产台账或检测记录系统能够保存设备与测点，但不能自然回答“精度保持性如何评价”。本项目的差异化在于将配置、数据序列、评价模型和结果解释连接起来。

| 常规数据管理 | 本项目的工程评价能力 |
|---|---|
| 保存资产和检测记录 | 将同一指标按时间排序，形成可计算的退化序列 |
| 展示单次测量值 | 同时评价退化速率、保持能力与波动稳定性 |
| 设置上下限 | 将出厂精度、失效精度、理想/极端值、循环时间、权重关联到指标 |
| 给出合格或不合格 | 输出综合得分、准则层得分、指标明细、薄弱环节和状态 |
| 记录部件试验 | 先判断是否失效，再在保持度与保持时间之间切换评价逻辑 |

因此，项目的价值在于根据精度检测数据给出**可比较、可追溯、能够定位薄弱环节的保持性评价结果**。

项目中的评价逻辑来源于课题组专利方案，不等同于行业中所有场景均采用的广义定义。软件的作用之一，就是将这些专用定义固定为统一数据口径和确定性计算流程，减少人工理解、手工计算和不同人员解释不一致的问题。

---

## 3. 输入、处理与输出

### 3.1 输入数据与配置

| 数据类别 | 内容 | 作用 |
|---|---|---|
| 项目与资产 | 项目、整机/部件资产、设备类型、资产编码 | 确定评价对象 |
| 指标定义与绑定 | 指标名称、类别、单位、出厂精度、失效精度、理想值、极端值、上下限、循环时间、权重 | 定义评价口径 |
| 周期性精度记录 | 几何和位置精度测点、记录时间、检测值 | 构成退化序列 |
| 循环试验记录 | 功能部件每次循环后的精度值 | 判断失效循环和保持时间 |
| 制品与样本记录 | 产品、抽样值、公差与关联指标 | 评价加工精度 |
| 用户与权限信息 | 用户、角色、启用状态 | 支持系统访问与管理 |

### 3.2 整机评估过程

~~~text
资产与指标绑定
        ↓
周期检测 / 制品抽样记录
        ↓
按指标和时间构造序列
        ↓
按类别分为几何、位置、加工精度
        ↓
评价量计算 → 模糊归一化 → 组合权重
        ↓
指标层 → 准则层 → 整机综合得分
        ↓
雷达图、最新状态、薄弱环节与明细
~~~

### 3.3 部件评估过程

~~~text
部件资产与指标绑定
        ↓
循环试验记录
        ↓
逐项比较失效阈值
        ├─ 任一指标失效：输出失效循环与精度保持时间
        └─ 全部未失效：计算精度保持度与平均得分
        ↓
最新状态与指标明细展示
~~~

### 3.4 输出结果

- 整机综合得分；
- 几何、位置、加工精度三个准则层得分；
- 单指标的原始评价量、模糊得分、权重、综合得分与状态；
- 雷达图维度值和薄弱环节；
- 部件的失效指标、失效循环、精度保持时间，或保持度得分；
- 当前指标绑定、记录和配置不足时的提示。

---

## 4. 核心评价逻辑

### 4.1 整机：三层指标体系

整机评估采用“目标层—准则层—指标层”结构：

| 准则层 | 评价重点 | 数据基础 |
|---|---|---|
| 几何精度 | 结构几何误差的长期保持 | 周期性精度检测 |
| 位置精度 | 定位、重复定位等运动精度的保持 | 周期性精度检测 |
| 加工精度 | 制品加工的一致性与系统偏差 | 制品抽样记录与公差 |

几何精度和位置精度的主要评价量包括：

- ARDR：由最小二乘拟合的退化曲线斜率表征退化速率；
- ARD：根据出厂精度、失效精度和误差均值表征精度保持度；
- AFD：由实测值与拟合值残差的均方根表征波动度。

加工精度的主要评价量包括：

- ACD：以样本标准差和公差带宽度评价加工一致性；
- AD：以样本均值偏离公差中心程度评价系统偏差。

各评价量先经过模糊归一化转为百分制，再结合主观默认维度权重和数据客观权重形成组合权重；之后按照指标层和准则层权重逐层汇总。

### 4.2 部件：先判断失效，再选择评价方式

部件评估体现了与整机“统一打分”不同的工程逻辑：

- 若任一指标在预设循环内超过失效阈值，系统优先采用精度保持时间评价；
- 若所有指标在预设循环内未失效，系统采用精度保持度评价。

这避免了部件已经失效却仍被一个平均分掩盖。输出不仅说明“得分多少”，还可以说明“第几次循环失效、对应多少小时保持时间、哪个指标触发失效”。

### 4.3 评价结果的解释性

系统不只返回一个分数，还保留：

- 指标类别与原始数据；
- 时间序列、拟合与残差信息；
- 归一化后的评价值；
- 权重与分层汇总路径；
- 最新状态和薄弱环节。

这使面试时能够说明“结果是如何从测量记录一步步计算出来的”。

---

## 5. 软件架构与数据流

### 5.1 架构概览

~~~text
Vue 前端
  ├─ 系统总览、项目配置、数据录入、记录管理、分析中心
  ├─ 设备台账、用户管理、系统监测与登录
  └─ 通过 REST API 提交配置、记录并展示评价结果
        ↓
FastAPI 后端
  ├─ project：项目、资产、资产指标绑定
  ├─ metric：指标定义
  ├─ record：测量与循环记录
  ├─ product：制品、参数配置、制品记录
  ├─ evaluate：整机与部件评价
  └─ user：用户与登录
        ↓
数据访问与数据库
  ├─ psycopg2 执行 PostgreSQL 查询与事务
  ├─ 启动时检查用户、指标绑定、制品相关表和字段
  └─ 保存资产、指标、绑定、记录、制品、用户和评价所需配置
~~~

### 5.2 核心请求路径示例

| 用户动作 | API/后端处理 | 数据与结果 |
|---|---|---|
| 新建或维护资产 | project 路由 | 写入资产及关联信息 |
| 给资产绑定评价指标 | project / metric 路由 | 保存阈值、出厂/失效值、权重、循环时间 |
| 录入检测或试验值 | record 路由 | 保存按时间或循环组织的记录 |
| 维护制品与样本 | product 路由 | 保存制品、参数、公差和样本数据 |
| 发起评价 | evaluate 路由 | 查询配置与记录，计算、汇总并返回评价结果 |

### 5.3 分层的工程意义

- 页面层把工程人员的配置和录入动作转为结构化请求；
- 路由层按业务领域组织接口；
- 评价层集中保留时间序列、拟合、归一化、权重和失效判断逻辑；
- 数据库保存原始记录与配置，保证后续能够复算和追溯。

这种结构也使后续修改可沿“页面—接口—计算—数据库”路径定位。

### 5.4 从 C# WinForms 单机方案转向 Web 核心

根据项目开发经历，早期精度测试软件采用以 C# WinForms 为代表的桌面客户端。这种方式对固定工位、离线使用和本地仪器控制较直接，但本项目需要解决的重点是跨项目、跨资产、跨周期的数据管理与评价协作：

- 现场检测人员需要持续录入不同资产、指标和循环的记录；
- 工程人员需要按时间读取完整序列并执行评价；
- 管理人员需要维护指标、阈值、权重和制品配置；
- 多个角色需要查看同一批最新数据，而不是传递本地文件副本。

因此，本版以浏览器/服务器架构作为数据平台核心，同时通过 Electron 保留桌面封装选项。Web 与桌面不再是两套业务逻辑：桌面端可以复用前端页面，核心数据与评价仍由后端和集中数据库统一提供。

~~~text
传统单机模式
现场电脑检测/录入 → 本地保存 → 导出文件 → 办公室整理和分析

本项目架构
浏览器或桌面封装
        ↓
统一 FastAPI 接口
        ↓
集中 PostgreSQL 数据
        ↓
统一评价逻辑与结果展示
~~~

### 5.5 各项技术选择及原因

| 技术或设计 | 选择原因 | 解决的问题 |
|---|---|---|
| 前后端分离 | 配置、录入、评价和数据管理职责不同，需要独立演进 | 避免复杂评价逻辑散落在界面中，便于追踪数据从录入到结果的过程 |
| Vue 3 + Vite | 适合构建项目配置、数据录入、记录管理和分析中心，组件复用效率高 | 统一多类业务页面和交互方式 |
| Element Plus | 提供工程管理系统常用的表格、表单、弹窗和校验组件 | 降低重复界面开发成本，保证操作一致性 |
| ECharts | 支持雷达图、趋势图和多维评价展示 | 将抽象评价量转成非算法人员可理解的结果 |
| FastAPI | Python 可直接承载时间序列、拟合、归一化与权重算法；接口开发和校验简洁 | 将评价能力封装为可复用服务，并与页面解耦 |
| PostgreSQL | 支持项目、资产、指标绑定、记录、制品和用户等关联数据的集中存储 | 支撑多人共享、历史积累、事务和复算追溯 |
| psycopg2 | 直接执行 PostgreSQL 查询和事务，便于现有表结构的精确控制 | 连接既有数据库结构和评价查询逻辑 |
| Electron | 在保留 Web 技术栈的同时提供桌面封装能力 | 兼顾传统桌面交付习惯与 Web 系统复用 |
| REST API | 为浏览器、Electron 和未来其他终端提供统一访问方式 | 避免不同终端重复实现业务和数据库逻辑 |

### 5.6 多角色协作与移动化价值

集中式架构允许多个岗位围绕同一份数据协作：

- 现场检测人员录入周期检测、循环试验和制品样本；
- 配置人员维护资产、指标、出厂值、失效阈值、循环时间与权重；
- 工程人员发起整机或部件评价，查看趋势与薄弱环节；
- 管理人员查看项目、资产和评价状态。

前端存在响应式布局实现，浏览器模式也为电脑、Pad 和手机访问提供基础。准确口径是：**架构具备多终端与移动化扩展能力，但每个页面的移动端可用性仍需通过实际屏幕、网络、权限和现场操作流程验证。**

### 5.7 架构优势总结

本次迁移的价值不是技术栈“更新”，而是工作范式变化：

- 数据从现场单机和本地文件转为集中保存的历史记录；
- 检测录入、规则配置、工程评价和管理查看可以并行开展；
- 同一评价服务可被浏览器与桌面封装复用；
- 原始数据和评价规则分离，支持复算、追溯和扩展；
- 系统从一次性测试工具转向覆盖项目、资产和长期记录的评价平台。

---

## 6. 数据结构与可追溯设计

### 6.1 核心对象关系

~~~text
项目 Project
 └─ 资产 Asset（整机或部件）
      ├─ 资产指标绑定 Asset-Metric Bind
      │    ├─ 指标 Metric
      │    ├─ 阈值 / 出厂值 / 失效值 / 权重 / 循环时间
      │    └─ 测量记录 Record
      ├─ 关联制品 Product
      │    ├─ 制品参数配置
      │    └─ 制品抽样记录 Product Record
      └─ 评价结果所需的状态与时间序列

用户 User
 └─ 登录、角色、启用状态
~~~

### 6.2 配置与原始数据分离

系统将“评价规则”和“实际检测值”分开保存：

- 规则层负责指标类别、失效阈值、理想/极端值、循环时间和权重；
- 数据层负责每次检测、循环或抽样记录；
- 计算层在评价时读取两类信息，生成可解释结果。

这样可减少把规则写死在单次记录中的风险，也便于同一框架适配不同资产、部件和产品。

---

## 7. 演示案例、验证边界与改进方向

### 7.1 文档中的样例结果

项目运行逻辑说明给出两类演示验证：

- 整机样机案例覆盖率为 100%，综合得分约 87.47 分；三层得分显示位置精度相对更值得关注；
- 部件案例展示两种分支：精密主轴 A 在固定循环内未失效，采用保持度评价；立式刀架 B 的 Z1 轴定位精度在第 4 次循环超过阈值，切换为保持时间评价，示例保持时间约 32 小时。

这些结果适合用于演示计算过程和两种评价分支，不应表述为真实客户设备的生产绩效或正式认证结果。

### 7.2 已有的工程性措施

从代码可见：

- 后端启动时检查和补齐部分数据库表/字段；
- 评价逻辑包含样本数量、空数据、分母为零、权重无效等处理；
- 提供数据库健康检查接口；
- 对整机与部件场景进行了明确的分支建模；
- 项目存在 Git 仓库，可用于后续建立改动记录。

### 7.3 当前边界

- 当前工作区存在未提交改动，后续应先整理版本基线再用提交记录支撑项目迭代经历；
- 尚未发现独立自动化测试文件，不能声称已形成完备测试体系；
- 未从现有材料确认真实生产部署、客户应用或第三方认证；
- 默认管理员初始化和数据库连接配置属于开发环境内容，正式展示或部署前应进一步审查安全配置。

### 7.4 优先改进建议

1. 为 ARDR、ARD、AFD、ACD、AD 和失效切换规则建立已知答案测试；
2. 为空记录、单点记录、失效阈值边界、权重缺失建立边界测试；
3. 在 Git 中完成一次干净的基线提交，并为后续变更保留需求、diff 和验证记录；
4. 增加数据字典和“指标配置—公式—页面结果”对照文档；
5. 将开发默认账号、密码和连接配置迁移为安全的部署配置。

---

## 8. 候选人的项目所有权与 AI 辅助边界

以下表述应以候选人的实际经历为准：

- 候选人围绕数控机床精度保持性验证场景提出整机和部件两类评价需求；
- 候选人参与课题组精度保持性专利评价方案研发，并参与将专用评价量、权重关系和失效分支转化为软件功能；
- 候选人参与梳理资产、指标、测量记录、阈值、循环时间、制品样本和评价结果之间的数据关系；
- 候选人参与定义“未失效评价保持度、已失效评价保持时间”的业务规则和展示要求；
- AI 编程工具用于加速页面、接口、数据库访问、计算代码和调试文档的实现；
- 候选人应逐步掌握对核心评价过程、输入输出、边界条件和结果案例的验收。

推荐表达：

> 项目采用 AI 辅助开发。我围绕数控机床整机与功能部件的精度保持性验证需求，参与定义指标绑定、周期记录、失效阈值、评价分支和结果展示逻辑，并使用 AI 工具加速前后端与数据库功能的实现、调试和迭代验证。

涉及专利时推荐补充：

> 整机精度保持性及相关专用评价指标来源于课题组共同研发的专利方案，我参与了方案研发和软件实现；专利权归属不属于个人。

---

## 9. 面试时的三分钟讲解结构

1. **问题**：单次精度检测无法回答设备或部件的长期保持能力，也难以区分趋势退化、波动和已经失效。
2. **方案**：系统将课题组专利方案中的专用评价定义软件化：整机按几何、位置、加工精度三层评价，部件先判断是否失效，再选择保持度或保持时间评价。
3. **实现**：Vue 负责项目配置、数据录入和结果展示；FastAPI 按项目、指标、记录、制品和评价拆分接口；PostgreSQL 保存配置与原始数据；评价模块完成序列、拟合、归一化和权重汇总。
4. **结果**：系统返回总分、准则层、单指标、状态和薄弱环节；失效部件还可返回失效循环和保持时间。
5. **所有权**：我参与课题组专利评价方案研发，并推动专用指标、权重关系和失效规则的软件化；项目使用 AI 辅助开发，我负责业务规则、数据结构、验收案例和迭代方向。

---

## 10. 审阅结论

该项目最值得展示的是“将精度检测和循环试验数据转化为可解释保持性评价”的能力。后续压缩为简历时，应保留整机/部件双路径、失效优先逻辑、时间序列评价、配置化指标、前后端数据库架构和 AI 辅助验收；删除大段公式细节、演示得分和具体内部表名。
