做了这么多年硬件我始终对一件事耿耿于怀每逢项目后期大把时间被PCB布线吞掉。手动拉线结果可控但枯燥又费人传统自动布线器在简单双面板上确实省事一旦遇到高速信号、差分对、BGA扇出它的“自动”立刻变成“自动添堵”。前几天在Hacker News上看到CircuitPilot这个项目——用物理引擎physics engine给PCB做自动布线auto-route并且把LLM拉进来参与决策第一反应是“又一个噱头”点进去认真看了设计思路之后我觉得这个方向值得好好拆一拆。这篇文章我想聊清楚三件事传统布线器到底死在哪儿、物理引擎凭什么能在这个场景里翻身、LLM在里面扮演的又是什么角色。不管你是硬件工程师、EDA工具开发者还是做AI应用落地的朋友这套“LLM解析约束 物理引擎生成路径”的组合都有不少值得拿走的东西。1. 先想想传统自动布线器到底死在哪1.1 “迷宫搜索”的困局走一步看一步传统自动布线器的底层核心绝大多数是迷宫布线Lee算法及其变体。它的思路很直白把PCB板面划成网格从信号源点开始一圈一圈往外扩散碰到终点之后按来路回溯于是得到一条最短路径。在只有一两个网络的年代这个算法堪称完美——它保证了连通性也保证了长度最优。问题出在多网络协同布线的时候。这套算法本质上是“走一步看一步”它只知道现在这个网络怎么走最短完全不知道后面还有几十个网络等着排队。前面网络留下了“漂亮”的最短路径很可能把后面网络的最佳通道彻底堵死。这就是为什么老式自动布线器在简单电路上表现尚可一旦网络数量上来布线结果就变成一团乱麻。打个比方迷宫算法像一个只看脚下的外卖小哥他总能找到最短的楼间小路但小路被他占了之后身后的同行全得绕远路。整个配送系统最后谁都没效率。1.2 真实PCB的约束根本不是“找路”更重要的是真实PCB的约束远远不是“两点之间能不能连通”这么简单。一块量产板子上同时压着好几类规则高速差分对要求等长误差控制在±5 mil以内且两条线必须尽量平行敏感时钟线要远离大电流开关电源区域避免串扰BGA扇出区要按特定逃逸方向布线不能横冲直撞禁布区域器件下方、螺丝孔附近、拼板边沿物理上不可进入走线拐角要是45°或圆弧不能出现锐角否则生产良率受影响。传统算法面对这些规则标准做法是给网格单元赋权重禁布区权重设无穷大等长约束简化成“尽量走蛇形线”差分对约束干脆留到后期人工调整。权重一多计算量指数级膨胀而且很多约束之间的优先级冲突权重根本表达不了。到这一步行业里大量布线工作仍然依赖人工原因不是工程师守旧而是工具真的接不住这些约束。1.3 破局点物理直觉正好针对“全局博弈”物理世界有个很妙的特性系统会自发趋向能量最低状态。你把一堆橡皮筋拴在几个桩子之间松手它们会自动找到一个稳定的受力平衡位置——没有任何中央规划但每个橡皮筋都恰到好处。这在形态上天然就适合处理“多网络互相制约”的布线问题。CircuitPilot让我眼前一亮的地方就在这里它没有沿着“改进寻路算法”的老路走而是换了个赛道把布线问题构造成一个物理模拟场景。禁布区是斥力源目标引脚是引力源走线是一串带弹簧连接的质点规则被翻译成各种力。系统迭代之后收敛出来的结果就是满足约束的走线路径。这个思路不是“找一个解”而是“让系统松弛出一个解”天然具备全局视野。2. 物理引擎如何把“布线规则”翻译成“受力运动”2.1 从网格搜索到势场梯度走线变成“下山”的过程理解了方向接下来看具体怎么做。假设我们要在板面上布一条从A点到B点的线物理引擎的做法不是搜索路径而是建立一个势能场。目标点B处放一个“引力谷底”板框边界、器件占位、禁布区都作为“斥力山峰”。然后我们模拟一个粒子从A点出发粒子受到合力 F -∇U 驱动这里的 U 就是坐标点上的势能值。粒子沿着合力方向不断移动最终滑进目标谷底。用公式表达每次迭代可以近似为粒子所受合力 F F_attract F_repulse F_spring F_damp速度更新 v_{t1} v_t (F / m) * dt位置更新 x_{t1} x_t v_{t1} * dt这一步的本质是把“路径搜索”变成“路径松弛”。粒子不需要知道整个地图的拓扑结构它只感知周围梯度但多个粒子同时在场上运动时力场会逼着它们自动互相避让。传统迷宫算法是单线程思维势场法是全局并行博弈这是两代方法论的分水岭。2.2 质点-弹簧-斥力用“橡皮筋”表达等长和间距势场解决了“避障寻路”的问题但等长、间距这类约束还得另想办法。物理引擎在这里的杀手锏是质点-弹簧系统。做法是把一条走线离散成一条“质点链”一串小质点相邻质点之间用弹簧连接。弹簧会尽量保持自然长度所以质点链天然有“拉直”的倾向。这正好对应了“走线不要乱弯”的设计习惯。在此基础上等长约束把需要等长的几条网络加载弹簧约束。物理引擎里有专门的弹簧-阻尼器可以让两条质点链的总长度被一个虚拟弹簧拉齐误差收敛到给定阈值。差分对间距两条并行的质点链之间加入横向弹簧距离太远拉回来距离太近推开保证两线始终平行且间距一致。禁布区和器件占位每个障碍物都被填充成斥力源。距离越近排斥力越大理想情况下按 1/d² 增强。这就是物理引擎版的“敬畏之心”。我在实际推演中比较喜欢用“橡皮筋图钉”来给非物理背景的朋友解释把板子当成一块钉满图钉的软木板图钉是障碍物然后用橡皮筋把各个引脚之间连起来松手后橡皮筋会绕过图钉、自动找平衡。物理引擎做的事就是把这张“橡皮筋平衡图”高速迭代出来。2.3 引擎选型不是越重越好既然叫物理引擎很多人第一反应是Box2D、Chipmunk、PhysX这类现成库。但真实做下来会发现直接套用刚体引擎并不顺手。原因很简单刚体引擎的设计目标是模拟不可变形的物体刚体而走线是柔性体你需要的是质点、弹簧、阻尼器这套“软体”模拟能力外加高效的碰撞检测。Box2D虽然有弹簧关节但是大量质点链的稳定性、不同约束的优先级管理做起来非常别扭。更合理的路径是自己实现一个轻量的质点-弹簧系统或者只借用刚体引擎中的宽相位碰撞检测部分核心的势场求导和弹簧解算自己写。理由有三点布线求解需要精确控制每个质点的受力权重自研解算器可以针对“等长”“间距”这类指标直接做归一化权重现成引擎里没人给你留这个口子物理引擎的迭代步长、阻尼系数在游戏里追求“看起来真实”在布线里要的是“快速收敛且不反弹”两者参数哲学完全不同布线场景动辄上千质点现成引擎的通用求解器为了鲁棒会牺牲速度自研系统反而可以做空间哈希加速只计算邻近质点之间的力复杂度从O(N²)降到O(N)。所以看到“We built a physics engine”这句话我一点都不意外。这个场景确实值得自己造一个专属引擎。3. LLM在里面不是画线的而是当翻译和指挥官3.1 把坐标交给LLM是灾难外行看到“用LLM做PCB布线”第一反应往往是“让AI生成坐标路径”。凡是做过工程落地的人听到这个想法就头大。LLM的数学能力、绝对坐标精度、复现稳定性全都不适合干这种像素级精确的几何活。让它生成“从(100,200)绕到(350, 180)再到(500, 320)”这种路径大概率结果是一堆非法几何图形而且每次跑结果都不一样完全不可控。CircuitPilot如果真走这条路根本撑不到在Hacker News上发布。它真正的聪明之处是把LLM放在了“约束理解与策略决策”层——LLM不直接造几何它分析人话、识别规则、生成结构化配置再由确定性代码编译成物理引擎的参数。这个分工是非常清晰的。3.2 一条自然语言约束的完整“翻译”过程举个例子你在板上看到U3和U4之间的差分对信号质量不行想让它重新布于是输入“U3和U4这对差分信号走顶层等长误差控制在±5 mil尽量别靠近时钟振荡器CK1。”LLM要做的是把这句话拆成结构化指令。合理的设计是输出类似这样的JSON{ nets: [DIFF_P, DIFF_N], layer: TOP, rules: [ {type: length_match, tolerance_mil: 5}, {type: clearance_from_obstacle, ref: CK1, clearance_mil: 25} ], optimize: length }这段JSON再由规则引擎编译成物理场景参数从网表里找出DIFF_P和DIFF_N的起点终点坐标生成两条平行质点链加载等长弹簧误差设定在±5 mil对应弹簧刚度系数取一个经过标定的值把CK1器件转化为半径25 mil的斥力源周围走线自动绕开优化目标设为“长度最短”对应引力势场的全局权重调高。这一整套流程LLM只负责“听懂人话并翻译”真正干苦力活的是物理引擎。这和我做AI辅助工具的经验完全一致语义理解是LLM的强项数值计算和几何求解是传统算法的强项两者结合才能做出能落地的产品。3.3 LLM会失误所以必须配“规则校验层”接入LLM之后很快就会遇到它的三大经典故障幻觉、漏读、误读。幻觉是它编造不存在的网络名或器件编号漏读是它忽略了你明显提到的某个约束误读则是把单位搞错mil和mm混为一谈或者把约束对象张冠李戴。解决思路不能靠“让LLM更努力”而要在LLM和物理引擎之间加一个确定性校验层。所有解析出来的规则先跑一遍合法性检查引用的网络名、封装位号是否真实存在于网表/板文件中单位是否统一数值范围是否物理合理比如等长误差5 mil合理500 mil就要报警不同规则之间是否冲突比如同时要求严格等长和绝对最短两者本身存在矛盾需要提示用户做优先级选择。校验不通过就直接打回让LLM重新解析或者交给用户确认。这一步看似笨拙却是整个系统稳定的基石。我在做类似AI辅助工具时的经验是LLM给出的是“建议”校验器给出的才是“约束”两者缺一不可。4. 工程实现管线与几个埋雷点4.1 从板文件到物理场景的完整数据流理解了角色分工再看整条工程管线。完整的流程大致如下输入解析读取EDA文件KiCad的.brd/.kicad_pcb、Specctra DSN、Gerber等解析出板框多边形、器件占位、网络连接关系、已有铜皮。规则理解LLM接收自然语言约束输出结构化JSON规则。校验编译校验JSON规则编译成物理引擎可执行的“势场弹簧阻尼”配置。场景构建把板框转为碰撞边界器件占位转为圆形/矩形斥力体禁布区转为斥力场源每个待布线网络生成初始质点链。物理求解迭代运行力的计算和位置的更新直到收敛或达到最大迭代次数。后处理对质点链做合法性过滤、拐角角度规整把任意角度修正为45°/90°、等长误差复核最终输出标准EDA可导入的走线数据。这套流程和传统自动布线器最大的不同在于传统工具是“用户给一个笼统的目标程序按内置规则办”CircuitPilot是“人类用自然语言描述意图系统自动翻译成物理约束再求解”。两种模式在灵活性上完全不在一个层级。4.2 核心求解循环伪代码物理求解是管线的心脏。我把核心循环简化出来方便理解for iteration in range(max_iterations): for each_particle in chain: # 1. 目标引力粒子被拽向目标引脚 f_attract k_attract * (target_pos - particle.pos) # 2. 障碍物斥力越近越强 f_repulse sum(k_repulse / dist_sq for obstacle in nearby_obstacles) # 3. 弹簧约束维持相邻质点间距、等长/并行关系 f_spring spring_force(particle, neighbors) # 4. 阻尼防止震荡让系统稳定下来 f_damp -k_damp * particle.velocity total_force f_attract f_repulse f_spring f_damp particle.velocity total_force / mass * dt particle.pos particle.velocity * dt这里有个工程细节值得展开为什么要单独加阻尼项因为纯弹性系统在迭代中会出现来回震荡弹簧被拉过头就往回弹、弹回去又拉过头形成永无止境的抖动。加入速度阻尼之后系统才会像浸在蜂蜜里一样稳稳地收敛到平衡态。从我调试经验看阻尼系数取临界阻尼附近值时收敛速度最快跑偏风险也最低。另外迭代策略还可以配合“温度退火”前期引导力权重调大让粒子快速接近目标后期约束力权重逐渐增加让粒子在局部微调间距和等长。这种思路和模拟退火是相通的实操中能明显改善结果质量。4.3 几个容易被忽视的工程雷区粒子密度质点链的取样间距很关键。间距太疏走线拐弯会异常生硬等长约束也调不准间距太密计算量陡增内存占用吓人。我见过有人踩坑一上来就把间距设到0.1 mil结果一个网络几百个质点整块板几千个网络求解器直接内存溢出。合理的起点是先按1 mil或2 mil设置再根据结果微调。层切换和过孔物理引擎天然在二维平面上工作遇到需要换层引出的信号得在过孔位置设置“势阱”让粒子主动经过这个点否则路径不会自然产生过孔。这里还要额外处理过孔间距规则复杂度会再上一个台阶。后处理角度规整物理引擎产出的路径是任意角度的而PCB制造通常要求45°或90°拐角。这个后处理很考验工程能力它不只是“把角度吸附到45°倍数”还要保证吸附之后不产生短路、不闯入禁布区。我可以说这是整个管线中“看似简单实际最磨人”的环节之一。收敛判断不能只看总力大小因为可能有局部极小值。要同时检查所有网络是否到达目标点、是否满足最小间距、是否满足等长误差。我建议把合法性检查放在每N次迭代之后跑一次不要放到最后一次性做否则出了问题还得从头跑。5. 实测效果、翻车现场和我的判断5.1 跑得顺的场景约束稀疏的板子从公开Demo和同类方案的效果来看物理引擎LLM的这套方案表现最好的是低到中等密度的双面板网络数量几百个量级高速约束不多。这类板子约束稀疏物理引擎自由度高的优势能完全发挥连通率高、走线自然、不需要人工干预的比率相当可观。传统自动布线器在这种板子上也不是不能用但遇到不规则板框、多禁布区的时候物理引擎绕障的灵活性明显更胜一筹。5.2 翻车现场高密度与严苛物理约束真正残酷的考验在高端板卡上翻车场景我也逐个复现过高密度BGA扇出BGA下面的引脚排列太密粒子链之间互相排斥“谁都挤不进中间通道”最终绕出一堆不合理的“S”形路径PCB LVS还查不出来肉眼一看惨不忍睹。严格差分等长差分对要求两条线严格平行同时两对之间又要拉开间距多个差分对挤在一起时弹簧系统的收敛速度极慢迭代几千次误差还是超过5 mil。工艺敏感约束板上已有大量45°走线物理引擎新产出的路径会打乱原有布线风格而且很容易在贴片器件焊盘附近生成锐角被生产部门直接打回来。这些翻车现场不是工程实现粗糙而是方法本身的当前天花板物理模拟擅长处理“软约束”但面对高密度下的“硬冲突”比如空间根本不够必须牺牲某条规则它缺乏人类工程师那种“踩下刹车、做优先级取舍”的决策能力。这时候LLM倒是可以通过解析更高层的设计意图来补位但整体成熟度还没到量产级别。5.3 和同类方案对比它现在更适合当“副驾”我把这套方案和市面上的主流路线放到一张表里看会更清楚方案相对优势明显短板适合场景传统迷宫自动布线稳定、速度快、结果可预期多网络交互时容易堵塞、复杂约束处理弱简单双面板、单网络布线商用专业布线器Specctra/ Allegro等支持高速差分对、等长、阻抗规则完善需要人工预设大量规则和通道学习成本高高速数字板、多层复杂板物理引擎LLM方案语义理解能力强、约束表达灵活、全局博弈高密度场景收敛难、角度后处理不成熟、实测样本少早期概念阶段、快速迭代、规则变化频繁的设计从这张表可以看出CircuitPilot目前的目标不应该是“替代资深工程师”也不该是完全替代商用专业布线器而应该是“把约束翻译成本和初期布线时间压到最低”。我自己判断这套方案在EDA领域最有价值的切入点是半自动协作工程师用自然语言把规则告诉系统系统快速跑出一版可用的物理布线雏形工程师再在高风险网络上做精细调整和最终裁决。比起从零开始手拉线这个效率提升是实实在在的。我个人在实际项目里试过类似思路之后最深的体会是这类方法的真正价值不在于某一版布线结果有多惊艳而在于它把“约束传递”这件事自动化了。过去是工程师把一本规则手册里的每一条翻译成手动操作现在是LLM做翻译、物理引擎做演算、工程师做最后裁判。如果未来能把物理求解换成更高精度的电磁场/热场模型再把LLM解析错误的样本收集起来做定向微调这个方向的想象空间还会再大一截。至少我现在看自动布线已经不会再想“为什么不能有个AI帮我想全局”了——物理引擎加LLM的组合正是在往这个方向一点一点靠近。