🔬 核心假设
当 Gemini 从图像输入转换为 TikZ 代码输入时，底层推理机制可能并未根本改变。模型可能在内部将图像转换为类代码表示：
图像输入
→
内部类代码结构
→
推理
注意：这是推测性的 —— 我们无法看到 Gemini 的���部处理流程。
随着时间推移，推理正在从自然语言表达转向更加结构化和形式化定义的表示方式。
📋 案例研究
2 推理方向差异
图像推理从左到右进行，但 TikZ 代码从原语向上生成。仔细检查 TikZ 代码会发现，它已经编码了几何含义 —— 代码与门级结构配对。
4 代码冗余问题
代码仍然太长和冗余。例如，我们真的需要编码详细的颜色样式吗？答案是否定的 —— 重要的是数值映射，而非样式属性。
5 代码长度问题
再次出现生成代码不必要地过长的问题。
7 平行关系感知
此案例展示了对图中平行关系感知的失败。然而，TikZ 包含可以帮助推断平行性的显式构造。关键问题是：如何正确地将相关 TikZ 代码与图像中的平行关系配对？
10 结构化信息利用
类似问题：TikZ 代码已包含角度计算和简单几何公式等注释，隐式编码了距离或对齐信息。问题在于如何有效利用这些结构化信息。
📝 结论
TikZ 代码通过显式编码几何关系（坐标、角度、距离）并将原语与语义注释配对，相比原始图像提供了结构性优势。然而，两个关键挑战仍然存在：
1. 代码冗余
样式属性（颜色、线条样式）增加了噪声而无语义价值。只有数值映射对推理有意义。
2. 配对问题
模型必须正确识别哪些代码元素与特定几何关系相关（例如，哪些线是平行的，哪些角度对应哪些连接）。这需要超越顺序解析的结构化代码理解。
核心洞见
从自然语言（图像描述）到结构化代码（TikZ 原语）的转变使更形式化的几何推理成为可能，但有效性取决于过滤冗余信息和学习代码到关系的映射。