桌面自动化对AI撒谎？用三层架构重构信息输入层

1. 为什么桌面自动化会对 AI 撒谎

如果你正在做 AI Agent 相关的开发，大概率会遇到这样一个场景：你把一个截图丢给多模态大模型，告诉它“帮我看一下当前界面，然后点击登录按钮”。模型很认真地回答“好的，登录按钮在屏幕中央偏右位置”，然后你用代码去点那个坐标，结果点到了广告横幅上。

这不是模型变笨了，而是桌面自动化在向 Agent 传递信息时，一直在“撒谎”。

这里的“撒谎”不是恶意欺骗，而是指信息失真。桌面上任何一层传递链条出了问题，Agent 拿到的世界就不是真实世界。更麻烦的是，这种错误不像接口报错那么容易发现——Agent 往往不会主动告诉你“我看不清，我再确认一下”，而是基于错误的坐标和错误的状态继续执行，直到把整个流程带偏。

我花了大概 3 个月的时间，专门在处理这个问题的根因：如何让桌面自动化向 AI Agent 提供更接近真实状态的信息。这篇文章想把这段过程里最有价值的经验整理出来，包括桌面自动化的信息失真源头、可靠的信息提取方案、完整的代码示例，以及生产环境中必须注意的坑。如果你正在做基于桌面应用的 RPA、自动化测试或者 AI Agent，这篇文章应该能帮你避开不少弯路。

先说结论：解决“谎报军情”问题，核心不是换一个更强的模型，而是重构 Agent 的信息输入层。把“喂一张截图”升级为“喂一份经过校验的结构化桌面状态描述”，准确率提升会非常明显。

2. 桌面自动化的信息失真源头

要解决“说谎”问题，首先要知道谎言从哪来。桌面自动化的信息链条大致是：操作系统窗口系统 -> 自动化 API / 截图工具 -> 信息提取层 -> Agent 模型 -> 动作执行。失真可能发生在每个环节。

2.1 坐标信息失真

传统的桌面自动化高度依赖坐标。比如“点击 (x=520, y=380)”这种指令，在窗口固定、分辨率固定的理想环境下没问题，但一旦窗口移动、缩放，或者用户切换了 DPI 缩放，坐标就全部失效。

更隐蔽的是多显示器场景。Windows 中负坐标存在，macOS 中不同显示器的缩放系数不同，Linux 不同桌面环境的坐标原点也不一样。如果 Agent 拿到的屏幕尺寸和坐标系统与实际渲染不一致，点击就会指哪打哪，却打不中。

2.2 视觉信息失真

截图是给 AI Agent 喂视觉信息的常见方式，但截图本身包含大量失真：

• DPI 缩放导致截图分辨率与控件实际渲染尺寸不一致。
• 动态内容（如动画、进度条、loading 状态）在不同时刻截图差异很大。
• 透明窗口、毛玻璃效果、高光渲染会干扰 OCR 和图像识别。
• 光标本身可能遮挡目标控件。
• 窗口被部分遮挡时，截图只能看到最上层的窗口。

这些失真在人类看来无关紧要，但模型会基于截图里的每一个像素做推理。一个模糊的边框、一个高光，模型可能就脑补出一个不存在的按钮。

2.3 状态信息失真

这是最容易忽略的一层。很多控件拥有“可见但不可用”“加载中”“已选中”等状态，而这些状态无法单纯从像素判断。

举例来说：一个按钮在页面上渲染得和正常按钮一模一样，但它正处于 disabled 状态，点击后不会有任何反应。Agent 看到它，以为可以点击，执行后却发现什么都没发生。如果 Agent 没有校验结果，它就会继续尝试，甚至认为“系统没有响应”，从而做出错误决策。

2.4 语义信息失真

桌面界面上的图形，尤其是工具栏图标，存在严重的语义歧义。一个“放大镜”图标可能是“搜索”，也可能是“放大视图”；一个“齿轮”图标可能是“设置”，也可能是“高级选项”。OCR 只能识别文字，无法理解图标的语义。如果你告诉 Agent “找到设置按钮”，而界面上只有齿轮图标，模型可能识别不出来，或者把另一个类似的图标误认为设置。

这四种失真叠加，就会出现标题里描述的“desktop automation lying to AI agents”问题。也就是说，Agent 看到的世界，和真实世界之间存在一个不断累积的错误层。

