Playwright MCP：AI驱动UI自动化测试的新范式与实践

1. 项目概述：当UI自动化测试遇上MCP

最近在折腾UI自动化测试，特别是用Playwright，发现一个挺有意思的讨论点：Playwright MCP。这个词在社区里热度不低，但很多刚接触的朋友可能会有点懵——Playwright我知道，MCP我也听过，但它俩放一块儿是啥？是Playwright推出了一个叫MCP的新功能，还是说用MCP协议来驱动Playwright？这背后其实反映了一个更深层的问题：在AI Agent和LLM（大语言模型）应用爆发的今天，我们传统的UI自动化测试框架，它的定位和未来演进方向在哪里？

简单来说，Playwright MCP这个组合词，目前更常见的理解是利用MCP（Model Context Protocol）协议，将Playwright的能力暴露给AI Agent或LLM，而不是Playwright本身内置了一个叫MCP的模块。MCP协议是由Anthropic等公司推动的一个开放协议，旨在标准化AI模型与外部工具、数据源之间的连接方式。所以，“Playwright MCP”的核心场景是：你有一个AI助手（比如Claude Code），你想让它帮你写Playwright测试脚本、分析测试结果，甚至直接操作浏览器进行探索性测试。这时，你需要一个“翻译官”或“桥梁”，这个桥梁就是遵循MCP协议的Server，它封装了Playwright的API，让AI模型能够理解并调用。

这引发了我的思考。Playwright本身已经是一个非常强大、现代的浏览器自动化库了，那为什么还需要MCP来“掺一脚”？这恰恰说明了UI自动化测试领域正在发生的变化：从纯粹的、脚本驱动的“录制-回放”或“代码编写-执行”模式，向“智能辅助”、“自然语言驱动”和“自适应探索”的方向演进。测试的创建和维护，不再仅仅是测试工程师的专属工作，也可能由产品、开发甚至AI协作完成。而MCP这类协议，就是实现这种协同和智能化的关键基础设施。

因此，本文我想结合自己使用Playwright的经验，深入聊聊在MCP这个新范式下，UI自动化测试的定位该如何调整，我们在搭建框架、设计用例时又需要有怎样的新思考。无论你是正在评估Playwright的测试新手，还是寻求测试提效的老手，希望这些来自一线的实践和思考能给你带来一些启发。

2. 核心需求解析：为什么需要Playwright与MCP的结合？

要理解“Playwright MCP”的价值，我们得先拆解当前UI自动化测试面临的几个核心痛点，以及MCP协议试图解决什么问题。

2.1 UI自动化测试的传统痛点

即使有了Playwright这样优秀的工具，传统自动化测试流程依然存在门槛和瓶颈：

1. 脚本编写与维护成本高：虽然Playwright的API已经比Selenium简洁很多，但编写健壮、可维护的测试脚本仍然需要专业的编程技能和对前端技术的理解。元素定位策略（CSS Selector, XPath）、等待机制、iframe处理、网络请求拦截等，每一个细节都可能成为新手（甚至是有经验的开发者）的“坑”。维护成本更高，页面UI一旦改动，选择器可能失效，需要人工排查和更新。

2. 测试用例设计依赖人工经验：什么样的测试用例是有效的？边界情况有哪些？哪些流程是核心路径？这些很大程度上依赖测试人员的业务理解能力和经验。缺乏智能化的辅助来生成更全面的测试场景或识别潜在的风险点。

3. 与开发流程的割裂：自动化测试往往是测试团队在开发完成后才介入的工作。如果能在开发阶段，甚至设计阶段，就让自动化测试的思维和部分能力介入，实现“测试左移”，就能更早地发现问题。但让开发人员去写复杂的Playwright脚本并不现实。

4. 结果分析与洞察不足：测试运行后产生大量日志和截图，分析失败原因、定位问题根因仍然是一个耗时的手动过程。缺乏智能工具帮助快速归纳错误模式、关联代码变更或给出修复建议。

2.2 MCP协议带来的新可能性

MCP协议的核心思想是“让模型更好地使用工具”。它为外部工具（如浏览器、数据库、文件系统）定义了一套标准的“描述”和“调用”方式。当Playwright通过一个MCP Server暴露其能力后，AI模型就能像调用一个已知函数一样去操作浏览器。

这为解决上述痛点提供了新思路：

