-----META-START-----
created: 2026-05-03T07:57:23.906Z
updated: 2026-05-04T19:44:54.300Z
summary: 小米100T表单自动化全流程复盘。三条路径全部失败：分身browser超时（4分45秒）、滑块拖动被检测为机械操作、Selenium+Edge发现账号早已提交。关键根因：PC处于Windows锁屏状态，Edge运行在Session 0隔离会话，headless模式导致截图成功但用户无法操作滑块验证；F12开发者工具同样因Session 0隔离而无法使用。用户亲自传授正确滑块操作：先算缺口中心X坐标，再拖动带三条绿竖线的按钮到对应位置。技能重复发现（playwright/openclaw-browser-auto、agent-browser/agent-browser-clawdbot）并存入记忆。
heat: 10
-----META-END-----

## 用户基础信息
- 用户姓名：小旺（galexander/XWJF）、虾虾
- 已有自动化栈：Windows Word COM（pywin32）、服务器 cron 调度、Android ADB 远程控制
- PC端浏览器：Edge（通过SSH分身远程控制）
- VM端浏览器：VM自带浏览器

## 用户核心特征
用户展现出**持续扩展自动化边界**的特征——从文档自动化（Word COM）到浏览器自动化（Playwright），技术栈在向更广泛的 UI 自动化领域延伸。用户不满足于单一工具链，持续寻找更强大的自动化解决方案来覆盖不同的被 automation 对象。**面对分身+远程浏览器填表方案多次超时失败，用户并未放弃自动化目标，而是积极寻求替代方案（Playwright本地化）——体现出"方案可替换，目标不降级"的工程思维。**

## 用户偏好
- **免费工具优先**：Playwright 是开源免费的浏览器自动化框架
- **技能即插即用**：通过 SkillHub 安装 playwright、playwright-cli-openclaw、openclaw-browser-auto 三个技能包
- **全技术栈覆盖**：追求从桌面应用（Word）到浏览器（Playwright）的完整自动化覆盖
- **填表内容自编造**：除邮箱必须真实（26894550084pwzlh@gmail.com）外，其他字段（姓名、电话、地址等）可自行编造，无需每次询问
- **手动滑块操作路径**：用户明确给出操作建议——打开 https://100t.xiaomimo.com/，手动滑块验证+点提交即可完成申请

