用 Cursor + Claude 开发OA、CRM等企业管理系统：AI 编程实战全记录

🌐 演示地址：http://ruoyioffice.com | 📦 源码1：https://gitcode.com/zhouzhongyan/ruoyi-office-vben.git | 📦 源码2：https://gitcode.com/zhouzhongyan/ruoyi-office.git | 📦 源码3：https://github.com/yuqing2026/ruoyi-office.git | 💬 微信：17156169080（备注「RuoYi Office」）

2026 年，AI 编程已经不是尝鲜玩具。我们团队用 Cursor + Claude，3 个月完成了传统方式需要 1 年的企业管理系统开发。这不是营销话术——14 个业务模块、上百张数据表、三端（PC + APP + 小程序）联动，真真切切地从需求文档到上线运行。本文是一份真实的实战记录，拆解我们在开发 RuoyiOffice 企业管理平台过程中，如何让 AI 承担 60%-80% 的编码工作，又在哪些环节仍然依赖人工判断。

引言：为什么写这篇文章？

过去一年，关于 AI 编程的文章不少，但大多停留在"Hello World 级别的 demo 演示"或"用 AI 写了一个贪吃蛇"。真正记录AI 参与企业级系统全周期开发的实战文章极少。

我们在开发 RuoyiOffice 的过程中积累了大量实际经验：

  • 哪些任务 AI 能直接搞定：CRUD 代码生成、数据库表设计、API 文档编写、前端页面搭建
  • 哪些任务需要人机协作：复杂业务逻辑、工作流集成、性能调优、安全审计
  • 哪些任务 AI 无能为力：架构级决策、产品需求澄清、线上故障排查

本文不吹不黑，用真实的代码片段、效率数据和踩坑记录，还原 AI 编程在企业系统开发中的全貌。

一、为什么选择 Cursor + Claude

市面上的 AI 编程工具不少，我们在 2025 年底启动 RuoyiOffice 项目时，对主流方案做了横向对比。

1.1 Cursor IDE：不只是"带 AI 的编辑器"

Cursor 是基于 VS Code 深度改造的 AI-Native IDE，核心优势在于AI 与编辑器的深度融合：

能力 说明 实际开发中的体感
内置对话 在编辑器内直接与 AI 对话，无需切换窗口 写着写着有问题，Ctrl+L 直接问，思路不断
代码补全 Tab 补全，支持多行预测 写完方法签名，Tab 一下整个方法体就出来
多文件编辑 AI 可以同时修改多个文件 改一个接口，Controller/Service/Mapper/VO 一起改
Agent 模式 AI 自主决定读哪些文件、改哪些代码、执行什么命令 给出需求描述，AI 自动找到相关文件并修改
@引用 用 @ 符号引用项目中的文件、目录、符号 @SupplyInfoService 让 AI 理解已有模式
Cursor Rules 项目级规则文件，持久化指导 AI 行为 写好一次规范，后续所有生成代码自动遵循

1.2 Claude：长上下文 + 高质量代码

选择 Claude 作为背后的大模型，原因很直接：

长上下文理解：Claude 支持超长上下文窗口。在企业系统开发中，一个业务模块往往涉及十几个文件、上千行代码。Claude 能一次性理解整个模块的上下文，生成的代码与现有代码风格一致。

代码质量稳定：经过半年的实际使用，Claude 生成的 Java/TypeScript 代码质量明显优于其他模型——变量命名规范、异常处理完整、边界条件考虑充分。

中文理解能力强：企业系统中有大量中文业务术语（“用印申请”“请假销假”“转正审批”），Claude 能准确理解这些概念并映射到代码层面。

1.3 主流 AI 编程工具对比

工具组合 优势 局限 适合场景
Cursor + Claude 长上下文、Agent 模式、代码质量高、中文好 需要付费订阅 企业级项目、复杂业务系统
VS Code + Copilot 普及度高、GitHub 生态集成好 上下文窗口较短、多文件编辑弱 单文件级别的代码补全
Windsurf + GPT-4 有免费额度、界面友好 代码质量波动、Agent 模式不够稳定 个人项目、学习练习
JetBrains + AI Assistant JetBrains 生态深度集成 AI 能力相对保守、不支持 Agent 模式 已经使用 IDEA 的团队