• 降低脚本创作门槛：测试人员或开发人员可以用自然语言描述测试意图，例如“请帮我写一个登录功能的测试，用户名输入‘test’，密码输入‘123456’，点击登录后验证是否跳转到首页”。AI模型通过MCP Server理解Playwright的能力，生成可执行的测试代码。这极大地降低了编写初始脚本的难度。
• 智能生成与补充测试用例：AI可以基于产品需求文档、用户故事甚至现有的部分测试用例，利用其对代码和业务逻辑的理解，自动生成更多的测试场景，包括边界值和异常流，弥补人工设计的盲区。
• 赋能探索性测试与调试：AI Agent可以扮演一个“不知疲倦的探索者”，根据MCP Server提供的浏览器操作能力（点击、输入、滚动、截图），在应用中进行探索性测试，记录操作路径和发现的问题（如JS错误、控制台警告、布局错乱），并自动生成问题报告。
• 增强结果分析与报告：测试运行后，AI可以分析失败截图、错误堆栈和网络日志，通过MCP查询相关代码仓库或文档，尝试推断失败原因，甚至给出具体的修复建议或代码片段。

所以，“Playwright MCP”的需求本质上是对UI自动化测试进行“智能化升级”和“体验重塑”的需求。它不取代Playwright，而是为其增加了一个强大的、自然语言的交互界面和智能大脑，让测试活动的参与方更广、效率更高、洞察更深。

3. 技术架构与方案选型

要实现“Playwright MCP”的能力，我们需要一个具体的技术架构。目前社区还没有一个官方的、开箱即用的“Playwright MCP Server”，但这正是其魅力所在——我们可以根据自身需求进行定制化构建。下面我分享一个可行的架构方案和选型思考。

3.1 核心组件与数据流

一个典型的“Playwright MCP”系统通常包含以下组件：

1. MCP Client (AI Agent / LLM应用)：这是发起请求的“大脑”。例如，在Claude Code编辑器中配置了MCP Client，或者你自己构建的一个基于LLM的测试助手应用。它负责理解用户自然语言指令，并将其转化为对MCP Server的标准调用。
2. Playwright MCP Server：这是核心的“桥梁”或“适配器”。它是一个独立的服务进程，主要职责有：
   • 实现MCP协议：暴露一组符合MCP规范的“工具”（Tools）和“资源”（Resources）。例如，工具可能包括navigate_to_url,click_element,fill_text,get_page_screenshot,run_test_script等。
   • 封装Playwright API：在Server内部，它调用真正的Playwright库（可能是Playwright for Python/Node.js/Java/.NET）来执行具体的浏览器操作。
   • 管理浏览器实例：负责Playwright浏览器实例（Chromium, Firefox, WebKit）的生命周期管理，包括启动、上下文创建、页面管理等。
3. 被测应用 (AUT)：即我们需要测试的Web应用程序。
4. 可选：测试基础设施：如测试数据管理、测试报告存储、持续集成(CI)环境等。MCP Server可以与这些系统集成，提供更丰富的能力（如“从数据库读取测试用户”、“将测试结果上传到报告平台”）。

数据流大致如下：用户向AI Agent用自然语言提出请求 -> AI Agent根据MCP协议格式，向Playwright MCP Server发起工具调用请求 -> MCP Server解析请求，调用对应的Playwright API操作浏览器 -> 浏览器与被测应用交互 -> MCP Server获取操作结果（成功/失败、截图、DOM状态等） -> MCP Server将结果返回给AI Agent -> AI Agent将结果组织成自然语言或代码反馈给用户。

3.2 技术选型考量

搭建这样一个系统，有几个关键的技术选型点：

