Claude一小时实战：从Excel小应用到Skills与MCP自动化链路

如果把“Claude 一小时实战”当作一句营销话术，那它不值得写一篇文章。但如果把它理解为一套真实的工作方式——用 Claude 生成小应用、用 Skills 沉淀重复流程、用 MCP 和浏览器操作打通外部系统——那这一小时的含义就完全不同了：它不是在“写代码”，而是在“组装一套可运行的自动化链路”。

过去我们做一个小工具，时间大多耗在哪里？耗在环境配置、接口调试、页面元素定位、格式清洗。代码本身反而是最快的一部分。Claude 真正改变的不是“代码生成速度”，而是把整个链条上的摩擦点逐步去掉：它不仅能写代码，还能通过 Skills 复用你沉淀的流程，通过 MCP 操作文件、浏览器、数据库和业务系统。这样一来，一个规则明确的小需求，确实有可能在一小时内从想法变成可运行的产物。

这篇文章会从概念讲起，然后分别用三个实战场景演示：用 Claude 做一个 Excel 统计小应用、把常用流程封装成 Skills、通过 MCP 让 Claude 操作浏览器完成网页表单填报。最后会给出业务自动化的串联思路、常见问题排查和工程建议。

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

先说判断：Claude 这类模型加工具链之后，真正降低的不是“写代码”的门槛，而是“把一个需求跑通”的门槛。

很多开发者已经在用 AI 写代码了，但大多数用法还停留在“复制粘贴代码片段”的阶段：问模型要一段 Python 脚本，拿回来自己调，然后手动运行、手动找 bug、手动把结果喂给下一步。这当然也能省时间，可省得很有限。真正高效的用法，是把模型放进一个 Agent 循环里：它接收到任务，自己拆解，自己调用工具，自己读取运行结果，发现问题再修正，最后产出中间结果或最终产物。

这套循环里，有三件事是关键：一是模型能不能生成可运行的代码，二是它能不能复用你之前总结好的流程和约束，三是它有没有权限和能力去操作真实的外部环境。对应到 Claude 的能力体系里，就是三个关键词：

• 小应用（Mini App / 单文件脚本）：模型直接产出可运行的 Python、JavaScript 小工具。
• Skills（技能包）：把提示词、脚本、约束打包成可复用模块，让模型下次“自动学会”怎么做这一类的活。
• 浏览器操作（Browser Automation / Computer Use）：通过 MCP 工具或视觉操作，让模型完成网页点击、输入、提取信息等真实业务动作。

谁最应该读这篇文章？三类人：第一，天天在处理 Excel、网页填报、数据整理这类重复工作的办公自动化需求方；第二，想把 AI 从“聊天工具”升级成“业务助手”的开发者；第三，正在做团队内部效率工具、想给同事交付“可复用自动化”的人。

也需要说清楚边界。一小时内能跑通的，是规则明确、输入输出边界清晰的场景，比如报表汇总、格式转换、表单预填、状态查询。一旦涉及多系统强耦合、复杂审批流、历史数据迁移，一小时远远不够。这也是本文最重要的预期管理：Claude 放大的是执行力，不是需求分析能力。

2. Claude、Skills、MCP、浏览器操作：核心概念与适用场景

2.1 Claude 与 Agent 循环

Claude 是 Anthropic 推出的大语言模型系列。日常使用中大家习惯叫它“ChatGPT 的竞品”，但在开发场景里，更准确的理解是：它是一个可以承担多步骤任务的 Agent 底座。

所谓 Agent，不只是一问一答。它更像一个实习生：你给它一个目标，它自己规划步骤，调用工具执行，看结果，如果不对就换一种方式再来。Claude Code 就是这个思路的最佳体现——在终端里，它能读文件、改代码、运行命令、看运行日志，然后继续修。

2.2 Skills：把流程变成“可调用技能”

英文名为 Skills，中文通常译为“技能包”。如果你写过代码，可以把它类比成“函数封装”：把一段固定流程连同输入输出规范、注意事项、参考脚本，封装成一个可重复调用的模块。

为什么需要 Skills？因为同样一群操作，你不可能每次都用自然语言重新描述一遍。比如“做 Excel 汇总报告”这个需求，第一次你用了一大段提示词才让模型理解你要什么；第二次换一个人来提需求，又要从头解释。有了 Skills，你只需说“按 excel_report 技能处理 records.xlsx”，模型就会自动加载技能里的步骤和经验。

