AI 开始操作电脑里的老软件了:没有 API,也能自动化?

有些工作，明明已经用了电脑，却还是离不开手工操作。

比如客户发来一份 Excel 订单。你要打开公司的旧版管理软件，把客户名称、产品型号、数量逐项填进去；录完一条，再录下一条。

你不是不知道这件事可以优化。问题是，一提自动化，就可能听到一句话：

“系统没有 API，不好对接。”

这句话背后，藏着不少公司的日常成本：软件已经买了，数据却还要靠人搬。

10 月 1 日，GitHub 宣布，GitHub Copilot 的 Computer Use（电脑操作）能力进入公开预览。在 Windows 和 macOS 上，它可以尝试读取应用界面、点击控件、输入文字、滚动、拖拽，并跨应用执行步骤。GitHub 特别提到了一个场景：没有 API、命令行或 MCP 集成的老软件，以及只能通过图形界面操作的软件。

这不是说所有老软件从此都能可靠地自动运行，而是过去被“没有接口”拦住的工作，现在多了一条可以试验的路。

01｜还要复制粘贴？

先弄懂 API 是什么。

可以把它理解成软件对外提供的标准通道。如果电商平台和 ERP 都有合适的接口，订单信息就可以直接传递，不必有人打开两个窗口，一项一项输入。

API 适合机器与机器直接交换数据；但并不是每套软件都提供这条通道。

尤其是一些多年没有大改的财务系统、工厂管理软件、仓储工具和专用桌面程序：它们未必难用到必须更换，也未必有足够多的需求值得专门改造。

更现实的问题是：有的系统虽然有接口，却需要额外付费、申请权限、做字段映射，之后还要有人维护。

于是企业面对一笔账：为一个每天几十次的流程投入开发，可能不如继续安排员工操作。

这就是为什么一个看上去毫无技术含量的动作，能在公司里持续好多年。

不是没人想到自动化，而是过去的自动化成本未必算得过来。

02｜AI 操作软件的方式

以前我们想自动录入订单，往往要找接口、写程序、配置 RPA，或者专门适配软件里的按钮位置。

Computer Use 提供了另一种尝试：让 AI 通过可访问的界面信息和视觉信息，像操作员那样完成一组步骤。

拿“表格录入旧系统”来说，它需要先读取源数据，再找到目标字段、填写、检查，之后处理下一条。

这里有两个容易误解的地方。

第一，“不要求 API”不等于“什么软件都能操作”。

如果软件界面无法识别、权限不足、窗口频繁变化，或者操作结果难以核对，AI 仍可能失败。

第二，“操作一次成功”不等于“可以无人值守”。

少量测试通过，并不能证明它能稳定处理大量订单，更不能证明它适合直接执行付款、删除、正式提交等高风险动作。

GitHub 官方文档还特别强调：如果 API、命令行、文件系统工具等更直接的方法能够完成任务，通常应优先使用，因为这些方式的数据结构和执行结果更可预测。

所以，Computer Use 不是要取代 API，而是补上 API 不容易覆盖的那一段。

03｜CEO 的一句话

就在这次 GitHub 更新的同一天，微软 CEO 萨提亚·纳德拉（Satya Nadella）在微软官方发布的组织调整说明中，把 Copilot 的愿景描述为：打造一个新的“工作操作系统”（a new OS for work），覆盖不同的模型、形态与任务。

这不是一句“把 Windows 换掉”的承诺，而是微软对未来工作入口的定位。

9 月 25 日，微软已经公布新版 Copilot 的三个方向：Home（聊天与协作工作）、Code（用 AI 构建工具）、Autopilot（持续执行任务的智能体）。微软希望把 Word、Excel、PowerPoint 等 Office 能力更深地放进 Copilot，而不是让 AI 永远停留在软件侧边栏里。

把这两条新闻放在一起，会发现一个值得注意的变化：

过去是人决定打开哪个软件，再在里面完成步骤；微软希望未来更多时候，人先说清楚要完成什么工作，由 AI 协调相关工具。

这是对战略方向的解读，还不是已经实现的现实。特别要分清：10 月 1 日发布的桌面 Computer Use 是 GitHub Copilot CLI 与 GitHub Copilot App 的预览能力，不能直接说成所有 Microsoft 365 Copilot 用户都已经获得同样功能。

