Claude一小时实战：从API到Skills再到浏览器自动化

很多业务团队在尝试把 AI 从“聊天问答”推进到“真正干活”时，往往卡在同一点：模型确实聪明，能写文案、能答问题，但一旦要做数据抽取、页面点击、表单填写、结果回写这些具体动作，就处处碰壁。Claude 及周边生态正好提供了一套组合能力：从最轻量的小应用，到可复用的 Skills，再到浏览器操作和端到端业务自动化。这篇文章按“一小时实战”来组织，四站任务分别是：10 分钟搭一个带双语输出的小应用，15 分钟定义一个标准化的 Skill，20 分钟完成浏览器操作自动化，最后 15 分钟把前面三件事串成一个业务自动化流程。适合有基础编程经验、想快速掌握 Claude 工程化用法的开发者，也适合零基础但愿意跟着敲代码的初学者。

1. 一小时前，先弄清这几个概念

在动手写代码之前，先用几分钟把四个关键概念理清楚。Claude、Skills、浏览器操作、业务自动化这四个词很容易被混在一起，但它们在实战中承担的任务完全不同。

1.1 Claude 不只是聊天框

Claude 是 Anthropic 推出的大语言模型系列，常见的使用方式有三种：网页版聊天、API 调用、命令行工具 Claude Code。网页版适合日常提问，API 适合嵌入到自己的系统里，Claude Code 则是面向开发者的终端工具，可以直接读取仓库代码、执行命令、修改文件。

很多人对 Claude 的印象停留在“聊天框”层面，但工程化的核心其实是 API。通过 API，我们可以把 Claude 的推理能力嵌入到任何业务系统中：输入一段文本，Claude 返回摘要、分类结果、抽取出的结构化字段，或者生成一段可执行的代码。本文的四个实战任务，全部围绕 API 和 Claude Code 展开。

1.2 Skills：给 Claude 装上一本“操作手册”

Skills 是 Claude 生态里非常重要但经常被忽略的能力。简单来说，Skill 是一个包含说明文档和示例文件的目录，它告诉 Claude：在执行某类任务时，应该遵循什么流程、使用什么格式、参考什么例子。

可以把 Skill 理解成给 Claude 的一本“操作手册”。比如你希望 Claude 每周帮你生成周报，普通做法是每次写一遍提示词：“请按照以下格式输出周报……”；用 Skill 之后，你只需要告诉它“使用周报 Skill”，Claude 就会自动加载 Skill 里预先写好的模板、规则和示例。

Skill 与 Prompt 的区别在于，Prompt 是一次性的指令，Skill 是可复用的结构化资产，可以在多个项目和团队之间共享。

1.3 浏览器操作：让 Claude 拥有“双手”

Claude 本身只能处理文本，不能直接点击按钮、填写表单。所谓“浏览器操作”，指的是利用代码或工具让浏览器自动执行页面交互，同时由 Claude 负责理解页面内容、决定下一步动作。

在工程实践中，浏览器操作通常有两种方案。

第一种方案是传统自动化脚本：让 Claude 分析网页 HTML，生成 Playwright 或 Puppeteer 脚本，然后执行这些脚本完成页面操作。优点是稳定可控，缺点是 Claude 不直接参与运行时决策。

第二种方案是 Anthropic 推出的 Computer Use 能力：Claude 直接观察屏幕截图，模拟键盘鼠标操作浏览器。优点是灵活，能处理动态页面和意外弹窗，缺点是对模型能力和网络环境要求较高，目前在复杂页面上仍需人工监督。

本文实战部分采用第一种方案，因为它更贴近生产环境，也更容易调试排错。

1.4 业务自动化：把步骤串成流水线

业务自动化是最终目标。它不局限于某一个 API 调用，而是把数据获取、AI 理解、系统操作、结果落库串成一条完整的流水线。

一个典型的自动化流程可能是这样的：

