用途：这是一套与具体产品无关的通用方法论，目标是观察 Web 应用前端与后端之间的 HTTP 流量，理解其结构，并编写能复现这些请求的程序化客户端，用自动调用替代浏览器中的人工点击。它不针对任何特定产品；涉及 Google batchexecute 协议时可参考 google-batchexecute-rpc 技能（若可用）。
它不是：不用于利用安全漏洞，不用于绕过加密，不用于访问无权限的数据；对使用浏览器中不可见密钥做客户端请求签名的应用无效。明确限制包括：无法攻破 Cloudflare Bot Management、TLS 指纹识别或行为分析等反爬机制；会话 Cookie 与令牌会过期，客户端需刷新策略；应用会随时更改内部 API，私有客户端会静默失效；使用前应检查服务条款，许多产品明确禁止自动化访问。
主要流程分五个阶段。第一阶段侦察：用 Chrome 开发者工具的 Network 面板，勾选 Preserve log，过滤 Fetch/XHR，逐个执行要自动化的 UI 操作并捕获完整 URL、HTTP 方法、全部请求头（尤其是 Cookie、Authorization、Content-Type、X-* 自定义头）、请求体格式与字段、响应格式与结构，并右键 Copy as cURL 验证请求可在浏览器外运行。认证信号可能出现在 Cookie、Authorization、自定义头、请求体或 URL 参数中；CSRF 令牌应每次从页面抓取而非硬编码。DevTools 不够时可使用 mitmproxy、Postman Proxy、Burp Suite 或 Playwright。
第二阶段认证提取：识别五种常见模式——会话 Cookie、Bearer JWT、请求头 API Key、表单中的 CSRF 令牌、动态请求签名。前几种可通过 Playwright 登录后保存 storageState，或从 Local Storage/响应体提取，并处理过期刷新；动态签名最难，需在压缩 JS 中找到签名函数并复现其哈希输入，或改用 Playwright 真实浏览器拦截请求。
第三阶段请求结构分析：判断协议类型（GraphQL、Google batchexecute RPC、REST、SSE 流、WebSocket、multipart 等）及对应处理方式，逐一移除请求头测试哪些是必需的，保留最小可行请求；异步任务需同时捕获提交请求与全部轮询请求。
第四阶段构建客户端：建议统一目录结构，拆分为 auth、encoder、decoder、client、types 五个模块，处理 401/403 重新认证、429 限流退避、5xx 重试，以及响应格式变化导致的静默失败（解析前记录原始响应）。
第五阶段稳定性与维护：私有 API 会无预警失效，应建立健康检查、响应结构校验、原始响应日志和认证轮换机制。本技能不覆盖移动应用 API、Electron 应用 API、WebSocket 密集型应用、客户端请求签名应用及反爬系统。