企业官网建设流程全解析

1. 这个11万star的项目到底在拆什么

第一次看到这个项目的star数，我以为是某个前端框架或者深度学习库。点进去才发现，它干的事情特别“朴素”——把软件界面拆成结构化的数据，让AI能看懂屏幕上有什么按钮、什么输入框、什么菜单。听起来简单，但真正上手跑通之后，我发现它解决的是一个长期被低估的痛点：让自动化脚本从“瞎点”变成“看着点”。

传统UI自动化是什么路子？你写个脚本，告诉它“点击坐标(320, 480)”，或者“找到文本为‘提交’的按钮”。前者换个分辨率就废了，后者遇到动态渲染或者多语言就抓瞎。而这个项目的思路是：先把当前屏幕的UI结构完整提取出来，转成类似HTML的层级树，再交给AI去理解“这个界面是干什么的”“下一步该点哪里”。这就好比以前你是蒙着眼睛在房间里摸开关，现在有人给你开灯了，还递给你一张房间布局图。

这个项目适合谁？三类人最应该关注：一是做RPA（机器人流程自动化）的开发者，你们肯定被元素定位折磨过；二是做AI Agent的团队，想让智能体操作桌面软件但苦于没有好的感知层；三是测试工程师，尤其是做跨平台UI测试的，这个工具能帮你省掉大量写选择器的时间。我花了大概两周时间，在Windows、macOS和Linux三个平台上都跑了一遍，踩了不少坑，也总结了一些官方文档里没写的经验。下面就从环境准备开始，一步步拆解怎么把这个“拆软件神器”真正用起来。

1.1 它和传统UI自动化工具的本质区别

很多人第一反应是：这不就是Appium、Selenium那套东西吗？我一开始也这么想，但实际用下来发现区别很大。Appium和Selenium的核心是“驱动”，它们通过WebDriver协议去操控浏览器或移动端，你需要告诉它具体操作哪个元素。而这个项目的核心是“解析”，它不负责点击，只负责把当前界面的UI结构完整地、结构化地提取出来。

打个比方：Selenium像是一个遥控器，你按哪个键它执行哪个动作；而这个项目像是一台扫描仪，它先把整个房间扫一遍，生成一张3D地图，然后你（或者AI）看着地图决定怎么走。这个区别决定了它的应用场景更偏向“感知层”而非“执行层”。你可以把它和任何自动化框架结合使用——用它的解析结果来驱动pyautogui做点击，或者喂给大语言模型做决策。

另一个关键区别是跨平台能力。传统方案里，Windows用UIAutomation，macOS用Accessibility API，Linux用AT-SPI，三套完全不同的接口。而这个项目在底层做了抽象，对外暴露统一的接口。我实测下来，同一段解析代码，在三个平台上都能跑，虽然底层调用的API不同，但返回的数据结构是一致的。这对需要跨平台部署的团队来说，省掉了大量适配工作。

1.2 拆解出来的数据长什么样

光说概念太虚，直接看数据。我在Windows上打开一个记事本，运行解析命令后，得到的是一个JSON格式的树形结构。每个节点包含这些字段：控件类型（Button、Edit、Menu等）、名称、坐标位置（左上角和右下角）、是否可见、是否可用、子节点列表。比如记事本的“文件”菜单，解析出来大概是这样的：

{ "type": "MenuItem", "name": "文件", "bounds": {"left": 10, "top": 30, "right": 60, "bottom": 55}, "visible": true, "enabled": true, "children": [ {"type": "MenuItem", "name": "新建", "bounds": {...}}, {"type": "MenuItem", "name": "打开", "bounds": {...}} ] }

这个结构的好处是，AI可以直接理解“文件菜单下面有新建和打开两个选项”，而不需要去猜像素。你可以把这个JSON喂给GPT-4，问它“我想保存文件，应该点哪里”，它能准确告诉你点“文件”然后点“保存”。我试过用纯截图让GPT-4识别，准确率大概七成，但用这个结构化数据，准确率能到九成五以上。原因很简单：截图有歧义，文字没有。

2. 环境搭建：三个平台各自的坑

官方文档给的安装步骤看起来很简单，就几行命令。但我实际跑下来，每个平台都有各自的坑，而且这些坑在文档里基本没提。下面按平台分开说，你可以直接跳到对应的部分。

2.1 Windows：权限和依赖库的隐形门槛

