💃 Lii's Blog

Search

SearchSearch

Recent Writing

2026-05-20记录

May 20, 202620 min read

2026-05-20 Turn Log

00:20:58 · Turn 1

原始回填

User

我让你做浏览器自动化你是怎么做的

Assistant

当前工作流：Local context recall → Hermes planning/review → Codex implementation/testing → Hermes review → Hermes memory hygiene。 按 codex-hermes workflow 执行。开始前读取本地 memory/context，结束后生成 Hermes memory candidates。 你说“让我做浏览器自动化”，我通常是这样做的： 1. 先打开目标页面 - 用 browser_navigate 到 URL - 它会返回当前页面的可交互元素 snapshot 2. 再看页面结构 - 用 browser_snapshot 看可点击/可输入的元素 - 如果页面是动态渲染、文本不够清楚，就用 browser_vision 看截图 - 需要查 DOM 或 JS 状态时，用 browser_console 3. 执行交互 - browser_click：点按钮、链接、复选框 - browser_type：往输入框里填内容 - browser_press：回车、Tab、方向键等 - browser_scroll：上下滚动 - 必要时再 snapshot 一次确认页面变化 4. 处理复杂页面 - 如果页面里有 canvas、验证码、复杂布局，我会优先用 browser_vision - 如果是表单校验、异步请求、隐藏报错，我会用 browser_console 查报错或状态 5. 验证结果 - 看页面是否真的完成了目标 - 检查控制台有没有错误 - 必要时回退、重试，或者换路径继续操作 简单说，我不是“写脚本然后盲跑”，而是边看页面边操作，像一个有反馈回路的浏览器操作者。 如果你愿意，我可以直接演示一遍： - 打开某个网站 - 登录/填表 - 抓取信息 - 点击下载 - 做一段完整的自动化流程 你把网址和目标给我，我就按这个方式做。

00:21:54 · Turn 2

原始回填

User

那你一直运行浏览器自动化不是非常消耗token吗？

Assistant

是的，浏览器自动化比纯终端/文件操作更耗 token，但不会“无限爆”。 关键在于我不会傻乎乎地全程盯着页面输出，而是尽量压缩上下文： 1. 只拿必要信息 - 优先用 browser_snapshot 的精简视图 - 只在看不懂页面时才用 browser_vision - 只在需要时才用 browser_console 查 DOM / 状态 2. 少做无意义往返 - 一次 snapshot 后，连续完成多个点击/输入 - 不每一步都重新读全页 - 只在页面变化后再刷新确认 3. 用最便宜的工具 - 如果能用 terminal / curl / API 解决，就不走浏览器 - 浏览器主要留给需要真实交互、JS 渲染、登录态、复杂 UI 的场景 4. 用“局部检查”代替“全量阅读” - 不展开整页大文本 - 不反复看同一屏内容 - 需要时直接读特定元素或控制台表达式 5. 真正耗 token 的通常不是“自动化”本身 - 而是： - 页面很乱 - 我需要反复推理下一步 - 网站状态变化频繁 - 错误多、重试多 - 也就是说，复杂网页比简单网页贵，失败重试比成功流程贵 所以结论是： - 是的，浏览器自动化比普通命令更贵 - 但如果控制好节奏，它通常是“可接受的成本” - 对于必须人工式交互的任务，它反而比你让我瞎猜更省总成本 如果你愿意，我可以给你一套“省 token 的浏览器自动化操作策略”，比如： “什么时候用 snapshot、什么时候用 vision、什么时候改用 terminal”。

00:23:11 · Turn 3

原始回填

User

那你能做浏览器自动化的项目吗。昨晚就跑脚本就行了那种

Assistant

可以，完全可以做成“昨晚挂着跑脚本就行”的那种。 我通常会把它做成这几类之一： 1. 纯脚本型 - 用 Playwright / Puppeteer / Selenium - 直接 headless 跑 - 适合：登录、点按钮、抓页面、填表、下载、监控 2. 夜间批处理型 - 写成一个可重复运行的脚本 - 用 cronjob 或后台进程夜里自动跑 - 适合：每天/每小时采集、批量检查、定时报表 3. 事件驱动型 - 页面变化、接口返回、任务完成就发消息 - 适合：盯站点、监控价格/库存/状态 我能帮你从零做到这几个层次： - 先定目标站点和流程 - 选技术栈 - 写脚本 - 加日志、重试、超时、截图 - 做夜间运行/定时运行 - 失败时自动保存证据 如果你想要的是“昨晚就能跑”的最实用版本，我建议默认这样做： - headless 浏览器 - 单脚本入口 - 本地保存日志和截图 - 失败自动退出并记录原因 - 用 cron 或后台任务夜里跑 - 结果写到文件或发消息 你只要给我这 4 个信息，我就能开始设计： - 目标网站/页面 - 要完成的动作 - 是否需要登录 - 运行频率：一次、每晚一次、还是持续监控 如果你愿意，我下一条就可以直接给你出一个“浏览器自动化项目方案”，或者直接帮你把脚本骨架搭出来。

