我以为 Computer Use 就是 Computer Use，测完才发现我在用锤子拧螺丝

上个月我在 Mac 上做了一件蠢事。

我用 Claude 的 computer use 功能，让它帮我批量重命名 500 个文件。AI 很认真地"看"着屏幕，一个一个地点击 Finder 里的文件，改名，回车，再点下一个……跑了将近 20 分钟，还没弄完一半。

后来换 Codex，一段 shell 脚本，8 秒搞定。

然后我又犯了另一个错误：让 Codex 帮我操作 Figma 导出切图。它生成了一段脚本，自信满满地开始执行，然后……报错了。因为 Figma 桌面端没有开放 CLI 接口，Codex 根本"摸不到"那个 GUI。

两次翻车，让我彻底搞清楚了一件事：Codex 的 computer use 和 Claude 的 computer use，根本不是同一种东西。 它们只是碰巧用了同一个词。

---

先别急着上手——这俩根本不是同类产品

很多人（包括一个月前的我）看到"computer use"这个词，会默认它们是同一类功能的不同实现。但如果你仔细拆开来看，会发现两者的底层架构和设计哲学差得很远。

用一张表把核心差异前置：

核心认知：Codex 是"写代码的 AI 程序员"，Claude computer use 是"会用电脑的 AI 实习生"。前者快准狠但只认命令行，后者灵活但慢且贵。

---

测试设计——同一台 Mac，同一批任务

选了五个典型自动化场景，刻意覆盖"纯逻辑型"和"GUI 交互型"两个维度：

1. 批量重命名文件（500 个 jpg，按日期+序号规则重命名）→ 纯逻辑型

2. 抓取网页数据填入表格（某电商平台商品列表 → Excel）→ 混合型

3. 自动发送邮件（读取 CSV，逐行发送个性化邮件）→ 纯逻辑型

4. 操作 Figma 导出切图（打开文件，按图层名批量导出 PNG）→ 纯 GUI 型

5. 多步 Shell 任务（克隆仓库 → 安装依赖 → 跑测试 → 输出报告）→ 纯逻辑型

---

实测过程——逐任务拆解

任务一：批量重命名文件

描述需求后，Codex 生成了以下脚本：

#!/bin/bash
Codex 生成的批量重命名脚本
DIR="$1"
COUNTER=1

for FILE in "$DIR"/*.jpg; do
DATE=$(stat -f "%Sm" -t "%Y%m%d" "$FILE")
NEWNAME="${DATE}_$(printf '%04d' $COUNTER).jpg"
mv "$FILE" "$DIR/$NEWNAME"
((COUNTER++))
done

echo "完成：共重命名 $COUNTER 个文件"

执行时间：8 秒，500 个文件全部完成，零错误。

Claude 截图识别 Finder 窗口，尝试逐个点击文件 → 右键 → 重命名。执行了约 12 分钟后，我手动终止了测试，此时完成了约 60 个文件。

---

任务二：抓取网页数据填入表格

这个任务有意思，因为它取决于目标网站的结构。

---

任务三：自动发送邮件

但速度仍然慢：50 封邮件跑了 34 分钟。

---

任务四：操作 Figma 导出切图 ⭐ 关键翻车场景

这是最能体现两者本质差异的任务。

Figma 桌面端没有开放 CLI 接口。Codex 尝试用 Figma REST API 来操作，但导出特定图层需要知道 node ID，它无法自动获取当前打开文件的图层结构。最终报错：

Error: Cannot access Figma layer structure without valid node IDs.
Please provide file key and node IDs manually.

Claude 截图识别 Figma 界面，找到左侧图层面板，逐一点击目标图层，右键 → Copy/Paste → Export。整个过程需要大量的截图-识别-点击循环。

耗时 28 分钟，成功导出了 23 个图层中的 21 个（2 个因为图层名称太长，截图识别出现截断错误）。

这一轮，Claude 赢得毫无争议。

---

任务五：多步 Shell 任务

克隆仓库 → 安装依赖 → 跑测试 → 输出报告。这是 Codex 的主场。

---

五任务数据汇总

数据说话，没有绝对的赢家。

---

本质差异——两种截然不同的哲学

测试数据背后，是两家公司对"AI 操控计算机"这件事的不同理解。

这就是为什么 Figma 任务会出现 0% vs 91% 的极端差距。

你的任务是什么？
│
├── 有 API / CLI 可以调用？
│       ├── 是 → 用 Codex（快10倍，稳定性更高）
│       └── 否 → 继续往下
│
├── 任务必须通过 GUI 完成？
│       ├── 是 → 用 Claude computer use
│       └── 否（其实有 CLI 但你懒得查）→ 用 Codex
│
└── 任务又有逻辑又有 GUI？
→ 组合用（见下一章）

---

结论与建议——不是选一个，是学会组合用

说"Codex 更强"或"Claude 更强"都是错的。它们是互补关系，不是竞争关系。

一个实用的 Mac 自动化工作流搭配方案：

Claude computer use 的成本显著更高，主要因为每一步操作都要发送截图，图像 token 消耗快。所以只在真正需要 GUI 的场景才用它，不要拿它当万能工具。

---

文中两个工具的 API 我都是通过同一个接入层调用的，好处是不用分别管理两套密钥、两套计费，切换模型只改一行参数。如果你也想直接复现本文的测试，可以用 [api.884819.xyz](https://api.884819.xyz) ——支持 Codex 和 Claude 全系模型，国内直连，按量计费，新用户注册即送体验 token，文中所有代码示例直接粘贴就能跑。

两个最简调用示例（Python）：

# Codex 调用示例
from openai import OpenAI

client = OpenAI(
api_key="your_key",
base_url="https://api.884819.xyz/v1"
)

response = client.chat.completions.create(
model="codex-mini-latest",
messages=[{"role": "user", "content": "写一个批量重命名jpg文件的bash脚本，按日期+序号格式"}]
)
print(response.choices[0].message.content)

# Claude computer use 调用示例
import anthropic

client = anthropic.Anthropic(
api_key="your_key",
base_url="https://api.884819.xyz"
)

response = client.beta.messages.create(
model="claude-sonnet-4-6",  # 对应 Claude Sonnet 4.6
max_tokens=4096,
tools=[{"type": "computer_20241022", "name": "computer", "display_width_px": 1280, "display_height_px": 800}],
messages=[{"role": "user", "content": "打开Figma，导出所有名称包含'icon'的图层为PNG"}],
betas=["computer-use-2024-10-22"]
)

---

测完这两个工具，我开始好奇一件事：

如果把 Codex 生成的脚本，直接交给 Claude computer use 去执行，会发生什么？

下篇我会试着把两个工具串成一条 pipeline——让 AI 写代码，让另一个 AI 帮你点"运行"。理论上，这能把两者的优势叠加：Codex 负责逻辑，Claude 负责界面交互，中间用一个轻量的编排层串联起来。

实测结果……有点出乎意料。有一个环节出了问题，是我完全没预料到的。

下篇见。

---

#AI工具 #ComputerUse #Claude #Codex #Mac自动化 #AI效率 #8848AI #AI实测