AI智能体与SST本地开发环境高效协作配置指南

1. 项目概述：当AI智能体遇上SST本地开发模式

如果你和我一样，正在深度使用Cursor、Claude Code这类AI编程助手来构建基于SST（Serverless Stack）的全栈应用，那你很可能已经遇到了一个共同的痛点：AI智能体在SST的dev模式下，表现得像个“盲人摸象”的新手。它会反复尝试启动已经运行的服务，找不到应用的真实端点，对控制台里滚动的日志视而不见，甚至在你眼皮底下创建出第二个、第三个重复的应用实例，把原本清晰的开发流程搅得一团糟。

这正是martinpllu/sst-agent-setup这个项目诞生的背景。它不是一个全新的框架或工具，而是一套经过实战检验的“规则”与“环境”配置方案，旨在为你的AI编程伙伴（特别是Cursor）铺平道路，让它能像一个经验丰富的开发者一样，与SST的本地开发环境顺畅协作。其核心哲学非常明确：开发者（你）负责启动并监控npx sst dev，而AI智能体则基于清晰的规则和上下文，在这个已运行的沙箱中进行安全的、可观察的编码操作。这既保证了开发流程的掌控权在你手中，又能最大化发挥AI的编码与问题诊断能力。

简单来说，这个项目解决了AI驱动开发中的一个关键断层。SST的dev模式本身极其强大，它通过CloudFormation本地模拟和热重载，提供了无与伦比的快速反馈循环。但当AI试图介入时，由于缺乏对当前运行状态的上下文感知，它往往会采取一些“想当然”但实际会破坏环境的行为。本方案通过提供结构化的日志访问、明确的状态发现规则以及安全的浏览器交互能力，弥合了这一断层。

2. 核心设计思路与方案选型

2.1 问题根源：AI智能体与SST dev模式的认知错位

要理解这套方案的价值，首先得拆解AI智能体在SST环境中“犯傻”的深层原因。这并非AI能力不足，而是信息不对称导致的必然结果。

1. 状态感知缺失：AI智能体（如Cursor的Agent模式）在分析代码库并执行任务时，通常从一个“干净”的上下文开始。它看不到你终端里正在运行的npx sst dev进程，也看不到该进程输出的实时日志、已创建的资源（如本地DynamoDB表、模拟的API Gateway端点）和应用程序的URL。因此，它的第一反应往往是尝试执行npm run dev或sst dev来“启动”应用，而这会与现有进程冲突。
2. 日志与输出隔离：SSTdev模式会将基础设施（Lambda、API Gateway等）的日志输出到终端，并通过一个基于WebSocket的日志查看器呈现。然而，前端框架（如React、Next.js）的开发服务器输出通常直接打印在启动它的终端里。AI智能体无法直接“看到”这些分散的日志流，导致它在调试前端问题时缺乏关键信息。
3. 端点发现困难：应用启动后，其访问URL（如http://localhost:3000）和API端点（如http://localhost:8000/api/）是动态生成的。AI智能体需要一种可靠的方式来获取这些信息，而不是基于代码中的硬编码猜测或重新部署。
4. 不安全的环境交互：一些开发任务可能需要与正在运行的应用进行交互，例如提交表单、点击按钮以验证流程。让AI直接在你的浏览器中操作是不现实且危险的。需要一种受控的、可编程的浏览器交互方式。

2.2 方案选型：规则（Rules）优先于MCP服务器

项目作者martinpllu在探索解决方案时，尝试过构建一个专用的MCP（Model Context Protocol）服务器。MCP是Anthropic提出的一种协议，旨在让模型安全、结构化地访问外部工具和数据。他尝试了两种路径：一是通过WebSocket连接到已运行的SST开发服务器以获取流式日志；二是直接以子进程方式启动sst dev --mode=mono并捕获其标准输出。

然而，他最终放弃了MCP服务器方案，选择了更轻量、更灵活的规则（Rules）文件方案。这是一个非常务实且高明的决策，原因如下：

