过去两年，AI 助手的能力边界很清晰——它只能在你当前打开的那个应用里干活。你在 Word 里问它改文案，它帮你改；你在浏览器里让它总结网页，它总结。但一旦任务涉及"先从邮件里提取附件，再在表格里填数据，最后发一条消息通知同事"，AI 就卡住了。每个应用是一座孤岛，AI 被困在岛上。
deepin 的小U同学 3.0 要做的，是让 AI 从"应用级"跳到"OS 级"——直接操控桌面上的多个软件，像真人坐在电脑前一样点击、输入、切换窗口，完成跨应用的复杂流程。6 月 10 日晚的直播主打真机实测，不是 PPT 画饼，这一点值得关注：跨应用操控的可靠性，只有实机演示才能验证。
应用级 AI vs. OS 级 AI：差距在哪？
应用级 AI 的典型形态是插件或侧边栏。它只能读取当前应用的上下文，调用当前应用暴露的 API。好处是安全边界清晰，坏处是能力被锁死在单个应用里。
OS 级 AI 的思路完全不同。它站在操作系统层面，拥有：
- 窗口管理能力：识别屏幕上的窗口列表，切换焦点，调整布局。
- 输入模拟能力：向任意窗口发送键盘输入、鼠标点击。
- 屏幕理解能力：通过视觉模型识别界面元素，而非依赖应用主动提供 API。
- 流程编排能力：把多个步骤串成一个可执行的自动化链路。
这意味着 AI 不需要等每个软件厂商开放接口，它直接"看"屏幕、"操作"界面，和人用电脑的方式一致。
跨应用场景的真实需求
说几个实际场景，这些是单应用 AI 做不到、但 OS 级 AI 理论上能覆盖的：
- 报销流程：从邮件下载发票图片 → 打开 OCR 工具提取金额 → 在财务系统填写报销单 → 发消息通知审批人。四个步骤横跨邮件客户端、图片工具、浏览器、即时通讯。
- 数据汇总：从三个不同的业务系统网页各导出一份 CSV → 在 Excel 里合并计算 → 把结果贴到协作文档里。
- 部署通知：在终端跑完部署命令 → 检查日志确认成功 → 在群里发一条"部署完成"的消息。
这些流程的共同特征：步骤不多，但跨越的应用多，每一步的输入是上一步的输出。人做起来几分钟，但重复执行很烦。传统自动化脚本需要为每个应用写专用集成代码，维护成本高。OS 级 AI 如果能用自然语言指令完成编排，确实是一种降维打击。
用 Python 模拟跨应用操控：当前能做到什么程度
在小U同学 3.0 的 OS 级 AI 发布之前，开发者可以用 Python 的 pyautogui + subprocess 实现基础的跨应用自动化。下面是一个可运行的示例——自动打开计算器、执行运算、截图保存结果：
#!/usr/bin/env python3
"""
跨应用自动化演示：打开计算器 → 输入运算 → 截图保存结果
依赖：pip install pyautogui Pillow
运行前确保：计算器应用已安装（Linux: gnome-calculator / Windows: calc）
"""
import subprocess
import time
import pyautogui
from PIL import Image
# 安全设置：鼠标移到屏幕角落可紧急中断
pyautogui.FAILSAFE = True
pyautogui.PAUSE = 0.3
def open_calculator():
"""启动计算器应用"""
# Linux 下启动 gnome-calculator；Windows 改为 "calc"
subprocess.Popen(["gnome-calculator"])
time.sleep(2) # 等待窗口加载
def compute_and_capture(expression="123+456"):
"""
在计算器中输入表达式并截图
expression: 要计算的算式，如 "123+456"
"""
# 聚焦计算器窗口（简单方式：点击屏幕中央区域）
screen_w, screen_h = pyautogui.size()
pyautogui.click(screen_w // 2, screen_h // 3)
# 逐字符输入表达式
for char in expression:
if char == "+":
pyautogui.press("+")
elif char == "-":
pyautogui.press("-")
elif char == "*":
pyautogui.press("*")
elif char == "/":
pyautogui.press("/")
else:
pyautogui.press(char)
# 按回车得到结果
pyautogui.press("enter")
time.sleep(1)
# 截图保存
screenshot = pyautogui.screenshot()
screenshot.save("calculator_result.png")
print(f"运算 {expression} 完成，截图已保存为 calculator_result.png")
if __name__ == "__main__":
open_calculator()
compute_and_capture("123+456")
这段代码展示了跨应用自动化的核心机制：启动外部程序 → 模拟输入 → 读取屏幕输出。但它的问题也很明显——坐标硬编码、没有视觉理解、异常处理脆弱。这正是 OS 级 AI 要解决的技术短板。
OS 级 AI 的技术猜想与伪项目示例
小U同学 3.0 的具体实现细节尚未公开，但基于 OS 级 AI 的公开思路，可以构想一个任务定义格式。以下是一个伪项目配置，标注了假设部分，仅用于理解设计方向：
# 伪项目示例：OS 级 AI 跨应用任务定义
# ⚠️ 以下格式为假设，非小U同学 3.0 官方 API
task:
name: "报销单填写"
description: "从邮件提取发票信息，填写到财务系统"
steps:
- id: extract_invoice
action: open_app
app: "邮件客户端"
then:
action: screen_find # 【假设】视觉定位界面元素
target: "包含'发票'的最新邮件"
then:
action: screen_read # 【假设】OCR + 语义理解
extract:
- field: "金额"
- field: "日期"
- field: "发票号"
save_as: invoice_data
- id: fill_form
action: open_app
app: "浏览器 → 财务系统"
then:
action: screen_find
target: "报销单表单"
then:
action: screen_type
fields:
金额: "{{ invoice_data.金额 }}"
日期: "{{ invoice_data.日期 }}"
发票号: "{{ invoice_data.发票号 }}"
then:
action: screen_click
target: "提交按钮"
- id: notify
action: open_app
app: "即时通讯"
then:
action: screen_type
target: "审批群聊天框"
message: "报销单已提交，金额 {{ invoice_data.金额 }}，请审批"
error_handling:
on_step_fail: pause_and_ask_user # 【假设】失败时暂停请求人工介入
这个 YAML 的设计要点：每一步用 screen_find / screen_read / screen_type / screen_click 四个视觉动作覆盖"看→理解→输入→确认"的完整链路，步骤间通过变量传递数据。和前面的 pyautogui 硬编码脚本相比，核心区别是用语义描述代替坐标，用视觉理解代替固定定位。
采纳建议与风险清单
如果你在考虑 OS 级 AI 的实际使用，有几个问题需要提前想清楚：
| 维度 | 关注点 |
|---|---|
| 可靠性 | 视觉识别在复杂界面、小字体、动态弹窗下是否稳定？直播演示选的场景可能偏简单，日常复杂场景才是真正考验 |
| 安全性 | AI 能操控任意应用 = 能访问任意数据。权限边界怎么划？误操作怎么回滚？ |
| 可观测性 | 自动化流程跑起来后，人怎么知道当前在哪一步、中间数据对不对？需要步骤日志和暂停机制 |
| 环境依赖 | 屏幕分辨率、应用版本、系统语言都会影响视觉识别。换一台电脑可能就要重新适配 |
| 成本 | 视觉模型每次识别都有推理开销，长流程的延迟和算力消耗需要评估 |
实用建议：
- 先从 2-3 步的短流程试起，别上来就编排十步长链。
- 每个流程保留人工确认节点——关键操作（如发送消息、提交表单）前让 AI 暂停等你点确认。
- 对比一下：如果某个流程用传统 API 脚本（如 Python + REST API）能搞定，优先用脚本——更稳定、更快、更便宜。OS 级 AI 的价值在于没有 API 的应用和非标准化的界面操作。
- 6 月 10 日晚的直播重点看：演示场景的复杂度是否超出"打开应用 + 输入文字"的级别，失败时的处理方式是否透明。
OS 级 AI 的方向是对的——让 AI 从应用里的"侧边栏顾问"变成桌面上的"操作执行者"。但从演示到日常可靠使用，中间还有不少工程问题要解决。看直播时，带着上面那张清单去观察，会比单纯看"一句话搞定"更有收获。