3. MERLIC开发环境与项目结构

MERLIC 的工程交付质量，很大程度上取决于开发环境是否被正确理解与组织。很多初学者把 MERLIC 当成一个“打开就能跑”的软件，结果在换机、换版本、远程部署时频繁踩坑。要避免这些问题，必须先厘清三个核心概念：MERLIC Creator、MERLIC Runtime，以及它们之间的远程执行关系，再在此基础上建立规范的项目文件组织与版本管理习惯。

Creator 与 Runtime：开发态与运行态的分离

MERLIC Creator 是图形化的开发环境，用于搭建视觉流程（Vision Procedure）、配置工具参数、调试图像、设计前端界面（Frontend）。它面向工程师，允许反复修改、试跑、观察中间结果。MERLIC Runtime 则是执行环境，它不提供流程编辑能力，只负责加载已保存的 MERLIC 项目（.mvtc 文件）并稳定运行，对外提供图像采集、结果输出与通信接口。

这种分离带来一个关键约束：Creator 中调试通过的流程，必须在 Runtime 上重新验证。因为两者在授权、相机驱动、通信插件、运行参数上可能不同。例如 Creator 常以“试用/开发授权”运行，而 Runtime 需要对应的运行授权（如 MERLIC Runtime License）；Creator 中可能使用本地图像文件夹作为图像源，Runtime 则连接真实工业相机。若忽略这一点，就会出现“开发机正常、产线机报错”的典型问题。

远程执行：Creator 与 Runtime 的协同方式

MERLIC 支持远程执行模式：Creator 可以作为客户端，连接到运行在另一台设备（或本机另一进程）上的 MERLIC Runtime，从而在开发机上远程启动、停止、监控流程。这在工程上非常实用——开发工程师在办公室调试，产线设备只部署 Runtime，避免把开发环境暴露在生产现场。

远程执行的关键配置项包括：目标设备的 IP 地址与端口、Runtime 是否允许远程连接、双方 MERLIC 版本是否兼容。一个常见误区是版本不一致：Creator 与 Runtime 的主版本号（如 5.x 与 5.y）若差异过大，远程连接可能失败或行为异常。因此工程规范中应明确记录“开发环境版本”与“部署环境版本”，并尽量保持一致。

项目文件组织：从“一个文件”到“一套工程”

MERLIC 的核心项目文件是 .mvtc，它内部封装了流程、工具参数、前端布局与通信配置。但一个可交付的工程绝不止一个 .mvtc。实际项目中通常还包含：相机配置文件、标定文件（如 .cal）、通信协议文档、测试图像集、部署说明、版本记录。若把这些散落在桌面或临时文件夹，交付时极易遗漏。

推荐的工程目录规范如下（示例结构，可按团队调整）：

Project_XYZ/
├── 01_Project/
│   ├── XYZ_Inspection_v1.2.0.mvtc      # 主项目文件
│   └── XYZ_Inspection_v1.2.0.bak       # 备份
├── 02_Config/
│   ├── camera_config.json              # 相机参数
│   ├── calibration.cal                 # 标定文件
│   └── communication_tcp.xml           # 通信配置
├── 03_TestImages/
│   ├── OK/                             # 合格样本
│   └── NG/                             # 缺陷样本
├── 04_Docs/
│   ├── 部署说明.md
│   └── 版本记录.md
└── 05_Release/
    └── v1.2.0/                         # 交付包（含 Runtime 所需全部文件）

这样组织的好处是：开发、测试、部署三套环境可以共享同一份目录结构，只需替换 01_Project 中的 .mvtc 与 02_Config 中的配置，即可完成版本切换。交付时直接打包 05_Release 下的对应版本，避免“漏文件”。

版本管理与工程目录规范

MERLIC 项目是二进制文件，Git 无法直观 diff，因此版本管理要依靠命名规范 + 标签 + 变更记录。建议 .mvtc 文件名包含版本号与日期，例如 XYZ_Inspection_v1.2.0_20240612.mvtc；每次提交在版本记录中写明：修改了哪个工具、调整了什么参数、影响了哪些检测项。

工程目录规范还应明确“谁在什么环境下运行”。例如：开发机使用 Creator + 试用授权，产线机使用 Runtime + 正式授权；两者版本号必须记录在部署说明中。若产线机需要远程执行，则需在部署说明中写明 Runtime 的 IP、端口、是否开启远程连接，以及防火墙放行规则。

一个可执行的交付检查清单

为便于落地，下面给出一份可直接使用的交付前检查清单（示例，按项目实际情况增删）：

把这份清单纳入交付流程，可以显著减少“现场才发现问题”的概率。MERLIC 的工程化，本质上就是把开发态的灵活性与运行态的稳定性，通过规范的文件组织与版本管理连接起来。Creator 负责“做对”，Runtime 负责“做稳”，而目录规范与版本记录负责“可复现、可追溯”。