• 复杂度与维护成本：一个功能完整的MCP服务器需要处理进程管理、流式数据解析、错误处理、资源清理等复杂逻辑。这引入了新的故障点，且其配置和调试本身就需要相当的开发量。
• 灵活性与适应性：规则文件（如Cursor的.mdc文件）本质上是给AI模型的“说明书”或“提示词”。它可以直接告诉AI：“环境已经这样设置了，你应该这样去获取信息，避免那样做。”这种方式更易于理解和定制。开发者可以根据自己项目的特殊结构（例如使用了特定的Monorepo工具，或有自定义的脚本）快速修改规则，而无需改动服务器代码。
• 更符合“辅助”定位：本方案的核心原则是“人主导，AI辅助”。规则文件完美地体现了这一点：它引导AI在人类已搭建好的舞台上表演，而不是让AI自己去搭建舞台。这降低了不可预测性，让开发者始终处于控制回路中。
• 更广泛的兼容性：规则文件的概念不仅限于Cursor。它可以很容易地适配到其他支持类似功能的AI编码环境，例如通过项目根目录的CLAUDE.md文件来指导Claude Code。这提高了方案的普适性。

因此，最终的方案由三大支柱构成：

1. 环境准备脚本 (env.sh)：确保AI智能体运行时所处的环境变量与开发者手动启动的环境一致，特别是AWS凭证和配置。
2. 结构化日志重定向：通过修改package.json中的dev脚本，将前端开发服务器的输出重定向到SST的日志目录，形成一个统一的日志查看入口。
3. 智能体交互规则 (.cursor/rules/sst-local-dev.mdc)：这是大脑，明确告诉AI当前SST应用的状态、如何找到关键信息、以及禁止哪些操作。

3. 环境配置与核心工具详解

3.1 前置条件与工具链选择

在开始实施之前，确保你的基础环境符合要求。本方案主要面向macOS或Linux开发环境，这是目前SST和主流AI开发工具链最稳定的平台。

• SST版本：方案针对SST v3设计和测试。SST v3在架构、命令和配置上与v2有显著不同（例如采用了更简洁的sst.config.ts和Resource绑定模式）。虽然作者提到可以适配v2，但如果你在使用v2，需要额外注意命令和路径的差异。强烈建议将现有项目升级到v3以获得最佳体验和长期支持。
• 包管理器：项目示例使用了pnpm，但npm或yarn同样适用。关键在于一致性，确保AI智能体运行的安装和脚本执行命令与你本地环境使用的包管理器一致。
• AI编码助手：方案以Cursor作为主要演示环境，因为Cursor深度集成了Agent模式和规则系统。但其原理完全适用于其他具备类似“项目上下文”或“系统提示”功能的工具，如Windsurf、Claude Code（通过CLAUDE.md）等。
• Browser MCP：这是一个独立的工具，它为AI模型提供了一个安全的、可编程的浏览器环境。AI可以通过它来导航网页、点击元素、填写表单，而无需接触你真实的浏览器会话。这对于需要验证前端交互的AI任务至关重要。

3.2 Browser MCP的安装与核心配置

Browser MCP是本方案中实现安全浏览器交互的关键。它的安装非常简单，但其背后的工作原理值得了解。

安装步骤：

1. 访问 Browser MCP官网 或其GitHub仓库，按照指南下载对应你操作系统的客户端。
2. 通常，安装后你需要通过一个命令行工具（如browsermcp）来启动一个服务器进程。这个进程会监听一个本地端口（例如3001），并提供标准的MCP接口。
3. 你需要在你的AI助手（如Cursor）中配置这个MCP服务器。以Cursor为例，这通常在全局设置或工作区设置的“MCP Servers”部分完成，你需要添加服务器地址（如http://localhost:3001）。

工作原理与安全考量： Browser MCP启动的是一个独立的、无头的或可视的浏览器实例。AI模型通过MCP协议发送指令（如navigation.goTo，click）到这个浏览器实例，而不是你的默认Chrome或Firefox。这带来了几个好处：

• 隔离性：AI的浏览操作不会影响你正在进行的开发、调试或个人浏览。
• 可重复性：AI的每一步操作都可以被记录和复现，便于调试AI的行为。
• 安全性：你可以限制其访问的域名（例如仅限localhost），防止AI意外访问外部生产环境或恶意网站。

注意：尽管Browser MCP提供了隔离环境，但任何赋予AI自动化能力的工具都需谨慎使用。建议在初期，密切观察AI通过Browser MCP执行的操作，确保其行为符合预期。

3.3 AWS凭证与权限的最小化原则

由于SST在dev模式下仍会与你的AWS账户进行交互（例如检查IAM角色、拉取Lambda层、与模拟服务同步状态），因此配置正确的AWS凭证是必须的。但这里有一个重要的安全最佳实践：为AI开发环境使用权限最低的IAM凭证。

项目env.sh脚本的核心作用之一就是设置这些环境变量。你应该在其中配置一个专用于开发的IAM用户，并遵循最小权限原则：