最终选择 Cursor + Claude 的决定性因素是 Agent 模式 + 长上下文——企业系统开发不是改一个函数那么简单，往往一个需求涉及跨模块的 10+ 文件修改，这正是 Cursor Agent 的强项。

1.4 AI 编程开发流程

promote-ai-coding-workflow.png

▲ AI 辅助开发的核心工作流：需求描述 → AI 生成 → 人工审查 → 反馈迭代 → 合并代码

我们总结出一套 AI 编程的标准工作流，贯穿 RuoyiOffice 整个开发过程：



1. 编写 Cursor Rules（一次性投入）
   ↓
2. 自然语言描述需求
   ↓
3. AI 生成第一版代码（DDL → 后端 → 前端）
   ↓
4. 人工审查 + 反馈修改意见
   ↓
5. AI 迭代修正（通常 2-3 轮收敛）
   ↓
6. 人工微调 + 集成测试
   ↓
7. 合并到主分支

关键理念：AI 负责"从 0 到 0.8"，人负责"从 0.8 到 1.0"。

二、项目背景：RuoyiOffice 企业管理平台

2.1 项目定位

RuoyiOffice 是基于 RuoYi-Vue-Pro（Yudao）深度定制的企业管理一体化平台，支持单体和微服务双模式部署。它不是一个 demo，而是一套面向真实企业场景的生产级系统。

2.2 技术栈

层级 技术选型 版本
后端框架 Spring Boot 3.5
ORM MyBatis-Plus + MyBatis-Plus-Join —
工作流引擎 Flowable BPMN 2.0
权限认证 Spring Security + OAuth2 多租户
前端框架 Vue 3 + Vben Admin 5.x TypeScript
UI 组件库 Ant Design Vue 4.x —
移动端 UniApp + Vue 3 + wot-design-uni —
构建工具 Vite 6.x + pnpm + Turbo Monorepo
AI 集成 Spring AI（多模型） —

2.3 业务模块规模

模块 功能概述 复杂度
系统管理 用户/角色/菜单/租户/字典/OAuth2 ★★★★
基础设施 代码生成/文件/配置/任务/日志 ★★★
BPM 工作流 Flowable 流程设计/审批/表单 ★★★★★
OA 办公 会议室/用印/公车/文件/日程/请假/差旅 ★★★★
HRM 人力 员工/考勤/薪资/招聘 ★★★★
资产管理 固定资产/盘点/调拨 ★★★
CRM 客户 客户/商机/合同/回款 ★★★★
ERP 进销存 采购/销售/库存 ★★★★
商城 商品/订单/营销/售后 ★★★★★
支付中心 多支付渠道集成 ★★★
AI 模块 对话/绘图/知识库/MCP ★★★★

14 个业务模块，每个模块都涉及数据库设计、后端 API、前端页面、BPM 流程集成、移动端适配。这种规模的项目，传统方式至少需要 6-8 名开发者投入 12 个月以上。
promote-architecture-overview.png
▲ RuoyiOffice 技术架构全景：Spring Boot 3.5 + Vue3 + UniApp 三端联动，Flowable 驱动审批流程

三、实战场景 1：用 AI 生成完整 CRUD 模块

以"办公用品管理"模块为例，完整展示从需求描述到代码生成的全过程。

3.1 Step 1：用自然语言描述需求

在 Cursor 中打开对话窗口，输入需求描述：


帮我设计并生成"办公用品管理"模块：

1. 业务概述：管理企业的办公用品台账、员工申请领用、行政发放、借用品归还
2. 数据模型：
   - oa_supply_info（用品台账）：名称、类型（消耗品/借用品）、单位、库存、预警值
   - oa_supply_apply（申请单）：申请人、申请日期、审批状态、BPM流程ID
   - oa_supply_item（申请明细）：关联申请单、关联用品、申请数量、发放数量、归还数量、状态
3. 业务规则：消耗品发放后即完结，借用品需追踪归还
4. 请参考 @oa_seal_apply 用印申请模块的代码结构和命名规范

关键技巧在最后一行——用 @引用 让 AI 学习已有模块的代码模式。AI 会读取用印申请模块的全部代码，理解项目的命名规范、包结构、异常处理方式，然后据此生成风格一致的新代码。

3.2 Step 2：AI 生成数据库设计

