企业官网建设流程全解析

工厂发来一张照片：

“这批板子的J2方向，怎么和你们今天发的装配图不一样？”

你打开项目目录，发现里面有：

• 控制板_V1.2
• 控制板_V1.2_修改
• 控制板_V1.2_最终版
• 控制板_V1.2_最终版2
• 控制板_V1.2_最终版3_发厂

再翻聊天记录：

“用这版。”

“上一个不要了。”

“BOM更新了，其他不变。”

“等一下，坐标文件也换一下。”

文件都有，消息也在，但你依然不敢回答：工厂到底收到哪套资料？实际生产采用哪套？它对应哪一个源工程状态？

这不是文件名不够长，而是三个不同的对象被混在了一起：

• 研发正在修改的设计；
• 已经发送的交付资料；
• 工厂实际采用的生产资料。

本文就把这三件事拆开，给出一套小团队也能执行的方法：从现有资料中回查交付版本，再用项目历史与交付记录，避免下一次重新翻聊天记录。

一、先明确：你要找的不是“最新版”，而是“本批采用版”

“最新”只能说明时间顺序，不能说明业务用途。

一个项目可能同时存在这些状态：

这是一种建议的团队记录方式，不代表软件中一定存在五个同名状态按钮。

设计的最新状态，可能正在开发新功能；工厂生产的，却可能仍是上一版。

因此，交付必须明确具体版本，而不能只让对方取“最新文件”。

另外还要区分：

“收到”不等于“采用”，“采用”也不等于已经完成整批生产。

涉及在制品或批次切换时，还需结合工厂执行记录确认，不能只依据研发端的一条发送消息。

二、文件名、板面版本、提交标识，为什么都要留？

很多团队已经在板面印了“V1.2”，为什么仍然查不清？

因为它们解决的是不同问题。

板面丝印版本、文件名和仓库提交标识各有用途，不能只保留其中一个。

例如，同封装换料可能不改变PCB铜层，板面仍是V1.2，但BOM已发生变化。只看板面版本，无法判断本批用了哪一个批准型号。

真正需要建立的是这条关系：

订单或批次 → 实际采用的交付包 → 交付包中的输出文件 → 对应源设计状态。

三、已经出问题了？按这五步回查，不要先打开“最新工程”

下面是一套建议的排查顺序。它的重点是先固定证据，再判断设计差异。

第一步：先问清“哪一批、哪一个问题”

至少记录：

• 项目与产品名称；
• 硬件版本、装配变体；
• 订单或批次；
• 具体位号或区域；
• 工厂观察到的现象；
• 发现问题的时间和工序。

不要只记录“J2装反了”。

需要进一步区分：

• PCB焊盘方向有问题？
• 坐标文件方向与工厂约定不一致？
• 装配图标识不清楚？
• 工厂实际执行了旧资料？
• 还是双方观察方向不同？

先把问题落到具体对象和批次，再讨论是哪一版出了问题。

第二步：让工厂回传实际使用的资料

不要先问：

“你们是不是用的最新那版？”

建议改为：

“请回传本批实际使用的交付包或文件清单，包含BOM、坐标和装配说明，并确认对应订单或批次。”

随后与研发归档的实际发送包核对。

原稿建议保留实际发送的资料包，而不只是源工程；发送时还应写明用途、版本及是否替代前次资料，并保留接收依据。

如果当时没有归档，只能从邮件附件、聊天文件、共享目录记录和工厂回传资料中恢复。此时应写明：

• 已找到哪些证据；
• 哪些文件来源仍不确定；
• 哪些结论还不能确认。

不要为了得到一个完整答案，把“推测对应”写成“已经证实”。

第三步：从交付记录找源设计依据

检查交付清单中是否记录：

• 源工程提交或发布标识；
• 项目与硬件版本；
• 装配变体；
• 输出日期；
• 输出配置；
• 接收方及用途。

如果已经建立关联，就可以从交付包回到具体设计状态，而不是靠文件名猜测。

如果没有记录，修改时间只能作为辅助线索，不能单独证明来源。

第四步：打开对应历史状态，检查相关对象

找到源设计后，先检查与问题直接相关的内容：

• J2的方向和引脚定义；
• 相关装配图；
• 坐标输出；
• 本轮修改说明；
• 输出配置是否变化。

必要时比较前后两个明确状态。

不同类型的比较解决不同问题：原理图关注元件与连接等设计语义，PCB关注实现层面的变化，Gerber关注制造输出。不能用一种比较代替全部检查；具体能力也取决于当前环境。

第五步：把原因和下一步分开写

例如：

已确认工厂回传的坐标文件属于前次交付包；研发后续发送了新文件，但未取得该批次切换确认。当前设计中的J2方向已调整。下一步先核对在制品数量和装配状态，再决定返工与后续资料切换方式。

这比一句“工厂用错版本了”更有价值，因为它说明了：

• 已经确认的事实；
• 尚未完成的检查；
• 谁需要继续处理。

四、从今天开始：分清保存、提交与发布

想减少这类追查，先不要急着制定几十页版本规范。把三个动作分清楚就很有帮助。

