Claude一小时实战：从零构建可复用Skills与浏览器自动化链路

“Claude 一小时实战”听起来像一场快速演示，但它描述的是一种值得反复使用的工作方式：在一小时内，用 Claude 生成一个可运行的小应用，配置一组可复用的 Claude Skills，再借助浏览器操作工具完成页面级任务，最后把这些能力组合成一条业务自动化链路。很多开发者已经能顺畅地和模型对话，真正缺的是把零散能力变成稳定流程的那套工程习惯。这篇文章按【中英双语】组织，中文讲解为主，关键术语和代码注释保留英文，并按照“概念 -> 环境 -> 实现 -> 验证 -> 排错 -> 优化”的顺序，带你跑通一个最小闭环。

1. 一小时能做什么：把小应用、Skills 与浏览器操作串成自动化

1.1 小应用：让模型产出从“代码片段”变成“可运行程序”

小应用（small app）在这里指的是由 Claude 生成、可以在本地启动并完成一个具体功能的轻量程序。它可以是一个待办事项页面、一个 JSON 格式化工具、一个内部报表查询页，不需要完整的工程架构，但必须能真实运行。

为什么要先做小应用？因为模型生成代码只是起点，代码能跑起来才是价值点。很多开发者在对话里看到一段不错的代码，复制到本地却因为依赖缺失、路径错误、版本不匹配而无法运行。一小时实战的第一步，就是强迫自己把“让模型写代码”升级为“让模型交付一个可运行的最小产品”。

这一阶段的关键在于收敛需求。越具体的提示词，生成结果越接近可运行状态。后面会用一个待办应用作为最小案例。

1.2 Skills：把重复说明变成模型可查的“项目手册”

Claude Skills 是一组以 Markdown 和脚本形式组织的可复用技能包。通俗地说，它像一本给模型看的项目操作手册：项目的构建命令、输出模板、代码规范、排错步骤，都写在技能目录里，模型在需要时会按 description 决定是否读取正文。

没有 Skills 时，每个新会话都要重新强调一遍规范，提示词越来越长，而且容易遗漏。配置 Skills 后，规范被沉淀成独立文件，团队可以维护、评审、更新。Anthropic 的 Agent Skills 机制中，常见形式是 skills/<技能名>/SKILL.md，文件头部带有 name、description 等元信息，正文写明使用步骤。不同工具的字段可能略有差异，落地前应该先核对当前版本的文档。

1.3 浏览器操作：模型负责决策，浏览器负责执行

Claude 无法自己打开页面、点击按钮或填写表单，它需要借助浏览器操作工具。目前有两种主流实现路线：一类是模型通过 computer use 能力直接观察屏幕并操作鼠标键盘；另一类是通过 MCP（Model Context Protocol）接入 Playwright、Puppeteer 等浏览器服务，把页面操作暴露成一个个工具函数。

两者的选择要按场景来。computer use 适合页面结构无法修改、没有 DOM 接口的旧系统；MCP 浏览器服务则适合现代 Web 页面，它可以直接定位元素、读取 DOM、填写表单，速度更快也更稳定。这里要特别注意操作边界：自动化的目标应该是自己有权访问的页面，首选本地服务或测试环境。

1.4 业务自动化：把三种能力按顺序组合

业务自动化（business automation）不是单一功能，而是把小应用、Skills 和浏览器操作组合成一条可重复执行的流程。最简单的一种组合是：浏览器操作负责采集输入，模型配合 Skills 负责分析生成，小应用或脚本负责保存结果。

一小时的时间可以这样分配：环境准备约 15 分钟，小应用约 15 分钟，Skills 配置约 10 分钟，浏览器操作约 10 分钟，组合联调约 10 分钟。这里还要预留 20% 缓冲，因为第一次操作大概率会遇到环境或工具链问题。

2. 环境准备：把 Claude 接入本地开发链路

2.1 准备清单

开始之前，先确认环境满足基本要求。需要一个可以访问 Claude 服务的账号和 API Key，本地需要 Python 3.11 以上或 Node.js 18 以上任一运行时，终端里可以执行 pip、npx 等命令。

API Key 的命名在不同语言中基本一致：Python 使用 anthropic 官方 SDK 时，会从 ANTHROPIC_API_KEY 环境变量读取；Node.js 环境同样支持。先把 Key 写入终端环境，再继续后面步骤。

2.2 目录规划

一小时实战最容易出现的问题是项目文件散落，技能目录、脚本、小应用混在一起。这里先建立一个干净目录：