3. 从坐标脚本到 AI Agent：事实来源的变迁

传统 RPA 工具解决上述问题的方式是：用固定坐标录屏回放，或者用控件选择器绑定元素。坐标方案精准但脆弱，控件选择器稳健但依赖应用是否暴露无障碍接口。

到了 AI Agent 时代，很多人以为可以直接跳过这些工作，用多模态模型“看懂”屏幕就行。实际项目跑下来，你会发现纯视觉方案在遇到复杂桌面应用时，准确率并不理想。

原因在于：模型“看到”的只是像素，而桌面应用的真实逻辑藏在控件树里。Windows 的 UI Automation（UIA）树、macOS 的 Accessibility 树、Linux 的 AT-SPI 树，这些才是桌面应用的“DOM 结构”。屏幕截图是“渲染结果”，控件树是“源代码”。只给 Agent 渲染结果，等于让一个程序员不看源码去猜页面逻辑。

过去构建桌面自动化，关键是找到“可靠的选择器”；今天构建 AI Agent，关键是找到“可靠的事实来源”。这个事实来源，应该是“屏幕视觉信息 + 控件树结构信息 + 状态信息”的组合，而不是单一的截图。

4. 三层架构：视觉层、结构层与校验层

要解决桌面自动化对 AI 的“说谎”问题，我最终落地的方案是一个三层架构：视觉层负责采集，结构层负责解析，校验层负责兜底。

• 视觉层：负责抓取屏幕截图、窗口位置、前台窗口信息。它的职责是提供空间的上下文。
• 结构层：负责读取控件树（Windows 上通常是 UIA，macOS 上是 Accessibility），把界面元素转为结构化的 JSON/文本描述。
• 校验层：在执行点击或输入动作后，重新读取控件树或截图，确认动作是否真正生效。

如果把 Agent 比作一个使用电脑的实习生，这三层分别对应：眼睛（视觉层）、手（执行动作）和检查习惯（校验层）。眼睛看到画面，手去操作，操作完回头确认有没有生效。缺少任何一层，实习生都会在工作中频频出错。

在实际代码实现中，视觉层可以用截图 + OpenCV 模板匹配做辅助定位，结构层用系统自动化 API 提取控件树，校验层用输出比对确认状态变更。这个组合方式能覆盖绝大多数桌面自动化场景。

5. 环境准备与前置条件

本文示例以 Windows + Python 为运行环境，因为 Windows 的 UIA 体系比较成熟，而且桌面 Agent 在 Windows 上最常见。macOS 和 Linux 的 API 思路一致，但调用方式略有不同，我会在文中单独提示。

建议的环境如下：

• 操作系统版本：Windows 10 或 Windows 11（版本以你实际项目为准）
• Python 版本：建议 3.9 或更高（本文示例代码用 3.10 验证过通用逻辑，不绑定具体版本）
• 需要安装的 Python 库：
  • pywinauto：Windows UI Automation 库，用于读取控件树和操作控件
  • pyautogui：屏幕控制库，用于截图、鼠标键盘操作
  • opencv-python：图像处理库，用于模板匹配
  • numpy：OpenCV 的依赖库
  • pillow：图像处理库

安装命令如下：

pip install pywinauto pyautogui opencv-python numpy pillow

如果你的环境中有虚拟环境，建议先创建并激活虚拟环境，避免污染全局 Python：

python -m venv venv venv\Scripts\activate pip install pywinauto pyautogui opencv-python numpy pillow

这里有一个容易踩坑的地方：pywinauto 在读取某些需要管理员权限的应用时，可能无法获取完整的控件树。如果你的 Agent 需要操作管理员权限的应用，最好让 Python 进程也以管理员权限运行，否则 UIA 读取会受到权限限制，返回的控件信息不完整。这一点在后面的常见问题中还会提到。

6. 核心流程拆解

整个信息提取流程，可以拆成四个步骤：获取窗口上下文、提取控件树、补充视觉定位信息、构造结构化上下文。下面逐一说明。

6.1 第一步：获取窗口上下文

Agent 需要知道自己在操作哪个窗口。这一步不仅记录窗口标题，还记录窗口矩形区域、是否最小化、是否前台等状态。

