Claude API+Skill+浏览器操作：一小时构建业务自动化流水线

过去半年里，关于 Claude 的讨论重心早已不是“谁的对话更像人”，而是另一件更实际的事：Claude 能不能从聊天窗口里走出来，真正参与开发者和业务人员的日常流程。它能通过 API 被嵌入小应用，能通过 Skills 获得某个岗位的业务规范，还能通过浏览器操作直接读取页面、点击按钮、提交表单。换句直接的话说，模型正在从“回答问题”变成“处理工作”。

我的判断是：Claude 在业务自动化赛道里真正的价值，不是单次回答质量又提升了多少，而是它把「技能沉淀」和「过程执行」这两件事接起来了。过去我们为每个自动化场景写胶水代码，维护一大堆规则和分支，页面一改版脚本就崩；现在可以把一部分流程判断交给模型，用可复用的 Skill 沉淀业务规则，再用浏览器操作去覆盖那些没有开放 API 的老系统。

这篇文章会用一次“一小时实战”的节奏，带你跑通四件事：用 Claude API 构建一个最小应用、定义并挂载一个周报 Skill、通过浏览器操作接管页面的数据读取、最后把三者串成一条可验证的业务自动化流水线。示例代码统一采用中英双语注释，输出也尽量中英双语，方便团队协作和后续维护。

1. 这篇文章真正要解决的问题

先说清楚痛点，否则你可能会误以为这又是一篇“Claude 功能清单”。

业务自动化的真实成本，从来不在模型侧，而在集成侧。 一个典型场景：每天早上，运营需要从内部看板抄数据，整理成周报，发布到企业 Wiki 或钉钉群。这个流程里没有一处是“智能”的，全是重复劳动，但自动化它却要面对三个麻烦：

• 很多内部系统没有开放 API，或者 API 权限申请要审批两三个月；
• 周报格式随团队变化，每次调整都要改一遍脚本里的模板代码；
• 数据源、生成器、发布工具三套东西互相割裂，没有统一的“流程编排层”。

Claude 这一套工具链，恰好是把这三块成本分别降下来：API 解决应用集成，Skill 解决业务规则沉淀，浏览器操作解决无 API 系统的接入。三者组合之后，流程编排可以交给模型辅助完成，开发者只需要关注边界和校验。

读完这篇文章，你应该能回答下面几个问题：

• 最小可用的小应用怎么用 Claude API 写出来；
• Skill 到底是什么，和提示词有什么区别；
• 浏览器操作应该选 Computer Use 还是 Playwright 这类工具；
• 一条真实的业务自动化流水线，如何串联、如何验证、如何排错。

适合的读者：后端或全栈开发者，想把 LLM 接进业务系统；测试和运维同学，想做巡检告警自动化；以及产品经理或技术负责人，想用最小成本验证“这个环节能不能交给 AI”。

2. 核心概念梳理：Claude、Skill、Tool Use 与 Computer Use

很多教程会把 Claude、Skill、MCP、Computer Use 堆在一起讲，读者看完只知道“很厉害”，不知道各自解决什么问题。这里先用一张表把边界划清楚。

六个概念可以归成一句话：Claude 是大脑，小应用是身体，Skill 是岗位说明书，浏览器操作是手和眼睛，MCP 是通用接线板。

真正容易误解的是 Skill 和系统提示词的关系。系统提示词每次都要把业务规则写一遍，规则一多就超长，改一处要同步改所有调用方；Skill 则是一个固定在项目目录里的“技能文件”，模型在需要的时候自动加载。换个类比：系统提示词是你在每个新员工入职时口头叮嘱一遍，Skill 是给员工一本岗位手册，手册放在抽屉里，用到的时候自己翻。

再解释一下 Tool Use 和 Computer Use 的分工。Tool Use 是模型“发出调用请求”，由你的代码去执行，适合有明确接口的场景；Computer Use 是模型直接给出屏幕坐标和动作，由它控制鼠标键盘，适合面对老系统、无 API、纯 GUI 操作的场景。前者稳定、可控、省 token；后者通用、灵活，但需要更强的安全边界。

3. 环境准备与前置条件