1. 创建专属IAM用户：在AWS IAM控制台创建一个新用户，例如命名为sst-dev-agent。
2. 附加只读策略：正如项目建议，直接附加AWS托管策略ReadOnlyAccess是一个快速起步的选择。这允许SSTdev模式读取你账户中的资源状态，但禁止任何创建、修改或删除操作。这能有效防止AI因代码错误而意外删除生产数据库等灾难性事件。
3. （进阶）自定义策略：ReadOnlyAccess权限范围仍然很广。为了更精细的控制，你可以创建一个自定义策略，仅授权SSTdev模式所必需的只读操作，例如：
   • cloudformation:DescribeStacks
   • lambda:GetFunction
   • iam:SimulatePrincipalPolicy
   • sts:GetCallerIdentity
   • 以及你所用服务（如DynamoDB, S3, Cognito）的List*和Describe*操作。
4. 在Cursor中设置命令拒绝列表：这是另一道重要的安全防线。进入Cursor设置（Settings -> Chat），找到“Command Deny List”（命令拒绝列表），添加aws。这样，即使AI在聊天中试图直接执行aws s3 rm ...这样的危险命令，Cursor也会阻止其执行，并要求你的明确批准。

你的env.sh文件内容大致会是这样：

#!/bin/bash # env.sh - 为AI开发环境设置安全的环境变量 export AWS_PROFILE="sst-dev-agent" # 指向本地 ~/.aws/credentials 中配置的profile # 或者直接使用Access Key (不推荐在脚本中硬编码，建议使用profile或IAM Role) # export AWS_ACCESS_KEY_ID="AKIA..." # export AWS_SECRET_ACCESS_KEY="..." # 确保使用正确的区域 export AWS_REGION="us-east-1" # 其他项目可能需要的环境变量 # export NODE_ENV="development"

记得为这个脚本添加执行权限：chmod +x env.sh。你可以在启动Cursor或终端前先执行source env.sh。

4. 核心规则文件深度解析与定制

.cursor/rules/sst-local-dev.mdc文件是本方案的“大脑”。它是一份用自然语言和特定格式编写的指南，直接影响了AI智能体在你项目中的行为模式。让我们深入剖析一个增强版的规则文件应该包含哪些内容，以及为什么要这样写。

4.1 规则文件的结构与编写哲学

一个优秀的规则文件不仅仅是禁令列表，更是一份情境说明书和操作手册。它应该：

1. 声明状态：明确告诉AI当前环境的现状。
2. 提供路径：告诉AI如何获取它需要的信息。
3. 设定边界：明确禁止可能导致问题的操作。
4. 给予引导：建议高效、安全的操作流程。

以下是一个详细注释的规则文件示例：