1. 程序从邮箱或 Excel 中读取批量数据；
2. 调用 Claude API 做语义理解，抽取关键字段并生成摘要；
3. 通过 Playwright 打开内部管理系统，将数据填写进表单；
4. 将执行结果写入日志或数据库，并通知相关人。

这四个步骤里，Claude 负责的是“理解”和“决策”，脚本负责的是“执行”，业务逻辑负责的是“串联”。这种分层方式非常重要，后面实战四会展开说明。

2. 环境准备：基础配置

实战开始前，先把环境准备妥当。这一节的内容大约需要 20 分钟，如果你是老手可以跳过部分细节。

2.1 获取 API Key

调用 Claude API 需要有 API Key。登录 Anthropic 控制台后，在 API Keys 页面创建密钥。这里需要注意几点：

• API Key 属于敏感凭证，不要提交到 Git 仓库，建议通过环境变量注入；
• 不同账号可用的模型名单可能不同，实际使用哪个模型 ID，以控制台显示为准；
• API 调用是计费的，测试时建议设置 max_tokens 上限，避免意外产生高额费用。

获取 Key 之后，在命令行里声明环境变量：

bash复制export ANTHROPIC_API_KEY="sk-ant-你的密钥"

Windows 用户可以在 PowerShell 里执行：

powershell复制$env:ANTHROPIC_API_KEY="sk-ant-你的密钥"

2.2 准备运行环境

本文示例使用 Python 3.10 或更高版本，核心依赖有两个：

• requests：用于调用 Claude API；
• playwright：用于浏览器自动化。

建议先创建一个独立的虚拟环境，避免依赖冲突。

bash复制mkdir claude-one-hour
cd claude-one-hour
python -m venv venv
source venv/bin/activate    # Windows: venv\Scripts\activate
pip install requests playwright
playwright install chromium

执行完这四条命令后，环境中就具备了调用 API 和操作浏览器的能力。

用下面的命令验证环境是否正常：

bash复制python -c "import requests; print('requests ok')"
python -c "from playwright.sync_api import sync_playwright; print('playwright ok')"

如果两个库都能正常导入，环境准备就算完成了。版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示配置思路。

2.3 用 Claude Code 还是直接调 API

Claude Code 是 Anthropic 的终端编程助手，可以直接在当前目录下工作，能读写文件、执行命令。它的优点是上手快，适合在项目中交互式使用 Claude。安装方式：

bash复制npm install -g @anthropic-ai/claude-code

安装后，在项目目录里输入 claude 即可进入交互界面。

但是，对于本文的浏览器操作和业务自动化场景，Claude Code 更适合作为开发辅助工具，真正落地自动化流程时仍需写 Python 脚本。所以本文的主线是 Python 脚本调用 API，Claude Code 作为备用工具出现在 Skill 部分。

3. 实战一：10 分钟构建一个小应用

第一个任务是在 10 分钟内构建一个可运行的小应用。这里我们做一个“中英双语摘要器”：输入一段任意文本，程序调用 Claude API，分别输出中文摘要和英文摘要。

这个小应用虽然简单，但涵盖了 API 调用的核心流程：构造请求、处理响应、异常兜底。

3.1 明确小应用的需求

需求可以拆成三块：

• 输入：一段文本，支持从命令行标准输入读取；
• 处理：调用 Claude API，生成中文摘要和英文摘要；
• 输出：在控制台分两段打印结果。

这里选择“摘要”作为功能，是因为摘要任务能直观展示 Claude 的理解能力，同时代码量小，适合 10 分钟内完成。

3.2 核心代码：调用 Claude API 做中英双语摘要

创建文件 summarizer.py：

python复制# 文件：summarizer.py
# Bilingual Summarizer - 中英双语摘要小应用

import os
import sys
import requests

API_URL = "https://api.anthropic.com/v1/messages"
API_KEY = os.environ.get("ANTHROPIC_API_KEY")

# 注意：这里使用占位模型 ID，请替换为控制台内可用的真实模型 ID
MODEL_ID = "claude-xxx-xxxx"