开始写代码前，先把环境准备齐。本文的示例以 Python 为主，同时也需要 Claude Code 来演示 Skill 的挂载方式。

3.1 基础环境清单

版本号无需和本文完全一致，以实际安装结果为准，但 Python 3.9 以上、Node.js 18 以上是比较稳妥的基线。

3.2 安装与配置步骤

bash复制# 1. 安装 Claude Code
npm install -g @anthropic-ai/claude-code

# 2. 验证安装
claude --version

# 3. 创建项目目录
mkdir claude-hour-practice && cd claude-hour-practice

# 4. 创建 Python 虚拟环境
python -m venv .venv
source .venv/bin/activate   # Windows 使用 .venv\Scripts\activate

# 5. 安装 Python 依赖
pip install anthropic playwright

设置 API Key 时，优先使用环境变量，而不是把密钥写死在代码里：

bash复制export ANTHROPIC_API_KEY="你的密钥"

这里要强调一个安全习惯：任何情况下都不要把 API Key 写进代码、配置或文档提交到仓库。 一旦泄露，别人可以消耗你的额度，甚至读取你允许模型访问的数据。更稳妥的做法是使用公司的密钥管理服务，或者在 CI 环境里从受管凭据注入。

Playwright 还需要安装浏览器内核：

bash复制python -m playwright install chromium

3.3 项目目录规划

text复制claude-hour-practice/
├── .claude/
│   └── skills/
│       └── weekly-report/
│           └── SKILL.md
├── data/
│   └── today_stats.json
├── output/
├── demo1_weekly_report.py
├── demo3_browser_playwright.py
├── demo4_automation.py
└── publish_to_wiki.py

目录设计遵循一个原则：数据和逻辑分离，技能和代码分离。 Skill 放在 .claude/skills 下，是因为 Claude Code 会按照这个约定自动扫描并加载；业务数据放在 data 下，是为了让自动化脚本可以只关心“读文件、调模型、写文件”这条链路。

4. 示例一：用 Claude API 构建最小应用

第一个示例不追求复杂，目标是跑通“调用 Claude API 完成一个真实小任务”：把散乱的会议记录整理成结构化周报。

4.1 完整代码

python复制# demo1_weekly_report.py
# Purpose: Convert messy meeting notes into a structured weekly report
# 用途：调用 Claude API 将零散会议记录整理为结构化周报

import os

from anthropic import Anthropic

# 从环境变量读取密钥，避免硬编码
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

raw_notes = """
2025-06-10 10:00 产品评审
讨论了首页改版方案，决定采用B方案。
移动端适配需要加急，计划两周内完成。
增长组反馈注册转化率偏低，需要安排A/B测试。
"""

response = client.messages.create(
    model="claude-sonnet-4-5",  # 请以官方模型列表为准
    max_tokens=1024,
    system=(
        "You are a technical team assistant. Turn scattered meeting notes "
        "into a structured weekly report.\n"
        "你是一名技术团队助理，负责把零散会议记录整理成结构化周报。"
    ),
    messages=[
        {
            "role": "user",
            "content": f"请把下面会议记录整理成周报格式：\n\n{raw_notes}",
        }
    ],
)

print(response.content[0].text)

这段代码的关键点有三个：

1. messages.create 是 Claude API 的核心入口，system 定义角色，messages 是对话上下文；
2. model 参数要以官方模型列表为准，不同时期可用模型会变化，建议写成配置项而不是硬编码；
3. max_tokens 要结合任务复杂度设置，周报这类任务 1024 足够，太长会增加成本和等待时间。

4.2 运行与验证

bash复制python demo1_weekly_report.py

预期输出是一段包含“本周进展、风险、下周计划”的文本。判断成功不只看有没有输出，还要看内容是否忠实于原文：日期、决策、时间点不能丢失，也不能新增原文没有的事实。这一步其实是后面所有自动化流程的基础——先确认模型在单次调用里稳定可靠，再谈串联。

如果输出出现乱码或截断，优先检查终端编码和 max_tokens；如果报 401，检查 ANTHROPIC_API_KEY 是否正确导出。

5. 示例二：用 Skills 给 Claude 注入业务知识