从实现上看，一个 Skill 通常是一个目录，里面包含一个描述文件（比如 SKILL.md）和可选的脚本。描述文件里记录了这个技能什么时候该用、操作步骤是什么、有哪些坑要避开。这个结构并不只属于 Claude，社区里的 Agent 框架普遍在向类似规范靠拢。对使用者来说，逻辑非常直观：技能名负责触发，描述文件负责引导行为。

2.3 MCP：模型连接外部世界的标准接口

MCP 全称 Model Context Protocol，即“模型上下文协议”。它是 Anthropic 开源的一套标准化协议，解决的是“模型如何调用外部工具和数据源”的问题。

如果没有 MCP，你要让 AI 读数据库、操作浏览器、读写文件，就得为每种场景单独做一套接口适配。有了 MCP，外部工具只需要实现一次通用协议，所有支持 MCP 的 AI 客户端都能调用。打个比方：MCP 相当于电脑上的 USB 接口，键盘、鼠标、U 盘、显示器各有各的功能，但都通过同一个接口连上电脑。在 Claude 的产品体系里，MCP 是扩展模型能力最核心的通道。

2.4 浏览器操作：DOM 级与视觉级的区别

Claude 操作浏览器有两条技术路线，很多人会混淆。

第一条是 DOM 级自动化，典型工具是 Playwright MCP。模型不直接“看”页面，而是通过 Playwright 工具读取页面的 DOM 结构，然后执行点击、输入、选择等操作。它的优势是速度快、定位准确、适合表单和结构化页面；劣势是需要浏览器环境配合，遇到复杂验证码或反自动化机制时会受限。

第二条是视觉级操作，即 Computer Use。模型像人一样看屏幕截图，移动鼠标指针，点击图标，输入文字。它的优势是几乎能操作任何软件，不限于网页；劣势是速度慢、成本高、稳定性不如 DOM 方案，更适合在隔离环境里做探索性操作。官方在发布这类能力时，也强调需要隔离环境与人工监督。

两条路线不是替代关系。对绝大多数业务自动化场景，DOM 级方案是首选；遇到需要操作桌面软件的边缘场景，再考虑视觉级方案。

3. 任务选型：哪些场景真的能在一小时落地

很多人一上来就问“能不能让 Claude 自动化我所有的工作”，这个问题本身就是错的。AI 自动化最重要的能力，不是“什么都能做”，而是“判断什么不该做”。一小时实战的前提，是选对任务。

适合的任务通常有三个特征：

• 规则明确：输入是什么、输出是什么、中间逻辑是什么，都能写清楚。
• 风险可控：操作产生的结果可以回滚，不影响生产数据，不外发不可控信息。
• 闭环可验证：跑完之后有明确的结果文件、页面状态或日志，可以判断成功还是失败。

反过来，下面这几类任务不建议一开始就尝试：

• 直接改生产数据库或线上配置，尤其是没有备份和回滚步骤的操作。
• 需要在网页上执行资金交易、发送对外邮件、提交正式审批等敏感动作。
• 涉及公司保密数据，但公司政策不允许把这些数据传给外部大模型 API。
• 需要长期无人值守运行，但目前没有日志、告警和人工接管机制的场景。

选型想做对，建议用一种“半小时原则”来判断：如果任务描述可以在半小时内由人讲清楚，说明规则足够明确，适合自动化；如果讲了半天还是各种例外情况，那就先别自动化，先把流程标准化再说。这个原则在后面的实战里会反复用到。

4. 环境准备与前置条件

在动手之前，先把环境确认好。下面这些准备围绕两条主线：一条是跑 Python 小应用，另一条是给 Claude 接入浏览器操作能力。版本信息建议以你实际使用的官方文档为准，文章里的命令给出的是通用思路。

4.1 账号与 API Key

• 一个可用的 Claude 账号，以及 API 访问权限。
• 准备好 API Key，建议通过环境变量 ANTHROPIC_API_KEY 注入，而不是硬编码在代码里。
• 如果只是体验对话和生成代码，用官方客户端的对话框即可；如果要做文件读取、浏览器操作，优先使用支持 Agent 循环和 MCP 的客户端环境。

4.2 Python 环境