text复制claude-hour-practice/
├── app/          # 小应用目录
├── skills/       # Claude Skills 目录
├── automation/   # 业务自动化脚本与输出
└── .env          # 环境变量文件

各目录职责明确：app 放可运行小应用的代码；skills 放所有技能包；automation 放抓取、生成、保存的编排脚本。后面所有示例都基于这个目录结构。

2.3 了解 Claude Skills 的目录结构

在 Anthropic 的 Agent Skills 机制中，技能以目录为单位组织，每个技能目录内有一个 SKILL.md 文件。文件头部使用 YAML frontmatter 写入元信息，正文则描述技能的使用步骤、模板、命令和注意事项。

markdown复制---
name: daily-report
description: 根据用户的工作日志生成中文日报。当用户要求生成日报、工作总结时使用。
---

# Daily Report Skill

## 使用步骤
1. 获取当天的工作日志。
2. 按下面的日报模板生成内容。
3. 只使用用户提供的信息，不要补充用户没有提到的事项。

## 日报模板
- 今日完成
- 明日计划
- 风险与阻塞

这个文件的核心设计是“渐进式披露”：description 需要简短、触发条件明确，正文可以长、完整。模型在对话中先看到 description，判断是否需要查看正文；只有任务相关时才会读取具体步骤。这样能节省上下文，也能让技能保持完整。

2.4 API 连通性验证

配置环境最快的验证方式，是用最小请求确认 API 链路可用。在 automation/tmp_check.py 写入：

python复制from anthropic import Anthropic

client = Anthropic()

message = client.messages.create(
    model="<当前可用的 Claude 模型 ID>",
    max_tokens=64,
    messages=[{"role": "user", "content": "请回复：链路正常"}],
)

print(message.content[0].text)

运行前先确认 anthropic 包已安装：

bash复制pip install anthropic
python automation/tmp_check.py

这里有几个注意点。model 参数中的模型 ID 并不固定，以账号实际可用的模型列表为准；如果请求返回模型不存在，就去当前账号的模型列表里确认最新 ID。如果返回认证错误，则检查 ANTHROPIC_API_KEY 是否已正确导出。

注意：在进入小应用、Skills 和浏览器自动化之前，先跑通这个最小请求。它能帮你把“环境问题”和“业务逻辑问题”分开，避免浪费时间误判。

2.5 中英双语的工程约定

既然标题标记了【中英双语】，项目中可以建立一套稳定的约定：文件路径、函数名、变量名使用英文；Markdown 说明文档以中文为主，关键术语同时保留英文；代码注释使用简短英文，正文解释使用中文。这样既方便国际协作，也方便中文读者理解。后面代码示例里的注释会统一用英文，正文则保持中文讲解。

3. 第一个小应用：让 Claude 生成一个可运行的待办应用

3.1 如何给 Claude 提需求

小应用阶段的目标是让 Claude 返回“能直接运行”的代码而非抽象建议。提示词要包含技术栈、路由、运行命令三个要素。这里给出的提示词模板可以直接复制使用：

text复制请生成一个最小可运行的待办应用，使用 Python FastAPI，只有一个 app.py 文件。
要求：
1. GET / 返回一个 HTML 页面，包含“添加待办”的表单和待办列表。
2. POST /todos 接收名为 item 的表单字段，将待办加入内存列表。
3. GET /todos 返回待办列表 JSON。
4. 给出运行命令。

不限定技术栈时，模型可能生成 React、Express、FastAPI 或其他方案。虽然对学习来说都是选择，但对“一小时内跑通”来说，明确技术栈能大幅降低环境准备成本。

3.2 参考实现 app.py

下面是一个参考实现，作用是验证小应用闭环。实际项目中，可以让 Claude 按上面的提示词生成等价代码，再对比差异。

python复制from fastapi import FastAPI, Form
from fastapi.responses import HTMLResponse, RedirectResponse

app = FastAPI()

todos = []

@app.get("/", response_class=HTMLResponse)
def home():
    items = "".join(f"<li>{item}</li>" for item in todos)
    return f"""<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="utf-8">
<title>Todo App</title>
</head>
<body>
<h1>Todo App</h1>
<form action="/todos" method="post">
<input name="item" placeholder="输入待办事项" />
<button type="submit">添加</button>
</form>
<ul>{items}</ul>
</body>
</html>"""

@app.post("/todos")
def add_todo(item: str = Form(...)):
    todos.append(item)
    return RedirectResponse("/", status_code=303)

