文件命名与目录结构规范：命名规则、目录层级设计、项目文件组织最佳实践
光学设计项目的交付物通常包含设计源文件（Zemax、Code V、LightTools 等）、机械接口图纸、加工图纸、测试报告、版本变更记录、仿真脚本和会议纪要。在实际工程中，大量项目延误和质量问题并非源于光学设计本身，而是源于文件管理混乱——找不到最新版本、无法追溯设计依据、目录层级过深导致协作困难。本章将围绕命名规则、目录层级设计和项目文件组织最佳实践三个核心模块展开，帮助学员建立一套可落地、可审计、可复用的文件管理规范。
3.1 命名规则：让文件名自解释
光学设计文件命名的最核心目标是：任何人（包括未来的自己）在不打开文件的情况下，仅凭文件名就能判断文件的内容、版本、适用状态和责任人。一个规范的文件名应当包含四个必要信息段：项目标识、内容描述、版本状态、日期或作者信息。推荐采用以下通用模板：
[项目代号]_[模块/子系统]_[文档类型]_[版本号]_[日期YYYYMMDD].[扩展名]
示例：
PRJ_ALPHA_LENS_OPT_V2.1_20250615.zmx
PRJ_ALPHA_LENS_MECH_IF_V1.0_20250610.stp
PRJ_ALPHA_LENS_TEST_MTF_V0.9_20250618.xlsx其中，项目代号建议使用不超过8位的字母数字组合，如“PRJ_ALPHA”代表某型号投影镜头项目；模块/子系统字段用于区分同一项目下的不同光学子系统（如“LENS”“ILLUM”“IMG”）；文档类型字段使用标准缩写（OPT=光学设计、MECH=机械接口、TEST=测试报告、SIM=仿真脚本、BOM=物料清单）；版本号遵循“V主版本.次版本”格式，主版本在重大设计变更时递增，次版本在局部优化时递增；日期字段使用8位数字格式，确保按文件名排序时自然形成时间序列。
3.2 目录层级设计：平衡深度与可访问性
目录层级设计的目标是让项目成员在不超过3次点击内到达目标文件。推荐采用“生命周期阶段—专业域—具体交付物”的三级结构，总深度控制在4层以内（含根目录）。典型的光学设计项目目录结构如下：
PRJ_ALPHA/
├── 01_Design/
│ ├── ZMX_Sequential/ # 序列模式光学设计
│ ├── NSC_NonSequential/ # 非序列模式（杂散光、照明）
│ ├── CAD_Interface/ # 机械接口文件（STP、IGES）
│ └── Design_Notes/ # 设计说明、计算书
├── 02_Verification/
│ ├── Simulation/ # 仿真脚本、公差分析结果
│ ├── Test_Report/ # 实测报告（MTF、畸变、透过率）
│ └── Correlation/ # 仿真与实测对比分析
├── 03_Manufacturing/
│ ├── DWG_DXF/ # 加工图纸
│ ├── BOM_List/ # 物料清单
│ └── Supplier_Info/ # 供应商沟通记录
└── 04_Project_Management/
├── Meeting_Minutes/ # 会议纪要
├── Change_Requests/ # 变更申请
└── Schedule/ # 项目计划这种结构的优势在于：一级目录按项目生命周期划分，符合设计流程的自然推进逻辑；二级目录按专业工具或交付物类型划分，便于不同角色（光学工程师、机械工程师、测试工程师）快速定位自己的工作区域；三级目录（如Design_Notes）用于存放辅助性文档，避免主目录文件过多。需要特别注意的是，禁止在目录中使用中文名称或包含空格，因为部分光学设计软件（如Zemax的某些版本）和版本控制工具对非ASCII字符支持不佳，可能导致文件路径解析错误。
| 目录层级 | 命名示例 | 内容说明 | 访问频率 |
|---|---|---|---|
| 一级（生命周期） | 01_Design | 设计阶段所有交付物 | 高 |
| 二级（专业域） | ZMX_Sequential | 序列模式光学设计源文件 | 高 |
| 三级（具体交付物） | Design_Notes | 设计计算书、假设记录 | 中 |
| 四级（版本归档） | Archive_V1 | 已冻结版本的备份 | 低 |
3.3 项目文件组织最佳实践：版本控制与协作机制
在多人协作的光学设计项目中，文件组织不仅是目录结构问题，更是流程管理问题。最佳实践包含三个关键机制：版本冻结与归档、工作区与发布区分离、变更记录可追溯。版本冻结指当设计通过评审后，将当前文件复制到Archive目录并标记为“冻结”，后续修改必须基于冻结版本创建新分支，禁止直接修改冻结文件。工作区与发布区分离是指每位工程师在个人工作目录（如01_Design/ZMX_Sequential/Working/）中操作，完成自检后提交到共享发布区（如01_Design/ZMX_Sequential/Release/），发布区文件由项目负责人统一审核后更新版本号。
3.4 实战案例：某车载镜头项目的文件重组
某车载镜头项目在开发中期出现严重文件管理问题：光学设计工程师使用“最终版”“V3_修改”“V3_修改2”等命名，机械工程师将STP文件直接放在共享盘根目录，测试报告散落在各人电脑中。项目评审时，客户要求提供完整的设计追溯链，团队花费两周时间才整理出可用的文件清单，且发现三处设计版本与测试报告不匹配的问题。
项目负责人决定进行文件重组，具体操作如下：第一步，建立标准目录结构（如上文所示），并制定命名规则模板；第二步，对现有文件进行盘点，按“当前有效版本”“历史归档版本”“废弃文件”三类分类，废弃文件移入_Trash目录（保留30天后删除）；第三步，为每个光学设计文件建立版本记录表，记录修改日期、修改人、修改内容和关联的测试报告编号；第四步，在共享服务器上设置权限，设计工程师对Working目录有读写权限，对Release目录只有读取权限，项目负责人拥有全部权限。
重组后的效果显著：文件定位时间从平均15分钟缩短至2分钟以内；客户审计时，设计追溯链完整清晰，一次通过；后续设计变更时，工程师基于冻结版本创建新分支，变更影响范围一目了然。复盘经验表明，文件规范的价值不在于“好看”，而在于降低沟通成本、减少版本错误、满足审计要求。该项目的教训是：文件规范应在项目启动时建立，而非在出现问题后补救；规范需要配套培训，确保每位成员理解并执行。
3.5 总结与自检清单
文件命名与目录结构规范是光学设计项目管理的“地基工程”，虽然不直接产生设计价值，但决定了项目交付的质量和效率。本章核心要点可归纳为：命名规则追求“自解释”，目录层级追求“3次点击可达”，文件组织追求“版本可追溯、权限可控制”。在实际执行中，建议团队在项目启动会上共同确认命名规则和目录结构，并写入项目章程；在项目进行中，由项目负责人定期检查文件组织情况，及时纠正偏差。
| 自检项 | 合格标准 | 检查方法 |
|---|---|---|
| 命名完整性 | 文件名包含项目代号、内容、版本、日期 | 随机抽取10个文件检查 |
| 目录深度 | 从根目录到目标文件不超过4层 | 手动浏览目录树 |
| 版本冻结 | 冻结文件无修改记录，修改基于新分支 | 查看文件修改时间与版本记录表 |
| 归档完整性 | 所有历史版本在Archive目录可查 | 对比版本记录表与Archive目录内容 |
| 权限设置 | Working/Release目录权限符合角色分工 | 使用不同账号测试访问权限 |
最后需要强调的是，文件规范不是一成不变的教条，而应随着项目规模和团队协作方式的变化进行适当调整。但无论如何调整，“可追溯、可定位、可审计”这三个核心原则必须始终坚守。