Windows上安装本身不复杂，pip install就能搞定。但第一次运行的时候，我遇到了两个问题。第一个是权限：如果你要解析的窗口是以管理员权限运行的，那你的Python脚本也必须以管理员身份运行，否则拿不到UI结构。这个坑很隐蔽，因为报错信息不会直接说“权限不足”，而是返回一个空的树。我一开始以为是代码写错了，排查了半天才发现是权限问题。

第二个是依赖库。这个项目在Windows上依赖comtypes和pywin32，这两个库在安装时可能会因为Python版本或者系统架构（32位 vs 64位）出现兼容性问题。我的建议是：直接用Python 3.9到3.11之间的版本，太新或太旧都容易出问题。另外，如果你用的是虚拟环境，确保在虚拟环境里也安装了这些依赖，不要只装在全局环境里。

还有一个实际使用中的细节：Windows的UI Automation接口在解析某些老旧软件（比如用Delphi或VB6写的程序）时，返回的控件树会非常扁平，所有控件都堆在一层，没有层级关系。这种情况下，你需要结合坐标信息来判断控件之间的包含关系。我写了一个简单的后处理函数，根据bounding box的包含关系重建树形结构，效果还不错。

2.2 macOS：辅助功能权限的授权流程

macOS的坑主要在权限上。系统有一个“辅助功能”权限，任何想读取UI结构的程序都必须获得这个权限。第一次运行脚本时，系统会弹窗提示你去“系统偏好设置 > 安全性与隐私 > 隐私 > 辅助功能”里勾选你的终端或者IDE。但问题是，如果你用的是iTerm或者VS Code，可能需要手动把它们的可执行文件拖进去，而不是在列表里勾选。

我遇到的一个诡异问题是：明明已经授权了，但脚本还是返回空树。后来发现是因为macOS的权限缓存机制——授权之后需要重启终端或者IDE才能生效。这个在官方文档里没写，我是试了三次才发现的。另外，如果你在CI/CD环境里跑，比如GitHub Actions的macOS runner，默认是没有辅助功能权限的，需要额外配置，这个后面会细说。

还有一点：macOS的Accessibility API在解析某些原生应用时，性能会比Windows差一些，尤其是控件数量多的时候。我实测解析一个复杂的Xcode界面，大概需要2到3秒，而同样复杂度的Windows界面只要0.5秒左右。如果你对实时性要求高，可能需要做缓存或者增量解析。

2.3 Linux：AT-SPI总线的配置细节

Linux上的坑最多，因为桌面环境太碎片化了。这个项目在Linux上依赖AT-SPI（Assistive Technology Service Provider Interface），你需要确保系统里安装了at-spi2-core和相关的Python绑定。在Ubuntu上，命令大概是：

sudo apt-get install at-spi2-core python3-pyatspi

但装完之后，还需要设置环境变量。默认情况下，AT-SPI总线可能没有启动，你需要手动启动它，或者在桌面环境的启动脚本里加上：

export GTK_MODULES=gail:atk-bridge export OOO_FORCE_DESKTOP=gnome

这两个环境变量的作用是让GTK应用和LibreOffice等程序把UI信息暴露给AT-SPI。如果不设置，你会发现只能解析到很少的控件，大部分应用返回的都是空树。我一开始在Xfce桌面环境下跑，怎么都拿不到Firefox的UI结构，后来换成GNOME才正常。所以如果你在Linux上遇到问题，先确认桌面环境是不是GNOME或KDE，这两个的兼容性最好。

另外，Linux上还有一个“无障碍总线”的概念。AT-SPI通过D-Bus通信，如果你的系统D-Bus配置有问题，也会导致解析失败。可以用dbus-monitor命令来调试，看看总线上有没有AT-SPI的消息。这个排查过程比较繁琐，但一旦配好，后续就很稳定了。

3. 核心API的调用逻辑与参数调优

环境配好之后，下一步就是调用核心API。这个项目对外暴露的接口不多，但每个接口都有一些参数值得细说。我用下来感觉，默认参数能覆盖80%的场景，但剩下20%的场景需要你理解参数背后的逻辑才能调好。

3.1 解析入口函数的选择策略

项目提供了两个主要的解析函数：一个是解析整个桌面（包括所有打开的窗口），另一个是解析指定窗口。我强烈建议用后者，原因有两个：一是性能，解析整个桌面在窗口多的时候非常慢；二是准确性，指定窗口能避免其他窗口的干扰。

