0. 简介
Cursor是一款受到开发者欢迎的AI编程助手，今天我们来分析它的系统提示词，以便更好地理解它的工作原理，提高使用效率。
1. Cursor Agent系统提示词
或询问可选参数。仔细分析请求中的描述性术语，因为它们可能表明应该包含一些必需的参数值，即使未明确说明。
你是一名功能强大的自主AI编码助手，由 Claude 3.7 Sonnet 提供支持。你只在世界上最好的 IDE——Cursor 中专门运行。
你正在与一位 USER 进行结对编程，以解决他们的编码任务。 该任务可能需要创建一个新的代码库、修改或调试现有代码库，或者只是回答一个问题。
每次 USER 发送消息时，我们都可能自动附加一些有关他们当前状态的信息，例如他们打开了哪些文件、光标位置、最近查看的文件、到目前为止会话的编辑历史、linter 错误等更多内容。
这些信息可能与编码任务相关，也可能无关，由你来决定。你的主要目标是在每条消息中遵循 USER 的指示。
<tool_calling>
你有可用的工具来完成编码任务。请遵守以下关于工具调用的规则：
始终严格按照指定的工具调用模式进行，并确保提供所有必要的参数。
此对话可能引用一些不再可用的工具。切勿调用未明确提供的工具。
在与 USER 交谈时，绝不要提及工具名称。 例如，不要说"我需要使用 edit_file 工具来编辑你的文件"，只要说"我将编辑你的文件"即可。
只有在必要时才调用工具。如果 USER 的任务是一般性的，或者你已经知道答案，那么无需调用工具，直接回答即可。
在调用每个工具之前，先向 USER 解释你为什么要调用它。
</tool_calling>
<search_and_reading>
如果你对 USER 的请求答案不确定，或者不知道如何满足他们的请求，你应该收集更多信息。 这可以通过额外的工具调用、提出澄清性问题等方式完成……
例如，如果你进行了语义搜索，结果可能并不能完全回答 USER 的请求，或者需要收集更多信息，也可以随时调用更多工具。
同样，如果你进行了某个编辑，可能只能部分满足 USER 的请求，但你不确定，可以在结束回合前收集更多信息或使用更多工具。
倾向于不要向用户寻求帮助，如果你可以自行找到答案的话。
</search_and_reading>
<making_code_changes>
当需要进行代码更改时，除非被请求，否则绝不要向 USER 输出代码。相反，应使用其中一种代码编辑工具来实现更改。
每回合最多只能使用一次代码编辑工具。
让你的生成代码能够被 USER 立即运行是极其重要的。为确保这一点，请仔细遵循以下说明： 添加所有必要的 import 声明、依赖和端点，以便运行代码。
如果你是从头开始创建代码库，则需要创建一个合适的依赖管理文件（例如 requirements.txt），其中包含包的版本和有用的 README。
如果你从头开始构建一个 web 应用程序，请为其提供美观且现代的 UI，并带有最佳用户体验实践。
切勿生成非常长的哈希值或任何非文本代码（如二进制），因为这对 USER 没有帮助并且成本高昂。
除非你只是向一个文件追加一些很容易应用的编辑，或创建一个新文件，否则你必须先阅读你要编辑的文件的内容或你要编辑的部分，然后才能进行编辑。
如果你引入了（linter）错误，并且你清楚如何修复（或可以很容易地找到修复方法），就进行修复，不要盲目猜测。并且不要在同一个文件上针对 linter 错误循环超过 3 次。如果在第三次仍无法修复，你应该停止并询问用户下一步该怎么做。
如果你建议的一个合理的 code_edit 没有被应用模型跟进，你可以尝试重新应用该编辑。
</making_code_changes>
<calling_external_apis>
除非 USER 明确要求，否则可以使用最合适的外部 API 和包来完成任务。无需征求 USER 的许可。
当选择 API 或包的版本时，选择与 USER 的依赖管理文件兼容的版本。如果不存在此文件或其中没有该包，则使用你训练数据中存在的最新版本。
如果外部 API 需要 API Key，请务必向 USER 指明。遵循最佳安全实践（例如，不要在可能暴露的位置对 API Key 进行硬编码）
</calling_external_apis>
<user_info>
用户的操作系统版本是 darwin 24.3.0。用户工作区的绝对路径是 $PATH。用户的 shell 是 /bin/zsh。
</user_info>
回答 USER 的请求可以使用相关工具（如果可用）。请检查每个工具调用所需的所有参数是否已提供或可以从上下文中合理推断。
如果没有相关工具或缺少必要的参数，请让 USER 提供这些值；否则继续进行工具调用。
如果 USER 为某个参数提供了特定值（例如带引号），请确保精确使用该值。不要自行编造或询问可选参数。仔细分析请求中的描述性术语，因为它们可能表明应该包含一些必需的参数值，即使未明确说明。
2. 系统提示词解读
2.1 模型驱动与身份定位
系统提示词首先明确了Cursor Agent的身份是"功能强大的自主AI编码助手"，由Claude 3.7 Sonnet驱动。这不仅告诉我们Cursor使用的是哪款模型，也暗示了它的定位是专业编程助手而非通用聊天工具。
从设计上看，这部分可能是个变量，因为Cursor新版本支持自动选择模型。明确标注模型类型也是为了避免用户在计费问题上产生疑问，因为Cursor按不同级别的模型（高级模型如Claude 3.5/3.7、GPT-4o以及非高级模型如DeepSeek、GPT-4o-mini等）收取不同费用。
2.2 工具调用规范
提示词中的<tool_calling>部分详细规定了工具调用的规则，包括：
- 严格按照指定模式调用工具
- 不调用未明确提供的工具
- 与用户交流时不直接提及工具名称
- 只在必要时调用工具
- 调用前向用户说明原因
这些规则确保了用户体验的流畅性，避免了技术细节干扰用户的思路。例如，Cursor不会说"我将使用edit_file工具"，而是直接说"我将编辑你的文件"，这种细节处理让交互更自然。
2.3 信息收集策略
在<search_and_reading>部分，提示词指导了Cursor在不确定如何满足用户请求时的信息收集策略：
- 通过工具调用、提问等方式收集信息
- 在不完全解决问题时继续收集信息
- 尽量自行寻找答案，而非向用户求助
这部分体现了Cursor的自主性设计理念，使它能像真正的编程助手那样，在遇到问题时主动寻找解决方案。
2.4 代码更改原则
<making_code_changes>部分包含了代码编辑的核心原则：
- 使用编辑工具而非直接输出代码
- 每轮对话最多使用一次编辑工具
- 生成能立即运行的代码（包含必要的导入和依赖）
- 为新项目创建适当的依赖管理文件和README
- 提供美观现代的UI和良好用户体验
- 避免生成长哈希值或二进制代码
- 编辑前先阅读文件内容
- 修复linter错误但不循环超过3次
这些原则确保了Cursor生成的代码高质量、可运行，并且符合现代开发标准。特别是"能够立即运行"这一点，体现了Cursor对用户体验的重视。
2.5 外部API调用指南
<calling_external_apis>部分规定了使用外部API和包的原则：
- 可自主选择最合适的API和包
- 选择与依赖管理文件兼容的版本
- 对需要API Key的服务进行明确提示
- 遵循最佳安全实践
这一部分反映了Cursor在实际开发中对安全性和兼容性的考虑，例如避免硬编码API密钥，这些都是专业开发中的基本准则。
2.6 用户环境信息
<user_info>部分提供了用户环境的基本信息，如操作系统版本、工作路径和shell类型。这些信息帮助Cursor在生成代码时考虑用户的具体环境，避免兼容性问题。
3. 如何更好地使用Cursor
基于对系统提示词的深入理解以及实际使用经验，我们可以采取以下详细策略来更好地利用Cursor：
3.1 充分利用Summarized Composers功能
Summarized Composers是Cursor v0.45版本引入的功能，可以极大地缓解上下文限制问题：
- 具体使用方法：
在Composer对话框中输入"@“，选择”@Summarized Composers"
系统会显示可选的历史Composer对话摘要
可以同时引用多个Summarized Composers
每个Composer对话可以重命名，方便快速定位
- 使用时机：
当你发现Cursor开始"健忘"时，就是使用此功能的最佳时机。一个简单的判断方法是在.cursorrules中添加一个识别标记，例如：
xxxxx开头
当Cursor不再使用这个特定的开头语句时，就说明上下文可能已经超限，需要开启新对话并引用之前的摘要。.cursorrules是放在项目根目录下的一个文件，你可以在里面指定ai如何生成代码。比如设置命名风格（驼峰or下划线）、缩进风格（2空格or4空格）、使用什么语言（JS or TS）等等。
一定要有Composer历史对话，才有办法引用这个新功能，否则就会出现“No available options”的提示。
3.2 合理配置Optional Long Context
Cursor v0.45版本还引入了Optional Long Context功能，允许在Composer模式下使用更长的代码上下文：
-
配置方法：
在【Cursor Settings-Features-Chat&Composer】中勾选开启
启用后会消耗更多的fast requests，可能略微降低响应速度 -
最佳使用场景：
- 处理大型代码文件（超过1000行）时
- 需要AI理解更广泛的上下文信息时
- 分析复杂的跨文件依赖关系时
- 进行大规模代码重构时
-
使用建议：
对于简单查询和小型文件，保持关闭状态以提高效率
在处理复杂项目时开启此功能
如果发现AI响应不够准确，可尝试启用此功能
根据实际需求灵活开启/关闭，平衡效率和资源消耗
3.3 建立有效的项目文档结构
良好的项目文档是缓解上下文限制的关键。特别是README.md文件，可以作为项目的"记忆库"：
- 实施方法：
在项目初始阶段，在.cursorrules中添加以下要求：
## 项目初始化
- 在项目开始时，首先仔细阅读项目目录下的 README.md文件并理解其内容，包括项目的目标、功能架构、技术栈和开发计划，确保对项目的整体架构和实现方式有清晰的认识；
- 如果还没有README.md文件，请主动创建一个，用于后续记录该应用的功能模块、页面结构、数据流、依赖库等信息。
这条要求的目的就是给项目生成README.md文档，用于记录项目的整体目标，功能模块和每个模块的用途，项目所使用的技术栈和依赖库，以及关键节点的变更和开发进度等。
每完成一个功能模块后，让Cursor更新README.md，记录相关信息
在后续对话中，使用"@File"来指定README.md作为上下文参考
这种方法的优势在于，相比Summarized Composers的高度提炼，README.md能保留更丰富的项目架构信息，为Cursor提供更完整的背景。
如果需要快速生成一些标准的提示可以使用花生插件来完成。
3.4 灵活运用Notepads保存常用逻辑
Notepads是Cursor中强大的上下文共享工具，适合存储频繁使用的代码模板和逻辑：
-
适用场景：
- 动态模板生成（如常见组件模板）
- 架构文档（前端规范、后端设计模式等）
- 开发指南（编码规范、最佳实践等）
-
最佳实践：
- 使用清晰的标题和分区
- 包含相关示例
- 保持内容专注和有序
- 使用Markdown格式提高可读性
- 添加必要的相关文件附件
-
示例结构：
```bash
# API Development Guidelines
## Endpoint Structure
- Use RESTful conventions
- Base URL: `/api/v1`
- Resource naming in plural form
## Authentication
- JWT-based authentication
- Token format: Bearer {token}
- Refresh token mechanism required
## Response Format
{
"status": "success|error",
"data": {},
"message": "Optional message"
}
## Attached References
@api-specs.yaml
@auth-flow.md
```
值得注意的是，Notepads不会跨项目自动同步。因此，一个实用的替代方法是将这些规范/指南先写在本地文件中，再复制到新项目中，然后使用"@File"实现类似的上下文索引效果。
3.5 有效利用Project Rules增强功能
Cursor v0.47版本引入了增强的Project Rules功能，提供了四种不同类型的规则：
- Always：自动附加到每个聊天和命令上
- Auto Attached：基于文件模式匹配自动附加
- Agent Requested：描述规则有助于完成的任务
- Manual：需要手动@引用才能包含在上下文中
这种分类使规则管理更加灵活，可以根据需要将不同类型的规则分配到不同类别，减少不必要的上下文消耗。
Rule for AI
## Always respond in 中文
## 你是高级系统架构师，clean code 专家
## 你的代码需要遵循基本软件设计原则，如：DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid), SOLID
## 使用思维链推理来进行代码 debug
## 每处的修改需要从整体上审视相关依赖，所有涉及到的地方都要同步修改，不可漏改、漏删，也不可多改、多删。
## 每次完成一个特性或者修复一个错误，随时更新进度记录。
4. 避免"AI降智"的预防策略
当使用Cursor进行长时间开发时，可能会遇到"AI降智"现象——即AI助手的表现不如之前那么好，这主要是由上下文限制和其他因素导致的。以下是详细的预防和解决策略：
增强项目管理与AI协作的最佳实践
我将在原有内容基础上，为每个部分增加更多实用的例子和具体实施方法。
4.1 项目初始化与结构化开发
创建清晰的项目初始化规则：
- 在项目根目录创建.cursorrules文件，详细定义开发规范
- 明确设定角色、目标、项目初始化步骤、编码标准等
- 包含特定领域的最佳实践和技术栈要求
示例1: 后端API开发规范
# Role
你是一个Node.js后端开发专家，精通Express框架和RESTful API设计。
# Goal
帮助构建一个高性能、安全的电子商务平台API。
## 第一步：项目初始化
- 使用Express Generator创建基础项目结构
- 实现MVC架构模式，清晰分离控制器、服务层和数据模型
- 配置环境变量和配置文件，区分开发/测试/生产环境
## 第二步：API开发标准
### 安全标准
- 所有API端点必须实现适当的认证和授权
- 必须使用参数验证防止注入攻击
- 敏感数据必须加密存储
### 性能考量
- 所有数据库查询必须优化并添加适当索引
- 实现数据缓存机制降低数据库负载
- API响应时间不应超过300ms
### 代码风格
- 遵循Airbnb JavaScript风格指南
- 使用async/await处理异步操作，避免回调地狱
- 每个函数不超过30行代码
## 第三步：测试策略
- 使用Jest编写单元测试，测试覆盖率至少达到80%
- 使用Supertest进行API集成测试
- 实现自动化负载测试确保性能达标
示例2: 前端Vue项目规范
# Role
你是Vue.js前端架构师，专注于构建高性能单页应用。
# Goal
开发一个响应式、用户友好的dashboard应用。
## 第一步：项目架构
- 使用Vue CLI创建项目，启用TypeScript支持
- 采用Vuex进行状态管理，模块化设计store
- 实现基于路由的代码分割优化首屏加载时间
## 第二步：组件开发规范
### 组件结构
- 采用Atomic Design原则组织组件库
- 公共组件必须有完整的props文档和单元测试
- 较复杂组件采用Composition API，简单UI组件可使用Options API
### 样式管理
- 使用SCSS预处理器，采用BEM命名规范
- 响应式设计必须覆盖移动端、平板和桌面三种尺寸
- 关键UI交互必须有过渡动画，提升用户体验
## 第三步：质量保证
- 使用ESLint和Prettier强制代码风格一致性
- Jest和Vue Test Utils进行组件测试
- Lighthouse分析性能得分，目标分数不低于90
项目文档的结构化管理示例：
标准化文档模板：
# 模块名称：用户认证系统
## 1. 功能概述
提供用户注册、登录、密码重置和多因素认证功能。
## 2. 技术架构
- 前端：React + Redux
- 后端：Node.js + Express
- 数据库：MongoDB
- 认证：JWT + OAuth2
## 3. API参考
### 3.1 用户注册
POST /api/auth/register
请求/响应格式示例与参数说明...
### 3.2 用户登录
POST /api/auth/login
请求/响应格式示例与参数说明...
## 4. 数据流说明
[流程图或时序图]
## 5. 安全考量
- 密码哈希策略
- 令牌管理
- 速率限制实现
## 6. 测试用例
关键测试场景清单...
## 7. 未来优化点
计划中的功能增强...
大型项目文档目录结构：
/docs
/architecture # 系统架构文档
overview.md # 系统整体架构
data-flow.md # 数据流图
tech-stack.md # 技术栈详情
/api-reference # API文档
authentication.md # 认证相关API
products.md # 产品相关API
orders.md # 订单相关API
/modules # 模块文档
/user-management # 用户管理模块文档
/payment-processing # 支付处理模块文档
/inventory # 库存管理模块文档
/guides # 开发指南
onboarding.md # 新开发者入门指南
deployment.md # 部署流程文档
testing.md # 测试策略文档
/design # 设计相关
ui-guidelines.md # UI设计规范
wireframes/ # 线框图目录
mockups/ # 设计稿目录
4.2 增量式开发与早期验证
构建最小可行产品(MVP)的详细策略：
增量开发计划示例（移动应用）：
| 阶段 | 功能模块 | 预期结果 | 验证方式 |
|---|---|---|---|
| 1 | 用户认证 | 用户可注册登录 | 手动测试登录流程 |
| 2 | 基础导航 | 可在主要页面间切换 | UI测试，检查页面路由 |
| 3 | 产品列表 | 显示从API获取的产品 | 加载速度和渲染正确性 |
| 4 | 搜索功能 | 用户可筛选产品 | 搜索准确性和响应时间 |
| 5 | 购物车 | 添加/移除/结算产品 | 购物流程端到端测试 |
功能分解与检查点示例：
功能：用户评论系统
├── 阶段1: 基础评论显示 (检查点1)
│ ├── 评论列表UI组件
│ ├── 从API获取评论数据
│ └── 分页控件
├── 阶段2: 评论提交功能 (检查点2)
│ ├── 评论表单组件
│ ├── 客户端验证
│ └── 提交API集成
├── 阶段3: 高级功能 (检查点3)
├── 评分系统
├── 回复功能
└── 举报不当评论
代码验证的实际例子：
第一个功能点验证示例：
// 实现基本的用户认证服务
class AuthService {
constructor(apiClient) {
this.apiClient = apiClient;
this.token = localStorage.getItem('auth_token');
}
async login(email, password) {
try {
const response = await this.apiClient.post('/auth/login', { email, password });
this.token = response.data.token;
localStorage.setItem('auth_token', this.token);
return true;
} catch (error) {
console.error('Login failed:', error);
return false;
}
}
}
// 快速验证测试
async function testAuthService() {
const mockApiClient = {
post: async (url, data) => {
console.log(`POST request to ${url} with data:`, data);
return { data: { token: 'test_token_123' } };
}
};
const authService = new AuthService(mockApiClient);
const result = await authService.login('test@example.com', 'password');
console.assert(result === true, '登录功能应返回true');
console.assert(authService.token === 'test_token_123', '应正确保存token');
console.log('Auth service 测试完成!');
}
testAuthService();
跨平台和环境测试检查清单：
# 跨平台测试清单
## 设备兼容性
- [ ] iOS最新版测试（iPhone 13/14）
- [ ] iOS旧版本测试（iPhone 8/X）
- [ ] Android最新版（Samsung Galaxy S22）
- [ ] Android中端设备（Pixel 6a）
- [ ] Android入门级设备（低性能环境）
## 网络条件测试
- [ ] WiFi连接（高速）
- [ ] 4G网络连接
- [ ] 3G网络（模拟弱网络）
- [ ] 网络中断恢复测试
## 屏幕适配
- [ ] 手机垂直方向
- [ ] 手机水平方向
- [ ] 平板设备
- [ ] 折叠屏设备展开/折叠状态
## 系统功能集成
- [ ] 推送通知
- [ ] 文件访问权限
- [ ] 相机/相册访问
- [ ] 后台运行/恢复
4.3 高效的版本控制与恢复策略
Git工作流程实践示例：
# 功能开发工作流
# 1. 从主分支创建功能分支
git checkout main
git pull
git checkout -b feature/user-profile
# 2. 开发功能，小步提交
# ...编写代码...
git add src/components/UserProfile
git commit -m "[User] 添加 - 用户资料页面基础结构"
# ...继续开发...
git add src/services/userService.js
git commit -m "[User] 添加 - 获取用户资料API集成"
# 3. 完成特性，创建标签
git tag -a v0.3.0-user-profile -m "用户资料功能完成"
# 4. 合并回主分支
git checkout main
git merge feature/user-profile
git push origin main --tags
Cursor分支策略图示：
具体提交消息模板示例：
[模块] 类型 - 详细描述
类型可以是:
- 添加: 新功能
- 修复: bug修复
- 优化: 性能或代码改进
- 重构: 不改变功能的代码重构
- 文档: 仅文档更改
- 测试: 添加或修改测试
例如:
[Auth] 修复 - 登录表单在提交时未禁用按钮导致重复提交
[Dashboard] 添加 - 用户活动数据图表组件
[API] 优化 - 减少产品列表API的响应大小提高加载速度
Cursor备份与恢复机制实例：
# Cursor备份与恢复策略
## 日常工作中
1. 每完成一个功能模块，使用Cursor的"Save Chat"功能保存当前会话
命名格式: [日期]-[功能名]-[状态]
例如: "2023-04-02-UserAuth-Completed"
2. 使用"New Chat"开始新功能开发，保持会话专注于单一功能
3. 定期检查Cursor历史记录，确保重要代码有备份点
## 代码恢复场景
1. 查找关键代码:
- 使用Cursor历史搜索功能，通过关键词查找相关会话
- 通过会话标题快速定位到特定功能的开发记录
2. 恢复特定版本:
- 在对话历史中找到所需代码段
- 使用"Copy"功能复制完整代码
- 或使用Cursor的"Replace file with this version"功能直接恢复
3. 重大错误恢复:
- 将当前错误代码保存为单独文件作为参考
- 从最后已知工作的Cursor会话中恢复代码
- 增量合并必要的修改
4.4 精确指导AI的代码修改
限定修改范围的具体示例：
# 差劲的指令
请修复登录功能的问题。
# 好的指令
请修改src/services/authService.js文件中的login函数（第25-40行），
修复以下问题：当用户输入正确凭证但API返回429错误（请求频率过高）时，
系统没有提示用户稍后重试而是显示"用户名或密码错误"。
需要添加对429状态码的特殊处理，返回更友好的错误信息，
但不要更改其他错误处理逻辑和现有的代码结构。
视觉化的修改范围指南：
文件: ProductCard.js
修改前:
+-----------------------+
| import React from... |
| |
| function ProductCard |
| ... |
| // 价格显示逻辑 | <-- 修改这部分
| const priceDisplay = |
| price.toFixed(2); |
| ... |
| return ( |
| <div>... |
+-----------------------+
修改后:
+-----------------------+
| import React from... |
| |
| function ProductCard |
| ... |
| // 价格显示逻辑 |
| const priceDisplay = |
| formatPrice(price); | <-- 使用新函数
| ... |
| // 添加格式化函数 | <-- 新增这部分
| function formatPrice(p) {
| return p ? '$'+p.toFixed(2) : 'N/A';
| } |
| ... |
+-----------------------+
防止AI随意改动的详细指令示例：
# 修改请求 - 添加分页功能
## 文件位置
src/components/ProductList.js
## 当前问题
产品列表一次性加载所有商品，可能导致性能问题。
## 需要修改的内容
1. 仅修改fetchProducts函数（第45-60行），添加分页参数
2. 在组件状态中添加page和pageSize变量
3. 添加简单的分页控件UI（在列表底部）
## 限制条件
1. 不要更改现有的产品卡片组件(ProductCard)
2. 保留所有现有的事件处理函数
3. 不要更改API响应处理逻辑，仅修改请求参数
4. 使用现有的样式系统，不要引入新的CSS框架
## 现有代码结构
```jsx
function ProductList() {
const [products, setProducts] = useState([]);
const [loading, setLoading] = useState(false);
const [error, setError] = useState(null);
// 这是需要修改的函数
const fetchProducts = async () => {
setLoading(true);
try {
const response = await api.get('/products');
setProducts(response.data);
setError(null);
} catch (err) {
setError('Failed to load products');
} finally {
setLoading(false);
}
};
// 其他代码...
}
4.5 可视化辅助与明确反馈
有效的UI示意图示例：
+----------------------------------+
| 产品详情页 - 设计稿 |
+----------------------------------+
+----------------------------------+
| < 返回 🔍 搜索 |
+----------------------------------+
| |
| +----------------------------+ |
| | | |
| | 产品图片 (轮播) | |
| | | |
| +----------------------------+ |
| |
| 产品名称 |
| ¥199.00 |
| |
| ⭐⭐⭐⭐☆ (4.2) 2,305条评价 |
| |
| 尺寸选择: |
| [S] [M] [L] [XL] [XXL] |
| |
| 颜色选择: |
| [🔴] [⚪] [⚫] [🔵] |
| |
| 数量: [-] 1 [+] |
| |
| +----------------------------+ |
| | 加入购物车 | |
| +----------------------------+ |
| |
| +----------------------------+ |
| | 立即购买 | |
| +----------------------------+ |
| |
+----------------------------------+
流程图实例：
订单处理流程:
[用户] -> (提交订单) -> [订单服务]
|
v
(库存检查) -> [库存服务]
|
+----------+----------+
| |
v v
(库存充足) (库存不足)
| |
v v
(创建支付请求) (通知用户)
| |
v |
[支付处理服务] |
| |
+---------+---------+ |
| | |
v v |
(支付成功) (支付失败) |
| | |
v +-----------+
(创建物流单)
|
v
[物流服务]
|
v
(完成订单)
明确反馈例子：
不正确的反馈：
"这个代码有问题，请修复。"
有效的反馈：
"这段代码不正确，因为它在处理异步API请求时没有考虑可能的网络错误。
请添加try/catch块捕获异常，并在UI中显示适当的错误消息。
特别是，需要处理网络超时(408)和服务器错误(500)两种情况。"
结构化反馈模板：
## 代码评审反馈
### 功能完成度: ⭐⭐⭐☆☆ (3/5)
- ✅ 数据成功加载并显示
- ✅ 分页控件工作正常
- ✅ 响应式布局适配移动设备
- ❌ 搜索功能未实现
- ❌ 加载状态没有视觉指示器
### 代码质量: ⭐⭐⭐⭐☆ (4/5)
- ✅ 代码结构清晰
- ✅ 组件拆分合理
- ✅ 使用了TypeScript类型
- ✅ 命名规范统一
- ❌ 缺少单元测试
### 需要修改的问题:
1. **高优先级**:
- 第25行: API请求应添加错误处理
- 第47行: 表单提交没有防止重复提交
2. **中优先级**:
- 第104行: 性能优化，应使用useMemo包装计算
- 样式文件过于冗长，考虑拆分为多个模块
3. **低优先级**:
- 考虑添加加载状态动画
- 添加代码注释解释复杂逻辑
4.6 高级项目管理技术
…详情请参照古月居
6. 总结与前景展望
通过深入分析Cursor Agent的系统提示词，我们不仅了解了Cursor内部如何设计和约束AI行为，也学习了如何更有效地利用这些设计来提高编程效率。虽然AI工具仍有其局限性，但随着技术的发展和我们对工具理解的深入，我们能够更好地发挥其价值。
7. 参考链接
https://mp.weixin.qq.com/s/FbPLWYtqY2URuuylEyJVKg
https://mp.weixin.qq.com/s/BtqKATAx5Q8_CKff1wmO5Q
https://mp.weixin.qq.com/s/RQ1p8jeCsymXo4ftCxpvQg
https://mp.weixin.qq.com/s/fwobTPGtVP0L2EV7clr6NQ
扫一扫
1987
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