00:33:51 · Turn 4

原始回填

User

看下这个网站https://www.zhipin.com/web/geek/jobs?ka=header-jobs为什么打开devtool就自动关闭或者是一直不停的刷新，它里面些了什么方法来检查用户打开了devTool

Assistant

我看了这个页面的源码和主 JS bundle，结论是： 它没有看到那种“经典的直接检测 DevTools 是否打开”的单一写法； 更像是一套“混淆后的 anti-debug / anti-tamper 防护”，会在你打开 DevTools、暂停脚本、展开对象、查看控制台时更容易触发。 我看到的明显点有这些： 1. 只显式关闭了 Vue Devtools - 代码里有一处： s.default.config.devtools=!1 - 这只是禁用 Vue 自带 devtools 接口，不是“检测你开没开 DevTools”。 2. 有一组很像反调试的“陷阱对象” - 给 RegExp、Date、Function、DOM 元素加了特殊 toString / getter： - reg.toString = ... - div.__defineGetter__('id', ...) - date.toString = ... - func.toString = ... - 这类代码的目的通常是：当你在控制台里查看、展开、打印这些对象时，触发副作用，从而判断有人在调试/检查。 3. 有“打印耗时/调试暂停”检测 - 代码里有： - performance.now() - 大对象数组打印耗时对比 - 某些计时函数 N() 的前后差值判断是否超过阈值 - 这类逻辑常用来判断： - 脚本是不是被断点暂停过 - 控制台展开对象是不是很慢 - 运行环境是不是被干预了 4. 有定时巡检 - 代码里有一个 500ms 周期在跑的检测循环 - 还有 5s 的 stop / cleanup 逻辑 - 这说明它不是一次性检查，而是持续巡检状态变化 5. 有控制台/弹窗/全局状态相关的钩子 - 它会 hook alert / confirm / prompt - 还有一些 window 上的全局检查函数 - 这通常是为了探测“有人在人工交互 / 调试 / 篡改运行环境” 6. 还有一些浏览器指纹类判断 - 例如 screenTop - screenY 这种写法更像是在识别某些浏览器族或窗口状态 - 这不一定是 DevTools 检测，但属于同一类“环境识别” 所以更准确地说： - 它大概率不是“检测到 DevTools 打开就直接跳一个 if” - 而是通过一套混淆的 anti-debug 逻辑，检测： - 控制台是否在看对象 - 脚本是否被暂停 - 运行环境是否异常 - 是否有自动化/篡改痕迹 - 一旦命中，页面可能表现为： - 自动刷新 - 空白 - 重定向 - 反复重载 - 某些内容加载不出来 我这边实际打开这个 URL 时，浏览器里也是空白页，这和它的反爬/反调试策略是吻合的。 如果你要，我下一步可以继续帮你做两件事之一： 1. 把这段混淆的 anti-debug 逻辑整理成可读伪代码 2. 继续定位它到底是哪一段触发了“刷新/关闭 DevTools”的表现 如果你愿意，我就继续往下拆。

00:34:29 · Turn 5

原始回填

User

Review the conversation above and update the skill library. Be ACTIVE — most sessions produce at least one skill update, even if small. A pass that does nothing is a missed learning opportunity, not a neutral outcome. Target shape of the library: CLASS-LEVEL skills, each with a rich SKILL.md and a references/ directory for session-specific detail. Not a long flat list of narrow one-session-one-skill entries. This shapes HOW you update, not WHETHER you update. Signals to look for (any one of these warrants action): • User corrected your style, tone, format, legibility, or verbosity. Frustration signals like ‘stop doing X’, ‘this is too verbose’, ‘don’t format like this’, ‘why are you explaining’, ‘just give me the answer’, ‘you always do Y and I hate it’, or an explicit ‘remember this’ are FIRST-CLASS skill signals, not just memory signals. Update the relevant skill(s) to embed the preference so the next session starts already knowing. • User corrected your workflow, approach, or sequence of steps. Encode the correction as a pitfall or explicit step in the skill that governs that class of task.

Assistant

已更新 skill library。 新增的类级 umbrella skill： - /Users/ai/.hermes/skills/software-development/browser-automation/SKILL.md 新增支持文件： - /Users/ai/.hermes/skills/software-development/browser-automation/references/anti-debug-patterns.md 这次补进去的重点有： - 浏览器自动化项目的省 token 工作法：优先 terminal/API，其次 browser_snapshot / browser_console，最后才 browser_vision - 夜间/持续跑脚本的项目形态：headless + 日志 + 截图 + 超时/重试 + 可验证退出码 - 识别 DevTools/anti-debug 的常见模式： - getter / toString 陷阱 - performance.now / Date 的时序探测 - viewport / screen geometry 检查 - alert/confirm/prompt hook - 定时轮询、样式注入、重定向/刷新 - 明确区分“禁用 Vue devtools”和“反调试逻辑”，避免误判 顺手说明一下 overlap： - 这个新 skill 和 systematic-debugging、node-inspect-debugger 有重叠 - 但我保留 browser-automation 作为上层 umbrella，因为它管的是“浏览器自动化怎么做、怎么省 token、怎么查反调试” 如果你要，我下一步可以继续把它拆成更实用的子参考文件，比如： - references/headless-project-template.md - scripts/smoke-browser-probe.py

