夜雨聆风同一张 DWG，为什么会在截图、PDF 和结构化数据里变成三个世界？
前几次测试 AI 看图纸，我们用的都是图片。
这也是大多数人最容易采用的方式：打开 CAD，截一张图，发给模型，然后开始提问。图片里的房间名称、尺寸和构件都来自原图，看起来并没有改变。
但这次把同一张 DWG 分别做成 PNG、PDF 和结构化 JSON 后，结果差得很明显。
两款模型在三种输入上的机械评分，碰巧都是 5 分、7 分和 9 分。但分数不是最值得看的结果：图片里的喷头，两边都只数出 36 个；到了 PDF，一个数出 24 个，另一个数出 50 个；换成 JSON，两边都准确找到 87 个喷头，却又同时把轴网分错了。
模型没有换，问题也没有换。变的是模型收到的证据。
我们怎样做这次对照测试
测试对象是一份真实喷淋图纸，图号为 08，包含“一层喷淋平面图”和“夹层喷淋平面图”。
我们从同一份 DWG 准备了三组输入：
1. 两张 A2、300 DPI 的 PNG，分别对应一层和夹层。 2. 一份两页 A2 PDF，第一页为一层，第二页为夹层。 3. 一份从 DWG/DXF 对象中提取的 JSON，保留文字、图层、块名、插入点和对象句柄等字段。
需要说明，本轮所谓“图片输入”并不是随手截取的 CAD 屏幕，而是由对应 A2 PDF 页面按 300 DPI 栅格化得到的 PNG。它比普通截图更清晰，因此仍然出现严重漏计，更能说明纯视觉遍历的局限。
测试模型采用本地宿主记录的配置名称：
• ChatGPT 5.6 sol (high) • Gemini 3.1 Pro (high)
每种输入都在独立上下文中运行，不允许读取另外两种格式，也不能查看答案键和其他模型结果。两款模型回答同样的五个问题：
• 图号和平面图名称是什么？ • 图中有哪些名称包含“实验室”的房间或区域？ • 一层、夹层各有多少个喷头？ • 两张图外围各有多少个轴网圆形标记？ • 仅凭当前材料，能否判断整张图完全符合消防规范？
统一任务模板、输入文件哈希、六份原始 Markdown 和自动比较报告均已留档，原始输出在评分前没有人工修订。两种本地宿主可调用的处理工具并不完全相同，因此本轮主要比较输入链路，不构成纯模型能力排名。
为了避免凭肉眼给模型打分，我们又从 CAD 源对象中生成了一份答案键。喷头通过指定图层和块名识别，轴网通过 _AXISO 块识别，文字保留原始位置和对象句柄。
这份答案键还没有经过消防专业人员独立复核，所以它只能用于核对文件事实，例如“有多少个指定块”“文字位于什么坐标”。它不是消防审图结论。
为防止答案键本身写错，我们又直接扫描 DXF 的 ENTITIES 段，并分别读取完整对象 JSON 和精简索引。三条读取路径都得到 87 个唯一喷头块，其中一层 35 个、夹层 52 个，没有重复句柄。
全景里，两张平面图并排出现；放大后，喷头只是连接在洋红色喷淋管线上的小圆形块。我们还在 AutoCAD 中选中其中一个对象，确认其位于 EQUIP_喷头 图层。下面保留全景、左右局部和对象属性，作为本轮视觉输入与 CAD 对象筛选的直接证据。
机械评分碰巧都是 5、7、9，但分数不是结论
现有自动评分结果如下：
这里的分数需要解释。
PNG 和 PDF 的导出范围没有包含标题栏图号。两款模型都没有根据文件名猜测“08”，自动评分却为此扣了一分。严格说，这一项应记为“输入中无证据”，不能当作模型识别失败。
图片里识别出的“化学实验室 E5-102”和“化学实验室 E5-104”也是真实文字，只是评分脚本没有自动归一化成“化学实验室”。所以，5、7、9 适合做本轮快速比较，不适合脱离任务细节单独传播。
比总分更值得看的是每种输入怎样出错。
完整图片：看懂了页面，却只数出 36 个喷头
两款模型都读出了“一层喷淋平面图”和“夹层喷淋平面图”，也都找到了“化学实验室 E5-102”“化学实验室 E5-104”和“手套箱实验室”。
轴网标记也数对了：一层 12 个，夹层 12 个，总数 24 个。
到了喷头计数，结果迅速失真：
两款模型都漏掉了 51 个喷头，漏计约 59%。
这并不奇怪。图纸缩放到模型可以处理的图像尺寸后，小型喷头符号与标注、线段、尺寸端点挤在一起。模型需要先从像素中判断“哪一组线代表一个喷头”，再遍历整张图，还要避免重计。
危险的地方不在于模型回答“看不清”。
两款模型都给出了精确总数，并把“已经完整遍历”标记为真。Gemini 对错误计数给出 0.95 的置信度；ChatGPT 的置信度是 0.66，并在自检中承认视觉计数可能受影响。
一张图里同时出现正确的房间名称、正确的轴网数量和错误的喷头数量，很容易让人对整份回答产生过高信任。工程图纸 AI 的风险，往往就藏在这种“多数内容看起来都对”的回答里。
补充测试：把整图切成高清局部，计数从 36 提高到 86
发布前，我们又追加了一轮不计入 5、7、9 自动评分的观察。
这次不再让模型同时读图名、房间、轴网和合规边界，而是把 AutoCAD 中的两块主要喷头区域分别截成高清局部图，只问一个问题：两张图分别有多少个喷头？
ChatGPT 无论逐张提问，还是两张局部图一起提问，结果都是 35 和 51。它只漏了一个喷头。Gemini 同时读取两张局部图时得到 31 和 46，也比完整页面上的 36 个总数明显改善。
我们还检查了“夹层截图是不是少截了一个”的可能。依据图中已知对象间距建立 CAD 坐标到截图像素的映射后，52 个喷头全部落在截图范围内，四周仍留有可见余量。因此，51 是视觉漏识别，不是截图裁掉了对象。
在被告知正确总数是 52 后，ChatGPT 能够回到图中定位遗漏：左上方小房间内，一根紫色横管上实际有 3 个喷头，第一次只计入了两端的两个。这个纠错过程说明局部图中的证据确实存在，但提示答案后的定位不能回算成首次计数正确。
Gemini 在得到 35 和 52 的正确答案后，也把结果改成了 87，但采用了另一种解释：它把原先数到的 31 和 46 称为“图面可见点位”，再根据夹层投影线和吊顶文字分别补入 4 个、6 个“隐藏上下喷”，刚好凑到正确总数。
这套解释不能采信。CAD 中的 87 个喷头块具有 87 个不同坐标，没有重合点位；本轮答案键统计的是实际块参照，也不是依据规范推算出的应设数量。Gemini 没有逐个指出 10 个漏掉的图面对象，而是在答案已知后构造了一套能够补齐差额的工程理由。相比普通漏计，这种“答案正确、证据却是倒推出来的”结果更需要警惕。
这轮补测同时缩小了图像范围，也把任务收窄为单一计数，所以不能把提升全部归因于分辨率。但它已经足以说明：图片输入并不是一个固定条件。对完整页面直接提问，和围绕任务切出高清局部图，可能得到完全不同的结果。
如果企业只有图片或 PDF，没有可解析的 CAD 源文件，更合理的计数流程应是：先定位目标区域，再按稳定比例切片，逐片识别，处理重叠区域的去重，最后汇总并回到原图复核。即便如此，86/87 也说明人工或程序校验仍不能省略。
PDF：文字回来了，计数没有回来
PDF 的表现比图片好，改善主要发生在文字提取。
两款模型都完整列出了四类名称：
• 化学实验室 • 实验室附属用房 • 手套箱实验室 • 物理化学实验室
这说明当前 PDF 保留了可利用的文本层。相比从像素中识字，直接读取文字对象更稳定，也更容易做去重和跨页遍历。
喷头数量仍然不可靠：
Gemini 的 50 个比 ChatGPT 的 24 个更接近答案键，但仍漏掉 37 个。一次结果也不足以证明它在 PDF 图纸计数上稳定优于另一款模型。
ChatGPT 这次不只读取 PDF 文本，还提取了矢量对象，并把页面重新渲染后交叉检查。结果依旧只有 24 个。
原因在于，PDF 中有矢量线条，不代表这些线条仍然是 CAD 里的“喷头对象”。一个块可能在发布过程中变成多条线、圆弧或字形；尺寸、引线和填充也会按 PDF 的表达方式重新组织。模型接触到的是发布页面里的绘图原语，不是 DWG 的块引用和对象层级。
PDF 很适合保存页序、版式和可审阅页面。它也可能保留文字。把它当成原始 CAD 数据模型的替代品，就会高估它能够提供的对象证据。
JSON：87 个喷头数准了，24 个轴网却分错了
换成结构化 JSON 后，图号、图名、实验室名称和喷头计数都变得准确。
两款模型都通过图层和块名找到：
• 一层喷头 35 个 • 夹层喷头 52 个 • 合计 87 个
这一步不再依赖视觉识别。只要解析过程没有漏项，模型可以遍历对象数组，按实体类型、图层和块名筛选，再回到插入点和原始句柄。
但结构化数据也出现了本轮最有价值的错误。
两款模型都找到 24 个 _AXISO 轴网块，却都回答“一层 16 个、夹层 8 个”。答案键是 12 个和 12 个。
我们重新检查了 24 个对象的插入点：
• 左图最右侧一组轴网，X 坐标约为 57521。 • 右图最左侧一组轴网，X 坐标约为 63385。 • 在两组坐标之间划分，可以得到 12 加 12。
答案键使用 x < 60000 归入一层，x >= 60000 归入夹层。Gemini 自行选用了约 68555 的分界，ChatGPT 使用 70000。两个阈值都把右图左侧的四个轴网划进了左图。
总数完全正确，归属仍然错误。
这说明结构化数据解决了“对象能不能被枚举”，没有自动解决“对象属于哪张图”。如果 JSON 只提供类型和坐标，却没有 plan_id、图幅边界或父子关系，模型仍要根据坐标分布猜测空间语义。
而且这种错误更容易被忽视。数字来自精确的对象遍历，解释也带着坐标和筛选条件，看起来比视觉回答更可靠。两款模型对错误的 16 加 8 都给出了很高置信度。
结构化数据不会消除推断。它只是把推断发生的位置，从“这几个像素是不是喷头”移动到“这个对象属于哪个区域”。
三种输入，其实对应三种证据
这次实测可以把三条链路的差异说得更具体。
因此，企业采购图纸 AI 时，只问“用了哪个大模型”是不够的。
同一基础模型接入不同图纸解析器、PDF 处理器和证据记录机制，工程表现可能完全不同。反过来，再强的模型只收到一张被压缩的整页图片，也会丢失小字、符号和准确定位所需的信息。
本轮两款模型的自动分数完全一致。Gemini 在 PDF 喷头计数上更接近答案，ChatGPT 在图片计数的自我校准上更克制。它们在 JSON 轴网分组中出现了相同错误。
一次样本不足以排模型名次，却足以说明输入链路需要单独验收。
面向生产的 JSON，至少要补上图幅归属
如果结构化数据准备进入真实工程流程，仅有“对象类型 + 坐标”还不够。
建议至少保留以下字段：
• 源文件标识、版本和哈希 • 转换工具、版本和参数 • 页码、布局名称或 plan_id• 每张图的边界框和坐标系 • 实体类型、图层、块名和属性 • 原始对象句柄 • 对象所属图幅、房间或系统 • 无法归属、转换失败和规则冲突状态
这样做的目的不是让 JSON 更复杂，而是减少模型自行猜分界线的机会。
如果系统回答“一层有 35 个喷头”，复核人员应该能够继续看到：这 35 个对象由什么规则筛选、属于哪个图幅、坐标在哪里、能否回到原始对象。模型如果无法确定归属，也应返回“待确认”，而不是为了凑出左右数量自行选择一个阈值。
这类字段可以看作图纸 AI 的证据合同。它约定的不只是传给模型什么数据，也约定每个结论怎样回到源图。
企业自己也可以做一次小范围验证
这次实验不需要先建设完整的图纸 AI 平台。一个小范围对照就能发现很多问题：
1. 选择一张范围明确、能够核对答案的真实图纸。 2. 从同一源文件生成图片、PDF 和结构化数据。 3. 固定五到十个实际任务，不随输入方式改变问题。 4. 每种输入单独运行，避免模型看到其他格式和答案。 5. 分别记录文字完整性、对象总数、空间归属、证据位置和置信度。 6. 不只比较总分，还要检查错误是否容易发现、能否回到原图。
标准答案也要分层。
块数量、文字和坐标可以从 CAD 对象中确定性提取；“是否满足消防规范”“某个空间关系是否合理”则需要完整图纸、适用规范、系统参数和专业人员复核。不要把文件事实答案键和工程审查结论混在一起。
本轮六次运行都拒绝仅凭当前输入判断整张图完全合规或不合规。这是正确表现。不过任务提示已经明确要求证据不足时保留边界，不能据此假设模型在所有使用场景中都会主动克制。
图纸 AI 的价值，不只在于回答得像不像
这次实验之后，我对“三种输入”有了更具体的判断。
图片让模型看到页面，但容易把小对象压进像素；PDF 让文字更容易读取，却没有恢复 CAD 的对象身份；JSON 让对象可以精确枚举，仍需要清楚说明它属于哪张图、哪个区域和哪个系统。
三种输入没有脱离任务的固定排名。
补充测试还说明，图片也不是一种固定输入。完整页面适合看布局和语境；面向单一任务的高清局部图，可能显著改善小对象识别。如果只有图片或 PDF，需要把分区切片、重叠去重和汇总复核做成系统能力，而不能依赖模型一次看完整张图。
如果任务是精确计数和定位，并且能够取得 CAD 源文件，结构化数据仍然更合适；如果结果要进入企业生产流程，页面语境、对象证据和人工复核缺一不可。
比“模型回答得多漂亮”更值得追问的是：
它依据什么得出结论？哪个环节可能丢了信息？结果错了以后，能不能回到原图找到原因？
这些问题答得清楚，图纸 AI 才开始从演示走向工程工具。
如果你的团队正在评估图纸 AI
如果你们正在选择截图、PDF 或结构化解析路线，可以通过文末入口或平台私信，简单说明图纸类型、希望 AI 完成的任务，以及目前能提供的源文件形式。我们会先判断这个场景是否适合做一次小范围输入链路验证。
关注我们
欢迎搜索并关注 筑见实验室，获取更多建筑 AI、工程软件与数字化工作流实践：
