Cursor 嵌入产研 —— 从产品背景到后端代码实现

我实现了用 Cursor 嵌入整个产研链路，现在已经打通了后端所有的场景和功能。重点突破了流程梳理、阶段提示词和规范，嵌入 AI 使用全新的工作流程。

不论你是公司老板、高层、创业者，你希望从 idea 到实现流程全面提效，都可以使用我这套模板，如有疑问请私信或微 jianzhangg 联系我。

AI嵌入产品从idea到实现全流程

flowchart TD %% 后端流程节点 - 左侧主线背景["背景
(产品主+AI辅)"] 业务架构["业务架构
(产品主+AI辅)"] 后端功能["后端功能
(产品+后端+AI)"] 数据库设计["数据库设计
(后端主+AI辅)"] 接口文档["接口文档
(产品+后端+AI)"] 后端代码["后端代码实现
(AI主+后端辅)"] %% 测试流程节点 - 右中侧测试["测试流程
(测试+AI)"] %% 前端流程节点 - 右上侧 UI图["UI图
(产品+UI+AI)"] 前端页面["前端页面
(AI主+前端辅)"] %% 主线连接 - 垂直流向（后端流程）背景 --> 业务架构业务架构 --> 后端功能后端功能 --> 数据库设计数据库设计 --> 接口文档接口文档 --> 后端代码 %% 测试连接 - 直角连接避免交叉业务架构 -..-> |测试流程| 测试接口文档 --> |测试流程| 测试 %% 前端连接 - 直角连接避免交叉业务架构 -..-> |前端流程| UI图 UI图 --> 前端页面 %% 前后端对接 - 直角连接避免交叉接口文档 --> |前后端对接| 前端页面 %% 布局调整 %% 把后端代码放在接口文档下方 %% 把前端页面放在接口文档右侧 %% 把测试放在UI图前面 %% 样式设置 classDef 人主导 fill:#FFE6CC,stroke:#D79B00,stroke-width:1px; classDef 后端 fill:#DAE8FC,stroke:#6C8EBF,stroke-width:1px; classDef 前端 fill:#D5E8D4,stroke:#82B366,stroke-width:1px; classDef 测试 fill:#E1D5E7,stroke:#9673A6,stroke-width:1px; %% 样式应用 class 背景,业务架构人主导; class 后端功能,数据库设计,接口文档,后端代码后端; class UI图,前端页面前端; class 测试测试; %% 连接线样式 - 后端流程线 linkStyle 0,1,2,3,4 stroke:#6C8EBF,stroke-width:1.5px; %% 测试虚线 linkStyle 5 stroke:#9673A6,stroke-width:1.5px,stroke-dasharray: 5 5; %% 测试实线 linkStyle 6 stroke:#9673A6,stroke-width:1.5px; %% 前端虚线 linkStyle 7,8 stroke:#82B366,stroke-width:1.5px,stroke-dasharray: 5 5; %% 前后端对接线 linkStyle 9 stroke:#D79B00,stroke-width:1.5px;

测试流程和前端页面，还没找到好的思路，从背景到后端代码实现的每个流程，都对应的规范和提示词。

背景 --> 业务架构

这需要人重点参与，指挥 AI 画各种图。比如我要做个网赚系统，以下是我画的图（内容太多有精简）。

flowchart TD subgraph TaskGold[" 产品架构"] subgraph User["用户领域"] U1["鉴权体系"] U2["用户信息"] U3["双重角色"] end subgraph Task["任务领域"] T1["任务信息"] T2["任务审核"] T3["任务曝光"] T4["任务聊天消息"] end subgraph Order["订单领域"] O1["订单状态机"] O2["订单售后/申诉"] O3["订单结算"] end subgraph Finance["资金领域"] F1["资金流转"] F2["支付提现"] F3["财务对账"] end end

业务流程图

flowchart LR %% 简化的业务流程 PublisherCreate[发布方
创建任务] --> TaskReview[平台审核任务] TaskReview --> TaskOnShelf[任务上架] TaskOnShelf --> WorkerAccept[执行方
接单] WorkerAccept --> PublisherPay[发布方
支付费用] PublisherPay --> WorkerSubmit[执行方
提交成果] WorkerSubmit --> PublisherCheck[发布方
验收成果] PublisherCheck --> TaskSuccess[任务完成
执行方获得报酬] %% 样式设置 - 使用更友好的颜色和图形 classDef publisherNode fill:#ffafbd,stroke:#333,stroke-width:2px classDef workerNode fill:#a1c4fd,stroke:#333,stroke-width:2px classDef platformNode fill:#ffecd2,stroke:#333,stroke-width:2px classDef successNode fill:#d5f5e3,stroke:#333,stroke-width:2px class PublisherCreate,PublisherPay,PublisherCheck publisherNode class WorkerAccept,WorkerSubmit workerNode class TaskReview,TaskOnShelf platformNode class TaskSuccess successNode

任务状态转换图

flowchart LR Draft["草稿"] -->|提交审核| Reviewing["审核中"] OffShelf["已下架"] -->|提交审核| Reviewing Reviewing -->|审核通过| OnShelf["已上架"] Reviewing -->|审核拒绝| OffShelf OnShelf -->|手动下架| OffShelf %% 样式设置 classDef draftNode fill:#f5f5f5,stroke:#333,stroke-width:2px,rx:10px classDef reviewNode fill:#ffe6cc,stroke:#333,stroke-width:2px,rx:10px classDef onShelfNode fill:#d5f5e3,stroke:#333,stroke-width:2px,rx:10px classDef offShelfNode fill:#fadbd8,stroke:#333,stroke-width:2px,rx:10px class Draft draftNode class Reviewing reviewNode class OnShelf onShelfNode class OffShelf offShelfNode %% 连线样式 linkStyle 0,1 stroke:#6c757d,stroke-width:1.5px linkStyle 2 stroke:#28a745,stroke-width:1.5px linkStyle 3,4 stroke:#dc3545,stroke-width:1.5px

订单状态转换图

flowchart LR %% 任务快照说明 note["任务快照：任务发布时创建快照，
快照关联到订单，确保订单中保存任务信息"] Created["待支付"] -->|发布方支付| Paid["已支付"] Paid -->|提交任务成果| Submitted["已提交"] Submitted -->|验收通过| Completed["已完成"] Submitted -->|验收不通过| Aftersale["售后中"] Aftersale -->|发布方处理
执行方同意| AftersaleDone["已售后"] Created -->|超时未支付| Closed["已关闭"] Paid -->|发布方取消| Closed %% 只能从售后中发起申诉 Aftersale -->|发布方处理
执行方不同意| Appeal["申诉中"] Appeal -->|客服处理| AppealDone["已申诉"] %% 终态纵向排列 Completed -.- FinalStates{{"终态"}} AppealDone -.- FinalStates Closed -.- FinalStates AftersaleDone -.- FinalStates %% 样式设置 classDef noteBox fill:#f8f9fa,stroke:#adb5bd,stroke-width:1px,stroke-dasharray:5 5,rx:5px classDef initialNode fill:#e3f2fd,stroke:#333,stroke-width:2px,rx:10px classDef processNode fill:#fff3cd,stroke:#333,stroke-width:2px,rx:10px classDef successNode fill:#d1e7dd,stroke:#333,stroke-width:2px,rx:10px classDef warningNode fill:#f8d7da,stroke:#333,stroke-width:2px,rx:10px classDef terminalNode fill:#6c757d,color:#fff,stroke:#333,stroke-width:2px,rx:15px,ry:15px class note noteBox class Created,Paid initialNode class Submitted processNode class Completed successNode class Aftersale,Appeal,AftersaleDone,AppealDone warningNode class Closed warningNode class FinalStates terminalNode %% 连线样式 linkStyle 0,1 stroke:#0d6efd,stroke-width:1.5px linkStyle 2 stroke:#198754,stroke-width:1.5px linkStyle 3,4,5,6,7,8 stroke:#dc3545,stroke-width:1.5px linkStyle 9,10,11,12 stroke:#6c757d,stroke-width:1.5px,stroke-dasharray:5 5

这一步很重要，要不停的修正每一个字眼，有可能哪一个措辞不对，就会导致生成一大堆额外的东西。

业务架构 --> 后端功能

提示词

请根据我提供的需求文档进行全面分析并生成完整的后端功能结构图。要求如下：

内容要求：
- 分析识别所有后端模块和功能组
- 区分App端功能(📱)和后台管理功能(🖥️)
- 标识对外提供的接口功能(🌐)和内部实现功能(⚙️)
- 补充必要的系统支撑功能（如通知中心、安全中心、统计分析、后台管理）
格式要求：
- 在文档顶部添加功能标识说明
- 使用【模块名称】突出显示主要功能模块
- 采用树形结构展示功能层级关系，用缩进和连接符(├、│、└)表示
- 每个功能条目末尾添加相应的功能标识符
- 保持统一的缩进格式和清晰的视觉层次
结构组织：
- 按业务领域划分主要模块（用户领域、任务领域、订单领域、资金领域等）
- 每个领域内按功能模块组织子功能
- 确保各功能模块间的逻辑连贯性
- 在系统支撑部分补充通用的基础设施功能

请生成一个完整的后端功能结构图，以Markdown格式呈现，确保直观易读且可以直接复制使用。

以下是我的需求文档：

示例 demo

这一步需要人看一下生成的接口是否符合预期。

后端功能 --> 数据库 ER 图和建表语句

提示词

请根据文档分析并生成应用的完整数据库设计：

输出要求：数据库ER图和数据库建表SQL

数据库ER图设计文件
- 使用mermaid ER图语法
- 包含所有主要数据实体及其关系
- 每个实体显示主键和关键外键字段
- 清晰标注实体间的关系类型(一对一、一对多等)
- 所有表在同一个图中展示
- 精心安排表格和关系顺序，尽量减少线条交叉
- 请在ER图中添加颜色区分不同业务模块，使用classDef和class语法为不同业务领域的表设置不同的填充颜色和边框颜色
- 生成后检查一下，确保没有语法错误
数据库建表SQL文件
- 使用MySQL兼容语法
- 不使用外键约束，仅使用索引维护表关系
- 为所有表和字段添加中文注释
- 表名称按照模块划分添加对应的前缀
- 添加适当的索引优化查询性能
- 包含初始化数据
- 字段设计遵循产品文档中的数据规格
- 字段类型和长度合理设置
- 表和字段添加默认值
- 按业务领域分组组织表结构

这是我的文件

示例 demo

生成的非常漂亮且完善，只需少量数据改动。

数据库 --> 接口文档

提示词

请根据我提供的功能结构图和数据库设计，为后端项目生成完整的接口和功能实现文档。

文档结构要求

按照功能结构图的模块划分，为每个模块创建独立的文件夹
- 每个模块文件夹命名为"XX_模块名称"（如"01_用户模块"），模块编号与功能结构图保持一致
- 在对应模块文件夹下，为每个功能创建单独的Markdown文件，命名为"XX.X_功能类型标识_功能名称.md"
- 功能类型标识必须包含在文件名中：🌐(前端接口)、🖥️(后台管理)或⚙️(内部实现)
- 示例：用户登录接口可能为"1.2_🌐密码登录.md"，后台管理功能为"3.1_🖥️任务审核.md"
- 功能文件编号应按照功能结构图中的顺序
确保为功能结构图中所有功能点都创建对应的文档
- 功能点与文档的对应应当明确，不遗漏任何功能
- 同一功能如有多种类型实现(如既有🌐又有🖥️)，必须分别创建不同类型的文档文件
- 如果一个功能涉及多个接口或实现内容，请创建所有必要的文档，编号可使用小数点扩展（如1.2.1, 1.2.2）
- 保持功能编号的层级与功能结构图的结构层级一致

文档内容规范（按功能类型区分）

前端接口功能（🌐）

严格遵循规范.md文件中定义的所有格式和内容要求
- 完整的URL、请求方法、入参、出参等API文档内容
- 接口说明和业务逻辑描述

后台管理功能（🖥️）

使用与前端接口相同的格式要求
- 完整描述API的URL、请求方法、入参、出参
- 说明管理后台权限要求和操作限制

内部实现功能（⚙️）

内部实现功能文档使用精简格式，要包含：
- 表交互：描述功能涉及的数据库表及其交互方式
- 逻辑说明：详细说明内部功能的业务逻辑和处理流程
- 流程图：使用Mermaid语法绘制功能的处理流程图
- 不需要包含URL、入参、出参等API接口相关内容

数据一致性要求

根据数据库表结构，正确映射功能涉及的数据：
- 确保字段名称、类型和含义在文档内外保持一致
- 功能间的共同概念应使用相同的命名和类型定义
功能逻辑与业务规则：
- 详细描述每个功能的业务处理逻辑和数据流转过程
- 清晰说明功能的前置条件和权限要求
- 明确功能之间的依赖和调用关系
- 对于复杂业务场景，说明状态迁移和事务处理方式
异常处理和边界情况：
- 描述常见的错误情况和对应的错误处理方式
- 说明参数验证规则和失败处理方式
- 考虑并记录边界情况的处理方法

质量保证要求

文档完成后进行自检：
- 检查是否覆盖了功能结构图中所有功能点
- 确认所有文档都符合对应类型（🌐、🖥️、⚙️）的规范要求，格式一致
- 验证流程图是否正确描述了业务流程
- 确保数据表关联的准确性和完整性
- 验证功能文件的编号是否符合功能结构图中的层级和顺序
- 确认功能类型标识是否正确添加到文件名中

请确保生成的文档既符合规范要求，又满足系统功能设计的需求，使开发团队能够基于这些文档高效实现所有系统功能。最终文档结构应清晰反映功能结构图中的层次关系，便于开发人员快速定位所需功能的实现细节。

规范

这里是我自己项目的规范，你在用的时候先为你自己项目接口文档定个规范，然后把规范文件也拖进去。

示例 demo

1.1 用户注册

接口URL ：/api/v1/user/register 功能描述：用户通过手机号注册账号

请求参数：

参数名	类型	必填	描述
phone	String	是	手机号码
password	String	是	密码(6-20位)
verifyCode	String	是	短信验证码
nickname	String	否	用户昵称(默认使用手机号)
userType	Integer	是	用户类型(0-执行方，1-发布方)

请求示例：

json 复制代码

{
  "data": {
    "phone": "13800138000",
    "password": "password123",
    "verifyCode": "123456",
    "nickname": "用户昵称",
    "userType": 0
  }
}

响应结果：

参数名	类型	描述
userId	Integer	用户ID
token	String	登录令牌
nickname	String	用户昵称
userType	Integer	用户类型(0-执行方，1-发布方)

响应示例：

json 复制代码

{
  "success": true,
  "code": "1",
  "message": "注册成功",
  "result": {
    "userId": 1001,
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
    "nickname": "用户昵称",
    "userType": 0
  }
}

逻辑描述：

校验手机号格式 → 2. 验证短信验证码 → 3. 检查手机号是否已注册
创建用户记录 → 5. 创建用户认证记录 → 6. 创建用户钱包记录
生成登录令牌 → 8. 返回用户信息

数据表关联：

主表：用户_user_user(插入) - 字段：id, username, password_hash, phone, nickname, user_type, status
关联表：用户认证_user_auth(插入) - 字段：id, user_id, auth_type, auth_key, auth_credential
- 关联：user_id → 用户_user_user.id
关联表：钱包_finance_wallet(插入) - 字段：id, user_id, balance, frozen_balance
- 关联：user_id → 用户_user_user.id

流程图：

flowchart TD A[开始] --> B{校验手机号格式} B -->|不合法| C[返回错误] B -->|合法| D{验证短信验证码} D -->|验证失败| C D -->|验证成功| E{检查手机号是否已注册} E -->|已注册| F[返回错误:手机号已注册] E -->|未注册| G[创建用户记录] G --> H[创建用户认证记录] H --> I[创建用户钱包记录] I --> J[生成登录令牌] J --> K[返回用户信息] C --> L[结束] F --> L K --> L

总结

核心是生成接口文档的时候把逻辑和流程图一并生成，前端可以根据文档写接口，产品和后端根据逻辑判断 AI 生成的是否符合预期。

接口文档 --> 后端代码实现

生成代码有一堆规范，每个微服务的文件结构、每个文件类型的编码规范等等，把这些规范和接口文档拖到一起，让 AI 生成即可。

结语

小型公司的老板、创业者、可以根据自身业务流程微调，还不懂的可以私我提供付费服务。