我用 Claude Sonnet 4.6 的 Computer Use 跑通了自动填表流程,这 3 个细节太关键了
我用 Claude Sonnet 4.6 的 Computer Use 跑通了自动填表流程,这 3 个细节太关键了
---
「我以为 10 分钟能搞定,结果搞了一整天」
事情的起因很简单:我们部门每季度要向三个不同的平台提交项目进度报告,每张表大概 20 个字段,手填一张要 15 分钟,一次性要填 60 多张。
我当时的想法也很简单——Claude 的 Computer Use 不就是干这个的吗?让 AI 看着屏幕自己填,我去喝杯咖啡,回来就完事了。
结果你猜怎么着?
我对着报错信息坐了整整一天。AI 要么点到了错误的输入框,要么填到一半就卡在那里不动了,要么遇到一个确认弹窗直接不知所措,整个流程就这么挂掉了。那种感觉,就像你满怀期待地买了一台「全自动」洗碗机,结果发现它连碗都不会放。
这篇文章,就是我踩完那些坑之后,整理出来的完整复盘。
如果你也在考虑用 Computer Use 自动化某个重复性的填表任务,这 3 个细节能帮你直接跳过我走过的弯路。
---
第一章:Computer Use 到底是什么?先搞清楚它能干嘛
很多人第一次听到「Computer Use」,会以为它是某种特殊的 API 接口,调用一下就能操控电脑。
不是的。它的本质要更有趣——
Computer Use 是让 AI 真正「看」屏幕、「动」鼠标、「敲」键盘的能力。
具体来说,它的工作流程是这样的:你的电脑屏幕会被截图发送给 Claude,Claude 看懂界面之后,告诉系统「把鼠标移到坐标 (342, 218),然后点击」,系统执行,再截图,再发给 Claude……如此循环,直到任务完成。
这和传统自动化工具有本质区别。我做了一张对比表:
| 维度 | Computer Use | Selenium/Playwright | 手动操作 | | 开发成本 | 低(写 Prompt 即可) | 高(需写选择器代码) | 零 | | 适应界面变化 | 强(AI 自己看懂) | 差(选择器一变就崩) | 强 | | 稳定性 | 中(依赖截图质量) | 高(确定性执行) | 低(人会累) | | 适用场景 | 复杂/不规则表单 | 结构固定的页面 | 低频任务 | | 上手门槛 | 低 | 高 | 无 | | 成本 | 按 Token 计费 | 免费 | 人力成本 | Computer Use 的核心优势只有一个:你不需要写选择器,AI 自己看懂界面。这意味着,哪怕目标网站改版了,哪怕表单字段顺序变了,只要 AI 能看懂界面,流程就能继续跑。这是 Selenium 做不到的事情。
但它也有明显的短板:速度慢(每步都要截图传输)、成本随任务量线性增长、对强验证码几乎没有办法。
搞清楚这些,你才能判断自己的场景适不适合用它。
---
第二章:环境搭建 + 基础跑通(手把手)
准备工作
你需要:
1. Claude Sonnet 4.6 的 API Key(Computer Use 是 Sonnet 4.6 的核心能力之一)
2. Python 3.10+
3. 一个虚拟桌面环境(推荐用 Docker + VNC,后面会说为什么)
💡 想直接上手?
文中所有代码示例都基于 Claude Sonnet 4.6 API 测试。如果你还没有 API Key,可以在 [api.884819.xyz](http://api.884819.xyz) 快速获取——支持按量计费,注册即送 5 元体验额度,不需要邮箱验证,跑完本文的完整示例大概只需要几毛钱。
第一步:安装依赖
pip install anthropic pillow pyautogui
如果用 Docker 虚拟桌面,还需要:
pip install vncdotool
第二步:初始化环境 + 写第一个填表 Prompt
import anthropic
import base64
from PIL import ImageGrab
client = anthropic.Anthropic(
api_key="your_api_key_here",
base_url="https://api.884819.xyz" # 8848AI 接入点
)
def take_screenshot():
"""截取当前屏幕并转为 base64"""
screenshot = ImageGrab.grab()
# ⚠️ 小白注意:分辨率固定在 1280x800,原因见第三章细节①
screenshot = screenshot.resize((1280, 800))
screenshot.save("screen.png")
with open("screen.png", "rb") as f:
return base64.b64encode(f.read()).decode()
def send_to_claude(screenshot_b64, instruction):
"""发送截图 + 指令给 Claude,获取操作动作"""
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
tools=[{
"type": "computer_20241022",
"name": "computer",
"display_width_px": 1280,
"display_height_px": 800,
"display_number": 1
}],
messages=[{
"role": "user",
"content": [
{
"type": "image",
"source": {
"type": "base64",
"media_type": "image/png",
"data": screenshot_b64
}
},
{"type": "text", "text": instruction}
]
}]
)
return response
📌 进阶可跳过:如果你已经熟悉 Anthropic SDK,上面的结构你一眼就看懂了。直接跳到第三章看细节。
第三步:跑起来
把目标表单的 URL 传给浏览器,截图,发给 Claude,让它告诉你下一步怎么操作,执行,再截图……这个循环就是 Computer Use 的基本骨架。
跑起来之后,你会感受到一种奇妙的感觉:看着鼠标自己动,光标自己移到输入框,文字一个个打进去——那一刻确实挺震撼的。
但震撼完了,你会发现它经常出错。
这就是第三章要解决的问题。
---
第三章:3 个让流程从「跑起来」到「跑稳」的关键细节
这是全文最核心的部分。每个细节都是真实踩坑换来的,不是从文档里抄的。
---
细节① 截图分辨率与坐标漂移问题
踩坑现场: AI 总是点错位置。明明要点「姓名」输入框,结果点到了旁边的「单位」框。一开始我以为是 Prompt 写错了,排查了半天,最后发现是坐标系对不上。 原因分析:你的屏幕可能是 2K 或 4K 分辨率,系统显示缩放设置为 150% 或 200%。这时候,屏幕的「逻辑分辨率」和「物理分辨率」是不一样的。Claude 看到的截图是物理像素,但它给出的坐标是基于截图尺寸计算的,而 pyautogui 执行点击时用的是逻辑坐标——两者之间有一个缩放系数的偏差,点哪都会偏。
import pyautogui
import ctypes
def get_scale_factor():
"""获取系统 DPI 缩放比例(Windows)"""
try:
awareness = ctypes.c_int()
ctypes.windll.shcore.GetProcessDpiAwareness(0, ctypes.byref(awareness))
return ctypes.windll.shcore.GetScaleFactorForDevice(0) / 100
except:
return 1.0
SCALE = get_scale_factor()
def execute_click(x, y):
"""坐标校正后点击"""
# Claude 给的坐标是基于 1280x800 截图的
# 需要转换为系统实际坐标
actual_x = int(x / SCALE)
actual_y = int(y / SCALE)
pyautogui.click(actual_x, actual_y)
print(f"点击坐标:截图({x}, {y}) → 实际({actual_x}, {actual_y})")
更简单的方案:直接把系统显示缩放设为 100%,或者在 Docker 容器里跑一个固定分辨率的虚拟桌面(这也是我推荐用 Docker 的原因)。容器里的环境是你控制的,没有缩放问题。
⚠️ 这个坑很隐蔽,因为偏差不是随机的,而是固定比例的——AI 每次都点错,但错的方向和距离都一样,很容易误判为「Prompt 问题」。
---
细节② Prompt 的「任务粒度」直接决定成功率
踩坑现场: 我最开始写的 Prompt 是这样的:「请帮我填写这张表单,姓名:张三,单位:XX公司,项目名称:……(20个字段)」
Claude 拿到这个 Prompt,开始填,填到第 8 个字段的时候,页面出现了一个「自动保存」的提示浮层,它不知道该怎么处理,就停在那里了。整个流程挂掉。
原因分析:一个大 Prompt 要求 AI 完成 20 步操作,中间任何一个意外(浮层、页面滚动、字段联动)都可能让它迷失。AI 的上下文窗口是有限的,任务越长,它「记住自己在哪一步」的能力就越弱。
解法:拆分为子任务链# 把一张表的填写拆分为多个子任务,每步完成后截图确认
SUBTASKS = [
{
"id": "step_1",
"instruction": "找到「姓名」输入框,点击后输入「张三」。完成后截图告诉我:输入框里现在显示的是什么内容?",
"expected_state": "姓名框显示张三"
},
{
"id": "step_2",
"instruction": "找到「单位名称」输入框,点击后输入「XX科技有限公司」。完成后截图告诉我:输入是否成功?",
"expected_state": "单位框显示正确内容"
},
# ... 每个字段一个子任务
]
def run_subtask_chain(subtasks):
"""顺序执行子任务链,每步完成后校验状态"""
for task in subtasks:
print(f"\n▶ 执行:{task['id']}")
screenshot = take_screenshot()
response = send_to_claude(screenshot, task['instruction'])
# 让 Claude 确认当前状态,再进行下一步
confirm_screenshot = take_screenshot()
confirm = send_to_claude(
confirm_screenshot,
f"请确认:{task['expected_state']}。如果是,回复「确认」;如果不是,描述当前状态。"
)
if "确认" not in confirm.content[0].text:
print(f"⚠️ 步骤 {task['id']} 状态异常,暂停执行")
return False
return True
效果对比:
- 大 Prompt 单次执行:成功率约 40%(20 个字段,中途出错概率极高)
- 子任务链执行:成功率提升到 82%(每步都有确认,出错能被捕获)
把「填完一张表」变成「填好一个字段,确认,再填下一个」——这个思路的本质是把 AI 的长期记忆依赖,转化为每步的短期判断。
---
细节③ 异常处理:弹窗、验证码、网络延迟的应对策略
踩坑现场: 跑到第 35 张表的时候,页面突然弹出一个「您的会话即将超时,是否继续?」的对话框。AI 没有处理这个弹窗的指令,就这么卡在那里,后台静默失败了。我发现的时候,已经过去了 40 分钟。 原因分析: 没有设计「感知-判断-重试」的容错逻辑。正常流程跑得很顺,但异常情况完全没有兜底。 解法:加入容错流程[截图] → [Claude 判断:当前页面状态是否正常?]
↓ 正常 ↓ 异常(弹窗/错误/超时)
[执行下一步] [识别异常类型]
↓
┌─────────────┼─────────────┐
↓ ↓ ↓
[确认弹窗] [等待加载] [触发人工介入]
↓ ↓ ↓
[继续执行] [重试3次] [发送告警通知]
import time
def execute_with_fallback(instruction, max_retries=3):
"""带容错逻辑的执行函数"""
for attempt in range(max_retries):
screenshot = take_screenshot()
# 先让 Claude 判断当前页面状态
status_check = send_to_claude(
screenshot,
"请检查当前屏幕:是否有弹窗、错误提示、或页面未加载完成的情况?"
"如果有,描述具体是什么;如果没有,回复「页面正常」。"
)
status_text = status_check.content[0].text
if "弹窗" in status_text or "确认" in status_text:
# 处理确认类弹窗
send_to_claude(screenshot, "点击弹窗上的「确认」或「继续」按钮")
time.sleep(1)
continue
elif "加载" in status_text or "请稍候" in status_text:
# 等待页面加载
print(f"页面加载中,等待 3 秒后重试(第 {attempt+1} 次)")
time.sleep(3)
continue
elif "验证码" in status_text:
# 验证码无法自动处理,触发人工介入
send_alert("遇到验证码,需要人工处理")
input("请手动处理验证码后,按 Enter 继续...")
continue
elif "页面正常" in status_text:
# 状态正常,执行实际指令
return send_to_claude(take_screenshot(), instruction)
# 超过最大重试次数
send_alert(f"任务失败,已重试 {max_retries} 次")
return None
def send_alert(message):
"""发送告警(可接入企业微信/钉钉)"""
print(f"🚨 告警:{message}")
# 这里可以接入你们的告警系统
这套容错逻辑加入之后,流程的「无人值守」时长从平均 8 分钟提升到了 45 分钟以上——也就是说,我真的可以去喝咖啡了。
---
第四章:实战效果 + 适用边界
给出真实数据,不夸大。
测试样本: 共 63 张政务类项目报告表单,字段数量 18-24 个不等。 | 指标 | 数据 | | 总任务量 | 63 张表 | | 完全成功 | 51 张(81%) | | 需人工介入后完成 | 9 张(14%) | | 彻底失败 | 3 张(5%,均为动态验证码页面) | | 平均每张耗时 | 约 4.2 分钟 | | 手动填写对比 | 约 15 分钟/张 | | 节省工时 | 约 10.8 分钟/张,63 张合计节省约 11 小时 | 哪些场景不适合用:- 强验证码(滑块验证、图形验证码):AI 无法处理,会卡死
- 高度动态页面(字段根据前一个输入实时变化):成功率会显著下降
- 需要登录态维护的场景:每次重启环境都要重新登录,需要额外处理
- 极高精度要求(金融/医疗类):81% 的成功率在这些场景是不够的,必须有人工复核
诚实说:Computer Use 目前更适合作为「效率工具」而不是「替代品」。它能帮你把重复劳动从 100% 降到 20%,但那 20% 的边界情况,你还是要自己处理。
---
结尾:「这只是开始」
回头看这 3 个细节,它们背后其实是同一个逻辑:
坐标问题 是环境层面的精确性;任务粒度 是指令层面的清晰度;异常处理 是流程层面的鲁棒性。把这三层都做好,Computer Use 才算真正可用。
Computer Use 的本质,是把「人的操作经验」转化为「AI 的执行能力」。你能把流程描述得多清晰,AI 就能执行得多稳定。这不是 AI 的问题,这是你对自己业务流程的理解深度。
你现在已经有了比 90% 人更清晰的认知框架。剩下的,就是把你自己的场景套进去跑一遍。
🔧 动手试试?
把本文的 Prompt 模板复制过去,换上你自己的目标网址,在 [api.884819.xyz](http://api.884819.xyz) 调用 API,注册即送 5 元体验额度,按量计费,不用担心浪费。看看 AI 第一次「动起来」是什么感觉。
---
📌 下一篇预告
>
Computer Use 填表只是第一步。
>
下一篇我会尝试一个更难的挑战:「让 AI 自动登录、翻页、抓取数据,再写入 Excel——全程零代码」
>
如果你想第一时间看到,记得关注/收藏这个专栏。
>
(剧透:有一个地方会让你觉得「AI 也太聪明了吧」——但也有一个地方会让你哭笑不得。下篇见。)
---
本文由8848AI原创,转载请注明出处。关注8848AI,带你从零开始学AI。#AI自动化 #ComputerUse #Claude #8848AI #AI教程 #RPA #效率工具 #Prompt技巧