答辩备战材料

一、题目在算什么(业务背景)

1.1 一句话定义

1.2 PCB 是什么 / 走线 / 网络

PCB(印制电路板):电子产品里那块布满铜线的板子,连接芯片、电阻、电容等元件。

走线(Line):TOP 层上的铜线。每根走线有起点、终点、线宽、线头类型(圆头/方头)。

网络(Net):电气上连通的所有点的集合。同一网络靠在一起是正常的(本来就连通);不同网络之间必须绝缘,否则短路。

1.3 违规判定规则(任务书第 5 页第 6 条)

注意:只有不同网络的走线才检测。同一网络的走线靠在一起不算违规。

1.4 为什么要"外扩 0.1mm"

设计思路:任务二的工程化设计原则

四条设计原则

整体设计遵循分层组织、预处理先行、粗筛—精算分离、结果去重可审计四条原则:

• 分层组织:interface 只负责窗口交互、表格填充和错误提示;非界面功能全部放在 logic 类,包括上下文获取、线段读取、外扩分组、候选筛选、结果收集和跳转数据;几何运算、图形创建、数据读取等底层能力复用 vSDK,不自行重写几何引擎。
• 预处理先行:按任务书在精算之前完成每条线的外轮廓外扩 0.1mm,保证后续判定严格针对"外扩后图形",而不是直接在原始图形上替换判定条件。
• 粗筛—精算分离:AABB 只做 4 次坐标比较,用于把跨网络线段对压缩到候选网络对;真正的几何运算交给 vSDK,避免在工业级几何内核之外做不严谨的近似计算。
• 结果去重可审计:PairKey 用较小 ObjectID 在高位、较大 ObjectID 在低位组成 64 位无序键,消除正反顺序重复,保证 GetTouch 与 GetDistance 两类结果合并后不重复计数;关键步骤输出 audit 日志。

六步主线流水线

设计动机

为什么外扩在前?任务书明确要求"先外扩再算",这是数据预处理步骤而不是自行替换判定条件。因此不能简化为"原图形距离小于 0.1mm 等价于外扩后相交"。

为什么要粗筛—精算分离?5331 条线产生 13,966,489 对跨网络线段组合,若不筛选则 492 个网络容器两两组合为 120,786 对、241,572 次精确调用。AABB 把它压缩为 1975 个候选网络对、3950 次精确调用,减少 237,622 次。

为什么用 PairKey?无序对键同时解决两个问题:同一对图形无论 SDK 以哪个方向返回都得到同一个键;GetTouch 与 GetDistance 两类结果合并时不会重复计数。

性能与正确性

工程完整性

一句话总结

二、数据怎么导入

2.1 DEMO2.tgz 是什么

是 ODB++ 格式的 PCB 制造数据包——PCB 行业最通用的数据交换格式之一。 内部是层级目录结构:job → steps/pcb → layers/top(我们要的TOP层)。

2.2 DFX MetaLab 读入 + vSDK 访问的三级指针

用户拖入 DEMO2.tgz 后,软件解析构建内存对象模型。我的代码通过 vSDK 逐级获取上下文:

2.3 TOP 层校验

不仅按名称找,还校验两个属性确保是正面信号层(任务书第 3 条):

三、算法全流程(核心,答辩重头戏)

3.1 整体流程图(背熟这条)

3.2 步骤详解

步骤 1:遍历 TOP 层,筛出所有线段

for (objectIndex = 0; objectIndex < 总数; objectIndex++) {
    GetLayerObjectType(..., objectIndex) → 用0基索引判断类型
    if (类型 == 5 /*Line*/) {
        GetLayerObjectInfosEx(...) → 读起点/终点/符号尺寸/线头名称
        GetLayerObjectNetID(..., objectIndex+1) → 用1基ObjectID读NetID
        存入 LineRecord 容器
    }
}

结果:5331 条线段进入内存。

步骤 2:每条线段外扩 0.1mm