指定窗口的方式有两种：通过窗口标题或者通过进程ID。窗口标题的方式更直观，但有个问题：如果标题是动态的（比如浏览器标签页会变），你就需要每次重新获取。进程ID的方式更稳定，但需要你先找到目标进程的PID。我的做法是结合使用：先用进程名找到PID，再用PID解析窗口。这样即使窗口标题变了，也不影响解析。

还有一个细节：解析函数有一个max_depth参数，控制解析的深度。默认是无限深，但实际用的时候建议设成5到8层。为什么？因为很多软件的UI树非常深，尤其是Web应用嵌入在桌面客户端里的情况，解析到十几层的时候，返回的数据量会爆炸，而且大部分深层节点对你做自动化决策没有帮助。我一般设成6层，既能拿到主要控件，又不会让数据量太大。

3.2 过滤与裁剪：让返回数据更干净

原始解析结果里有很多“噪音”控件，比如不可见的、被禁用的、纯装饰性的容器。这些控件对AI决策没有帮助，反而会干扰判断。项目提供了一个filter参数，可以按条件过滤。我常用的过滤条件有三个：

• visible=True：只保留可见控件
• enabled=True：只保留可用控件
• type not in ['Pane', 'Group']：排除纯容器控件

加上这些过滤之后，返回的数据量能减少60%到70%，而且AI的理解准确率会更高。我做过对比测试：不过滤的情况下，GPT-4判断“下一步点哪里”的准确率大概是85%；过滤之后，准确率提升到93%左右。原因很简单：噪音少了，关键信息就更突出。

还有一个裁剪技巧：如果你只关心某个区域内的控件，可以用bounds参数指定一个矩形区域，只解析这个区域内的控件。这在处理复杂界面时特别有用，比如你只想操作一个对话框，就可以把解析范围限制在对话框的坐标范围内，避免解析整个主窗口。

3.3 坐标系统的坑：逻辑像素与物理像素

坐标系统是很容易踩坑的地方，尤其是高DPI屏幕。在Windows上，如果系统缩放是150%，那UI Automation返回的坐标可能是逻辑像素，而pyautogui用的可能是物理像素。这两个不一致的话，你解析出来的控件位置和实际点击位置就会对不上。

我遇到的具体问题是：解析出来的按钮坐标是(100, 200)，但用pyautogui点击(100, 200)却点到了别的地方。后来发现是因为缩放比例的问题。解决方案是：在解析的时候，获取系统的DPI缩放比例，然后把逻辑坐标乘以缩放比例，转换成物理坐标。Windows上可以用ctypes.windll.shcore.GetScaleFactorForDevice(0)来获取缩放比例，macOS上可以用Quartz.CoreGraphics的相关接口。

Linux上相对简单，因为大部分桌面环境的缩放是在合成器层面处理的，AT-SPI返回的坐标通常就是物理坐标。但如果你用的是Wayland而不是X11，情况会更复杂，因为Wayland的安全模型不允许程序随意获取全局坐标。这种情况下，你可能需要依赖窗口管理器提供的接口，或者改用X11会话。

4. 和AI模型对接的实战方案

解析出UI结构只是第一步，真正的价值在于让AI基于这个结构做决策。我试过三种对接方案，各有优劣，下面分别说。

4.1 直接喂JSON给大语言模型

最简单的方式是把解析出来的JSON直接塞进GPT-4的prompt里，然后问它“我想完成XX操作，应该点哪个控件”。这个方案的好处是零训练成本，开箱即用。但有几个注意事项：

第一，JSON不能太大。GPT-4的上下文窗口虽然大，但塞太多数据会影响推理速度和准确率。我的经验是控制在2000个token以内，大概对应50到80个控件。如果控件太多，需要先做过滤和裁剪。

第二，prompt的设计很关键。我试过几种写法，效果最好的是这种结构：先描述当前界面的整体功能（比如“这是一个文本编辑器的主界面”），然后列出可操作的控件（用简洁的格式，比如“按钮：保存，位置：左上角”），最后给出任务描述。这样GPT-4能快速定位到相关控件。

第三，要处理模型返回的格式。我让GPT-4返回一个JSON，包含action（点击、输入、滚动等）和target（控件名称或坐标）。然后在代码里解析这个JSON，调用pyautogui执行。这个流程跑通之后，准确率能到90%以上，但偶尔会有幻觉，比如返回一个不存在的控件名称。我的做法是加一层校验：如果返回的控件名称不在解析结果里，就重新问一次，或者降级到坐标点击。