• Python 3.10 及以上版本。
• 安装 pandas 和 openpyxl，用于处理 Excel 文件。

bash复制pip install pandas openpyxl

4.3 Node 环境与 Playwright MCP

Playwright MCP 是一个把浏览器控制能力封装成 MCP 工具的服务器，依赖 Node.js 环境。

bash复制# 检查 Node 版本，建议 18 及以上
node -v

# 安装 Playwright 的 Chromium 内核（如果后续提示浏览器缺失）
npx playwright install chromium

有了这些基础环境，后面三个实战就可以直接操作了。

5. 实战一：用 Claude 一小时做一个 Excel 统计小应用

第一个实战用一个最常见的办公场景：把一周的工时/加班记录 Excel 表，按员工和类型汇总成一张报告表。这件事手动做要打开 Excel、拉透视表、调格式，重复十几次之后就会萌生“写个脚本”的念头。

我把任务描述成一个提示词，发给 Claude：

请写一个 Python 脚本，读取同目录下的 records.xlsx，表格包含“员工姓名”“日期”“工时”“类型”四列。请按“员工姓名 + 类型”分组汇总工时，结果保存为 summary.xlsx。要求：用 pandas，空值按 0 处理，输出前打印前 10 行汇总结果，不要连接数据库。

模型给出的核心代码可以整合成下面这样：

python复制# 文件路径：report.py
import pandas as pd

def load_records(path: str) -> pd.DataFrame:
    df = pd.read_excel(path)
    required = ["员工姓名", "日期", "工时", "类型"]
    missing = [col for col in required if col not in df.columns]
    if missing:
        raise ValueError(f"Excel 缺少必要列: {missing}")
    df["工时"] = df["工时"].fillna(0)
    return df

def generate_summary(df: pd.DataFrame, output_path: str) -> pd.DataFrame:
    summary = df.groupby(["员工姓名", "类型"], as_index=False)["工时"].sum()
    summary = summary.sort_values(["员工姓名", "类型"])
    summary.to_excel(output_path, index=False)
    return summary

if __name__ == "__main__":
    records = load_records("records.xlsx")
    result = generate_summary(records, "summary.xlsx")
    print(result.head(10))
    print(f"已生成汇总文件: summary.xlsx")

这段代码本身没有什么复杂逻辑，但它是 Claude 自动化能力的最小闭环：读入数据、检查列名、处理空值、分组汇总、输出文件、打印验证信息。

运行方式：

bash复制python report.py

预期效果是：终端打印前 10 行汇总记录，同时当前目录多出一个 summary.xlsx，打开后能看到按员工和类型拆分的工时合计。

这里要特别说明一个容易忽略的点：让模型“自动生成代码”不难，难的是让它理解文件路径、列名和生产环境之间的差异。所以提示词里一定要写清楚“输入文件具体在哪里、有哪些列、输出到哪里”。信息越具体，生成结果越接近直接可用。

做完这一步，你已经拥有一个可以用半个多小时搞定的小应用了。下一步的关键问题是：这个流程能不能复用？这就引出 Skills。

6. 实战二：把重复流程沉淀成 Skills

假设你已经让 Claude 生成了一次 Excel 汇总脚本。下周同事跑来求你：“帮我也汇总一下这个月的记录。”你打算怎么办？重新让 Claude 生成一遍脚本？那太浪费了。更好的做法是把刚才的流程、约束和脚本一起封装成一个 Skill，让 Claude 以后遇到同类需求时自动调用。

一个 Skill 推荐的组织方式如下：

code复制.claude/skills/
└── excel-report-skill/
    ├── SKILL.md
    └── scripts/
        └── make_report.py

在这个目录里，SKILL.md 是技能的核心描述文件。它用 Markdown 格式编写，头部包含技能的元信息，正文包含操作步骤和注意事项。下面是一个可用的示例：

markdown复制---
name: excel_report
description: 根据原始工时 Excel 表生成按员工和类型汇总的报告。当用户要求做工时统计、加班汇总、类型汇总、Excel 分组求和时使用。
---

# Excel 报告生成技能

## 适用条件
- 输入文件为 .xlsx，包含列：员工姓名、日期、工时、类型。
- 输出目标：按员工 + 类型汇总工时，结果保存为新的 .xlsx 文件。