Claude 根据需求描述，生成了完整的 DDL 语句：

CREATE TABLE oa_supply_info (
    id          BIGINT NOT NULL AUTO_INCREMENT COMMENT '用品ID',
    supply_name VARCHAR(200) NOT NULL COMMENT '物品名称',
    supply_type TINYINT NOT NULL COMMENT '管理类型：1-消耗品 2-借用品',
    category_id BIGINT COMMENT '分类ID',
    unit        VARCHAR(50) COMMENT '计量单位',
    spec        VARCHAR(200) COMMENT '规格型号',
    stock_quantity   INT DEFAULT 0 COMMENT '库存数量',
    warning_quantity INT DEFAULT 0 COMMENT '预警数量',
    status      TINYINT DEFAULT 0 COMMENT '状态：0-正常 1-停用',
    remark      VARCHAR(500) COMMENT '备注',
    creator     VARCHAR(64) DEFAULT '' COMMENT '创建者',
    create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    updater     VARCHAR(64) DEFAULT '' COMMENT '更新者',
    update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    deleted     BIT(1) DEFAULT b'0' COMMENT '逻辑删除',
    tenant_id   BIGINT NOT NULL DEFAULT 0 COMMENT '租户ID',
    PRIMARY KEY (id)
) ENGINE=InnoDB COMMENT='办公用品台账';

CREATE TABLE oa_supply_apply (
    id           BIGINT NOT NULL AUTO_INCREMENT COMMENT '申请ID',
    apply_no     VARCHAR(64) NOT NULL COMMENT '申请编号',
    user_id      BIGINT NOT NULL COMMENT '申请人ID',
    dept_id      BIGINT COMMENT '部门ID',
    apply_reason VARCHAR(500) COMMENT '申请事由',
    bpm_status   TINYINT DEFAULT 0 COMMENT 'BPM审批状态',
    process_instance_id VARCHAR(64) COMMENT '流程实例ID',
    creator      VARCHAR(64) DEFAULT '' COMMENT '创建者',
    create_time  DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updater      VARCHAR(64) DEFAULT '' COMMENT '更新者',
    update_time  DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    deleted      BIT(1) DEFAULT b'0' COMMENT '逻辑删除',
    tenant_id    BIGINT NOT NULL DEFAULT 0 COMMENT '租户ID',
    PRIMARY KEY (id)
) ENGINE=InnoDB COMMENT='办公用品申请单';

值得注意的几点：

  • 字段命名自动遵循项目约定（snake_case，creator/create_time/updater/update_time/deleted/tenant_id 基础字段齐全）
  • 多租户字段tenant_id 自动加上，因为 AI 从 @引用的模块中学到了这个约定
  • 索引和约束在生成的完整版本中也包含（这里省略了部分字段和索引以节省篇幅）

3.3 Step 3：AI 生成后端代码

接下来让 AI 生成后端的完整 CRUD 代码。Cursor 的 Agent 模式会自动创建所需的所有文件：

Controller 层——遵循 RESTful 规范，自带 Swagger 注解和权限校验：

@Tag(name = "管理后台 - 办公用品台账")
@RestController
@RequestMapping("/oa/supply-info")
@Validated
public class SupplyInfoController {

    @Resource
    private SupplyInfoService supplyInfoService;

    @PostMapping("/create")
    @Operation(summary = "创建办公用品")
    @PreAuthorize("@ss.hasPermission('oa:supply-info:create')")
    public CommonResult<Long> createSupplyInfo(
            @Valid @RequestBody SupplyInfoSaveReqVO reqVO) {
        return success(supplyInfoService.createSupplyInfo(reqVO));
    }

    @GetMapping("/page")
    @Operation(summary = "获取办公用品分页")
    @PreAuthorize("@ss.hasPermission('oa:supply-info:query')")
    public CommonResult<PageResult<SupplyInfoRespVO>> getSupplyInfoPage(
            @Valid SupplyInfoPageReqVO pageReqVO) {
        return success(supplyInfoService.getSupplyInfoPage(pageReqVO));
    }
    // ... 更新、删除、详情接口
}

Service 层——包含完整的业务逻辑和事务管理：

@Service
@Validated
public class SupplyInfoServiceImpl implements SupplyInfoService {

    @Resource
    private SupplyInfoMapper supplyInfoMapper;