单次调用能解决的问题有限。真实业务里，周报有固定模板、有指标口径、有风险责任人要求，这些规则如果每次用提示词塞给模型，既容易超长，又难维护。Skill 就是为此设计的。

5.1 什么是 Skill

Skill 是项目目录下一个包含 SKILL.md 的文件夹。SKILL.md 的头部有一段 YAML 格式的元信息，其中 description 特别重要：Claude Code 会根据 description 判断“这个技能什么时候该被用”。正文则是完整的行为规范，相当于一份岗位说明书。

markdown复制# 文件路径：.claude/skills/weekly-report/SKILL.md
---
name: weekly-report
description: 当用户需要生成周报、整理工作周报、合并多个任务更新时使用。输出格式遵循公司周报模板。
---

# Weekly Report Skill

You are a weekly report assistant. Follow the rules below strictly.
你是周报撰写助手，必须严格遵循以下规范。

## 输出模板 / Output Template

周报必须包含四个模块：

1. Progress / 本周进展
2. Risks & Blockers / 风险与阻塞
3. Next Week Plan / 下周计划
4. Coordination Needed / 需要协调事项

## 规则 / Rules

- 每个模块最多 5 条要点，每条以动词开头
- 风险项必须标注负责人
- 所有日期统一使用 YYYY-MM-DD 格式
- 输出标题使用中英双语，正文使用中文

5.2 Skill 如何生效

进入项目目录启动 Claude Code：

bash复制cd claude-hour-practice
claude

然后在对话里说一句：

text复制根据 data/today_stats.json 里的数据，生成今天的周报。

Claude Code 会读取 .claude/skills 下的所有技能描述，判断 weekly-report 匹配当前任务，然后加载 SKILL.md 作为行为的约束。它的好处是：业务规则只维护一份文件，改了 Skill，所有相关自动化、所有团队成员的行为就一起改了。

这里有一个新手最容易踩的坑：description 写得太泛，比如“处理文档”，结果任何任务都可能触发它，反而干扰正常回答；或者写得太窄，比如只写“生成周报”，用户说“帮我写个周报发到群里”就匹配不上。建议 description 覆盖同一个技能可能被唤起的多种说法，并给出反例排除说明。

Skill 和普通提示词最大的区别，也值得再强调一次：普通提示词是“每次调用都带上”，Skill 是“需要时自动加载”。它在模式上非常接近工程师日常的“配置即代码”，可以提交到 Git 做版本管理，可以评审，可以回滚，这是它能进入生产流程的关键。

6. 示例三：浏览器操作的两种路径

业务自动化最让人头疼的是“没有 API 的老系统”。浏览器操作就是为了补上这一块。目前主流有两类做法：Computer Use 和 Playwright 类自动化工具。

6.1 两种路径对比

如果目标是“读取某个页面上的表格数据”，直接用 Playwright 抓取页面文本，再交给 Claude 分析，是性价比最高的方案；如果目标是“像人一样操作一个没有任何接口的老客户端”，才需要考虑 Computer Use。

6.2 路径一：Playwright 抓取页面 + Claude 分析

python复制# demo3_browser_playwright.py
# Purpose: Capture a dashboard page and let Claude analyze the content
# 用途：抓取看板页面文本，交给 Claude 做数据分析

import asyncio

from anthropic import Anthropic
from playwright.async_api import async_playwright

async def capture_dashboard(url: str) -> str:
    """Open the page and return visible text content."""
    async with async_playwright() as p:
        browser = await p.chromium.launch(headless=True)
        page = await browser.new_page()
        await page.goto(url, timeout=15000)
        # 等待关键表格出现，动态页面必须显式等待
        await page.wait_for_selector("table.daily-stats", timeout=10000)
        text = await page.locator("body").inner_text()
        await browser.close()
        return text

async def main():
    # 示例使用本地测试页面；生产环境请替换为授权访问的内网地址
    url = "http://localhost:8080/dashboard"
    content = await capture_dashboard(url)

    client = Anthropic()
    response = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        messages=[{
            "role": "user",
            "content": (
                "This is the text of a dashboard page. Extract new user count, "
                "order count, and tell me whether an alert is needed "
                "(threshold: new users < 100).\n"
                "这是某个看板页面的文本内容，请提取新增用户数、订单量，"
                "并判断是否需要告警（阈值：新增用户小于 100）。\n\n"
                f"{content[:6000]}"
            ),
        }],
    )
    print(response.content[0].text)

