一、我是谁，我卡在哪
个人背景
我在制造业做工程/质量管理，日常工作离不开两件事：
- 读2D工程图——拿到供应商或研发出的PDF图纸，需要把图号、版本、Notes、材料要求、全部尺寸公差、GD&T、基准特征等逐条录入系统，用于首件检验（FAI）、SPC和量检具规划。
- 处理量测数据——从QMS/MES系统导出Excel量测数据，按公差计算CPK/PPK，生成正态分布图和PPT报告，用于品质评审。
这两件事高度依赖人工，一张中等复杂度的图纸就够磨一下午。
当前痛点
以2D工程图解析为例——这是我耗时最多、也最容易出错的环节：
拿到PDF图纸 → 肉眼逐区识图 → 手工抄录尺寸/公差/Notes → 填入Excel → 反复核对
一张 Cam 盖板零件图，包含 50+ 个尺寸标注、10条 Notes、17项材料/表面/外观要求、5条GD&T。手工处理：
- 全量抄录 + 交叉核对至少 3-4 小时
- 小字尺寸链容易看漏或看错（如 Ø1.6 vs Ø16，差一个数量级）
- Notes里的中英文混合内容（材料标准、盐雾测试、外观检验表）拆分困难
- GD&T符号、基准引用关系需要反复对照才能理清
- 没有证据留痕——录完后无法回溯"这个0.05公差从图纸哪个位置读到的"
更头疼的是：公司图纸很多，每张都要这么来一遍，而且不允许遗漏——FAI少录一个尺寸就是审核事故。
二、我用 TraeWork 怎么解决的
模式：
Work Code
我用 TraeWork 写了一个名为 2d-drawing-structured-extractor 的 Skill，把整个工程图解析流程固化成了可重复执行的SOP：
文件检查 → 文本层+页面渲染 → 逐区审图 → 结构化提取 → 规则校验 → 不确定项分流 → JSON+Excel+证据截图
第一步：文件检查与审图材料准备
上传PDF后，Skill 自动运行 file_inspector.py 检查文件完整性、页数、SHA256、原生文字块数量等，然后调用 pdf_renderer.py 以240 DPI渲染整页图 + 3×3重叠分区图，同时用 extract_text.py 提取原生文本层。
这一步的关键是双通道原则：文本层提高数值精度，图像层确认真实可见字形和工程符号。两者冲突时不自动选"更合理"的值，而是同时保留并标记为 conflicting。
第二步：逐区审图与结构化提取
这是最核心的环节。Skill 按固定顺序逐区提取，不允许跳跃：
图框元数据 → 修订记录 → 全部Notes → 材料/表面/环境 → 尺寸与公差 → GD&T → 基准/特征/标识 → 不确定项
每个尺寸都建立独立记录——不是一串OCR文本，而是拆成ID、视图、特征、公称值、公差类型、上下偏差、数量修饰符、是否基本尺寸等20+字段。对无法可靠识别的内容（如ISO TOL符号分辨率不足），自动进入 uncertainties 数组并要求人工复核。
第三步：规则校验与交付文件生成
提取完成后，rule_validator.py 自动校验：ID不重复、页码合法、bbox坐标顺序正确、confidence在0-1范围、公差值符号方向合理、基本尺寸不套用默认公差等。然后 output_adapter.py 一键生成全套交付物。
三、提效前后对比
| 环节 | 以前（纯手工） | 现在（TraeWork + Skill） | 提效 |
|---|---|---|---|
| 文件检查与初步浏览 | 10分钟 | 1分钟 | 10× |
| 尺寸/公差逐条抄录 | 1.5-2小时 | 5分钟 | 20× |
| Notes/材料/表面要求拆分 | 30-45分钟 | 3分钟 | 15× |
| GD&T/基准/特征整理 | 20-30分钟 | 2分钟 | 15× |
| 交叉核对与复查 | 30-60分钟 | 2分钟（规则校验自动跑） | 20× |
| 证据留痕 | 不做（或手动截图标注） | 0分钟（自动裁切112张证据图） | 从无到有 |
| 总计 | 3-4小时/张 | 15-20分钟/张 | 10-15× |
最关键的不是速度——是零遗漏和全链路可追溯。每个提取项都有bbox坐标和证据截图，审查时可以一键定位到图纸上的原始位置。
四、成果展示
以一张 Cam-Top-Cover 盖板零件图为例，最终交付了完整的"四件套 + 校验报告"：
| 指标 | 数值 |
|---|---|
| 结构化记录总数 | 119 |
| 尺寸记录 | 50 |
| Notes条目 | 10 |
| 证据截图 | 112 |
| 校验错误 | 0 |
| 不确定项（已分流） | 10 |
产物1：drawing_extract.json — 结构化JSON
遵循Schema 2.0.0，包含8个顶层数组：drawing_metadata（21条）、revision_history（1条）、general_notes（10条）、material_surface_environment（17条）、dimensions_gdt_fai（55条）、datums_features_markings（5条）、uncertainties（10条）。每条记录携带页码、区域、bbox坐标、置信度、提取方法和证据ID。
产物2：drawing_extract_review.xlsx — 工程师复核Excel
按分类分Sheet的结构化表格，工程师可以直接在Excel中逐条复核，标记确认或修改，用于FAI审核归档。
产物3：evidence/ — 112张证据截图
每个提取项对应一张从原始PDF精确裁切的证据图（300 DPI），附带evidence_manifest.json索引。审查时打开任意一条记录，即可定位到图纸上的原始位置，实现"说走就走"的可追溯。
产物4：validation_report.json + processing_manifest.json
校验报告：0错误、5警告（均为ISO TOL符号不可识别，已如实保留并分流）。处理清单：记录Skill版本、处理时间、各数组计数、质量门控结果（human_review）。
另外，我还写了一个配套的 excel-flow-matching Skill——处理QMS/MES量测数据，自动匹配流程生成正态分布图和CPK报告。两个Skill配合使用，从"读图纸"到"出品质报告"的完整链路就打通了。
五、实践经验总结
坑1：不同模型能力差异巨大，Skill要为"弱模型"做加固
我在国内顶级模型上测试效果很好，但同事本地部署的是20B级别的模型，识别能力有明显差距。解决方案：把决策逻辑从提示词搬到代码里——比如尺寸公差优先级判断、公差类型推断、坐标校验等，全部用Python脚本确定性执行，模型只负责"看图识别"，不做复杂推理。这样即使弱模型识别能力差一些，脚本兜底也能保证输出质量。
坑2：图像旋转方向搞反，差点全盘错位
图纸是横向的，PDF是竖向A4，需要旋转-90°才能正确阅读。第一次写脚本时转成了+90°，结果整个图纸上下颠倒，所有区域裁切坐标全错。教训：图像变换必须先验证一张——先旋转一张全页图，肉眼确认方向正确后再批量处理。
坑3：不确定项不要硬猜，分流才是正解
图纸上有些内容确实看不清——比如标题栏ISO TOL区的GD&T符号，分辨率不足，硬猜只会引入错误。我在Skill里专门设计了 uncertainties 数组，所有无法可靠识别的内容自动进入这里，标记 review_required=true，并写入不确定的原因和处理建议。校验器还会检查"有人工复核标记但uncertainties为空"的情况，确保不遗漏。这个设计让输出诚实而非假装完美。