1. 保存：保留当前工作副本

按下保存，说明本地文件发生了变化。

但它不自动意味着：

• 同事已经能看到；
• 已形成可追踪的仓库状态；
• 已经通过评审；
• 可以用于生产。

2. 提交并推送：形成团队可追踪的设计状态

在受版本控制的工作流程中，提交并推送可以保留一次修改及其说明，为后续定位和比较提供依据。

Altium项目历史可以呈现创建、提交、发布及相关事件。完整项目历史能力要求项目处于工作区原生版本控制管理之下，不能把“文件在云端”和“具备完整版本历史”直接画等号。

免费试用30天链接

3. 发布：关联选定的设计状态与交付数据

发布用于把选定状态与相应输出联系起来，但它仍不等于工厂已经收到或采用。

若当前环境具备Project Releaser，可按对应流程配置项目发布；使用本地输出时，也应保留明确的来源清单和归档包。

可以记成一句话：

保存是保住工作，提交是留下修改依据，发布是组织交付数据，回执是确认交接结果。

五、提交说明别写“改一下”：写清对象、原因和影响

版本历史有没有用，很大程度上取决于记录能否让人看懂。

以上为虚构示例，不代表实际项目记录。

可直接使用的提交说明格式

对象：
修改了哪个器件、网络、区域或输出配置。

原因：
对应什么需求、问题或评审结论。

影响：
涉及哪些设计文件和下游资料。

检查：
完成了什么检查，哪些验证仍未完成。

例如：

对象：J2连接器及相关装配说明。
原因：适配已确认的外壳接口方向。
影响：需检查PCB、坐标文件和装配图。
检查：已完成位置与方向复核；样机装配验证待完成。

“待验证”就写待验证，不要为了让记录显得完整而写成“已验证”。

提交最好围绕一个可理解的工作目的组织。不要把接口修改和无关的大规模改名混在一起，也不必每移动一次对象就创建一条冗长记录。

六、一张交付记录，把源设计和工厂用版连起来

下面是建议模板，可使用当前可用的项目记录或外部清单维护，不要求软件自动生成全部字段。

发送消息也要写清楚

项目：控制板A
硬件版本：V1.2
装配变体：基础版
用途：本次样板制造与装配

请使用本次交付包，包标识以附件名称为准。
本包替代前次指定交付包，请勿混用文件。

请确认：
1. 收到的交付包标识；
2. 拟采用的订单或批次；
3. 旧资料是否已进入备料或生产；
4. 是否存在需要澄清的问题。

这是说明格式示例，实际发送前应填入具体标识。

如果只是补充说明而不替换原包，也要明确补充内容与适用范围。不能让接收方自行决定哪些新旧文件应该拼在一起。

七、旧项目想纳入工作区，先用副本验证

如果目前主要依赖本地目录，可以从一个项目开始，不必一次迁移全部历史设计。

Altium提供Make Project Available Online路径，将现有项目放入工作区，并按项目状态选择版本控制方式。但Simple Sync与原生Git管理的功能和协作条件不同，应先确认采用哪种方式。

迁移前先做四件事

1. 保留原始项目；
2. 列出库、输出模板与外部文件等依赖；
3. 确认现有版本库的管理责任；
4. 明确试用项目和正式项目的边界。

已有外部Git或SVN的团队，不要为了试用直接删除原关联。先由仓库负责人确认迁移或同步方案。

第一次迁移的验收

• 工程能够正常打开；
• 关键依赖仍可用；
• 项目管理方式明确；
• 浏览器能查看相应内容；
• 能找到一次具体提交及其说明。

“上传成功”只是数据进入了环境，不是版本管理已经建好。

八、找到旧版以后，别立即覆盖当前工程

查到上次交付版本，不代表下一步就是“恢复旧版”。

当前项目中可能已经存在：

• 尚未提交的修改；
• 已经验证的新功能；
• 与采购或制造联动的变化；
• 其他工程师正在进行的工作。

建议先查看历史状态，再在独立工作副本中检查差异。确需重新采用历史设计时，应按团队变更规则形成新的可追踪结果，而不是无记录地覆盖当前文件。

尤其要记住：

恢复源设计，不会自动撤销已经发生的采购、备料和制造动作。

历史功能帮助你找回证据，工程与生产决定仍要结合当前实际状态。

九、Altium Develop真正值得验证的，是“离开原设计者还能不能查清楚”

评估Altium Develop时，不必先统计上传了多少工程、保存了多少文件。

更实际的问题是：

• 同事能否找到指定的设计状态？
• 能否理解一次修改的原因？
• 能否把交付包与源设计关联起来？
• 原设计者不在时，其他人能否继续追查？

在适用的工作区和版本控制条件下，项目历史可以为这些任务提供基础；发布与交付记录则进一步连接设计状态和输出资料。具体中国区功能与授权，需要按当前环境确认。

工具不能替你判断哪个批次获准生产，也不能自动证明工厂用了哪套文件。但它可以帮助团队减少对“某个人记得”的依赖。