if __name__ == "__main__":
    asyncio.run(main())

这个示例的关键在于分工：Playwright 负责“确定性的部分”，比如打开页面、等待元素、抓取文本；Claude 负责“判断性的部分”，比如从文本中提取指标、比较阈值、生成结论。这样既保留自动化稳定性，又利用模型的理解能力。

6.3 路径二：Computer Use 操作任意界面

如果页面没有稳定的选择器，或者要操作的是桌面应用，就需要 Computer Use。它的基本循环是：截图 → 模型决定动作 → 执行动作 → 再截图，直到任务完成。

python复制# demo3_computer_loop.py
# Purpose: A minimal loop for Computer Use (screen-based operation)
# 用途：Computer Use 最小循环骨架：截图、决策、执行、再截图

import base64
import time

import anthropic

client = anthropic.Anthropic()

def capture_screen() -> bytes:
    """返回当前屏幕 PNG 字节。生产环境建议使用虚拟机截图接口。"""
    # 示例：from PIL import ImageGrab
    # img = ImageGrab.grab()
    # img.save("screen.png")
    # return open("screen.png", "rb").read()
    raise NotImplementedError("请接入你的截图方案")

def run_action(action):
    """解析并执行模型返回的动作，例如 click、type、scroll。"""
    # action 示例：{"action": "click", "coordinate": [640, 400]}
    raise NotImplementedError("请接入动作执行方案")

def main():
    # 限制最大步数，防止模型反复决策产生失控循环
    for step in range(20):
        screenshot = capture_screen()
        response = client.messages.create(
            model="claude-sonnet-4-5",  # 以官方模型列表为准
            max_tokens=1024,
            tools=[{
                "type": "computer_20250113",  # 工具类型名以官方 API 文档为准
                "name": "computer",
                "display_width_px": 1280,
                "display_height_px": 800,
                "display_number": 1,
            }],
            tool_choice={"type": "auto"},
            messages=[{
                "role": "user",
                "content": [
                    {
                        "type": "image",
                        "source": {
                            "type": "base64",
                            "media_type": "image/png",
                            "data": base64.b64encode(screenshot).decode(),
                        },
                    },
                    {
                        "type": "text",
                        "text": "请点击页面上的‘导出数据’按钮。如果已经出现下载，直接停止。",
                    },
                ],
            }],
        )

        # 解析响应里的 tool_use 块并执行
        for block in response.content:
            if block.type == "tool_use" and block.name == "computer":
                run_action(block.input)

        # 如果模型直接返回文本，表示认为任务已完成
        if all(block.type == "text" for block in response.content):
            print("Task considered done / 模型认为任务已完成")
            break

        time.sleep(1)

if __name__ == "__main__":
    main()

需要特别提醒：Computer Use 一定要在隔离环境里跑。 模型可能点错按钮、发错消息、删掉文件，这不是模型“故意的”，而是这类操作的固有风险。更稳妥的做法是在虚拟机或容器里运行，并且为它配置最小权限账号。生产环境如果要使用，务必加入人工确认环节。

6.4 在 Claude Code 里注册浏览器 MCP

如果你的主要工作形态是 Claude Code，可以直接注册 Playwright MCP 服务器，让 Claude 在对话中调用浏览器：

bash复制# 注册 Playwright MCP
claude mcp add playwright -- npx @playwright/mcp@latest

# 查看已注册的 MCP
claude mcp list

注册后在 Claude Code 对话中就可以直接说：“打开 http://localhost:8080/dashboard，读取表格数据，把今日指标写入 docs/dashboard_today.md”。Claude 会调用 MCP 暴露的浏览器工具，完成导航、定位、读取和写文件。MCP 的好处是工具接入标准化，一次注册，后续多个任务都能复用。

7. 示例四：业务自动化串联与运行验证

