当前位置：首页 > news >正文

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

news 2026/5/8 11:08:49

1. 项目概述：为AI智能体优化SST本地开发环境

如果你和我一样，正在深度使用Cursor、Claude Code这类AI编程助手来构建基于SST（Serverless Stack）的全栈应用，那你很可能也遇到过同样的困境：AI写代码很猛，但一到本地开发调试环节就容易“卡壳”。我最近在重构一个中型项目时，让AI助手基于SST添加用户认证和数据库模块，结果它反复尝试自己启动sst dev，导致端口冲突；或者修改了Lambda函数后，它无法确认部署是否成功，因为看不到实时日志；更常见的是，AI对当前运行中的本地端点（比如前端React应用的localhost:3000）状态一无所知，做出一些基于错误假设的修改。

这正是sst-agent-setup这个项目要解决的核心痛点。它不是一个新框架，而是一套经过实战打磨的“环境配置”与“协作规则”，旨在让AI智能体（Agent）能够顺畅地与SST的本地开发模式（sst dev）协同工作。其核心思想非常明确：开发者作为“指挥官”手动启动并监控sst dev，而AI作为“执行者”在这个已知、稳定的环境中进行代码编写和问题修复。这套方案通过简单的日志重定向、环境变量管理和一组清晰的规则（Rules），将SST本地开发的状态“暴露”给AI，极大提升了在长周期、多步骤的智能体工作流（Agentic Loop）中的开发效率。

简单来说，它让AI从“盲人摸象”变成了“心中有图”。接下来，我会详细拆解这套方案的每一个组成部分，分享如何将其适配到你自己的SST项目中，并附上我在实际整合过程中踩过的坑和总结出的技巧。

2. 核心设计思路：为何是“规则”而非“MCP服务器”？

在深入实操之前，有必要先理解这个项目背后一个关键的技术选型决策：为什么选择了基于文本规则（Rules）的方案，而不是构建一个功能更强大的MCP（Model Context Protocol）服务器？

2.1 MCP服务器方案的探索与局限

最初，我和许多开发者想的一样，认为一个专用的MCP服务器是最优雅的解决方案。我确实动手实现了一个原型，主要尝试了两种路径：

WebSocket连接模式：让MCP服务器通过SST Dev的WebSocket接口连接到正在运行的sst dev进程，实时获取日志流和应用状态。理论上这能提供最丰富、最实时的上下文。
子进程托管模式：在MCP服务器内部直接使用child_process启动sst dev --mode=mono，并捕获其stdio（标准输入输出流），然后将这些信息通过MCP工具（Tools）暴露给AI模型。

这两种方式我都在测试项目中实现了，但最终都放弃了。原因在于它们引入了显著的复杂性：

状态管理负担：MCP服务器需要维护与SST进程的连接状态，处理连接中断、重连、进程异常退出等问题。这本身就是一个潜在的故障点。
资源与权限问题：让AI通过MCP间接控制一个可能涉及AWS资源部署的进程，存在安全风险。虽然可以加权限控制，但复杂度上升。
适配成本高：每个开发者的SST项目结构、依赖、甚至sst dev的启动参数都可能不同。一个通用的MCP服务器很难做到开箱即用，往往需要用户进行额外配置。

2.2 规则（Rules）方案的优势与哲学

相比之下，基于规则的方案体现了“简单即美”的工程哲学：

