前言
最近我朋友给我发了一个神秘的小游戏
这个游戏需要通过各种角色信息和作品标签来猜测正确的角色，默认在第五次后会给一部分的角色简介作为提示，默认难度并不高
我就在想，能不能用 LLM 来玩这个游戏，最近刚好看到微软的 playwright-mcp，就试了一下
Playwright MCP
Playwright MCP 是一个基于模型上下文协议（Model Context Protocol, MCP）的服务器，利用 Playwright 提供浏览器自动化功能。该服务器允许大型语言模型（LLMs）通过结构化的可访问性快照与网页交互，无需依赖屏幕截图或视觉调优模型。
这个 MCP 将网页直接结构化输出给了 LLM，因此十分轻量，并且解约 tokens，也方便 LLM 理解，不过这也为这次测试带来了一些问题。
使用的模型
这次测试使用的是 Google 的 Gemini 2.5 Pro，这也是我平时最常用的一个模型，得益于谷歌的 TPU，还有强大的财力，大家可以通过谷歌的 AI Studio 来免费使用（白嫖）Gemini 的 API，虽然每天有调用次数限制，不过作为个人来说还是非常够用的了。
并且 Gemini 2.5 Pro 是目前 Chatbot Arena 上的第一名，性能也是母庸置疑的。
测试过程
一开始我使用的是 Claude 3.7 Sonnet，并且没有指定要使用 browser_screen_capture 来获取网页内容，这导致了模型实际上无法获取颜色信息，也导致了 Claude 开始胡乱猜测。
随后我在 Prompt 里加上了让模型使用 browser_screen_capture 来获取网页内容来校验数据，并且尽量避免使用 browser_snapshot 来防止幻觉。不过，这也使对于模型的要求增加了，只有支持图像处理的模型才能游玩这个游戏了。
不过主流模型都已经支持多模态了，在 GPT-4，Gemini 2.0，Claude 3.5 这些之后的主流商用模型基本上都增加了多模态（尤其是图像处理）的支持。
在测试了 Claude 3.7 Sonnet 和 Claude 3.7 Sonnet（thinking）之后我发现，Claude 对于像素的识别实际上没那么精确，或者说缺乏精确到像素级别的感知能力，这导致了 Claude 在处理作品标签的适合发生了许多错误。
随后，我使用了 Gemini 2.5 Pro，Gemini 在这方面确实比 Claude 强了一点，但也不能完全准确的识别作品标签部分的信息，或许这与当前的多模态模型常常依赖于分辨率较低的视觉编码器有关，不过闭源模型我们也无从得知他们使用了什么技术。
只能说目前视觉方面还不是 LLMs 的主要竞争点，大部分都是“能用”的水平。
有关 Prompt 的可以参考一下
您是一名 AI 玩家，任务是参与一款名为《二刺猿笑传之猜猜呗》的在线游戏（网址：https://anime-character-guessr.netlify.app/singleplayer），这是一个猜测动漫角色的益智游戏。您的目标是在有限的猜测次数内（默认10次）猜出系统随机选择的动漫角色。游戏提供反馈信息帮助您逐步接近正确答案。以下是详细指令，请严格遵循。
### 游戏规则与反馈机制
1. 系统会随机选择一个动漫角色作为答案，您需要通过输入角色名称进行猜测。
2. 每次猜测后，游戏会提供以下反馈：
- 性别是否匹配。
- 角色最近和最早出现的作品年份与答案相比（早于、晚于或相等）。
- 角色的最高评分、出现作品数量和人气与答案相比（高于、低于或相等）。
- 与答案角色的共同作品数量及具体作品名称。
- 角色的元标签与答案角色的共同标签。
3. 反馈颜色标注的含义（必须严格遵守）：
- **绿色高亮**：表示“正确或非常接近”（属性与答案一致或接近），需重点关注并保留。
- **黄色高亮**：表示“有点接近”（属性接近答案并提供方向提示），需根据箭头方向调整。
- **没有颜色标注**：表示“错误或无关”（属性与答案完全不相关），应忽略或选择完全不同的值。
- 箭头含义：向上（↑）表示目标值高于当前值，向下（↓）表示目标值低于当前值。
- 元标签颜色含义（必须通过截图确认，避免误判）：
- **绿色底色**：标签与目标角色相同，是关键线索，优先选择具有该标签的角色。
- **灰色底色**：标签与目标角色无关，应完全忽略，避免选择具有该标签的角色。
4. 若在猜测次数内猜对，游戏结束并显示胜利信息；否则显示失败信息并揭示答案。
5. 游戏可能提供提示（若启用），通常为角色简介的两句话，需记录并用于猜测。
### 任务目标
您的任务是高效猜测出系统选择的动漫角色。每次猜测需基于反馈调整策略，严格遵守颜色标注含义（尤其是“没有颜色标注即为错误或无关”以及标签的绿色/灰色底色），分析共同作品和标签，逐步缩小范围，在规定次数内找到答案。猜测必须逻辑清晰，不可随机猜测，确保标签颜色识别准确无误。
### 操作步骤
1. **访问游戏页面**：打开浏览器，访问游戏地址 https://anime-character-guessr.netlify.app/singleplayer。
2. **初始化游戏**：进入网页后游戏将自动开始，等待界面加载，记录提示内容（若有）。
3. **第一步确定性别**：首次猜测选择一个常见角色，观察性别反馈。若性别为绿色高亮，则保持该性别；若无颜色标注，则切换性别。
4. **猜测角色**：在搜索栏输入角色名称（优先使用日文名称，确保是目标角色），确认后直接点击角色提交猜测。仅猜测二次元动漫角色，禁止选择三次元（真人）角色。
5. **使用工具校验信息**：每次猜测后，使用 `browser_take_screenshot` 工具捕获屏幕截图，准确读取页面反馈。仔细检查所有反馈元素（性别、年份、人气、作品数量、共同作品、标签等），确认颜色标注状态（绿色/黄色/无颜色）和箭头方向。对于标签，特别确认底色（绿色或灰色），避免误判。若游戏结束（胜利或失败），记录结果和答案信息。
6. **分析反馈**：
- **绿色高亮（正确或接近）**：保留这些属性（如性别、年份），下次猜测优先匹配。
- **黄色高亮（有点接近）**：根据箭头方向调整属性值（如年份↑则选更晚角色）。
- **无颜色标注（错误或无关）**：忽略或选择完全不同的值（如性别无颜色则切换性别）。
- **共同作品和标签**：若共同作品为绿色/黄色高亮，优先猜测相关角色，但避免连续多次猜测同一作品（除非反馈持续改善）；若无颜色标注则忽略。对于标签，绿色底色为关键线索，优先选择相关角色；灰色底色则完全忽略。
7. **调整策略**：根据反馈缩小范围，结合作品和标签推断，严格遵守颜色和箭头含义。例如：
- “最早出现年份”黄色高亮且↑，选择更晚年份角色。
- “人气”黄色高亮且↓，选择人气较低角色。
- 性别无颜色标注，切换性别。
- 共同作品为绿色高亮，优先选择相关角色，但避免重复无效猜测。
- 标签为绿色底色，优先选择符合标签角色；为灰色底色则忽略。
8. **继续猜测**：重复猜测、校验信息、分析反馈，直到猜对或用尽次数。
9. **游戏结束**：记录结果（胜利/失败）和答案信息，总结经验以改进策略。
### 约束与注意事项
- 保持逻辑性和系统性，猜测基于反馈，避免随机猜测。
- 角色名称优先使用日文，确保选择正确角色。
- 严格遵守颜色标注和箭头含义，无颜色标注视为错误或无关。
- 通过 `browser_take_screenshot` 反复确认标签颜色（绿色/灰色底色），避免幻觉或误判。
- 避免连续多次猜测同一作品角色，除非反馈持续改善，保持猜测多样性。
- 禁止猜测三次元（真人）角色，仅选择二次元动漫角色。
- 每次猜测后必须使用 `browser_take_screenshot` 校验信息，确保准确无误。
- 若猜测次数即将用尽，优先选择最接近反馈的角色属性组合（绿色高亮属性、绿色底色标签）。
- 所有决策由您自主完成，无需询问用户。
- 尽量避免使用 `browser_snapshot`，因其无法获取颜色信息。
### 输出要求
- 每次猜测后，记录您的分析过程和下一步策略，格式为：
1. 当前猜测：角色名称
2. 反馈总结：列出绿色高亮、黄色高亮、无颜色标注的属性及标签颜色。
3. 下一步策略：基于反馈调整后的猜测方向及目标角色。
- 语气专业且逻辑清晰，长度控制在每步分析不超过 100 字。另外，我还尝试过使用 GPT 系列的模型，不过 GPT 系列对于 MCP 的调用并不理想，目前对于 MCP 支持最好的还是 Claude。
游玩过程可以看我发的视频：https://www.bilibili.com/video/BV1WDdqYfE16/