为什么这个区别重要？因为我们讨论的是两个层次：

• 具体能力： AI 能否在没有接口的桌面软件里完成操作？
• 产品方向： 工作是否可能逐步从“围绕软件菜单操作”，转向“围绕任务目标组织”？

前者值得今天测试，后者值得长期关注。

04｜和你有什么关系？

如果你手里就有一个旧系统，不必先研究宏大的 AI 战略，先看日常工作里有没有这些情形。

一、反复从表格向业务系统录入资料。

例如把供应商报价、产品型号、采购数量填入内部系统。字段固定、可逐条检查，是合理的起点。

二、每天要经过相同窗口、菜单和表单。

例如在专用桌面软件里批量填写非敏感测试参数。重复步骤越明确，越容易设计可验证的小实验。

三、一个流程跨两个以上软件，但又不值得单独开发。

例如从测试表格取数据，更新一份内部演示文稿，再输出结果清单。

不过，千万别把“重复”当成唯一标准。如果 Excel 自己就能用公式、Power Query 批量处理，或者系统支持 CSV 导入，就没必要让 AI 用鼠标一条条点。

选择工具可以简单理解为：

关键不是追求“全都交给 AI”，而是找到过去投入产出比不好的那部分工作。

05｜到底值不值得用？

假设每天录入 100 条记录，每条手工操作 1 分钟，一个月工作 22 天。

人工总耗时约为 36.7 小时/月。

再假设引入 AI 后，每天仍需要 25 分钟负责启动、复核和纠错，那么每月保留下来的人工投入约为 9.2 小时，理论上减少了约 27.5 小时人工工作。

请注意：这是为了展示计算方法而设定的假设，不是 Copilot 的实测结果。

要不要真正部署，还要把工具费用、初始配置、异常处理、维护，以及错误带来的潜在损失算进去。

所以应该比较的是：

净收益 = 节省的人工成本 − 工具与维护成本 − 预期错误成本。

如果 AI 经常找错字段，员工反而花更多时间核对，它就没有真正创造价值。

相反，如果能稳定处理大部分标准记录，把异常交回给人，那么即使它没有完全代替人工，也可能值得用。

能完成演示，是技术上的可行；持续省时省钱，才是业务上的可行。

06｜怎么试？

GitHub 公布的启用方式并不复杂。

使用 GitHub Copilot CLI，可以输入：

/computer on

通过 /computer show 查看状态，使用 /computer off 关闭。使用 GitHub Copilot App，则在 Settings → Computer Use 中启用。macOS 还需要相应的辅助功能和屏幕录制权限；应用操作需要遵循授权设置，组织管理员也可能禁用该功能。

第一次测试，建议只使用虚构数据和模拟系统，不要连接真实订单和财务账号。

可以这样交代：

请把已打开的测试表格中前 10 条虚构记录录入模拟管理程序。只填写客户代号、地区和产品类型。每完成一条就检查字段是否对应；遇到不确定字段、异常弹窗或可能正式提交的按钮，立即停止并请求我确认。结束后报告成功数量、错误数量、人工干预次数和总耗时。不要猜测缺失内容，也不要操作真实业务数据。

测完只看四件事：录对几条、错在哪里、需要人接管多少次、加上复核究竟花了多久。

再让员工手工做一遍相同任务。只比较 AI 的点击速度，没有意义；要比较完成一项工作所付出的总成本。

如果十条都不稳定，就先找原因，不要急着扩大到一千条。

最后：老软件不必先升级

这次新闻最吸引人的地方，是 GitHub 明确把没有 API 的老软件纳入了 Computer Use 的适用探索范围。

它不意味着系统改造从此不再必要，也不意味着 AI 可以安全接管所有桌面工作。

但它给了企业一个新问题：

过去因为开发成本太高而放弃的那项自动化，现在是否值得重新算账？

纳德拉提出“新的工作操作系统”，描绘的是长远方向；Computer Use 能否操作你手里的旧软件，需要具体测试。

把这两者区分清楚，就不会因为技术演示而过度兴奋，也不会错过真正可以省钱的机会。

AI 会不会点击鼠标，并不是最重要的。重要的是，那些长期靠人连接的软件流程，终于多了一种值得验证的解决办法。