def summarize(text: str, language: str) -> str:
    """调用 Claude API 生成指定语言的摘要。

    Summarize the given text in the target language.
    """
    system_prompt = (
        "You are a professional summarization assistant.\n"
        "你是一名专业的摘要助手。请用简洁清晰的语言概括用户输入的核心内容。\n"
        f"Target language / 目标语言：{language}"
    )

    payload = {
        "model": MODEL_ID,
        "max_tokens": 1024,
        "system": system_prompt,
        "messages": [
            {"role": "user", "content": f"请总结以下内容：\n\n{text}"}
        ],
    }

    headers = {
        "x-api-key": API_KEY,
        "anthropic-version": "2023-06-01",
        "content-type": "application/json",
    }

    resp = requests.post(API_URL, json=payload, headers=headers, timeout=30)
    resp.raise_for_status()

    data = resp.json()
    return "".join(block.get("text", "") for block in data.get("content", []))


def main():
    sample_text = sys.stdin.read().strip()
    if not sample_text:
        sample_text = (
            "Claude is an AI assistant developed by Anthropic. "
            "It can chat, write code, analyze documents, and automate workflows. "
            "Developers use the Claude API to build their own applications."
        )

    print("=== 中文摘要 ===")
    print(summarize(sample_text, "中文"))
    print("\n=== English Summary ===")
    print(summarize(sample_text, "English"))


if __name__ == "__main__":
    main()

这段代码的核心逻辑有四点：第一，通过环境变量读取 API_KEY，避免密钥硬编码；第二，构造 system prompt，在其中指定输出语言；第三，用 requests.post 调用 /v1/messages 端点，超时时间设置为 30 秒；第四，从响应中提取 content 数组里的文本内容并拼接返回。

3.3 运行与验证小应用

准备一个测试文本文件 test.txt：

text复制Large language models are transforming enterprise workflows. 
By combining API calls with browser automation, developers can 
build systems that understand natural language and take real actions.

然后通过标准输入传递给脚本：

bash复制cat test.txt | python summarizer.py

预期输出大致如下：

text复制=== 中文摘要 ===
大型语言模型正在改变企业工作流。开发者将 API 调用与浏览器自动化结合，
可以构建既能理解自然语言、又能执行实际操作的自动化系统。

=== English Summary ===
Large language models are transforming enterprise workflows. 
By integrating API calls with browser automation, developers 
can build systems that understand language and perform real actions.

到这里，第一个小应用已经完成。它只有 60 行左右的代码，但已经具备完整的 API 调用和数据提取流程，这可以成为后续所有自动化任务的基础。

如果你想把小应用变成一个真正的服务，可以用 input() 代替标准输入，或者用 FastAPI 包一个 HTTP 接口，但那是之后扩展的事情，本节已经完成了核心目标。

4. 实战二：自定义 Skills 让重复工作标准化

第二个任务是在 15 分钟内创建一个 Skill，让 Claude 咟标准化格式输出结果。我们以“周报生成”为场景，先把 Skill 的原理讲清楚，再实际创建并验证。

4.1 Skills 与 System Prompt 的区别

System Prompt 是在每次请求时随 API 调用附带指令，适合一次性任务。如果同一个项目里反复需要相同的指令和模板，每次都重写 System Prompt 会很痛苦，而且很容易在各处产生不一致的版本。

Skill 则是把指令、模板、示例打包成一个独立目录，放在项目里统一管理。Claude 在遇到相关任务时会自动读取 Skill 内容，按其中的规范执行。相当于从“写一次性纸条”升级为“建立标准化作业指导书”。

4.2 最小 Skill 文件结构

一个最小的 Skill 目录结构如下：

text复制weekly-report-skill/
├── SKILL.md
└── examples/
    └── sample-report.md

SKILL.md 是核心文件，通常包含两部分：最顶部的 YAML 元信息，以及正文部分的指令说明。元信息里用 name 定义 Skill 名称，用 description 描述适用场景。正文部分写详细的执行规则、输出格式和注意事项。