    @Override
    public Long createSupplyInfo(SupplyInfoSaveReqVO reqVO) {
        SupplyInfoDO supplyInfo = BeanUtils.toBean(reqVO, SupplyInfoDO.class);
        supplyInfoMapper.insert(supplyInfo);
        return supplyInfo.getId();
    }

    @Override
    public void updateSupplyInfo(SupplyInfoSaveReqVO reqVO) {
        validateSupplyInfoExists(reqVO.getId());
        SupplyInfoDO updateObj = BeanUtils.toBean(reqVO, SupplyInfoDO.class);
        supplyInfoMapper.updateById(updateObj);
    }

    @Override
    public void deleteSupplyInfo(Long id) {
        validateSupplyInfoExists(id);
        supplyInfoMapper.deleteById(id);
    }

    private void validateSupplyInfoExists(Long id) {
        if (supplyInfoMapper.selectById(id) == null) {
            throw exception(SUPPLY_INFO_NOT_EXISTS);
        }
    }
    // ... 分页查询、库存操作
}

AI 生成的代码有几个亮点：

  • 自动使用了项目封装的 BeanUtils.toBean 做对象转换
  • 异常处理用了全局错误码机制 throw exception(SUPPLY_INFO_NOT_EXISTS)
  • @Validated 注解自动加上
  • @Resource 注入（而非 @Autowired）符合项目约定

3.4 Step 4：AI 生成前端页面

前端代码生成同样使用 Agent 模式，AI 会参照已有模块生成 Vben Admin 风格的页面：

表单 Schema 定义——声明式配置，自动关联字典和远程数据源：

export function useFormSchema(): VbenFormSchema[] {
  return [
    {
      fieldName: 'supplyName',
      label: '物品名称',
      component: 'Input',
      rules: 'required',
      componentProps: { placeholder: '请输入物品名称' },
    },
    {
      fieldName: 'supplyType',
      label: '管理类型',
      component: 'ApiSelect',
      rules: 'required',
      componentProps: {
        api: () => getDictOptions(DICT_TYPE.OA_SUPPLY_MANAGEMENT_TYPE),
        labelField: 'label',
        valueField: 'value',
      },
    },
    {
      fieldName: 'unit',
      label: '计量单位',
      component: 'Input',
      componentProps: { placeholder: '个/支/箱/台' },
    },
    {
      fieldName: 'stockQuantity',
      label: '库存数量',
      component: 'InputNumber',
      componentProps: { min: 0, precision: 0 },
    },
    {
      fieldName: 'warningQuantity',
      label: '预警数量',
      component: 'InputNumber',
      componentProps: { min: 0, precision: 0 },
    },
  ];
}

列表页——包含搜索、表格、操作按钮的完整页面骨架：

const [Grid, gridApi] = useVxeGrid({
  columns: [
    { field: 'supplyName', title: '物品名称', minWidth: 120 },
    {
      field: 'supplyType', title: '管理类型', width: 100,
      slots: { default: 'supplyType_default' },
    },
    { field: 'unit', title: '单位', width: 80 },
    { field: 'stockQuantity', title: '库存', width: 80 },
    { field: 'warningQuantity', title: '预警值', width: 80 },
    {
      field: 'status', title: '状态', width: 80,
      slots: { default: 'status_default' },
    },
    { field: 'createTime', title: '创建时间', width: 180, formatter: 'formatDateTime' },
    { title: '操作', width: 200, fixed: 'right', slots: { default: 'actions' } },
  ],
  proxyConfig: {
    ajax: { query: async ({ page }) => getSupplyInfoPage({ ...page, ...gridApi.formValues }) },
  },
  toolbarConfig: { buttons: [{ code: 'create', name: '新增', status: 'primary' }] },
});

image.png

从需求描述到生成一个完整的 CRUD 模块（3 张表、后端 Controller/Service/Mapper/VO、前端列表页/表单页/详情页），AI 总共花了约 30 分钟，人工审查和微调又花了 30 分钟。同样的工作量，纯手写至少需要 2-3 天。

四、实战场景 2：用 AI 生成 BPM 工作流集成

CRUD 生成相对标准化，真正考验 AI 能力的是BPM 工作流集成——这涉及到 Flowable 引擎的回调机制、状态流转、异步通知等复杂逻辑。

