← 返回作品
人机协作 / E3 / 2026.05 · v1
Browser Control Strategy
形成一套可安装的开源 Codex Skill 与 Google AI 浏览器 Hub：复用持久登录态、避免复制 Cookie，并为跨窗口控制、失败切换和 GitHub 发布保留明确路径。
Outcome first把浏览器自动化拆成发现、登录态、精确操作、本地预览和视觉兜底，让每一步使用最合适的控制通道。
下方说明问题、我的角色、关键判断、验证结果与当前限制。
Evidence snapshot / verified run
把结果放回证据链里。
这些数字来自项目文件、运行记录或可公开来源。它们说明完成到哪里，也把验证条件和没有证明的部分保留下来。
- 5 phases
- 主要控制阶段发现、身份、精确操作、本地预览与视觉兜底
- 1 hub
- 跨窗口 CDP 路径为 Google AI 场景复用同一持久登录容器
- MIT
- 开源许可证仓库与使用边界可以公开复核
PHASE 01公开研究先行先了解页面结构和官方流程，减少登录后盲目游走。
→PHASE 02明确登录态来源优先复用受控持久 Profile，并让用户完成密码与验证码。
→PHASE 03精确操作与失败切换DOM 任务交给 Playwright，本地预览交给 Browser，视觉死角才使用桌面控制。
- 01公开发现登录前先确认路径与字段
- 02身份容器持久 Profile 复用登录状态
- 03精确操作Playwright 承担 DOM 与表单任务
- 04独立兜底视觉控制不污染主路径
- Problem
- 浏览器任务经常失败，不是因为按钮不会点，而是自动化工具选错了阶段：公开研究、登录态复用、DOM 操作、本地预览和视觉兜底被迫由同一条不稳定通道承担。
- My role
- 方法设计、Skill 工程、Windows 自动化与开源发布
- Status
- 已开源 · MIT
- Evidence
- E3 · 可公开复核的真实运行证据 · 已完成公开边界检查
浏览器控制不是一个工具的问题
公开资料搜索不需要登录态，表单填写需要精确 DOM，普通 Chrome 里已有的账号状态又不应该被复制出去。把这些任务都交给一个扩展，失败只是时间问题。
先选择状态，再选择工具
这套方法先问：任务是否依赖现有登录？是否可以用受控持久 Profile？是否只是在本地预览？确认状态后，再把每一阶段交给最合适的控制通道。
安全边界也是产品体验
密码、验证码和账号批准始终由用户完成；自动化不读取、导出或迁移普通 Chrome Cookie。少做一步“聪明”的捷径，换来的是下一次任务仍然可理解、可复用、可撤回。
01
Delivered
- 将浏览器任务拆成公开发现、身份获取、精确操作、本地预览与视觉兜底阶段
- 提供可复用的 Playwright 持久 Profile 和 Google AI CDP Hub 启动脚本
- 规定 Chrome 插件、Browser、Computer Use 与 CDP 的适用边界和回退顺序
- 将 Skill、参考说明与 GitHub 发布策略按 MIT 许可证公开
02
关键判断
- 先判断任务需要哪种浏览器状态，再选择工具，而不是先打开一个随机浏览器
- 通过用户批准的持久 Profile 或 SSO 复用登录，不复制、导出或迁移正常 Chrome Cookie
- 登录、验证码、密码和安全确认由用户完成，自动化只处理普通页面动作
- 失败时切换通道并保留状态，不在同一脆弱插件上反复消耗时间
03
验证与证据
- 公开 GitHub 仓库包含完整 Skill、通道路由文档与 Hub 启动脚本
- README 给出可复现的安装方式和 CDP 连接路径
- 项目采用 MIT 许可证，并明确不读取或移植普通 Chrome Cookie
04
限制与下一步
- 网站 DOM、浏览器安全策略和插件实现会变化，路由仍需随环境复核
- 持久 Profile 被其他窗口锁定时，需要回到原窗口或连接现有 Hub
- 该方法降低失败概率，不承诺绕过验证码、登录安全或平台限制
AI 辅助说明：AI 协助形成 Skill 文档、脚本与案例文字；安全边界、工具路由、公开许可证和最终实现由 Eric 负责。