LLM 与 PCB 布线结合是这几年电子设计自动化EDA领域很受关注的方向。很多人第一反应是“大模型怎么可能画电路板”但看到“LLM PCB Routing”这类项目后会发现LLM 真正参与的不是替代布线引擎而是把资深工程师脑子里的经验、规则、判断方式沉淀下来变成可以检索、可以问答、可以辅助决策的知识系统。这篇文章会围绕“LLM 教会 PCB 布线”这个主题拆解里面最关键的几个问题LLM 在 PCB 布线里到底能做什么不能做什么。怎么把合约工程师Contract Engineer的经验变成 LLM 可用的知识。一套从零搭建 LLM PCB 辅助工具的完整思路。PCB 布线中“经验规则”如何用提示词、知识库、Agent 等方式落地。哪些坑是实际做的时候一定会遇到的。不管你是做硬件开发、PCB Layout还是对大模型应用感兴趣这篇内容都可以给你一个比较完整的参考路径。1. 背景为什么 LLM 会出现在 PCB 布线领域1.1 传统 PCB 布线的真实痛点PCB 布线也就是 PCB Routing是从原理图到生产文件之间最耗时、最依赖经验的环节。很多人以为布线就是“把线连上”但实际做过 Layout 的人会很清楚这里面有大量约束和取舍信号完整性高速信号线需要控制阻抗、避免跨分割、保证回流路径。电源完整性电源平面分布、去耦电容位置、过孔数量。工艺限制线宽线距、过孔大小、器件间距、组装可行性。可制造性拼板、工艺边、Mark 点、散热设计。成本控制板层数量、过孔类型、板材等级。EDA 工具里的自动布线器可以解决“连通性”问题但很难解决“布得好不好”的问题。真正决定一块板子能不能稳定工作、能不能顺利量产的往往是工程师脑子里那些“说不清但很重要”的经验。1.2 合约工程师经验的价值与流失风险很多公司做项目时会聘请合约工程师Contract Engineer也就是按项目周期雇佣的资深 Layout 工程师。这类工程师经验丰富但项目结束后经验也随之流失。新项目来了团队可能又要从头摸索。这篇文章标题 “What the Contract Engineer Taught It” 想表达的核心思想就是把合约工程师在项目中的判断逻辑、布线习惯、问题处理方式记录下来用 LLM 来学习、检索和应用让个人经验变成团队可复用的知识资产。LLM 的强项不是计算也不是几何优化而是理解和生成自然语言。它特别适合处理“经验类知识”。1.3 LLM 在 EDA 中的定位在 EDA 领域LLM 不是用来替代布线引擎的。更合理的定位是辅助设计决策根据约束条件、器件手册、历史项目经验生成布线建议。知识问答设计师遇到问题可以直接问“这个电源模块的输入输出电容怎么摆”“DDR 走线等长怎么约束”。规则解释与生成把自然语言描述转成 EDA 工具的约束规则。评审辅助自动检查设计文件中可能存在的风险点。培训与经验传承新人可以通过对话方式学习资深工程师的方法。需要注意的是LLM 本身并不具备“物理感知”。它不知道电流怎么流不知道 2.4G 天线附近能不能铺铜。它只是通过大量文本学习到了“人类通常在这种情况下怎么处理”。2. 环境准备搭建 LLM PCB 知识助手需要什么如果你想把 LLM 真正用起来而不是只是看热闹建议从一套最小可用的环境开始。2.1 硬件与操作系统LLM 的运行方式有两种本地部署和调用云端 API。本地部署适合追求数据安全、不想把设计资料传到外网的情况。建议显卡显存至少 16GB推荐 24GB 以上。7B~14B 参数量的量化模型可以跑起来。云端 API适合快速验证思路。不需要高配硬件按调用量付费。操作系统方面Windows、Linux、macOS 都可以。如果做正式的知识库项目推荐 Linux 服务器。2.2 软件与框架选型组件推荐方案说明LLM 模型Qwen2.5-7B / Llama3.1-8B参数量适中中文和英文表现都不错推理框架Ollama / vLLMOllama 适合本地快速测试vLLM 适合服务化部署向量数据库Chroma / Milvus / pgvector用来存 PCB 文档和经验知识向量知识库框架LangChain / LlamaIndex / Spring AI负责文档加载、分割、检索、问答流程编排Agent 编排LangGraph / Spring AI MCP适合做多步骤任务比如查文档、调 EDA 脚本UI 界面Streamlit / Open WebUI快速搭建可视化对话界面版本方面不需要刻意追求最新关键是版本之间兼容。比如 LangChain 和 Ollama 的 API 对接不同版本参数名会变化建议锁定自己验证过的组合。2.3 示例项目结构下面是一个典型的项目目录结构llm-pcb-assistant/ ├── data/ │ ├── docs/ # 原始文档如 PCB 设计规范 │ ├── rules/ # 合约工程师经验规则 │ └── projects/ # 历史项目复盘记录 ├── src/ │ ├── ingest.py # 文档加载与向量化 │ ├── retriever.py # 检索逻辑 │ ├── agent.py # Agent 编排 │ └── app.py # 对话入口 ├── config/ │ ├── settings.yaml # 全局配置 │ └── prompts.yaml # 提示词模板 ├── requirements.txt └── README.md这个结构适合后续扩展成完整的“LLM PCB 设计助手”。3. LLM 与 PCB 布线结合的核心原理先解决一个问题LLM 到底怎么“学会”布线答案是它不是学会布线而是学会了“关于布线的知识”。3.1 从数据到知识LLM 的学习对象LLM 可以处理这些 PCB 相关内容设计规范文档IPC 标准、企业设计规范、高速设计指南。器件数据手册引脚定义、封装尺寸、电气参数、Layout 建议。项目复盘记录之前项目遇到的问题、解决方案、效果验证。仿真报告SI信号完整性、PI电源完整性仿真结论。产线反馈DFM可制造性设计审查问题、返工记录。资深工程师的口述经验这是最难获得但最有价值的部分。合约工程师的经验并不一定写在文档里。它可能存在于一次评审会议、一个修改记录、一条聊天消息里。所以数据采集这件事比模型选择更重要。3.2 RAG把经验“喂”给 LLMRAGRetrieval-Augmented Generation检索增强生成是目前最实用的方案。原理很简单把文档切块Chunk。对每个文本块生成向量Embedding。用户提问时把问题转成向量。在向量数据库中检索最相似的文本块。把检索结果和问题一起交给 LLM生成最终回答。这样做的好处是不需要微调模型成本低。可以随时更新知识库。回答可以引用原文提高可信度。避免模型“一本正经地胡说八道”。3.3 Agent让 LLM 能调用工具如果只是问答RAG 就够了。但如果想让 LLM 做更多事比如查询 PADS 文件、运行脚本、生成约束文件就需要 Agent。Agent 的核心是让 LLM 决定“下一步做什么”。比如用户问“帮我检查一下当前 PCB 文件里 3.3V 电源网络的线宽是否满足 1A 电流要求。”Agent 的流程可能是调用文件解析工具读取当前 PCB 网络信息。查询知识库找到 1A 电流对应的推荐线宽。对比线宽表确认是否满足。如果不满足给出建议调整值。这个流程需要 LLM 具备“计划—执行—检查”的能力。在实际项目中可以通过 LangChain、LangGraph 或 Spring AI 来实现。4. 实战从零搭建一个“PCB 经验问答与布线建议助手”下面我们用一套比较完整的流程搭建一个能回答 PCB 布线问题的 LLM 助手。这个示例以本地部署 RAG Agent 为主代码片段可以直接复用。4.1 安装依赖# 创建虚拟环境 python -m venv venv source venv/bin/activate # Windows 下用 venv\Scripts\activate # 安装核心依赖 pip install langchain langchain-community chromadb sentence-transformers pip install ollama streamlit pip install pyyaml这里用 Ollama 做本地模型推理用 Chroma 做向量数据库用 Streamlit 做界面。4.2 配置 Ollama 模型先安装 Ollama然后拉取模型ollama pull qwen2.5:7b ollama pull nomic-embed-textqwen2.5:7b用于文本生成nomic-embed-text用于向量化。如果显存不够可以用更小的模型。启动服务ollama serve默认服务地址是http://localhost:11434。4.3 准备 PCB 经验知识文档假设我们手里有一份合约工程师整理的“DCDC 电源模块布线经验”内容大致如下DCDC 电源模块布线经验整理自项目 X 1. 输入电容应尽量靠近芯片 VIN 引脚回流地过孔紧邻电容地焊盘。 2. 开关节点SW走线要短而宽尽量减少寄生电感。 3. 反馈信号采样点应位于输出电容之后走线远离 SW 节点。 4. 底部最好不要在芯片下方直接铺铜避免回流路径聚集。 5. 电感下方各层铺铜需谨慎必要时做挖空处理。 6. 输出电压检测走线使用 0.2mm 以上宽度并做包地处理。这类文档就是“合约工程师经验”的载体。我们需要把它切成合适的块存入向量数据库。4.4 文档导入与向量化创建src/ingest.py# 文件路径src/ingest.py import os from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma # 配置路径 DOCS_DIR data/docs CHROMA_DIR data/chroma def ingest_documents(): # 1. 加载文档 docs [] for filename in os.listdir(DOCS_DIR): if filename.endswith(.txt) or filename.endswith(.md): file_path os.path.join(DOCS_DIR, filename) loader TextLoader(file_path, encodingutf-8) docs.extend(loader.load()) # 2. 切分文本 text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , ] ) chunks text_splitter.split_documents(docs) # 3. 向量化并存储 embeddings OllamaEmbeddings( modelnomic-embed-text, base_urlhttp://localhost:11434 ) vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directoryCHROMA_DIR ) vectorstore.persist() print(f成功导入 {len(chunks)} 个文本块) if __name__ __main__: ingest_documents()这里有几个关键点chunk_size决定了检索的粒度。PCB 经验文本一般按“单条经验”切分效果更好。chunk_overlap避免把一条完整规则从中间切断。分隔符要加入中文标点否则中文句子容易被硬切。运行导入python src/ingest.py4.5 构建问答检索链创建src/retriever.py# 文件路径src/retriever.py from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma from langchain_community.llms import Ollama from langchain.chains import RetrievalQA from langchain.prompts import PromptTemplate CHROMA_DIR data/chroma # 自定义提示词让回答更贴合 PCB 场景 template 你是一名资深的 PCB Layout 设计顾问具备丰富的硬件工程经验。 请基于提供的参考知识回答用户问题。如果参考知识中没有相关信息 请明确说明“根据现有知识库无法完全确认”并给出通用建议。 参考知识 {context} 用户问题{question} 请用中文回答给出具体建议和注意事项。 prompt PromptTemplate( templatetemplate, input_variables[context, question] ) def create_qa_chain(): embeddings OllamaEmbeddings( modelnomic-embed-text, base_urlhttp://localhost:11434 ) vectorstore Chroma( persist_directoryCHROMA_DIR, embedding_functionembeddings ) retriever vectorstore.as_retriever( search_kwargs{k: 5} ) llm Ollama( modelqwen2.5:7b, base_urlhttp://localhost:11434, temperature0.2 ) qa_chain RetrievalQA.from_chain_type( llmllm, retrieverretriever, return_source_documentsTrue, chain_type_kwargs{prompt: prompt} ) return qa_chain if __name__ __main__: chain create_qa_chain() while True: question input(请输入你的 PCB 布线问题输入 exit 退出) if question.lower() exit: break result chain.invoke({query: question}) print(\n 回答 ) print(result[result]) print(\n 参考来源 ) for doc in result[source_documents]: print(-, doc.page_content[:80].replace(\n, )) print()注意temperature设置成 0.2是为了让输出更稳定、更贴近知识库内容而不是自由发挥。4.6 添加 Agent 能力查询线宽建议PCB 布线中有一个很典型的问题“某个电流下线宽至少需要多少”这个问题看起来简单但严格来说需要根据铜厚、温升、走线位置来计算。我们可以把工程上常用的“线宽—电流—铜厚”对照表做成工具让 Agent 调用。创建src/tools/trace_width.py# 文件路径src/tools/trace_width.py def estimate_trace_width(current_a: float, copper_oz: float 1.0, temp_rise: float 10) - float: 基于 IPC-2221 外部层经验公式估算线宽。 返回单位为 mm。 公式I k * A^0.44 * dT^0.725 其中 k 对外层取 0.024A 单位 mil^2, I 单位 A import math # IPC-2221 外部层系数 k 0.024 # 先估算截面积 A (单位平方密耳 mil^2) # 1 oz 铜厚约为 1.378 mil thickness_mil copper_oz * 1.378 # 解方程 I k * A^0.44 * dT^0.725 # A (I / (k * dT^0.725)) ^ (1/0.44) A (current_a / (k * (temp_rise ** 0.725))) ** (1 / 0.44) # 线宽 mil A / thickness_mil width_mil A / thickness_mil # 转换为 mm1 mil 0.0254 mm width_mm width_mil * 0.0254 # 工程上一般取 10%~20% 余量 recommend_mm width_mm * 1.2 return { current_a: current_a, copper_oz: copper_oz, temp_rise_c: temp_rise, calculated_width_mm: round(width_mm, 3), recommend_width_mm: round(recommend_mm, 3), note: IPC-2221 经验估算实际需结合走线长度、散热条件和工艺能力 }创建src/agent.py把工具注册给 Agent# 文件路径src/agent.py from langchain.agents import initialize_agent, AgentType, tool from langchain_community.llms import Ollama from tools.trace_width import estimate_trace_width tool def trace_width_tool(current_a: str, copper_oz: str 1.0) - str: 根据电流(A)和铜厚(oz)估算 PCB 外部层走线宽度(mm)。输入示例trace_width_tool(2.5, 1.0) try: current float(current_a) copper float(copper_oz) result estimate_trace_width(current, copper) return (f电流 {result[current_a]}A铜厚 {result[copper_oz]}oz f温升 10℃ 时计算线宽约 {result[calculated_width_mm]}mm f建议线宽 {result[recommend_width_mm]}mm。 f{result[note]}) except Exception as e: return f计算失败{str(e)} def create_agent(): tools [trace_width_tool] llm Ollama( modelqwen2.5:7b, base_urlhttp://localhost:11434, temperature0.2 ) agent initialize_agent( toolstools, llmllm, agentAgentType.ZERO_SHOT_REACT_DESCRIPTION, verboseTrue, handle_parsing_errorsTrue ) return agent if __name__ __main__: agent create_agent() question 3.3V 电源网络需要走 2A 电流1oz 铜厚线宽需要多少 answer agent.run(question) print(answer)这个示例展示了 LLM Agent 的核心思想模型负责理解用户意图并决定调用哪个工具工具负责精确计算。4.7 用 Streamlit 搭建界面创建src/app.py# 文件路径src/app.py import streamlit as st from retriever import create_qa_chain st.set_page_config(page_titleLLM PCB 布线助手, layoutwide) st.title( LLM PCB 布线知识助手) # 初始化问答链 st.cache_resource def load_chain(): return create_qa_chain() chain load_chain() question st.text_input(请输入你的 PCB 布线问题) if st.button(获取建议) and question: with st.spinner(正在检索知识库并生成建议...): result chain.invoke({query: question}) st.markdown(### 回答) st.write(result[result]) with st.expander(查看参考文档): for doc in result[source_documents]: st.info(doc.page_content)运行界面streamlit run src/app.py这样你就得到了一套完整的 LLM PCB 布线知识助手可以导入不同项目的经验文档持续扩充知识库。5. 实战中的常见问题与排查思路LLM PCB 这套组合看着简单真正跑起来会有不少问题。5.1 回答内容与 PCB 知识库不相关问题现象常见原因解决思路LLM 回答泛泛而谈没有引用知识库内容向量检索到的上下文与问题不匹配检查 chunk 大小、检索相似度阈值、文档格式回答中英文混杂术语不统一Prompt 指定不清晰在系统提示词中强调统一术语如“统一使用中文”完全没有引用知识库直接自由发挥RAG 链路问题或模型能力不足确认检索结果是否真正传给 LLM必要时加大模型参数量5.2 本地模型推理速度慢7B 模型在 CPU 上推理速度非常慢一个回答可能要几十秒。建议使用 GPU 运行开启OLLAMA_FLASH_ATTENTION1。降低上下文长度比如num_ctx设置为 4096。使用量化模型如 Q4_K_M。如果并发量高改用 vLLM 部署。5.3 向量化中文效果差中文文本切分和向量化比英文容易出问题。建议使用针对中文优化的 embedding 模型如bge-large-zh。切分时把“标题”和“正文”区分开避免规则被拆散。对 PCB 术语做同义词扩展比如“走线”“布线”“Routing”“Trace”可以用统一词表。5.4 Agent 工具调用失败initialize_agent在 LangChain 新版中可能出现弃用警告或参数变化。建议固定 LangChain 版本。新项目可以直接用 LangGraph 写更可控的 Agent 流程。工具函数的 docstring 写清楚输入格式LLM 依赖它来判断怎么调用。5.5 知识库更新后回答不变Chroma 持久化目录可能缓存了旧数据。更新文档后需要重新执行ingest.py并确认没有重复插入相同数据。建议在文档中加入版本号字段或对相同来源做覆盖更新。6. 如何真正“教会”LLM 做 PCB 布线工程化建议如果你只是做一个 demo上面的代码已经够了。但如果想在生产环境中真正落地有几点建议值得留意。6.1 不要试图让 LLM 自学成才LLM 不会因为你给了一堆文档就能自主布线。它更适合做“辅助判断”和“经验问答”。真正负责布线连通性和质量的依然是专业 EDA 工具。LLM 的价值在于减少查阅手册的时间。把模糊的问题拆解成可执行的检查项。帮助新人理解资深工程师的决策逻辑。6.2 建立结构化的经验知识体系合约工程师的经验通常是非结构化的比如“这里线尽量短一点不然可能会有干扰。”这类表述要变成 LLM 能用的知识最好结构化规则编号R-2024-PWR-001 适用场景DCDC 电源模块 约束对象输入电容到 VIN 引脚走线 规则描述走线长度尽量小于 5mm线宽不小于 0.5mm 风险等级高 验证方式近场探头测试结构化之后无论是检索还是后续做规则校验都更有价值。6.3 用 RAG 微调结合的方式提升效果RAG 适合外挂知识微调适合塑造回答风格和领域语感。如果你想长期在一个细分领域深耕可以考虑先收集几百条高质量 PCB 问答对。用 LoRA 对基座模型做轻量微调。微调后继续搭配 RAG 使用。每次项目复盘后更新知识库。微调成本不低初期建议先用 RAG 验证场景再决定要不要微调。6.4 数据安全与合规边界PCB 设计文件往往包含未发布产品的关键信息。使用 LLM 必须注意涉及内部设计文件时优先本地部署模型。不要把原理图、PCB 源文件直接发给外部 API。对上传文档做脱敏处理删除公司名称、项目代号。记录所有 LLM 调用日志便于审计。6.5 从“问答”走向“自动检查”问答只是第一步。更高级的用法是让 LLM 自动生成检查报告。例如输入一个 PCB 的约束文件LLM 结合知识库自动生成设计评审问题清单1. 3.3V 网络线宽是否满足电流需求 2. 晶振下方是否有其他层走线穿越 3. 屏蔽罩接地过孔间距是否合理 4. 高速差分对等长误差是否在 ±5mil 以内这一步可以通过 Agent 编排实现先读取设计文件再逐项调用检查工具最后汇总报告。7. LLM PCB Routing 的未来方向从目前的发展趋势看LLM 与 PCB 布线的结合会沿着几个方向演进。7.1 LLM 辅助布线参数推荐未来 EDA 工具可能会内置 LLM 助手在设计过程中实时回答布线和约束问题。比如在 PADS 或 Allegro 中选中一根网络LLM 自动提示推荐线宽、过孔大小、回流策略。7.2 自然语言生成约束规则目前很多 EDA 工具的约束规则都靠手动配置。LLM 可以把一句“这个 USB 差分对走线等长控制在 5mil 以内”直接转成规则文件。虽然现在还不够成熟但方向已经明确。7.3 设计知识自动沉淀未来项目结束后系统可以从设计文件、评审记录、仿真报告、产线问题中自动抽取经验形成新的知识文档。这会让“合约工程师经验”真正留在企业里。7.4 多模态文档理解PCB 领域大量知识存在于图片里比如叠层结构图、器件封装图、布线示意图。多模态 LLM 可以直接从图片中提取信息辅助设计判断。这会比纯文本 RAG 更强大。8. 总结与下一步建议回到标题那句话“What the Contract Engineer Taught It”。LLM 的 PCB 布线能力本质上来自优质经验的持续输入。模型本身只是一个推理引擎真正有价值的是我们喂给它的知识。如果你想在这个方向深入建议按这个顺序推进先收集你自己项目里最常遇到的 50 个布线问题。把答案整理成结构化的文档。用本文的代码搭一套 RAG 问答助手。在真实项目中试用记录回答不准确的地方。逐步增加 Agent 工具把线宽计算、阻抗计算、过孔载流能力等工具接进去。如果效果好再考虑微调模型和建设企业级知识库。这个领域最大的门槛不是模型而是高质量工程经验的数字化。谁先把经验整理好了谁就能让 LLM 真正帮上忙。如果你正在做 PCB 设计或者 LLM 应用开发可以试着从一份最熟悉的布线设计规范开始跑通第一版知识问答助手。等你能把资深工程师的经验顺利“教”给 LLM后续的扩展就会顺畅很多。