要让cursor生成的mock数据贴近真实业务场景，必须让ai理解字段背后的业务含义、约束条件和常见分布规律，不能只给字段名和类型。明确业务角色与上下文，在提示词开头直接定义数据所属的业务模块和使用方；按字段逐条约束生成规则，用自然语言描述或真实样例说明取值逻辑；注入真实业务节奏与异常模式，设定时间范围、增量节奏、合理异常及字段间业务联动。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要让Cursor生成的mock数据贴近真实业务场景，必须让AI理解字段背后的业务含义、约束条件和常见分布规律，不能只给字段名和类型。
明确业务角色与上下文
在提示词开头直接定义数据所属的业务模块和使用方。例如：“你是一名电商中台的数据工程师，正在为订单履约服务生成测试用的orders表mock数据。”
这一步决定后续所有字段的取值逻辑——没有这个前提，AI可能把order_status生成成“已发货”“已取消”“待支付”，却漏掉“风控拦截”“物流异常”等真实系统中存在的状态。
按字段逐条约束生成规则
对关键字段分别说明业务含义、合法取值范围、出现频率、格式要求和关联逻辑。
方法一：用自然语言描述约束
“user_id：6～12位数字字符串，前两位代表注册渠道（10=App、21=小程序、33=H5），后4位需与created_at的年月日（如20240521）部分保持一致”
Agents 正在你的整个代码库中处理越来越复杂、运行时间更长的任务。本次版本引入了新的 agent 框架改进，以实现更好的上下文管理，并在编辑器和 CLI 中带来了许多提升使用体验的修复。
方法二：提供真实样例+说明
“payment_method：参考真实线上占比生成——微信支付（62%）、支付宝（28%）、云闪付（7%）、货到付款（3%）。禁止出现‘PayPal’或‘Bitcoin’等非国内主流方式。”
【payment_method字段若未限定地域和占比，Cursor极易生成脱离中国电商实际的支付方式】
注入真实业务节奏与异常模式
第一步：设定时间范围与增量节奏
“created_at字段需覆盖2024-03-01 00:00:00至2024-05-31 23:59:59，其中4月促销期（4月1日–4月10日）订单量是日常的3.2倍，每日峰值集中在20:00–22:00。”
第二步：加入合理异常数据
“约1.7%的订单address字段含错别字（如‘朝阳去’‘望京西街12好’），0.4%的phone字段末尾多一位数字（如138123456789）。”
第三步：建立字段间业务联动
“当order_status = ‘已退款’时，refund_amount必须大于0且≤total_amount；当status = ‘已发货’时，logistics_no必须为SF[8位数字]+[2字母]格式（如SF12345678HK）。”