4.3 实战：创建一个“周报生成”Skill

在项目目录下创建 skills/weekly-report/SKILL.md：

markdown复制---
name: weekly-report
description: Generate a structured weekly report from daily notes.
description_zh: 根据每日工作记录生成结构化的周报。
---

# Weekly Report Skill

你是周报助手。根据用户提供的原始工作记录，输出以下格式的周报：

## 本周核心工作
- 列出 3 到 5 项最重要的工作内容，用一句话概括每项。

## 遇到的问题与解决方式
- 对每个问题，先描述现象，再给出解决办法。

## 下周计划
- 列出下周计划，要求可执行、有优先级。

## 需要协调的资源
- 如果没有则写“无”。

写作要求：
1. 使用简洁的中文表达，关键术语保留英文；
2. 每项工作建议包含量化结果；
3. 不要编造记录中不存在的信息；
4. 如果原始记录过于零散，先在内部整理成时间线，再输出正式周报。

参考示例见 examples/sample-report.md。

再创建示例文件 skills/weekly-report/examples/sample-report.md：

markdown复制## 本周核心工作
- 完成订单模块的接口联调，将平均响应时间从 800ms 降低到 300ms。
- 修复生产环境的登录超时问题，影响用户约 2000 人。

## 遇到的问题与解决方式
- 接口并发冲突：原因是共享缓存未加锁，通过引入分布式锁解决。

## 下周计划
1. 完成性能压测报告；
2. 推进新的活动页面上线。

## 需要协调的资源
- 需要测试环境一套。

这样，一个 Skill 就创建完成了。它最大的价值是让输出格式标准化，后续团队成员可以直接复用同一份规范。

4.4 在 Claude Code 中加载并使用 Skill

如果你是 Claude Code 用户，可以把 skills 目录放到项目的 .claude/skills/ 下，然后启动 Claude Code，在对话里描述需求。当任务匹配 weekly-report 的 description 时，Claude 会自动读取该 Skill 并按规则生成。

例如输入：

text复制这是本周的工作记录：完成了三个需求开发，修复了一个线上 bug，下周准备开始新模块设计。

Claude 就会自动套用周报格式，而不需要你再补充一大堆格式要求。

如果卡在加载环节，可以先检查目录名和文件名是否完全匹配，以及 SKILL.md 是否放在第一层位置。另外，不同版本对目录的读取路径可能不同，建议查阅当前版本的官方文档，确认是 .claude/skills 还是 skills。

5. 实战三：浏览器操作与网页自动化

第三个任务是浏览器操作。这个部分最容易遇到坑，所以必须把原理讲清楚再动手。

5.1 为什么需要浏览器自动化

很多业务系统没有开放 API，录入数据、查询信息、导出报表都只能通过网页操作。浏览器自动化就是在这种场景下介入的：让程序模拟人类用户，自动完成页面访问、表单填写、按钮点击和数据提取。

Claude 在这个过程中的角色主要有两个：分析页面结构、生成操作脚本。也就是说，Claude 不是自己去“点击”，而是负责理解“应该点击哪里”，把动作翻译成可执行的 Playwright 脚本。

5.2 方案对比：Playwright 脚本 vs 原生 Computer Use

为了帮助选型，把两种方案放在一起对比：

在团队没有专门测试环境时，建议先选 Playwright 方案。它更加成熟，运行结果可以记录视频和截图，出了问题容易回溯。

5.3 实战：用 Claude 生成并执行一个网页表单填写脚本

场景设定：在内部系统 http://localhost:3000/#/apply 上，需要录入一批员工申请数据，表单包含姓名、邮箱、申请类型三个字段和一个提交按钮。

第一步，先用 Claude 分析页面的候选表单结构。可以打开浏览器的开发者工具，把关键 HTML 片段拿给 Claude 看，请它生成选择器和建议。这里直接给出稳定的 Playwright 执行代码：

python复制# 文件：auto_fill.py
# Auto fill a web form using Playwright

