1. 项目概述当AI学会“用电脑”最近在GitHub上看到一个挺有意思的项目叫showlab/computer_use_ootb。这个名字直译过来是“开箱即用的电脑使用”听起来有点玄乎但它的核心目标非常明确让一个大型语言模型LLM能够像真人一样通过观察屏幕、理解指令然后操作鼠标和键盘来使用电脑完成各种任务。这可不是简单的“自动化脚本”。传统的自动化比如用Python的pyautogui写死坐标去点击或者用Selenium录制宏本质上都是“盲操”——程序不知道屏幕上发生了什么只是机械地执行预设步骤。一旦界面布局变了或者弹出一个意外的对话框整个流程就崩了。而computer_use_ootb想做的是“有眼睛和手的AI”。它让AI模型比如GPT-4V、Claude 3 Opus这类多模态模型实时“看到”你的电脑屏幕截图理解当前的状态打开了什么窗口、按钮在哪里、输入框里有什么文字然后根据你的自然语言指令比如“帮我把桌面上的报告.docx重命名为‘最终版.docx’”自主规划一系列操作移动光标、点击、打字、滚动最终完成任务。这个项目解决的核心痛点是人机交互的“最后一公里”。我们有了强大的语言模型能理解复杂意图也能生成代码但如何让这些能力无缝地作用于我们每天使用的图形界面GUI上computer_use_ootb提供了一个端到端的框架试图打通从“意图理解”到“物理操作”的完整链路。它适合任何对AI智能体AI Agent、自动化、人机交互前沿感兴趣的朋友无论是想了解原理的研究者还是想打造个人效率助手的开发者都能从中获得启发。2. 核心架构与工作原理拆解要理解这个项目我们不能只看它做了什么更要看它是如何做到的。整个系统的设计思路可以类比为一个坐在电脑前的人类助手的工作流程。2.1 核心组件眼、脑、手整个系统由三个核心模块构成它们协同工作形成了一个完整的感知-决策-执行闭环。1. 视觉感知模块The “Eye”这是系统的输入。它的任务很简单定时捕获电脑屏幕的图像。但关键在于捕获的“策略”。它不能无脑地每秒截屏60次那样会产生海量冗余数据给后续的模型推理带来巨大负担。常见的策略包括变化触发只有当屏幕像素发生显著变化比如新窗口弹出、内容更新时才捕获新帧。固定频率智能去重以较低频率如每秒1-2帧截屏并结合图像哈希算法过滤掉内容几乎相同的连续帧。区域聚焦结合操作系统API只截取当前活动窗口或特定区域减少需要处理的数据量。 项目通常会使用像mss(跨平台) 或pyautogui、PIL.ImageGrab(Windows/macOS) 这样的库来实现屏幕捕获。2. 智能决策模块The “Brain”这是整个系统的核心也是最复杂的部分。它接收来自“眼睛”的屏幕截图和来自用户的自然语言指令然后输出一个具体的“动作计划”。这个模块通常由一个多模态大语言模型MLLM来担任。 它的工作流程是情境理解模型分析屏幕截图识别出所有UI元素按钮、输入框、图标、文本及其状态是否可点击、是否有焦点、内容是什么。这要求模型具备强大的视觉-语言理解能力。任务规划结合用户指令“登录邮箱把收件箱里来自‘老板’的未读邮件标记为已读”和当前屏幕状态模型需要将复杂任务分解成一系列原子操作步骤。例如[找到浏览器图标并点击] - [在地址栏输入邮箱网址] - [找到用户名输入框并点击] - [输入用户名] - ...动作生成为每个原子步骤生成具体的、可执行的指令。这里的指令不是自然语言而是一种结构化的动作描述。computer_use_ootb项目很可能定义了一套自己的动作规范Action Schema例如{ action: click, target: {type: button, text: 登录}, coordinates: {x: 800, y: 300} // 可选作为目标描述的补充 }或者更简单的直接输出坐标和操作类型{type: “move_and_click”, “x”: 800, “y”: 300}。3. 动作执行模块The “Hand”这个模块负责将“大脑”输出的结构化动作指令转化为操作系统级别的输入事件。它相当于一个机器人流程自动化RPA的执行器。鼠标控制模拟鼠标移动、点击左键、右键、双击、拖拽、滚动。常用库有pyautogui,pynput(更底层可控性更强)。键盘控制模拟键盘按键包括组合键如CtrlC、输入字符串。同样使用pyautogui或pynput。精准定位这是难点之一。模型可能只给出了一个模糊的目标描述“点击登录按钮”。执行模块需要将描述与屏幕上的实际元素对应起来。有几种策略坐标直接执行如果模型输出了绝对坐标直接移动鼠标到该坐标点击。但屏幕分辨率变化或窗口移动会导致坐标失效。元素匹配后执行结合OCR光学字符识别和图像模板匹配在屏幕上寻找与描述匹配的元素计算其中心坐标后再操作。这更健壮但计算开销更大。注意在实际部署中出于安全考虑操作系统尤其是macOS和最新版的Windows会对程序化模拟输入进行严格限制需要用户手动授予“辅助功能”或“输入监听”权限。这是所有自动化工具都会遇到的坎。2.2 工作流闭环与反思机制一个健壮的AI智能体不能只会“莽”。computer_use_ootb这类项目通常会实现一个闭环工作流观察捕获当前屏幕状态S_t。思考将S_t和用户指令I输入给MLLM模型输出动作A_t和对下一步的预测S_{t1}。执行执行模块执行动作A_t。再观察等待短暂时间让界面响应捕获新的屏幕状态S_{t1}。验证与反思比较实际的S_{t1}和模型预测的S_{t1}。如果差异巨大比如预期中该出现的窗口没出现说明动作可能失败了。此时系统会将“失败状态”反馈给模型要求它重新分析并制定新计划。这个“反思”环节对于处理异常情况至关重要。3. 关键技术细节与选型考量要实现一个稳定可用的“AI电脑使用者”在技术选型和细节处理上有很多门道。下面我结合常见实践拆解几个关键点。3.1 多模态模型的选择与提示工程“大脑”选谁这直接决定了系统的上限。闭源模型 vs. 开源模型闭源GPT-4V, Claude 3, Gemini Pro Vision优势是能力强对复杂场景和模糊指令的理解好能生成高质量的动作规划。劣势是API调用有成本、有延迟且数据需要出境在某些场景下可能存在合规与隐私顾虑。开源LLaVA, Qwen-VL, CogVLM优势是本地部署数据隐私有保障可定制化微调。劣势是整体能力尤其是复杂推理和细粒度空间理解通常弱于顶级闭源模型且本地部署需要较强的GPU资源。选型心得对于原型验证和追求极致效果GPT-4V或Claude 3 Opus是首选。如果任务相对简单固定或者对隐私、成本极度敏感可以尝试微调一个优秀的开源VLM。computer_use_ootb项目为了体现“开箱即用”OOTB很可能会优先支持通过API调用闭源模型因为这对大多数用户来说门槛最低。提示词Prompt设计 这是驱动模型正确工作的“咒语”。一个好的提示词需要明确告诉模型角色你是一个可以操作电脑的AI助手。能力你可以看到屏幕截图并输出特定的动作指令。动作规范清晰定义所有可用的动作类型click, type, scroll, press_key等、格式必须是严格的JSON和每个参数的涵义。思考链Chain-of-Thought要求鼓励模型先一步步推理“我需要先找到文件资源管理器窗口...”再输出动作。这能显著提升动作的准确性和可解释性。安全与边界明确禁止模型执行某些危险操作如删除系统文件、访问特定网站并设定单次任务的最大步骤数防止陷入死循环。3.2 屏幕理解的粒度从像素到语义模型“看”屏幕看的是什么是纯粹的像素阵列还是带有语义的结构化信息这里有不同的技术路径端到端像素到动作最“暴力”也最理想的方式。将屏幕截图直接扔给一个端到端的模型比如一个基于Transformer的架构让它同时完成视觉理解和动作生成。但这需要海量的屏幕截图动作序列配对数据进行训练数据获取和标注成本极高目前还不成熟。视觉理解动作规划两阶段这是当前主流且实用的方法。也是computer_use_ootb最可能采用的方式。第一阶段视觉理解。将截图输入MLLM要求其用自然语言或结构化数据描述屏幕。例如“屏幕中央是一个Chrome浏览器窗口正在访问Gmail。页面顶部有一个搜索框右侧有一个‘撰写’按钮。收件箱列表中有3封未读邮件其中一封标题是‘项目更新’发件人是‘张三’。”第二阶段动作规划。将这份“场景描述”连同用户指令再次输入给MLLM或同一个模型的不同调用让其生成动作序列。这种方式降低了对模型“像素级”空间理解的要求利用了大语言模型强大的文本推理能力效果更好也更节省上下文长度因为用文本描述代替了高分辨率图片。结合UI底层信息在桌面端我们可以通过操作系统提供的辅助功能API如Windows的UI Automation, macOS的Accessibility直接获取窗口和控件的层级结构、类型、名称、状态等元数据。这比从像素中识别要精确和稳定得多。一个更强大的系统可以融合像素截图和UI元数据给模型提供最丰富、最准确的环境信息。例如模型可以知道“这个可点击的区域是一个名为‘btnSubmit’的按钮”而不仅仅是“图片里有一块蓝色的矩形”。3.3 动作执行的可靠性与容错让鼠标精准点击到目标听起来简单实则暗坑无数。定位策略混合使用绝对坐标快但不稳定。仅作为其他方法的补充或最后手段。相对坐标/区域点击如果模型能识别出目标元素的大致区域一个边界框可以让鼠标移动到该区域内的一个随机点进行点击避免总是点击同一个像素而被检测为机器人。基于特征的查找这是更可靠的方法。结合OCR获取屏幕上所有文本及其位置当模型指令是“点击‘保存’按钮”时就在OCR结果里查找文本内容包含“保存”且控件类型可能是按钮的区域。也可以使用图像模板匹配但模板对UI主题、缩放变化敏感。操作间的等待与同步 这是新手最容易忽略的地方。点击一个按钮后程序必须等待足够的时间让新界面加载出来才能进行下一步操作。这个等待时间不能是固定的time.sleep(2)因为网络或电脑性能会导致加载时间波动。最佳实践是采用“条件等待”在预期会出现新元素的位置持续截图并检测直到目标元素出现通过OCR或图像匹配判断或者超过最大超时时间。例如点击“登录”后就循环检测屏幕上是否出现了“收件箱”字样或用户头像图标。引入随机延迟在连续操作之间加入微小且随机的延迟如0.5秒 ± 0.2秒使操作序列更像人类行为避免被一些简单的反自动化机制检测。异常处理与状态恢复 必须假设任何一步都可能失败。系统需要监控异常并有一套恢复策略。超时处理任何一个“条件等待”如果超时则触发失败处理流程。状态回滚记录关键操作前的状态。如果一系列操作失败可以尝试回退到上一个稳定状态例如按ESC键关闭可能意外弹出的窗口或者激活原始的任务窗口。失败反馈循环如前所述将失败后的屏幕状态和错误信息如“等待了10秒仍未找到‘下一步’按钮”反馈给大模型让它尝试新的策略比如“可能按钮被遮挡了先滚动一下页面看看”。4. 从零搭建一个基础原型实操指南理解了原理我们不妨动手搭一个最简单的版本体验一下整个流程。这里我们用一个“模拟”场景来避免直接操作真实桌面可能带来的风险但核心逻辑完全一致。4.1 环境准备与依赖安装我们使用Python因为它有最丰富的库生态。假设我们要实现一个能“看到”模拟计算器界面并操作它的AI。# 创建虚拟环境推荐 python -m venv ai_computer_agent_env source ai_computer_agent_env/bin/activate # Linux/macOS # ai_computer_agent_env\Scripts\activate # Windows # 安装核心依赖 pip install openai # 用于调用GPT-4V API pip install pillow # 用于图像处理 pip install pyautogui # 用于模拟鼠标键盘在模拟环境中我们可能不用其截图功能 pip install mss # 高效的跨平台截图库 pip install requests为了模拟我们用一个简单的Tkinter图形界面来充当“电脑屏幕”。4.2 构建一个模拟的“桌面环境”我们先创建一个simulated_desktop.py文件里面有一个简单的计算器界面。import tkinter as tk class SimulatedCalculator: def __init__(self, root): self.root root root.title(模拟计算器) self.entry_var tk.StringVar() self.entry tk.Entry(root, textvariableself.entry_var, font(Arial, 14), justifyright) self.entry.grid(row0, column0, columnspan4, stickyew, padx5, pady5) self.entry_var.set(0) buttons [ (7, 1, 0), (8, 1, 1), (9, 1, 2), (/, 1, 3), (4, 2, 0), (5, 2, 1), (6, 2, 2), (*, 2, 3), (1, 3, 0), (2, 3, 1), (3, 3, 2), (-, 3, 3), (0, 4, 0), (., 4, 1), (, 4, 2), (, 4, 3), (C, 5, 0) ] for (text, row, col) in buttons: btn tk.Button(root, texttext, font(Arial, 12), width5, height2, commandlambda ttext: self.on_button_click(t)) btn.grid(rowrow, columncol, padx2, pady2) def on_button_click(self, char): current self.entry_var.get() if char C: self.entry_var.set(0) elif char : try: result eval(current) self.entry_var.set(str(result)) except: self.entry_var.set(Error) else: if current 0 or current Error: self.entry_var.set(char) else: self.entry_var.set(current char) def get_screenshot_as_image(self): 模拟截图将Tkinter窗口渲染为PIL Image对象 from PIL import ImageGrab # 获取窗口位置和大小 x self.root.winfo_rootx() y self.root.winfo_rooty() width self.root.winfo_width() height self.root.winfo_height() # 截取窗口区域 screenshot ImageGrab.grab(bbox(x, y, xwidth, yheight)) return screenshot if __name__ __main__: root tk.Tk() app SimulatedCalculator(root) root.mainloop()运行这个文件你会看到一个图形化的计算器。我们的AI智能体目标就是操作它。4.3 实现核心智能体循环接下来我们创建主程序ai_calculator_agent.py。为了简化我们直接使用OpenAI的GPT-4 Turbo with Vision假设你有API Key并模拟点击操作实际项目中会用pyautogui去点真实坐标。import base64 import json import time from io import BytesIO from openai import OpenAI from PIL import Image import simulated_desktop # 导入我们刚才写的模拟计算器 # 初始化OpenAI客户端和模拟桌面 client OpenAI(api_key你的API_KEY) # 请替换为你的API Key root tk.Tk() calculator_app simulated_desktop.SimulatedCalculator(root) root.update() # 确保窗口渲染出来 def encode_image_to_base64(pil_image): 将PIL Image对象转换为Base64字符串用于API传输 buffered BytesIO() pil_image.save(buffered, formatPNG) return base64.b64encode(buffered.getvalue()).decode(utf-8) def get_screenshot(): 获取当前模拟计算器的屏幕截图Base64格式 img calculator_app.get_screenshot_as_image() return encode_image_to_base64(img) def ask_ai_for_action(screenshot_b64, user_instruction): 将截图和指令发送给GPT-4V请求它返回下一步动作 prompt f 你是一个可以操作图形界面应用程序的AI助手。你会看到一张应用程序的截图。 你的任务是根据用户的指令决定下一步做什么操作并严格按照以下JSON格式输出动作。 当前用户指令是{user_instruction} 可用的动作类型 1. click: 点击一个按钮。你需要提供按钮上显示的文本。 2. type: 在输入框当前显示数字的地方输入一串字符。提供要输入的字符串。 3. press_key: 模拟按下键盘键。提供键名如 enter, escape。本例中可能用不到 4. done: 任务已完成无需进一步操作。 **只输出一个合法的JSON对象不要有任何其他解释。** 示例1用户说“输入123”你看到计算器界面。 输出{{action: type, content: 123}} 示例2用户说“计算1加2等于多少”你需要规划多个步骤。但本次只输出**下一步**动作。 首先你需要点击按钮来输入“1”“”“2”“”。所以第一步是 输出{{action: click, target_text: 1}} 现在请分析下面的截图并输出下一步动作的JSON。 response client.chat.completions.create( modelgpt-4-vision-preview, # 或 gpt-4-turbo messages[ { role: user, content: [ {type: text, text: prompt}, { type: image_url, image_url: { url: fdata:image/png;base64,{screenshot_b64} } } ] } ], max_tokens300, ) # 解析返回的JSON try: result response.choices[0].message.content.strip() # 模型有时会在JSON外加json 标记需要去除 if result.startswith(json): result result[7:] if result.endswith(): result result[:-3] action_dict json.loads(result) return action_dict except json.JSONDecodeError as e: print(f解析AI返回的JSON失败: {e}) print(f原始返回: {result}) return None def execute_action(action_dict): 执行AI返回的动作指令在我们的模拟环境中 action_type action_dict.get(action) if action_type click: target_text action_dict.get(target_text) print(f[执行] 模拟点击按钮: {target_text}) # 在实际模拟中我们直接调用计算器的方法 calculator_app.on_button_click(target_text) root.update() # 更新界面显示 time.sleep(0.5) # 模拟操作间隔 elif action_type type: content action_dict.get(content) print(f[执行] 模拟输入: {content}) # 这里简化处理将输入内容逐个字符作为按钮点击 for char in content: if char in 0123456789.-*/: calculator_app.on_button_click(char) root.update() time.sleep(0.1) time.sleep(0.5) elif action_type done: print([执行] 任务完成。) return True # 返回True表示任务结束 else: print(f[警告] 未知动作类型: {action_type}) return False def main_loop(user_instruction): 主控制循环 print(f开始执行指令: {user_instruction}) max_steps 10 # 防止无限循环 for step in range(max_steps): print(f\n--- 步骤 {step1} ---) # 1. 观察 screenshot_b64 get_screenshot() # 2. 思考 action ask_ai_for_action(screenshot_b64, user_instruction) if not action: print(AI未返回有效动作终止。) break print(f[AI决策] {action}) # 3. 执行 task_done execute_action(action) # 4. 检查是否完成 if task_done: print(指令执行完毕) break # 简单验证如果AI连续返回相同动作可能卡住了 # 这里省略复杂的验证/反思逻辑 else: print(f达到最大步骤数({max_steps})强制终止。) final_screenshot calculator_app.get_screenshot_as_image() final_screenshot.save(final_result.png) print(最终界面已保存为 final_result.png) if __name__ __main__: # 启动Tkinter事件循环在另一个线程此处简化实际需用线程 # 为了演示我们这里用一个简单的指令 import threading threading.Thread(targetroot.mainloop, daemonTrue).start() time.sleep(2) # 等待窗口启动 user_command 计算125乘以8等于多少 main_loop(user_command) # 程序结束后可以手动关闭计算器窗口这个示例虽然简陋但完整演示了“观察-思考-执行”的闭环。AI会看到计算器截图分析用户指令然后一步一步地点击按钮来完成计算。你需要将你的API_KEY替换成有效的OpenAI API Key才能运行。实操心得在真实项目中get_screenshot函数会使用mss捕获真实屏幕execute_action会使用pyautogui移动真实鼠标并点击。但核心架构与此完全一致。这个模拟 demo 完美避开了环境依赖和权限问题是学习和调试智能体逻辑的绝佳起点。5. 深入挑战与进阶优化方向构建一个玩具原型很有趣但要让computer_use_ootb这样的项目真正“可用”还需要解决一系列严峻的挑战。5.1 长上下文与状态管理复杂的任务如“整理我下载文件夹里过去一周的所有PDF文档按日期重命名并移动到‘已处理’文件夹”可能需要几十甚至上百个步骤。大语言模型的上下文长度是有限的。问题不能把整个操作历史所有截图和动作都塞进提示词。解决方案压缩历史只保留最近几步的高清截图和动作对于更早的步骤用简短的文本摘要代替例如“步骤1-5打开了文件资源管理器并导航到下载目录”。分层任务规划先让模型做一个高级规划将大任务分解为几个原子性子任务子任务1筛选PDF子任务2重命名子任务3移动。然后分别执行每个子任务每个子任务内部维护自己的短期记忆。这类似于人类做事时的“心里有谱”。利用外部记忆使用向量数据库存储历史观察和动作当需要回顾时根据当前状态检索最相关的历史片段而不是全部加载。5.2 处理模糊指令与复杂UI“帮我把那个文件发给我同事” – “那个文件”是哪个“同事”的邮箱是什么真实的指令往往是模糊的。解决方案主动询问Ask for Clarification当模型无法确定时应该输出一个特殊的动作比如{action: ask_user, question: 请问您想发送哪个文件请指出文件名。}。系统会暂停执行将问题展示给用户等待用户反馈后再继续。利用系统上下文智能体可以访问一些系统信息如当前用户的联系人列表、最近打开的文档等来帮助消解歧义。例如当用户说“同事”模型可以查询通讯录列出最近联系过的几个人让用户选择。对复杂UI的鲁棒性面对动态加载、无限滚动、非标准控件如自定义绘制的按钮纯视觉方法可能失效。此时需要融合UI自动化框架如Playwright, Selenium对于WebPyWinAuto, Appium对于桌面和移动端。这些框架可以直接获取DOM或控件树提供比像素更稳定和语义化的信息。5.3 效率、成本与延迟优化实时截屏、调用大模型、执行动作这个循环必须足够快才能有流畅的体验。截图优化如前所述采用差异捕获、降低分辨率在满足识别精度的前提下、只截取活动窗口等技术。模型调用优化小模型协同用一个小而快的模型或本地模型处理简单的、重复性的识别任务如“当前焦点是否在输入框”只有遇到复杂场景时才调用强大的GPT-4V。缓存对于相似的屏幕状态比如同一个登录界面模型的分析结果可以缓存起来重复使用。并行与流式思考模型推理和执行鼠标移动在某些情况下可以部分重叠。动作预测与批处理高级的模型可以预测一连串动作“点击A后很可能会点击B”然后以更快的速度批量执行减少观察-思考的循环次数。5.4 安全与伦理边界这是一个拥有巨大潜力和风险的技术。一个能操作电脑的AI如果被恶意使用后果不堪设想。必须内置的安全护栏操作确认对于高风险操作删除文件、转账、发送邮件、安装软件必须暂停并弹出明确提示要求用户手动确认。沙盒环境在学习和测试阶段应在虚拟机或受限制的沙盒环境中运行。指令白名单/黑名单明确界定AI可以执行和禁止执行的操作类型。权限最小化以最低必要的系统权限运行智能体进程。项目设计考量computer_use_ootb这类开源项目在提供强大能力的同时必须在文档和代码中反复强调安全风险并提供易于配置的安全策略模块。让使用者尤其是开发者清醒地意识到自己正在赋予程序何种权限。6. 典型应用场景与未来展望尽管挑战重重但“让AI使用电脑”这个方向的应用前景极其广阔。6.1 近期的实用化场景无障碍辅助为行动不便或视障人士提供强大的电脑操作助手通过语音指令完成复杂的图形界面交互。软件测试自动化自动执行探索性测试Exploratory Testing模拟用户随机操作发现意料之外的软件缺陷。它能理解错误弹窗并记录下来比传统的脚本测试更智能。个人工作效率倍增器数据搬运工跨平台、跨应用的数据整理和录入。例如“把这份Excel表格里的数据填到网页版的CRM系统中”。日常操作宏将一系列复杂的、非标准化的操作如每周从几个不同格式的报告中提取数据生成周报固化下来只需一句指令即可触发。软件上手助手打开一个陌生的专业软件如Photoshop直接告诉AI“我想把这张照片的背景去掉并调亮肤色”AI可以尝试操作软件来实现。IT运维与支持自动完成一些标准的系统配置、日志收集、故障排查步骤减轻运维人员的重复劳动。6.2 中远期的演进方向从“操作”到“理解与创造”未来的AI助手不仅能操作现有软件还能基于对软件功能的理解组合创造出新的工作流。例如你告诉它“我想做一个关于市场趋势的PPT”它可能会自动打开浏览器搜索资料用Python分析数据生成图表最后打开PowerPoint将文字和图表排版成幻灯片。多模态交互的融合结合语音、手势、眼动追踪形成更自然的人机协同。AI不仅是执行者更是预测者能根据你的工作习惯和当前上下文主动提供建议或提前准备好下一步所需的界面。操作系统级集成也许未来的操作系统会原生内置这样一个AI智能体内核所有应用程序都通过一套标准的可访问性接口向其暴露功能和状态使得AI能够以更高效、更安全的方式与所有软件交互彻底打破应用之间的壁垒。showlab/computer_use_ootb这个项目正是迈向这个未来的一块重要基石。它把那些曾经只存在于论文和演示中的概念打包成了一个可供开发者探索和构建的原型。虽然距离真正的“开箱即用”还有很长的路要走但它清晰地指明了方向AI将不再仅仅是对话的伙伴或内容生成器而是能直接在我们数字世界中动手干活的智能体。作为开发者理解其原理亲手尝试构建不仅能帮助我们掌握前沿技术更能激发我们去思考如何设计下一代的人机交互界面。毕竟当AI成为用户时我们的软件又该如何被“使用”呢