4.1 挑战：FlowBillService 接口

RuoyiOffice 的 BPM 模块定义了统一的 FlowBillService 接口，所有需要接入审批流程的业务模块都必须实现这个接口：

public interface FlowBillService {
    /** 提交流程后回调 */
    void afterSubmit(String processInstanceId, Long businessId);
    /** 审批通过回调 */
    void afterApprove(String processInstanceId, Long businessId);
    /** 审批拒绝回调 */
    void afterReject(String processInstanceId, Long businessId);
    /** 流程取消/撤回回调 */
    void afterCancel(String processInstanceId, Long businessId);
    /** 删除业务数据时清理流程 */
    void cleanProcess(Long businessId);
}

这个接口不复杂，但实现逻辑涉及：状态同步、业务校验、异常处理、事务一致性。新人手写很容易遗漏边界情况。

4.2 AI 生成的集成代码

让 AI 参考 @oa_seal_apply（用印申请）的 FlowBillService 实现，为办公用品申请生成对应代码：

@Service
@Validated
public class SupplyApplyFlowBillServiceImpl implements FlowBillService {

    @Resource
    private SupplyApplyMapper supplyApplyMapper;
    @Resource
    private SupplyItemMapper supplyItemMapper;

    @Override
    @Transactional(rollbackFor = Exception.class)
    public void afterApprove(String processInstanceId, Long businessId) {
        // 1. 校验申请单存在
        SupplyApplyDO apply = validateApplyExists(businessId);
        // 2. 更新申请单审批状态
        supplyApplyMapper.updateById(new SupplyApplyDO()
                .setId(businessId).setBpmStatus(BpmProcessStatusEnum.APPROVE.getStatus()));
        // 3. 所有明细项状态从"申请中"变为"待领用"
        supplyItemMapper.updateStatusByApplyId(
                businessId,
                SupplyItemStatusEnum.APPLYING.getStatus(),
                SupplyItemStatusEnum.PENDING_RECEIVE.getStatus());
    }

    @Override
    @Transactional(rollbackFor = Exception.class)
    public void afterReject(String processInstanceId, Long businessId) {
        supplyApplyMapper.updateById(new SupplyApplyDO()
                .setId(businessId).setBpmStatus(BpmProcessStatusEnum.REJECT.getStatus()));
    }

    @Override
    @Transactional(rollbackFor = Exception.class)
    public void cleanProcess(Long businessId) {
        supplyApplyMapper.updateById(new SupplyApplyDO()
                .setId(businessId)
                .setBpmStatus(BpmProcessStatusEnum.CANCEL.getStatus())
                .setProcessInstanceId(""));
    }
    // ... afterSubmit, afterCancel
}

AI 理解了几个关键模式：

  • 审批通过后需要联动子表状态（明细项从"申请中"变为"待领用"）
  • 事务注解不能遗漏，状态流转必须原子性
  • 异常校验在操作前执行
  • 状态枚举使用项目统一的 BpmProcessStatusEnum

这段代码几乎不需要人工修改就能直接使用——因为 AI 从 @引用 的用印申请模块中完整学习了回调模式。

4.3 关键洞察

BPM 集成是我们使用 AI 编程最"惊艳"的场景之一。原因是：

  1. 模式高度一致：所有业务模块的 FlowBillService 实现结构相似，AI 善于识别和复现模式
  2. 上下文决定质量：提供一个高质量的参考实现（@引用），AI 的输出质量显著提升
  3. 边界条件完整：AI 不会"忘记"处理拒绝、取消、清理等边缘路径，而人手写时经常遗漏

五、实战场景 3：用 AI 转换 PC 端到移动端

RuoyiOffice 的 PC 端基于 Vben Admin（Ant Design Vue），移动端基于 UniApp（wot-design-uni）。两端的组件库、布局方式、交互模式完全不同。

5.1 挑战：跨框架转换

将一个 PC 端页面转换为移动端页面，涉及：

维度 PC 端（Vben Admin） 移动端（UniApp）
组件库 Ant Design Vue wot-design-uni
表格 VxeTable（复杂表格） 列表卡片（wd-card）
表单 VbenForm（Schema 驱动） wd-form + wd-input 手写
路由 Vue Router uni.navigateTo
状态管理 Pinia Pinia（UniApp 版）
布局 左侧菜单 + 内容区 底部 Tab + 页面栈

