🎯 学什么：通过浏览器自动化访问非官方 API（API/应用程序接口：让不同软件之间互相通信的"插座"） 的 Skill 设计——CDP（CDP/Chrome DevTools Protocol：Chrome 开发者工具协议，让外部程序能操控浏览器） 桥接模式 + Danger Skill 的伦理设计原则。 💡 难易度：⭐⭐⭐ | ⏱️ 预计时间：40 分钟

---

1. 课程概览

💡 白话小课堂：有些 AI 服务有网页版但没有 API——就像一家店只有门店没有外卖。CDP 桥接就是「派个机器人去门店帮你买东西」——机器人操作浏览器，打开网页输入问题，把结果抓回来给你。L1-07 教你设计这种「没有官方 API 也要用」的 Skill，以及如何在 Skill 中妥善处理合规和风险。

本课的独特定位——这是 Level 1 中唯一涉及「伦理设计」和「风险告知」的课程：

⚠️ 避坑指南：danger- 前缀不是开玩笑的——这类 Skill 用的是「非官方入口」，可能违反服务条款、可能随时被封。你必须在 Skill 里清楚告诉用户风险，并且「让用户明确同意」后才能继续。只写在 description 里不够——用户可能不看 description。

🔑 核心秘诀：认证管理用浏览器 Profile 而非存储密码——不需要存密码（消除泄露风险）、不需要管 OAuth 刷新（浏览器帮你管）、首次手动登录是自然的交互（「打开浏览器，你登录一下」）。

---

2. CDP 桥接模式详解

2.1 什么是 CDP 桥接？

CDP = Chrome DevTools Protocol。Chrome 浏览器暴露了一套协议，允许外部程序控制浏览器——打开网页、点击按钮、输入文字、读取内容。

传统 API 调用 vs CDP 桥接：

传统 API 调用：
  你的程序 → HTTP Request → API 服务器 → JSON Response → 你的程序
  路径：直接的，有文档的，有 SLA 保障的

CDP 桥接：
  你的程序 → CDP 协议 → Chrome 浏览器 → 操作网页 → 提取结果 → 你的程序
  路径：间接的，模拟人类操作浏览器的，没有 SLA 的

💡 白话小课堂：传统 API 是「打电话给客服中心」——有标准流程，有服务承诺。CDP 桥接是「派人去门店排队」——也能办成事，但可能排队、可能门店装修、可能改了规矩。

2.2 为什么需要 CDP 桥接？

场景 1：服务只有网页版没有 API。Gemini 有 Web 版（gemini.google.com），但没有对所有开发者开放 API。CDP 桥接让不开放 API 的服务也能被程序化调用。

场景 2：API 收费但网页版免费。某些服务的 API 按调用收费，但网页版免费。CDP 桥接可以利用免费通道——但这是灰色地带，必须告知用户风险。

场景 3：API 的功能不如网页版。网页版通常功能最新最全（因为是面向终端用户的），API 可能滞后。

2.3 认证管理：为什么用浏览器 Profile？

这是 CDP 桥接型 Skill 最关键的设计决策——怎么处理登录？

浏览器 Profile 的工作原理：

首次使用：
  1. Skill 打开 Chrome → 导航到 Gemini Web
  2. 用户手动登录（输入 Google 账号密码）
  3. Chrome 保存 Cookie 到 Profile 目录
  4. 关闭浏览器

后续使用：
  1. Skill 打开 Chrome → 加载同一个 Profile → Cookie 还在
  2. 直接进入已登录状态 → 无需再登录
  3. 用户完全无感

🔑 设计要点：浏览器 Profile 方案的关键是「把认证安全问题委托给浏览器本身」——存储 Cookie 的安全保障由 Chrome（Google 自己开发的浏览器）负责，你的 Skill 不碰任何密码或 token。

2.4 同意检查：为什么要 Consent Check？

CDP 桥接访问的是非官方接口——这意味着：

• 服务条款可能禁止自动化访问
• 接口可能随时变化（没有 API 版本承诺）
• 账号可能被限流或封禁

Consent Check 的设计：

每次使用前：
  1. 检查 consent.json 文件是否存在
  2. 已同意？→ 显示上次同意时间 + 风险提示 → 继续
  3. 未同意？→ ⛔ BLOCKING：展示免责声明 → AskUserQuestion
  
  AskUserQuestion:
    "Yes, I accept the risks" → 创建 consent.json，记录时间戳 → 继续
    "No, I decline" → 停止执行

🔑 设计要点：Consent Check 不是一次性的——即使同意了，每次使用仍会显示风险提示（含同意时间），让用户始终记得「这是一个非官方接口」。这是 Danger Skill 信任设计的核心：不藏风险，反复提醒。

