章节 22 / 29 · 课程总览 · 起始 1:53:35

章节主旨

演示让 Claude Code 用 HTTP 请求 直接调用第三方 API(以 cal.com 预约为例)来完成网页动作,而非模拟浏览器点击;并诚实展示这类临时方案的脆弱与耗时。

核心论点

  1. 很多”点按钮”式的网页操作,本质可绕过 UI 直接用 HTTP 请求打 API 完成,不必真去自动化点击。(→ 详解1)
  2. 为单一具体问题临时拼的方案,能跑通但脆弱——只对特定页面有效、来回试错、耗时长。(→ 详解2)

知识点详解

1. 用 HTTP 请求替代模拟点击 1:53:43

是什么:想在网页上”往前走一步”(如约会议)通常要点按钮、填表单,这背后往往是 JavaScript,单纯的 HTTP 请求难以直接触发点击。

为什么:很多站点(如 cal.com)其实提供 API,预约动作本身可以不经 UI、直接发 HTTP 请求完成。Nick 只给一句”帮我约明天下午 3:30,名字 test、邮箱……“,Agent 就自己去找 API 文档、查可约时段、再发起预约。

怎么用:让 Agent 先抽取页面上的 cal.com 链接、在 Chrome 打开确认,再据 API 文档拼请求。核心心智是:能打 API 就别去自动化点击 1:54:24

2. 一次性方案的脆弱与取舍 1:55:03

是什么:Nick 明说自己”是在为一个非常具体的问题造一个非常具体的解”——这类 一次性方案不是通用能力。

为什么:并非人人都用 cal.com,每换一个站点就得重新摸清它的 schema 与请求格式;实际跑起来来回试错、坐等十几分钟,最后才勉强约上 1:55:26

怎么用:把它当探针而非生产管道——验证”HTTP 直连 API 可行”即可;真要复用,得为目标站点固化 schema,并接受它只对特定页面有效。

术语

  • HTTP request(HTTP 请求,不经浏览器 UI 直接与服务端通信的方式)
  • API documentation(API 文档,Agent 据此推断可用端点、参数与可约时段)
  • fragile solution(脆弱方案,只对特定输入/页面成立、易随环境变化失效的临时解)

自检问题

  1. 为什么”点网页按钮约会议”往往可以改用 HTTP 请求完成? 答案:因为该动作背后常有可调用的 API,预约本身能不经 UI 直接发请求完成;Agent 会先找 API 文档、查可约时段再发起预约。见详解1 1:53:43
  2. 这个 cal.com 预约方案有哪些局限,该如何定位它? 答案:它是为单一问题拼的一次性方案,只对特定 cal.com 页面有效、需逐站摸清 schema、来回试错且耗时十几分钟;应把它当可行性探针而非通用生产管道。见详解2 1:55:03