前言
前面给大家分享了《Cursor实战：一人全流程模块开发 - 掘金》，全栈开发不是梦，一人搞定一个模块。
前面那次分享，为了让大家直观的感受到Cursor辅助全栈开发的能力，我们挑选了最简单的单表场景。
今天，我们升级一点，分享一个关联表的业务场景。
背景及任务
背景
还是我们团队内部的协同平台，整个项目基于SpringBoot+Element UI实现，技术框架是在各种开源组件上面进行了进一步封装，数据库采用的MySQL。
研发项目都会用到各种资源，比如服务器、域名、证书等，这些资源分散在阿里云、腾讯云等多个第三方服务商，对于项目后期运维来说，太过分散，尤其是涉及到各种续费问题时。
任务
我们计划实现一个“项目资源”模块，挂在“项目”下，将各种资源管理起来，并可以区分是哪个平台购买的。
为了更好地聚焦多表关联部分，“项目”和“项目资源”的单表增删改查代码已经通过代码生成工具生成。
建表sql如下：
-- 项目信息表
DROP TABLE IF EXISTS `project_base`;
CREATE TABLE `project_base`
(
id BIGINT(20) NOT NULL AUTO_INCREMENT,
create_by_id BIGINT(20) DEFAULT NULL COMMENT '创建人ID',
dept_id BIGINT(20) DEFAULT NULL COMMENT '创建人机构ID',
create_by varchar(64) COLLATE utf8_bin DEFAULT '' COMMENT '创建者',
create_time datetime DEFAULT NULL COMMENT '创建时间',
update_by varchar(64) COLLATE utf8_bin DEFAULT '' COMMENT '更新者',
update_time datetime DEFAULT NULL COMMENT '更新时间',
remark varchar(1000) COLLATE utf8_bin DEFAULT NULL COMMENT '备注',
contract_id BIGINT(20) DEFAULT NULL COMMENT '合同ID',
project_name VARCHAR(100) DEFAULT NULL COMMENT '项目名称',
project_code VARCHAR(100) DEFAULT NULL COMMENT '项目编号',
project_type VARCHAR(100) DEFAULT NULL COMMENT '项目类型',
project_description TEXT COMMENT '项目详细描述',
start_date date COLLATE utf8_bin DEFAULT NULL COMMENT '项目开始日期',
end_date date COLLATE utf8_bin DEFAULT NULL COMMENT '项目预计结束日期',
actual_end_date date COLLATE utf8_bin DEFAULT NULL COMMENT '项目实际结束日期',
project_status VARCHAR(100) DEFAULT NULL COMMENT '项目状态',
manager_user_id BIGINT(20) DEFAULT NULL COMMENT '项目经理',
relate_document VARCHAR(255) DEFAULT NULL COMMENT '关联文档',
PRIMARY KEY (`id`)
) ENGINE = InnoDB
AUTO_INCREMENT = 1
DEFAULT CHARSET = utf8
COLLATE = utf8_bin COMMENT ='项目信息表';
-- 项目资源表
CREATE TABLE `project_resource` (
`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID',
`project_id` bigint(20) NOT NULL COMMENT '关联项目ID',
`resource_name` varchar(100) NOT NULL COMMENT '资源名称',
`resource_type` varchar(50) NOT NULL COMMENT '资源类型(SERVER-服务器/DOMAIN-域名/CERTIFICATE-证书)',
`provider` varchar(50) DEFAULT NULL COMMENT '服务提供商',
`provider_url` varchar(200) DEFAULT NULL COMMENT '服务提供商URL',
`purchase_amount` varchar(50) DEFAULT NULL COMMENT '购买金额',
`purchase_date` datetime DEFAULT NULL COMMENT '购买日期',
`expire_date` datetime DEFAULT NULL COMMENT '到期日期',
`renew_remind_days` int(5) DEFAULT 30 COMMENT '续费提醒天数',
`resource_status` varchar(50) DEFAULT NULL COMMENT '资源状态(USING-使用中/EXPIRED-已过期/TERMINATED-已停用)',
`description` varchar(200) DEFAULT NULL COMMENT '资源描述',
`resource_info` varchar(200) DEFAULT NULL COMMENT '资源信息',
`relate_document` varchar(500) DEFAULT NULL COMMENT '关联文档',
`create_by_id` BIGINT(20) DEFAULT NULL COMMENT '创建人ID',
`dept_id` BIGINT(20) DEFAULT NULL COMMENT '创建人机构ID',
`create_by` varchar(64) COLLATE utf8_bin DEFAULT '' COMMENT '创建者',
`create_time` datetime DEFAULT NULL COMMENT '创建时间',
`update_by` varchar(64) COLLATE utf8_bin DEFAULT '' COMMENT '更新者',
`update_time` datetime DEFAULT NULL COMMENT '更新时间',
`remark` varchar(1000) COLLATE utf8_bin DEFAULT NULL COMMENT '备注',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 COMMENT='项目资源表';
操作过程
录入页面关联项目
代码生成工具仅能生成单表基础代码，像“项目资源”中的关联项目字段并未处理。
我们通过Cursor直接实现录入页面下拉项目关联。
上下文：
编辑页面edit.vue、项目接口projectBase.js、项目资源建表sql。
提示词：
项目资源录入页面edit.vue中关联项目应该使用下拉，直接关联项目信息模块。
指定上下文、明确操作范围（edit.vue）将会大大降低大模型幻觉。
结果：
项目资源录入页面关联项目代码就搞定了，并且准确识别原有下拉字典代码（生成时占位）进行修改，也不会遗留垃圾代码。
效果：
项目列表呈现资源数据
项目资源一般直接会在项目模块进行查看，计划在项目列表增加一个“资源”按钮，点击后打开右侧抽屉，展示“项目资源”信息。
上下文：
项目列表页面index.vue、项目资源接口resource.js。
提示词：
项目列表页面增加“资源”按钮，点击后在右侧打开“资源”抽屉，抽屉内显示“项目资源”数据，项目资源数据不要采用表格样式。
如果想要高效的生成正确结果，提示词中应该准确使用关键词，比如“抽屉”、“表格样式”。
所以，AI协同编程效果好的前提是需要大家储备丰富的编程基础，并能在提示词中准确的选择使用。
强者恒强，弱者更弱！
结果：
效果：
类型的字典没有渲染，并且显示出来的信息稍微少了一点，通过简单的提示词再优化一下，效果如下。
项目名称临时字段添加
项目资源的关联项目进行保存在前面已经实现了，但是列表和查看页面还没有正常显示项目名称，进一步完善下。
上下文：
项目资源列表页面、项目资源查看页面、项目后端Mapper.xml、项目建表sql、项目资源建表sql。
由于前后端一起修改，涉及到的文件较多，如果不指定上下文，容易出现文件找错的情况。
尤其是Mapper.xml文件不在src下，最好直接指明。
提示词：
项目资源列表、查看页面中的关联项目字段无法正常显示项目信息中的project_name，请帮我修复。
我希望通过后端实体中增加临时字段的方式实现，不考虑前端方式。
java工程中不使用lombok，使用mybatis，不使用mybatis plus。
这个提示词就比较多了，尤其是一些限制条件，因为Cursor模型中的知识和我们自身的规范可能不大一样。
但也不用担心如何确定最佳提示词，多试几次后，保存效果最好的提示词之后一直用即可。
AI协同编程的一个重要事项就是维护一个自己的提示词库。
结果：
可以看到分析过程很合理，包括实体没有加入到上下文也考虑到了。
效果：
总结
本次主要分享了多表关联业务场景下如何使用Cursor提效，经过实战验证，可以发现不论是页面关联效果，还是后端关联字段查询，Cursor都可以很好的处理。
多表关联业务尝试成功后，其实大部分真实开发场景都可以搞定了，只需要根据不同的业务场景做好任务的划分和分解即可。