4.2 本地小模型的微调思路

如果你对延迟敏感，或者不想依赖外部API，可以考虑用本地小模型。我试过用Llama 3 8B做微调，训练数据就是“UI结构JSON + 任务描述 → 操作指令”这样的三元组。训练数据可以从实际使用中收集：每次人工操作之后，把当时的UI结构和操作记录下来，积累几百条之后就能微调了。

微调后的模型在特定软件上的准确率能到85%左右，虽然不如GPT-4，但延迟低很多，而且不需要联网。不过微调的成本不低，需要一张显存至少16GB的显卡，训练时间大概几个小时。如果你的场景比较固定（比如只操作某几个特定软件），微调是值得的；如果场景多变，还是用大模型更灵活。

4.3 混合方案：规则引擎兜底

纯AI方案有个问题：不稳定。同样的界面，模型可能这次判断对了，下次就错了。为了提高稳定性，我在AI决策之外加了一层规则引擎。规则引擎处理那些高频、固定的操作，比如“点击保存按钮”“关闭当前窗口”。这些操作不需要AI判断，直接用规则匹配就行。

规则引擎的实现很简单：维护一个“控件名称 → 操作”的映射表，解析出UI结构后，先查表，如果命中就直接执行，不命中再交给AI。这样能把AI的调用频率降低70%左右，整体稳定性也提升了不少。我实测下来，混合方案的端到端成功率能到95%以上，而纯AI方案大概在85%到90%之间波动。

5. 踩坑实录：那些文档没告诉你的问题

这一部分是我在实际使用中遇到的最棘手的几个问题，以及排查过程。如果你也遇到类似情况，可以按这个思路来。

5.1 解析结果为空：从权限到总线的完整排查链路

解析结果为空是最常见的问题，可能的原因有五六种。我总结了一个排查顺序，按这个顺序走，基本能定位到问题。

第一步，检查权限。Windows上确认脚本是否以管理员身份运行；macOS上确认辅助功能权限是否已授权并重启了终端；Linux上确认AT-SPI总线是否启动。这一步能解决60%的问题。

第二步，检查目标窗口是否在前台。有些系统只允许解析前台窗口的UI结构，如果目标窗口被其他窗口遮挡，解析会返回空。解决办法是用SetForegroundWindow（Windows）或activate（macOS）把目标窗口激活。

第三步，检查依赖库版本。这个项目的不同版本对依赖库的要求不一样，比如某个版本要求pywin32>=305，你装的是304就会出问题。用pip list确认一下版本，必要时升级或降级。

第四步，检查系统语言和区域设置。这个坑很隐蔽：某些系统在非英语区域设置下，UI Automation返回的控件名称可能是乱码或者空字符串。解决办法是把系统区域设置改成英语（美国），或者用控件的类型和坐标来识别，而不是依赖名称。

第五步，如果以上都没问题，那就是目标软件本身不支持无障碍接口。有些软件（尤其是游戏和某些专业工具）用的是自绘UI，不暴露标准的无障碍接口。这种情况下，这个项目就无能为力了，只能退回截图+OCR的方案。

5.2 动态界面的解析时机问题

很多软件的界面是动态的：菜单展开、对话框弹出、加载动画，这些都会改变UI结构。如果你在界面还没稳定的时候就解析，拿到的数据是不完整的。我遇到过一个典型场景：点击“文件”菜单后，菜单项有一个淡入动画，大概300毫秒。如果在动画过程中解析，只能拿到部分菜单项。

解决方案是加一个“等待稳定”的逻辑：解析之前，先连续解析两次，比较两次的结果是否一致。如果一致，说明界面稳定了；如果不一致，等200毫秒再试。这个逻辑我封装成了一个函数，调用起来很方便。实测下来，加上这个等待之后，解析准确率提升了15%左右。

还有一个相关的问题：某些操作会触发界面刷新，刷新过程中解析会拿到旧数据。比如点击“刷新”按钮后，列表内容会更新，但更新是异步的。这种情况下，你需要等待某个特定控件出现或消失，而不是简单等固定时间。我一般用“轮询+超时”的方式：每隔100毫秒解析一次，直到目标控件出现，或者超过5秒超时。

5.3 多显示器与虚拟桌面的坐标偏移