@app.get("/todos")
def list_todos():
    return {"todos": todos}

实现里有两个容易忽略的细节。第一个是 item: str = Form(...)，它告诉 FastAPI 从表单字段读取 item，如果不写这个类型声明，POST 请求会返回 422，因为框架不知道参数来自哪里。第二个是 RedirectResponse 使用 303 状态码，避免页面刷新时重复提交表单。

3.3 运行与验证

在 app 目录下安装依赖并启动：

bash复制pip install fastapi uvicorn
uvicorn app:app --reload --port 8000

分别验证接口和页面：

bash复制curl http://127.0.0.1:8000/todos
curl -X POST http://127.0.0.1:8000/todos -d "item=学习 Claude Skills"
curl http://127.0.0.1:8000/todos

预期输出依次是 {"todos":[]}，然后 POST 成功返回 303 跳转，最后第二次 GET 返回 {"todos":["学习 Claude Skills"]}。在浏览器访问 http://127.0.0.1:8000/，可以看到表单和列表。

这一步的常见错误包括：只安装 fastapi 忘记安装 uvicorn、8000 端口被占用、中文内容在 Windows 终端乱码。前两类属于环境问题，统一用“检查安装列表、换端口”的方式处理；中文乱码与终端编码有关，临时可以通过启动前设置 PYTHONIOENCODING=utf-8 缓解。

4. 配置 Skills：让模型按团队规范输出内容

4.1 Skills 和小应用的分工

小应用解决的是“代码能不能运行”，Skills 解决的是“模型输出是否符合预期”。两者并不冲突，而是一前一后的关系：小应用提供工具底座，Skills 约束模型在工具里产出的格式和内容。

一个常见做法是：把输出模板、审查清单、翻译规范写成技能，每次新会话通过技能目录自动加载。相比把规范粘贴在提示词里，技能文件可以被多个项目复用，也可以放在版本库里跟踪变更。

4.2 Skill 示例一：日报生成

在 skills/daily-report/SKILL.md 中写入：

markdown复制---
name: daily-report
description: Generate a Chinese daily report from work logs. Use when user asks for daily report or work summary.
---

# Daily Report

## Steps
1. Ask user for today's work items.
2. Generate report with the template below.
3. Do not add items not mentioned by the user.

## Template
### 今日完成
- ...
### 明日计划
- ...
### 风险与阻塞
- ...

这个技能文件同时展示了中英双语的写法：description 和 Steps 用英文，模板内容用中文，正好符合前面约定的工程风格。

4.3 Skill 示例二：术语对照生成

团队文档场景中，术语对照非常高频。可以单独建一个技能：

markdown复制---
name: bilingual-glossary
description: Generate a Chinese-English glossary table for given technical content.
---

# Bilingual Glossary

## Steps
1. Identify key technical terms from input.
2. Output a Markdown table with columns: English / 中文 / 说明
3. Keep terminology consistent with the provided term base if any.

这个技能的价值在于，当自动化流程生成报告时，Claude 会自动把关键术语整理成对照表，而不需要每次在提示词里解释什么是“中英术语对照”。

4.4 加载 Skills 的两种方式

Skill 的加载方式和工具相关。在 Claude Code 这类命令行工具里，通常通过启动参数或配置文件把技能目录暴露给模型，例如 claude --add-dir skills；在直接调用 API 的脚本里，则需要自己读取 SKILL.md 内容并放入 system prompt 或 user prompt。两种方式的差异，本质上取决于“谁负责读取文件”：命令行工具会自己读取，API 方式需要代码读取。

如果发现技能没有生效，优先检查两条：技能目录是否真正被加载，以及提示词里是否包含了技能正文。调试技巧是先把 SKILL.md 全文粘贴进提示词，确认模板本身可用，再去排查自动加载配置。

5. 浏览器操作：从读取网页到操作网页

5.1 两条技术路线的选择

浏览器操作（browser automation）有两条路线。一条是 computer use，模型通过工具拿到屏幕截图，然后分析坐标并调用鼠标、键盘操作。它的优点是几乎不需要页面提供额外接口，适合处理旧系统；缺点是依赖视觉定位，速度较慢，Web 元素轻微变化就可能导致点击偏位。

另一条是 MCP 浏览器服务，常见的是 Playwright MCP。模型调用 navigate、click、type、extract_content 这类函数操作浏览器。它直接操作 DOM，定位准确、执行快速、可控性好。

5.2 Playwright MCP 的最小配置

