1. 浏览器里跑EDA这件事到底靠不靠谱第一次看到 Nomoreda 这个项目我的反应是又有人想在浏览器里做 PCB 设计了。这个念头不新鲜从早期的网页版原理图工具到各种在线协同硬件平台每隔几年就会冒出来一波。但仔细看完它的定位——Browser EDA、MCP-Friendly、KiCad/Altium-Compatible——我意识到这次的路子跟以前不太一样。它没有打算取代 Altium Designer 或者 KiCad而是把自己放在了一个中间层的位置上用浏览器做轻量化的查看、编辑和协同同时通过 MCP 协议把 AI Agent 接进来再通过兼容层跟 KiCad、Altium 的工程文件打交道。说白了Nomoreda 想解决的是一个很具体的痛点硬件工程师的日常工作里有大量时间花在打开重型软件—等加载—改一个小地方—再导出这个循环上。Altium Designer 装完动辄十几个 GB启动一次要等半天电脑内存使用量越来越多时间长了内存不足是常态。KiCad 虽然轻一些但跨平台协同、版本管理、跟 AI 工具联动这些事它本身并不擅长。Nomoreda 的思路是把看和轻改这部分搬到浏览器里把重活留给本地专业工具中间用标准格式和 MCP 协议打通。这篇文章适合几类人看一是天天跟 Altium、KiCad 打交道、想找提效手段的硬件工程师二是对 MCP 协议感兴趣、想知道它在 EDA 场景怎么落地的开发者三是想了解浏览器端 EDA 技术路线选型的产品或技术负责人。我会从整体设计思路、核心技术点、实操流程、常见坑四个维度拆开讲尽量把为什么这么设计讲透而不是只罗列功能。2. 整体设计思路为什么是浏览器为什么是 MCP2.1 浏览器 EDA 的定位取舍浏览器做 EDA最大的争议点是性能。PCB 设计里动辄几万个走线段、几千个焊盘WebGL 和 Canvas 的渲染能力能不能扛住这是第一个要回答的问题。Nomoreda 的做法是明确区分查看/标注/轻编辑和重布局布线两类场景。前者用浏览器渲染完全够用后者仍然交给本地工具。这个取舍很关键因为如果一上来就想在浏览器里做完整的布局布线性能和维护成本都会失控。从技术上看浏览器端渲染 PCB 数据通常有几条路SVG、Canvas 2D、WebGL。SVG 适合元素少、需要精确交互的场景但元素一多 DOM 节点爆炸内存直接顶不住。Canvas 2D 性能好一些但交互命中检测要自己实现。WebGL 适合大规模图元但开发复杂度高。Nomoreda 这类工具一般会采用 Canvas 2D 加分层渲染的策略把铜箔层、丝印层、阻焊层分开渲染每层独立缓存缩放平移时只重绘变化的部分。这样即使几万个图元帧率也能维持在可用水平。另一个取舍是数据存储。浏览器端不可能把整个工程文件都加载进内存尤其是 Altium 的 .PcbDoc 动辄几十上百 MB。合理的做法是服务端做解析和索引浏览器端只拉取当前视口和当前层需要的数据类似地图瓦片的思想。这样既控制了内存又加快了首屏加载。2.2 MCP 协议在 EDA 里的角色MCP 是 Model Context Protocol 的缩写简单理解就是一套让 AI 模型或 Agent 能够标准化地调用外部工具、读取外部数据的协议。你可以把它类比成AI 世界的 USB 接口——只要工具实现了 MCP Server任何支持 MCP 的客户端比如各种 AI 编程助手、Agent 框架就能直接调用它不用为每个工具单独写适配。放到 EDA 场景里MCP 的价值就很直观了。传统上你想让 AI 帮你分析一个原理图得先把文件导出成文本、截图、或者手动描述给 AI来回折腾。有了 MCPAI Agent 可以直接通过协议查询这个网络上有哪些元件、这个差分对的走线长度是多少、帮我找出所有未连接的引脚。Nomoreda 把自己做成 MCP-Friendly意味着它暴露了一套标准的工具接口AI 可以像调用本地函数一样操作工程数据。这里要区分两个概念MCP 和 RAG 不是一回事。RAG 是检索增强生成解决的是让模型知道更多背景知识MCP 解决的是让模型能动手操作外部系统。在 EDA 里RAG 可以用来查器件手册、设计规范MCP 则用来实际读取和修改工程。两者配合才能让 AI 真正参与到设计流程里而不是只当个问答机器人。2.3 KiCad/Altium 兼容层的实现逻辑兼容是这类工具的生命线。硬件工程师不会为了用一个新工具就把历史工程全部重做所以能不能读 KiCad 和 Altium 的文件直接决定了工具有没有实用价值。KiCad 的文件格式是公开的.kicad_sch 和 .kicad_pcb 都是基于 S-expression 的文本格式解析相对容易。社区里已经有成熟的解析库Nomoreda 大概率是直接复用或者参考了这些实现。Altium 就麻烦得多.SchDoc 和 .PcbDoc 是二进制格式官方没有公开完整规范社区逆向出来的解析器比如 python 的一些库覆盖度参差不齐。常见的做法是优先支持 Altium 导出成中间格式如 ODB、IPC-2581、Gerber或者要求用户先在 Altium 里另存为 ASCII 格式再导入。提示如果你打算用这类工具处理 Altium 工程最稳的路径是先在 Altium 里导出为通用格式而不是指望工具直接啃二进制文件。二进制解析的坑太多尤其是不同版本之间的差异。兼容层的另一个重点是往返一致性。读进来能看改完能导回去而且导回去之后 Altium 或 KiCad 打开不能报错这才是真兼容。很多工具只能做到单向导入导出就丢信息这种在实际工作里没法用。判断一个 EDA 工具兼容性好不好最简单的测试方法就是导入一个复杂工程不做任何修改直接导出再用原软件打开对比有没有差异。3. 核心技术点拆解与实操要点3.1 工程文件的解析与索引不管前端做得多漂亮后端解析才是这类工具的地基。以 KiCad 的 .kicad_pcb 为例文件里包含了层定义、网络表、元件封装、走线段、过孔、铺铜等大量信息。解析的目标不是把整个文件读成对象树就完事而是要建立可查询的索引。我一般会建议按这几个维度建索引按层Layer、按网络Net、按元件Component、按坐标范围Bounding Box。有了这几个索引前端请求当前视口内第 3 层的所有走线时后端能快速返回而不是每次全量扫描。对于大工程这个差别是秒级和毫秒级的区别。解析时几个容易踩的坑单位换算。KiCad 内部用纳米Altium 常用 mil 或 mm导入导出时必须统一否则尺寸直接错乱。坐标原点。不同工具的坐标系原点位置不一样有的在左下角有的在页面中心转换时要格外小心。层映射。KiCad 和 Altium 的层命名和编号规则不同需要一张映射表尤其是内层和机械层。3.2 浏览器端渲染的性能优化前面提到分层渲染这里展开讲具体怎么做。假设一个 4 层板顶层铜、底层铜、丝印、阻焊每层单独一个 Canvas 或者一个离屏 Canvas 缓存。用户缩放平移时只对可见区域重绘。对于走线这种重复图元可以用 Path2D 批量绘制减少状态切换。实测下来几万条走线用 Canvas 2D 分层渲染在中端笔记本上能跑到 30 帧以上交互基本流畅。如果图元数量再上一个量级就得上 WebGL把走线转成三角形或者线段批次提交给 GPU。但 WebGL 的开发和调试成本高很多除非确实有必要否则 Canvas 2D 是性价比更高的选择。内存控制是另一个重点。浏览器标签页的内存是有上限的加载大工程时如果不做限制很容易崩。策略是只保留当前视口附近的数据在内存里远处的数据序列化到 IndexedDB 或者直接丢弃需要时再拉。这跟地图应用的思路一样。3.3 MCP Server 的接口设计把 Nomoreda 做成 MCP-Friendly核心是设计一套合理的工具接口。接口设计得好不好直接决定 AI 能不能用得顺手。我理解一套好的 EDA MCP 接口应该覆盖这几类能力能力类别典型接口用途查询类get_components, get_nets, get_traces让 AI 读取工程结构分析类check_drc, measure_length, find_unconnected让 AI 做设计检查修改类move_component, add_via, change_trace_width让 AI 执行修改导出类export_gerber, export_bom, export_pdf让 AI 触发输出设计接口时有几个原则。第一粒度要适中太细了 AI 要调很多次太粗了又不够灵活。第二参数要明确尽量用结构化数据而不是自然语言描述。第三修改类接口一定要有预览和确认机制不能让 AI 直接改坏工程。第四返回结果要包含足够的上下文比如修改后受影响的范围方便 AI 判断下一步。注意修改类接口是风险最高的部分。我的建议是默认只读修改能力需要显式开启并且每次修改都记录操作日志方便回滚。3.4 与 KiCad、Altium 的数据往返往返一致性是兼容层的终极考验。实现上通常需要一个中间数据模型Intermediate Representation把 KiCad 和 Altium 的数据都转换成这个统一模型编辑后再转换回目标格式。这个中间模型的设计质量决定了能保留多少信息。常见的丢失点包括自定义属性、特殊封装、层叠结构、设计规则。这些在转换过程中如果处理不好导回去就会出问题。我的经验是对于无法完美映射的信息宁可原样保留在扩展字段里也不要丢弃。这样即使当前工具用不上导回原软件时还能还原。实操上建议的工作流是用 Nomoreda 做查看、标注、轻量修改和协同评审重活仍然在 KiCad 或 Altium 里做。把它当成一个浏览器端的工程查看器和协同层而不是全功能替代品这样预期就不会错位。4. 完整实操流程从导入到协同评审4.1 环境准备与工程导入假设你手上有一个 KiCad 工程想用 Nomoreda 打开看看。第一步是确认工程文件的完整性。KiCad 工程通常包含 .kicad_pro、.kicad_sch、.kicad_pcb 以及可能的库文件。导入前最好在本地 KiCad 里打开确认没有报错避免把问题带进新工具。导入方式一般有两种上传文件或者连接代码仓库。如果工程在 Git 里直接连仓库更省事还能利用版本历史。上传的话注意文件大小限制大工程建议先精简或者分块。导入后第一件事是核对层数和板框尺寸。这两个数据如果不对后面全是错的。层数在层管理面板里看板框尺寸用测量工具量一下跟原始设计对比。我遇到过导入后内层丢失的情况就是因为层映射表没配对。4.2 浏览器端的查看与标注导入成功后界面通常分几个区域左侧是层和网络列表中间是画布右侧是属性面板。查看时的几个高效操作用快捷键切换层显示比鼠标点快得多。用网络高亮功能追踪某条信号线的完整路径排查连接问题特别有用。用测量工具量走线长度、间距做等长检查时很方便。标注功能是协同评审的核心。你可以在画布上任意位置加评论比如这个过孔太靠近板边了、这条差分对间距不均匀。评论会关联到具体坐标和层其他人打开就能看到。这比截图发群里高效得多因为截图丢失了坐标和层信息。4.3 通过 MCP 接入 AI 助手这是 Nomoreda 最有意思的部分。假设你配置好了 MCP 连接AI 助手就能读取当前工程。举几个实际能用的场景第一个场景是设计规则检查。你可以让 AI 帮你找出所有线宽小于 6mil 的走线或者所有间距小于 8mil 的地方。AI 通过 MCP 调用查询接口返回结果列表你点击就能定位到具体位置。这比手动跑 DRC 再逐条看报告快。第二个场景是 BOM 核对。让 AI 读取工程里的元件清单跟你的采购清单对比找出缺料或者型号不符的。这个用 MCP 查询接口加一点逻辑就能实现。第三个场景是设计意图问答。新同事接手一个老工程可以直接问 AI这个电源部分的拓扑是什么、这几个电容的作用是什么。AI 通过 MCP 读取原理图结构结合自己的知识回答。当然回答的准确性取决于工程信息的完整度标注和注释写得越清楚AI 答得越准。配置 MCP 连接时注意几个参数服务地址、认证方式、超时时间。超时时间别设太短大工程查询可能要几秒。认证建议用 token 而不是明文密码。4.4 修改与导出轻量修改是 Nomoreda 的另一个用途。比如调整丝印位置、修改元件标号、更新封装。这些操作在浏览器里做比开重型软件快得多。但要注意修改后一定要走一遍导出验证流程导出成 KiCad 或 Altium 格式用原软件打开确认没有报错、没有信息丢失。导出 Gerber 是另一个常用功能。Altium 24 导出 Gerber 的流程比较繁琐如果 Nomoreda 能一键导出并且参数可配置能省不少事。导出时重点检查层是否齐全、钻孔文件是否包含、单位和格式是否正确。Gerber 格式有 RS-274X 和 X2 之分跟板厂确认清楚用哪种。5. 常见问题与排查技巧实录5.1 导入失败或数据缺失这是最常见的问题。排查顺序建议这样走现象可能原因排查方法导入报错文件格式不支持或损坏用原软件打开确认文件正常层数不对层映射表缺失检查层配置文件元件丢失封装库未找到确认库文件是否一起导入尺寸错乱单位换算错误核对导入时的单位设置网络表为空原理图未关联确认 PCB 和原理图的关联关系我的经验是遇到导入问题先别急着怀疑工具八成是文件本身或者库路径的问题。尤其是 KiCad库路径配置不对元件就显示不出来。5.2 浏览器卡顿或崩溃大工程在浏览器里卡顿通常是内存或渲染的问题。先看内存占用如果持续增长不释放多半是数据没做分页加载。再看渲染如果平移缩放时掉帧严重可能是没做分层缓存。几个实用的缓解手段关闭不需要显示的层、降低渲染精度比如走线用简化表示、分区域查看而不是一次加载整板。如果工程实在太大考虑只导入需要评审的部分。5.3 MCP 连接不稳定MCP 连接问题一般出在配置上。检查清单服务是否启动、地址端口是否正确、认证 token 是否有效、防火墙是否拦截。如果连接时断时续看超时设置大查询适当延长超时。还有一个容易忽略的点并发限制。如果同时有多个 AI 请求服务端可能扛不住。建议对 MCP 接口做限流并且给长查询加缓存。5.4 导出后原软件打不开这是往返一致性的问题。排查时先确认导出格式和版本Altium 不同版本的文件格式有差异导出时选对版本很重要。再看有没有非法字符或者超范围的值比如坐标为负、线宽为零。一个实用的验证方法导出后不要直接用原软件打开先用文本编辑器看看文件结构是否完整有没有明显的截断或者乱码。二进制格式看不出但文本格式如 KiCad能看出不少问题。提示导出前先做一次全量保存导出后如果发现问题可以对比原始文件和导出文件的差异快速定位是哪一步出的错。6. 这类工具值不值得投入时间我用过不少浏览器端 EDA 工具大部分用两次就放弃了原因是看着新鲜用起来鸡肋。Nomoreda 这类工具能不能跳出这个怪圈关键看两点一是兼容性够不够硬能不能真的读写你手上的工程二是 MCP 集成够不够深AI 能不能真的帮上忙而不是添乱。从目前的信息看它的方向是对的。浏览器端做查看和协同本地工具做重活MCP 做 AI 接入的桥梁这个分工符合实际工作流。但具体好不好用还得看兼容层的完成度和 MCP 接口的设计质量。我的建议是先拿一个不太重要的工程试试水重点验证导入导出的往返一致性再决定要不要纳入日常工作流。最后分享一个我踩过的坑别指望一个工具解决所有问题。EDA 工具链本来就是多工具协作浏览器端工具的价值在于补位而不是替代。把它放在合适的位置上它就能发挥价值指望它包打天下最后只会失望。