企业官网建设流程全解析

简介：面向 SolidWorks 二次开发入门与进阶者的一套参数化建模示例工程，重点解决在 VC6 环境下通过插件方式调用 SolidWorks API、实现零件尺寸驱动与模型自动生成的问题。包内共95个文件，以 C++ 源码（.cpp/.h）、资源脚本（.rc/.rgs）、编译中间文件（.obj/.pdb/.sbr）及界面位图（.bmp）为主，并含类型库与注册文件，整体约4.33MB，便于直接编译调试并观察插件注册、对话框交互和参数传递流程。已有624人学习下载。工程包含零件、属性页、对话框、文档与日志等多模块源码，可帮助梳理 MFC 插件从入口到 API 调用的完整路径；位图资源与注册脚本则方便复现界面和部署过程。读者可从中获取插件工程的组织结构、SolidWorks 类型库引用方式、参数化建模的核心调用链，以及资源与界面搭建的参考实现，适合需要理解二次开发框架、对照代码排查编译与注册问题的开发者。

1. 从一张改到吐的图纸说起：参数化建模为什么要落到二次开发上

某非标设备团队接过一批结构高度相似的机架，八成尺寸都由三个安装距和两个接口直径推出来。每改一次型，画图的人要把草图尺寸翻三遍、把工程图标注对两遍，最后再手改一遍 BOM。做到第五十套，图纸本身没错，人先出错。参数化建模要解决的正是这件事：把「以参数为准」的规则固化成模板，再让程序去驱动它，而不是靠人记。SolidWorks 的二次开发接口恰好卡在这个位置上——它既读得到模型里的尺寸与配置，也写得进新值并触发重建。这套方案适合三类人：正在做毕设、需要拿出一个可演示可验收的自动化建模系统的学生；课程设计里要做 CAD 二次开发题目的同学；以及手上有一批结构件、想把手改图纸换成填参数表的从业者。

2. 技术选型与接口结构：三层对象模型与四种调用形态的取舍

动手写第一行代码之前，先把「谁是谁」搞清楚，比急着调通一条拉伸特征划算得多。SolidWorks 的接口是一套 COM 组件，对外的入口只有一个，但内部是严格的三层结构。很多人第一次做二次开发翻车，不是逻辑写错，是根本没分清自己拿到的对象属于哪一层，结果在装配体上调零件的方法，或者在零件上调工程图的方法，编译能过、运行报空。

2.1 SldWorks 到 ModelDoc2：把对象模型先摸清

顶层是应用程序对象，代表进程本身，负责开文档、关文档、读系统选项、拿插件对象。往下一层是文档对象，零件、装配体、工程图共用同一个基类，只是各自还有一层专属扩展：零件能拿到特征管理器，装配体多一个组件集合，工程图多一个视图集合。再往下是几何与参数层，草图、特征、尺寸、配置都挂在这一层。

这套结构决定了写代码的顺序永远是从上往下拿：先有应用，再有文档，再从文档里取你要改的那个尺寸。反过来，从尺寸对象往上找文档也不是不行，但那属于绕路，异常处理会多出一倍。

// 连接已在运行的实例；若没有则新建一个进程 SldWorks swApp = null; try { swApp = (SldWorks)Marshal.GetActiveObject("SldWorks.Application"); } catch (COMException) { swApp = (SldWorks)Activator.CreateInstance( Type.GetTypeFromProgID("SldWorks.Application")); } swApp.Visible = true; // 调试期打开，正式批处理时关掉能快一截 swApp.CommandInProgress = true; // 告诉宿主当前有命令在跑，避免界面抢焦点

这里的取实例方式值得多说一句。批量脚本如果每次都新建实例，跑一百个零件就会在任务管理器里留下一串残影，最后内存吃满、机器卡死。优先连已有实例，连不上再新建，是批处理场景的常规写法。CommandInProgress置位的作用是告诉 SolidWorks 当前有自动化命令在执行，避免用户在界面上误触打断流程。

