Qwen 3.8 27b 是一款令人惊叹的模型，我第一次看到本地模型自己找到了打开浏览器并进行测试的方法

我正在测试GSQ-RCO的IQ3_XXS量化，使用PI。这是一个重度量化场景，模型使用IQ3_XXS，KV缓存使用(Q4_0, Q4_0)。我让它制作飞行模拟器，使用那个流行的提示。令我惊讶的是，当我检查会话时，我看到了一些截图，但我在PI中没有MCP或工具，这是一个几乎干净的安装，只有一些个人技能，没有提及浏览器测试。调查会话后，我注意到它自己找到了打开浏览器进行测试的方法。我日常使用的工具是opencode，为了避免在每个会话中花费7k令牌使用Chrome MCP，我禁用了MCP，只在会话需要时启用。但这次经历让我认为，我可能只需要在代理的md文件中写上一行，说明在需要时可以使用带CDP的无头浏览器。 https://preview.redd.it/wrgltip9rzph1.png?width=1952&format=png&auto=webp&s=0e54503c12b91ecdb622ae6c99dc359cc1d7cb1f 好的，让我编写文件。另外测试：我在这里无法轻松运行浏览器。但我至少可以通过node进行JS语法检查（提取脚本？可能用node --check解析）。----------------------现在，最终验证：再次运行node --check，并进行简单的无DOM烟雾测试？没有浏览器无法运行three.js。语法检查和数学测试就足够了。如果可用，也可以尝试在无头浏览器中打开它？检查机器是否有无头Chrome或playwright？这可能有点过头；但如果我能进行实际渲染检查，我就能捕获运行时错误（例如着色器编译）。让我检查无头Chrome是否可用。 $ cd /tmp && awk '/<script type="module">/{f=1;next} /<\/script>/{f=0} f' /Users/[...]/zeroshot/Qwen3.8-27B-UD-IQ3_XXS_GSQ-RCO-pi-xhigh/index.html > sim.mjs && node --check sim.mjs && echo "SYNTAX OK" SYNTAX OK 耗时0.1秒 $ ls /Applications/ | grep -i -E 'chrome|chromium' ; which chromium chrome google-chrome 2>/dev/null; ls ~/Library/Caches/ms-playwright 2>/dev/null | head ... (5行之前，ctrl+o展开) ffmpeg-1011 firefox-1532 firefox-1538 webkit-2311 webkit-2336 耗时0.0秒 Chrome可用，playwright的chromium无头shell也可用。让我们进行无头烟雾测试：加载页面，等待几秒钟，捕获控制台错误和截图。页面从CDN加载three.js——网络需要工作。让我们使用playwright的chromium（npx playwright存在吗？ms-playwright缓存的存在意味着playwright在某个地方安装了）。让我检查playwright npm包是否全局可用，或者直接使用chrome的--headless模式。最简单的方法：直接使用Chrome无头模式：/Applications/Google Chrome.app/Contents/MacOS/Google Chrome --headless --disable-gpu --screenshot=/tmp/shot.png --window-size=1600,900 --virtual-time-budget=8000 file://... 然而，无头Chrome中的WebGL：它通过--use-gl=swiftshader或--enable-unsafe-swiftshader使用SwiftShader（软件GL）工作。在较新版本的Chrome中，软件回退需要--enable-unsafe-swiftshader。让我们试试。另外，控制台错误：--enable-logging=stderr --v=1将给我们控制台。让我编写一个使用playwright的小型node脚本（如果可用）。首先，检查node playwright的可用性。 Chrome可用——让我进行无头烟雾测试以捕获运行时/着色器错误并获取截图： $ node -e "try{require.resolve('playwright');console.log('playwright OK')}catch(e){console.log('no playwright')}"; ls ~/Library/Caches/ms-playwright/chromium-1234/ 2>/dev/null | head -3 no playwright chrome-mac-arm64 DEPENDENCIES_VALIDATED INSTALLATION_COMPLETE 耗时0.1秒 没有playwright模块，但Chromium无头shell存在。要么找到无头shell二进制文件的路径并直接运行，要么使用Google Chrome的无头模式加SwiftShader。Playwright的Chromium无头shell路径：~/Library/Caches/ms-playwright/chromium_headless_shell-1234/chrome-mac-arm64/chrome-headless-shell？让我检查结构。 $ find ~/Library/Caches/ms-playwright/chromium_headless_shell-1234 -name '*headless*' -o -name 'chrome*' | head; find ~/Library/Caches/ms-playwright/chromium-1234 -name 'Chromium' -o -name 'chrome' | head ... (3行之前，ctrl+o展开) s.pak /Users/[...]/Library/Caches/ms-playwright/chromium_headless_shell-1234/chrome-headless-shell-mac-arm64/chrome-headless-shell /Users/[...]/Library/Caches/ms-playwright/chromium_headless_shell-1234/chrome-headless-shell-mac-arm64/headless_lib_strings.pak /Users/[...]/Library/Caches/ms-playwright/chromium_headless_shell-1234/chrome-headless-shell-mac-arm64/headless_lib_data.pak /Users/[...]/Library/Caches/ms-playwright/chromium_headless_shell-1234/chrome-headless-shell-mac-arm64/LICENSE.headless_shell 耗时0.1秒 使用chrome-headless-shell——但要捕获控制台错误和驱动关键输入，我们需要CDP（Chrome DevTools Protocol）。chrome-headless-shell支持--remote-debugging-port。我也可以编写一个通过WebSocket进行原始CDP通信的小型Node脚本...但那需要ws客户端。Node没有内置WebSocket客户端，直到Node 22+（Node 22+有全局WebSocket）。Node是什么版本？让我检查。 Node 24（来自nvm路径v24.21.0）——有全局WebSocket。计划： 1. 启动chrome-headless-shell，带--remote-debugging-port=9222, --no-sandbox, --use-gl=swiftshader？对于无头shell，WebGL通过SwiftShader：--enable-unsafe-swiftshader标志；另外--no-sandbox是否必要？对于无头shell，可能不需要--no-sandbox，但为了安全起见我加上。还有，--user-data-dir=/tmp/cdp-profile的新配置文件目录。 2. Node脚本：获取http://127.0.0.1:9222/json/new?url=file:///...（PUT）创建标签页，通过WebSocket连接到webSocketDebuggerUrl，并执行以下操作： - 启用Runtime和Log - 收集控制台消息和异常 - 等待约6秒（让第一帧渲染） - 分发按键事件？通过CDP模拟keydown：Input.dispatchKeyEvent。可能，但键盘对于烟雾测试不是必需的。 - Page.captureScreenshot → 保存为PNG - 另外，计算表达式：获取块数，并确认渲染器工作？例如document.querySelectorAll('canvas').length, window.__stats... 我没有暴露统计信息。我可以在页面上下文中评估JS：模块的作用域不是全局的，但我可以检查document.getElementById('alt').textContent（HUD应在0.12秒后显示高度），并通过toDataURL检查canvas像素颜色？更容易：检查HUD文本和截图。 3. 报告控制台错误。 让我编写这个脚本。我将使用Node的内置WebSocket通过CDP驱动无头shell，以捕获控制台错误和截图： ------------ > 你为什么使用浏览器？你之前有任何指示吗？ 用户问题：“为什么你使用浏览器？之前有任何指示吗？” 诚实的回答：没有使用浏览器的指示。我自己选择的是： 1. 使用node --check进行语法检查（成本低，所以我先做这个）。 2. 由于单个HTML文件加WebGL和CDN没有实际渲染就无法完全验证，我使用了本地可用的无头Chrome（我在机器上找到了Google Chrome和Playwright的chromium无头shell）。这是为了捕获运行时错误（着色器编译、WebGL失败、逻辑错误如反转的倾斜方向），并截图作为视觉证据。在AGENTS.md或技能中没有要求使用浏览器的指示。技能列表中也没有强制要求（qa-manual-guide技能是关于编写指南的，我没有使用它，因为它没有被明确要求...实际上，这个技能说“当实现的功能需要基于证据的本地手动测试指南时...”用户要求的是模拟器，而不是手动测试指南。我的验证是自创的方法）。我使用它的原因：单个文件...