expandedWidth = lineWidth + 0.2;
expandedLength = isRectangle ? capLength + 0.2 : expandedWidth;
CreateShapeByLine(原起点, 原终点, expandedLength, expandedWidth, isRectangle, ...)

步骤 3:按网络分组进 ShapeConter 容器

ShapeConter 是 vSDK 提供的几何容器,专门用来批量计算。按 NetID 分组:

NetID=1 的所有线段 → ShapeConter_1
NetID=2 的所有线段 → ShapeConter_2
...
共 492 个容器

步骤 4:AABB 粗筛(性能关键)

问题:5331 条线中共有 13,966,489 对跨网络线段组合。若不做空间筛选,492 个网络容器两两组合为 C(492,2)=120,786 对,而相交与距离各调用一次,最多需要 241,572 次精确 SDK 调用。

解决:先对 13,966,489 对跨网络线段做轻量 AABB(Axis-Aligned Bounding Box,轴对齐包围盒)比较。判断两个包围盒是否分离只需要 4 项边界比较;只要某条线段对的扩展包围盒可能接近,才把对应网络对加入候选集合:

if (A.maxX < B.minX || B.maxX < A.minX ||
    A.maxY < B.minY || B.maxY < A.minY) {
    // 不可能相交,跳过
}

效果:最终得到 1975 个候选网络对,执行 1975×2=3950 次精确 SDK 调用;相比无筛选的 241,572 次,减少 237,622 次,约减少 98.36%。13,966,489 是轻量线段对比较次数,不是 GetDistance 调用次数。

步骤 5:精算(GetTouch + GetDistance)

// 5a. GetTouch:显式取得外扩后相交的图形对
// 5b. GetDistance(0.0, 0.1):取得外扩后最小距离位于 [0.0,0.1) 的图形对
// 5c. 将两类结果按无序 ObjectID 对去重合并

步骤 6:去重 + 输出

用 PairKey = (较小id << 32) | 较大id 组成 64 位无序对键,存入 QHash 去重。 最终输出 5400 对唯一违规,其中外扩后相交 3873 对,不相交但外扩后最小距离小于 0.1mm 的 1527 对。

四、函数是自己写的还是调 SDK 的(必问)

4.1 提交代码中实现的工程逻辑(答辩要讲清)

4.2 关键工程设计(应能现场解释)

4.3 调 vSDK 库的(诚实承认)

SDK 一共调了 27 个不同的接口,分四类:

4.4 从DFX菜单到检测结果的完整调用链

4.5 核心数据结构与复杂度

复杂度口径:当前粗筛仍遍历跨网络线段对,理论时间复杂度为 O(L²),本数据集实际完成13,966,489次轻量AABB比较; 精算只处理1975个候选网络对。空间主要用于线段记录、492个网络容器、候选网络对和5400个结果对。若数据规模继续增长,可使用均匀网格、R树或扫描线替代全线段两两粗筛。

4.6 异常处理、资源生命周期与界面线程

五、audit 日志与 0基/1基(关键故事)

5.1 audit 日志是什么

audit = "体检报告"。一次检测跑完后,把所有关键数字记录下来,打印到 Qt Creator 的"应用程序输出"面板。

struct DetectionAudit {
    int lineCount;              // 线段总数
    int networkCount;           // 网络总数
    qint64 crossNetworkPairCount; // 跨网络对数
    int touchPairCount;         // 相交命中数
    int distancePairCount;      // 距离命中数
    int uniqueViolationCount;   // 最终违规数
};

实际输出:Distance detection audit: lines=5331 nets=492 crossNetPairs=13966489 touchHits=3873 distanceHits=5400 uniqueViolations=5400

5.2 0基 / 1基是什么

5.3 vSDK 的坑:两套体系混用

5.4 我踩的坑(错误代码)

line.objectId = objectIndex;  // ❌ 错!存成了 0基
GetLayerObjectNetID(board, layer, line.objectId, line.netId);  // ❌ 错!要 1基