Playwright MCP 可以通过 npx 启动。在某些 MCP 客户端中，配置项写在 mcpServers 里，下面是一个通用示例：

json复制{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

配置文件的存放位置取决于具体客户端，可能是用户级配置，也可能是项目级 .mcp.json。配置完成后，重启客户端，模型就能看到 playwright 相关工具。

启动浏览器自动化前，可以先在本地启动待办应用作为操作目标。让 Claude 打开 http://127.0.0.1:8000/，填写待办表单并提交，再读取列表，这就是第一个完整的浏览器操作闭环。注意在使用 Playwright MCP 前要先确保 npx 可以执行，Node.js 版本满足要求。

5.3 浏览器自动化的安全边界

浏览器自动化比文本生成更容易触及权限边界，这里需要明确几条底线。自动化操作只能发生在自己有权访问的页面上，优先使用本地服务和测试环境；不要在脚本中保存生产环境明文口令；对需要登录的系统，优先使用测试账号或受控的密钥管理方案；页面操作要设置超时和重试，避免页面变化导致脚本无限等待。

注意：浏览器自动化的合规边界是“自动化自己有权手工完成的操作”。不要把自动化工具用于绕过访问控制、破解验证或匿名化访问，这类用法不符合正常开发实践。

6. 组合成业务自动化：抓取页面、生成简报、保存本地文件

6.1 选取一个可复现的场景

组合示例最简单可靠的场景是：本地有一份公告页面，自动化流程读取公告内容，调用日报生成技能输出简报，保存到本地文件。这个场景不依赖外部系统、不涉及登录，可以随时复现。

先准备本地公告页面，放在 automation/notice/index.html，内容包含几条公告即可。在 automation/notice 目录启动一个静态服务：

bash复制python -m http.server 8080 --directory automation/notice

然后通过浏览器自动化提取页面文本，再交给模型生成报告。生产环境中，这个页面可以替换成内部公告系统、监控面板或工单列表，前提是操作权限清晰。

6.2 编排脚本结构

业务自动化脚本建议按“采集、生成、落地”三个函数拆开。这样每一段都可以单独测试，也方便替换实现：

python复制import os
from pathlib import Path

from anthropic import Anthropic

client = Anthropic()

SKILL_TEXT = """
name: daily-report
description: Generate daily report.

### 今日完成
- ...
"""

def fetch_page_text(url: str) -> str:
    """Fetch page text via browser automation tool."""
    # 实际实现取决于你选择的浏览器自动化工具，
    # 可能是调用 Playwright MCP 的 extract_content，
    # 也可能是直接使用 Playwright API。
    raise NotImplementedError

def generate_report(page_text: str) -> str:
    prompt = f"{SKILL_TEXT}\n\n页面内容：\n{page_text}"
    message = client.messages.create(
        model="<当前可用的 Claude 模型 ID>",
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}],
    )
    return message.content[0].text

def save_report(report: str, output_dir: Path) -> Path:
    output_dir.mkdir(parents=True, exist_ok=True)
    path = output_dir / "daily-report.md"
    path.write_text(report, encoding="utf-8")
    return path

if __name__ == "__main__":
    text = fetch_page_text("http://127.0.0.1:8080/notice/")
    report = generate_report(text)
    path = save_report(report, Path("automation/reports"))
    print(f"report saved: {path}")

这段脚本有意保留了 fetch_page_text 的接口占位。实际项目里，可以把它实现为封装好的 Playwright 调用，也可以接入 MCP 工具返回值。循环结构应该保持“一个输入进入、一份产物出来”的方式，这样后续替换数据源时不用改动生成和保存逻辑。

6.3 预期产物

生成的 report 文件会是一个 Markdown 简报，示例如下：

markdown复制### 今日公告摘要
- 系统升级：本周六 22:00-24:00 登录服务可能中断。
- 新功能：内部报表增加导出 CSV 能力。
- 流程变更：报销审批改为两级审批。

### 术语对照
| English | 中文 | 说明 |
| --- | --- | --- |
| CSV export | 报表导出 | 逗号分隔格式文件导出 |

生产环境不能只做到这一步。脚本进入定时任务前，至少要补齐：失败重试、超时控制、日志记录、结果校验。例如报告长度小于某个阈值时就视为失败，发送告警而不是直接静默通过。

7. 验证与排错：一小时实战中最常见的四个问题

7.1 API 请求成功但 Skills 没有生效

现象：Claude 能正常返回内容，但输出格式明显不符合技能模板。