2.5 命名规范：为什么叫 danger- 前缀？

baoyu-compress-image       ← 绿色：常规工具
baoyu-format-markdown      ← 绿色：常规工具
baoyu-danger-gemini-web    ← 红色：危险！非官方接口

danger- 前缀的作用是把风险提示「前移」到文件名：

• 用户在 Skill 列表中浏览时，第一眼就看到警告
• 与安全 Skill 并列时，视觉区分明显
• 团队管理者审核 Skill 列表时，一眼识别需要审批的

🔑 设计要点：风险提示不能只在运行时——用户可能在看到 Consent 弹窗之前就已经把 Skill 装上了、配好了、准备用了。把警告前移到名字里，让用户在每一个环节（发现→安装→配置→使用）都被提醒。

---

3. Danger Skill 的四条设计原则

从 baoyu-danger-gemini-web 提取的通用原则——适用于任何涉及非官方/逆向接口的 Skill。

什么时候用 Danger 模式？ → 当 Skill 满足以下任一条件：

• 使用非官方/逆向工程 API
• 可能违反目标服务的条款
• 稳定性依赖非公开接口（随时可能变化）
• 可能导致用户账号受限

什么时候不要用？ → 官方 API、开源工具封装、本地处理——不需要 Danger 模式。

---

4. 结构拆解：Danger CDP 桥接型模板

---

5. 电商案例：竞品淘宝店新品上架自动监控——每日抓取标题+价格+卖点

🛒 实战案例：某美妆淘宝店运营每天要跟踪5个直接竞品店铺的新品动态——上了什么新品、定价多少、标题主打什么成分、首图是什么风格。此前人工方式每天逐个店铺刷一遍，看到新品就截图存Excel，每天花1.5小时，而且经常漏掉"悄悄上架"的新品（竞品改老链接主图不通知）。

用 baoyu-danger-gemini-web CDP 桥接做自动化监控：

1. 收集5个竞品店铺的"全部宝贝"页面URL，每天自动访问
2. 设计提取prompt模板："列出本页所有商品：商品名 | 价格 | 月销量 | 标题前15字 | 是否标注'新品'标签"
3. 用CDP桥接自动化浏览器访问店铺页面，发送提取prompt，获取结构化结果
4. 对比前一天的抓取结果——新增商品自动标注"NEW"，价格变动标注"调价↑/↓"，下架商品标注"GONE"
5. 输出每日竞品快报 竞品日报/2026-05-05.md，按店铺分节，变动项高亮
6. 限速保护：每个店铺页面间隔3秒（--delay 3000），避免触发淘宝风控

效果：

• 竞品监控时间：1.5小时/天 → 8分钟/天（脚本自动跑，运营只看变动项）

• 竞品新品发现时效：从"平均滞后3天"变为"上架当天发现"

• 发现1个竞品偷偷降价30%清库存——当天调整自家同品类定价策略，避免被价格战打懵

• 3个月积累了1200+条竞品商品历史数据，可以回溯竞品价格走势和上新节奏

🔑 启示：电商竞争最怕的不是对手比你强，而是对手变了你还不知道。竞品监控从"每天刷一遍"变成"脚本自动跑+人工只看变动"，把1.5小时的体力活压缩成8分钟的决策时间。CDP桥接在没有官方店铺API的场景下是最实用的过渡方案——但如果有官方API开放，应该迁移。

---

6. 掌握检验

Q1：CDP 桥接模式和传统 API 调用模式的核心区别是什么？

• A) 传统 API 用 HTTP Request → API Server → Response；CDP 桥接用 Chrome CDP → 自动化浏览器操作 → Web 界面 → 提取结果
• B) CDP 桥接比传统 API 更快
• C) 传统 API 不需要网络连接，CDP 桥接需要
• D) CDP 桥接只能用于 Google 的服务

Q2：以下哪项不是「Danger Skill」的四条设计原则之一？

• A) 明确标注风险，用户必须知情决策（danger- 前缀 + description 警告）
• B) 要求显式同意，不能静默使用（⛔ BLOCKING Consent Check）
• C) 提供替代方案，有官方 API 优先建议
• D) 强制开源全部代码

Q3：为什么 CDP 桥接型 Skill 用浏览器 Profile 做认证管理，而不是存储密码或 OAuth Token？这种方式有哪些优点？

Q4：Consent Check 为什么设计为「每次使用都显示风险提示」而不是「同意一次后永不再提示」？这个设计解决了什么信任问题？

Q5：danger- 前缀的作用是什么？为什么只用 description 中的警告不够，还要体现在文件名里？

Q6：以下关于 CDP 桥接的适用场景，哪个说法最准确？