import time
from playwright.sync_api import sync_playwright

FORM_URL = "http://localhost:3000/#/apply"


def fill_one_apply(page, name: str, email: str, apply_type: str):
    """在页面上填写一条申请记录。"""
    page.fill("#name", name)
    page.fill("#email", email)
    page.select_option("#applyType", apply_type)
    page.click("#submitBtn")
    time.sleep(1)  # 等待页面响应，实际项目中建议用显式等待


def main():
    records = [
        {"name": "张三", "email": "zhangsan@example.com", "type": "leave"},
        {"name": "Li Si", "email": "lisi@example.com", "type": "business"},
    ]

    with sync_playwright() as p:
        browser = p.chromium.launch(headless=False)
        page = browser.new_page()
        page.goto(FORM_URL, wait_until="networkidle")

        for record in records:
            fill_one_apply(page, record["name"], record["email"], record["type"])
            print(f"Submitted: {record['name']} / 已提交：{record['name']}")

        browser.close()


if __name__ == "__main__":
    main()

这段代码的关键点有三处：第一，with sync_playwright() 负责启动和关闭浏览器进程；第二，fill 和 select_option 分别处理输入框和下拉框；第三，headless=False 让浏览器窗口可见，便于调试，生产环境可以改成 headless=True。

实际项目中，选择器可能比 #name 复杂得多。建议先把页面交给 Claude 分析，让它输出一组最优选择器；如果页面是 Vue 或 React 写的，很可能是动态生成的属性，需要多消耗一点时间做稳定性处理。

5.4 安全性与合规注意事项

浏览器自动化可以极大提升效率，但也要注意边界：

• 只能操作自己有权限访问的系统，未经授权不得扫描、爬取或篡改数据；
• 涉及登录操作时，优先使用测试账号或专用隔离环境，不要使用真实生产账号；
• 自动化脚本执行频率要模拟人工速度，避免给服务器造成压力；
• 建议记录完整的执行日志，含时间、操作、结果，便于审计和回溯。

这里特意强调这一点，是因为浏览器自动化的权限能力很强，一旦脚本被误用，可能造成数据泄露或系统异常。

6. 实战四：把上面三件事串成一个业务自动化流程

最后一个实战是把小应用、Skill 和浏览器操作串成一个完整的业务闭环。

6.1 业务流程描述

设想一个实际场景：每天业务人员会收到大量客户申请邮件，需要从邮件里提取客户姓名、联系方式和申请类型，然后在 CRM 系统里录入，最后生成一份统计报告。

传统人工处理每人每天约耗时两小时，而用自动化流程可以实现接近实时的处理。整个流程拆成四个步骤：

1. 读取邮件文件或待处理列表；
2. 调用 Claude API，从文本中抽取结构化字段；
3. 用 Playwright 打开 CRM 页面，逐条录入；
4. 调用小应用生成中英双语处理摘要，保存到报告文件。

6.2 流程编排：从数据获取到结果输出

为了让流程清晰，先设计一个通用的结构。数据获取阶段可以用一个模拟函数替代真实邮件客户端，后续接入企业邮箱时只需替换这一个函数即可：

• fetch_pending_leads()：负责取数，返回原始文本列表；
• parse_lead_with_claude(text)：调用 Claude API 做抽取，返回结构化字段；
• submit_lead_to_crm(lead)：调用 Playwright 填写 CRM 表单；
• generate_report(results)：汇总执行结果并生成双语报告。

这样拆分的意义是，每一层都可以独立测试，任何一个环节出问题都容易定位。

6.3 完整代码示例

下面是完整的自动化脚本，包含以上四个函数：

python复制# 文件：crm_automation.py
# End-to-end business automation with Claude + Playwright
# 基于 Claude 与 Playwright 的端到端业务自动化

import os
import requests
from playwright.sync_api import sync_playwright

API_URL = "https://api.anthropic.com/v1/messages"
API_KEY = os.environ.get("ANTHROPIC_API_KEY")
MODEL_ID = "claude-xxx-xxxx"  # 替换为控制台可用的模型 ID

