4. 测量程序命名与版本规范

在ZEISS CALYPSO的实际使用中，测量程序（.cmp/.cal 等）往往由多人、多台设备、多个项目并行维护。如果命名随意、版本混乱，就会出现“同名不同件”“同件多版”“改完不知道改了什么”的典型问题。本节要解决的不是“起个好听的名字”，而是建立一套可被机器识别、可被人快速判断、可被追溯的命名与版本体系，让程序从创建到报废的每一步都有据可查。

一、统一命名规则：让文件名本身携带信息

命名规则的核心目标是：不打开程序，仅凭文件名就能判断它测什么、属于谁、处于什么状态。推荐采用“分段式结构”，用固定分隔符（如短横线或下划线）连接各语义段，避免空格和中文标点，防止跨系统传输时乱码。一个可直接落地的结构如下：

项目代号_零件号_工序号_特征类型_设备编号_版本号
示例：PRJ-A21_8472-113_OP30_GEAR_HOUSING_CMM-02_V1.3.0

各段含义需要团队统一约定并写入规范文档：项目代号用于区分产品线或客户；零件号与图纸一致，避免自造简称；工序号对应工艺路线；特征类型说明测量对象（如壳体、齿轮、孔组）；设备编号标明程序适配的机型或测头配置，因为不同测头半径、不同探针组会直接影响测量结果；版本号单独成段，便于排序和检索。分隔符统一使用下划线，段内若需连接用短横线，保证任何一段都不会与分隔符冲突。

需要特别强调的是禁止事项：不得使用“新建文件夹”“最终版”“最终版2”“张三改的”这类无信息量命名；不得在文件名中出现空格、斜杠、冒号等操作系统或传输协议敏感字符；不得用中文全角符号混排。命名一旦确定，应由程序管理员在共享目录中建立模板，新建程序时直接复制模板改名，减少人为随意性。

二、版本号管理：用语义化版本表达变更程度

版本号建议采用主版本.次版本.修订号三段式（如 V1.3.0），每一段的递增条件必须明确，否则版本号就失去意义。判断依据如下：

• 主版本号（Major）：测量策略发生根本性变化，例如更换基准体系、改变探针配置、测量元素数量增减导致结果不可直接比较。此时旧数据与新数据不能混用，必须重新做MSA或比对验证。
• 次版本号（Minor）：测量逻辑不变，但增加了新特征、调整了部分元素的测量顺序或采点数量，结果仍可与旧版本对比。递增次版本号时需在变更记录中说明新增或调整了哪些元素。
• 修订号（Patch）：仅修正笔误、注释、输出报告格式、公差显示方式等不影响测量值和判定结果的改动。修订号递增可简化审批，但仍需记录。

版本号必须与程序文件同步更新，不能出现“文件已改、版本号没动”的情况。建议在程序内部也写入版本信息，例如在CALYPSO的“程序信息”或注释区填写版本号和修改日期，这样即使文件被重命名，打开程序仍能确认版本。版本号只增不减，禁止回退覆盖；若确需回退，应新建一个更高版本号并注明“回退至V1.2逻辑”，保留历史版本文件。

三、变更记录与程序追溯机制

变更记录是版本管理的“账本”，追溯机制是“查账路径”。两者结合，才能回答“这个尺寸是谁、什么时候、为什么改的”。推荐使用一张程序变更记录表，与程序文件同目录存放，或纳入PLM/质量系统。表中至少包含以下字段：

追溯机制的关键在于“程序—报告—零件”三者绑定。每次测量输出的报告应自动或手动记录程序名称与版本号，报告归档时与程序版本对应。当出现质量争议时，可通过零件批次号查到测量报告，再由报告查到程序版本，最后由变更记录查到修改人和修改原因。建议在共享目录中按“项目/零件/工序”建立文件夹，每个文件夹内保留当前有效版本和“历史版本”子目录，历史版本只读，禁止直接修改。

四、落地执行要点

规范要真正生效，需要三个配套动作。第一，建立命名模板与版本号规则文档，放在共享目录首页，新程序创建时强制参照。第二，设置程序管理员角色，负责审核命名、批准版本升级、维护变更记录表，避免人人可改、无人负责。第三，定期审计，例如每月抽查10个程序，检查文件名、内部版本信息、变更记录三者是否一致，发现不一致立即整改并记录。

总结来说，命名规则解决“找得到”，版本号解决“分得清”，变更记录解决“说得明”，追溯机制解决“查得回”。四者形成闭环，测量程序才从个人工具变成受控资产，这也是ZEISS测量程序标准化建设中必须优先固化的基础环节。