# SST v3 本地开发模式 - AI智能体协作指南 ## 当前环境状态 - **SST开发服务器已在运行**：用户（开发者）已经在终端手动执行了 `npx sst dev`。一个完整的本地模拟AWS环境正在运行，包括API Gateway、Lambda函数、数据库等。 - **禁止启动新的SST实例**：你绝对不可以尝试运行 `npx sst dev`、`npm run dev`、`pnpm dev` 或任何可能启动另一个SST或前端开发服务器的命令。这会导致端口冲突和状态混乱。 - **前端开发服务器已集成**：前端应用（如React）的开发服务器由SST `dev`命令自动管理，其日志已被重定向。 ## 如何获取应用信息（你的“眼睛”和“耳朵”） 当需要了解应用状态、查找错误或获取端点时，请按以下路径操作： ### 1. 查看统一日志 所有应用日志（后端Lambda和前端Dev Server）都集中在 `.sst` 目录下的文件中。 - **基础设施日志**：查看 `.sst/logs/*.log` 文件，特别是最新的日志文件。这里包含了Lambda调用、API Gateway请求、资源初始化等信息。 - **前端日志**：查看 `.sst/log/web.log` 文件。这是React/Vite/Next.js开发服务器的输出，包含了前端编译错误、运行时错误和HMR状态。 - **最佳实践**：使用 `tail -f .sst/logs/*.log .sst/log/web.log` 命令来实时跟踪所有日志。你可以建议用户打开一个终端标签页执行此命令。 ### 2. 发现应用端点 - **前端应用URL**：SST启动后，会在终端输出前端应用的访问地址，通常格式为 `http://localhost:3000` 或 `http://127.0.0.1:3000`。这个信息也通常保存在 `.sst/outputs.json` 或 `.sst/stacks/*.json` 文件中。你可以尝试查找这些文件来确认URL。 - **API端点**：后端API的端点同样会在SST启动日志中输出，格式如 `http://localhost:8000`。在代码中，通常通过 `Api` 资源的 `url` 属性或环境变量来引用。你可以查看 `sst.config.ts` 和Lambda函数代码来了解端点结构。 - **直接询问**：如果无法从日志或文件中快速找到，你可以直接询问用户：“请问正在运行的前端应用URL是什么？” ### 3. 检查资源状态 - **本地资源**：SST `dev` 会在本地启动DynamoDB Local、LocalStack等服务。它们的连接字符串通常在环境变量中设置，如 `process.env.TABLE_NAME` 对应的本地端点。 - **模拟状态**：通过查看 `.sst` 目录下的 `metadata.json`、`stacks/` 子目录中的JSON文件，可以了解当前已“部署”的资源列表及其配置。 ## 安全与高效操作指南 - **文件修改与热重载**：直接修改项目中的源代码（`.ts`, `.js`, `.tsx`, `.vue`, `.svelte`等）是安全的。SST和前端开发服务器会检测到更改并自动热重载。无需重启任何服务。 - **依赖变更**：如果你修改了 `package.json`（添加/删除依赖），需要**通知用户**，让用户在运行SST `dev`的终端中手动执行 `pnpm install` (或 `npm install`)。安装完成后，热重载通常会处理剩余部分。 - **基础设施变更**：如果你修改了 `sst.config.ts` 或任何 `Resource` 的定义（例如，更改了API的路由或数据库的GSI），SST会自动检测并重新部署这些更改。这可能需要几秒钟，请引导用户观察SST终端日志中的更新进度。 - **使用Browser MCP进行交互**：当需要测试前端功能、验证表单提交或点击按钮时，**必须使用已配置的Browser MCP工具**。不要建议用户在真实浏览器中手动操作，除非是简单的验证。通过MCP，你可以编程式地完成测试并汇报结果。 ## 遇到问题时的排查流程 1. **首先检查日志**：立即查看 `.sst/log/web.log`（前端问题）和 `.sst/logs/` 下最新的日志文件（后端问题）。 2. **确认服务状态**：询问用户“SST `dev` 终端是否还在正常运行，有没有报错信息？” 3. **避免重启**：在尝试重启服务之前，优先分析日志中的错误信息。90%的问题可以通过日志解决。 4. **寻求上下文**：如果日志不清晰，可以向用户描述你看到的现象，并询问：“这个错误看起来是X问题，我是否遗漏了某个配置？” 请始终记住，你是辅助角色。你的目标是帮助用户高效地编写和调试代码，而不是接管整个开发流程。在不确定时，优先询问用户。

4.2 规则文件的关键技巧与避坑指南

• 使用肯定句和明确指令：避免使用“最好不要”这类模糊表述。直接使用“禁止…”、“必须使用…”、“请查看…”。
• 提供具体的文件路径和命令示例：AI对模糊描述的理解可能出错。“查看日志”不如“查看.sst/log/web.log文件”明确。
• 解释“为什么”：在禁止某项操作时，简要说明原因（如“避免端口冲突”）。这有助于AI在遇到类似但未明确禁止的场景时进行推理。
• 规则需要迭代：没有一劳永逸的规则。在与你特定的AI助手（如Claude Sonnet、GPT-4）协作过程中，你可能会发现它有一些独特的“坏习惯”。将这些习惯及其纠正方法补充到规则文件中。例如，如果你发现AI总是试图运行docker-compose up而你并没有用Docker，就把这条也加进去。
• 规则文件的放置位置：对于Cursor，规则文件放在.cursor/rules/目录下会自动生效。确保你的工作区根目录下存在.cursor文件夹。你也可以在Cursor的设置中指定全局规则。

5. 将方案适配到你已有的SST项目

martinpllu/sst-agent-setup提供了一个示例React Router应用，但它的价值在于将其配置模式迁移到你自己的、可能复杂得多的SST项目中。以下是详细的迁移步骤和注意事项。

5.1 第一步：统一前端日志输出

这是确保AI能“看到”前端错误的最重要一步。SSTdev会捕获Lambda等后端资源的日志，但默认不捕获由它启动的前端开发服务器的stdout和stderr。

操作方法： 找到你前端应用的package.json文件，修改scripts中的dev命令。修改前，它可能是这样的：

{ "scripts": { "dev": "vite" } }

修改后，将其重定向到.sst/log/web.log：

