企业官网建设流程全解析

1. 原理图编译检查到底在查什么

1.1 从一次“翻车”经历说起

前两年带过一个做工业控制板的小团队，硬件负责人跟我吐槽：板子打样回来，上电之后MCU的复位引脚一直处于不确定状态，查了两天才发现原理图里有个网络标签拼写错了——RESET_MCU写成了REST_MCU，而ERC（Electrical Rule Check，电气规则检查）当时是关着的，编译只跑了默认的Validate，压根没报错。这个坑其实非常典型：很多人把“编译通过”等同于“原理图没问题”，但Altium Designer 22里，编译（Compile）和验证（Validate）是两码事，而真正能揪出电气逻辑错误的，是编译过程中触发的ERC和后续的DCR（Design Rule Check在设计端的对应概念，这里特指设计规则层面的检查）。

所以这篇东西我想把AD22里原理图编译检查这条链路彻底讲清楚：Validate、Compile、ERC、DCR这几个环节各自管什么、怎么配、报错怎么读、坑在哪里。适合已经能画原理图但经常被“编译一堆警告”搞懵的硬件工程师，也适合刚接手别人项目、需要快速判断原理图健康度的朋友。核心关键词就几个：Altium Designer 22、原理图编译检查、Validate、DCR、ERC，下面全部围绕它们展开。

1.2 Validate、Compile、ERC、DCR 四者的关系

先把概念理清楚，不然后面配置全是糊涂账。

• Validate（验证）：AD22里对单个文档或整个工程的“语法级”检查，主要看元件位号是否重复、封装是否缺失、图纸符号是否悬空这类结构性问题。它不深入电气逻辑。
• Compile（编译）：把工程里所有原理图文档合并成一个统一的“编译后文档”（Compiled Document），生成网络表、元件实例、层次结构。编译过程中会顺带跑ERC。
• ERC（Electrical Rule Check）：电气规则检查，是编译的一部分。它检查的是“电气上说不通”的东西，比如输出脚直接接输出脚、电源网络没驱动源、输入脚悬空等。
• DCR：在原理图阶段，DCR通常指设计规则层面的检查，比如网络类（Net Class）是否覆盖、差分对命名是否合规、总线定义是否完整。它比ERC更偏“设计规范”，而不是“电气对错”。

一句话总结：Validate管结构，Compile管整合，ERC管电气逻辑，DCR管设计规范。四者层层递进，缺一个都可能让错误溜到PCB阶段。

提示：很多人只跑Validate就以为完事了，这是最常见的认知误区。Validate通过不代表ERC通过，ERC通过也不代表DCR没问题。

2. 编译前的工程准备与参数配置

2.1 工程结构梳理：别让层次图坑了你

在点编译之前，先确认工程结构是干净的。AD22支持平坦式（Flat）和层次式（Hierarchical）两种原理图组织方式。层次式设计里，如果子图端口（Port）和父图图纸符号（Sheet Symbol）的入口（Entry）没对上，编译时会报一堆“Net not found”或者“Port not matched”。

我的习惯是：编译前先在Projects面板里右键工程，选择“Project Options”，在“Options”标签页确认“Net Identifier Scope”设置正确。平坦式设计一般选“Global”，层次式设计选“Hierarchical”或“Automatic”。这个设置直接决定网络标签的解析范围，选错了会出现“明明连了却报未连接”的诡异现象。

另外，如果工程里有多个原理图文档但只有一个顶层图，务必把顶层图设为“Set as Top-Level Document”，否则编译时可能从错误的根节点开始解析。

2.2 ERC矩阵配置：把误报压下去

ERC的规则配置在“Project Options”的“Error Reporting”标签页，核心是那张“Connection Matrix”（连接矩阵）。矩阵的行和列代表不同的引脚类型（Input、Output、Bidirectional、Passive、Power、Open Collector等），交叉点的颜色代表违规等级：绿色不报、黄色警告、橙色错误、红色致命错误。

默认矩阵非常严格，比如“Output”对“Output”是红色错误，“Passive”对“Passive”是绿色。实际项目里，很多误报来自“Power”类型引脚。比如一个电源网络的驱动源是稳压芯片输出，但如果你把它的引脚类型设成了“Passive”，ERC就会报“Power net has no driver”。

我的经验配置是：

