LLM如何传承合约工程师经验，辅助PCB布线决策
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 / vLLM | Ollama 适合本地快速测试，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：把经验“喂”给 LLM
RAG（Retrieval-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, encoding="utf-8") docs.extend(loader.load()) # 2. 切分文本 text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50, separators=["\n\n", "\n", "。", "；", " ", ""] ) chunks = text_splitter.split_documents(docs) # 3. 向量化并存储 embeddings = OllamaEmbeddings( model="nomic-embed-text", base_url="http://localhost:11434" ) vectorstore = Chroma.from_documents( documents=chunks, embedding=embeddings, persist_directory=CHROMA_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( template=template, input_variables=["context", "question"] ) def create_qa_chain(): embeddings = OllamaEmbeddings( model="nomic-embed-text", base_url="http://localhost:11434" ) vectorstore = Chroma( persist_directory=CHROMA_DIR, embedding_function=embeddings ) retriever = vectorstore.as_retriever( search_kwargs={"k": 5} ) llm = Ollama( model="qwen2.5:7b", base_url="http://localhost:11434", temperature=0.2 ) qa_chain = RetrievalQA.from_chain_type( llm=llm, retriever=retriever, return_source_documents=True, 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.024（A 单位 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 # 转换为 mm，1 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( model="qwen2.5:7b", base_url="http://localhost:11434", temperature=0.2 ) agent = initialize_agent( tools=tools, llm=llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, verbose=True, handle_parsing_errors=True ) 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_title="LLM PCB 布线助手", layout="wide") 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_ATTENTION=1。 - 降低上下文长度，比如
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，后续的扩展就会顺畅很多。