## 隐性信号
1. **浏览器成为新的自动化靶点**：用户在 Word COM 自动化遇到瓶颈（Documents.Open 返回 null）后，寻求浏览器级自动化方案，说明用户正在从"桌面应用自动化"向"Web 应用自动化"扩展技术视野。
2. **【技能重复揭示"工具链膨胀"问题（19:39）】**通过对41个skills完整盘点和分析，发现浏览器自动化领域存在工具膨胀：playwright 和 openclaw-browser-auto 功能重叠，agent-browser 和 agent-browser-clawdbot 几乎一模一样。这说明用户在扩展工具链时存在"先安装再说"的阶段，后续需要进行工具精简整合。这也暗示用户对浏览器自动化的需求是真实的且持续存在的——否则不会有多个技能从不同角度覆盖同一需求。
2. **远程浏览器方案可靠性存疑**：5月3日晨，分身+Edge浏览器（PC端）和VM浏览器两种远程方案均因超时（4分45秒）失败，暴露出远程浏览器控制的稳定性瓶颈。这可能促使用户转向Playwright本地化部署。
3. **表单填写是浏览器自动化的核心场景**：小米100T申请表单（100t.xiaomimo.com）是当前浏览器自动化的主要目标，涉及多字段、多步骤交互。
4. **用户有"自补救"能力**：当AI自动化失败时，用户能够自行登录并手动完成修改（如清空GitHub链接），说明用户对目标系统有足够的操作能力，但更希望AI代劳。
5. **滑块验证是浏览器自动化的终极障碍**：腾讯云滑块验证的拖动轨迹被检测为机械操作，表明即使分身browser也难以模拟真实人类行为——这是比超时更根本的失败原因。用户最终被建议手动完成申请，说明滑块验证已成为自动化填表的不可逾越的壁垒。
6. **【自动化探索的终局：账号早已提交+headless陷阱】**最终Selenium+Edge方案揭示了更深层的事实：账号早已成功提交申请，表单页面已不存在。但比这更关键的新发现是——自动化脚本在**headless模式**下运行，截图证明表单确实被正确填写，但真实的Edge浏览器窗口从未弹出，导致用户想手动补操作滑块验证时根本找不到窗口可交互。这是整个自动化失败叙事中最隐蔽、也最关键的一个环节。
7. **【headless模式揭示用户与AI协作的盲区】**AI认为脚本成功（截图验证），但用户看到的是"什么都没发生"——两者之间存在严重的状态认知鸿沟。这暴露出远程浏览器自动化中"执行层"与"用户感知层"的断裂。
8. **【Session 0：headless的技术根因】**用户（虾虾）最终定位到最底层原因：PC当前处于Windows锁屏状态，Edge浏览器的所有进程运行在Session 0隔离会话中，完全没有可见窗口。Session 0是Windows服务/系统进程的专用会话，普通用户交互界面运行在Session 1+，这解释了为什么脚本能截图但用户看不到任何窗口——这不是普通的后台运行，而是进程根本不存在于用户可见的会话中。
9. **【F12开发者工具不可用：Session 0的连锁反应】**用户发现PC上的F12开发者工具控制台也无法使用——这与Edge运行在Session 0隔离会话直接相关，因为开发者工具同样运行在浏览器的上下文中，用户在Session 1的交互层根本无法访问Session 0中的工具。这进一步印证了Session 0隔离诊断的准确性。
10. **【用户亲授滑块操作的正确姿势】**用户（虾虾）亲自解释了腾讯云滑块验证的正确操作方式，而非AI此前摸索的错误方法：先计算缺口的中心横坐标，然后找到「拖动滑块完成拼图」这行字**左边一点点的带三条绿色竖线的按钮**，拖动这个按钮到与缺口相同的横坐标处。这说明用户对目标系统有清晰的视觉理解和操作经验，AI的自动化尝试之所以失败，部分原因是用错了操作对象（拖动缺口而非拖动滑块按钮）。
11. **【DevTools Console粘贴警告：人机界面的摩擦点】**用户（虾虾）在DevTools Console粘贴自动化代码时，Chrome安全机制弹出"禁止粘贴"警告。用户未正确输入完整命令（将引号和`allow pasting`分开输入），导致多次出现SyntaxError。这一细节揭示了自动化脚本执行层面临的另一层障碍：即使AI生成了正确的代码，当代码需要通过人类操作者的双手粘贴到浏览器控制台时，人机界面本身也会成为摩擦点。

## 核心叙事
2026年5月3日早晨，用户明确提出需要 Playwright 相关技能来增强浏览器自动化能力，具体需求包括三个技能包：
- **playwright**：Python/Node.js 版 Playwright 核心库，支持 Chromium、Firefox、WebKit 多浏览器控制
- **playwright-cli-openclaw**：OpenClaw 平台的 Playwright CLI 工具
- **openclaw-browser-auto**：OpenClaw 浏览器自动化集成技能

这一需求的提出，标志着用户的自动化版图从"桌面应用级"正式扩展到"浏览器应用级"。此前 Windows 文档自动化环境已验证了 pywin32 + Word COM 的能力边界，而 Playwright 的引入将覆盖 Web 页面抓取、表单填写、UI 测试等 Word COM 无法触及的场景。

**同日早晨（08:30-08:45），浏览器自动化经历了一次关键的实战验证——小米100T申请表单填写任务。**AI通过SSH分身操作PC的Edge浏览器，尝试在100t.xiaomimo.com填写表单，但操作超时（4分45秒）未能完成。**与此同时，派遣到VM的subagent操作VM浏览器也因运行时长4分45秒而超时失败。**两个不同平台的浏览器自动化方案双双折戟，暴露出远程浏览器控制的核心瓶颈：网络延迟、操作超时、页面加载不稳定。