调整矩阵的原则是：只压误报，不压真错。每次改完要记录原因，否则过几个月自己都忘了为什么这么设。

2.3 编译选项里的隐藏开关

“Project Options”的“Options”标签页里有个“Compile”区域，几个关键选项：

• “Compile all sheets”：勾上，确保所有子图都参与编译。
• “Auto-Increment Part Number”：建议关掉，编译时自动改位号会让人抓狂。
• “Allow Ports to Name Nets”：层次式设计里建议勾上，端口名可以直接作为网络名。
• “Netlist Options”：确认“Net Identifier Scope”和前面设的一致。

还有一个容易被忽略的：在“Error Reporting”标签页底部，有个“Report Suppressed Violations”选项。如果你之前手动抑制过某些违规（右键违规项选“Suppress”），勾上这个可以在编译报告里看到被抑制的项，避免“以为修好了其实只是被藏起来了”。

3. 从Validate到Compile的完整实操流程

3.1 第一步：单文档Validate快速排雷

打开任意一张原理图，按快捷键C然后V（或者菜单Project > Validate Document），AD22会对当前文档跑一次Validate。这一步很快，主要看：

• 元件位号是否有重复（比如两个R1）
• 元件是否有封装（Footprint为空会报）
• 图纸符号的入口是否悬空
• 网络标签是否有拼写异常（AD22会做基础拼写检查）

Validate的结果在“Messages”面板里。如果面板没显示，去View > Panels > Messages打开。这里有个技巧：Messages面板右键可以“Clear All”，建议每次Validate前先清空，避免旧消息干扰。

注意：Validate不检查电气逻辑，所以“Output接Output”这种错误在这一步是看不到的。别被“Validate通过”骗了。

3.2 第二步：全工程Compile触发ERC

按C然后C（Project > Compile PCB Project），AD22开始编译整个工程。编译过程中会：

1. 解析所有原理图文档，建立统一的元件和网络数据库。
2. 根据“Net Identifier Scope”合并网络。
3. 跑ERC，按连接矩阵生成违规报告。
4. 生成编译后文档，可以在Navigator面板里浏览。

编译完成后，Messages面板会列出所有违规。每条违规都带一个“跳转”链接，双击可以直接定位到原理图上的具体位置。这个功能非常实用，尤其是大工程里找一根悬空的线。

编译报告里常见的违规类型：

• “Net xxx has no driving source”：网络没有驱动源，通常是电源网络或输入网络。
• “Output Pin connected to Output Pin”：输出对输出，真短路。
• “Input Pin not driven”：输入脚没被驱动，可能悬空。
• “Duplicate Net Names”：网络名重复，可能是不同页用了同名标签但没连在一起。
• “Component has no footprint”：元件缺封装。

3.3 第三步：逐条处理违规的正确姿势

处理违规不是“看到就改”，而是先分类：

第一类：真错误，必须改。比如Output对Output、电源网络无驱动源、元件缺封装。这类问题不改，PCB阶段一定出问题。

第二类：误报，改配置或抑制。比如某些电源脚被设为Passive导致的“无驱动源”，可以改引脚类型，或者在矩阵里把对应组合设为绿色。如果只是个别情况，右键违规项选“Suppress”也可以，但要在“Report Suppressed Violations”里能看到，避免遗忘。

第三类：设计意图，确认后忽略。比如某些测试点故意悬空，ERC报“Input not driven”，确认没问题后可以抑制。

我的习惯是：每处理一条，就在Messages面板里标记一下（右键 > Place Directive或者直接改颜色），处理完再重新编译，直到Messages面板干净。这个过程可能要迭代两三次，但比PCB阶段返工便宜太多。

3.4 第四步：DCR层面的设计规范检查

ERC过了之后，还要看DCR层面的东西。AD22里没有独立的“DCR”按钮，但可以通过以下方式覆盖：

• Net Class检查：在“Project Options”的“Class Generation”里，确认网络类是否按规则生成。比如差分对是否自动归入“Differential Pairs”类。
• 差分对命名：差分对命名要符合_P和_N后缀规则，否则PCB阶段无法自动识别。可以在“Project Options”的“Differential Pairs”里定义命名模板。
• 总线定义：如果用了总线，确认总线成员是否完整。编译后可以在Navigator面板里展开总线看成员。
• Room和区域规则：如果原理图里定义了Room，确认Room的覆盖范围是否正确。