为什么需要窗口矩形？因为后续所有坐标计算都基于窗口内坐标，而不是全局屏幕坐标。把坐标锚定在窗口内部，窗口移动后，坐标仍然相对有效。

6.2 第二步：提取控件树

控件树是结构层的核心数据。通过 UIA 可以获取控件的类型、名称、自动化 ID、坐标矩形、状态（enabled/visible/selected）等信息。

但这里有个细节：不是每个控件都值得传给模型。一个复杂的桌面应用可能有几百个控件节点，如果全部塞给模型，既浪费 token，又容易干扰推理。更合理的做法是过滤出“可交互控件”，也就是按钮、输入框、下拉框、复选框、列表项等，并且去掉不可见或 disabled 的节点。

6.3 第三步：补充视觉定位信息

结构层输出控件矩形后，视觉层可以用截图验证目标区域是否真的存在视觉可见的控件。这个验证可以帮助解决有些应用没有正确暴露 UIA 属性的问题——比如某控件在 UIA 树里是空白名称，但屏幕上渲染出了明确的文字或图形。

此时可以用 OpenCV 模板匹配，把 UI 元素的模板图片放到截图中搜索，找到匹配区域后，与控件树的矩形做交叉校验。两者一致，说明元素真实存在；不一致，说明可能出现了“UIA 撒谎”或“截图偏移”。

6.4 第四步：构造结构化上下文

把前三步得到的信息组装成 Agent 可以消费的 JSON 结构。这个结构包含窗口信息、可交互控件列表、控件坐标、控件状态和视觉辅助描述。

直接给 Agent 原始控件树是一个常见误区。原始控件树的内部控制名、控件类型 ID 等噪音很多，Agent 很难直接判断“哪个是登录按钮”。更有效的做法是，把控件树中与业务操作相关的信息提取出来，生成一份精简的“桌面状态描述”，再配合截图一起交给模型。

这一步做得好不好，直接决定 Agent 的决策准确率。

7. 完整示例代码实现

下面我用一个实际的例子来演示：读取当前前台窗口，提取可交互控件，并构造一份结构化上下文。

7.1 示例代码：提取桌面状态

文件名：desktop_state.py

import json import time from pywinauto import Desktop, Application import pyautogui class DesktopStateExtractor: def __init__(self, top_level_only=True, min_width=10, min_height=10): self.top_level_only = top_level_only self.min_width = min_width self.min_height = min_height def get_active_window_info(self): """获取当前前台窗口信息""" win = Desktop(backend="uia").window_text() app = Application(backend="uia").connect(title_re=".*", timeout=5) active_window = app.window(handle=app.active_()) rect = active_window.rectangle() return { "title": active_window.window_text(), "class_name": active_window.class_name(), "left": rect.left, "top": rect.top, "right": rect.right, "bottom": rect.bottom, "width": rect.right - rect.left, "height": rect.bottom - rect.top, "is_active": True } def iter_controls(self, window, depth=0): """递归遍历控件树，返回可交互节点列表""" results = [] try: children = window.children() except Exception: return results for child in children: try: ctrl_type = child.element_info.control_type name = child.element_info.name enabled = child.element_info.is_enabled() visible = child.element_info.is_visible() # 只保留可交互控件类型 if ctrl_type in {"Button", "Edit", "ComboBox", "CheckBox", "ListItem", "RadioButton", "Hyperlink", "TreeItem", "TabItem"}: if enabled and visible: rect = child.rectangle() # 过滤过小元素，避免噪音 if (rect.right - rect.left >= self.min_width and rect.bottom - rect.top >= self.min_height): results.append({ "type": ctrl_type, "name": name, "control_id": child.element_info.automation_id, "left": rect.left, "top": rect.top, "right": rect.right, "bottom": rect.bottom, "width": rect.right - rect.left, "height": rect.bottom - rect.top }) if not self.top_level_only: results.extend(self.iter_controls(child, depth + 1)) except Exception: # 单个控件读取失败不阻塞整体 continue return results def extract(self): """提取当前桌面状态""" window_info = self.get_active_window_info() app = Application(backend="uia").connect(handle=pyautogui.getActiveWindow()._hWnd) main_window = app.active_() controls = self.iter_controls(main_window) # 只保留名称非空的控件，减少噪音 controls = [c for c in controls if c["name"] and c["name"].strip()] return { "window": window_info, "interactive_controls": controls, "timestamp": time.time() } if __name__ == "__main__": extractor = DesktopStateExtractor(top_level_only=False) state = extractor.extract() print(json.dumps(state, ensure_ascii=False, indent=2))