• Playwright MCP Server的实现语言：这取决于你的技术栈和团队熟悉度。由于Playwright对Node.js和Python的支持最为成熟和全面，Node.js (TypeScript/JavaScript) 或 Python是首选。社区早期的一些MCP Server示例也多用这两种语言编写。选择Node.js可以利用其异步事件驱动的优势，更好地处理大量并发浏览器操作；选择Python则便于与已有的Python测试生态（如pytest）集成。
• MCP Server框架：你可以从头实现MCP协议，但更高效的方式是使用现有的SDK。Anthropic官方提供了@modelcontextprotocol/sdk(Node.js) 和mcp(Python) 等SDK，它们封装了协议通信、工具定义等底层细节，让你能更专注于业务逻辑（即Playwright操作的封装）。这是推荐的选择。
• AI Agent / LLM的选择：这决定了智能化的上限。你可以集成像Claude (通过Claude Code)、GPT或开源的Llama、DeepSeek等模型。需要考虑的是模型的代码理解能力、上下文长度以及对工具调用（Function Calling）的支持程度。Claude Code目前对MCP的原生支持较好，是快速上手的理想选择。
• 部署与运行模式：
  • 本地开发模式：MCP Server作为本地进程启动，AI Agent（如配置了MCP的Claude Code）通过stdin/stdout或本地Socket与其通信。适合个人探索和调试。
  • 服务化模式：将Playwright MCP Server部署为一个HTTP/SSE服务，允许网络上的多个AI Client连接。这更适合团队协作或集成到更大的自动化平台中。但需要注意安全性和浏览器实例的资源管理（避免内存泄漏）。

注意：无论选择哪种部署模式，Playwright浏览器实例的资源消耗都是必须严肃对待的问题。每个浏览器实例都占用不小的内存和CPU。在服务化场景下，必须实现连接池、超时销毁、异常恢复等机制，否则服务器很容易被拖垮。

4. 实操：构建一个基础的Playwright MCP Server

理论讲了不少，我们来点实际的。我将以Node.js (TypeScript) 环境为例，展示如何构建一个最基础的Playwright MCP Server。这个Server将暴露几个最常用的浏览器操作工具。

4.1 环境准备与初始化

首先，确保你的系统已安装Node.js (建议版本18+) 和 npm。

# 1. 创建一个新项目目录 mkdir playwright-mcp-server && cd playwright-mcp-server # 2. 初始化Node.js项目，并安装核心依赖 npm init -y npm install @modelcontextprotocol/sdk playwright npm install -D typescript @types/node tsx # 3. 初始化TypeScript配置 npx tsc --init # 在生成的 tsconfig.json 中，确保设置 "target": "ES2022", "module": "NodeNext", "outDir": "./dist" # 4. 创建源代码目录和入口文件 mkdir src touch src/server.ts

4.2 实现MCP Server核心逻辑

接下来，我们编辑src/server.ts文件。这个Server将实现两个核心工具：navigate（导航到URL）和screenshot（截取页面截图）。