传统做法是开发者一个页面一个页面地手工"翻译"，每个页面需要 2-4 小时。

5.2 AI 转换过程

我们为 Cursor 编写了专门的 Skill（技能文件），告诉 AI 如何做 PC→移动端转换。AI 会：

  1. 读取 PC 端页面代码：理解数据结构、API 调用、业务逻辑
  2. 转换 API 层：将 import { getXxxPage } from '@/api/oa/xxx' 转为 UniApp 的 API 调用方式
  3. 生成列表页：VxeTable → wd-card 卡片列表，包含下拉刷新和分页加载
  4. 生成表单页：VbenForm Schema → wd-form 手写表单，包含数据校验
  5. 生成详情页：信息展示 + 审批操作按钮
  6. 注册路由和菜单：自动添加到 UniApp 的 pages.json 和菜单配置

一次性生成 5 个文件（API 层 + 列表页 + 创建页 + 详情页 + 搜索页），从执行到完成大约 30 分钟——这在手工转换中需要 2-3 天。

5.3 转换效果对比

以"办公用品申请列表"为例：

PC 端——复杂表格，支持多列排序、筛选、分页：

// PC 端：VxeTable 列定义
columns: [
  { type: 'checkbox', width: 50 },
  { field: 'applyNo', title: '申请编号', minWidth: 140, sortable: true },
  { field: 'userName', title: '申请人', width: 100 },
  { field: 'bpmStatus', title: '审批状态', width: 100, slots: { default: 'bpmStatus_default' } },
  { field: 'createTime', title: '申请时间', width: 180, formatter: 'formatDateTime' },
  { title: '操作', width: 200, fixed: 'right', slots: { default: 'actions' } },
]

移动端——AI 自动转换为卡片式列表：

<template>
  <wd-pull-refresh v-model="refreshing" @refresh="onRefresh">
    <view class="list-container">
      <wd-card v-for="item in list" :key="item.id" @click="goDetail(item.id)">
        <template #title>
          <view class="card-header">
            <text class="apply-no">{{ item.applyNo }}</text>
            <wd-tag :type="getStatusType(item.bpmStatus)">
              {{ getStatusLabel(item.bpmStatus) }}
            </wd-tag>
          </view>
        </template>
        <view class="card-body">
          <text>申请人：{{ item.userName }}</text>
          <text>申请时间：{{ formatDate(item.createTime) }}</text>
        </view>
      </wd-card>
    </view>
  </wd-pull-refresh>
</template>

AI 在转换过程中自动处理了：

  • 布局变化：横向表格 → 纵向卡片
  • 交互变化：分页按钮 → 下拉刷新 + 滚动加载
  • 组件替换：wd-tag 替代 dict-tag
  • 导航方式：router.push → uni.navigateTo

六、AI 编程的关键技巧

经过 3 个月的实践，我们总结了一套让 AI 编程效果最大化的技巧：

6.1 技巧总览

技巧 说明 效果
编写 Cursor Rules 项目规范、命名约定、架构约束写成 Rules 文件 所有生成代码风格统一，减少 60% 的修改量
@引用相似模块 用 @file 让 AI 学习已有模块的代码模式 生成代码与项目一致性极高
分步骤生成 先 DDL → 再后端 → 再前端，每步审查 问题在每步都能发现，避免积累到最后
Agent 模式批量操作 多文件修改一次完成 一个需求涉及 10+ 文件，Agent 一次搞定
持续反馈优化 指出具体问题让 AI 迭代 2-3 轮即可收敛到满意质量
建立提示词模板 常用需求描述模板化 团队成员都能高效使用 AI

6.2 Cursor Rules 的威力

Cursor Rules 是我们效率提升最大的单一因素。在 .cursor/rules/ 目录下，我们维护了项目级别的规则文件：

.cursor/rules/
├── project-overview.mdc      # 项目全景（技术栈、目录结构、模块清单）
├── cursorrules-vben-framework.mdc  # Vben 框架使用规范
└── ...

project-overview.mdc 文件会在每次 AI 对话时自动加载（alwaysApply 模式），确保 AI 始终了解项目的全貌——技术栈版本、包命名规范、目录结构、模块关系。