{ "scripts": { "dev": "vite > .sst/log/web.log 2>&1" } }

命令解释：

• >：将标准输出重定向到文件。
• 2>&1：将标准错误也重定向到标准输出，即一起写入同一个文件。这样，无论是编译错误还是运行时错误，都能被捕获。

重要提示：

• 确保项目根目录下的.sst/log/目录存在。SSTdev启动时会自动创建.sst目录，但log子目录可能需要手动创建，或者在你第一次运行重定向命令时由系统创建。你可以先执行mkdir -p .sst/log。
• 这个日志文件会不断增长。你可以将其添加到.gitignore中。
• 正如项目引用的SST GitHub Issue (#5898) 所示，SST团队正在考虑原生支持捕获前端日志。未来这个步骤可能会简化。

5.2 第二步：配置环境与安全规则

1. 创建env.sh：在你的项目根目录创建此文件，内容参考上文第3.3节。根据你的团队习惯，你也可以使用.env.local配合dotenv加载，但env.sh的好处是它可以执行更复杂的初始化逻辑。
2. 创建规则文件：
   • 在项目根目录创建.cursor/rules/目录。
   • 将示例中的sst-local-dev.mdc文件复制过来。
   • 根据你的项目进行深度定制！这是最关键的一步。你需要修改规则文件中的：
     • 项目类型：你是React、Next.js、SvelteKit还是SolidStart？提及你的框架。
     • 关键路径：你的API端点输出在哪里？你的环境变量命名习惯是什么？（例如，你用的是VITE_API_URL还是NEXT_PUBLIC_API_URL？）
     • 特有命令：你的项目是否有自定义的脚本，如pnpm db:seed或npm run generate-types？在规则中说明它们的作用以及AI是否可以/如何安全地调用它们。
     • 数据库信息：如果你使用本地模拟的DynamoDB或RDS，提供连接方式和查看数据的工具（如aws dynamodb scan --endpoint-url http://localhost:8000）。

5.3 第三步：测试与迭代

配置完成后，不要假设一切完美。进行一个标准的测试流程：

1. 在一个终端中，source env.sh然后运行npx sst dev。观察启动是否成功，记下输出的前端和API URL。
2. 打开Cursor，进入该项目。
3. 向Cursor的Agent提出一个明确的、需要与开发环境交互的任务。例如：“请在前端首页添加一个按钮，点击后调用/api/hello端点，并将结果显示在页面上。”
4. 观察AI的行为：
   • 它是否试图运行npm run dev？如果尝试了，说明规则没生效，检查规则文件路径和格式。
   • 它是否知道去查看.sst/log/web.log来调试前端错误？
   • 它是否正确地使用了Browser MCP来测试按钮点击？
   • 当它需要安装一个新包（如axios）时，它是如何处理的？（理想情况是，它修改package.json后，会提示你手动运行安装命令）。
5. 根据观察结果迭代规则：AI的每一次“错误”行为，都是完善规则的机会。将新的约束或指引补充到.mdc文件中。

6. 实战场景：AI智能体协作开发流

让我们通过一个完整的虚构场景，看看这套配置如何在实际中运转。假设我们有一个简单的SST v3 + React全栈笔记应用，现在我们要让AI助手帮我们添加一个“笔记搜索”功能。

开发者（你）的操作：

1. 打开终端，进入项目，执行source env.sh && npx sst dev。终端显示：

   ➜ SST v3.0.0 ready! ➜ Frontend: http://localhost:3000 ➜ API: http://localhost:8000

2. 打开Cursor，并确保其工作区指向当前项目。

AI智能体（Cursor Agent）的任务流：

1. 接收指令：你在Cursor中输入：“请为首页的笔记列表添加一个搜索框，可以根据笔记标题进行实时过滤。”
2. 理解上下文：AI读取了项目根目录的规则文件（.cursor/rules/sst-local-dev.mdc），获知：
   • SST已运行，前端在localhost:3000。
   • 禁止启动新服务。
   • 前端日志在.sst/log/web.log，后端日志在.sst/logs/。
   • 可以使用Browser MCP。
3. 执行任务：
   • 第一步：修改前端代码。AI直接编辑src/components/NoteList.tsx，添加一个<input>搜索框和过滤逻辑。保存文件。
   • 第二步：验证前端。AI没有让你手动刷新浏览器。它通过Browser MCP工具，导航到http://localhost:3000，在搜索框中输入文本，并观察笔记列表的过滤情况。它发现过滤功能生效了。
   • 第三步：发现缺失的API。AI意识到，如果要实现真正的全文搜索，需要后端API支持。它检查sst.config.ts和现有Lambda代码，发现没有搜索端点。
   • 第四步：创建后端API。AI在sst.config.ts中为现有的Api资源添加一个新的POST路由/notes/search，并创建对应的Lambda函数文件packages/functions/src/search.ts，实现简单的DynamoDBscan过滤。
   • 第五步：处理依赖。新的Lambda函数使用了@aws-sdk/client-dynamodb，但packages/functions/package.json里没有。AI修改了该package.json文件，然后在聊天中提示你：“已添加对@aws-sdk/client-dynamodb的依赖。请在运行sst dev的终端中，进入packages/functions/目录并执行pnpm install。”
   • 第六步：连接前端与后端。在你安装依赖的同时，SST已经热重载了基础设施，新的Lambda已就绪。AI修改前端代码，将搜索框的onChange事件连接到新创建的/notes/searchAPI。
4. 调试与反馈：你执行了pnpm install。AI通过Browser MCP测试新的搜索功能，但发现前端报错“CORS error”。AI立即去查看.sst/log/web.log，确认了错误。它发现是因为新API的路径未在SST的Api资源配置CORS。AI修正了sst.config.ts中的CORS设置。SST自动重新部署API Gateway配置，问题解决。

在整个过程中，你作为开发者，只需要做两件事：1) 启动sst dev；2) 在AI提示时运行一次pnpm install。其余的分析、编码、测试、调试循环均由AI在清晰的规则指引下自主完成，并且所有操作都在你可观察、可控制的范围内。