这段代码中，最关键的两个函数是get_active_window_info和iter_controls。前者告诉 Agent“我正对着哪个窗口”，后者把控件树过滤成可交互节点。控件类型的过滤条件可以根据你的业务场景调整，比如你关心列表项但不关心超链接，可以按需增删。

7.2 示例代码：基于截图校验控件是否真实渲染

控件树里的控件不一定真实可见。下面这段代码用截图裁剪目标区域，再判断该区域是否包含足够的视觉信息，用来和控件树的矩形做交叉校验。

文件名：visual_verify.py

import cv2 import numpy as np import pyautogui def verify_region_has_content(left, top, right, bottom, threshold=20): """ 通过截取屏幕指定区域，计算灰度方差，判断该区域是否包含视觉内容。 返回 True 表示区域有内容，False 表示区域可能是空白/纯色。 """ width = max(right - left, 1) height = max(bottom - top, 1) screenshot = pyautogui.screenshot(region=(left, top, width, height)) gray = cv2.cvtColor(np.array(screenshot), cv2.COLOR_RGB2GRAY) # 灰度方差低，说明区域内像素变化很小，很可能是空白区域 variance = gray.var() return variance >= threshold, variance # 示例：验证控件区域是否真实渲染 if __name__ == "__main__": content_exists, var = verify_region_has_content(100, 100, 300, 200) print(f"区域内容方差: {var:.2f}, 判定结果: {'有内容' if content_exists else '疑似空白'}")

为什么要做这一步？因为在某些渲染异常、窗口最小化或控件被遮挡的情况下，UIA 树里仍然报告控件存在，但屏幕上其实看不到。让 Agent 操作一个看不见的控件，会产生诡异的行为。视觉校验可以兜底这种异常。

7.3 示例代码：构造 Agent 可消费的结构化上下文

在得到控件树和视觉校验结果后，下一步是把信息组装成模型容易理解的 JSON 描述。这一步的关键是让模型只看到它需要的信息，而不是几百个控件节点全部堆给它。

文件名：build_context.py