• A) CDP 桥接适合所有生产级场景，包括银行交易
• B) CDP 桥接适合实验、原型和低风险场景；生产级/关键业务应使用官方 API
• C) CDP 桥接只能在 Windows 上使用
• D) CDP 桥接与官方 API 功能完全一样

Q7：某跨境电商想用 CDP 桥接批量优化 2000 条产品描述。从 Consent Check 到限速保护，完整的操作流程包括哪些关键步骤？如果 Gemini 后来开放了官方 API，为什么应该迁移？

---

7. 答案

点击查看答案

Q1：A — CDP 桥接与传统 API 调用最大的区别在于通信路径。传统 API：App 直接发 HTTP Request 到 API 服务器，服务器返回 Response；CDP 桥接：App 通过 Chrome DevTools Protocol 控制浏览器，浏览器自动化操作 Web 界面（打开网页、输入内容、点按钮），再从页面中提取结果。这是一种"模拟人类操作浏览器"来间接调用服务的方式。

Q2：D — "强制开源全部代码"不是 Danger Skill 的设计原则。四条原则是：1) 风险前置（danger- 前缀让用户一眼识别）；2) 显式同意（⛔ BLOCKING Consent Check，不能静默使用）；3) 替代方案（有官方 API 时优先建议）；4) 透明运行（每次使用显示风险提示 + 同意时间）。

Q3：浏览器 Profile 保存的是浏览器的 Cookie/Session 状态而非原始凭证。优点有四：1) 不需要存储密码（消除了密码泄露风险）；2) 不需要处理 OAuth token 的刷新和过期逻辑；3) 利用浏览器原生的 Cookie/Session 管理（由浏览器保证安全性）；4) 首次使用的手动登录流程对用户来说是自然的（"打开浏览器，你登录一下"），后续自动复用（"记住我"）。本质上是把认证安全问题委托给了浏览器本身。

Q4："每次提醒"而非"一次同意永不再提示"的设计解决了三个信任问题：1) 记忆衰减——用户 3 个月前同意的风险提示早忘了，但风险依然存在；2) 状态变化——目标服务可能更新了条款、改了接口、加了反爬措施，风险比同意时更高了；3) 代理人问题——如果团队中一个人点了同意，后来的使用者也需要知道这是危险操作。每次显示风险提示 + 上次同意时间，让用户始终保持知情——这是 Danger Skill 信任设计的核心：「不藏风险，反复提醒」。

Q5：danger- 前缀的作用是让用户在"第一时间"就知道这个 Skill 存在风险——不是在使用中才发现，而是在看到名字的那一刻就知道。仅靠 description 中的警告不够，因为：1) 用户可能跳过 description 不看；2) 在 Skill 列表中浏览时，文件名是第一展示信息；3) 当多个 Skill 并列时（如 baoyu-compress-image vs baoyu-danger-gemini-web），前缀直接区分了"安全"和"危险"类别。这是"风险前移"的设计——把警告从运行时的 Consent 对话前移到了文件名。

Q6：B — CDP 桥接本质上是对非官方 Web 界面的自动化操作，不享受 API SLA 保障——服务可能随时改变 Web 界面结构、增加反自动化保护、限制访问频率，甚至关闭服务。因此只适合实验、原型和低风险场景。对于生产级业务（如支付、交易、客户交付），必须使用有 SLA 保障的官方 API。

Q7：关键步骤：1) Consent Check——首次使用时获得用户明确同意，创建 consent.json 记录时间戳；2) 数据导出——将 2000 个 SKU 的标题和描述导出为结构化 CSV；3) 标准 prompt 模板——设计统一的优化 prompt，确保处理一致性；4) CDP 桥接自动化——通过 Chrome CDP 操作 Gemini 网页版逐条发送；5) 结果写回——自动提取 AI 回复，写回 CSV；6) 限速保护——每条间隔 3 秒（--delay 3000）避免触发风控。如果 Gemini 后来开放了官方 API，应该迁移因为：API 有 SLA 保障（稳定性）、有版本承诺（不会突然变）、不会违反服务条款（合规）、不限速（可批量）——Danger Skill 是过渡方案，不是永久方案。

（6/7 通过）

---

8. 延伸阅读

• [[L1-08-推文转Markdown|下一课：推文转Markdown]] — 另一个 danger Skill，CDP 数据提取
• [[L2-11-一键发布到X|L2-11：一键发布到X]] — CDP 发布模式（同样是 CDP，方向相反：L1-07 从网页抓数据，L2-11 往网页发数据）
• [[L1-04-YouTube字幕提取|L1-04：YouTube字幕提取]] — 回顾传统 API 桥接 vs CDP 桥接的对比