多显示器环境下，坐标系统会变得复杂。Windows上，主显示器的左上角是(0,0)，副显示器可能在左边（负坐标）或右边（正坐标）。如果你用pyautogui点击，它用的是虚拟桌面的坐标系，而UI Automation返回的可能是相对于某个显示器的坐标。这两个不一致的话，点击就会偏移。

我遇到的具体问题是：在双显示器环境下，解析出来的按钮坐标是(100, 200)，但实际点击却点到了主显示器的对应位置，而不是副显示器上的按钮。解决办法是获取每个显示器的偏移量，然后把控件坐标转换成虚拟桌面坐标。Windows上可以用win32api.EnumDisplayMonitors来获取显示器信息，macOS上可以用NSScreen.screens。

虚拟桌面（比如Windows的“任务视图”）是另一个坑。虚拟桌面里的窗口，UI Automation可能无法正确解析，因为窗口实际上不在当前桌面上。这种情况下，你需要先切换到目标窗口所在的虚拟桌面，再解析。这个操作在Windows上可以用IVirtualDesktopManager接口来实现，但需要额外的COM调用，稍微有点复杂。

6. 性能优化：从秒级到毫秒级的调优经验

默认配置下，解析一个中等复杂度的界面大概需要500毫秒到1秒。如果你需要高频解析（比如做实时监控），这个速度是不够的。我通过几个优化手段，把解析时间降到了100毫秒以内。

6.1 增量解析与缓存策略

全量解析每次都要遍历整个UI树，开销很大。但实际上，大部分界面的变化是局部的：可能只是某个文本框的内容变了，或者某个按钮的可用状态变了。增量解析的思路是：只解析发生变化的子树，其他部分用缓存。

实现方式有两种：一是监听UI事件（Windows上有UIAutomation的事件接口，macOS上有AXObserver），当事件触发时，只重新解析受影响的节点；二是定期做全量解析，但两次解析之间做diff，只更新变化的部分。第一种方式更高效，但实现复杂；第二种方式简单一些，适合对实时性要求不那么高的场景。

我用的是第二种方式：每500毫秒做一次全量解析，然后和上一次的结果做diff。如果diff很小（比如只变了几个节点），就只更新那几个节点；如果diff很大（比如界面切换了），就全量更新。这样在界面稳定的情况下，实际的计算量很小，解析时间能降到50毫秒左右。

6.2 并行解析与异步IO

另一个优化思路是并行化。UI树的各个子树之间是独立的，可以并行解析。Python里可以用concurrent.futures.ThreadPoolExecutor来实现。我试过开4个线程，解析时间从800毫秒降到了250毫秒左右。但要注意，UI Automation的接口不一定是线程安全的，多线程调用可能会出问题。我的做法是：主线程负责遍历树结构，把叶子节点的解析任务分发给线程池。这样既利用了并行，又避免了并发访问同一个接口。

异步IO是另一个方向。如果你用的是asyncio框架，可以把解析操作包装成异步任务，这样在等待解析结果的时候，可以同时做其他事情。不过UI Automation的底层是同步的，包装成异步只是表面上的异步，实际执行还是阻塞的。真正要异步，需要用多进程或者C扩展。这个成本比较高，一般场景下用线程池就够了。

6.3 裁剪解析范围的具体参数

前面提到过用bounds参数裁剪解析范围，这里展开说一下具体怎么设。假设你要操作一个对话框，对话框的坐标是(400, 300)到(800, 600)。你可以把bounds设成{"left": 400, "top": 300, "right": 800, "bottom": 600}，这样只解析这个区域内的控件。

但有个细节：有些控件的bounding box可能部分在区域内，部分在区域外。默认情况下，只要控件的中心点在区域内，就会被解析。如果你希望更严格，可以设置strict_bounds=True，这样只有完全在区域内的控件才会被解析。我一般用默认的非严格模式，因为部分在区域内的控件往往也是相关的。

裁剪之后，解析时间能减少50%到80%，具体取决于界面复杂度。我实测过一个复杂的设置界面，全量解析要1.2秒，裁剪到只解析当前标签页之后，只要200毫秒。这个提升非常明显。

7. 实际应用场景的落地案例

说了这么多技术细节，最后分享几个我实际落地的场景，让你更直观地理解这个工具能干什么。

7.1 跨平台软件测试的自动化巡检