CRM_URL = "http://localhost:3000/#/lead"


# 第一步：获取待处理的原始文本数据
def fetch_pending_leads():
    """模拟从邮件或文件中读取待处理线索。

    Simulate fetching pending leads from email or file.
    """
    return [
        "客户张三，来自上海，想咨询企业版的 API 套餐，邮箱 zhangsan@example.com",
        "Li Si from Beijing, interested in the enterprise plan, email lisi@example.com",
    ]


# 第二步：用 Claude 从文本中抽取结构化字段
def parse_lead_with_claude(text):
    """调用 Claude API 抽取客户姓名、城市、需求和邮箱。"""
    payload = {
        "model": MODEL_ID,
        "max_tokens": 512,
        "system": (
            "你是信息抽取助手。从客户留言中抽取姓名、所在城市、需求描述、邮箱。\n"
            "输出 JSON 格式：{\"name\": \"\", \"city\": \"\", \"requirement\": \"\", \"email\": \"\"}"
        ),
        "messages": [{"role": "user", "content": text}],
    }
    headers = {
        "x-api-key": API_KEY,
        "anthropic-version": "2023-06-01",
    }
    resp = requests.post(API_URL, json=payload, headers=headers, timeout=30)
    resp.raise_for_status()
    data = resp.json()
    content = "".join(block.get("text", "") for block in data.get("content", []))
    # 实际项目中建议用 JSON 解析库处理；此处直接返回文本以演示流程
    return content


# 第三步：用 Playwright 将结构化字段录入 CRM 系统
def submit_lead_to_crm(lead_fields: dict):
    """根据字段填写 CRM 表单。"""
    with sync_playwright() as p:
        browser = p.chromium.launch(headless=True)
        page = browser.new_page()
        page.goto(CRM_URL, wait_until="networkidle")
        page.fill("#name", lead_fields.get("name", ""))
        page.fill("#city", lead_fields.get("city", ""))
        page.fill("#requirement", lead_fields.get("requirement", ""))
        page.fill("#email", lead_fields.get("email", ""))
        page.click("#saveBtn")
        page.wait_for_timeout(800)
        browser.close()


# 第四步：生成执行报告
def generate_report(results):
    report_lines = []
    for idx, result in enumerate(results, start=1):
        report_lines.append(f"{idx}. {result}")
    with open("automation_report.txt", "w", encoding="utf-8") as f:
        f.write("\n".join(report_lines))
    print("Report generated / 报告已生成：automation_report.txt")


def main():
    raw_leads = fetch_pending_leads()
    results = []

    for raw in raw_leads:
        print(f"Processing: {raw[:30]}...")
        fields_text = parse_lead_with_claude(raw)
        # 实际项目需要真正解析 JSON；这里为演示直接打印
        results.append(fields_text)

    generate_report(results)


if __name__ == "__main__":
    main()

需要注意的是，parse_lead_with_claude 返回的是 JSON 文本，实际项目中需要进一步解析成字典格式，并对缺失字段做兜底判断。上面代码是先跑通流程，再替换成严格解析。

6.4 运行效果与异常兜底

运行脚本：

bash复制python crm_automation.py

正常时会在控制台输出两条处理日志，并生成 automation_report.txt。如果 Playwright 因为定位不到元素而报错，会在 submit_lead_to_crm 位置抛出异常，此时只需要查看错误信息里的选择器，交给 Claude 重新生成即可。

在生产系统中，还应该在每一步增加失败重试、人工确认和消息通知，避免某一条数据失败后整个流程中断。

7. 常见问题与排查思路

这部分整理四个高频问题，按“现象 - 原因 - 解决”的方式速查。

7.1 API 返回 401/403

排查顺序建议：先打印环境变量是否存在，再用 curl 做最小请求，最后检查代码里的 headers 拼写。

7.2 Skills 不生效