import { Server } from '@modelcontextprotocol/sdk/server/index.js'; import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'; import { CallToolRequestSchema, ListToolsRequestSchema } from '@modelcontextprotocol/sdk/types.js'; import { chromium, type Browser, type Page } from 'playwright'; // 定义工具的参数和返回值类型 interface NavigateArgs { url: string; } interface ScreenshotArgs { selector?: string; // 可选，指定某个元素的CSS选择器 fullPage?: boolean; // 可选，是否截取整个可滚动页面 } class PlaywrightMCPServer { private server: Server; private browser: Browser | null = null; private page: Page | null = null; constructor() { // 1. 创建MCP Server实例 this.server = new Server( { name: 'playwright-mcp-server', version: '0.1.0', }, { capabilities: { tools: {}, // 声明本Server提供工具 }, } ); // 2. 注册工具列表处理器 this.server.setRequestHandler(ListToolsRequestSchema, async () => ({ tools: [ { name: 'navigate', description: '使用Playwright打开或导航到一个指定的URL。', inputSchema: { type: 'object', properties: { url: { type: 'string', description: '要导航到的完整URL，例如 https://example.com', }, }, required: ['url'], }, }, { name: 'screenshot', description: '截取当前页面的截图。可以截取整个页面或特定元素。', inputSchema: { type: 'object', properties: { selector: { type: 'string', description: 'CSS选择器，用于指定要截图的特定元素。如果省略，则截取整个视口或页面。', }, fullPage: { type: 'boolean', description: '如果为true，则截取整个可滚动页面的长图。默认为false。', }, }, }, }, // 后续可以继续添加更多工具，如 click, fill_text, get_text 等 ], })); // 3. 注册工具调用处理器 this.server.setRequestHandler(CallToolRequestSchema, async (request) => { const { name, arguments: args } = request.params; try { switch (name) { case 'navigate': { const { url } = args as NavigateArgs; await this.ensureBrowserAndPage(); // Playwright 实际导航操作 await this.page!.goto(url, { waitUntil: 'networkidle' }); return { content: [ { type: 'text', text: `成功导航到: ${url}`, }, ], }; } case 'screenshot': { const { selector, fullPage = false } = args as ScreenshotArgs; await this.ensureBrowserAndPage(); let buffer: Buffer; if (selector) { const element = await this.page!.$(selector); if (!element) { throw new Error(`未找到选择器为 "${selector}" 的元素`); } buffer = await element.screenshot(); } else { buffer = await this.page!.screenshot({ fullPage }); } // 将截图转换为base64，以便在文本协议中传输 const base64Image = buffer.toString('base64'); return { content: [ { type: 'text', text: `截图已完成。`, }, { type: 'image', data: base64Image, mimeType: 'image/png', }, ], }; } default: throw new Error(`未知的工具: ${name}`); } } catch (error: any) { return { content: [ { type: 'text', text: `工具调用失败: ${error.message}`, }, ], isError: true, }; } }); // 4. 初始化浏览器实例（懒加载） this.ensureBrowserAndPage = this.ensureBrowserAndPage.bind(this); } // 懒加载启动浏览器和页面 private async ensureBrowserAndPage() { if (!this.browser) { // 以无头模式启动，适合服务器环境。调试时可设置为 false: `headless: false` this.browser = await chromium.launch({ headless: true }); this.page = await this.browser.newPage(); // 设置默认视口和超时 await this.page.setViewportSize({ width: 1280, height: 720 }); this.page.setDefaultTimeout(30000); } } // 启动Server，使用stdio传输（适用于Claude Code等本地集成） async run() { const transport = new StdioServerTransport(); await this.server.connect(transport); console.error('Playwright MCP Server 已启动并等待连接...'); } // 清理资源 async close() { if (this.page) await this.page.close(); if (this.browser) await this.browser.close(); await this.server.close(); } } // 启动服务器 const server = new PlaywrightMCPServer(); server.run().catch(console.error); // 处理进程退出信号，优雅关闭 process.on('SIGINT', async () => { await server.close(); process.exit(0); }); process.on('SIGTERM', async () => { await server.close(); process.exit(0); });

4.3 编译、运行与连接AI Agent

1. 编译和运行Server： 在package.json中添加一个启动脚本：

   "scripts": { "start": "tsx src/server.ts" }

   然后运行：

   npm start

   你的Playwright MCP Server现在就在标准输入/输出上运行并等待连接了。

