4.6 KiB
4.6 KiB
要让 Cursor 能够高效地完成这项复杂任务，你需要将“需求”转化为“结构化指令”。不要一次性丢给它所有任务，建议按照**“调研-分析-开发-优化”**的逻辑分阶段进行。
以下是为你设计的 Prompt 模板，你可以根据实际情况稍作修改：
第一阶段：现状分析与评估（核心提示词）
使用场景： 将 openapi.json 拖入 Cursor，打开你的项目根目录，发送以下 Prompt：
Prompt: 我现在正在对接用户商品管理模块，API 定义在
@ApiServer-web-admin_dashboard_pc/默认模块.openapi.json中。请你执行以下任务：
- 接口完整性对比： 分析该 OpenAPI 文件中所有以
/product或user开头的接口。对比我当前项目中src/api/product.ts（或对应目录）的实现，列出缺少实现的接口、参数定义不一致的接口。- 逻辑可行性判断： 检查这些接口的请求方式、入参结构和响应字段，判断是否存在潜在的逻辑错误（如字段类型不匹配、缺失必要的分页参数等）。
- 输出报告： 请整理出一份表格，列出：接口路径 | 功能描述 | 是否已实现 | 潜在风险/待修复点。
请先完成这一步，不要急于写代码。
第二阶段：功能开发与组件化（架构层）
使用场景： 在第一阶段确认无误后，让 Cursor 介入代码实现。
Prompt: 基于上一步的分析结果，我们需要进行代码落地。请遵循以下工程化标准：
- 请求实现： 按照我现有项目的请求风格（例如
axios+ts-interface），补全缺失的接口请求函数。- 组件化拆分： 在实现业务页面时，请评估哪些逻辑可以抽离为公共组件（例如：商品详情预览框、批量操作栏、规格选择器）。如果某个功能在多个页面有重复逻辑，请将其提取为独立的 Component，并说明该组件的 Props 定义。
- 嵌套与快捷入口： 针对“商品管理”模块，请思考是否存在需要嵌套展示的功能（如：点击列表行展开详细信息，或弹窗式管理）。如果是，请直接使用
ant-design(或你使用的框架) 的组件来实现这种交互，并保证良好的用户体验。
第三阶段：样式与交互优化（视觉层）
使用场景： 页面雏形出来后，让 Cursor 优化细节。
Prompt: 现在页面已经实现了基本功能，请重点优化 UX/UI：
- 布局优化： 请检查当前的表格布局，确保字段对齐合理、间距符合 Material Design 或 Ant Design 标准。
- 交互美化： 增加必要的 Loading 状态、空状态（Empty Data）、操作反馈（Toast/Message）。
- 响应式评估： 检查该 Dashboard 页面在不同分辨率下的表现，是否需要将部分复杂的筛选表单折叠到“高级筛选”面板中，以保持界面整洁。
- 视觉建议： 请评估当前样式是否过于简单，建议增加一些层级感（例如卡片式布局、阴影、不同层级的按钮样式）。
给 Cursor 的“提效秘诀”（必读）：
为了让 Cursor 表现得更好，请务必配合以下操作：
- 利用
@Codebase： 在 Prompt 中提到@Codebase，让 Cursor 全局检索你的代码规范（例如：你以前写的api请求是怎么写的，component是怎么封装的），这样它生成的代码才不会“违和”。 - 小步快跑： 如果 API 接口很多（比如超过 10 个），千万不要让它一次性全写完。一次让它写 2-3 个接口或一个组件，改完一个确认一个。
- 强制提供 Interface： 在提示词中加上一句：“请确保所有接口请求和响应都定义了对应的
TypeScript Interface，严禁使用any类型。” - 指定参考文件： 如果你有已经写好的“完美的页面”，在对话框中输入
#引用该文件，告诉 Cursor：“请参照src/pages/TemplatePage.tsx的代码规范和交互逻辑来实现商品管理页面。”
总结你的检查清单（作为你的最终验收标准）：
- OpenAPI 定义的字段是否全覆盖？
- 是否每个接口都写了 try-catch 或统一的错误处理？
- 是否有复用性强的组件？（避免重复代码）
- 是否有交互反馈？（Loading/Success Tips）
- 样式是否统一？（使用了全局定义的颜色/间距变量）
如果你直接丢给它一个庞大的任务，Cursor 往往会产生“幻觉”或者代码质量下降，分步骤引导是使用 AI 开发复杂后台的最佳实践。