有了 Rules 之后，你不需要每次都告诉 AI "我们用的是 Spring Boot 3.5"“Mapper 文件放在 xxx 包下”“前端用 Vben Admin”——AI 已经知道了。

6.3 @引用的最佳实践

@引用 是 Cursor 最强大的功能之一。在我们的实践中，最有效的引用策略是：

  1. 新建模块时：@一个已完成的同类模块，让 AI 学习完整的代码结构
  2. 改 Bug 时：@报错的文件 + @相关的配置文件，给 AI 足够的上下文
  3. 写测试时：@被测试的 Service + @已有的测试文件，让 AI 理解测试风格

一个典型的 prompt 示例：

请参考 @ruoyi-office/yudao-module-oa/yudao-module-oa-biz/src/main/java/cn/iocoder/yudao/module/oa/service/seal/ 
用印申请模块的代码结构，为"公车申请"模块生成完整的后端代码（Controller/Service/Mapper/VO/DO）。
业务规则：公车申请需要选择车辆、起止时间、用车事由，审批通过后自动占用车辆时间段。

七、AI 编程的局限与应对

我们不想只展示 AI 的光鲜面。在 3 个月的实战中，我们也遇到了不少 AI 搞不定的场景。

7.1 复杂业务逻辑需要人工介入

AI 擅长"模式化"的代码生成，但面对复杂的业务规则组合时会力不从心。

例如，差旅报销模块中的费用校验逻辑：

- 交通费需要根据员工职级匹配差旅标准（飞机/高铁/火车）
- 住宿费不能超过出差城市的限额
- 餐补按实际天数自动计算，跨城市需要拆分
- 超标部分需要走额外审批

这种"多维度交叉"的业务逻辑，AI 能生成一个大致框架，但细节经常出错——比如忽略了跨城市的餐补拆分场景。最终方案是 AI 生成 70% 的骨架代码，人工补充 30% 的细节逻辑。

7.2 安全相关代码必须人工审查

任何涉及权限校验、数据隔离、SQL 注入防护的代码，我们都会进行逐行人工审查。AI 生成的代码在安全方面有两个隐患：

  1. 权限校验不够精细：AI 可能只加了 @PreAuthorize 注解，但遗漏了数据权限（如"部门经理只能看本部门数据"）
  2. SQL 拼接风险：在复杂查询场景中，AI 偶尔会使用字符串拼接而非参数化查询

应对策略：安全相关代码的 Code Review 永远由人工完成，不依赖 AI 的自信判断。

7.3 性能优化需要经验判断

AI 能写出正确的代码，但不一定能写出高性能的代码。典型场景：

  • N+1 查询：AI 在处理关联查询时倾向于循环调用 Mapper，而非使用 Join 或批量查询
  • 缓存策略：AI 不了解实际的流量特征，无法判断哪些数据适合缓存
  • 索引设计：AI 能创建基本索引，但复合索引的列顺序需要根据实际查询模式判断

应对策略：AI 生成初版代码后，由有经验的开发者做性能审查，重点关注数据库查询和缓存逻辑。

7.4 测试用例仍需补充

AI 能生成基础的单元测试（Happy Path），但对边界条件的覆盖不够全面。例如：

  • 并发场景（两人同时申请最后一件库存物品）
  • 异常流程（审批中途发起人撤回，同时审批人已通过）
  • 数据边界（超大数量、负数、空值）

应对策略：AI 生成基础测试用例作为起点，人工补充边界条件和异常路径测试。

八、效率数据：到底快了多少？

以下数据基于 RuoyiOffice 项目中多个模块的实际开发耗时统计（取平均值），对比了纯手工开发和 AI 辅助开发的时间消耗：

8.1 单模块开发效率对比

开发环节 传统方式 AI 辅助 效率提升 备注
数据库设计（DDL） 2 小时 15 分钟 8x 含字段设计、索引、约束
后端 CRUD 代码 4 小时 30 分钟 8x Controller/Service/Mapper/VO/DO
前端页面 6 小时 1 小时 6x 列表页 + 表单页 + 详情页
BPM 流程集成 3 小时 30 分钟 6x FlowBillService + 状态管理
移动端适配 2 天 30 分钟 10x+ PC 端 → UniApp 完整转换
单元测试 2 小时 30 分钟 4x 基础测试用例
人工审查与微调 — 1-2 小时 — AI 输出的必要审查时间