文档对象的获取则统一走打开接口，返回值就是文档基类，需要零件专属能力时再向下转型：

int errs = 0, warns = 0; ModelDoc2 doc = swApp.OpenDoc6( partPath, (int)swDocumentTypes_e.swDocPART, // 文档类型：零件 (int)swOpenDocOptions_e.swOpenDocOptions_Silent, // 静默打开，不弹对话框 "", // 配置名，留空表示用上次激活的 ref errs, ref warns); if (doc == null) throw new InvalidOperationException($"打开失败 errs={errs} warns={warns}");

errs和warns这两个输出参数千万别丢。打开失败时返回的可能是空引用，光看返回值你只知道「失败了」，不知道是文件被占用、路径不对还是版本不兼容；把这两个码记进日志，排查时能省半天。静默打开这个选项在无人值守的批处理里是必须的，否则文档里有缺失引用时会弹窗等人点，脚本就永远卡在那儿。

2.2 宏、独立程序、Add-in、外部脚本四种形态怎么选

接口摸清之后，下一个决策是「代码挂在哪」。四种形态各有各的适用面，选错了后期改起来很痛苦。

宏是最轻的，录一段操作、改几行就能跑，适合验证某个 API 到底怎么调、参数顺序是什么。缺点是宏跟文档绑得太松，分发要靠文件拷贝，而且宿主是 SolidWorks 自己的编辑器，调试能力有限，稍微复杂一点的逻辑就会写成一团。

独立程序是一个 exe，自己起界面、自己读参数表、自己连 SolidWorks 实例。这种形态在「批量生成」类需求里最实用：参数可以来自 Excel、来自数据库、来自命令行，用户不用打开软件本体也能跑。毕设和课程设计大多应该选这一种，因为它能独立演示，答辩时不用现场装插件。

Add-in 是挂在 SolidWorks 进程里的插件，启动即加载，用户可以直接在菜单栏点按钮，体验最接近原生功能。代价是要注册 COM 组件、要处理加载卸载、调试时要附加进程，对第一次做的人来说门槛不低。

外部脚本用 Python 之类的语言调用 COM，胜在改起来快、跟数据处理生态接得顺，适合做一次性迁移或者小批量试验。缺点是类型信息弱，容易在参数类型上栽跟头。

我一般的判断是：要交付一个能独立运行、能批量处理的系统，选独立程序；要在软件里加一个常驻按钮，选 Add-in；只是想把某个反复操作省掉，写宏就够了。

2.3 三条参数驱动路线：尺寸、方程式、配置

参数化建模本身有三条驱动力，选哪条决定了整个系统的复杂度。

最直接的是尺寸驱动：程序按名字找到某个尺寸，直接写入新值，重建。这条路线控制粒度最细，想改哪个改哪个，缺点是要维护一张「尺寸名到业务参数」的映射表，模板一改名字，映射就断。

第二条是方程式与全局变量：在模板里预先把关键尺寸绑到全局变量上，程序只改全局变量的值。好处是映射关系稳定，改模板几何不影响变量名；缺点是模板搭建要求高，一旦有人手改方程式，整个约定就废了。

第三条是配置：同一个零件文件里放多个配置，每个配置对应一组尺寸值，程序只切换配置或者批量新建配置。这条最适合「系列化」场景，一个文件管一整个族，工程图也能跟着配置走。

实际项目里这三条通常是混用的：配置负责大结构差异，全局变量负责族内的关键参数，尺寸驱动负责少数需要精调的位置。把这条分工在方案里写清楚，后面的架构才不会乱。

3. 总体架构设计：参数层、几何层、输出层的职责划分

把功能列成一堆菜单项，是很多人做二次开发时最常见的组织方式，结果代码跑到三千行就没人敢动了。换个思路，按「数据从哪来、几何怎么变、结果去哪」切成三层，每一层只跟相邻层说话，边界清晰了，后面加需求只是加一个模块，不是改一锅粥。

3.1 参数表结构与校验规则

参数层负责一件事：把外部的输入变成程序能信任的结构化数据。输入通常是 Excel 或 CSV，一张表一行对应一个零件实例。设计这张表时最容易犯的错是「列名直接对应尺寸名」，看着省事，实际把几何细节漏进了业务层，模板一改整张表作废。

比较稳的做法是业务列和几何列分开。业务列是用户填的：型号、安装距、接口直径、材质、数量；几何列是程序算的或者映射的：对应的尺寸全名、目标配置名、输出路径。中间用一个映射配置把它们接起来。

校验一定要在打开 SolidWorks 之前做完。等程序已经把文档读进内存了再发现某行数据非法，前面的开销全白费，而且容易留下没关闭的文档。批量场景下，一行坏数据不该拖垮整批，正确做法是把这一行标成失败、记下原因、继续下一行，最后统一出一张结果表。

3.2 模板零件的建模规范与命名约定

几何层的核心资产是模板零件。模板做得好不好，直接决定二次开发能不能落地。我一般会要求模板满足几条硬约束：草图必须完全定义，不允许有过定义或欠定义的悬空几何；关键尺寸必须改成语义化名称，比如把默认的D1@草图1改成安装距A@主草图；所有可驱动尺寸集中在少数几个草图或特征里，不要散落在几十个特征深处；装配体模板里用配合而不是固定，避免改一个零件整机炸开。

命名约定同样要写进方案。尺寸全名的格式是「尺寸名@所属特征名@所属文档名」，程序按字符串匹配去取，任何一个环节改名都会命中失败。约定一旦定下来，模板的任何改动都要走评审，不能让画图的人随手改。

除了尺寸，还有一类元数据要处理：自定义属性。材质、型号、重量、图号这些东西不会改变几何，但要写进工程图标题栏和 BOM。属性写在文档级的自定义属性管理器里，可以按配置区分，也就是说同一个文件的不同配置可以有不同的图号。

// 按配置写入自定义属性，第二个下标是配置名，空串代表"文档级" CustomPropertyManager cpm = doc.Extension.CustomPropertyManager[""]; cpm.Add3("图号", (int)swCustomInfoType_e.swCustomInfoText, 图号值, (int)swCustomPropertyAddOption_e.swCustomPropertyReplaceValue); cpm.Add3("材质", (int)swCustomInfoType_e.swCustomInfoText, 材质值, (int)swCustomPropertyAddOption_e.swCustomPropertyReplaceValue);

Add3的第四个参数决定同名属性存在时是覆盖还是报错。批处理场景下必须选覆盖，否则第二次跑同一批数据会全线失败。这一点在第一次调试时如果没注意，很容易得出「程序只能跑一次」的错误结论。

3.3 生成流水线的时序与失败回滚

把整条链路串起来看，一次生成要经过：读表校验、打开模板、改参数、重建、另存、出工程图、写结果日志。这七步里任何一步失败，都必须保证后面的步骤不再执行，并且已经打开的文档要关掉。

时序上有两个容易忽略的点。一是另存必须在重建成功之后，否则存下去的是旧几何；二是工程图必须在零件另存之后才打开，因为工程图引用的是新文件名，顺序反了会引用到模板本身。

失败回滚的原则是「谁打开谁关闭」。程序里用try/finally包住整个处理单元，finally 里无条件关闭本次打开的文档，不要在 catch 里关——异常发生时，栈可能已经不在原来的位置了。

foreach (var row in rows) { ModelDoc2 part = null; try { part = OpenPart(swApp, templatePath); ApplyParams(part, row); // 写尺寸 if (!part.EditRebuild3()) throw new Exception("重建失败，几何可能自相交"); part.SaveAs3(row.OutputPath, 0, 0); ExportDrawing(swApp, row); // 出图单独成一步 results.Add(new Result(row, true, "")); } catch (Exception ex) { results.Add(new Result(row, false, ex.Message)); } finally { if (part != null) swApp.CloseDoc(part.GetTitle()); } }

这段结构看起来平淡，但它把「单行失败不影响整批」和「文档一定关闭」两件事同时保证了。批量任务最怕的不是报错，是报错之后进程里还挂着二十个没关的文档，内存越跑越高，最后在某一行莫名其妙地崩掉。

4. 核心模块实现：尺寸驱动、特征重建与批量出图

架构定完，接下来是最见真章的部分：真正把值写进模型，并且确认它确实生效了。这一层代码量不大，但细节密度最高，单位、命名、重建状态三件事任何一件出问题，表现都是「模型没变」。

4.1 定位并改写尺寸：名称解析与单位换算

SolidWorks 的 API 里，所有长度量的内部单位都是米。这一点必须刻在脑子里：你在界面上看到的是 50 毫米，程序里读出来是 0.05。参数表如果按毫米填写，进入 API 之前必须除一千；反过来读回来给用户看，要乘一千。这个换算只要漏一处，结果就是模型放大或缩小一千倍，而且往往要到出图打印时才发现。

取尺寸有两个入口。按名字取最直接，字符串格式是「尺寸名@特征名」，文档名可以省略：

// 尺寸全名形如 "安装距A@主草图"，不含文档名时按当前文档匹配 Dimension dim = (Dimension)doc.Parameter("安装距A@主草图"); if (dim == null) throw new Exception("未找到尺寸，检查模板是否改名或该尺寸不在当前配置中"); // 参数表按毫米填写，API 要求米，这里统一换算 double valueInMeter = row.安装距A / 1000.0; // 只在当前激活配置里改，不影响同文件的其它配置 int rc = dim.SetSystemValue3( valueInMeter, (int)swSetValueInConfiguration_e.swSetValue_InThisConfiguration, null); if (rc != 0) throw new Exception($"尺寸写入失败，返回码 {rc}");

SetSystemValue3的第二个参数是这条命令最关键的开关。选「仅当前配置」，改值只影响激活的那个配置，其它配置保持原样；选「所有配置」，整个文件所有配置一起变。做系列化的时候如果错选成后者，你会得到一堆几何完全相同的配置，而且很难反查是哪一步改坏的。

返回码不要忽略。写值成功返回 0，非 0 一般意味着尺寸被方程式锁定、被几何关系限制，或者名字匹配到了但对象类型不对。这时候继续往下重建，得到的是一份看起来成功、实际没变的模型，比直接报错更麻烦。

另外还有一个隐坑：doc.Parameter只认当前激活配置下的尺寸。如果某个配置里这个尺寸被压缩了，取到的就是空引用。所以按配置生成时，顺序应该是先激活目标配置，再取尺寸，再写值。

4.2 重建结果的校验：不只是看返回值

EditRebuild3返回布尔值，但这个值只代表「重建过程没有抛出致命错误」，不代表几何是合理的。尺寸改成自相交、壁厚改成负数、圆角半径大于相邻边长度，这些情况重建照样返回真，模型却已经是一坨废几何。

真正靠谱的校验得自己做，通常是三层。第一层是几何校验，调用文档的几何检查能力，看有没有无效面或无效边；第二层是数值校验，把关键尺寸读回来跟期望值比对，确认写入真的生效；第三层是业务校验，检查质量属性、包围盒尺寸是否落在合理区间。

doc.EditRebuild3(); // 第一层：把刚写进去的值读回来比对，确认没有被方程式改回去 double readBack = dim.GetSystemValue3( (int)swInConfigurationOpts_e.swThisConfiguration, null); if (Math.Abs(readBack - valueInMeter) > 1e-6) throw new Exception($"回读不一致：期望 {valueInMeter}，实际 {readBack}"); // 第二层：包围盒尺寸落在业务允许区间内 double[] box = (double[])doc.Extension.GetBox( (int)swBoundingBoxOptions_e.swBoundingBoxOptions_VisibleOnly); double length = box[3] - box[0]; if (length < 0.01 || length > 5.0) throw new Exception($"包围盒异常：{length:F3} m");

回读比对这一步看着多余，实际救过很多次场。方程式、全局变量、设计表这三样东西任何一个在后台生效，都会把你刚写的值覆盖掉，而 API 不会报错。只有读回来对一遍，才知道到底谁说了算。

包围盒校验则是最省事的业务兜底：不管内部几何怎么变，最终零件的外形尺寸总得落在合理范围。这条规则写起来只有两行，却能挡住绝大多数「参数填错一位」的低级事故。

4.3 配置与系列化：一张表生成整族零件

当一个文件要管一整个零件族时，配置是比「一个型号一个文件」更好的组织方式。好处很实在：工程图、材料、属性都能跟着配置走，文件数量少，后期维护成本低。

生成配置的顺序是：激活模板配置、复制一份新配置、在新配置里改尺寸、写该配置的属性。复制这步不能省，直接新建空配置会得到一个没有特征的壳。

// 以模板配置为蓝本复制，保证特征树完整 Configuration cfg = doc.AddConfiguration3( row.型号, // 新配置名 "由参数化程序生成", // 备注 "", // 备用名，一般留空 (int)swConfigurationOptions2_e.swConfigOption_SuppressByDefault); if (cfg == null) throw new Exception("配置创建失败，名称可能重复"); doc.ShowConfiguration2(row.型号); // 切到新配置再改尺寸

swConfigOption_SuppressByDefault这个选项决定新配置里特征的压缩状态。系列化零件通常希望新配置继承模板的压缩状态，方便后续按需打开某些特征。如果选成全部解开，一个本来只有五个特征的零件会突然冒出二十个，重建时间和文件体积都会失控。

配置名本身也要管。用型号做配置名是最自然的，但型号里如果带斜杠、井号、星号这类字符，创建会直接失败。稳妥的处理是在写入前做一次字符清洗，把非法字符替换成下划线，同时保留原始型号到自定义属性里，供 BOM 显示。

如果零件族的差异维度不多、组合数可控，也可以在模板里预置一张系列零件设计表，由 Excel 维护每一行的配置值。程序这边只需要往表里追加行、触发重建就行。这条路线的好处是参数改了不用重新编译程序，坏处是对 Excel 有依赖，且设计表被手工动过之后很难查。我一般把它留给「参数组合固定、变更频率低」的场景。

4.4 工程图与 BOM 的自动刷新

零件生成完只是半成品，交付物里还有工程图和明细表。这两块的自动化程度，决定了这套方案是「能演示」还是「能干活」。

工程图的关键在于引用关系。模板工程图里预先放好视图，视图指向的是模板零件；零件另存成新名字之后，工程图的引用需要重新指向。正确顺序是：先另存零件，再用新文件路径打开对应的工程图模板副本，让软件自己完成引用重定向，最后重建视图。

// 复制工程图模板到目标路径，再打开它 File.Copy(drawingTemplate, row.DrawingPath, true); ModelDoc2 drw = swApp.OpenDoc6(row.DrawingPath, (int)swDocumentTypes_e.swDocDRAWING, (int)swOpenDocOptions_e.swOpenDocOptions_Silent, "", ref errs, ref warns); drw.EditRebuild3(); // 让视图重新计算 DrawingDoc dw = (DrawingDoc)drw; // 遍历图纸上的视图，更新其中的 BOM 表 object[] views = (object[])dw.GetViews(); foreach (object v in views) { View view = (View)v; BomTableAnnotation bom = view.GetBomTable(); if (bom == null) continue; bom.UpdateTable(); // 触发 BOM 重新读装配体 } drw.SaveAs3(row.DrawingPath, 0, 0);

UpdateTable这步经常被忘掉，结果是工程图打开了、视图刷新了，BOM 还是旧的。原因是 BOM 表缓存了上次读取的结果，只有显式更新才会重读装配体结构。

视图引用重定向还有一个更隐蔽的情况：如果新零件和模板零件在同目录、名字前缀相同，SolidWorks 有时会自己「猜」到错误的那一个。避免的办法是让每个型号的输出目录独立，文件名用完整型号而不是增量编号，减少同名匹配的机会。

到这一步，一条从参数表到零件到工程图的链路才算闭合。整个流程里真正难的从来不是某一行 API，而是这些「看起来应该自动、实际不会自动」的地方。

5. 避坑与排查：参数化流水线上最容易翻车的五个点

这套东西调通不难，稳定跑一个月不难才难。下面五条是实际项目里出现频率最高、而且症状最有迷惑性的问题，每一条都按「看到什么、为什么、怎么办」写，遇到时可以直接对号入座。

5.1 尺寸改了，模型纹丝不动

现象很典型：程序返回成功，日志里写着「写入完成」，打开模型一看还是原来的样子。

原因通常有三个。一是尺寸被方程式或全局变量绑定，程序写进去的值在重建时被公式重新算了一遍盖掉；二是尺寸被几何关系完全约束，比如标注从动，改它等于改一个结果而不是输入；三是取到的尺寸对象根本不在当前激活的配置里，写了个空。

排查顺序是：先回读，把GetSystemValue3的结果打出来，看是不是真的写进去了；如果回读值不等于写入值，去查方程式的数量，把方程式临时解掉再试；如果回读是对的但模型没变，检查尺寸的驱动状态和草图是否完全定义。

解决办法，从根本上说是在模板阶段就把规矩定死：参与参数化的尺寸一律不许被方程式引用，需要公式的放到业务层算，算完再写死值。我见过一个项目为了「灵活」把所有尺寸都挂上方程式，结果二次开发做成了「改什么都不生效」，最后靠删方程式才救回来。

5.2 模型整体放大一千倍

现象是生成的零件尺寸离谱，50 毫米的安装距变成了 50 米，屏幕上只剩一个角。

原因只有一个：单位没换。API 内部统一用米，参数表通常按毫米填，中间漏了除以一千。这个错误之所以危险，是因为它在程序层面完全合法，写入成功、重建成功、保存成功，一路绿灯，只有人眼看得见。

解决方式是把换算收口到一处。不要在几十个地方各写一遍/1000.0，而是在读取参数表之后立刻统一转换成米，后续所有代码只处理米。反过来输出报表时再乘回去。同时配合 4.2 里说的包围盒校验，一旦外形尺寸超出业务区间就报错，把这类错误挡在保存之前。

还有一个变体：有些尺寸的类型不是长度而是角度，单位是弧度。角度参数如果也按度数处理，同样会偏，而且偏得更隐蔽——一个 90 度的折弯变成 90 弧度，几何直接炸开。参数表里最好单独标出单位列，程序按列的类型分派换算规则。

5.3 跑到一半卡死，进程里挂着一堆文档

现象是脚本前几十个跑得好好的，突然不动了，任务管理器里 SolidWorks 进程内存一路涨。

原因基本是两个：打开的文档没关，或者文件被别的进程占用。前者的典型写法是只在成功分支里关闭文档，异常分支直接跳出循环；后者常见于上一次运行崩溃留下的锁，或者文件正被同步盘扫描。

排查时先看进程里的文档数量，能直接确认是不是泄漏。如果是，把关闭动作挪进 finally，并且用GetTitle拿到的标题去关，不要用完整路径——CloseDoc认的是标题不是路径，传路径进去关不掉还不报错。

文件占用的问题更麻烦一些，因为表现是打开返回空引用，错误码却不明显。稳妥的做法是打开前先做一次可写性探测，拿不到独占句柄就跳过并记录，不要硬开。

另外提醒一句：批处理跑之前把同步盘的实时扫描关掉，这个操作能省掉一大半莫名其妙的占用失败。血泪经验，不是玄学。

5.4 中文路径或特殊字符导致打开失败

现象是同样的代码，测试机跑得好，换台机器就报打开失败，文件明明在那儿。

原因通常是路径里带中文、空格或括号，而程序在某处做了字符串拼接或编码转换。COM 接口本身对 Unicode 是支持的，问题多出在中间层：读 CSV 时用了默认编码、拼路径时用了字符串插值没做转义、日志里打印出来的路径看着对但实际有不可见字符。

解决方式有三条：读参数表时显式指定 UTF-8；路径统一用Path.Combine拼，不手写分隔符；打开前先File.Exists判一次，不存在就把实际路径原样打进日志，用引号包起来，能立刻看出有没有多余空格。

文件名本身也建议做清洗。型号里带斜杠、星号、问号这类字符，在文件系统上本来就是非法的，创建时不一定报错，但后续打开会失败。统一的清洗规则是把这些字符替换成下划线，同时保留原始型号到属性里。

5.5 批量跑到一半崩溃，没有后悔药

现象是跑了三百个零件，程序在第两百多个崩了，前面生成的哪些成功、哪些失败、哪些只做了一半，全不知道。

原因很简单：没有断点续跑的能力，也没有中间状态记录。批处理程序把「生成」和「记录」混在一起，记录写在最后，程序一崩什么也没留下。

解决办法是改成「先记后做」。每处理一行，先在结果表里写一条「处理中」，成功后改成「成功」，失败改成「失败 + 原因」。这样即使进程被杀，打开结果表就知道进行到哪一行，从下一行接着跑就行。同时输出文件先写到临时目录，确认成功再移到正式目录，避免半成品混进交付物。

这套机制写起来不到五十行，但它决定了这套方案是「演示一次」还是「每天都能跑」。我一般还会在结果表里加一列耗时，跑完看一眼哪几行特别慢，往往能发现模型复杂度失控的型号。

6. 验收与答辩：用哪几组数据证明这套参数化方案站得住

验收这件事，最容易犯的错是演示「跑通了一个」。跑通一个和能交付之间差着十个数量级。答辩或者交付评审时，评委真正想看的不是你点一下按钮出来一个零件，而是这套东西在边界上会怎么表现。

我一般会准备四组数据，覆盖四个维度。

这四组里，异常组最能体现工程成熟度。很多人准备的演示数据都是干净漂亮的，一旦评委随手填个空值就全线崩溃，前面讲的架构再漂亮也没用。

答辩陈述建议按「问题—方案—证据」三段走，不要按代码结构讲。先说清楚原来手工改一套图要多久、错在哪里；再说这套方案把哪些环节变成了填表；最后用上面那张表的实测数字收尾。中间的技术细节，等评委问到了再展开——被问到 API 怎么处理单位、怎么保证重建成功，这些才是加分项，主动讲反而容易讲散。

有几个问题几乎一定会被问到，提前想好答案：模板改了怎么办（答：映射配置独立于模板，改模板只改映射，有变更记录）；生成的零件能不能手工再改（答：可以，但再跑一次会覆盖，所以手工修改要走另存）；为什么不直接用系列零件设计表（答：设计表适合固定组合，程序适合参数需要计算或者来自外部系统的场景）。这三个问题答得利落，基本就稳了。

最后说一句自己的教训。早些年做第一个版本，验收时只跑了三组标准数据，全部通过，交付第二周就被打回来——现场有人填了一个 0，程序把零件壁厚改成了零，重建返回成功，保存也成功，打开一看是个空壳。从那以后我每次交付前都强制走一遍「异常输入组」，宁可自己先把它跑崩，也不让它在别人手里崩。希望帮到你。

本文还有配套的精品资源，点击获取