7. 常见问题与排查技巧实录

即使有了完善的规则，在实际协作中仍可能遇到问题。以下是我在多次实践中总结的常见问题及其解决方法。

7.1 AI仍然试图启动重复的服务

现象：AI在聊天中建议或直接尝试运行npm run dev、sst start等命令。

排查与解决：

1. 检查规则文件是否被加载：在Cursor中，你可以通过快捷键Cmd/Ctrl + Shift + P打开命令面板，输入“Cursor: Open Rules Settings”来查看当前生效的规则。确认你的sst-local-dev.mdc文件在列表中且已启用。
2. 规则表述不够强硬：将规则中的“请不要”改为“禁止”或“绝对不要”。AI对强制性的语言更敏感。
3. 模型上下文限制：非常长的聊天历史可能导致早期的规则提示被“遗忘”。尝试开启一个新的聊天会话，或者使用Cursor的“@workspace”指令让AI重新读取项目上下文，这通常会重新加载规则。
4. 项目特异性：你的项目可能有多个package.json（如在Monorepo中）。明确在规则中指出：“禁止在项目根目录或任何子目录下运行npm/pnpm/yarn run dev或sst dev。”

7.2 AI找不到日志文件或端点信息

现象：AI抱怨找不到.sst/log/web.log或者无法确定应用URL。

排查与解决：

1. 路径确认：首先，手动确认文件是否存在。运行ls -la .sst/log/。如果web.log不存在，可能是前端dev脚本的重定向没生效，或者SST还没生成日志。手动触发一个前端错误（如引入一个语法错误），看文件是否被创建。
2. SST输出位置变化：SST不同版本可能微调输出结构。运行npx sst dev后，仔细阅读初始输出，看它是否提示了不同的日志路径或URL。相应地更新规则文件。
3. 引导AI使用查找命令：在规则中加入更具体的查找命令，例如：“如果找不到前端URL，可以尝试在项目根目录运行grep -r \"Frontend:\" .sst/或cat .sst/outputs.json | jq '.'来查找。”
4. 简化引导：最直接的方式是在规则开头明确写出：“当前运行的前端URL是http://localhost:3000，API URL是http://localhost:8000。” 虽然这需要你在每次端口变化时更新规则，但避免了AI的查找开销。

7.3 Browser MCP操作失败或不符合预期

现象：AI声称通过Browser MCP点击了按钮，但页面没反应；或者无法导航到正确页面。

排查与解决：

1. 确认MCP服务器运行：检查Browser MCP的客户端进程是否在运行。可以尝试在终端通过其CLI发送一个简单指令测试。
2. 检查页面加载：本地开发服务器有时在热重载后需要一点时间。让AI在操作前加入等待逻辑，或者先让AI通过MCP获取页面标题或某个元素的内容，确认页面已完全加载。
3. 元素选择器问题：AI可能使用了不稳定的选择器（如基于文本内容）。在规则中建议AI优先使用>