2. 配置AI Agent (以Claude Code为例)： 你需要告诉Claude Code如何找到你的MCP Server。这通常通过一个配置文件（如claude_desktop_config.json）完成。配置文件的位置因操作系统而异。

   • macOS:~/Library/Application Support/Claude/claude_desktop_config.json
   • Windows:%APPDATA%\Claude\claude_desktop_config.json
   • Linux:~/.config/Claude/claude_desktop_config.json

   编辑这个文件（如果不存在则创建），添加你的Server配置：

   { "mcpServers": { "playwright": { "command": "node", "args": [ "/ABSOLUTE/PATH/TO/YOUR/playwright-mcp-server/dist/server.js" // 注意：需要先编译成JS，或直接使用tsx运行ts文件 ], "env": { "NODE_ENV": "development" } } } }

   实操心得：配置路径一定要用绝对路径。更稳妥的做法是，在项目目录下写一个简单的启动脚本（shell或batch），然后在配置中指向这个脚本，脚本内处理好路径和运行环境。

3. 在AI Agent中使用： 重启Claude Code后，你就可以尝试用自然语言发出指令了，例如：

   • “请导航到百度首页。”
   • “为当前页面截个图。” AI模型会理解你的意图，通过MCP协议调用你编写的Server中的navigate和screenshot工具，并将结果（成功信息或base64格式的图片）返回给你。

这个示例虽然简单，但完整展示了从零搭建一个Playwright MCP Server的核心流程。你可以在此基础上，继续添加click,fill_text,evaluate（执行JS）,get_content（获取页面文本）等更多工具，使其功能越来越强大。

5. 深入思考：MCP范式下UI自动化测试框架的设计要点

有了可以运行的Playwright MCP Server，我们回到更本质的问题：在这种新的“智能驱动”范式下，我们设计UI自动化测试框架时，思路要有哪些转变？以下是我总结的几个关键点。

5.1 从“脚本集合”到“能力服务”

传统的自动化测试框架，核心资产是一堆测试脚本文件（.spec.js,.test.py）。而在MCP架构下，Playwright的核心价值被抽象为一组标准的、可远程调用的服务能力。这意味着：

• 能力需要被良好地定义和描述：MCP Server暴露的每个“工具”（Tool），其输入参数、输出格式、可能发生的错误都需要有清晰的定义。这类似于设计一套API。良好的设计能让AI模型更准确地理解和使用它们。例如，click工具除了需要selector参数，是否还需要一个wait_for参数来指定点击后等待何种状态（如导航完成、元素出现）？
• 状态管理变得复杂：在传统脚本中，浏览器页面（Page）的状态随着代码执行线性变化。在MCP服务中，多个AI请求可能并发或交错发生，它们可能操作同一个页面，也可能需要独立的页面上下文。Server必须设计合理的会话（Session）或上下文（Context）管理机制，来隔离不同“对话”或“任务”的状态，避免相互干扰。
• 错误处理与恢复需要更健壮：AI模型可能发出不合理或顺序错误的指令（比如在页面加载完成前就尝试点击）。Server端不能简单崩溃，需要设计友好的错误反馈机制，将Playwright执行过程中的异常（如超时、元素未找到）转化为AI模型能理解的错误信息，并尽可能保持浏览器会话的可用性。

5.2 测试用例的生成、描述与维护

当AI能够参与测试创作时，测试用例的存在形式可能发生变化。

• 自然语言作为“需求”或“种子”：最基础的测试场景可以用自然语言描述，由AI转化为可执行的脚本。这要求我们积累和提炼出高质量的“提示词（Prompt）”，来指导AI生成结构良好、断言完整、稳定性高的测试代码。
• 测试用例的“元描述”：我们可能不再直接维护大量的具体脚本代码，而是维护一套测试场景的元数据描述。这套描述定义了测试的意图、数据、流程节点，而具体的代码实现可以由AI根据当前应用的状态动态生成。当页面UI发生变化时，只需调整元描述或重新生成代码，可能比直接修改硬编码的选择器更容易。
• 视觉与结构双重断言：AI可以更容易地结合视觉对比（通过截图）和DOM结构/文本内容进行综合断言。MCP Server可以提供screenshot_and_compare（截图对比）、get_element_styles（获取元素样式）等工具，让AI不仅能判断“按钮是否存在”，还能判断“按钮的颜色和位置是否正确”。

5.3 与现有测试生态的融合

引入MCP和AI能力，不意味着抛弃现有的优秀实践和工具链。

• 与测试运行器（Test Runner）结合：生成的Playwright测试脚本，最终应该能无缝接入你现有的测试运行器，如Playwright Test、Jest、pytest等。这样可以利用它们强大的并行化、重试、报告和钩子（Hooks）功能。MCP Server可以提供一个run_test_suite工具，接收测试文件路径或代码字符串，调用本地的Playwright Test CLI来执行，并返回标准化结果。
• 测试数据管理：AI生成测试时，需要测试数据。MCP Server可以集成访问测试数据源（如数据库、CSV文件、API）的工具，让AI能够获取合适的测试数据来填充表单。这需要事先定义好数据源的访问方式和数据格式。
• 持续集成（CI）流程：在CI流水线中，如何触发AI辅助的测试？一种模式是，在代码合并前，由AI Agent基于代码变更自动分析受影响的功能，并生成或更新相应的回归测试脚本，然后提交执行。这需要将MCP Server集成到CI环境中，并处理好权限和资源隔离问题。

5.4 安全与风险控制

将浏览器自动化能力通过一个服务暴露出来，尤其是可能被AI自动调用，安全是重中之重。

• 操作范围限制：必须严格限制MCP Server可访问的URL范围。绝不能允许AI随意导航到任意外部或内部生产环境网站。可以通过配置白名单，或限制只能访问某个特定的测试环境域名。
• 危险操作禁止：某些Playwright操作具有潜在风险，如文件下载、上传（可能上传恶意文件）、执行任意JavaScript代码（page.evaluate）。在暴露给AI时，必须仔细评估，必要时禁止或施加严格的沙箱限制。
• 权限与认证：如果MCP Server以服务形式部署，必须实现客户端认证。AI Agent在调用前需要提供有效的凭证。同时，Server本身操作浏览器时用到的任何测试账号密码，都应通过环境变量或安全的密钥管理服务获取，绝不能硬编码。
• 资源配额与隔离：为防止恶意或错误的AI指令耗尽资源，必须为每个会话或客户端设置资源配额，如最大运行时间、最大内存使用、最多打开的页面数等。并且确保不同会话的浏览器上下文是完全隔离的。

6. 常见问题与避坑指南

在实际探索“Playwright MCP”的过程中，我踩过不少坑，也总结了一些常见问题和解决思路。

6.1 开发与调试阶段

• 问题：MCP Server启动失败，AI Agent连接不上。

  • 排查：首先检查AI Agent的配置文件路径和命令是否正确。最有效的方法是直接运行你的Server启动命令，看其是否能独立启动并打印出等待连接的日志。如果Server启动报错，通常是依赖未安装（playwright浏览器未下载）或代码语法错误。
  • 技巧：在开发初期，可以暂时将MCP Server实现为一个简单的HTTP服务器，用curl或Postman手动发送MCP格式的请求来测试工具调用，这比通过AI Agent调试更直接。

• 问题：AI模型无法正确理解或调用我定义的工具。

  • 排查：检查你在Server中定义的工具描述（description）和输入模式（inputSchema）是否足够清晰、准确。AI模型严重依赖这些元数据来理解工具的功能和用法。描述应简洁明了，参数应注明是否必填、类型和示例。
  • 技巧：参考Anthropic官方MCP文档中优秀工具定义的范例。为复杂工具提供详细的示例（example字段）非常有帮助。

• 问题：Playwright操作超时或失败，但错误信息不清晰。

  • 排查：在Server代码中增加详细的日志记录，记录接收到的请求、调用的Playwright API以及抛出的异常堆栈。特别是在ensureBrowserAndPage和每个工具的实现中，加入try-catch块，捕获所有可能的错误（网络错误、选择器错误、浏览器崩溃等）。
  • 技巧：为Playwright页面设置合理的超时（setDefaultTimeout），并为关键操作（如goto,waitForSelector）单独配置等待策略和超时时间。在返回给AI的错误信息中，尽量包含有操作性的提示，如“元素未找到，当前页面标题是X，可用的主要元素有Y”。

6.2 稳定性与性能

• 问题：长时间运行后，Server内存占用越来越高。

  • 原因：浏览器实例（BrowserContext, Page）未被正确关闭。即使操作完成，如果页面没有关闭，相关的JS上下文、DOM树、缓存等资源会一直驻留内存。
  • 解决：实现会话管理。为每个独立的“任务”或“对话”创建独立的BrowserContext，并在任务完成后（或超时后）强制关闭该Context及其中的所有Pages。定期清理闲置过久的会话。

• 问题：并发请求时，操作相互干扰或失败。

  • 原因：多个AI请求共享了同一个Page实例，一个请求的操作（如导航）会打断另一个请求正在进行的操作。
  • 解决：坚决做到会话隔离。每个客户端连接或每个用户请求，都应该对应一个独立的Playwright BrowserContext（甚至独立的Browser实例）。这样能确保完全的并行和隔离。虽然这会增加资源开销，但稳定性是首要的。可以通过连接池技术来平衡资源和性能。

• 问题：截图或页面内容返回给AI时数据量太大，导致传输缓慢或出错。

  • 解决：MCP协议对单次消息大小可能有限制。对于截图，可以：
    1. 压缩图片质量（Playwright的screenshot选项可以设置quality）。
    2. 只截取关键区域，而非整个页面。
    3. 对于文本内容，可以限制返回的长度，或提供摘要。
    4. 考虑将大型数据（如图片、文件）先存储到一个临时位置（如对象存储），然后通过一个URL资源（Resource）的方式提供给AI，而不是直接嵌入在消息中。

6.3 与AI协作的提示

• 问题：AI生成的测试脚本过于脆弱，元素选择器不合理。

  • 建议：不要完全依赖AI生成最终脚本。将其视为“初级测试开发助手”。它生成的代码需要经过有经验的工程师审查和优化。你可以通过Prompt引导AI使用更稳定的定位策略，例如：“请使用包含>