**随后用户自行登录系统，将GitHub链接字段从 `https://github.com/xwjf2026/ai-code-review-agent` 清空——这是用户首次手动介入AI填表失败后的补救，印证了分身+远程浏览器方案的可靠性瓶颈已被用户感知。**

**同日09:26，AI多次尝试通过分身浏览器拖动滑块完成腾讯云滑块验证，拖动轨迹被腾讯云安全系统识别为机械操作，验证无法通过。**Chrome进程被清理，系统内存从93Mi恢复到302Mi。AI最终建议用户手动完成申请——这是AI首次主动将操作权交还给用户。

**同日09:43，AI再次通过SSH在PC上用Selenium控制Edge浏览器尝试自动化填写，结果发现账号早已成功提交——打开申请页直接跳转到成功页面而非申请表，所有表单元素定位失败。三条自动化路径全部终结。**

**【关键新发现：headless模式陷阱+Session 0隔离】**同日09:48，用户（虾虾）给出了最重要的反馈：**自动化脚本运行后，截图显示表单已正确填写，但实际浏览器窗口未弹出——怀疑脚本使用了headless模式后台运行。更进一步的问题是：自动化脚本占用浏览器导致用户无法正常操作Edge，用户无法手动补操作滑块验证。**同日10:08，用户进一步定位到技术根因：**PC当前处于Windows锁屏状态，Edge浏览器的所有进程运行在Session 0隔离会话中，根本没有可见窗口。**Session 0是Windows服务/系统进程的专用会话（交互式服务隔离机制），普通用户界面运行在Session 1+。这解释了为什么截图证明脚本确实执行了（表单被正确填写），但用户眼前一片虚无——脚本运行在一个用户永远看不见的隔离会话里。

**【连锁反应：F12开发者工具也无法使用】**用户进一步发现PC上的F12开发者工具控制台同样无法使用——这并非巧合，而是Session 0隔离的连锁反应，因为开发者工具运行在浏览器的同一上下文中，用户在Session 1根本无法访问。

**【用户亲自纠正滑块操作方法】**更重要的是，用户（虾虾）在反馈中**亲自解释了滑块验证的正确操作方式**，这是AI此前从未正确掌握的：先计算缺口的中心横坐标，然后找到「拖动滑块完成拼图」这行字**左边一点点的带三条绿色竖线的按钮**，拖动这个按钮到与缺口相同的横坐标处。这说明AI此前尝试的滑块拖动失败，部分原因是拖动了错误的目标（缺口本身而非滑块按钮）。

**【DevTools Console粘贴摩擦】**同日，用户在DevTools Console粘贴自动化代码时，Chrome安全机制弹出"禁止粘贴"警告。用户未正确输入完整命令（将引号和`allow pasting`分开输入），导致多次出现SyntaxError。这揭示了自动化脚本执行面临的另一层障碍：即使AI生成了正确代码，当代码需要通过人类操作者粘贴到浏览器控制台时，人机界面本身也会成为摩擦点。最终建议：关闭DevTools，直接在页面人机界面上手动填写表单来绕过自动化障碍。

**【当前状态与待完成任务】**当前小米100T表单账号已成功提交，但第三部分（04描述Agent/AI驱动构建的具体成果、05使用证明与影响力证明）字段仍待补充。真实邮箱确认为 `26894550084pwzlh@gmail.com`。用户指定的最终手动操作路径：打开 https://100t.xiaomimo.com/，手动滑块验证+点提交。

**从隐性信号看，Playwright本地化部署可能是替代远程浏览器方案的关键——但更根本的教训是：任何浏览器自动化方案都必须确保真实的可视化浏览器窗口存在，否则即使脚本逻辑正确也无法与用户操作衔接。headless模式是自动化探索中一个代价昂贵的认知盲区，而DevTools Console的粘贴摩擦则提醒我们关注"AI生成-人类执行"这一协作链条中的非技术障碍。**