Skill 的 description 是触发关键，建议把适用场景和关键词都写进去，例如“周报”“weekly report”“工作记录”。

7.3 浏览器自动化运行不稳定

尽量少用 time.sleep，多用 Playwright 自带的显式等待，例如 page.wait_for_selector("#successMsg")。这能显著提高稳定性。

7.4 业务自动化流程中断

在工程上，自动化流程一定要设计失败隔离和重试策略，否则任何一个小故障都可能造成数据错乱。

8. 最佳实践与工程建议

前面四站已经把一条完整的自动化链路跑通了，这一节是真正进入生产环境之前需要补齐的工程规范。

8.1 权限最小化与敏感信息隔离

凡是涉及浏览器自动化的脚本，权限范围一定要尽量小。建议使用专用测试账号，不直接操作生产数据和真实个人信息。API Key、数据库密码、登录凭证统一放到环境变量或密钥管理服务中，不要写进代码和配置仓库。

另外，日志中不要打印完整邮件地址、手机号等敏感字段，可以用 zhangs***@example.com 这样的脱敏格式。

8.2 日志与审计

自动化流程必须有日志，这是出了问题之后快速定位的关键。日志至少记录以下信息：

• 每步任务开始和结束时间；
• 输入数据的摘要和最终结果；
• 异常信息及堆栈；
• 浏览器操作的截图或视频。

如果预算允许，可以在每次表单提交后保存页面截图，对审计非常有帮助。

8.3 人机协同设计

不是所有环节都适合全自动。对于高风险操作，比如删改生产数据、提交对外支付等，应该设计成“AI 准备 + 人工确认”的模式。即脚本自动预填表单，但最终提交动作由人工点击确认完成。

这种设计既享受了自动化带来的效率提升，又避免了模型幻觉或脚本误操作造成的不可逆后果。

8.4 成本控制与缓存

API 调用按 token 计费，所以代码里要养成控制成本的习惯：

• 设置合理的 max_tokens，不要让一个无关紧要的任务生成几千字；
• 对重复的文本内容做缓存，相同输入直接返回上次结果；
• 抽取任务用较小的上下文，把不需要的信息提前裁剪掉；
• 批量任务优先考虑异步或并发，减少等待时间。

8.5 测试与灰度

自动化脚本也要像正规软件开发一样做测试。先在测试环境跑通整个流程，再切到灰度环境，最后才在生产环境全量放开。每次页面改版后，让 Claude 重新分析选择器并生成新脚本，然后跑回归用例。

建议维护一份核心路径用例清单，包括成功场景、失败场景和边界场景，保证每次升级后自动化流程依然可靠。

9. 总结与后续学习路线

这一小时，我们用四个实战任务走通了 Claude 工程化的完整链路：先是写了一个能生成中英双语摘要的小应用，接着定义了一个可复用的周报 Skill，然后用 Playwright 实现了浏览器表单自动化，最后把三部分串成了业务自动化流程。整条链路的核心思路是分层：Claude 负责理解和生成，脚本负责执行，业务代码负责串联。

接下来可以往三个方向深入。第一个是深入学习 Anthropic 官方文档里的 Agent SDK 和 MCP 模型上下文协议，理解如何让 Claude 与更多外部工具通信；第二个是学习 Playwright 的高级特性，包括网络拦截、PDF 下载、多标签页处理和可视化测试；第三个是工程化方向，研究如何把 Skill 文件和自动化脚本纳入 CI/CD 流程，配合配置中心实现团队级别的能力复用。

实际项目中，最需要注意的风险有三点：API Key 泄露、自动化脚本造成生产数据错误、模型幻觉导致信息误判。围绕这三点，优先把权限隔离、日志审计和人机确认机制做扎实，再逐步放开自动化范围。

如果你已经跟着文章完成了至少两个实战任务，恭喜你，你已经完成了从“会向 Claude 提问”到“会用 Claude 搭建自动化方案”的关键一步。剩下的就是找一个带着痛点的真实业务流程，拆开它，用同样的方式串起来。