我用 Claude 的"计算机控制"功能跑通了自动贴现流程，踩了 2 个坑

上个月我在朋友圈发了一条消息："Claude 的 Computer Use 功能，我以为又是 PPT 级演示，结果它真的在动我的鼠标。"

那条消息被截图转发了几十次，很多人问我怎么做到的。这篇文章就是答案。

---

先说结论：这玩意儿真的能用了

我做财务相关工作，每天有一个绕不开的重复动作——**票据贴现申请**。流程不复杂，但步骤繁琐：登录系统、选单据、核对金额、填写利率、确认提交、导出回执。手熟的人做一笔大概 15 分钟，遇到系统卡顿或者单据多的时候，半小时也打不住。

我测试的结果是：**Claude Computer Use 跑完全流程，4 分 12 秒，全程无人值守。**

不是 Demo，不是模拟环境，是连接真实业务系统跑的。

我知道你现在的反应——"这不就是 RPA 吗？""这不就是写个脚本吗？"

不一样。我来解释。

---

Computer Use 是什么？用人话说清楚

传统 RPA（机器人流程自动化）的逻辑是：**你告诉机器人，第 3 行第 2 列有个按钮，点它。**

这意味着你要提前把每一个元素的坐标、ID、XPath 全部写死。页面一改版，脚本就废了。维护成本极高。

Claude 的 Computer Use 完全不同。它的逻辑是：**截一张屏幕图片，发给 Claude，Claude 看懂图片内容，然后告诉你"把鼠标移到右上角那个写着'提交'的蓝色按钮，点击它"。**

用一个类比：

> 传统 RPA 是**盲人按图索骥**，地图变了就迷路。
> Claude Computer Use 是**一个真人坐在你电脑前操作**，看到什么就处理什么，页面改版了它照样能找到按钮。

工作原理的闭环是这样的：

```
屏幕截图 → Claude 视觉理解 → 输出动作指令（鼠标/键盘）→ 执行动作 → 再次截图 → 循环
```

每一步都有"眼睛"，每一步都在理解上下文。这就是为什么它能处理跨系统、跨页面、有条件判断的复杂流程——**贴现申请**这种需要"看数字、做判断、跨页面"的任务，正好是它的主场。

---

手把手复现：我的完整实现思路

这是本文最核心的部分。我把实现过程拆成 4 个步骤，进阶读者可以直接复用。

Step 1：环境准备