关注点分离：开发者负责启动并观察sst dev——这是你最擅长也最需要掌控的部分。AI则专注于在你提供的“沙箱环境”内进行代码创作。权责清晰，互不干扰。
零额外开销：规则是纯文本文件（如.cursor/rules/*.mdc），被AI客户端读取。它不运行任何额外服务进程，不占用端口，几乎无性能损耗。
极致透明与可调试：所有交互都发生在你的终端（sst dev日志）和AI的聊天界面中。你可以清晰地看到AI基于哪些信息做出了决策，整个过程是可观测、可追溯的。
高度可定制：规则文件就是Markdown，你可以根据自己项目的特殊需求，轻松增删改查提示词。比如，如果你的项目使用了特殊的数据库连接字符串格式，你可以直接在规则里写明如何解析它。

我的实操心得：在追求自动化的过程中，我们常常会陷入“为自动化而自动化”的陷阱，试图用一套复杂的系统去解决一个本质上很简单的问题。sst-agent-setup的方案提醒我们，有时最高效的“人机协作”模式，不是让机器完全接管，而是通过清晰的规则和接口，让两者在各自擅长的领域发挥最大效能。你作为开发者，对系统整体状态和业务逻辑的把握是AI目前无法替代的；而AI在快速生成代码片段、查找API文档、修复简单bug方面的能力又是人类难以匹敌的。这套方案恰好平衡了二者。

3. 环境配置与核心组件解析

理解了设计思路，我们来看具体怎么搭建。这套配置主要包含三个核心部分：日志重定向、环境准备脚本、以及给AI的规则文件。

3.1 日志重定向：让AI“看见”控制台

这是整个 setup 中最关键的一步。SST Dev 模式本身会将基础设施（如 Lambda、API Gateway）的日志输出到终端，但对于本地运行的前端服务（如通过sst dev启动的 Next.js 或 React 开发服务器），其日志默认只打印到启动它的那个终端，而不会被 SST 统一捕获到文件。

这就导致了一个问题：AI 智能体无法通过读取日志文件来知晓前端服务的编译状态、热更新是否成功、或者是否发生了运行时错误。为了解决这个问题，我们需要手动将前端服务的输出重定向到一个固定的日志文件中。

操作步骤与原理：假设你的 SST 项目中，前端部分位于packages/web，使用npm run dev启动。你需要修改packages/web/package.json中的dev脚本：

// 修改前 "scripts": { "dev": "vite" } // 修改后 "scripts": { "dev": "vite > ../../.sst/logs/web.log 2>&1" }

命令拆解：

vite: 启动开发服务器的原命令。
>: 重定向操作符，将命令的标准输出（stdout）写入指定文件。
../../.sst/logs/web.log: 指定日志文件路径。这里向上两级目录回到项目根目录，然后指向.sst/logs/文件夹。选择这个位置是因为它是 SST 运行时的工作目录，相关且容易定位。
2>&1: 这是一个关键部分。2代表标准错误流（stderr），1代表标准输出流（stdout）。2>&1表示“将标准错误流重定向到标准输出流所指向的地方”。这样，无论是正常日志还是错误信息，都会一并写入web.log文件。

重要注意事项：重定向操作>会覆盖目标文件。如果你需要追加日志，应使用>>。但在开发场景下，每次重启 dev server 时覆盖旧日志通常是更清晰的选择。另外，确保.sst/logs/目录存在，如果不存在，SST 会在首次运行时创建它，但你也可以手动mkdir -p .sst/logs。

3.2 环境准备脚本 (`env.sh`)

这个脚本的目的是为你的 AI 助手会话提供一个干净、一致的上下文环境。它通常包含项目相关的环境变量。

一个典型的env.sh内容：

#!/bin/bash # sst-agent-setup 环境变量 export SST_APP_NAME="my-sst-app" export SST_STAGE="dev" export LOCAL_FRONTEND_URL="http://localhost:3000" export LOCAL_API_URL="http://localhost:8000" export LOG_FILE_PATH="$PWD/.sst/logs" # 提示：AWS凭证通常由 SST 自动管理，不建议在此导出敏感信息。

如何使用：

将env.sh文件放在项目根目录。
在启动你的 AI 助手（如 Cursor）之前，在终端中执行source env.sh。这会使得这些环境变量在当前 shell 会话中生效。
当你在这个终端中启动 Cursor 或配置 IDE 终端时，AI 助手就能感知到这些变量。

为什么需要它？AI 模型在分析代码和问题时，如果它能明确知道当前的应用名称、开发阶段（stage）以及本地服务的访问地址，它给出的建议会精准得多。例如，当它需要构造一个 API 调用时，它可以直接使用$LOCAL_API_URL/users，而不是猜测或硬编码一个可能错误的地址。

3.3 AI 规则文件 (`.cursor/rules/sst-local-dev.mdc`)

这是指导 AI 行为的“宪法”。规则文件使用特定的格式（通常是 Markdown 或类似格式），定义了 AI 在项目中应该知道什么、如何操作。

让我们剖析一个核心规则片段，并理解其设计逻辑：

## SST Local Development Context **You are working within a Serverless Stack (SST) application that is currently running in local development mode (`sst dev`).** ### Key Principles - The human developer has already run `npx sst dev` in a terminal. **DO NOT** attempt to start another instance. - All infrastructure (Lambda, API Gateway, DynamoDB Local, etc.) and the local web server are managed by that single `sst dev` process. - Your goal is to write and fix code that integrates seamlessly with this running environment. ### How to Discover State 1. **Logs**: Application and infrastructure logs are being written to the `.sst/logs/` directory. - The main SST process log is at `.sst/logs/sst.log`. - The local web app (e.g., React) log is at `.sst/logs/web.log` (if configured). - To check if the app is running, you can suggest the user to `tail -f .sst/logs/sst.log` or look for recent entries. 2. **Endpoints**: The running application exposes local endpoints. - The frontend is typically at `http://localhost:3000`. - The backend API Gateway endpoints are printed in the terminal after `sst dev` starts and are also logged. They follow the pattern `http://localhost:8000/{api-path}`. 3. **Process Status**: If you need to verify if `sst dev` is running, you can ask the user to check their terminal, or suggest running `ps aux | grep sst`. ### Your Interaction Guidelines - When making changes to infrastructure (e.g., `sst.config.ts`) or function code, you can inform the user that SST's hot reload will automatically update the running dev environment. - After suggesting a change, you can prompt the user to check the relevant log file for errors or success messages. - If you suspect the dev server might be in a bad state, you can suggest the user to **restart** the `sst dev` process in their terminal (Ctrl+C, then re-run `npx sst dev`). Do not attempt to kill processes programmatically.

规则设计的精妙之处：

明确边界：开篇就强调“人类已启动sst dev”，禁止AI重复启动。这直接避免了端口冲突和资源浪费。
提供发现路径：不是直接告诉AI所有状态，而是教它“如何自己去发现”。例如，告诉它日志在哪里、端点URL的通常模式是什么。这比硬编码信息更灵活，也培养了AI根据上下文推理的能力。
定义安全交互模式：所有可能影响外部状态的操作（如重启服务），都设计为“建议用户执行”，而非AI直接执行。这保证了控制权始终在开发者手中，符合安全最小化原则。

4. 完整集成到现有SST项目的实操流程

假设你已有一个正在开发的SST v3项目（例如，一个包含React前端和若干Lambda后端的全栈应用），现在你想将这套agent-setup集成进去，以下是步步为营的操作指南。

4.1 第一步：前置检查与项目准备

首先，确认你的项目状态：

确保你的项目基于SST v3。检查package.json中sst的版本号。v2和v3在架构和配置上差异较大，本方案主要针对v3优化。
确保你的sst dev可以正常运行，能够成功启动本地模拟的AWS服务和前端应用。
确定你使用的AI开发工具。本指南以Cursor为例，但原理同样适用于 Claude Code（使用CLAUDE.md）或其它支持自定义规则的IDE/编辑器。

4.2 第二步：配置前端日志重定向

进入你前端包所在的目录（例如packages/frontend）。

打开package.json。
找到启动开发服务器的脚本（通常是"dev": "vite"、"dev": "next dev"或"dev": "react-scripts start"）。
将其修改为重定向模式。你需要找到正确的日志路径。由于SST在项目根目录的.sst文件夹下运行，从前端包目录到根目录的相对路径可能是../../。
对于 Vite (React/Vue) 项目：
```
"scripts": { "dev": "vite --port 3000 > ../../.sst/logs/web.log 2>&1", // ... 其他脚本 }
```
对于 Next.js 项目：
```
"scripts": { "dev": "next dev -p 3000 > ../../.sst/logs/web.log 2>&1", // ... 其他脚本 }
```
注意：这里显式指定了--port 3000或-p 3000是为了确保端口固定，方便在规则中引用。如果你的SST配置已经指定了前端端口，请与之保持一致。
测试：在项目根目录运行npx sst dev。等待启动完成后，打开另一个终端，执行tail -f .sst/logs/web.log。你应该能看到前端服务器的实时日志输出。刷新浏览器页面，应该能看到对应的请求日志。这证明重定向成功。

4.3 第三步：创建环境变量脚本

在项目根目录创建env.sh文件。

#!/bin/bash # Project: Your Awesome SST App # Description: Environment variables for AI-assisted development # 项目标识 export PROJECT_NAME="my-sst-app" export SST_STAGE="dev" # 通常与 `sst dev` 的 stage 一致 # 本地服务端点 - 请根据你的 sst.config.ts 和前端配置调整 export LOCAL_WEB_URL="http://localhost:3000" # API Gateway 的本地端点通常是 8000 端口，路径前缀在 config 中定义 export LOCAL_API_BASE="http://localhost:8000" # 路径常量 export SST_LOGS_DIR="$PWD/.sst/logs" export SST_LOG_FILE="$SST_LOGS_DIR/sst.log" export WEB_LOG_FILE="$SST_LOGS_DIR/web.log" echo "Environment set for $PROJECT_NAME ($SST_STAGE)." echo "- Web: $LOCAL_WEB_URL" echo "- API: $LOCAL_API_BASE" echo "- Logs: $SST_LOGS_DIR"

赋予执行权限并 source 它：

chmod +x env.sh source ./env.sh

此时，在终端输入echo $LOCAL_WEB_URL应该能正确输出地址。

4.4 第四步：设置Cursor规则

Cursor的规则文件存放在项目根目录下的.cursor/rules文件夹中。

创建目录和文件：

mkdir -p .cursor/rules touch .cursor/rules/sst-local-dev.mdc

将sst-agent-setup项目中的规则内容复制过来，并根据你的env.sh进行个性化调整。重点是更新端点URL和日志路径，使其引用你定义的环境变量。

## SST本地开发协作规则 **核心前提**：开发者已在终端运行 `npx sst dev`。你（AI）必须在此现有环境中工作，切勿尝试启动新的`sst dev`、`npm run dev`或任何可能冲突的服务进程。 ### 环境上下文 - **项目名称**: `{{PROJECT_NAME}}` (对应环境变量 `$PROJECT_NAME`) - **开发阶段**: `{{SST_STAGE}}` (对应 `$SST_STAGE`) - **前端地址**: `{{LOCAL_WEB_URL}}` (对应 `$LOCAL_WEB_URL`) - **API网关地址**: `{{LOCAL_API_BASE}}` (对应 `$LOCAL_API_BASE`) - **日志目录**: `{{SST_LOGS_DIR}}` (对应 `$SST_LOGS_DIR`) ### 如何获取系统状态？ 1. **检查服务是否运行**：请用户查看运行 `sst dev` 的终端，或使用 `tail -f {{SST_LOG_FILE}}` 查看最新日志。 2. **查看前端编译/错误**：日志位于 `{{WEB_LOG_FILE}}`。当用户修改前端代码后，可建议其 `tail -f` 此文件以确认热更新是否成功或是否有编译错误。 3. **验证API端点**：本地API端点格式通常为 `{{LOCAL_API_BASE}}/your-api-path`。具体的端点路径可在 `sst.config.ts` 中定义的栈（Stack）输出中找到，也会在 `sst dev` 启动时打印在终端。 ### 你的行动指南 - **代码修改后**：告知用户SST的热重载功能会自动处理基础设施和函数的更新。建议他们稍等片刻，然后刷新前端页面或调用API进行测试。 - **遇到错误时**： - 首先，建议用户检查相关的日志文件（`sst.log` 对应Lambda/资源错误，`web.log` 对应前端错误）。 - 根据日志错误信息，提供具体的修复建议。 - **需要重启时**：如果怀疑开发环境状态异常（如端口占用、内存泄漏），**请建议用户在终端中手动重启**（按 Ctrl+C 停止 `sst dev`，然后重新运行 `npx sst dev`）。你绝不应当直接执行重启命令。 - **关于AWS操作**：在 `sst dev` 模式下，所有对DynamoDB、S3等资源的本地调用都是模拟的。如果用户需要执行真实的AWS CLI命令（如查询生产数据库），这必须由用户明确批准后在终端执行。切勿擅自执行 `aws` 命令。

注意：上述规则中使用了{{VARIABLE}}占位符，但请注意，Cursor规则文件本身不支持动态变量替换。这些占位符是写给你看的，用于说明这里应该填写什么。你需要手动将它们替换为env.sh中定义的实际值，或者直接写成明确的路径和URL。更常见的做法是，在规则中直接写入你项目的固定值，因为对于同一个项目，这些值很少变动。

4.5 第五步：集成Browser MCP（可选但推荐）

Browser MCP 是一个让AI模型能够控制浏览器进行自动化操作的协议服务器。在这个上下文中，它非常有用，因为AI可以直接打开前端页面、点击按钮、填写表单，从而进行端到端的功能测试，而不仅仅是看代码。

安装：按照 Browser MCP 官方文档进行安装。通常是一个全局npm包或可执行文件。
启动：在另一个终端标签页中运行 Browser MCP 服务器。命令类似browser-mcp或npx @modelcontextprotocol/server-browser。
配置Cursor：在Cursor的设置中，找到MCP服务器配置（Settings -> MCP Servers），添加Browser MCP服务器的连接信息（通常是WebSocket地址，如ws://localhost:3001）。

更新规则：在你的sst-local-dev.mdc规则文件中，可以添加一节关于Browser MCP的说明：

### 浏览器自动化 (通过Browser MCP) - 你可以使用集成的Browser MCP工具来操控运行在 `{{LOCAL_WEB_URL}}` 的网页。 - 这对于测试UI交互、验证表单提交、或截图确认页面状态非常有用。 - 在操作前，可以先询问用户：“需要我打开前端页面进行测试吗？”

完成以上五步后，你的SST项目就具备了与AI智能体高效协作的基础设施。接下来，让我们看看在实际编码会话中，这套组合拳如何发挥威力。

5. 实战演练：一个完整的AI协作开发场景

假设我们正在开发一个简单的“待办事项”应用，前端是React，后端API使用SST的Api和Function构造，数据存储在DynamoDB本地表中。

初始状态：你已经运行了source env.sh和npx sst dev。前端在http://localhost:3000运行，API在http://localhost:8000运行。你打开了Cursor，它已经加载了当前项目和你刚配置的规则。

任务：你告诉Cursor：“当前的任务列表页面，我想在每个任务项后面添加一个‘标记为重要’的按钮。点击后，这个任务应该在DynamoDB里被更新，important字段设为true。前端也需要高亮显示重要任务。”

让我们模拟一下一个“训练有素”的AI助手会如何行动：

理解上下文与约束：AI首先读取规则，知道sst dev已在运行，前端和API端点地址明确，日志文件位置清楚。它不会提议去启动任何服务。
分析现有代码结构：AI会浏览代码库，找到任务列表的前端组件（比如TodoList.jsx）和后端处理任务更新的Lambda函数（比如packages/functions/src/updateTodo.ts）。
提供修改方案：
- 后端：AI会建议修改updateTodo函数的逻辑，使其能够接收一个important字段并更新DynamoDB中对应的项。它可能会直接生成代码补丁，并解释：“这个修改会由SST热重载自动生效。你可以通过调用PUT {{LOCAL_API_BASE}}/todos/{id}来测试这个新端点。”
- 前端：AI会修改TodoList.jsx，为每个任务项添加一个按钮，并绑定一个调用更新API的点击事件。它可能会说：“按钮的样式你可以根据设计系统调整。点击后，建议先检查浏览器控制台（Network标签）和{{WEB_LOG_FILE}}确认请求是否成功。”
引导测试与验证：
- AI可能会问：“需要我使用Browser MCP打开页面，帮你点击一下新按钮来测试功能吗？” 在你同意后，它可以自动操作浏览器完成一次测试。
- 或者，它会建议你：“现在可以在前端页面点击新按钮，然后运行tail -n 20 {{SST_LOG_FILE}}来查看Lambda函数执行的日志，确认更新操作是否成功以及是否有错误。”
- 如果测试失败，AI会根据你提供的错误日志（从你粘贴的sst.log片段或web.log片段），给出具体的调试建议，比如“DynamoDB更新表达式语法有误”，并提供一个修正后的代码版本。
完成迭代：在整个过程中，你始终控制着核心的sst dev进程。AI像是一个超级熟练的结对编程伙伴，它能快速写出代码，并且知道如何在这个特定的、正在运行的环境中验证代码的正确性。它不会做出“重启服务试试”这种粗暴的建议，而是引导你利用现有的日志和观察手段。

这个流程将原本可能需要你来回切换终端、浏览器、IDE，并不断向AI解释当前状态的碎片化工作，变成了一个流畅的、上下文共享的协作过程。

6. 常见问题、故障排查与进阶技巧

即使配置正确，在实际使用中也可能遇到一些问题。以下是我在实践中总结的常见情况及其解决方法。

6.1 日志文件没有生成或为空

可能原因1：路径错误。前端package.json中的重定向路径../../.sst/logs/web.log可能不正确。使用pwd命令确认前端包目录的绝对路径，然后计算到项目根目录.sst的相对路径。
可能原因2：目录不存在。SST 可能在首次运行sst dev后才创建.sst目录。你可以手动创建日志目录：mkdir -p .sst/logs。
可能原因3：权限问题。确保当前用户对.sst/logs目录有写权限。
排查命令：在前端包目录下，手动运行npm run dev（即重定向后的命令），看看是否报错。或者，使用一个绝对路径进行测试，如> /tmp/web.log 2>&1，看日志是否能生成。

6.2 AI助手似乎忽略了规则

可能原因1：规则文件未生效。在Cursor中，检查设置 -> Rules，确保你的项目规则已启用。有时需要重启Cursor或重新打开项目。
可能原因2：规则冲突。如果项目中有多个规则文件，可能存在冲突或覆盖。检查.cursor/rules/目录下的所有.mdc文件。
可能原因3：会话上下文过长。如果对话历史非常长，早期的规则提示可能会被“挤出去”。尝试开启一个新的聊天会话（New Chat），新会话会重新加载所有规则。
解决方案：可以在对话中明确提醒AI：“请遵循我们项目中关于SST本地开发的规则。” 这通常会触发它去重新读取相关上下文。

6.3`sst dev`进程意外退出或卡住

现象：终端无响应，或者前端/API无法访问。
标准处理流程：
1. 在运行sst dev的终端中，按Ctrl+C尝试优雅退出。
2. 如果无响应，在另一个终端找到进程ID并强制结束：pkill -f “sst dev”。
3. 检查是否有端口占用。SST常用的端口是3000（前端）、8000（API）、9000（LocalStack/模拟服务）。使用lsof -i :3000等命令查看并结束占用进程。
4. 清理SST临时文件有时能解决奇怪的问题：rm -rf .sst .aws-sam（注意：这会清除本地模拟的DynamoDB等数据）。
5. 重新运行npx sst dev。
给AI的规则补充：可以在规则中明确写出这个排查流程，这样当AI察觉到环境异常时，可以给你一个结构化的重启建议清单。

6.4 如何为不同的AI工具适配规则？

Cursor：使用.cursor/rules/目录下的.mdc文件。
Claude Code：使用项目根目录下的CLAUDE.md文件。你可以将sst-local-dev.mdc的核心内容复制到CLAUDE.md中。
Windsurf / Zed 等：请查阅其官方文档，通常也有类似的“项目说明”或“规则”文件配置方式。
通用技巧：即使工具不支持高级规则，你也可以在对话开始时，手动将最重要的几条规则（如“不要启动sst dev”、“日志在这里”、“端点在这里”）以系统提示（System Prompt）的形式发送给AI，为其设定初始上下文。

6.5 进阶技巧：增强AI的上下文感知能力

将sst.log关键信息喂给AI：当遇到一个复杂部署错误时，你可以直接将.sst/logs/sst.log文件末尾的相关行（比如最后50行）复制粘贴到对话中。AI凭借强大的上下文理解能力，经常能直接定位到错误根源，比如一个错误的IAM权限配置或VPC设置。
结合sst console：SST Console 提供了一个Web界面，可以查看资源、调用函数、查看请求追踪。你可以告诉AI：“我已经打开了SST Console，在Functions标签页可以看到Lambda函数的日志流。” 然后AI可能会指导你：“请在Console里点击触发那个函数，然后把返回的错误信息告诉我。”
创建更细粒度的规则：你可以为不同的任务创建专门的规则文件。例如：
- database-rules.mdc：包含如何连接本地DynamoDB Shell、常用查询语句。
- api-test-rules.mdc：包含如何使用curl或 Postman 测试本地API端点，以及预期的响应格式。
- auth-rules.mdc：如果使用了Cognito模拟，说明如何获取测试用户的Token。这样，当AI处理特定领域问题时，可以加载更精准的上下文。

7. 安全与权限管理的考量

在让AI更深入地接入开发环境时，安全是一个不可忽视的话题。这套方案在设计上已经考虑了基本的安全边界（AI不直接执行命令），但仍有一些要点需要注意。

AWS凭证隔离：sst dev使用的是你本地配置的AWS凭证（通常是~/.aws/credentials）。确保AI助手（如Cursor）本身没有权限直接执行aws cli命令。你可以在Cursor的设置中，将aws添加到命令拒绝列表（Command Deny List），这样当AI试图生成一个aws s3 ls这样的命令时，Cursor会要求你手动批准执行。
最小权限原则：如果你按照项目建议，在env.sh中配置AWS凭证，请务必使用一个仅具有ReadOnlyAccess策略的IAM用户。即使凭证意外泄露，也能将风险降到最低。更好的做法是，完全不通过env.sh导出AWS密钥，而是依赖SST自动管理的、基于你本地配置文件的临时凭证。
代码访问：AI助手自然拥有对你项目代码的完全访问权。这本身是它的工作所需。关键在于，不要将敏感信息（如生产数据库密码、第三方API密钥）硬编码在代码中。务必使用SST的Config系统或AWS Secrets Manager来管理机密，这样即使代码被AI看到，也不会泄露实际密钥。
Browser MCP的管控：Browser MCP赋予了AI控制浏览器的能力。虽然通常仅限于你打开的本地开发页面，但仍建议在可控的环境下使用。避免让其访问包含敏感信息的真实生产管理后台。