舞台工艺审图 AI 实践：把 200dpi 渲染默认值改成 300dpi，一天少写 9 条假意见
一、背景
前段时间接手了一个城市交响音乐厅的舞台机械、灯光、音响三专业系统性重审项目。甲方把整套竣工图甩过来，一共 218 页，要求我们按 C5 级别的精度做全量栅格目验。所谓 C5，就是行业内对图纸审读颗粒度最细的一档，相当于把每一页当论文插图看，表头、编号、小数点都要过一遍。这个项目拖了很久，竣工图上满是各个专业后来补的修改标记，图面状态比常规新建项目复杂得多，甲方专门点了名要"三专业交叉复核"，意思是不能各专业只看自己的图，要把机械、灯光、音响在同一空间里的衔接关系也查一遍。
我们这边用了 AI 智能体来辅助审图，思路是把 DWG 图纸渲染成栅格图，然后让模型逐页给出候选意见。这条链路在团队内部跑了快两年，从最早的纯人工目检，到后来加了 OCR 做文本抽取，再到现在的多模态模型直接读图，中间换过好几轮方案。这次项目本来应该是一个很常规的执行案例，问题出在渲染参数这个最容易被忽略的环节上。
第一遍跑的时候，为了赶进度，渲染参数沿用了团队历史项目里的默认配置——200dpi。200dpi 出图快，218 页大概十几分钟就跑完了，模型一口气给出 23 条候选意见，看起来成果丰硕。当时组里还挺高兴，觉得这遍效率不错，甚至有同事说"看来模型越来越靠谱了"。但这句话在两个小时后就被推翻了。
复核环节由我和另一个同事分头做，C5 级别是 100% 全检，23 条意见一条都不能跳过。验到第 4 条的时候就发现不对劲——那条意见说"编号 J28171 与设备台账不符"，我翻到原 DWG 一看，图纸上写的是 J23171，数字 3 被渲染成了 8。接着往下验，第 7 条说"灯光回路 ED2120K 编码规则违反"，原图纸上明明是 ED1202K，字母 E 和数字 1 的顺序被看反了。验到第 9 条，意见说"引用了已作废的 GB/T 5972 规范"，我把整张表翻了一遍，根本没有这一行，是模型把表头里的规范引用说明当成了正文数据行。
越验越心凉。到验完所有 23 条的时候，统计结果出来了：9 条假阳性，占候选意见的 39%。这个数字是当日实测相对权重——它反映的是这次审图任务里假阳性意见占候选意见总量的相对比例，不是绝对的工时占比。换个项目、换个模型、换个图纸复杂度，这个比例肯定会变，但"渲染分辨率导致判读质量塌陷"这件事在我们团队后续几个项目里是稳定复现的。
9 条假阳性长什么样？举几个典型的教学样本：
- J28171 实为 J23171。图纸上的编号是 J23171，模型在 200dpi 渲染图里把"3"看成了"8"。原因很简单，200dpi 下数字 3 的笔画宽度只有 3 个像素左右，抗锯齿处理之后中间那道弧线被填实了，视觉上就是一个 8。模型不是在"猜"，它是"确实看到了一个 8"，所以 confidence 给得很高。
- ED2120K 实为 ED1202K。灯光回路编号里字母 E、D 和数字 1、2、0 的顺序被看反了。200dpi 下这种字母数字混排的小字，字间距被压缩到 5 个像素以内，模型分不清"ED"和"DE"、"21"和"12"的边界。
- GB/T 5972 行不存在。模型把表头区域里一段规范引用说明当成了正文数据行，凭空捏造了一条"引用了作废规范"。这种错误在 200dpi 下特别常见，因为表头和正文在视觉上的区分依赖字体粗细和留白，分辨率不够时这两者的区别被抹平了。
- E.05/E.11 合法分项被误判重复。舞台机械表里两个合法分项，因为渲染图上字号小、行距挤，模型当成重复行报了出来。
- B.04 表头误读。表头区域被当成数据区，报了一条完全不存在的矛盾项。
这 9 条假意见如果直接发出去，每一条都足以让施工方返工核对，或者让甲方对我们的审图质量打问号。施工方收到 J28171 那条会翻遍整个项目档案去找这个编号，找不到就开始怀疑我们审图团队的专业水平。而更讽刺的是，200dpi 快扫省下的时间，远远小于后面证伪复核加意见重生成的代价。等于是为了省 10 分钟，多花了 40 分钟去擦屁股。
这就是本文要讲的核心结论：在 AI 辅助审图这条链路上，渲染分辨率默认值是性价比最高的调优旋钮。把 200dpi 改成 300dpi，假阳性率显著下降，立意见阈值也可以跟着拉高，整体提速反而更明显。 这个结论不是理论推演，是用 218 页真实图纸和 23 条候选意见换来的。
二、环境准备
先交代一下我们这边的审图环境，方便同行对照自己的项目。
硬件与部署：审图任务跑在一台 48G 显存的工作站上，AI 智能体用的是本地部署的 7B 级多模态模型，外加一个负责调度渲染和页管理的服务进程。多模态模型直接读栅格图，不需要 OCR 中间件，这是本方案的关键前提——如果走 OCR 路线，分辨率问题会被 OCR 引擎自己消化一部分，但本文的结论针对的是"模型直接读图"这条路。选本地部署而不是云端 API，主要是甲方对图纸数据出境有要求，这个限制在行业里很普遍，不是个例。
图纸格式：甲方交付的是 DWG，我们用 LibreDWG 工具链做格式转换。转换这一步本身会引入不确定性——同一个 DWG 文件在不同版本的转换工具下，渲染出来的栅格图会有细微差异。所以我们固定了转换版本号，保证可复现。曾经吃过亏，有一次换了个转换版本，同一份图纸渲染出来差了两页，后来回溯问题花了半天，从此就把版本号钉死了。
渲染管线：渲染用的是我们自研的一个栅格化脚本，核心参数是 dpi 和分页策略。200dpi 的默认值是团队两年前定的，当时觉得"反正模型只是做粗筛，200dpi 够看了"。这个判断在当时的模型能力下也许说得通，但现在的多模态模型对细节的关注度远高于两年前，模型能力上来了，渲染配置却没跟上，错配就出现了。这次项目证明这个判断彻底错了。
意见生成与复核：模型给出候选意见后，会生成一个结构化的 JSON 意见集，每条意见带页码、坐标框和判定理由。复核环节由人工抽检，抽检比例按风险分级，C5 级别是 100% 全检，B 级别是 30%，C 级别只做重点页抽检。这次项目的 23 条意见全部走 C5 全检流程，所以才能把 9 条假阳性一条不漏地揪出来。
这里插一句行业背景：舞台工艺图纸的审读有个特殊难点，就是多专业交叉。机械专业画的吊杆系统图，和灯光专业画的调光柜系统图，在 DMX512 回路编号上是同一套编码规则，但画在不同图页、由不同人绘制，图面风格差异很大。有人画图喜欢用细线，有人喜欢用粗线，有人把编号写得很大，有人写得很小。200dpi 渲染下，这种风格差异被放大成"疑似不一致"，是假阳性的一个重要来源。举个具体例子，吊杆系统图里编号 J23171 是用 3.5 号字写的，到了灯光系统图里对应的 DMX512 回路编号 ED1202K 用的是 2.5 号字，两种字号在 200dpi 下的清晰度差了一大截，模型对不同页的判读标准就会飘。
另外一个容易被忽略的环境因素是图纸的原始质量。竣工图不像新蓝图，上面经常有手工补的修改标记、红圈蓝圈、胶带贴的补丁。这些非数字内容在栅格化之后会变成噪声，200dpi 时噪声和有效信息的对比度更低，模型更容易把噪声当信息。300dpi 下这个问题会缓解，但不会完全消失——后面踩坑部分会详细说。
三、步骤
整个修正过程拆成四步，每一步都是可复现的命令行操作。
第一步：回溯第一遍的渲染配置，锁定问题参数。
先看历史配置里渲染命令长什么样：
# 第一遍渲染（200dpi 默认值）
python render_dwg.py –input concert_hall_c5.dwg –dpi 200 –out ./render_200
200dpi 意味着每英寸 200 个像素点。A1 图纸（594×841mm）渲染出来大约是 4677×6600 像素，单页文件 2-3MB。这个分辨率对肉眼远看是够的，在屏幕上缩放浏览完全没问题。但模型要读的是 ED2120K 这种字母数字混排的小字，笔画宽度在 200dpi 下只有 3-4 个像素，稍微沾点抗锯齿就糊成一团。当时定 200dpi 的时候考虑的是文件大小和渲染速度，没考虑模型读小字的需求。这是个典型的"用人眼需求替代了机器读图需求"的错误。
第二步：整段重渲，300dpi 一次到位。
# 第二遍渲染（300dpi）
python render_dwg.py –input concert_hall_c5.dwg –dpi 300 –out ./render_300
300dpi 下同一张 A1 图渲染出来约 7016×9933 像素，单页 8-12MB。渲染时间从 15 分钟涨到 35 分钟左右，多花 20 分钟。这里要强调的是"一次到位"——不要分段改，不要先改一半看看效果，要么全部 300dpi，要么全部维持原样。混着来是最贵的，踩坑部分会展开说。
第三步：意见集整段重生成。
不是挑那 9 条重新看，而是全部 218 页重新过一遍。理由是：分辨率变了，模型对每一页的判读依据都变了，局部修改意见集没有意义，必须整段重跑。这个道理其实很朴素——你换了一副更清晰的眼镜，需要把所有东西重新看一遍，而不是只重看之前看错的那几件。
python run_review.py –render-dir ./render_300 –model-path ./local-vlm-7b –out ./review_300
这一步跑完，候选意见从 23 条降到 19 条。
第四步：人工抽检验证。
对 19 条意见逐条核对原 DWG，确认剩余 19 条全部成立，假阳性清零。同时回头验证那 9 条被消掉的假意见，确认它们在新渲染下确实不再被误判，而不是被模型"跳过了"。这个回头验证很重要——如果模型不是看对了而是根本没看那一页，那问题就换了一种形态，需要从另一个角度排查。这次项目里确认了 9 条假阳性是被正确消掉的，不是漏判。
四个步骤里，前两步是渲染侧改动，第三步是模型侧改动，第四步是验证侧改动。整套流程里没有任何代码逻辑变化，唯一变量就是 dpi。这就是我说"改渲染默认值比任何优化都值钱"的原因——不需要改模型、不需要改提示词、不需要改审核规则，一个参数就解决了问题。 对比一下其他优化手段：改提示词要反复调、改审核规则要重新设计判定逻辑、换模型要重新训练或微调，每一项的成本都是渲染参数调整的几十倍。
四、代码与命令
下面把完整渲染管线和意见生成流程贴出来，方便同行直接复用。
渲染脚本核心逻辑：
"""render_dwg.py —— 舞台工艺图纸栅格化渲染脚本"""
import os
import subprocess
def render_page(dwg_path: str, out_dir: str, dpi: int = 300) –> str:
"""把 DWG 渲染为 PNG 栅格图，返回输出目录路径。
dpi 是本文的核心参数。低于 250 时，图纸上编号类小字
会出现笔画粘连，直接拉高模型判读的假阳性率。
团队规范要求生产环境固定 300dpi，禁止默认 200。
"""
os.makedirs(out_dir, exist_ok=True)
cmd = [
"libredwg-convert",
"-d", str(dpi), # 渲染分辨率
"-f", "png",
"-o", out_dir,
dwg_path,
]
subprocess.run(cmd, check=True)
return out_dir
if __name__ == "__main__":
# 生产环境固定 300dpi，禁止默认 200
render_page("concert_hall_c5.dwg", "./render_300", dpi=300)
意见生成脚本核心逻辑：
"""run_review.py —— 调用 AI 智能体逐页生成候选意见"""
from pathlib import Path
def review_renders(render_dir: str, model_path: str) –> list[dict]:
"""遍历栅格图，让模型给出结构化候选意见。
返回结构：[{page, bbox, claim, reason, confidence}, …]
"""
pages = sorted(Path(render_dir).glob("*.png"))
opinions = []
for page in pages:
# 模型直接读图，不做 OCR 中转
result = call_vlm(model_path, str(page))
opinions.extend(result["opinions"])
return opinions
def call_vlm(model_path: str, image_path: str) –> dict:
"""调用多模态模型。此处省略具体推理框架代码。"""
...
意见集重生成后的对比：
# 第一遍意见集（200dpi）
$ jq 'length' review_200.json
23
# 第二遍意见集（300dpi）
$ jq 'length' review_300.json
19
# 差值即被分辨率修正消掉的假阳性候选
$ echo $(jq 'length' review_200.json) – $(jq 'length' review_300.json) | bc
4
注意，上面这个差值 4 只是"候选意见条数"的差值，不是假阳性条数的精确差值。23 条里有 9 条假阳性，300dpi 下这 9 条里有 5 条被消除，另外还有 4 条真阳性在新渲染下也被判对了（原本就被判对了，没变），同时有 0 条新假阳性出现。候选条数 23→19 的净变化，是假阳性消除和新判读调整共同作用的结果。这里贴出来是为了让同行理解"重生成"不是简单的删除，而是模型重新判读一遍。
复核环节的命令行操作：
# 导出候选意见供人工复核
python export_reviews.py –input review_300.json –format markdown –out ./review_300.md
# 人工复核结果回填
python feedback_review.py –review-file ./review_300.md –out review_300_confirmed.json
复核环节用的是 Markdown 格式导出，每条意见一页，带原图截图和判定理由。人工复核时直接在 Markdown 里标注"确认/驳回/待核实"，然后脚本回填成结构化 JSON。这套流程在团队内部跑了一年多，C5 级别项目的人工复核效率从最初的每人每小时 5 页提升到现在的每人每小时 12 页，300dpi 渲染功不可没。
五、踩坑
这次修正过程中踩了三个坑，都是同行容易犯的。
坑一：以为局部重渲能省时间，结果更慢。
第一遍发现 9 条假阳性后，我第一反应是只把那 9 条对应的页重渲一遍。算了一下，9 条意见分布在 7 页上，重渲 7 页应该比全量 218 页快很多。实操下来发现不行。原因有两点：
结论：要么全量统一分辨率，要么别改。混着来是最贵的。
坑二：以为提立意见阈值能压假阳性，其实治标不治本。
第一遍的 23 条意见里，假阳性的 confidence 分数分布和真阳性是重叠的。我专门做了个统计：
- 真阳性的 confidence 分布：0.72 到 0.91
- 假阳性的 confidence 分布：0.75 到 0.88
两条分布曲线基本重叠，也就是说，你没法靠一个阈值把假阳性筛掉。强行把阈值从 0.7 拉到 0.9，假阳性压下去一点（从 9 条降到 6 条），真阳性也跟着掉（从 14 条降到 11 条）——J28171 那种笔画粘连的情况，模型给的 confidence 本来就高，因为它"确实看到了一个 8"，给它 0.85 的分数一点不冤枉。从模型的视角看，它在那张糊图上看到的信息和一个真人看到的差不多，结论当然自信。
分辨率改到 300dpi 之后，模型看到的就是"3"，confidence 和理由都对了，阈值自然可以放回 0.7，真阳性一条不丢。这才是正确的顺序：先修输入质量，再调判定阈值。如果反过来先调阈值，模型看到的还是糊图，它只会更保守地报"不确定"，但不确定不等于正确，只是把假阳性从"自信地错"变成了"犹豫地错"。
坑三：低估了渲染时间对项目排期的挤占。
300dpi 渲染 218 页要 35 分钟，200dpi 只要 15 分钟。项目排期上，渲染是串行环节，多 20 分钟会让整个审图流程晚 20 分钟结束。排期部门一看渲染时间涨了 133%，第一反应就是"能不能降回去"。
但算总账的话：
- 200dpi 路径：渲染 15 分钟 + 复核 40 分钟（9 条假阳性逐条证伪，每条平均 4 分钟翻原图核对）+ 重生成 10 分钟 ≈ 65 分钟
- 300dpi 路径：渲染 35 分钟 + 复核 15 分钟（19 条真阳性快速过，每条平均不到 1 分钟）≈ 50 分钟
300dpi 反而快 15 分钟。这个账要提前跟项目组说清楚，否则排期部门会在渲染环节给你砍时间，逼你退回 200dpi，然后假阳性再来一轮，进入恶性循环。我们后来在团队内部定了个规矩：渲染时间单列，不计入"人工复核时间"指标，避免排期时被错误压缩。
坑四（补充）：竣工图上的手工标记是另一个噪声源。
这个坑是这次项目特有的，但也值得提一下。竣工图上经常有施工方后来补的红笔圈注、胶带贴的修改单、铅笔写的备注。这些东西在 200dpi 下和正文信息混在一起，模型分不清哪个是原始图面、哪个是后来加的标记。300dpi 能缓解一部分，但如果手工标记特别多，光靠分辨率还是不够。我们的应对是预处理阶段手动清理明显的手工标记，但这一步很耗时，218 页清理花了差不多半天。更好的方案是让甲方提供"纯电子版"竣工图，但这个要求在合同阶段就得提出来，项目中途再要就晚了。
六、总结
回到最初的那个数字：200dpi 渲染下，AI 智能体给出的 23 条候选意见里有 9 条假阳性，当日实测相对权重 39%。改成 300dpi 后，候选意见降到 19 条，假阳性清零，复核时间省了将近一半。这不是一次偶然的参数调整，而是我们团队在多个项目里稳定复现的结论——分辨率不够，模型看到的就是一张糊图，再强的判读逻辑也无米下锅。
这件事的核心教训不是"我们的模型不行"，而是审图链路的输入质量决定了输出质量的上限。分辨率这个参数，在多模态审图方案里是最底层的输入，它直接影响模型"看到什么"。看到的东西糊，后面判读逻辑再精细也救不回来。这就像让一个人戴着毛玻璃眼镜去审合同——你再专业，也看不清条款里的数字。
落地建议四条：
最后强调一下边界：本文讲的是人眼判读侧的假阳性，也就是模型读渲染图时因为像素不够而产生的误判。这和"机器闸门也会假报警"那类问题不一样——后者是闸门侧的代码路径逻辑问题，前者是渲染参数和立意见阈值的量化决策问题。两类假阳性要分开治，不要混在一个"降误报"的口号里，否则很容易改错地方。一个是输入质量问题，一个是逻辑判定问题，解决路径完全不同。
审图这件事，说到底是在和"看不见的误差"打交道。一个 dpi 参数，9 条假意见，20 分钟渲染时间——这笔账算清楚了，比任何模型调优都值钱。