结果:每条线查到的是"前一个对象"的网络,所有网络归属全错位。 本该同网络的线被分到不同网络 → 产生虚假的"跨网络违规"。 网络数虚增:本该 492,变成 515。

5.5 怎么发现的——audit 立功

5.6 正确的修复

line.objectId = objectIndex + 1;  // ✅ 改成 1基!
GetLayerObjectNetID(board, layer, line.objectId, line.netId);  // ✅

这个 1基的 objectId 贯穿全程:查 NetID、AddShape 编号、表格显示、GotoResult 比较,都用它,保证一致。

六、正确性如何验证(含 ODB++ 独立解析)

6.1 原始几何数据复核:TOP 线段数为 5331

将 DEMO2.tgz 解压后直接解析 ODB++ 的 TOP/features 文件,不经过插件的对象读取流程,重新统计原始图形记录:

6.2 网络数 492 vs 527(口径不同,都合理)

527 是 ODB++ 全局 netlist 中定义的网络编号数;492 是对 vSDK 返回的 5331 条 TOP 线段 NetID 去重后的数量。两者统计对象不同,因此不能用 527−492=35 直接断言这些网络只存在于哪一层。后续算法应使用与 TOP 线段一一对应的 492 个有效 NetID 分组。

6.3 5400 组结果的逐对复核

6.4 答辩时的验证顺序

先展示插件 audit 的六个关键数字,再说明原始 ODB++ 对 9410 个 TOP 对象和 5331 条 L 记录的复核,最后说明解析几何与 Shapely/GEOS 的逐对结果集合一致。验证脚本属于开发期自查材料,不是任务书要求的提交文件;现场以可复现的统计口径和结果集合为主。

七、答辩话术集锦(按评委提问分类)

🎯 开场自述(30 秒)

📌 Q1:这些算法都是你自己写的吗?

📌 Q2:那你核心贡献是什么?

📌 Q3:为什么 ObjectID 用 1基,而遍历用 0基?

📌 Q4:为什么圆头线段的 LineLength 要等于 LineWidth?

📌 Q5:为什么要做 AABB 粗筛?直接两两算不行吗?

📌 Q6:5400 这个数字怎么验证是对的?

📌 Q7:为什么用 GetDistance 而不是 GetTouch?

📌 Q8:外扩后几何怎么变?圆头和方头有区别吗?

📌 Q9:代码量多少?

logic.cpp     542 行  ← 核心算法
logic.h        88 行
interface.cpp 269 行  ← UI交互
interface.h    72 行
interface.ui  149 行(XML)

📌 Q10:最尖锐——这代码是不是 AI 写的?

📌 Q11:GetDistance 不是你写的,你只是调了一下?

📌 Q12:性能怎么样?还能优化吗?

📌 Q13:DLL 是怎么被 DFX MetaLab 加载的?

📌 Q14:点击运行时还做了什么?

vSDK_Display_SetPartDisplay(false)  // 关闭元件显示
vSDK_Display_SetSelectMode(4)       // 选择模式→对象模式
vSDK_Display_SetObjectMode(3)       // 绘制模式→轮廓模式

📌 Q15:表格坐标格式怎么保证的?

📌 Q16:AABB粗筛为什么不会漏检?

📌 Q17:约1.552秒是怎么测出来的?

📌 Q18:没有导入DEMO2或SDK接口失败怎么办?

📌 Q19:为什么每次表格顺序稳定?

📌 Q20:工程怎么构建?为什么最终只提交五个开发文件?

📌 Q21:两位参赛者如何分工?

八、速记卡(打印带去答辩)

🔑 核心数字(背熟)

🔑 三个关键决策(必答)

🔑 分工清单(自己写的 vs 调库的)

🚫 绝对不能说的两句话

🎬 现场演示脚本(约60—90秒)

⏱ 5 分钟时间分配建议

🛡 防身护身符