第一次注册试用，就做这一个任务

使用一个非敏感测试项目：

1. 建立一次基线提交；
2. 修改一个明确对象，例如J2方向；
3. 再次提交，写清原因和待检查事项；
4. 生成一套测试交付资料并记录来源；
5. 请另一位同事独立回查。

让对方回答：

修改前后分别是什么状态？
为什么修改？
这套交付资料对应哪次状态？
它是否已经获得实际生产采用确认？

注册或申请试用前，先通过Altium Develop中国区官方渠道确认项目历史、版本控制、发布与分享能力的适用条件。

当这些问题能从记录中得到答案，而不是靠你重新解释，这次试用就已经有了可判断的价值。

免费试用30天链接

在线阶段 1 – 配置服务器发布

发布流程的此阶段用于指定你希望生成的数据类型。可发布的数据项包括：

• Source Data– 源设计的快照。
• Fabrication Data– 制造厂（Fabrication House）用于制作裸板所需的数据。
• Assembly Data for the Base Design (no variations)– 装配厂（Assembly House）依据物料清单（BOM）对裸板进行完整贴装所需的数据，适用于未变体的基础设计。
• Assembly Data for DesignVariant n– 装配厂依据物料清单（BOM）对裸板进行贴装所需的数据，适用于基础设计的Variant n。

装配数据集的数量将对应于基础（无变体）设计，以及为该设计定义的所有检测到的变体。

项目发布流程的阶段 1——配置要包含在发布中的内容（要生成哪些数据）。

在线阶段 2 – 验证项目

当阶段 1 无问题完成后，如果在已分配的 OutJob 文件中检测到一个或多个验证类型报告，则会自动运行发布流程的下一阶段。将运行所有已定义的验证输出生成器（这些生成器定义在分配给正在发布的数据项的 Output Job 文件中）。这包括运行以下任意项：

• Differences Report– 使用比较器判断源文档与 PCB 设计文档是否正确同步。
• Electrical Rules Check– 检查所捕获源设计的电气/制图有效性。
• Design Rules Check– 根据指定的板级设计约束检查 PCB 文档的有效性。
• BOM Checks– 检查源 BOM 文档（*.BomDoc）中与 Design Items 或 Part Choices 相关的潜在违规（如可用）。
• Footprint Comparison Report– 将板上封装与其源库进行比较，确保其为最新且匹配。
• Component State Checking– 检查处于受限状态的元件。作为配置的一部分，您需要为目标 Workspace 中每个当前定义的 Lifecycle Definition 的每个当前定义状态确定要采取的动作：不处理、警告或生成错误。后者将阻止设计发布。此外，运行该检查会生成一个便捷的基于 HTML 的报告，使您可以一目了然地看到哪些设计元件不处于有效状态。
• Environment Configuration Compliance Check– 检查是否仅使用了通过环境配置允许、且可供您所分配角色使用的数据项（如适用）。该检查还可确保所有设计项均来源于 Workspace。

在线阶段 3 – 生成数据

当阶段 2 无问题完成后，会自动运行发布流程的下一阶段。在此阶段，将运行分配给所包含 Data Items 的 OutJob 文件中定义的所有其他输出，以生成要发布到 Workspace 中相关目标 Item 的数据。

与其他阶段一样（但在此阶段更明显，因为运行时间更长），会使用图标来显示生成进度：

在线阶段 4 – 复核数据

在所有验证检查均已通过并生成输出数据后，发布流程的此阶段允许您查看已生成的数据。

在提交发布并将数据上传到 Workspace 之前，请先检查生成的数据，确认一切符合预期。

在线阶段 5 – 上传数据

在上一阶段确认发布后，将自动进入此阶段。该阶段仅显示将数据上传到 Workspace 中相关数据 Item 的修订版的进度。

此阶段仅反映将生成的数据上传到 Workspace 中已链接的 Item-Revisions 的进度。

在线阶段 6 – 执行报告

这是流程的最后阶段，提供发布摘要。

发布的最终报告。

使用导航链接可快速访问包含已发布数据（制造数据、装配数据以及任何自定义数据集）的关联 Item Revision，位置在 Explorer panel 中——这是您进入 Workspace 的入口。

借助Explorer面板，可直接在 Workspace 中查看项目的已发布数据。

就这些——项目发布完成后，您可以直接关闭Release视图。当您将来需要对同一项目重新发布时，Project Releaser可让这一过程快速且轻松，并会自动递增目标 Item-Revisions。

写在最后

“最终版3”并不可怕。真正的问题是：它无法告诉后来的人，这份资料从哪来、发给了谁、用于哪批。

小团队不一定需要复杂流程，但至少应留下四类依据：

1. 源设计状态；
2. 修改原因；
3. 实际发送的资料包；
4. 接收与采用范围。

以后工厂再问“这批到底按哪版做”，你需要的就不再是翻遍文件夹、逐条猜聊天记录，而是一条能够回查的关系：

从批次找到交付包，从交付包找到源设计，从源设计找到修改原因。

这才是PCB版本管理真正需要解决的问题。

免费试用30天链接