这些检查没有统一的“一键DCR”，但可以在编译后通过Navigator面板和PCB Rules的预览来验证。我的做法是：编译通过后，先在Navigator里把每个网络类展开看一遍，确认没有遗漏的成员，再去PCB阶段。

4. 常见报错速查与排查技巧

4.1 高频报错速查表

4.2 独家避坑技巧

技巧一：用“Compiled Document”反向验证。编译后，在Navigator面板里选“Compiled Document”，可以像看PCB网络一样浏览所有网络和元件。我经常用这个功能检查“以为连了其实没连”的网络——如果某个网络在Navigator里只有一个引脚，那大概率是断的。

技巧二：批量处理位号重复。如果工程里位号重复很多，别一个个改。用“Tools > Annotation > Annotate Schematics Quietly”，AD22会自动重新编号，但要注意先备份，因为这会打乱原有位号。

技巧三：ERC矩阵的“颜色记忆法”。绿色=放行，黄色=警告，橙色=错误，红色=致命。调整时只动橙色和黄色，红色尽量别碰。每次调整后，在工程里建一个ERC_Config_Notes.txt记录改动，团队协作时特别有用。

技巧四：编译前先“Clear All” Messages。这个前面提过，但值得再强调。旧消息不清，新违规会被淹没，尤其是迭代修改时。

技巧五：用“Suppress”要留痕。右键抑制违规后，在“Report Suppressed Violations”里能看到。但更好的做法是加一个“Directive”（放置 > Directive），在原理图上标注“此违规已确认”，这样别人接手时能看到你的判断。

4.3 编译通过后的“最后一公里”

编译通过、Messages干净，不代表可以直接导PCB。还有几件事要做：

1. 重新生成网络表：Design > Netlist For Project > Protel，确认网络表生成无报错。
2. 检查元件位号唯一性：在“Project Options”里跑一次“Annotate”，确认没有重复。
3. 确认封装库路径：在“Components”面板里检查每个元件的封装是否都能找到，避免导PCB时缺封装。
4. 备份编译后文档：编译后的文档包含了所有网络和元件信息，建议另存一份，方便回溯。

5. 把编译检查变成习惯

5.1 团队协作里的编译规范

带团队时，我会要求每个人在提交原理图前必须跑一次完整Compile，并且Messages面板必须干净。为了统一标准，我会在工程模板里预置好ERC矩阵和编译选项，新人直接套用，避免每个人一套配置。

另外，版本控制里只提交原理图源文件，不提交编译后文档（因为可以重新生成）。但编译报告（Messages面板导出为HTML）可以提交，作为设计评审的依据。

5.2 从“被动修错”到“主动预防”

刚开始用AD22时，我也是被Messages面板追着跑，后来慢慢总结出几个预防性习惯：

• 画图时随手设置引脚类型，别等编译时再改。
• 网络标签命名统一规范，比如电源用VCC_3V3、VCC_5V，信号用SPI_MOSI这种前缀。
• 每画完一页就Validate一次，别攒到最后。
• 层次图端口命名和父图Entry严格一致，最好复制粘贴。

这些习惯养成后，编译报错会少一大半，剩下的基本都是真问题，处理起来也快。

5.3 一个真实项目的编译检查记录

拿最近做的一块STM32控制板举例，编译时Messages面板报了17条违规。分类后：

• 真错误3条：两个Output对Output（RS485方向控制脚冲突）、一个电源网络无驱动源（LDO输出脚被设为Passive）。
• 误报9条：全是电源脚类型问题，改矩阵后消失。
• 设计意图5条：测试点悬空，加Directive标注后抑制。

处理完重新编译，Messages干净，导PCB一次成功，没有出现网络丢失或封装缺失。整个过程从编译到干净大概花了40分钟，比PCB阶段返工省了至少两天。

这个记录我留在工程里，下次做类似项目直接参考，效率更高。

提示：编译检查不是“一次性任务”，而是贯穿原理图设计全程的习惯。越早跑，越早发现，越省事。

最后分享一个小技巧：AD22的Messages面板可以导出为HTML报告（右键 > Export），我习惯把每次编译报告存档，项目结束时对比前后差异，能看出设计质量的提升轨迹。这个习惯坚持了三年，现在团队里新人入职第一课就是学看编译报告。