00:35:30 · Turn 6

  • Session: 20260520_002026_9ddc94
  • Summary: 分析BOSS直聘的反自动化技术栈：Vue devtools禁用、陷阱对象（RegExp/Date/Function toString覆盖）、性能计时检测、定时巡检、控制台钩子、浏览器指纹screenTop-screenY等，属混合型anti-debug防护体系而非单一检测手段。
  • Important: yes
  • Action needed: no
  • Session hub: 20260520_002026_9ddc94
  • Entry: 2026-05-20_003530_20260520_002026_9ddc94_turn-6

原始回填

User

那这种网站做自动化脚步是不是非常困难

Assistant

是的，这类网站做自动化脚本通常会“明显更难”，而且难点不在“写个点击脚本”，而在“长期稳定跑”。 主要困难一般有这几类： 1. 反自动化 / 反调试 - 你刚看到的这种 DevTools 检测、debugger 陷阱、对象 getter、副作用检测，都会让脚本更容易触发异常 - 结果可能是空白、刷新、重定向、内容缺失 2. 指纹识别 - 会看浏览器特征、窗口特征、插件/环境、canvas、WebGL、时区、字体等 - headless、无痕、虚拟化环境更容易被识别 3. 登录态和风控 - 登录、验证码、滑块、短信验证、频率限制 - 即使脚本能跑，跑一段时间后也可能失效 4. 页面结构经常变 - SPA、异步加载、动态 class、虚拟列表 - 你写死的 selector 很容易坏 5. 不是每一步都能被“机器化” - 有些页面设计目标就是阻止自动化批量抓取 - 这时候脚本不是“不够聪明”，而是“对方不想让你自动化” 所以结论是： - “能不能做”：能 - “难不难”：比普通网站难很多 - “能不能稳定夜间跑”：有时可以，但要看目标和风控强度 - “是否值得”：如果有官方 API、数据导出、站内通知、RSS、开放接口，通常比硬爬更稳 如果你只是做个人/内部用途，比较靠谱的路线通常是： - 优先找官方接口或页面数据源 - 尽量用正常浏览器上下文，不要 headless 优先 - 保持低频率、少并发 - 关键步骤允许人工介入 - 失败时保存截图和日志，方便定位 如果你想，我可以进一步帮你判断： 1. 这个站适不适合自动化 2. 适合用哪种方案：Playwright、请求直抓、还是半自动人工辅助 3. 怎么设计成“夜里跑，失败能留证据”的脚本结构 你要的话，我可以直接给你一个“高对抗网站自动化可行性评估清单”。

00:36:22 · Turn 7

原始回填

User

Playwright做自动化的原理是什么？

Assistant

Playwright 的核心原理可以理解成： 它不是“模拟鼠标键盘乱点”，而是“通过浏览器自动化协议，直接指挥浏览器内部对象”。 简单拆开说： 1. 它先启动一个真实浏览器 - 可以是 Chromium、Firefox、WebKit - headless 或有界面都可以 - 浏览器仍然是真浏览器，不是纯解析器 2. 它和浏览器建立控制通道 - 对 Chromium，主要走 CDP（Chrome DevTools Protocol） - 对 Firefox/WebKit，走各自的自动化协议 - 本质是一个进程间通信通道，通常是 WebSocket/pipe 一类 3. 它控制的是“页面对象” Playwright 直接操作： - Browser - BrowserContext - Page - Frame - Element/Locator 所以你写的： - click() - fill() - press() - goto() - waitForResponse() 其实是在调用浏览器内部能力，不是纯前台 UI 自动点按。 4. 它会自动等待 这是 Playwright 很强的地方。 比如你点一个按钮时，它不会只做“单击动作”： - 先等元素可见 - 等可点击 - 等不被遮挡 - 等页面稳定一点 - 之后再执行 这就是为什么它通常比“自己 sleep+点击”的脚本稳定。 5. 它会注入脚本帮助读取页面状态 Playwright 可以在页面上下文里执行 JS： - 读 DOM - 读 localStorage / sessionStorage - 读 cookie - 监听网络请求 - 拦截响应 - 处理 iframe、shadow DOM 6. 它还能控制网络层 比如： - 拦截请求 - 改 header - mock 接口 - 阻止图片/CSS 加载 - 记录 API 返回 所以 Playwright 不是单纯“UI 自动化工具”，而是“浏览器级自动化平台”。 一句话总结： Playwright = 启动真实浏览器 + 通过自动化协议控制浏览器内部状态 + 自动等待 + DOM/网络/页面级操作。 如果你愿意，我还可以继续给你讲两件更实用的： - Playwright 和 Selenium 的原理差别 - 为什么高对抗网站会识别 Playwright/headless

Graph View

Backlinks

  • No backlinks found