把前面三块拼起来，就得到一条完整的业务自动化流水线：读取数据 → 调用 Claude 生成周报（遵守 Skill 规范）→ 输出文件 → 发布到测试环境 Wiki。

7.1 自动化主流程代码

python复制# demo4_automation.py
# Purpose: A small business automation flow: data -> Claude -> weekly report
# 用途：业务自动化主流程：业务数据 → Claude 生成周报 → 输出到 output 目录

import json
from pathlib import Path

from anthropic import Anthropic

BASE_DIR = Path(__file__).parent
SKILL_FILE = BASE_DIR / ".claude" / "skills" / "weekly-report" / "SKILL.md"
DATA_FILE = BASE_DIR / "data" / "today_stats.json"
OUTPUT_DIR = BASE_DIR / "output"


def load_today_data() -> str:
    """读取当日业务数据，返回 JSON 字符串。"""
    raw = json.loads(DATA_FILE.read_text(encoding="utf-8"))
    return json.dumps(raw, ensure_ascii=False, indent=2)


def generate_weekly_report(client: Anthropic, data_text: str, skill_text: str) -> str:
    """调用 Claude 生成周报，system 中注入 Skill 规范。"""
    response = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=2048,
        system=(
            "You are a weekly report assistant. Follow the skill spec strictly.\n"
            "你是周报撰写助手，必须严格遵循技能规范。\n\n"
            f"{skill_text}"
        ),
        messages=[{
            "role": "user",
            "content": (
                f"Today's data is:\n{data_text}\n"
                f"今天的业务数据如下，请生成周报。"
            ),
        }],
    )
    return response.content[0].text


def main():
    client = Anthropic()
    skill_text = SKILL_FILE.read_text(encoding="utf-8")
    data_text = load_today_data()

    report = generate_weekly_report(client, data_text, skill_text)

    OUTPUT_DIR.mkdir(exist_ok=True)
    out_file = OUTPUT_DIR / "weekly_report.md"
    out_file.write_text(report, encoding="utf-8")

    print("Report generated / 周报已生成:", out_file)
    print(report[:500])


if __name__ == "__main__":
    main()

对应数据文件：

json复制{
  "date": "2025-06-10",
  "new_users": 328,
  "orders": 1204,
  "gmv": 158000,
  "bugs": [
    { "id": "BUG-120", "title": "支付回调偶发超时", "owner": "张三" },
    { "id": "BUG-121", "title": "小程序白屏", "owner": "李四" }
  ]
}

这段代码做的事情非常朴素：读文件、调模型、写文件。但正式因为它朴素，才适合作为自动化主链路的骨架。Skill 的规范通过 system 注入，这样即使不用 Claude Code，纯 API 调用也能复用同一个技能文件，保证了规则的一致性。

7.2 发布到测试环境

python复制# publish_to_wiki.py
# Purpose: Publish the generated report to a test wiki page
# 用途：把生成的周报发布到测试环境 Wiki（仅测试环境示例）

import asyncio

from playwright.async_api import async_playwright


async def publish(report_path: str, wiki_url: str) -> None:
    """在测试环境把报告写入页面并点击发布。"""
    async with async_playwright() as p:
        browser = await p.chromium.launch(headless=True)
        page = await browser.new_page()
        # 生产环境请使用受控登录态或调用 Wiki 的正式 API
        await page.goto(wiki_url)
        report_text = open(report_path, encoding="utf-8").read()
        await page.fill("#report-editor", report_text)
        await page.click("button#publish")
        await page.wait_for_selector(".published-tip", timeout=10000)
        await browser.close()
        print("Published / 已发布")


if __name__ == "__main__":
    asyncio.run(publish("output/weekly_report.md", "http://localhost:8080/wiki/new"))

这段代码只能跑在测试环境。真实生产环境里，发布动作建议改成调用 Wiki 的正式 API，并且在发布前加入人工确认：打印报告预览，等待审批，再执行发布。任何“自动发送”“自动发布”“自动删除”类动作，都应该默认为高风险操作。

7.3 运行与验证流程

bash复制# 1. 运行自动化主流程
python demo4_automation.py

# 2. 检查输出文件
cat output/weekly_report.md