8.2 项目整体效率

指标 数据
项目总模块数 14 个业务模块
AI 辅助覆盖率 约 80% 的初始代码由 AI 生成
平均迭代轮次 每个模块 AI 生成后需 2-3 轮反馈修正
总开发周期 3 个月（传统估算 12+ 个月）
核心开发人数 2-3 人（传统估算 6-8 人）

8.3 效率提升的真实含义

需要澄清一点：效率提升不等于"AI 写了所有代码"。

更准确的表述是——AI 接管了大量重复性、模式化、低创造性的编码工作（CRUD 骨架、页面模板、接口定义、数据转换逻辑），让开发者能将精力集中在架构设计、业务逻辑、性能优化、安全审计等高价值环节。

这就像有了洗碗机，厨师还是要自己做菜，但再也不用花时间洗碗了。

九、团队协作中的 AI 编程实践

AI 编程不仅是个人效率工具，在团队协作中同样发挥了重要作用。

9.1 新人上手加速

RuoyiOffice 项目有完善的 Cursor Rules 和提示词模板（存放在 ruoyi-office-prompt/ 目录下）。新成员加入后：

  1. 第 1 天：阅读 project-overview.mdc，了解项目架构
  2. 第 2 天：跟着提示词模板，用 AI 生成一个简单模块
  3. 第 3 天：已经能独立使用 AI 进行业务模块开发

传统方式下，新人至少需要 1-2 周 才能独立写出符合项目规范的代码。AI 将这个时间压缩到了 2-3 天。

9.2 代码一致性保障

14 个业务模块由不同的开发者完成，但代码风格高度一致——这不是因为大家都严格遵守了代码规范文档（说实话没几个人会认真读规范文档），而是因为AI 始终在遵守 Cursor Rules 中定义的规范。

命名风格、包结构、异常处理、日志规范、注释格式——这些细节全部由 AI 统一保证。

9.3 提示词模板化

我们将常用的需求描述模式整理成了提示词模板：

模板 用途 包含内容
全局代码规范 所有模块通用 命名约定、异常处理、日志规范
流程表单生成规范 BPM 相关模块 FlowBillService 实现、状态机设计
PC 转 APP 规范 移动端开发 组件映射、布局转换、API 适配
业务模块生成 新模块开发 DDL → 后端 → 前端完整流程

十、写在最后

用 Cursor + Claude 开发 RuoyiOffice 的 3 个月里，我们最大的感受是——AI 编程的价值不在于"替代程序员"，而在于"重新定义程序员的工作重心"。

在 AI 出现之前，一个全栈开发者 70% 的时间花在写 CRUD、调样式、拼页面这些重复性工作上，只有 30% 的时间用于架构思考和业务创新。

现在比例反转了。AI 处理了大量机械性编码，开发者可以把大部分精力放在真正需要人脑的地方：

  • 需求分析：理解用户到底要什么（AI 不懂用户）
  • 架构设计：选择正确的技术方案（AI 只能给建议）
  • 业务建模：将复杂现实抽象为数据模型（AI 需要人指导）
  • 质量把控：安全、性能、可维护性的最终判断（AI 容易遗漏）

RuoyiOffice 的开发过程证明了一件事：AI 编程在企业级系统开发中是可行的、有效的、值得投入的。 但前提是——你需要建立一套规范化的 AI 协作流程（Rules + 提示词模板 + 审查机制），而不是指望 AI 一键出奇迹。

2026 年，AI 编程已经从"锦上添花"变成了"不用就落后"的生产力工具。如果你还没开始，现在正是时候。

💡 想要体验 RuoYi Office 的强大功能？

🌐 在线演示：http://ruoyioffice.com/web/（账号 admin / admin123）

💬 技术咨询：添加微信 17156169080，备注「RuoYi Office」

⭐ 如果觉得不错，请给个 Star 支持一下！
# spring boot # anti-design-vue # java # uni-app
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

GEO-AI 时代的数字增长新基建

avatar AtomGit开源社区
cover

2026年深圳GEO十大服务商排行榜：谁更懂中小微企业AI获客？

avatar AtomGit开源社区

C语言进阶篇（自定义类型）

int x;inty;}p1={1,2};int x;int y;int point;char ch;int main()

avatar AtomGit开源社区