2、光学设计文档类型概览
做光学设计这些年，我经手过的项目少说也有几十个。每次复盘时都会发现一个规律：项目出问题，往往不是设计水平不够，而是文档没管好。你想想看，一个镜头从概念到量产，中间会产生多少种文件？每种文件又该谁来维护、谁来审核、怎么存档？
这一章，我就把光学设计中最常见的五类文档掰开揉碎讲清楚。说白了，这就是你后续做版本管理的“原材料清单”。
2.1 设计规格书 —— 项目的“宪法”
设计规格书是所有文档的起点。它定义了你要设计什么、达到什么指标、在什么约束下工作。没有它，后面的所有工作都是无根之木。
我个人习惯把规格书分成三个层次：
| 层次 | 内容 | 典型参数 |
|---|---|---|
| 系统级 | 光学系统整体性能要求 | 焦距、F/#、视场角、工作波段、MTF下限 |
| 组件级 | 各光学元件的独立要求 | 曲率半径公差、厚度公差、折射率允差、阿贝数允差 |
| 环境级 | 系统工作与存贮条件 | 温度范围、湿度、振动、气压、寿命 |
规格书还有一个容易被忽视的作用：它是版本追溯的“锚点”。每次设计变更，都要问一句：这个变更是否突破了规格书的边界？如果突破了，规格书本身就要升版。
2.2 ZEMAX/CAD源文件 —— 设计的“DNA”
这是光学设计师最熟悉的文件类型。ZEMAX（或Code V、LightTools）源文件记录了完整的光学系统结构、材料、优化变量和评价函数。CAD源文件则记录了机械结构、镜筒、隔圈、压圈等实体模型。
嗯，这里要注意：源文件管理最容易出问题的不是“怎么存”，而是“存了什么”。
- ZEMAX文件：除了.zmx文件本身，还要保存对应的玻璃库文件（.agf）、镜头数据表格、点列图、MTF曲线截图。我见过有人只存了.zmx，结果换台电脑玻璃库路径不对，整个文件打不开。
- CAD文件：建议同时保存原生格式（如.SLDPRT）和通用格式（如.STEP、.IGES）。通用格式用于跨软件协作，原生格式用于后续修改。
2.3 测试报告 —— 设计的“成绩单”
设计做得好不好，不是设计师说了算，是测试数据说了算。测试报告记录了实际加工装配后的系统性能数据，是验证设计是否达标的核心依据。
一份完整的测试报告应该包含：
- 测试条件：环境温度、湿度、测试设备型号、校准日期。这些信息决定了测试数据的可信度。
- 原始数据：干涉仪波面图、MTF测试曲线、畸变网格图。不要只放处理后的结果，原始数据才是追溯的“铁证”。
- 与规格书的对比：每个测试项都要有“实测值 vs 规格值”的对照表。超出公差的部分要用红色标注，并附上偏差分析。
- 测试人、审核人、日期：这是文档追溯的基本要素，缺一不可。
2.4 变更记录 —— 设计的“日记本”
变更记录是版本管理的核心工具。它记录了谁、在什么时间、因为什么原因、对设计做了什么样的修改。没有变更记录，版本追溯就是一句空话。
我个人习惯用表格来管理变更记录，格式如下：
| 变更编号 | 日期 | 变更人 | 变更内容 | 变更原因 | 影响范围 | 审批人 |
|---|---|---|---|---|---|---|
| CR-2024-001 | 2024-03-15 | 张三 | 将第3片透镜材料从H-ZF52改为H-ZF62 | 原材料供货周期延长至12周 | 像质、热稳定性、成本 | 李四 |
| CR-2024-002 | 2024-04-02 | 王五 | 调整第2、4面空气间隔，从2.5mm改为2.8mm | 优化MTF，提升0.7视场性能 | 镜筒长度、公差分配 | 李四 |
2.5 评审纪要 —— 设计的“会议记录”
评审纪要是最容易被人忽视、但追溯价值极高的文档。它记录了设计评审、变更评审、阶段评审中的讨论内容、决策结果和待办事项。
为什么说它重要？因为很多设计决策的“为什么”不会写在规格书里，也不会写在源文件里，而是写在评审纪要里。比如：
- “为什么选择了非球面而不是增加一片球面镜？” —— 因为评审时大家讨论过，非球面虽然加工成本高，但能减少一片透镜，整体重量和长度更优。
- “为什么公差放得这么松？” —— 因为评审时确认了，这个系统对温度漂移不敏感，可以适当放宽机械公差来降低成本。
这些“隐性知识”如果不记录下来，半年后换个人来维护这个设计，他完全不知道当初的决策逻辑，只能重新分析一遍。
2.6 五类文档的关系
这五类文档不是孤立的，它们构成了一个完整的闭环：
- 设计规格书定义目标 → ZEMAX/CAD源文件实现目标 → 测试报告验证目标 → 如果发现问题，通过变更记录修改设计 → 修改方案经过评审纪要确认后执行 → 更新后的设计再次进入测试验证。
你想想看，如果其中任何一个环节的文档缺失或管理混乱，这个闭环就会断裂。到时候出了问题想追溯，就像在迷宫里找出口——不是找不到，而是找到了也说不清路径。