1. 从“看不见”到“看得见”AI 硬件设计辅助系统的关键一步做过硬件设计的朋友都知道画原理图、摆器件、连网络、查封装这些活儿琐碎且耗时。尤其是当你面对一块已经画好的板子想快速理清某个模块的走线逻辑或者想确认某个电源网络的去耦电容到底放了几颗光靠肉眼在 Altium Designer 或 Cadence 里来回缩放、翻页效率低得让人抓狂。这两年 AI 辅助设计工具层出不穷但绝大多数都停留在“你问它答”的聊天层面——AI 看不到你的屏幕看不到你的工程文件它只能根据你手动输入的文字去猜。这就好比让一个经验丰富的硬件老手闭着眼睛帮你 review 电路他再厉害也使不上劲。所以当我开始搭建自己的 AI 硬件设计辅助系统时第一个要解决的问题就是让 AI 看得见。具体来说就是让 AI 能够实时获取当前屏幕上硬件设计软件窗口的内容理解我正在看什么原理图、什么 PCB 布局、什么参数表格然后基于这些视觉信息给出针对性的建议。这个系列的第二篇我就专门来聊“抓屏”这件事——怎么抓、抓什么、抓完之后怎么用以及我在 Electron 技术栈下踩过的那些坑。这篇文章适合两类人看一类是正在做 AI 辅助工具、需要让模型获取桌面应用视觉信息的开发者另一类是硬件工程师想了解 AI 辅助设计系统底层是怎么运作的以后自己搭工具时心里有数。我会从整体设计思路讲起然后深入到 PrintWindow 抓屏的具体实现、Electron 环境下的窗口管理、图像预处理与传输最后分享几个实际调试中遇到的典型问题和排查方法。全文基于我在 Windows 平台上的实际项目经验代码和参数都可以直接参考复现。2. 整体设计思路为什么选择抓屏而不是读文件2.1 硬件设计软件的数据封闭性Altium Designer、Cadence Allegro、Mentor Xpedition 这些主流硬件设计工具它们的工程文件格式要么是加密的二进制要么是私有数据库结构直接解析文件来获取设计信息的门槛极高。以 Altium 为例原理图文件.SchDoc本质上是 OLE 复合文档里面嵌套了二进制流和压缩数据虽然社区有一些逆向解析的尝试但版本兼容性极差AD 每更新一个大版本解析逻辑就可能失效。PCB 文件.PcbDoc更复杂包含多层堆叠、铜皮多边形、规则约束等大量结构化数据想完整还原几乎是一个独立的大工程。相比之下抓屏获取视觉信息是一条“绕过格式壁垒”的捷径。不管设计软件内部怎么存储数据它最终都要把设计内容渲染到屏幕上。我只要把窗口画面截取下来送给具备视觉理解能力的 AI 模型模型就能像人一样“看”到原理图上的器件符号、网络标签、连线关系或者 PCB 上的走线、焊盘、丝印。这种方式与软件版本无关与文件格式无关通用性极强。注意抓屏方案获取的是像素级信息对于需要精确数值的场景比如某条走线的具体宽度是 6mil 还是 8milAI 可能无法从图像中准确读出。这类精确参数仍然需要结合人工输入或后续的 OCR 辅助识别来补充。2.2 抓屏方案选型BitBlt、Windows Graphics Capture 与 PrintWindowWindows 平台上抓取窗口内容常见的有三条路BitBltGDI 位块传输最传统的方式通过GetDC获取窗口设备上下文然后用BitBlt把像素复制到内存 DC。优点是兼容性好几乎所有 Windows 版本都支持。缺点是当窗口被遮挡、最小化或者使用硬件加速渲染时抓到的可能是黑屏或残缺画面。硬件设计软件大量使用 GPU 加速渲染BitBlt 经常抓不到内容。Windows Graphics CaptureWGCWindows 10 1803 之后引入的现代截屏 API基于 DirectX能抓到 GPU 渲染的内容性能好、画面完整。缺点是需要较新的系统版本且 API 使用相对复杂在 Electron 中集成需要借助原生模块或第三方库。PrintWindow一个专门用于“请求窗口把自己画出来”的 API。它向目标窗口发送WM_PRINT或WM_PRINTCLIENT消息让窗口主动将自己的内容绘制到指定的设备上下文中。关键优势在于即使窗口被其他窗口遮挡甚至部分最小化只要窗口进程还在运行PrintWindow 通常都能拿到完整画面。这对于后台运行 AI 辅助系统的场景非常关键——我不希望每次抓屏都要把设计软件窗口切到最前面。综合评估下来我最终选择了PrintWindow 为主、BitBlt 为辅的策略。PrintWindow 负责常规抓取当 PrintWindow 返回失败或画面异常时降级到 BitBlt 尝试。WGC 作为后续升级选项等系统兼容性要求提高后再考虑接入。2.3 Electron 在系统中的角色整个 AI 硬件设计辅助系统采用 Electron 作为桌面端框架。选 Electron 的理由很直接我需要一个能快速搭建 UI、能方便地调用 Node.js 生态、同时又能通过原生模块访问 Windows API 的运行时。Electron 的主进程跑 Node.js可以加载ffi-napi、koffi这类库直接调用user32.dll和gdi32.dll中的函数渲染进程负责展示 AI 对话界面和抓屏预览。主进程与渲染进程之间通过 IPC 通信把抓到的图像数据传给前端做展示同时发送给 AI 模型做分析。这里有一个架构上的关键决策抓屏逻辑放在主进程图像预处理放在独立的工作线程AI 调用放在主进程的网络模块。这样做的原因是抓屏和 AI 调用都是 IO 密集型操作放在主进程可以避免渲染进程卡顿而图像缩放、格式转换等 CPU 密集型操作放到worker_threads里防止阻塞主进程的事件循环。3. PrintWindow 抓屏的核心实现细节3.1 窗口句柄的获取与匹配抓屏的第一步是找到目标窗口。硬件设计软件的窗口标题通常包含工程名或文件名比如“PCB1.PcbDoc - Altium Designer”。我通过EnumWindows遍历所有顶层窗口对每个窗口调用GetWindowTextW获取标题再用关键词匹配来定位目标。匹配逻辑我做了三层精确匹配窗口标题完全等于预设的字符串适合固定工程名的场景。包含匹配标题中包含“Altium Designer”“Cadence”“PcbDoc”“SchDoc”等关键词覆盖面广。进程名匹配通过GetWindowThreadProcessId拿到进程 ID再查进程可执行文件名比如X2.EXE对应 Altium Designer。这一层最可靠不受窗口标题变化影响。实际使用中我优先用进程名匹配因为硬件工程师经常同时打开多个工程窗口标题会变但进程名是固定的。拿到HWND之后还要用IsWindowVisible和IsIconic判断窗口是否可见、是否最小化。如果窗口最小化了PrintWindow 仍然可以工作但抓到的画面尺寸可能是最小化状态的需要特殊处理。3.2 PrintWindow 的调用参数与 flag 选择PrintWindow 的函数签名如下BOOL PrintWindow(HWND hwnd, HDC hdcBlt, UINT nFlags);其中nFlags有两个常用值PW_CLIENTONLY值为 1只绘制窗口的客户区不包括标题栏、边框、菜单栏。对于硬件设计软件来说客户区就是原理图或 PCB 的绘图区域这正是我需要的。PW_RENDERFULLCONTENT值为 2Windows 8.1 之后引入用于抓取使用 DirectComposition 渲染的窗口内容。很多现代应用包括部分硬件设计软件的新版本使用这种渲染方式不加这个 flag 会抓到黑屏。我的策略是先尝试PW_RENDERFULLCONTENT | PW_CLIENTONLY如果返回的画面全黑或全白再降级到PW_CLIENTONLY最后降级到0绘制整个窗口。这个降级链在实际项目中覆盖了绝大多数情况。// 使用 koffi 调用 PrintWindow 的示意代码 const koffi require(koffi); const user32 koffi.load(user32.dll); const gdi32 koffi.load(gdi32.dll); const PrintWindow user32.func(bool PrintWindow(void* hwnd, void* hdc, uint32 flags)); const GetClientRect user32.func(bool GetClientRect(void* hwnd, _Out_ RECT* rect)); const CreateCompatibleDC gdi32.func(void* CreateCompatibleDC(void* hdc)); const CreateCompatibleBitmap gdi32.func(void* CreateCompatibleBitmap(void* hdc, int w, int h)); const SelectObject gdi32.func(void* SelectObject(void* hdc, void* obj)); const GetDIBits gdi32.func(int GetDIBits(void* hdc, void* hbm, uint32 start, uint32 lines, _Out_ void* bits, _Inout_ BITMAPINFO* bi, uint32 usage));3.3 内存 DC 与位图的创建PrintWindow 需要传入一个目标设备上下文HDC窗口会把内容画到这个 DC 上。这个 DC 不能是屏幕 DC必须是一个内存 DC否则会直接画到屏幕上造成闪烁。创建流程如下用GetDC(NULL)获取屏幕 DC 作为兼容参考。用CreateCompatibleDC(screenDC)创建内存 DC。用GetClientRect(hwnd, rect)获取窗口客户区尺寸。用CreateCompatibleBitmap(screenDC, width, height)创建与屏幕兼容的位图。用SelectObject(memDC, bitmap)把位图选入内存 DC。调用PrintWindow(hwnd, memDC, flags)。用GetDIBits从位图中提取像素数据到缓冲区。这里有一个容易踩的坑位图的尺寸必须与窗口客户区尺寸完全一致。如果窗口在抓屏过程中被调整了大小GetClientRect拿到的尺寸和实际绘制内容不匹配会导致画面拉伸或截断。我的做法是在抓屏前先调用GetClientRect抓屏后再调用一次如果两次尺寸不一致就丢弃本次结果重新抓。3.4 像素数据的提取与格式转换GetDIBits填充的BITMAPINFO结构体需要正确设置bmiHeaderconst BITMAPINFO koffi.struct(BITMAPINFO, { bmiHeader: BITMAPINFOHEADER, bmiColors: koffi.array(uint32, 3) }); const BITMAPINFOHEADER koffi.struct(BITMAPINFOHEADER, { biSize: uint32, biWidth: int32, biHeight: int32, biPlanes: uint16, biBitCount: uint16, biCompression: uint32, biSizeImage: uint32, biXPelsPerMeter: int32, biYPelsPerMeter: int32, biClrUsed: uint32, biClrImportant: uint32 });关键参数设置biBitCount 32BGRA 四通道biCompression 0BI_RGB 无压缩biHeight设为负数表示自上而下的像素排列这样提取出来的缓冲区第一行就是图像顶部省去翻转操作。biSizeImage设为width * height * 4。提取出来的 BGRA 数据需要转换成 AI 模型能接受的格式。大多数视觉模型接受 PNG 或 JPEG 的 base64 编码。我使用sharp库做转换const sharp require(sharp); async function bgraToPng(bgraBuffer, width, height) { return sharp(bgraBuffer, { raw: { width, height, channels: 4 } }).png({ compressionLevel: 6 }).toBuffer(); }sharp底层用 libvips转换速度快内存占用低。对于 1920x1080 的截图转换耗时大约 80-120ms完全可以接受。4. Electron 环境下的窗口管理与抓屏调度4.1 主进程与渲染进程的职责划分在 Electron 中我把抓屏相关的能力全部封装在主进程的一个ScreenCaptureService类里。这个类对外暴露三个方法listWindows()返回当前所有可见窗口的列表包含标题、进程名、句柄。captureWindow(hwnd, options)抓取指定窗口返回 PNG Buffer。startAutoCapture(hwnd, interval)启动定时抓屏通过 IPC 把图像推送给渲染进程。渲染进程通过ipcRenderer.invoke调用这些方法拿到图像后展示在预览区域同时把图像数据发送给 AI 分析模块。这里有一个设计上的取舍图像数据不通过 IPC 传输。IPC 传输大 Buffer 会经过序列化1920x1080 的 PNG 大约 2-5MB频繁传输会造成明显的性能开销。我的做法是主进程把图像写入临时文件或共享内存渲染进程只接收文件路径或共享内存标识然后自己读取。4.2 定时抓屏的节流与去重AI 辅助系统不需要每帧都抓屏。硬件设计是一个相对静态的场景工程师看一张原理图可能停留几十秒甚至几分钟。我的默认抓屏间隔是3 秒这个频率既能及时捕捉到用户的视图切换又不会造成过大的系统负担。但仅仅定时还不够还需要做画面去重。如果用户没有切换视图、没有滚动、没有缩放连续抓到的画面是完全一样的重复送给 AI 分析纯属浪费 token 和算力。我的去重策略是对每次抓到的 PNG Buffer 计算一个快速哈希比如取 Buffer 中间 1024 字节的 MD5。与上一次的哈希比较如果相同则跳过本次 AI 调用。如果连续 10 次哈希相同把抓屏间隔临时拉长到 10 秒直到检测到画面变化再恢复。这个策略在实际使用中把无效 AI 调用减少了大约 70%效果非常明显。4.3 多显示器与 DPI 缩放处理硬件工程师普遍使用多显示器而且经常是 2K、4K 高分辨率屏幕。Windows 的 DPI 缩放会让抓屏变得复杂当系统缩放比例为 150% 时GetClientRect返回的是逻辑像素而PrintWindow绘制的是物理像素两者不一致会导致抓到的画面尺寸错误。解决方案是在 Electron 启动时调用app.commandLine.appendSwitch(high-dpi-support, 1)和app.commandLine.appendSwitch(force-device-scale-factor, 1)强制应用以 100% 缩放运行然后在抓屏时通过GetDpiForWindow获取目标窗口的实际 DPI手动计算物理像素尺寸。具体来说const dpi GetDpiForWindow(hwnd); const scale dpi / 96; const physicalWidth Math.round(logicalWidth * scale); const physicalHeight Math.round(logicalHeight * scale);然后用物理尺寸创建位图抓完之后再按需缩放回逻辑尺寸用于显示。这一步不做的话在 150% 缩放的屏幕上抓到的画面会缺失右下角大约 1/3 的内容非常隐蔽。5. 图像预处理与 AI 传输的实操要点5.1 图像压缩与分辨率适配直接把 4K 截图原图送给 AI 模型不仅传输慢而且很多模型对输入图像有尺寸限制比如最长边不超过 2048 像素。我的处理流程是裁剪如果只需要分析原理图区域先用sharp.extract裁掉工具栏、面板等无关区域。裁剪区域可以通过窗口类名和控件位置动态计算也可以让用户在 UI 上手动框选。缩放把最长边缩放到 1600 像素保持宽高比。这个尺寸在清晰度和传输效率之间取得了较好的平衡。实测 1600 像素宽的截图AI 能清楚识别出器件标号如 R12、C34和网络标签如 VCC_3V3、GND。压缩PNG 转 JPEG质量设为 85。对于原理图这种线条图JPEG 质量 85 几乎看不出压缩损失但文件大小能从 3MB 降到 300KB 左右。async function preprocessImage(pngBuffer, cropRegion) { let pipeline sharp(pngBuffer); if (cropRegion) { pipeline pipeline.extract(cropRegion); } return pipeline .resize(1600, null, { withoutEnlargement: true }) .jpeg({ quality: 85, progressive: true }) .toBuffer(); }5.2 Base64 编码与 API 调用大多数视觉模型的 API 接受 base64 编码的图像。编码本身很简单const base64Image jpegBuffer.toString(base64); const dataUrl data:image/jpeg;base64,${base64Image};但这里有一个性能陷阱toString(base64)对于 300KB 的 Buffer 大约耗时 2-5ms但如果每 3 秒调用一次累积起来也会占用主进程时间。我的优化是把 base64 编码也放到 worker 线程里和图像预处理一起完成主进程只负责发送 HTTP 请求。5.3 提示词与图像内容的配合抓屏只是手段让 AI 理解画面才是目的。我在发送图像的同时会附带一段结构化的提示词告诉 AI 当前是什么软件、什么类型的视图、需要关注什么。比如当前画面是 Altium Designer 的原理图视图。 请识别图中的主要功能模块列出所有电源网络及其对应的去耦电容。 如果看到未连接的引脚或悬空的网络标签请指出。这段提示词不是固定的而是根据窗口标题和用户当前的操作上下文动态生成。如果窗口标题包含“PcbDoc”提示词就切换成 PCB 布局相关的分析指令。这种“图像 上下文提示词”的组合比单纯发一张图让 AI 自由发挥效果要好得多。6. 常见问题与排查技巧实录6.1 抓到的画面全黑或全白这是 PrintWindow 最常见的问题原因通常有三个窗口使用了硬件加速渲染部分硬件设计软件的新版本默认开启 GPU 渲染PrintWindow 的WM_PRINT消息无法获取 GPU 渲染的内容。解决办法是尝试加上PW_RENDERFULLCONTENTflag如果仍然无效需要在软件设置里关闭硬件加速或者降级到 BitBlt 窗口置顶的方案。窗口处于最小化状态最小化时窗口不渲染内容PrintWindow 可能返回空白。解决办法是先用ShowWindow(hwnd, SW_RESTORE)恢复窗口抓完再最小化回去。但这个操作会打扰用户所以我的策略是检测到最小化时直接跳过本次抓屏。位图未正确选入内存 DCSelectObject的返回值是旧对象必须保存并在最后恢复否则可能导致 DC 状态异常。这个错误很隐蔽表现为第一次抓屏正常后续全部失败。6.2 抓屏导致目标窗口闪烁或卡顿PrintWindow 是同步调用会阻塞目标窗口的消息循环。如果抓屏频率过高比如 500ms 一次硬件设计软件会出现明显的卡顿感。我的经验是抓屏间隔不低于 2 秒。抓屏操作放在setImmediate或setTimeout中异步执行避免阻塞主进程的其他任务。如果目标窗口正在执行耗时操作比如铺铜、DRC 检查暂停抓屏等操作完成后再恢复。可以通过检测窗口标题是否包含“正在处理”等关键词来判断。6.3 多窗口场景下的句柄失效硬件设计软件经常弹出对话框比如“选择器件”“配置规则”这些对话框是独立的顶层窗口会抢焦点。如果抓屏逻辑只匹配主窗口句柄当对话框弹出时主窗口可能被禁用PrintWindow 返回失败。我的处理方式是维护一个窗口句柄列表每次抓屏前重新枚举优先抓取当前活动窗口GetForegroundWindow如果活动窗口是对话框就抓对话框否则抓主窗口。6.4 常见问题速查表问题现象可能原因排查方法解决方案画面全黑硬件加速渲染加PW_RENDERFULLCONTENT测试关闭软件硬件加速或改用 WGC画面全白窗口最小化IsIconic判断跳过抓屏或恢复窗口画面尺寸错误DPI 缩放不一致对比GetClientRect与GetDIBits尺寸用GetDpiForWindow计算物理尺寸抓屏后窗口卡顿抓屏频率过高降低频率测试间隔不低于 2 秒异步执行句柄失效窗口被销毁或重建IsWindow判断每次抓屏前重新枚举窗口图像模糊缩放比例不当检查 resize 参数最长边不低于 1200 像素6.5 一个容易被忽略的细节窗口边框与阴影Windows 10/11 的窗口有圆角和阴影效果GetClientRect返回的客户区不包括这些装饰。但 PrintWindow 加PW_CLIENTONLY时某些软件会把绘图内容画到非客户区比如 Altium 的某些面板导致抓到的画面缺失边缘内容。我的做法是抓取整个窗口不加PW_CLIENTONLY然后用DwmGetWindowAttribute获取窗口的实际边框范围手动裁剪掉标题栏和边框。这样虽然多了一步裁剪但保证了内容的完整性。7. 抓屏之后的下一步从“看得见”到“看得懂”抓屏解决的是“AI 能看到什么”的问题但看到之后怎么理解、怎么把视觉信息转化为对硬件设计有用的建议是下一个要攻克的难关。我在实际项目中的体会是抓屏本身的技术难度并不算高真正花时间的是稳定性打磨——处理各种窗口状态、DPI 组合、软件版本差异。上面提到的那些坑每一个都让我调试了大半天。目前这套抓屏模块已经稳定运行在我的 AI 硬件设计辅助系统里配合视觉模型能够实现原理图模块识别、网络连接检查、PCB 布局初步审查等功能。后续我还会继续分享图像理解、提示词工程、多轮对话上下文管理等方面的实践经验。如果你也在做类似的事情或者对某个细节有疑问欢迎一起交流。