# 3. 检查是否符合 Skill 规范（建议手动抽查当天内容）
grep -E "Risks|Coordination" output/weekly_report.md

# 4. 测试环境发布
python publish_to_wiki.py

判断成功的标准不是“程序没有报错”，而是这四条：

1. 输出文件包含 Skill 模板要求的四个模块；
2. 每条风险事项标注了负责人；
3. 日期格式是 YYYY-MM-DD；
4. 发布后页面内容与生成文件一致。

建议再加一次“干跑验证”：先只生成不发布，人工检查一两天，确认格式稳定后，再加入自动发布环节。这样可以把模型输出质量的风险和自动化流程的风险分开排查。

8. 常见问题与排查方法

自动化脚本的失败往往不是“模型不行”，而是环境、权限、选择器、上下文这些细节问题。这里列一组高频问题。

这里的核心思路是：先定位层，再定位因。 报错先看是哪一层的问题：密钥层、网络层、模型参数层、页面操作层还是数据层。不要一上来就怀疑模型的智能，大多数“模型不听话”的问题，根源在上下文结构或者 Skill 的触发描述上。

9. 最佳实践、安全边界与工程建议

自动化跑通只是第一步，能稳定运行、能回滚、不产生安全事故，才算真正进入生产。

9.1 安全与权限

• 密钥管理：API Key 永远不要进代码仓库，使用环境变量、密钥管理服务或 CI 受管凭据；
• 最小权限：给自动化脚本分配的账号，只授予本次任务必需的权限；不要用管理员账号跑浏览器操作；
• 隔离环境：Computer Use 和高风险浏览器操作，在虚拟机或容器中运行，防止误操作影响生产系统；
• 人工确认：发送消息、发布内容、删除数据、执行付款类动作，必须保留人工确认环节；
• 审计日志：记录每一次模型调用、每一步浏览器动作、每一次发布操作，出问题时能复盘。

9.2 工程化建议

• Skill 进 Git：Skill 文件是业务规则的代码化表达，必须纳入版本管理，变更要评审；团队里应指定负责人维护。
• 数据校验前置：喂给模型之前先校验数据完整性，空数据、异常数据、超大文本要提前拦截，而不是让模型消化坏数据。
• 输出校验后置：对模型输出做规则校验，比如必须包含四段标题、日期格式正确、风险项有负责人，校验不过就拒绝发布。
• 成本控制：设置 max_tokens 上限，长文本先截断或摘要；对常用数据做缓存，减少重复调用。
• 重试与幂等：API 调用要处理 429 和临时错误，采用指数退避重试；整个自动化流程要设计成可重复执行且结果一致。
• 干跑模式：强烈建议脚本支持 DRY_RUN 开关，默认只生成不发布，需要显式开启才执行写操作。

9.3 从原型到生产的分阶段路径

一小时能跑通的是原型，它是用来验证“这条业务链路是否值得自动化”的。进入生产前，至少要补上三件事：稳定的数据源接入、完善的观测和告警、以及操作审批流程。顺序建议是：先做只读自动化，再做生成类自动化，最后才考虑写操作类自动化。

10. 总结与后续学习方向

一个小时的时间里，我们实际上完成了一条完整的认知链路：从 Claude API 的最小应用，到 Skill 注入业务规范，再到浏览器操作处理无 API 系统，最后串联成可运行、可验证的业务自动化流水线。每个环节都有它要解决的具体问题，也都对应着不同的工程风险。

下一步如果继续深入，建议优先研究三个方向：一是 MCP Server 开发，把团队内部的数据源和工具封装成标准接口；二是 Skill 的系统化设计，比如为不同岗位沉淀可复用的技能包；三是自动化流程的评测机制，用一批固定案例去回归测试，确保证改 Skill 或换模型后输出质量不回退。

最后提醒一句：这类自动化最危险的判断，不是“AI 能不能做”，而是“该不该让它做”。凡是涉及发布、删除、转账、对外通信的动作，先想清楚人工确认放在哪一步，再谈效率提升。把边界设好，Claude 这套工具链才会真正成为团队可靠的自动化帮手，而不是下一个需要紧急回滚的定时炸弹。