## 操作步骤
1. 读取 Excel 文件，先校验必要列是否存在。
2. 将“工时”列的空值填充为 0。
3. 按“员工姓名”和“类型”分组求和。
4. 输出汇总文件，并打印前 10 行便于快速验证。

## 注意事项
- 不要修改原始文件，只输出新的汇总文件。
- 输出文件使用 UTF-8 编码，列名保持中文不变。
- 如果原始文件列名不一致，先向用户确认映射关系，不要自行猜测。

这个文件的头部字段很关键：name 是技能名，description 是触发说明。Claude 在收到用户请求后，会根据描述判断是否需要加载该技能。如果一个技能的 description 写得太泛，模型可能该触发时不触发；写得太窄，又可能在相关场景下用不上。好的做法是把“用户可能怎么说”写进描述里，比如上面例子里列举了“工时统计、加班汇总、类型汇总”这些近义表达。

把脚本放到 scripts 目录后，你在对话里可以直接说：

请用 excel_report 技能处理 records.xlsx，输出今天的汇总报告。

Claude 会加载技能描述，按照里面的步骤执行，以提高结果的一致性。相比每次重新描述一遍需求，这个模式把“个人经验”变成了“团队可复用的标准操作流程”。新同事接手时，不需要看他人的聊天记录，只需要看一眼技能目录和说明文件，就知道这一类活应该怎么干。

需要说明的是，不同客户端对 Skill 的管理入口不完全一致：有些提供可视化技能管理界面，有些使用 .claude/skills/ 目录。具体入口以你使用的版本和官方文档为准，但“技能目录 + 描述文件 + 脚本”的组织思路是通用的。

7. 实战三：通过 MCP 让 Claude 操作浏览器

第三类高阶用法是浏览器操作。这里不讨论“让 AI 随便替你在网上做任何事”，而是限定在你有权访问、并且操作结果可验证的业务场景，比如内部 OA 系统的表单填报、测试环境里的页面回归、公开页面信息提取。

7.1 接入 Playwright MCP

最稳妥的路线是使用 Playwright MCP 服务器。安装好 Node 环境后，在 Claude 客户端的 MCP 配置里增加一项：

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

不同客户端的配置入口不一样：有的在设置里的 MCP 服务器页面，有的在配置文件里写上面的 JSON。添加完成后，重启客户端，让 MCP 工具生效。

7.2 模型如何通过 MCP 操作浏览器

配置好之后，Claude 不再只是一个“文字对话模型”，它拥有了浏览器工具调用能力。当你给出任务时，模型会调用 MCP 工具打开页面、等待页面加载、获取页面快照、定位元素，然后执行点击和输入。

一个典型对话任务是这样的：

打开 https://example.com/login，在“用户名”输入框填入 test_user，在“密码”输入框填入 test_pwd，点击“登录”按钮。登录成功后进入首页，把页面上第一条待办事项标题告诉我。

执行过程中，模型可能会先后调用多个浏览器工具：打开页面、读取页面文本、定位输入框、填入内容、点击按钮、等待跳转、读取结果。这就是 Agent 循环在真实场景里的样子：每一步都基于上一步的页面反馈决定下一步动作。

7.3 生产环境使用的边界

浏览器自动化的风险边界，比代码生成要敏感得多。这里给三条硬性原则：

• 优先在测试环境、临时环境中运行，避免直接在核心生产页面上做未验证的写操作。
• 不要在对话中明文提交高权限账号密码。如果是测试账号且场景需要，用后及时收回权限。
• 遇到验证码、短信校验、异常弹窗，立即停下来，交给人工处理，不应当让脚本尝试绕过安全验证。

为什么这么强调？因为浏览器自动化一旦出错，后果可能是误提交、数据错乱或账号异常，这类代价远高于“代码跑了几次失败”的成本。自动化提升的是效率，而不是安全意识。

8. 业务自动化综合场景：把三个能力串起来

如果只看单个实战，你可能会觉得每一块都不难。但 Cl包的动力，在于把三个能力串联成一个完整业务链路。

假设一个流程是这样的：每个月末收集几十个员工的工时记录，需要清洗数据，汇总成报告，再把结果填入 OA 系统中的月度报表页面。

这个链路的关键设计，是每个步骤的输出都是一份独立文件或可验证的状态。Excel 汇总结果是文件，浏览器操作的结果是页面截图。这样做的好处有两个：第一，任何一步失败都能定位到具体环节，不会一团黑盒；第二，中间产物保留下来，方便事后审计和重新执行。