我帮一个团队做过跨平台桌面软件的自动化测试。他们的软件有Windows、macOS、Linux三个版本，以前每个平台都要写一套测试脚本，维护成本很高。用这个工具之后，测试脚本只需要写一套：解析UI结构，然后根据控件名称和类型来断言。比如“检查主窗口是否有‘保存’按钮”“检查点击‘新建’后是否弹出了对话框”。

这个方案的好处是跨平台一致。同一段测试代码，在三个平台上都能跑，因为解析出来的数据结构是一样的。而且因为是基于UI结构而不是坐标，所以对分辨率和缩放的适应性也很好。他们原来跑一轮回归测试要2个小时，现在只要40分钟，而且误报率从15%降到了3%以下。

7.2 给RPA流程加上“眼睛”

另一个场景是RPA。传统的RPA流程很脆弱：网页改个版、软件换个皮肤，流程就断了。我帮一个做财务自动化的团队改造了他们的RPA流程：原来是用坐标点击，现在改成先解析UI结构，找到目标控件再点击。改造之后，流程的稳定性大幅提升，原来每周都要修几次，现在一个月都不用动。

具体做法是：在RPA的每个步骤之前，先调用解析函数，拿到当前界面的控件列表。然后用一个简单的匹配算法（按名称和类型匹配）找到目标控件，获取它的坐标，再调用pyautogui点击。如果找不到目标控件，就抛出异常并截图，方便排查。这个改造大概花了三天时间，但后续节省的维护时间远超这个投入。

7.3 辅助工具：让AI帮你操作复杂软件

最后一个场景比较有意思：我做一个辅助工具，帮助不熟悉复杂软件的用户完成操作。比如某个专业的视频编辑软件，菜单层级很深，新手找不到功能。这个工具的做法是：用户用自然语言描述想做什么（比如“把视频导出成MP4格式”），工具解析当前UI结构，喂给GPT-4，让GPT-4生成操作步骤，然后自动执行。

这个场景对准确率要求很高，因为操作错了可能会丢失数据。我的做法是加一个“确认”步骤：AI生成操作步骤后，先展示给用户看，用户确认后再执行。这样既降低了风险，又让用户学到了操作路径。实测下来，GPT-4在视频编辑软件上的操作准确率大概80%，加上用户确认之后，实际成功率能到95%以上。

8. 一些零散但重要的经验

最后分享几个零散的经验，都是我在实际使用中总结的，不一定系统，但都挺实用。

关于版本选择：这个项目更新很频繁，但新版本不一定稳定。我的建议是用比最新版晚一个版本，比如最新是2.5，你就用2.4。这样既不会太旧，又避开了最新版可能有的bug。另外，锁定依赖库的版本很重要，不要用pip install -U随便升级，很容易出现兼容性问题。

关于日志：解析失败的时候，日志非常重要。我建议在代码里加上详细的日志，记录每次解析的耗时、返回的控件数量、过滤前后的差异。这样出问题的时候，能快速定位是解析本身的问题，还是过滤逻辑的问题。我一般用Python的logging模块，把日志输出到文件，方便后续分析。

关于测试：这个工具本身也需要测试。我写了一个简单的测试脚本，用几个常见的软件（记事本、计算器、浏览器）做基准测试，每次升级版本或者改代码之后，跑一遍测试，确认解析结果没有大的变化。这个习惯帮我避免了好几次因为升级导致的意外问题。

关于社区：这个项目的社区很活跃，Issues里有很多有价值的讨论。我遇到的大部分问题，在Issues里都能找到答案。建议在使用之前，先花半个小时翻一翻最近的Issues，看看有没有你可能会遇到的坑。另外，项目的Discussions板块也有很多实战经验分享，比官方文档更接地气。

关于安全：这个工具能读取UI结构，意味着它能“看到”屏幕上的所有内容，包括敏感信息。如果你在共享环境或者生产环境使用，一定要注意权限控制，避免泄露敏感数据。我的做法是：在解析之前，先过滤掉包含敏感关键词的控件（比如“密码”“账号”），或者对解析结果做脱敏处理。这个在金融、医疗等场景下尤其重要。

关于扩展：这个项目的架构设计得不错，很容易扩展。比如你可以自定义解析器，支持特定的软件；或者自定义过滤器，按自己的需求裁剪数据。我写过一个自定义解析器，专门处理某个用Qt写的软件，因为默认的解析器拿不到Qt的控件树。扩展的方式是继承基类，实现几个关键方法，然后在配置里注册。这个在官方文档里有说明，但例子不多，需要自己摸索一下。