吴前锐这次我们来看一个很直接的话题：用 Claude 一小时能做出什么。标题里的关键词是“小应用、Skills、浏览器操作、业务自动化”，这四个东西正好对应一套从“搭建”到“跑通”再到“接入业务流程”的完整链路。如果你手头已经有一个 Claude 账号，或者正准备申请 API 权限，那这篇文章可以帮你把一小时拆成四个可执行的阶段，每个阶段都能产出可见结果。
先说结论：一小时内完成四件事是可行的，但它不是零基础魔法。你需要有一点命令行基础，能分清“本地代码”和“云端模型”之间的数据流向，并且愿意在测试环境里反复试错。文章标题标注了“中英双语”，实际上这不仅是语言层面的双语，更是提示词工程和结构化输出的练习，比如让 Claude 同时输出中文结论和英文摘要，再用 Skills 固化这套转换规则，最后让浏览器操作脚本把结果自动归档到内部系统。这个流程非常适合行政、运营、技术文档、数据整理这类重复度高的业务场景。
下面按一小时实战的顺序展开，从最轻量的小应用开始，逐步走到浏览器操作和业务流程自动化。
1. Claude 一小时实战：核心能力速览
| 能力模块 | 作用 | 适合场景 | 上手难度 |
|---|---|---|---|
| 小应用 | 用 Claude 生成可运行的 Web 页面或本地小程序 | 工具型页面、内部表单、原型验证 | 低 |
| Skills | 把固定提示词、处理步骤封装成可复用技能 | 文档总结、代码审查、翻译、数据清洗 | 中 |
| 浏览器操作 | 让 Claude 驱动浏览器完成点击、填写、读取 | 网页信息采集、内部系统录入、RPA 替代 | 高 |
| 业务自动化 | 串联上述能力形成完整任务流 | 报表生成、跨系统数据搬运、定时任务 | 中高 |
关于硬件门槛，如果走 Claude 官方 API，你的本地电脑只需要能跑代码和浏览器，不需要高性能 GPU。模型计算发生在云端，本地主要负责发送请求、接收响应、执行文件读写和浏览器驱动。这点和本地部署模型完全不同，也是“一小时实战”能成立的物理前提。
需要说明的是，Claude 模型版本和接口细节更新较快，下面的命令、配置和调用示例都采用通用结构，实际使用时以你当前账号可用的模型版本和官方文档为准。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 适用场景与使用边界
Claude 一小时实战适合这几类人：
- 经常处理中英双语材料的产品、运营和技术支持人员；
- 需要快速生成内部小工具但没有完整前后端开发时间的业务人员；
- 想把重复性网页操作交给 AI 代理的 RPA 入门者；
- 想验证“AI Agent 到底能不能稳定完成多步骤任务”的开发者。
真正值得投入的场景，是那些“规则明确、步骤固定、容错成本低”的任务。比如：把英文合同摘要成中文要点，把多个网页的产品参数整理成表格，把日报从业务系统搬运到报表系统。这类任务一旦验证稳定，能明显节省时间。
它不适合的场景同样明确：
- 涉及敏感账号、支付操作、未授权系统访问的流程；
- 需要极高准确率的公开内容发布；
- 没有人工复核环节的对外交付。
合规边界必须提前划清。使用 Claude 处理企业数据前，要确认数据脱敏、保密协议和服务条款允许；浏览器操作只能在你有权限访问的网站和测试环境中进行，不能绕过登录、验证码或任何安全限制；涉及人脸、声音、商标、版权素材时，必须获得合法授权。自动化操作如果影响到第三方网站的正常服务，同样要避免。
3. 环境准备与前置条件
一小时实战建议准备以下环境，尽量在开始前完成安装，不要在实战中边装边学。
3.1 账号与 API 权限
准备一个 Claude 账号，并确认自己拥有 API 调用权限。不同账号类型可以使用的模型和接口能力不同，建议先进入控制台查看模型列表和余额，再决定采用网页端操作还是 API 编程方式。
网页端适合快速交互验证，API 适合写入自动化流程。二者并不冲突，一小时实战中可以用网页端生成代码，再用 API 把代码流程化。
3.2 本地运行环境
建议安装：
- Python 3.10 以上，用于运行调用脚本和自动化工具；
- Node.js 18 以上，用于运行某些 Claude 插件工具和本地服务；
- Git，便于拉取官方示例仓库和版本管理；
- 一个你熟悉代码编辑器，VS Code 或任意文本编辑器都可以。
安装命令示例：
bash复制# 检查已有环境
python --version
node --version
git --version
# 如果需要安装 Python 依赖，创建虚拟环境后用 pip 安装
python -m venv claude_hour
source claude_hour/bin/activate # Windows 下为 claude_hour\Scripts\activate
pip install anthropic requests
3.3 API Key 与私有化配置
把 API Key 放到环境变量中，不要写死在代码里：
bash复制# macOS / Linux
export ANTHROPIC_API_KEY="sk-ant-你的密钥"
# Windows PowerShell
$env:ANTHROPIC_API_KEY="sk-ant-你的密钥"
从安全角度讲，API Key 等同于账号凭据。代码仓库里不要提交包含真实 Key 的配置文件，也不要截图分享到公开网络。
3.4 测试站点与沙箱环境
浏览器操作部分需要准备一个可自由操作的测试站点。建议用本地搭建的演示网页，或者在明确允许自动化测试的公开网站上操作。不要第一次就在真实业务系统里跑自动化，可以先录屏观察，确认每一步动作都符合预期后，再考虑迁移到受控生产环境。
4. 一小时实战第一站：用 Claude 生成并运行小应用
4.1 什么是 Claude 小应用
这里说的“小应用”，指的是通过 Claude 生成前端代码、由本地浏览器运行的小型工具页面。不需要服务器，不需要数据库，一个 HTML 文件就能完成。典型例子包括中英对照翻译页、批量文本清洗工具、报价单生成器、会议纪要模板。
小应用的价值不在于功能复杂，而在于“快速验证”。如果你的业务场景需要频繁处理固定格式的信息，小应用能把重复劳动的步骤压缩成大段粘贴、一键处理。
4.2 制作流程
第一步，在 Claude 对话中描述需求。描述越具体越好。
建议提示词模板：
text复制请生成一个单页 HTML 小应用，功能是中英对照翻译辅助工具。
要求：
- 左侧输入中文文本，右侧显示英文翻译；
- 下方保留双语对照视图；
- 样式使用简洁的 CSS，不需要前端框架；
- 支持一键复制双语文案；
- 页面语言使用英文界面，但内部注释保留中文说明，方便维护。
第二步，让 Claude 输出完整 HTML 代码，保存为 translation_helper.html。
第三步，用浏览器直接打开文件，不需要启动服务器。如果涉及浏览器本地存储，则需要启动一个简单的 HTTP 服务：
bash复制python -m http.server 8000
然后访问 http://localhost:8000/translation_helper.html。
4.3 验证标准
页面能正常打开，左侧输入中文后右侧能正确调用 Claude 接口返回英文翻译，或者页面能正确调用你配置的翻译 API。复制按钮有效，双语对照视图在滚动时保持对齐。
这里的真正难点不是生成页面，而是让页面能稳定调用 Claude API。浏览器直接调用 API Key 不安全，因此更稳妥的方案是让 Claude 生成一个“本地 Python 服务 + 前端页面”组合：前端负责展示和输入，Python 后端负责调用 Claude API 并返回结果。
示例结构：
bash复制project/
├── server.py
├── templates/
│ └── index.html
└── .env
server.py 骨架：
python复制from flask import Flask, request, jsonify, render_template
import anthropic
import os
app = Flask(__name__)
client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
@app.route("/")
def index():
return render_template("index.html")
@app.route("/api/translate", methods=["POST"])
def translate():
data = request.get_json()
text = data.get("text", "")
response = client.messages.create(
model=MODEL_NAME,
max_tokens=1024,
messages=[
{"role": "user", "content": f"将下面的中文翻译成英文，并给出英文解释：\n{text}"}
]
)
return jsonify({"result": response.content[0].text})
if __name__ == "__main__":
app.run(port=8000, debug=False)
这个阶段的目标是“让跑起来的结果可验证”，不要求代码优雅。能先看到页面与 Claude 接口之间的数据往返成功，第一站就算结束。
5. 一小时实战第二站：把固定操作封装成 Skills
5.1 Skills 的核心思路
Skills 解决的是“每次都要重复输入相同提示词”的问题。同样一段数据清洗、同样一份英文合同摘要、同样一套代码审查规则，与其在对话里反复粘贴，不如打包成一个可重复调用的技能。
Skills 并不是神秘功能，它的核心是一份结构清晰的定义文件，里面写清楚技能名称、适用场景、输入格式、处理步骤和输出规范。Claude 在运行时会读取这份定义，按里面约定的方式执行任务。
5.2 一个最小的 Skills 结构
假设你要封装一个“中英双语版合同摘要技能”：
text复制skills/
└── contract-summary/
├── SKILL.md
└── examples/
└── sample_input.txt
SKILL.md 示例：
markdown复制---
name: contract_summary
description: 从英文合同中提取关键条款，生成中英双语摘要。
license: MIT
---
# 技能：合同摘要
## 适用场景
- 英文合同、协议、条款的快速审阅
- 需要同时输出中文阅读版和英文原文对照
## 输入格式
文本文件或粘贴文本，包含合同英文正文。
## 处理步骤
1. 识别合同中的甲方、乙方、金额、期限、违约责任、保密条款；
2. 每个条款先用一段中文概括，再引用对应的英文原文关键句；
3. 输出统一 markdown 结构。
## 输出格式
- 标题：合同摘要（中英双语）
- 表格字段：条款模块、中文摘要、英文关键句、风险提示
这种文件名和字段规范在不同 Claude 工具中的加载方式可能不同，有的放在项目目录即可被自动识别，有的需要在配置里显式声明路径。更稳妥的做法是在对话中直接添加“请加载项目目录下的 skills/contract-summary/SKILL.md，并执行里面的流程”，这样不依赖工具的自动发现机制。
5.3 Skills 验证测试
验证技能是否生效，可以用固定测试集：
- 准备 3 份不同格式的英文合同样本；
- 调用技能并输出结果；
- 检查输出是否遵循了 SKILL.md 规定的表格结构和双语摘要要求；
- 记录每次调用消耗的 token 数和耗时，对比未使用 Skills 时的差异。
判断成功的关键不是“Claude 能读懂合同”，而是“三份样本的输出结构一致”。结构不稳定时，优先修改 SKILL.md 中的“处理步骤”和“输出格式”，而不是临时在对话里补充要求。这也是 Skills 比单纯提示词更适合工程化落地的原因：规则固化后，输出稳定性更容易观察和调整。
6. 一小时实战第三站：浏览器操作实战
6.1 浏览器操作要做到什么
这一站的核心是：让 Claude 不仅能“读入网页内容”，还能“发起浏览器操作”。比如打开指定地址、等待页面加载、提取可见文本、点击按钮、填写输入框、提交表单，最后把结果写回本地文件。
实现路径通常有两种：一是通过浏览器扩展或 MCP 服务把浏览器状态暴露给模型，二是给模型提供浏览器操作工具，模型输出操作指令、由本地方案执行。
实际操作时会发现，模型对页面元素的理解依赖页面本身的语义结构。按钮没有可访问名、输入框没有唯一 id、页面是重 JavaScript 渲染时，自动化稳定性会明显下降。所以在实战中优先选择结构清晰的内部系统页面作为测试对象。
6.2 操作流程示例
假设需求是把一个列表页面中符合条件的结果批量写入 CSV：
- 用 Claude 编写打开页面并等待加载的脚本；
- 设置筛选条件，读取列表第一页中的目标字段；
- 将数据写入
results.csv； - 检查是否有“下一页”按钮，循环执行；
- 全部完成后生成一份操作日志。
伪代码示例：
python复制from claude_browser_tool import BrowserSession
session = BrowserSession(headless=False)
session.goto("https://your-internal-site.example/list")
session.wait_for("table.loaded")
rows = session.query_table(
selector="table tbody tr",
columns=["id", "title", "status"]
)
filtered = [r for r in rows if r["status"] in ["pending", "processing"]]
with open("results.csv", "w", encoding="utf-8") as f:
for row in filtered:
f.write(f"{row['id']},{row['title']},{row['status']}\n")
session.log("筛选完成，共写入 {} 行".format(len(filtered)))
这里使用的是描述性伪代码，真实项目中需要替换成实际可用的 SDK 或 MCP 工具。判断该步骤成功与否只有一个标准：脚本最后一次运行导入的数据量是否与页面人工核对结果一致。
6.3 浏览器操作的边界提醒
浏览器自动化的风险比前两站高，因为它在真实网络环境中执行动作。三步自查必须做：
- 页面是否被网站条款允许自动化？
- 操作是否涉及登录凭据、个人隐私、支付接口或未授权数据？
- 如果脚本误操作，是否会造成不可恢复的修改？
建议第一次运行时采用“只读模式”，脚本只负责读取和保存，不点击、不提交。确认读取逻辑稳定后，再增加表单填写和提交动作。实际操作中很多意外都来自页面结构微调或加载延迟，所以每步都要加等待条件、超时保护和日志输出。
7. 一小时实战第四站：把前面三站串成业务自动化
7.1 业务自动化的目标
第四站不是新功能，而是集成。把小应用、Skills、浏览器操作串成一个连续任务。一个典型的自动化场景：
- 浏览器操作模块从授权列表页抓取原始英文产品描述；
- Skills 模块批量执行“产品描述中文摘要”技能；
- 小应用页面展示对照结果，供业务人员修正；
- 修正后的数据自动写入报表系统。
整个流程的数据流向是单向的，每一步的输出都是下一步的输入，中间任何一步都可以暂停、人工介入、回滚。
7.2 自动化调度脚本示例
python复制import time
import json
from logger import Logger
log = Logger("automation.log")
def main():
log.info("开始自动化流程")
# 第一步：抓取页面数据
raw_items = browser_capture()
log.info(f"抓取到 {len(raw_items)} 条记录")
# 第二步：Skills 批量处理
processed_items = []
for item in raw_items:
result = claude_skill_call("contract_summary", item["raw_text"])
processed_items.append({
"id": item["id"],
"zh_summary": result["summary"],
"en_quote": result["quoted_sentence"]
})
time.sleep(1) # 避免接口请求过于密集
# 第三步：写入输出文件
with open("output.json", "w", encoding="utf-8") as f:
json.dump(processed_items, f, ensure_ascii=False, indent=2)
log.info("自动化流程完成")
if __name__ == "__main__":
main()
批量任务时必须设计失败重试。常见做法是给每条任务编号并保存状态，处理失败的任务放入 retry_queue，让脚本在下一次循环只处理未完成项。不建议在主流程里直接用大循环反复调用，因为一旦中间步骤出错，整个任务都要从头跑。
7.3 人工复核与告警
自动化不是无人化。每小时实战跑通的自动化流程，至少要保留两层人工保障：输出数据落盘前做一次数量和字段完整性检查；每次自动化运行结束后，把操作日志、调用 token 数、失败任务数汇总成一份运行报告。
如果业务方无法接受自动生成的最终结果直接进入生产流程，可以先把自动化输出保存为待审核草稿，由人工点击确认后再进入下一环节。这样一个小时跑通的自动化就具备了基本的工程可用性。
8. 资源占用、成本与性能观察
Claude 一小时实战的资源占用主要是 API 调用费用和本地进程资源。
8.1 费用观察
每次调用 Claude 接口都会消耗 token。中英双语功能对 token 的消耗比单语高，因为输出内容要同时包含两种语言。观察费用的方法很简单：在控制台查看每次请求的输入输出 token 统计，对比“直接要求翻译”和“通过 Skills 封装后执行翻译”的差异。
从实际体验看，使用 Skills 的早期阶段 token 消耗会略高，因为模型要读取 SKILL.md 定义；但任务复杂度提升后，Skills 能减少模型重新理解需求的开销，总体会更稳定。
8.2 延迟观察
浏览器操作环节主要耗时在网络请求和页面渲染，Claude API 本身的响应时间反而是次要因素。建议在自动化脚本中记录三个时间指标：API 请求开始时间、API 返回时间、下游步骤完成时间。这样能快速定位是模型调用慢，还是本地浏览器操作慢。
8.3 如何降低消耗
- 把长文本按合理长度分块，避免一次请求塞入过多上下文；
- 设置合理的
max_tokens，防止模型输出超长无关内容； - 关闭浏览器操作中不必要的截图和录屏；
- 对固定格式的网页抓取，优先使用选择器提取文本，而不是把整个页面截图抛给模型识别。
9. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| API 返回 401 或 403 | API Key 错误、权限不足 | 检查环境变量和控制台密钥状态 | 重新生成 Key，确认账号有对应模型权限 |
| API 返回 429 | 请求频率过高或余额不足 | 查看控制台用量 | 增加请求间隔，补充额度 |
| 中英双语输出结构不稳定 | SKILL.md 输出格式描述不够具体 | 对比多次输出结果 | 在 SKILL.md 中增加字段级示例 |
| 浏览器脚本找不到页面元素 | 页面结构变化或加载未完成 | 查看 DOM 结构，开启页面等待日志 | 改用更稳定的选择器，增加显式等待 |
| HTML 小应用页面打不开 | 路径错误、静态服务未启动 | 检查终端日志 | 用 python -m http.server 8000 重新启动 |
| 批量任务中途失败 | 单条数据格式异常 | 查看任务状态表 | 增加重试队列，跳过异常项后继续执行 |
| 本地服务端口被占用 | 上一次进程未退出 | 查看端口占用 | 换端口或清理进程 |
9.1 接口报错后的结构化排查流程
当接口调用报错时，先看返回的错误体，不要只看状态码。错误体中的 error.type 和 message 能直接指出是认证问题、上下文长度问题还是模型参数问题。
通用排查脚本：
python复制import anthropic
import os
client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
try:
response = client.messages.create(
model=MODEL_NAME,
max_tokens=256,
messages=[{"role": "user", "content": "hello"}]
)
print(response.content[0].text)
except anthropic.APIStatusError as e:
print("状态码:", e.status_code)
print("错误信息:", e.body)
这样排查能快速区分“账号权限问题”“参数问题”和“服务端限流”。
10. 最佳实践与使用建议
10.1 一小时实战的时间分配建议
标题写“一小时”，但实际操作建议按 90 分钟规划，预留缓冲。推荐时间分配：
- 第 0-10 分钟：环境检查和环境变量配置；
- 第 10-25 分钟：完成小应用生成与浏览器打开；
- 第 25-40 分钟：完成第一个 Skills 定义与三份样本测试；
- 第 40-55 分钟：完成浏览器操作脚本的只读测试；
- 第 55-70 分钟：串联自动化流程，跑通一次完整任务；
- 剩余时间：整理日志、排查问题、沉淀模板。
10.2 中英双语的工程化
中英双语并不仅是“翻译请求”，建议把双语要求写进 SKILL.md 和处理脚本。例如：“输出字段固定为 title_zh、title_en、summary_zh、summary_en”，这样后续无论谁来运行技能，输出都是同一套 schema，下游程序不需要处理键名不一致问题。
10.3 安全与合规基线
- API Key 一律走环境变量，不上传、不写死、不提交到公开仓库；
- 数据脱敏后再交给云端模型处理，尤其是合同、个人信息、内部系统数据；
- 浏览器自动化只操作自己有权限的网站，不在生产系统高频试错；
- 批量任务必须限量限频，避免对业务系统造成额外负载；
- 对外输出前人工复核，尤其涉及金额、日期、法律责任的内容。
10.4 保留最小可运行模板
每次实战结束后，把能跑通的最小配置复制到 templates/ 目录，形成自己的模板库。下次遇到类似任务时直接套用，不需要从零开始。模板库建议包含：环境变量说明、SKILL.md 规范、调用脚本样例、测试输入三份、输出样例一份。
11. 总结与下一步
Claude 一小时实战最值得尝试的点是“四个能力模块的串联”。小应用解决输入输出展示，Skills 解决重复规则的固化，浏览器操作解决外部数据获取，业务自动化把三者变成一个可运行的流程。最先应该验证的是 Skills 的稳定输出，因为它是整个自动化链路能复用的基础。最容易踩的坑是浏览器选择器不稳定和批量任务缺少失败重试机制，第一次跑通后先不要急着扩大任务量，而是先补日志、补异常处理、补人工复核环节。
下一步可以沿着两条线扩展：一是把现有的“单次脚本”升级成带定时调度的任务服务，增加运行状态看板；二是把 Skills 和浏览器操作模块逐步抽象成独立的内部工具，让团队其他成员不需要懂编程也能配置新的自动化场景。对大多数团队来说，真正有价值的不是一次一小时演示，而是把这套方法沉淀成一套可复用的内部流程。建议收藏备用，下次遇到重复性文档处理和网页数据整理任务时，直接按流程来。