PCB昨晚改了连接器方向，今天重新导出了Gerber。
BOM没重新导出，因为“没有加减器件”。坐标文件也没动，因为“就改了一个地方”。
发厂前，把输出目录压缩一下，发给贴片厂：
“以这版为准，可以安排了。”
问题是：压缩包是今天生成的，里面的文件却不一定属于同一个设计状态。
新Gerber、旧BOM、另一版坐标文件，单独打开可能都没有明显问题，放在一起却可能无法指导正确生产。
本文要解决的，就是PCB交付前这个容易被忽略的问题：
怎样确认Gerber、BOM和坐标文件，不只是“都导出来了”，而是能够互相对得上？
不需要先建设复杂的交付系统。对小团队来说，从固定输出配置、明确设计基线和一张交付清单开始，就能让发厂资料更容易检查和追溯。
免费试用30天链接
“三件套对账”，到底对什么？
这里的“三件套”是指：
- Gerber及配套钻孔资料：说明裸板制造所需的图形与孔信息；
- BOM：说明要使用哪些器件，以及位号、型号、数量等信息；
- 坐标文件：说明相关装配对象的位置、装配面及旋转信息。
它们分别服务于不同环节，但必须能够对应到明确的设计状态和装配要求。
需要强调的是：三件套是本文检查的主线，不代表每家工厂只需要这三类文件。
装配图、特殊工艺说明以及其他交付格式，仍应按接收方要求提供。
对账不是比较三个文件的日期
“修改时间都是今天”不能证明来源一致；“文件名都有V1.2”也不能证明内部内容匹配。
真正要对的是三个层次：
层次 | 核心问题 | 检查重点 |
|---|---|---|
来源一致 | 从哪一个设计状态生成？ | 工程版本、提交或发布依据、输出配置 |
装配一致 | 这次到底生产哪个版本？ | 变体、装配范围、不装件 |
对象一致 | 同一个位号在各份资料中是否说得通？ | 型号、位置、装配面、方向及例外说明 |
文件齐全是起点，来源与内容能够互相解释，才是对账完成。
先看一个场景：为什么“只改一点”也要检查整套资料？
以下为示例场景。
一块控制板准备再次打样，本轮有三项修改：
- J2旋转180°，以适配新的线束方向；
- U3更换为经过项目验证的同封装型号；
- 基础版不再装配指示灯D5。
如果工程师只重新导出Gerber，会发生什么？
修改 | 只看Gerber可能漏掉什么 | 还要检查哪些资料 |
|---|---|---|
J2旋转180° | 坐标文件可能仍保留旧方向 | 坐标文件、装配图 |
U3更换同封装型号 | 铜层可能没有变化，BOM却应更新 | BOM、批准的选型或替代记录 |
D5改为不装 | 裸板焊盘仍然存在，不代表需要贴装 | 变体、BOM、坐标文件、不装件说明 |
这说明：
Gerber正确，不等于采购型号正确；裸板相同，不等于装配版本相同。
同封装换料时，Gerber可能保持不变，但BOM已经发生实质变化。处理不装件时，也需要核对变体、BOM、坐标文件与装配说明之间的关系。
所以，交付检查不能只围绕“我刚刚改了哪个文件”，而应围绕：
这次修改会影响工厂的哪些动作？
第一步：先和工厂确认“需要什么”，再决定“导出什么”
不要直接复制上一个项目的输出配置，也不要默认上一家贴片厂接受的资料，下一家也能直接使用。
发厂前，至少确认以下内容：
项目 | 需要确认的问题 |
|---|---|
裸板制造 | 文件格式、层命名、板框、钻孔及特殊工艺要求 |
BOM | 必填字段、完整型号、数量表达、替代料及不装件表达方式 |
坐标文件 | 单位、坐标原点、装配面、旋转角度及方向约定 |
装配图 | 极性、1脚标识、连接器方向、特殊装配说明 |
交付方式 | 文件组织、版本标识、接收人及旧资料作废方式 |
这些要求应由项目和接收方明确，而不是靠软件默认值推断。
特别注意：坐标文件中的“90°”不是全部答案
方向是否正确，需要结合封装定义、导出约定和工厂贴装流程核对。
建议优先挑选以下器件检查：
- 有极性的器件；
- 连接器；
- IC；
- 底面器件；
- 本轮旋转过或调整过封装方向的器件。
不要在没有确认约定的情况下，仅凭某个角度数值判断方向正确或错误。
第二步：用OutJob固定输出配置，减少“这次和上次不一样”
临时从菜单导出文件很方便，但重复交付时，容易出现：
- 这次少选了一层；
- BOM输出字段与上次不同；
- 坐标文件单位发生变化；
- 导出目标仍指向旧目录。
Altium的Output Job可以保存多类输出配置。在项目中添加Output Job File后，配置所需输出及目标容器，再执行生成。
建议的配置顺序
在项目中添加OutJob文件
明确哪一份用于正式交付，避免多份配置混用。配置需要的输出
按接收方要求设置Gerber、钻孔、BOM、坐标文件及装配资料。逐项核对参数
包括层集合、单位、字段、变体选择与输出位置等适用设置。配置输出目标并试生成
先在测试目录生成一次，再打开结果检查。将OutJob与项目共同维护
输出规则改变时，记录改变原因和适用范围。
一个容易踩的坑：菜单导出设置，不等于OutJob设置
直接从编辑器导出的设置，与OutJob中的设置是分开保存的。
如果你刚刚通过菜单调整了Gerber设置，不应假定OutJob已经同步改变。下一次使用OutJob时，仍需检查对应配置。Altium_Develop_...icles.docx
团队最好明确：
哪份OutJob是本项目的正式交付配置？谁可以修改？修改后怎样检查？
OutJob能固定重复设置，但不能自动证明配置满足这家工厂的全部要求。
第三步：输出前建立基线，输出中不要继续改设计
本轮交付至少应明确：
- 项目名称；
- 硬件版本；
- 本次装配变体；
- 源设计状态；
- 正式输出配置。
其中，“源设计状态”应尽量精确：如果项目有受管理的提交或发布依据，记录对应标识；如果采用本地流程，则保留明确的工程归档副本和记录。
仅写“最新版”不够，因为工厂生产期间，研发可能已经开始下一轮修改。
输出前检查五件事
本轮设计修改已经保存；
原理图与PCB一致性已经检查；
已完成项目规定的ERC、DRC及人工复核；
已确认要生产的变体和不装件；
已确认正式输出配置。
规则检查通过，不代表所有电气、制造和装配要求都已验证。关键封装、连接器方向及特殊工艺仍需单独检查。
生成过程中发现要改设计，怎么办？
不要一边生成文件，一边继续修改源工程。
例如，生成BOM后发现U3型号后缀不完整，你修改了参数，接着生成Gerber和坐标文件。此时，先前生成的BOM就可能不再对应最终状态。
正确处理方式是：
- 暂停本轮交付；
- 完成修改；
- 重新确认设计基线；
- 重新生成受影响的完整资料集合；
- 再做一次对账。
对于规模不大的打样项目，一个便于执行的团队约定是：基线改变后，用正式OutJob重新生成整套候选交付资料，而不是在旧包里零散补文件。
第四步：每次交付用新目录，别让旧文件“搭便车”
下面这种目录最容易制造混乱：
Output/
├─ 新Gerber.zip
├─ BOM.xlsx
├─ BOM_新.xlsx
├─ 坐标.csv
├─ 坐标_上次能用.csv
└─ 发厂用.zip
每份文件都有保留理由，但接手人无法判断应该选哪一份。
建议每次候选交付建立新目录，例如：
控制板A_样板交付_硬件V1.2_基础版_日期/
├─ 01_裸板制造/
├─ 02_装配资料/
└─ 03_交付清单/
这是目录组织示例，不是软件强制格式。实际应按工厂接收要求调整。
关键只有两点：
- 不要将旧输出目录直接当作本次交付目录；
- 目录名辅助识别，交付清单负责说明来源。
生成完成后，需要重新打开输出文件检查，而不是只看文件是否存在、大小是否非零。
核心步骤：三件套按这三轮对账
第一轮：核对来源与变体
先检查整套资料，而不是立即钻进某个文件。
检查项 | 合格条件 |
|---|---|
来源设计 | 能找到本轮对应的源工程状态 |
输出配置 | 能说明采用哪份配置生成 |
装配变体 | BOM、坐标及装配说明对应同一目标 |
输出目录 | 没有混入其他交付批次的文件 |
资料范围 | 覆盖接收方要求的文件集合 |
对于共用裸板、不同装配的产品，应说明裸板资料与各套装配资料的关系。
不能把基础版文件复制后改名为增强版，就当作完成变体输出。文件名改变不会改变内部内容。
第二轮：按位号核对装配对象
以本次目标变体为准，对照BOM、坐标文件和装配图：
- 本次应装器件是否被正确表达；
- 不装件是否按约定处理；
- 本轮变更器件是否体现了正确型号、位置和方向；
- 没有进入坐标文件的对象是否有合理解释。
建议把BOM中合并的位号展开后再核对，而不是直接比较文件行数。
例如，一行BOM写着：
- 位号：R1、R2、R3、R4
- 数量：4
坐标文件中则可能是四条独立记录。两份文件行数不同，并不表示存在错误。
同样，机械件、手工装配件或约定由工厂另行处理的对象，可能不会进入贴片坐标文件。目标是让装配对象之间的关系能够解释，而不是强求所有文件行数相等。
可以建立这样一张对照表：
位号或对象 | 本次装配要求 | BOM检查 | 坐标文件检查 | 其他说明 |
|---|---|---|---|---|
J2 | 装配，本轮旋转180° | 型号与数量正确 | 核对位置、装配面和方向 | 装配图标明接口朝向 |
U3 | 装配，采用已批准的新型号 | 完整型号已更新 | 核对位置与封装方向 | 保留换料依据 |
D5 | 基础版不装 | 按约定排除或标记不装 | 按约定处理，不产生误贴装指令 | 装配说明明确标注 |
机械附件 | 按装配要求处理 | 按约定列出 | 不适用时说明原因 | 由对应工序处理 |
以上为检查示例。实际是否输出不装件、怎样标记以及哪些对象进入坐标文件，应与接收方约定一致。
用Excel也能先做一轮辅助核对
以下是一个通用的人工检查方法，不是软件自动提供的制造放行结论：
- 将本次应装器件整理为“一行一个位号”；
- 将坐标文件中的位号整理到另一张表；
- 使用查找或计数功能，找出只出现在一侧的位号；
- 单独检查重复位号；
- 对差异逐项写明原因。
比如，可用下面的公式辅助检查某个位号是否出现在坐标清单中：=COUNTIF(坐标清单!A:A,A2)
假设两张表的A列均为位号：
- 返回
0：坐标清单中未找到，需要核查； - 返回
1：找到一条记录，但仍需检查位置、装配面和方向； - 返回大于
1：需要检查重复记录或文件组织方式。
位号存在，只能证明找到了对应记录，不能证明这条记录的内容正确。
如果是拼板交付，还应先与工厂明确坐标文件对应单板还是拼板，不能直接套用单板的数量与重复位号判断。
第三轮：围绕本次修改，核对实际输出
整套资料的来源和装配对象对上以后，还要回到本轮修改清单。
对前面的示例，至少完成三项检查：
1. J2旋转：检查设计与装配输出是否一致
- 在PCB中确认最终位置和方向；
- 在坐标文件中找到J2，核对装配面与方向约定；
- 在装配图中确认接口朝向；
- 必要时与贴片厂确认其对该封装旋转值的解释。
不要仅凭坐标文件里出现了“180”就判定正确。
2. U3换型号：检查BOM是否真正变化
- 制造商与完整型号是否更新；
- 是否仍残留旧型号；
- 输出模板是否引用了正确字段；
- 若允许多个采购选择，批准范围是否表达清楚。
同封装换料可能不引起Gerber变化，因此不能用“Gerber与上一版相同”证明BOM也无需更新。
3. D5不装：检查变体是否传递到装配资料
- 本轮是否选择了基础版；
- BOM中的不装状态是否符合工厂要求；
- 坐标文件是否采用了相应处理方式；
- 装配图和交付清单是否明确标注。
变体影响的不只是文件名，而是实际装配要求。
Gerber和钻孔资料仍要单独打开检查
重点包括：
- 层集合是否完整；
- 板框是否正确；
- 孔信息是否符合要求；
- 本轮修改区域的关键图形是否符合预期。
如果使用Gerber比较，还应先确认层映射、单位、坐标和文件集合具有可比性。输出配置不同，也可能产生大量差异，不能全部归因于设计修改。
对不上时，先查来源，不要急着手改输出文件
发现问题后，最方便的处理往往是直接改Excel或坐标文件。
但如果没有同步修正源数据或输出配置，下一次重新生成，同样的问题还会回来。
建议按以下顺序排查：
发现的问题 | 优先检查 |
|---|---|
BOM仍是旧型号 | 源参数、输出字段映射、所选变体、是否打开了旧文件 |
坐标方向与PCB不一致 | 来源版本、装配面、封装方向及工厂旋转约定 |
BOM有位号，坐标没有 | 不装设置、输出范围、器件装配方式及例外约定 |
两套资料对应不同变体 | 各输出的变体设置与生成过程 |
Gerber出现大量意外差异 | 层映射、单位、原点及输出配置 |
输出目录同时存在多份同类文件 | 是否混入历史输出，正式交付集合是否唯一 |
先定位源数据、配置或理解方式上的问题，再重新生成和检查。
如果接收方确实要求对导出结果进行转换或后处理，应把它作为明确步骤记录下来，保留原始输出、处理规则和检查结果，而不是依赖某个人临时修改。
发厂前可直接使用的交付检查表
建议将下面的表复制到项目交付记录中。每项填写“通过”“不适用”或“待处理”，待处理项必须说明负责人和下一步。
类别 | 检查内容 | 结果与依据 |
|---|---|---|
来源 | 已记录源工程状态或提交、发布标识 | 待填写 |
来源 | 已记录硬件版本及装配变体 | 待填写 |
配置 | 已确认正式OutJob及本轮配置 | 待填写 |
设计 | 已完成规定的同步检查、ERC、DRC及人工复核 | 待填写 |
裸板资料 | 已检查Gerber层集合、板框及关键图形 | 待填写 |
钻孔资料 | 已检查孔信息与制造要求 | 待填写 |
BOM | 完整型号、数量、位号及不装件表达正确 | 待填写 |
坐标文件 | 单位、原点、装配面及旋转约定已核对 | 待填写 |
交叉核对 | BOM与坐标中的装配对象能够对应，例外已说明 | 待填写 |
装配图 | 极性、1脚、连接器方向及特殊说明清楚 | 待填写 |
目录 | 本次资料未混入其他批次文件 | 待填写 |
交付 | 用途、接收方及是否替代前次资料已写明 | 待填写 |
归档 | 已保留实际发送的交付包及接收依据 | 待填写 |
这份表是建议的团队检查模板，不表示Altium Develop会自动完成其中所有检查或强制审批。工具能帮助组织数据，制造与装配判断仍需对应证据。
免费试用30天链接
发出去不算结束：让工厂确认“收到哪版、用在哪批”
很多交付问题不发生在生成阶段，而发生在修改之后。
例如，上午发送完整资料，下午发现BOM需要调整，于是又单独发了一份Excel：
“BOM用这个。”
如果没有说明哪份旧文件作废、其他资料是否仍然有效，接收方就需要自行拼接交付包。
更稳妥的做法是：发送时明确用途、版本、替代关系，并请接收方确认；归档时保留实际发出的包，而不只是源工程。
可以直接使用的交付说明
交付项目：控制板A
硬件版本：V1.2
装配变体：基础版
本次用途：样板制造与装配
交付包标识：填写实际文件名或交付编号
源设计依据：填写实际提交、发布标识或归档依据本轮主要变化：
1. J2方向调整；
2. U3采用已批准的新型号；
3. D5在基础版不装。与前次资料的关系：
本交付包替代前次指定资料包，请勿混用。
请填写被替代资料的具体标识。需要特别确认：
1. 坐标单位、原点及方向约定；
2. D5不装要求；
3. 如旧资料已进入备料或生产，请先反馈当前状态。请确认：
收到的交付包标识、拟采用的订单或批次，以及尚需澄清的问题。
Altium Develop在这里真正帮什么？
免费试用30天链接
这套方法即使从本地文件开始，也有价值。
但当项目持续迭代、多人参与时，还会遇到三个问题：
- 这份交付包对应哪一个设计状态？
- 本轮修改为什么发生？
- 后续问题能否回到当时的资料，而不是只看到最新设计？
这正是评估Altium Develop相关工作区能力时值得关注的地方：把设计来源、修改记录和交付反馈连接起来，让一份资料更容易解释和复现。
需要区分不同环节：
环节 | 可以帮助解决的问题 | 不能直接替代的判断 |
|---|---|---|
OutJob | 固定重复输出配置 | 配置是否满足工厂要求 |
项目历史 | 追踪设计状态与修改原因 | 哪个状态已经获准生产 |
项目发布 | 在支持环境中关联选定设计状态与输出 | 制造、装配和测试是否合格 |
工作区反馈 | 在可用能力范围内保留讨论与处理依据 | 正式签核和生产切换责任 |
OutJob属于设计端输出配置能力，不应简单等同于注册工作区后即可使用的全部功能。
如果当前环境具备Project Releaser，可按对应流程将输出与设计状态关联；没有这项能力时，本地交付包也应保留清楚的来源记录。完整项目历史同样具有版本控制方式等前提，不能把“文件在云端”直接等同于“具备完整追溯”。
第一次试用：别先迁移所有项目，先完成一次测试交付
如果你正在评估Altium Develop，可以先用一个非敏感测试项目完成以下任务：
- 建立一个明确的设计基线；
- 配置并保存正式OutJob；
- 从同一设计状态生成制造与装配资料；
- 按本文方法完成三件套对账；
- 通过当前可用的工作区方式保留来源与反馈；
- 请另一位同事独立查找本次交付依据。
让同事尝试回答三个问题：
这套资料从哪一版生成？
本次生产哪个装配变体？
为什么确认J2、U3和D5的输出符合本轮要求？
如果不需要重新找聊天记录、也不需要你逐个解释文件，这次测试就有了可判断的结果。
准备尝试时，可通过Altium Develop中国区官方渠道确认当前注册与试用方式，以及设计端输出、项目历史、发布和分享能力的具体条件。先确认能完成这项任务，再进入实际验证。
免费试用30天链接
写在最后：别只问“导出了吗”，要问“对上了吗”
PCB发厂前，真正需要确认的不是“Gerber、BOM、坐标文件都在”。
而是：
- 它们是否来自明确的设计状态；
- 是否对应正确的装配变体；
- 本轮变化是否体现在相应输出中；
- 不一致之处是否有合理、可追查的说明；
- 工厂是否知道本次采用哪套资料。
可以把整个流程记成一句话：
先定基线，再按配置输出；逐项对账，成套交付，保留回执。
你交给工厂的，不应该只是一个装满文件的压缩包，而应该是一套来源清楚、内容相符、用途明确的制造与装配依据。
免费试用30天链接
