让约束进入执行链路：AI PCB 设计中的校验与制造输出

AI 能生成电路描述、选择元器件并调用工具后，一个自然的问题是：它离可以制造的 PCB 还有多远？这个问题不能只看预览是否像一块电路板，也不能只看工具是否成功返回一个 ZIP。

在阅读与核查 Agentic EDA 的过程中，我更关注要求有没有进入实际执行链路。文档里写了最小线宽，配置对象也有这个字段，但如果生成器、布线器和验证器都没有使用它，这条规则就还没有形成工程保障。

本文讨论这种核查方法，并结合当前阅读到的制造导出路径说明边界。早期任务中的集成缺口属于历史快照，不能直接当作项目今天的状态。文中的规则值与电路场景均为合成示例，不构成实际投板参数。

从规划建议走向确定性检查

提示词适合表达意图，例如“优先使用易采购器件”“把去耦电容放在电源引脚附近”。模型可以据此规划，但自然语言本身无法证明最终布局已经满足要求。

一个更完整的执行链可以表示为：

需求与约束 → 器件候选 → 电路描述 → 布局 / 布线
                                      ↓
                             电气与几何检查
                                      ↓
设计快照 ───────────────────────→ 制造导出前复核

软性要求负责引导选择，确定性检查负责给出可重复的判定。两者可以互补：模型解释为什么选择某个方案，工具报告哪些规则满足、哪些违规、哪些还没有能力检查。

“没有发现错误”还要说明检查覆盖了什么。如果检查器只处理几何间距，就不能把它的通过描述为完整电气验证或制造认可。

沿着规则追踪消费者

我会选一条规则，查它如何进入每个环节，而不只是搜索字段是否存在。例如最小间距涉及配置读取、生成工具参数、布线器转换、几何检查和报告展示。

环节	需要追踪的问题
配置	单位、默认值、来源和版本是否明确
生成	工具是否读取了该值，还是继续使用硬编码
布线	转成外部格式时是否遗漏或改变单位
验证	是否对实际输出检查，违规能否定位
导出	是否复用同一快照与约束，失败能否阻止输出

作为设计示意，可以让一次运行携带一份约束对象：

// 仅为演示数值；实际值应来自选定厂商、工艺和项目要求。
const constraints = {
  version: 'demo-rules-1',
  unit: 'mm',
  minTrackWidth: 0.25,
  minClearance: 0.25,
};

这份对象并不会自动让设计合规。每个工具仍需显式消费它，测试也应证明改变规则后输出或校验结果确实变化。若改变配置完全不影响工具行为，就要继续追查规则是否只停留在界面或类型定义中。

器件数据需要对应到实际封装

“找到了合适的芯片”通常只是开始。型号、符号引脚、封装焊盘、供应商编号和装配数据之间，都可能出现不一致。

我会把器件候选和最终选定项分开：候选搜索结果提供参数和来源，选定项需要固定到具体型号与封装，并核对符号到焊盘的映射。采购可用性属于有时效的信息，不应把某次搜索结果永久写成“始终有货”。

对缺少料号、封装不明确或映射未确认的项，应给出可操作的提示。能生成 BOM 不代表 BOM 已经适合采购，能生成贴片坐标也不代表方向、原点和装配约定都经过核对。

预览与导出使用同一份设计

另一个风险是画面和文件来自不同状态。预览可能显示用户刚刚修改的设计，导出工具却读取旧缓存，最终拿到的 Gerber 就不是正在看的那一版。

一种可继续完善的设计，是为电路数据、约束和工具版本形成明确的运行快照，用摘要关联预览、校验报告与制造文件。预览成功只代表渲染过这份数据；校验结果还需要记录使用了哪些规则、对应哪份快照。

如果导出前发生修改，旧报告应标记为过期或重新执行。仅靠前端按钮变灰不够，导出服务本身也要检查输入和阻断条件。这些快照与版本建议需要结合项目逐项实现，不能从一个摘要字段推断整条链路已经一致。

导出前再检查一次

在当前阅读到的制造模块中，构建制造包时会再次聚合阻断项，包括 DRC 错误、电气、机械，以及铜区域连通相关的问题；存在阻断项时拒绝继续。通过后才生成 Gerber、BOM 与贴片坐标文件，并打包输出。

这比“之前校验按钮显示通过，所以直接导出”更可靠，因为导出入口自己承担了最后一层检查。但它的结论仍限于已实现的检查规则，不能扩展为专业工具的全部 DRC 已通过，也不能替代板厂的工程审核。

导出包还应该在文件层检查预期文件是否齐全、内容是否为空、层命名和坐标是否符合目标流程。必要时使用独立查看器复核 Gerber 与钻孔文件，让检查不要完全依赖同一套生成逻辑。

用固定案例评估整条链路

模型升级后只看几次成功演示，很难知道是否真的改善。更有用的是准备固定任务集：一个可完成的小电路，一个故意包含未连接网络的例子，一个封装映射错误的例子，以及一个违反间距规则的布局。

每次运行分别记录模型规划失败、工具执行失败、规则未通过、基础设施错误和最终产物情况。这样，模型调用被上游拒绝就不会被误算成布线失败；工具顺利结束但仍有违规，也不会被算成设计成功。

对于人工审查，还要记录需要改动的具体项，而不只写“看起来不错”。如果要比较两个版本，任务、规则、预算和工具版本应尽量保持一致，未完成的检查也要单列。

AI 在这里可以帮助缩短规划与操作路径，工程约束则给这些操作提供边界。我更希望项目逐步做到：每一项通过都能说明依据，每一个阻断都能定位原因，每一份制造输出都能追溯到实际检查过的设计。