为什么不做"更快画图"的提效小工具，而要做"会思考的出图工程师"？
背景：出图为什么是个问题？
在航空、汽车等制造行业，一张工程图纸从 3D 模型到可下厂加工的最终版本，通常需要经历 5-8 轮审核修改。问题不在于"画图慢"——CATIA 的制图功能已经足够高效。问题在于决策慢：
- 这个尺寸该标在哪里？标什么类型？
- 基准体系是否完整？公差等级是否合理？
- 技术要求是否遗漏了热处理/表面处理/无损检测？
- 明细表序号是否与图纸标注一致？
这些问题依赖的是经验、标准和判断力，而不是操作熟练度。
逆向切入：从"自动出图"到"出图审核"
市面上已有不少"自动标注"工具，但它们普遍面临一个困境：AI 的 95% 准确率在出图场景不是优势而是灾难——剩下的 5% 可能导致零件报废。
我们的策略是逆向切入：
传统思路（难）：3D模型 → AI生成图纸 → 交付
逆向思路（易）：历史图纸 → AI审核质量 → 输出报告逆向的优势：
- 技术风险低（只检查，不生成）
- 容易建立信任（"帮你检查" vs "替你画图"）
- 历史图纸就是天然训练数据
- 审核积累的规则可以直接驱动后续生成引擎
技术架构
核心决策：纯 C++ CAA
在 CATIA 插件开发中，CAA C++ 是唯一官方支持的插件框架。虽然 C# 开发效率更高，但跨语言的 COM Interop 在 CATIA 环境中极其脆弱——GUID 硬编码、接口签名版本依赖、多线程模型冲突。最终选择了纯 C++ 方案。
六大检查模块
图纸审核引擎
├── 尺寸可测性检查 → 标注的尺寸是否真的可以测量？
├── 基准体系完整性检查 → A-B-C 三基准是否完整？
├── 技术要求完整性检查 → 热处理/表面处理/无损检测是否遗漏？
├── 公差合规性检查 → 公差等级是否合理？精度-粗糙度是否匹配？
├── 明细表一致性检查 → 序号标注 vs 明细表 vs 3D装配体是否一致？
└── 审核报告生成器 → Excel + PDF + CATIA内嵌问题列表多 CAD 平台适配架构
虽然 Phase 0 只做 CATIA，但架构上预留了多平台扩展能力：
平台无关层（100% 可复用）
├── 5 个检查引擎 ← 只操作 DrawingData struct
├── 报告生成器 ← Excel COM + libharu PDF
└── AuditOrchestrator
▲ IDrawingParser 接口解耦
平台适配层（每平台 15-20 人日）
├── CATIADrawingParser ← Phase 0
├── NXDrawingParser ← Phase 3
└── SWDrawingParser ← Phase 3图纸解析：最核心的基础模块
一张 CATDrawing 文件包含以下需要遍历的元素：
- 视图：主视图、投影视图、剖视图、局部放大图、轴测图
- 尺寸标注：线性/直径/半径/角度/倒角，以及关联的 3D 几何引用
- 公差标注：形位公差框、基准符号、粗糙度符号
- 文本注释：技术要求文本
- 表格：明细表（BOM）、标题栏
- 序号标注：Balloon 及其关联的 3D 组件
解析的核心挑战在于3D 几何关联——每个标注是否真正引用了 3D 模型上的有效几何面，这是判断"可测性"的基础。
规则引擎：JSON 驱动的知识管理
不做 AI 推理，用规则匹配。企业出图标准以 JSON 配置文件形式管理：
{
"id": "TR-010",
"category": "热处理",
"condition": "material IN ['30CrMnSiA','40Cr'] AND part_type != '焊接件'",
"required_pattern": "(调质|淬火|正火|退火|热处理)",
"severity": "error",
"suggestion": "钢制零件需标注热处理要求，常见：调质处理 HB220-250"
}优势：修改规则不需要重新编译 C++ 插件，支持企业级定制。
后续计划
- Phase 0（3个月）：CATIA 审核工具，纯 C++ CAA
- Phase 1（4个月）：半自动出图，AI 出初稿 + 人工确认
- Phase 2（6个月）：智能增强，技术要求自动生成 + 公差推理
- Phase 3（8个月）：多 CAD 平台 + Web 管理端 + PLM 对接
*下一篇预告：CATDrawing 图纸解析的完整 API 遍历——从 Document 到 Balloon 的全链路。*