上个月交付一块六层BMS主控板，客户在截止日前一天催生产文件。我打开Allegro 17.4，照老流程配Artwork Control，导Gerber，导钻孔，导坐标，导BOM，最后打包发走。整个过程约半小时。等工厂回执亮起时，我发现NC Route文件是旧版本——因为我根本没把它放进这次输出目录。那一刻我意识到，这不是"下次注意"能解决的问题，这个行为本身就不该存在。
后来我花了两周，用Allegro Skill写了一套XTools，目标只有一个：把"配置光绘Film、指定钻孔格式、命名归档、生成生产附档"这些确定性的步骤，压缩成一条命令。现在团队里无论谁拿到一块板子，运行XT_OUTPUT_ALL，程序读层叠、建Film、写参数、输出文件、归档打包，一气呵成。手动操作不再考验记忆力，交给代码的代码永远不会漏层。这篇就把XTools的设计思路、核心实现和踩过的坑完整拆出来，供同样被生产文件折磨的Layout工程师参考。
1. 手动归档这件事，到底浪费了什么
1.1 一份"完整"生产数据包里，藏着多少隐藏工序
很多工程师觉得导出Gerber就是"Manufacturing -> Artwork -> 点确认"，但如果工厂只收到一层TOP和一层BOTTOM，现场绝对会打电话来问：丝印呢？阻焊呢？钢网呢？钻孔文件呢？
一份能直接下单的生产数据包，通常包含这几类：
- 光绘Gerber：所有导电层、阻焊层、助焊层、丝印层，部分项目还要含板框层。
- 钻孔文件：NC Drill钻刀程序，以及铣外形的NC Route程序。
- 网表文件：IPC-356格式，供飞针测试或治具测试使用。
- 贴片坐标文件：Pick&Place，SMT产线贴片机程序要用。
- BOM清单：采购、产线备料、贴片编程都要用。
- 装配图：研发自检、手工焊接、产线首件确认时人工比对用。
手动流程里，这些文件的格式、命名、路径、单位、精度全部由人工确认。哪怕你再熟练，脑海中有一份checklist，检查动作本身也一直在消耗注意力。人不是机器，注意力一旦被长时间消耗，漏项就是必然。
1.2 手动操作最容易翻车的物理节点
我统计了团队一年里因为生产文件出过的问题，集中在几个固定节点：
| 环节 | 常见事故 | 后果 |
|---|---|---|
| Artwork Film配置 | 漏配内层、漏配钢网层 | 工厂无法生产，来回补文件 |
| Undefined line width | 默认0，细线断铜、蚊脚状边缘 | 板厂抱怨，电气性能下降 |
| 钻孔参数 | 单位/精度和Gerber不一致 | CNC乱码或孔位偏移 |
| NC Route | 只导出Drill、忘了Route | 外形无法切割 |
| 文件命名 | 版本号写错、目录放错 | 工厂用错版本，批量报废 |
| 改板后再输出 | 手动配置没同步 | 新Gerber混入旧层内容 |
为什么总是这些地方？因为它们没有技术难度，却有极高的"繁琐度"。人脑处理繁琐的事情时，会有意无意地想"走捷径"，一旦走了捷径，边界条件就被跳过。比如觉得"上次配好了就不用再检查"，结果上次的配置可能在别的项目里被改掉了。
1.3 确定性工作，本就不该靠人的注意力来兜底
回到那条BMS主控板的事故。NC Route没进输出目录，不是我不会操作，而是在重复劳动里漏了一步。这个逻辑放在代码里，就是"配置列表不全则报错、文件缺失则阻塞"，程序可以做到100%不漏；但人做不到。
所以XTools设计的第一个原则是：凡是能从设计数据库推导出来的映射关系，全部程序化。层叠和Film之间存在确定性映射：导电层要出正片，阻焊钢网丝印各要对号入座。钻孔格式可以由板厂参数直接推导。文件名规则可以预先定义。只要映射明确，这个动作就不该靠人来记。
2. XTools的设计骨架：在Allegro内部调用原生能力
2.1 为什么把脚本写进Allegro，而不是外部GUI自动化
最早我考虑过用AutoIt之类的工具去模拟鼠标点击Artwork界面，试了两天放弃了。原因很现实：
- 外部工具依赖屏幕分辨率和窗口焦点，渲染一变脚本就废。
- Allegro版本升级后控件坐标和层级变化，维护成本极高。
- 最致命的是，外部工具根本拿不到设计数据库的真实层叠信息，它看不到cross-section里究竟有几层导电层，只能靠人去告诉它"哪些层要输出"。
而Skill是Allegro原生的脚本语言，运行在进程内，可以直接读取设计对象、Subclass、变量，也能调用原生输出函数。这等于站在系统内部做自动化，而不是隔着屏幕模拟人。所以XTools全部用Skill写成，紧贴设计数据库这套"事实来源"。
2.2 XTools的模块划分
整个项目没有用单文件堆到底，而是按职责拆开，方便单独调试：
| 模块 | 职责 |
|---|---|
| xt_config.il | 读取用户配置文件，包括项目名、版本号、板厂profile |
| xt_stackup.il | 读取cross-section层叠信息，筛选导电层/介质层 |
| xt_film.il | 构建Film清单，生成Artwork Control文件 |
| xt_drill.il | 设置NC Drill / NC Route参数并触发输出 |
| xt_archive.il | 统一命名、归档目录、自动生成ReadMe |
| xt_ui.il | 注册菜单和命令行入口 |
| xt_main.il | 总入口，串起整个流程 |
模块之间通过一个全局上下文xt_env传递数据。启动时xt_env记录设计文件路径、用户配置、当前版本号，后面的模块只从上下文取数，避免参数满天飞。
2.3 用户入口：命令、菜单、自动加载
XTools支持两种调用方式。一种是命令行：在Allegro Command窗口输入xt_output_all即可。另一种是菜单：安装后菜单栏多出一个XTools下拉菜单，点击"一键输出生产文件"效果等价。
安装很简单，把脚本目录加入allegro.ilinit，或者在File -> Script里手动load一次。命令注册的Skill示意：
axlCmdRegister("xt_output_all" 'XT_Output_All) axlCmdRegister("xt_gerber" 'XT_Output_Gerber) axlCmdRegister("xt_drill" 'XT_Output_Drill) axlCmdRegister("xt_package" 'XT_Package_Archive) axlCmdRegister("xt_bom" 'XT_Gen_BOM)注册后菜单代码类似这样（Allegro 17.4环境验证过）：
axlUIMenuRegister( "XTools" '( ("一键输出生产文件" "xt_output_all") ("只输出Gerber" "xt_gerber") ("只输出钻孔文件" "xt_drill") ("生成BOM" "xt_bom") ("打包归档" "xt_package") ) )3. 从层叠表到Artwork Control：自动构建的核心逻辑
3.1 先读懂Allegro的"层"知识
Allegro里的层分两套体系。第一套是cross-section中的物理层，比如TOP、GND、SIGNAL、BOTTOM，它们是真正的导电层，决定PCB的叠层结构；第二套是制造用的Subclass，比如TOP/SOLDERMASK、TOP/PASTEMASK、TOP/SILKSCREEN，它们附着在某个物理层上，承担阻焊、钢网、丝印等制造功能。
XTools要做的事，就是遍历cross-section，找出所有导电层；再根据每个层的属性，自动关联出对应的SOLDERMASK、PASTEMASK、SILKSCREEN；最后把这些组合写进Artwork Control文件。
3.2 代码：读取导电层并生成Film清单
核心逻辑简化后大概是这样的（完整版有异常处理，此处只展示主路径）：
defun( XT_Extract_Conductor_Layers () let( (stack layers) stack = axlDBGetDesign()->stackup layers = nil foreach( item stack->crossSection when( upperCase(item->type) == "CONDUCTOR" layers = append1( layers item->name ) ) ) layers ) )拿到导电层列表后，将它展开为Film清单：
defun( XT_Build_Film_List (conductor_layers) let( (films) films = list( list( "TOP" list("TOP" "PIN" "VIA") ) list( "BOTTOM" list("BOTTOM" "PIN" "VIA") ) ) foreach( layer conductor_layers films = append1( films sprintf( nil "%s/SOLDERMASK" layer) ) films = append1( films sprintf( nil "%s/PASTEMASK" layer) ) films = append1( films sprintf( nil "%s/SILKSCREEN" layer) ) ) films ) )这段逻辑决定了输出哪些层，也决定了不会漏层。为什么？因为Film是从层叠表"推"出来的，而不是从上次的配置里"抄"过来的。每次运行都基于当前设计重新生成，这就消除了"旧Film残留"的根本问题。
3.3 生成Artwork Control File并触发输出
Allegro的Artwork设置可以保存为Artwork Control文件。XTools用文本方式动态生成这个文件，里面逐行写出TAPE类型、坐标格式、每个Film包含的Subclass，然后调用原生函数执行：
axlOutputArtwork( xt_artwork_file t )这里重点参数有几个：
- TAPE类型：RS274X，也就是常说的Gerber X2之前的经典RS-274-X格式，绝大多数板厂通用。
- 坐标格式：FORMAT 2.5，整数2位、小数5位，对常规板卡精度足够；如果用公制单位，也可以改成3:3。
- Undefined line width：我强制写为6mil，这个值下面会单独讲。
- 坐标模式：ABSOLUTE绝对坐标，避免相对坐标累计误差。
每次输出前，脚本会先把上一次的Artwork Control文件清空重建。这一步看似简单，实际上等价于每次都在用"干净表单"配置，而不是在旧表单上改。
3.4 钻孔文件参数怎么处理
钻孔文件是最容易被低估的一环。很多手动翻车案例都出在：钻孔的单位、精度和Gerber不一致，或者补零方式选错。XTools采用与板厂确认过的一组默认参数：
; NC Drill / NC Route 参数示意 nc_units = "metric" ; 公制单位 nc_format = "3:3" ; 整数3位小数3位 nc_zero_suppression = "trailing" ; 末尾零抑制 nc_coordinate = "absolute" ; 绝对坐标这组参数写进项目本地的nc配置，然后通过axlShell触发Allegro执行NC Drill和NC Route输出。
需要说明的是，这组参数不是所有板厂都通用。有些老牌工厂还习惯英制单位、前导零模式。所以XTools把板厂参数做成profile：每个工厂一个配置段，下单前按工厂切换。零抑制方式如果选错，CNC程序会出现整板偏移或孔数异常，这比漏一层还难排查——因为光看程序清单是看不出问题的。
3.5 命名规则：全英文、下划线、版本日期
手动归档最大的隐患其实是"人起名"：同一层，这个项目叫TOP_GERBER，下个项目叫TOP_GTL，工厂那边如果严格按命名匹配，很容易套错层。XTools里所有文件名必须经过统一函数生成：
defun( XT_File_Name (prefix layer type version date ext) sprintf( nil "%s_%s_%s_V%s_%s.%s" prefix layer type version date ext ) )生成的名字长这样：
BMS_Main_TOP_GERBER_V1.2_20250115.art BMS_Main_DRILL_V1.2_20250115.drl BMS_Main_ROUTE_V1.2_20250115.drl BMS_Main_BOM_V1.2_20250115.csv强制全英文、下划线、无空格。为什么？因为一旦文件名出现空格或中文，不同的压缩传输工具、不同品牌的CAM软件，很可能出现乱码或无法解析。命名这件事，宁可丑，不能错。
4. 按下XT_OUTPUT_ALL之后，完整生产包里有什么
4.1 输出物清单与服务对象
XTools一键执行后，产物不是一个Gerber文件，而是一整个生产包。每类文件有明确的接收对象：
| 输出文件 | 给谁用 | 干什么用 |
|---|---|---|
| Gerber（RS274X） | PCB板厂 | 干膜、蚀刻、阻焊、丝印制作 |
| NC Drill / NC Route | 板厂CNC部门 | 钻孔和铣外形 |
| IPC-356 网表 | 板厂/测试厂 | 飞针测试或治具测试 |
| Pick&Place 坐标 | SMT贴片厂 | 贴片机贴装编程 |
| BOM.csv | 采购/SMT | 建料号、备料和贴片排序 |
| Assembly PDF | 研发/手工焊 | 人工比对和维修定位 |
| ReadMe.txt | 所有接收方 | 版本、层数、工艺要求说明 |
4.2 归档结构：工厂和SMT都看得懂的目录
输出目录会自动生成，结构固定：
BMS_Main_V1.2_20250115/ ├── GERBER/ │ ├── BMS_Main_TOP_GERBER_V1.2_20250115.art │ ├── BMS_Main_BOTTOM_GERBER_V1.2_20250115.art │ ├── BMS_Main_GND_GERBER_V1.2_20250115.art │ ├── BMS_Main_TOP_SOLDERMASK_V1.2_20250115.art │ ├── BMS_Main_TOP_PASTEMASK_V1.2_20250115.art │ ├── BMS_Main_TOP_SILKSCREEN_V1.2_20250115.art │ └── ... ├── DRILL/ │ ├── BMS_Main_DRILL_V1.2_20250115.drl │ └── BMS_Main_ROUTE_V1.2_20250115.drl ├── ASSEMBLY/ │ └── BMS_Main_ASSEMBLY_TOP_V1.2_20250115.pdf ├── BOM/ │ └── BMS_Main_BOM_V1.2_20250115.csv ├── PICKPLACE/ │ └── BMS_Main_PICKPLACE_V1.2_20250115.csv └── README.txt这个结构不是拍脑袋定的，而是参考了多家板厂和SMT厂在收件时的习惯。分类目录减少了对方找文件的成本，ReadMe则把版本号、板材、板厚、表面处理、阻抗要求一次性写清楚，避免双方来回确认。
如果用户需要压缩包，XTools会调用外部7z命令行把整个文件夹压成一个zip，压缩名同样带版本和日期。
4.3 一键之后，依然要做的三项人工核对
自动化输出不意味着完全免检。我自己的实践是，XTools跑完后做三件事：
一是用CAM工具打开Gerber预览。我习惯用CAM350或者GC-Prevue在线打开，逐层看一遍，重点看板框有没有闭合、丝印有没有明显飞出板外、铜皮有没有异常断缺。
二是核对钻孔文件。用脚本对比brd里实际的过孔和焊盘数量与NC Drill文件里的孔数，数量不一致立刻报错。这一步在XTools里已经做了部分自动化：读brd的孔表，再和NC Drill解析结果比对，偏差超过阈值就阻断打包。
三是用网表工具把IPC-356和原始原理图网表比对一遍。这一步能发现"封装管脚定义不一致"这类隐藏问题，属于输出之后的额外保险。
自动化的意义在这里体现得很清楚：机器做的事情，出错率趋近于零；人工只需要把精力花在"判断结果是否合理"上，而不是花在"确保步骤都做了"上。
5. 实际跑了大半年，踩出的四个坑与修复方式
5.1 坑一：Artwork Control残留的旧Film
现象最先出现在一个二次改版项目上。第一次输出正常，第二次改版后有人反馈：Gerber目录里混进了一层"临时调试层"，这层本来只在调试版本里存在。
排查链路是这样的：先看Film清单，发现控制文件里多了一行旧Film；再看脚本，发现每次运行虽然重建了Artwork文件，但Allegro的Artwork表单里如果存在已注册的Film条目，新条目会追加在旧条目后面，而不是覆盖同名条目。两个不同名字的Film同时存在，输出时全部被执行。
修复方案：XTools在生成Artwork Control文件之前，先调用清除逻辑，把Artwork表单中所有已注册Film条目清空，再写入本次生成的Film清单。这个看似琐碎的细节，恰恰是"自动生成配置"和"在旧配置上打补丁"的本质区别：配置文件必须是幂等的——每次运行的结果都是基于当前设计重新推导，而不是在旧状态上累积。
5.2 坑二：Undefined line width 等于0引发的细线断铜
上线一段时间后，板厂反馈某批板子铺铜区域出现"蚊脚状"边缘，还有几处细线看起来像断的。拿到CAM文件放大后确认，是部分Shape边缘和Route Keepin上的线条线宽为0，导致光绘解释器输出异常细的图形。
原因其实在Allegro本身：如果你在Artwork Control里把Undefined line width填0，那些没有显式定义线宽的图形对象按0处理；如果板厂制程能力不足以做这么细的线，就会出现断铜或边缘毛刺。手动配置时很多人会随手填一个6mil或8mil，但脚本生成配置时，早期版本忘了处理这个字段，沿用默认值0。
修复方案：XTools把Undefined line width强制设为6mil，并在输出前做一次lint检查。lint会扫描所有Shape和Line，找到线宽低于2mil的对象，先告警再决定是否继续。这不是为了刁难设计师，而是让"无意中产生的最小线宽"在进工厂前暴露出来。
5.3 坑三：16.6与17.4的API差异
团队里不是所有人都升到了17.4，还有人用16.6。XTools在16.6上一跑就报unknown function。排查后确认，部分axl函数是17.x才引入的API，在16.6里要么不存在、要么参数不同。
修复方案：入口处用axlVersion()判断版本号，大于等于17.4走新版API分支，16.6走旧版兼容分支。同时把最小支持版本锁在16.6，低于16.6直接提示不兼容并终止。这里也想提醒各位：写Skill工具时尽量少用太新的函数，除非你能保证团队环境同步升级；如果必须用，要做好分支。
5.4 坑四：输出路径与文件名的字符问题
有一次合作的SMT厂反馈，压缩包里的Pick&Place文件名打开后变成"乱码"——实际是文件名里有全角括号和中文，工厂的贴片机程序内置了严格的字符集，解析失败。
这坑完全可以通过规则规避。XTools最终固定了命名规范：只允许ASCII字符、下划线和连字符，禁止空格、中文、全角符号。输出路径也强制为项目根目录下的output/，如果检测到路径里有中文或空格，脚本会直接报错并给出建议路径。可能有人觉得"不让用中文路径"很粗暴，但在我这个场景里，规则简单、执行严格，比花哨的宽容逻辑更可靠。
6. 还没做完的事：ODB++、版本比对与团队共享
6.1 向ODB++延伸
RS-274X当下够用，但越来越多板厂开始接受ODB++甚至IPC-2581。ODB++把图形、钻孔、网表、物料信息集成在单一数据库中，文件的传递和管理比一堆Gerber加Drill更清晰。Allegro 17.4有ODB++相关菜单，但Skill的开放接口并不完整，XTools目前没有直接集成，只是预留了外部转换工具的调用点。下一步计划是把ODB++输出也纳入一键流程，同时保留Gerber作为双保险，毕竟不是所有工厂都吃ODB++。
6.2 增加"版本水印"与归档指纹
生产文件最怕的其实是"拿错版本"。Gerber文件本身不带版本信息，文件名里的V1.2全靠人输入，存在输错的可能。XTools计划在ReadMe里自动记录当前brd文件的MD5值、输出时刻、版本号，并把这些信息同步写进归档日志。将来一旦出现争议，可以直接通过MD5反查是哪一份brd产生的文件，避免在版本问题上扯皮。
6.3 团队共享与配置统一
目前XTools的配置以本地文件为主，不同工程师手里的板厂profile不完全一致，出现过同一块板子两个人导出的钻孔文件精度不同的情况。下一步准备把配置改成共享盘或Git仓库里的统一profile，配合一个简单的"一键同步配置"命令，保证团队所有人用的是同一套参数。
最后分享一条我自己受益最多的经验：工具写完以后，用一块已经正常交付过的老项目做"回归样本"，每次改脚本都跑一遍，对比输出文件与上一版的差异。这比任何单元测试都管用，因为PCB生产文件这个事的"正确"标准只有一个——工厂能顺畅地把它做出来。凡是能让工厂顺畅生产的改动，都值得沉淀进工具里；凡是让人重复记忆的步骤，都值得扔进代码里。