可能原因：技能目录没有被加载；提示词里没有引用 SKILL.md 正文；技能描述与用户请求关联度不够，模型判断为不需要读取。

检查方式：先手动把 SKILL.md 内容粘贴到提示词里，确认模板本身可用；再查看工具加载的目录列表，确认 skills 目录路径正确；最后检查描述是否覆盖用户可能的表述方式。

处理建议：调试阶段不要把自动加载和模板内容混在一起，先手动验证模板，再排查加载逻辑。技能描述要写得足够具体，比如“当用户要求生成日报、工作总结、每日汇报时使用”，而不是只写一个泛泛的“日报工具”。

7.2 浏览器自动化打开页面但点击不到按钮

现象：页面已经加载，但 click 操作没有产生预期结果。

可能原因：选择器过期；按钮在 iframe 或 shadow DOM 中；页面元素尚未加载完成；headless 模式下视口尺寸导致元素被遮挡。

检查方式：先截图确认页面上按钮是否存在；用 snapshot 命令查看当前可操作元素列表；检查页面是否有异步加载的等待时间。

处理建议：选择器尽量使用稳定的语义定位，不要依赖当前页面上的临时 class；操作前增加显式等待；如果按钮确实在 iframe 里，先切换 frame 再操作。调试时用 headed 模式，能看到完整过程，定位更快。

7.3 生成代码无法运行

现象：启动时出现 ModuleNotFoundError、端口占用或版本兼容错误。

可能原因：依赖没有安装完整；Python 版本和模型假设的环境不一致；生成代码里使用了不存在或过新的包 API。

检查方式：从报错第一行开始，逐一确认依赖项、版本、导入路径。例如 ModuleNotFoundError: uvicorn 说明缺依赖；Address already in use 说明端口冲突。

处理建议：小应用统一放到虚拟环境；启动前先用 pip freeze 检查关键依赖；给 Claude 的需求里写明“使用 FastAPI、只有一个 app.py、用 pip 安装 fastapi 和 uvicorn 即可运行”，能显著减少这类问题。

7.4 一小时没跑完

现象：时间都花在环境安装和反复试错上，核心链路还没跑通。

可能原因：没有先做最小连通性验证；需求描述过于宽泛；一次做太多能力。

检查方式：回到环境清单，检查 API Key、运行时版本、依赖安装是否已经确认。

处理建议：严格按照“最小闭环优先”原则：先 curl 连通 API，再运行待办应用，再加载一个 Skill，再接浏览器工具，最后才做组合。每完成一步就记录结果，这样无论在哪一步卡住都能定位到具体环境问题。

以下表格汇总了四个问题的排查要点：

8. 生产化建议、术语表与下一步方向

8.1 从一小时原型到生产自动化的差距

一小时实战跑通的是链路，不是生产。原型和生产的差距集中在四类问题：配置、日志、异常和权限。

• 配置：密钥不要硬编码在脚本里，统一使用环境变量或密钥管理服务。
• 日志：每步流程都要有结构化日志，至少记录输入来源、模型输出长度、耗时、状态。
• 异常：脚本要能区分“页面抓取失败”“模型输出为空”“文件写入失败”，分别处理。
• 权限：脚本运行账号使用最小权限，不把生产密钥给到自动化脚本随意读取。

同时，依赖版本要固定。Python 里用 requirements.txt 或 uv.lock 锁定版本，Node 工具链同样需要固定版本，避免一个月后重新运行时行为变化。

8.2 Skills 作为团队资产来维护

Skills 的价值会随维护次数增长。建议把技能目录放进版本库，命名、变更记录、评审流程都按普通代码标准管理。每个技能文件都要有使用步骤和输出模板，不要只写一个含糊的描述。

团队可以建立一组常用技能：daily-report 生成每日汇报，code-review 输出代码审查清单，bilingual-glossary 生成中英术语表，sql-analyzer 解释慢查询。这样新成员加入时不需要把规则重复解释一遍，模型和人都可以查阅同一套规范。

8.3 中英双语术语速查表

8.4 下一步实践方向

跑通这条链路后，可以往四个方向扩展：把日报生成接入定时任务，每天固定时间运行；组合多个 MCP server，让流程同时访问文件、数据库和通知服务；编写团队内部的页面巡检脚本，定时检查关键页面是否可访问；把错误日志回传给 Claude，让它根据报错自动修改脚本代码。

一个小时内完成的是验证，真正有价值的是积累：Skills 目录会越来越完整，自动化脚本会越来越稳。下一次遇到类似需求，直接复用这套链路，时间成本会明显下降。