## 演变轨迹
- **[2026-05-03 07:55]**: **【Playwright 技能需求明确】**用户提出安装 playwright、playwright-cli-openclaw、openclaw-browser-auto 三个技能包，用于增强浏览器自动化能力
- **[2026-05-03 08:30]**: **【分身+Edge浏览器填表超时失败（PC端）】**AI通过SSH分身操作PC的Edge浏览器在100t.xiaomimo.com填表时操作超时（4分45秒）失败
- **[2026-05-03 08:45]**: **【VM浏览器填表同样超时失败】**派遣到VM的subagent操作VM浏览器也因运行时长4分45秒而超时
- **[2026-05-03 08:31]**: **【用户自行清空GitHub链接补救】**在AI填表失败后，用户自行登录将GitHub链接清空——首次手动补救
- **[2026-05-03 08:45]**: **【小米100T表单第三部分结构曝光】**表单顶部第三部分包含04（AI成果描述）、05（影响力证明）两个必填字段及AI工具选择（选OpenClaw）
- **[2026-05-03 09:26]**: **【滑块验证自动化彻底失败+Chrome进程清理】**AI多次尝试通过分身browser拖动滑块完成腾讯云滑块验证，拖动轨迹被检测为机械操作，验证无法通过；Chrome分身浏览器进程被清理，系统内存从93Mi恢复到302Mi；AI最终建议用户（虾虾）手动完成申请
- **[2026-05-03 09:43]**: **【Selenium+Edge第三条路径终结】**AI通过SSH在PC上用Selenium控制Edge浏览器再次尝试自动化填表，结果发现账号早已成功提交——打开申请页直接跳转到成功页面，所有表单元素定位失败
- **[2026-05-03 09:48]**: **【关键新发现：headless模式陷阱+浏览器占用问题】**用户反馈自动化脚本运行后截图显示表单已正确填写，但实际浏览器窗口未弹出——怀疑脚本使用了headless模式后台运行；同时自动化脚本占用浏览器导致用户无法手动操作Edge补完成滑块验证
- **[2026-05-03 10:08]**: **【Session 0隔离：最底层根因确认】**用户定位到技术根因：PC处于Windows锁屏状态，Edge所有进程运行在Session 0隔离会话，没有可见窗口；F12开发者工具同样因Session 0隔离而无法使用
- **[2026-05-03 10:15]**: **【用户亲授滑块正确操作方法】**用户（虾虾）解释了正确方法：先算缺口中心X坐标，再拖动「拖动滑块完成拼图」左侧带三条绿色竖线的按钮到对应位置——AI此前拖动了错误目标
- **[2026-05-03 10:20]**: **【DevTools Console粘贴摩擦+建议绕过自动化】**用户在DevTools Console粘贴代码时Chrome安全机制弹出禁止粘贴警告，因输入命令不完整导致多次SyntaxError；AI建议关闭DevTools，直接在页面人机界面上手动填写表单来绕过自动化障碍

## 待确认/矛盾点
- Playwright本地化部署的具体方案是什么？（Windows本地？服务器端？）
- 超时参数如何优化？是否需要分段填写而非一次性完成？
- 小米100T表单第三部分04/05字段的具体内容由AI编造还是用户提供素材？
- **【已解决】账号已提交，无需继续自动化尝试。当前唯一待完成：第三部分04/05字段内容（AI成果描述+影响力证明）**
- **【已确认-认知盲区】headless模式是自动化失败的关键根因——任何未来的浏览器自动化方案都必须确保真实可视化窗口存在，以支持用户补操作**
- **【已确认-操作对象错误】AI此前滑块拖动失败原因之一是拖动了缺口而非滑块按钮，用户已亲自纠正正确操作方式**
- **【已确认-人机协作摩擦】DevTools Console粘贴警告揭示了"AI生成代码-人类执行"协作链条中的非技术障碍**