2、文件体系总纲：为什么需要文件体系、核心文件夹结构设计、版本管理基础（Git入门）
说实话，我见过太多光学工程师，设计能力一流，但文件管理一塌糊涂。
有一次，一个同事找我借一个透镜设计源文件。他翻遍了桌面、下载文件夹、微信聊天记录，最后跟我说：“我记得文件名里有‘最终版’三个字。” 结果他发过来五个“最终版”，每个都不一样。嗯，这种场景，你想想看，是不是很熟悉？
所以，在咱们正式开始搭建光学设计文件体系之前，得先聊聊“为什么”。
2.1 为什么需要文件体系？
说白了，文件体系不是为了“好看”，而是为了“救命”。
我个人习惯，在项目启动的第一天，就把文件夹结构搭好。为什么这么急？因为项目一旦跑起来，你根本没时间回头整理。
文件体系的核心价值：
- 可追溯性：三个月后，你还能找到“当时那个0.8视场的MTF曲线”对应的ZEMAX文件。
- 可复现性：换一台电脑，或者换一个人，能完全复现你的设计过程。
- 可协作性：团队里每个人都知道“最新版”在哪里，不会出现“我改了你别动”的尴尬。
- 可交付性：项目结束时，你能快速打包出完整的交付物，而不是花三天找文件。
我在项目中遇到过最惨的一次：一个做了半年的投影镜头项目，因为硬盘坏了，所有本地文件全丢。幸好我们用了Git，从远程仓库拉回来，只损失了当天上午的工作量。从那以后，我再也不敢把文件体系当摆设。
2.2 核心文件夹结构设计
文件夹结构怎么设计？我建议你遵循一个原则：按项目生命周期分，而不是按文件类型分。
什么意思？很多人喜欢建“ZEMAX文件夹”、“CodeV文件夹”、“PDF文件夹”。这种结构，找文件的时候你会疯掉。因为一个项目里，ZEMAX文件可能有几十个版本，散落在不同子文件夹里，你根本不知道哪个对应哪个。
下面是我用了多年的结构，你可以直接拿来用：
Project_Name/
├── 00_Project_Info/ # 项目立项、需求文档、合同
│ ├── 01_Requirements/
│ ├── 02_Contracts/
│ └── 03_Meeting_Notes/
├── 01_Design/ # 设计源文件
│ ├── 01_Initial_Design/ # 初始结构
│ ├── 02_Optimization/ # 优化过程
│ ├── 03_Tolerance/ # 公差分析
│ └── 04_Final_Design/ # 最终设计
├── 02_Simulation/ # 仿真与验证
│ ├── 01_Stray_Light/
│ ├── 02_Thermal/
│ └── 03_Mechanical_Check/
├── 03_Prototype/ # 样机与测试
│ ├── 01_Drawing/
│ ├── 02_Test_Report/
│ └── 03_Photos/
├── 04_Deliverables/ # 最终交付物
│ ├── 01_Source_Files/
│ ├── 02_Documents/
│ └── 03_Presentation/
├── 05_References/ # 参考资料
│ ├── 01_Patents/
│ ├── 02_Standards/
│ └── 03_Vendor_Specs/
└── README.md # 项目说明文件
我的小技巧：
每个文件夹前面加数字编号（00, 01, 02...），这样在文件管理器里会自动按顺序排列。你想想看，打开项目文件夹，第一眼看到的就是“项目信息”，然后是“设计”、“仿真”、“样机”、“交付”，是不是很清晰？
这个结构的好处是：按流程走。你从需求开始，到设计、仿真、样机、交付，每一步都有对应的文件夹。不会出现“设计文件散落在桌面”的情况。
2.3 版本管理基础（Git入门）
说到版本管理，很多光学工程师的第一反应是：“我又不是程序员，学什么Git？”
我曾经也这么想。直到有一次，我为了对比两个优化方案的差异，手动保存了“方案A_v1.zmx”、“方案A_v2.zmx”、“方案A_final.zmx”、“方案A_final_真的最终版.zmx”…… 一共十几个文件。最后我自己都分不清哪个是哪个。
Git就是来解决这个问题的。
2.3.1 Git能做什么？
| 场景 | 传统做法 | Git做法 |
|---|---|---|
| 保存版本 | 手动复制文件，改文件名 | git commit，自动记录差异 |
| 回溯历史 | 翻找“最终版”文件 | git checkout，一键回到任意版本 |
| 对比差异 | 肉眼对比两个ZEMAX文件 | git diff，自动显示改动行 |
| 团队协作 | 微信传文件，手动合并 | git push/pull，自动合并冲突 |
| 备份恢复 | 手动复制到U盘/网盘 | git push到远程仓库，一键恢复 |
2.3.2 Git入门三板斧
你不需要成为Git专家，只需要掌握三个命令，就能解决80%的问题。
- git init：在项目文件夹里初始化一个Git仓库。只需要做一次。
- git add + git commit：保存当前版本。相当于“拍照存档”。
- git log + git checkout：查看历史版本，并切换到任意版本。
举个例子，假设你有一个ZEMAX文件：
# 第一步：初始化仓库（只在第一次做）
cd Project_Name
git init
# 第二步：添加文件并保存版本
git add 01_Design/01_Initial_Design/initial_lens.zmx
git commit -m "初始结构，双高斯，F/2.8，焦距50mm"
# 第三步：修改文件后，再次保存
git add 01_Design/02_Optimization/optimized_lens.zmx
git commit -m "第一次优化，像质提升，MTF@30lp/mm达到0.6"
# 第四步：查看历史
git log --oneline
# 输出：
# a1b2c3d 第一次优化，像质提升
# e4f5g6h 初始结构，双高斯
# 第五步：回到初始版本看看
git checkout e4f5g6h
注意：
Git默认不会跟踪二进制文件（如.zmx、.seq）的“内容差异”，它只会保存整个文件的新版本。这意味着，如果你频繁修改大文件，仓库体积会增长很快。我的建议是：每次commit只保存一个“有意义”的版本，比如“优化前”、“优化后”、“公差分析前”，而不是每改一个参数就commit一次。
2.3.3 一个简单的Git工作流
我个人习惯用这种工作流，简单、不容易出错：
- 每天开始工作前：
git pull（如果有远程仓库，拉取最新版本） - 完成一个里程碑：
git add .+git commit -m "描述改动" - 每天结束工作前：
git push（推送到远程仓库备份）
就这么简单。你不需要学分支、合并、rebase那些复杂操作。对于光学设计项目，一个主分支（main）就够了。
避坑指南：
我曾经犯过一个错误：把整个“设计”文件夹都git add了，结果把几十个中间版本文件（比如“test_001.zmx”、“test_002.zmx”）都提交了。仓库瞬间变得臃肿不堪。后来我学会了用.gitignore文件，把临时文件、中间文件排除在外。
一个简单的.gitignore示例：
# 忽略所有临时文件
*.bak
*.tmp
# 忽略中间版本（如果你有命名规范）
*_test_*
*_temp_*
2.4 本章知识结构图
下面这张图，把文件体系的三个核心部分串起来了。你可以把它当作一个“检查清单”，每次启动新项目时对照着做。