【效率工具】让多个AI模型讨论光学问题,效果怎么样?||之晓光学

在理解了“赛博课题组”的角色分工后，很多同行可能会好奇，这几个 AI 究竟是如何有条不紊地推进一个光学预研项目的？这就不得不提这套系统背后的标准化工作流（Workflow）和逻辑思路了。为了让大家更直观地理解，我将这个过程拆解为三个极其贴近我们真实工作状态的核心环节。

我们使用kimi、豆包、通义千问、deepseek和豆包五种国产模型，设置三个专家角色。为了让大家更直观地理解这几个 AI 是如何有条不紊地推进研究的，我们来看一个具体的实操案例：

AR 眼镜逐渐兴起，戴AR眼镜在运动会场看比赛或在演唱会场看演唱会时，直接用眼镜上的摄像镜头拍摄，由于演唱会或运动场很大，所以要求镜头焦距尽量长。但由于镜头装在眼镜上，所以重量尽量轻。 根据以上场景，现要求设计一款焦距尽量长、重量尽量轻的镜头。

请梳理各种技术路线在目前学术界和工业界的应用现状。请从光学理论角度对比各类的优缺点。最后请专家从指标的的角度，评估一下各种方案所能达到的性能边界，并给出一个综合建议。

第一阶段：需求拆解与前沿知识检索

我们把指标也提交给赛博课题组，不指望给出具体内部参数，只需要让AI们讨论出一个技术路线。此时系统会根据用户输入的角色，自动分配让任务：

这里我是用的Lead是kimi，Host是qwen3.5-plus，reporter是豆包。实际上我们已经可以不管这个界面，去做别的事情了（例如开会、写报告、做PPT、画CAD图等其他会占用大量时间的工作）。AI会自动规划任务流程：

二阶段：多角色激辩与结构化状态追踪

一开始AI设定的任务流程不一定合理，但是在讨论的过程中，不同的角色具备不同的能力，对于提出的观点，有二次验证和复核环节，同时会根据检索到的资料以及其他AI的发言修正任务。

它会敏锐地提取出“焦距尽量长”与“光学总长极短（轻量化）”这一对核心物理矛盾，并指派文献综述员去检索轻薄长焦方案。目前的版本中，AI可以自动检索arXiv，后续版本我们也会升级自主学习能力。

在这个阶段，课题组爆发了极其精彩的“技术路线之争”。有专家激进地提出使用“超构表面（Metasurface）或衍射光学”方案，认为这能把厚度做到微米级；但光机审稿人立刻予以反击，指出在大光圈下，超构表面的边缘衍射效率会断崖式下跌，绝对无法满足边缘相对照度（Rel）的要求，且存在严重的彩虹纹色散。在经历了几轮无情的工程可行性拷问后，AI 们集体向物理约束低头，否决了纯超构表面的幻想，转而给出了更为务实的“全塑料非球面+潜望式折返光路”的综合方案。

第三阶段：工程产物生成与研讨纪要输出

在目前的版本中，用户设定的综述角色会在讨论完成后输出一个md文件的报告，我们可以用一些免费工具转换成word，这样，我们就能直接看到讨论的结果。

当激辩达成共识后，系统的“记录员（Reporter）”会开始收尾。它不再像普通对话框那样输出零散的聊天记录，而是自动生成一份高度结构化的 Markdown 甚至 LaTeX 排版的专业研究报告。报告中清晰地列出了最终推荐的技术路线、被否决方案的致命缺陷、以及遗留的工程风险点。对于没有达成共识的问题，纪要中也会指出，这给了我们检索相关资料的方向。

这个问题对于人类光学工程师来说比较简单，当AI工程师接收到“消除二级光谱”的任务后，它也不会凭空去猜测材料，而是会立刻触发文献与数据检索模块。系统会自动拆解任务，去查阅异常色散玻璃的特性，抓取相对部分色散与阿贝数的线性偏离关系。

在这里，我们的赛博课题组还在正常工作，尝试从理论上计算光谱特性。编程专家迅速写出了一段 ZPL 宏代码草稿，试图在成都光明的玻璃库中循环遍历，计算每一块候选玻璃的相对部分色散，以寻找能满足消二级光谱线性方程的理想组合；而审稿人则在一旁紧盯着材料的价格等级和加工难度。

我们可以仔细观察一下讨论的过程，资料备齐后，课题组进入最核心的协同推演阶段。光学专家首先给出一套初步构想，比如提议使用某款高异常色散的重冕玻璃（如H-ZPK系列）搭配普通的火石玻璃来满足的复消色差条件。

非常有意思的是，两片透镜是无法复消色差的，课题组在讨论中发现了这一点。它在发现两块玻璃的方程组无解后，陷入了纯数学的“局部最优解”陷阱。它开始不断微调光焦度分配，试图给出一个“虽然没完全消色差，但数值已经最小”的妥协方案，却始终没有产生“跳出原有维度，增加一个自由度（第三块玻璃）”的物理直觉。

可惜的是，AI的解决思路不是增加第三片透镜或者引入衍射面，而是选择放弃复消色差的目标，转而想办法使两片透镜组合的光学系统色差尽量小：

这样的现象说明AI 拥有极强的具体问题推理和求解能力，但缺乏物理上的“升维跳跃”直觉。目前的生成式AI模型极其依赖于人类导师来指定宏观战略（比如指定自由度），只有输入的条件足够清晰，它们才能去完成复杂战术执行（推导、写代码、排公差）的人机协作。这也是目前比较火的openclaw面临的一个问题，消耗了大量的tokens，却得不到可用的结果。