从实现角度看，你可以先跑步骤 1 和 2，确认 summary.xlsx 正确后，再让 Claude 用浏览器工具打开 OA 页面，并明确告诉它：“在我们确认汇总数据无误之前，只填写表单，不要点击提交。”这里用到的核心技巧，是把操作拆成“预填”和“提交”两个动作，中间插入人工确认点。

这条链路跑通之后，后续的月度汇总就不需要重复搭架子了。这也是为什么前面要花时间做 Skills：第一次跑通的流程，固化下来，下次直接调用。

9. 常见问题与排查方法

实战过程中，最常遇到的不是模型能力不足，而是环境、配置和上下文带来的各种小坑。下面这张排查表覆盖了几个高频问题：

这些问题的排查思路有一个共同点：先确认“环境通不通”，再确认“配置对不对”，最后才怀疑“模型理解错了”。顺序反了，很容易陷入无意义的重复尝试。

10. 最佳实践与工程建议

把 Claude 用到真实业务里，有几条工程经验值得提前建立，它们能避免你在后期踩大坑。

第一，明确输入输出边界。每次让 Claude 处理任务时，都要把输入文件路径、数据字段、输出位置写明白。不要让它自由决定“数据从哪里来、到哪里去”。中间文件是最好的状态容器，比对话上下文可靠得多。

第二，Skill 的粒度要适中。一个技能只做一件事，比如“生成 Excel 汇总报告”，而不要做一个“全公司流程自动化”的巨型技能。技能太大，触发逻辑会变复杂，维护成本也高。技能描述里一定要包含常见的用户表达方式，这是它能被正确触发的关键。

第三，任何写操作都要有回滚方案。尤其是浏览器操作里涉及提交表单、发送消息、更新数据时，尽量先让 Claude 跑“只读”步骤，确认无误后再放行写操作。生产环境的数据变更，应当在变更前备份，并在变更后记录前后状态。

第四，敏感数据不进入提示词。模型会读取你传入的数据内容。不要在生产环境把数据库账号、私钥、身份证号等敏感信息直接贴在提示词中。用测试账号、脱敏数据做验证，是成本最低的安全措施。

第五，日志和人工确认点必须保留。自动化练的不是“一把梭”，而是“可控地推进”。每完成一个关键步骤，都让 Claude 输出结果摘要或截图；涉及高风险动作时，加入人工确认点。这样即使出现问题，也能快速定位是哪个环节出了错，而不是推倒重来。

第六，用“运行后验证”替代“生成后信任”。模型生成的代码和操作，默认都是“候选版本”，必须通过运行结果来验证。你不需要逐行审查所有代码，但一定要验证每个关键节点的输出是否符合预期。

11. 中英双语句式速查表

这个实战过程虽然是在中文环境下操作，但不少提示词模板、工具名称和报错信息都是英文的。下面是几个高频场景的中英对照句式，方便你在不同环境之间切换：

这两组句式本质上是一样的，只是表现形式不同。在实际工作中，模型对中文指令的理解已经足够好，英文句式更常用于写提示词模板、记录 Skill 描述和团队协作文档，方便跨国团队共享。

12. 总结与下一步行动

把三个实战放在一起看，你会发现它们之间有一条清晰的递进关系：小应用解决“单个任务怎么完成”，Skills 解决“同类任务怎么复用”，浏览器操作解决“怎么跟外部系统交互”。三者组合起来，才是完整的业务自动化能力。

真正有价值的地方不在任何一个单点，而在“复用”和“串联”。今天你让 Claude 写出一个 Excel 统计脚本，是一个单点成果；一周后你把它固化成 Skill，让同事也能调用，就是一个小型自动化资产；再过一个月，你把它接上网页表单填报，就变成了一条能持续运行的业务流程。

下一步建议很具体：不要急着做复杂的跨系统集成，先挑一个你每周都在重复、规则又清楚的小任务，按文章里的流程走一遍。先让 Claude 生成代码，跑通结果；再把它封装成 Skill；最后如果有网页操作需求，接上 Playwright MCP，在一个测试页面里验证完整链路。一小时的目的，不是让你完成所有自动化，而是让你完成第一个可复用的自动化。把这篇文章收藏起来当起点，真正动手跑一次，比看十篇教程都有用。