首先你需要一个稳定的 Claude API 接入点。我用的是 **[api.884819.xyz](https://api.884819.xyz)**，支持 Claude 的 Computer Use 接口，国内直连，按量计费，注册即送 5 元体验额度，省去了折腾网络环境的时间——这对于想快速验证想法的人来说，是最省心的起点。

系统权限方面，需要给运行脚本的进程开放截图权限和鼠标键盘控制权限（macOS 需要在"安全性与隐私"里授权"辅助功能"）。

最简的 Python 调用示例（约 20 行）：

```python
import anthropic
import base64
from PIL import ImageGrab

初始化客户端，指向国内接入点 client = anthropic.Anthropic( api_key="your_api_key", base_url="https://api.884819.xyz/v1" )

def take_screenshot():
"""截取当前屏幕并转为 base64"""
screenshot = ImageGrab.grab()
screenshot.save("/tmp/screen.png")
with open("/tmp/screen.png", "rb") as f:
return base64.b64encode(f.read()).decode()

def ask_claude(screenshot_b64, task_description):
"""将截图发给 Claude，获取下一步操作指令"""
response = client.messages.create(
model="claude-sonnet-4-6", # 用 Sonnet 4.6，性价比最优
max_tokens=1024,
tools=[{"type": "computer_20241022", "name": "computer", "display_width_px": 1920, "display_height_px": 1080}],
messages=[{
"role": "user",
"content": [
{"type": "image", "source": {"type": "base64", "media_type": "image/png", "data": screenshot_b64}},
{"type": "text", "text": task_description}
]
}]
)
return response
```

Step 2：Prompt 设计——让 Claude "不乱跑"

这是最容易被忽视的环节。很多人上来就写"帮我完成贴现申请"，然后发现 Claude 开始乱点，甚至点到了不相关的页面。

**核心原则：把任务拆成原子步骤，每步只做一件事，完成后等待确认。**

我用的 System Prompt 模板如下：

```
你是一个专业的财务操作助手，正在帮助完成票据贴现申请流程。

【操作规范】
1. 每次只执行一个动作，执行完毕后等待我提供新的截图
2. 如果页面正在加载，请告知"等待页面加载"，不要继续操作
3. 如果找不到目标元素，停止操作并描述当前屏幕状态
4. 操作金融系统时，确认金额前必须复述数字，等待我确认后再点击

【当前任务】
完成一笔票据贴现申请，单据号：{invoice_id}，申请金额：{amount} 元

【操作步骤】
Step 1: 确认当前在贴现申请页面
Step 2: 在单据列表中找到指定单据号并勾选
Step 3: 核对金额与利率填写区域
Step 4: 填写贴现利率（当前利率：{rate}%）
Step 5: 点击"确认提交"，等待系统响应
Step 6: 截图保存提交成功的回执页面
```

关键点：**加入"等待确认"机制**，不要让 Claude 一口气跑完所有步骤，中间要有截图反馈的闭环。

Step 3：贴现流程的关键节点拆解

实际跑下来，整个流程分 4 个关键节点：

1. **登录验证**：账号密码输入 + 验证码识别（Claude 视觉能力可以直接读图形验证码，成功率约 85%）
2. **单据筛选**：在列表中定位特定单据号，这里需要 Claude 能识别表格结构
3. **金额填写**：数字输入，Claude 会自动清空已有内容再填写
4. **提交确认**：识别"确认"vs"取消"按钮，这是踩坑最多的地方（见下一章）

Step 4：异常处理逻辑

在 Prompt 里加入兜底指令：

```
【异常处理规则】
- 如果连续 2 次未找到目标元素，停止并输出 ERROR: ELEMENT_NOT_FOUND
- 如果页面出现弹窗，优先处理弹窗再继续主流程
- 如果操作后 10 秒页面无变化，输出 ERROR: PAGE_TIMEOUT
```

---

2 个坑，差点让我放弃

好，重头戏来了。

坑 1：分辨率问题，它把"确认"当成了"取消"

**现象描述**

第一次完整测试的时候，流程跑到最后一步——点击"确认提交"。

我盯着屏幕，看着鼠标缓缓移动，然后……点在了"取消"上。

好，我以为是偶然，重跑。

第二次，还是点"取消"。

第三次点错的时候，我真的想关掉电脑。

**根本原因**

查日志之后发现问题所在：我的显示器是 2K 分辨率，macOS 开启了 Retina 缩放（2x scaling），**实际截图分辨率是 2560×1440，但我在 Computer Use 的工具配置里写的是 `display_width_px: 1920`。**

Claude 以为屏幕是 1920 宽，但实际截图是 2560 宽，坐标换算出了偏差——"确认"按钮在 Claude 眼里的位置，实际上对应的是旁边的"取消"。

**解决方案**

把工具配置里的分辨率改成实际截图分辨率：

```python
# 错误写法
tools=[{"type": "computer_20241022", "name": "computer",
"display_width_px": 1920, "display_height_px": 1080}]

正确写法：先获取实际截图尺寸，再传入 from PIL import ImageGrab screenshot = ImageGrab.grab() width, height = screenshot.size # 获取真实分辨率

tools=[{"type": "computer_20241022", "name": "computer",
"display_width_px": width, "display_height_px": height}]
```

**避坑口诀：** `display_width` 要和截图宽一致，差一个像素都可能点错按钮。

---

坑 2：页面加载延迟，流程跑到一半卡死

**现象描述**

第二个坑出现在提交之后。

点击"确认提交"成功，系统开始处理，这时候会有 2-3 秒的 loading 动画。

Claude 截图，看到 loading 页面，判断"提交成功"，然后立刻去找"下载回执"按钮。

但 loading 还没结束，回执按钮根本没出现。

日志里只有一行冷冷的报错：

```
ERROR: element not found - 回执下载
Traceback: ToolUseBlock action=mouse_click coordinate=[1243, 678]
```

任务就这么中断了。

**根本原因**

Claude 没有"等待"的天然概念。它截一张图，做一个判断，执行一个动作。**如果页面还在加载，它不会主动等，它会直接在加载中的页面上操作，然后找不到元素就报错。**

**解决方案**

两个层面同时处理：

**① Prompt 层面**，明确告诉 Claude 如何识别"加载中"状态：

```
【等待规则】
- 如果页面中出现 loading 图标、进度条或"处理中"文字，
输出 WAITING，不要执行任何操作，等待下一张截图
- 连续 WAITING 超过 5 次（约 10 秒），输出 ERROR: TIMEOUT
```

**② 代码层面**，在每次执行动作后加入显式等待：

```python
import time

def execute_action_with_wait(action, wait_seconds=3):
"""执行动作后等待页面响应"""
perform_action(action) # 执行鼠标/键盘操作
time.sleep(wait_seconds) # 等待页面响应
screenshot = take_screenshot() # 重新截图
return screenshot # 返回最新状态
```

**避坑口诀：** 操作之后必须等，等完再截图，截图再判断。异步页面是 Computer Use 最大的敌人。

---

值不值得用？我的真实评估

说完踩坑，该客观说说这东西的边界了。

**它不是万能的。**

我用了一个月，得出的结论是：**Computer Use 适合的场景，是"流程复杂但相对固定，且难以通过 API 直接对接"的情况。**

具体来说，用下面这个决策矩阵来判断：

| | **操作复杂度低** | **操作复杂度高** |
|---|---|---|
| **流程稳定** | ❌ 写脚本更合适，成本更低 | ✅ Computer Use 最佳场景 |
| **流程多变** | ⚠️ 看情况，可以试试 | ✅ Computer Use 优势明显 |

贴现申请属于"流程相对稳定 + 操作跨系统复杂"，落在右上角——**Computer Use 的主场**。

但如果你的需求是"每天定时抓取某个网页的数据"，那写个 Playwright 脚本比 Computer Use 更稳定、更便宜。

**时间账算下来是值的：**

- 手动操作：15 分钟/笔
- Computer Use：4 分钟/笔，节省 73%
- 每月贴现笔数约 40 笔，节省约 **9 小时**

9 小时，够多睡几觉了。

---

> 📌 **下一篇预告**
>
> 跑通单笔贴现之后，我开始想：**如果让 Claude 同时控制多个窗口、并行处理不同单据，会发生什么？**
>
> 我测试了"多 Agent 协作 + Computer Use"的组合玩法，结果出乎意料——有一个场景效率提升了 8 倍，但有一个场景直接把系统搞崩了，差点触发风控警报。
>
> **下周更新，建议先关注，别错过。**

---

*本文由8848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。*

#AI自动化 #ClaudeComputerUse #财务自动化 #AI实战 #8848AI #RPA替代 #AI踩坑记录 #效率工具