import json from desktop_state import DesktopStateExtractor from visual_verify import verify_region_has_content def build_agent_context(): extractor = DesktopStateExtractor(top_level_only=False) raw_state = extractor.extract() window_info = raw_state["window"] controls = raw_state["interactive_controls"] rendered_controls = [] for ctrl in controls: has_content, _ = verify_region_has_content( ctrl["left"], ctrl["top"], ctrl["right"], ctrl["bottom"] ) if has_content: rendered_controls.append({ "type": ctrl["type"], "name": ctrl["name"], "center_x": (ctrl["left"] + ctrl["right"]) // 2 - window_info["left"], "center_y": (ctrl["top"] + ctrl["bottom"]) // 2 - window_info["top"], "enabled": True, "visible": True }) context = { "window": { "title": window_info["title"], "width": window_info["width"], "height": window_info["height"] }, "description": "当前窗口中的可交互控件如下，坐标使用窗口内部相对坐标。", "controls": rendered_controls } return context if __name__ == "__main__": context = build_agent_context() print(json.dumps(context, ensure_ascii=False, indent=2))

这段代码会把控件坐标转换为窗口内部相对坐标，这样窗口移动后，Agent 拿到的坐标仍然可以配合窗口矩形换算成真实屏幕坐标。这一步是避免“坐标谎报”的重要措施。

你可能会注意到，我没有直接把控件树的原始数据塞给模型，而是把它转成了以“控件名称和相对坐标”为核心的描述。模型看到的信息更接近人类的操作视角——“姓名输入框在窗口上方，登录按钮在输入框下方”，这种描述比“edit control with automation_id=1001 at rect(50, 60, 200, 100)”更不容易让模型混淆。

8. 运行结果与效果验证

运行上面的脚本前，可以先打开一个简单的桌面应用，比如 Windows 自带的记事本，并让它保持在前台。然后执行：

python desktop_state.py

如果一切正常，你会看到类似下面的输出（具体控件内容取决于你当前打开的应用）：

{ "window": { "title": "无标题 - 记事本", "class_name": "Notepad", "left": 100, "top": 100, "right": 1100, "bottom": 700, "width": 1000, "height": 600, "is_active": true }, "interactive_controls": [ { "type": "Edit", "name": "文本编辑器", "control_id": "15", "left": 100, "top": 130, "right": 1100, "bottom": 700, "width": 1000, "height": 570 }, { "type": "MenuItem", "name": "文件(F)", "control_id": "", "left": 100, "top": 105, "right": 160, "bottom": 130, "width": 60, "height": 25 } ], "timestamp": 1720000000.123 }

如何判断输出是否可靠？你可以人工核对几个点：

• 窗口标题是否与前台窗口一致。
• 控件名称是否能对应上界面上的实际文字。
• 控件矩形是否落在窗口矩形内部，且位置大致正确。
• 视觉校验时，那些被过滤掉的控件是不是真的看不见。

如果输出为空，或者控件数量异常少，优先检查是不是应用窗口没有处于前台，或者应用本身没有暴露 UIA 信息。不是所有应用都支持无障碍接口，比如某些自绘界面的游戏、视频渲染窗口，控件树里可能只有一个大的空白节点。这种情况需要依赖视觉方案补充。

9. 常见问题与排查思路

在实际项目里，我遇到过的桌面自动化问题基本都能归入下面这张表格。建议收藏备用。

这里要特别说明 DPI 缩放问题。在 Windows 上，如果系统缩放设为 125% 或 150%，pyautogui截图的屏幕坐标和真实物理像素坐标之间会存在换算差。最常见的表现是：Agent 说它看到了按钮在 (x, y)，你点击 (x, y) 却点到了按钮旁边。解决办法是在代码开头获取系统的缩放因子，并将所有屏幕坐标换算为物理坐标。如果你的项目也需要支持高分屏，这块一定要提前设计，不然后期返工的成本很高。

还有一个容易踩的坑是“窗口失焦”。当你用脚本连接窗口并读取控件树时，目标窗口必须处于活动状态。窗口一旦失焦或最小化，UIA 返回的坐标和可见性状态会变得不可靠。这也是为什么我在示例里先获取前台窗口信息再读取控件树，而不是直接写死窗口标题去连接。

10. 最佳实践与工程建议

解决桌面自动化对 AI “说谎”的问题，本质上是在做信息的可信度治理。下面几条工程建议，是这 3 个月里最有价值的沉淀。

10.1 永远不要只信单一信息源

单一信息源注定不可靠。UIA 可信，但自绘界面会失效；截图可信，但动态渲染和遮挡会造成误判；坐标可信，但 DPI 和窗口移动会让坐标偏移。正确的姿态是：用多个信息源互相校验，只有多方一致时，才把信息传给 Agent。

在代码实现上，这要求你建立类似“置信度”的概念。比如 UIA 和截图都确认同一个按钮存在，置信度就是“高”；只有 UIA 确认存在，置信度就是“中”；只有截图识别出来，置信度就是“低”。Agent 在决策时，可以根据置信度决定是直接操作还是先截图确认。

10.2 给 Agent 的是“事实”，不是“过程数据”

很多 Agent 项目直接把控件树、截图数组、原始日志全塞给模型，以为信息越多越好。实际效果恰恰相反：信息越多，噪音越多，模型越容易看到内容就编造解释。给模型的信息应该是“事实”而非“过程数据”。

什么是事实？窗口标题是事实，控件名称是事实，按钮的状态是事实，坐标是事实。什么是过程数据？UIA 内部的 element ID、控件类型数字编号、坐标堆栈、调试日志，这些不是模型决策必需的信息。

10.3 动作执行后必须做结果校验

Agent 执行完点击或输入动作之后，必须重新读取一次界面状态，确认动作是否真正生效。这个步骤就像是数据库事务中的“确认提交”。如果没有校验，Agent 就会面临“我以为点了保存，实际上没点中”的问题。

实现方式一般有两种：

• 状态变化校验：点击按钮后，读取界面状态是否出现预期变化（如弹窗出现、页面切换）。
• 截图对比校验：点击前后截图做差分，如果画面完全没有变化，说明点击可能没有生效。

推荐优先用状态变化校验，因为截图差分会受到动画、光标闪烁等因素干扰，误报率比较高。

10.4 抽象出“桌面状态 DSL”

如果你的 Agent 要处理多个桌面应用，建议抽象出一套统一的“桌面状态描述语言”（DSL）。比如统一用 type 表示控件类型，用 name 表示可见文本，用 center_x/center_y 表示相对窗口坐标。

这样做的好处是，Agent 侧只需要解析一套 JSON 格式，而不需要关心底层是 UIA 还是截图识别。无论遇到什么应用，最终交给模型的信息格式都是一致的。这不仅降低了模型的理解难度，也让后续扩展新应用变得简单。

10.5 建立自动化回归测试

桌面自动化和 Web 自动化一样需要回归测试。每改一次信息提取逻辑，都应该跑一遍覆盖核心流程的测试用例。测试建议分两层：

• 单元层：验证某个控件在某个状态下是否被正确提取。
• 场景层：验证 Agent 在真实界面上能否完成“打开应用 -> 输入信息 -> 点击提交 -> 看到成功提示”的完整流程。

界面自动化测试天然有不稳定性，但桌面 Agent 的失败往往发生在信息提取层，而不是模型推理层。把提取层的测试覆盖率提上去，Agent 的稳定性会显著改善。

10.6 注意安全与权限边界

桌面 Agent 与 RPA 工具一样，天然具备操作系统的控制能力。在开放给用户之前，需要认真考虑权限边界：

• Agent 只能操作指定窗口，不能随意切换到其他应用。
• 执行敏感动作前，必须让用户确认。
• 涉及输入账号密码的场景，不要在日志里记录键盘输入。
• 在 CI/CD 或生产环境跑自动化时，使用专用的测试账号和隔离的测试环境，避免误操作真实数据。

如果 Agent 连接到真实业务系统，建议在代码层面做强校验：窗口标题必须匹配白名单、提交前必读二次确认弹窗、操作记录完整留痕。

11. 哪些场景应该避开“三件套”方案

虽然前面讲的结构层 + 视觉层 + 校验层方案能解决大部分问题，但它并不是银弹。在以下几类场景中，这套方案仍然会遇到困难：

• 游戏界面：大多数游戏使用自绘渲染，UIA 几乎拿不到控件信息，截图又是动态画面，模板匹配很容易失效。
• 视频剪辑软件：时间轴控件大量依赖自定义绘制，标准控件树只有顶层窗口，控件层级全部丢失。
• Linux 环境下的某些老旧桌面应用：AT-SPI 适配不完整，读取控件树返回的信息很少。

遇到这些场景，比较务实的做法是降低 Agent 的自动化深度，只做“读取屏幕信息并给用户提示”，不做自动点击；或者改用更细粒度的视觉模型专门做控件检测。故意让 Agent 在不稳定环境里强行操作，只会把一个小问题放大成系统性灾难。

12. 总结与下一步实践方向

回到最初的问题：桌面自动化为什么会向 AI Agent 说谎？答案不是某一层的 bug，而是信息链条上每个环节都存在失真——坐标会漂移、截图会失真、状态会过期、语义会歧义。真正有效的解法，是把“信息提取”当作一个独立的、和模型推理同等重要的工程环节来对待。

这篇文章提供的三件事，值得你在实际项目中验证：

一是把“截图喂给模型”升级为“结构化桌面状态描述 + 截图辅助验证”。模型不是不能看图，而是不应该只看图就做操作决策。

二是把“控件树 + 截图 + 状态校验”组合成一套互相印证的信息管线。单一信息源都是不可靠的，只有交叉验证过的信息才值得信任。

三是把 Agent 的执行闭环变成“感知 -> 决策 -> 执行 -> 再校验”，而不是“感知 -> 决策 -> 执行”。没有校验环节的 Agent，在真实桌面环境里一定会出现“点击了但没生效”的幽灵操作。

如果你正在做一个桌面 Agent 项目，下一步建议这样做：先跑通上面三段示例代码，把当前环境下的控件树提取准确率统计出来，再设计一个最简单的“打开应用 -> 点击按钮”实验，对照本文的校验层思路加上结果确认。先在小场景里验证信息保真度，再扩展到复杂的业务流程。

桌面自动化和 AI Agent 的组合还很年轻，这个领域的核心问题不是模型不够聪明，而是我们给模型的世界还不够真实。把桌面状态如实、完整、可信地告诉模型，已经是当前阶段性价比最高的优化方向。