🌐 演示地址：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 | 💬 微信：（备注「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 编程在企业系统开发中的全貌。
市面上的 AI 编程工具不少，我们在 2025 年底启动 RuoyiOffice 项目时，对主流方案做了横向对比。
Cursor 是基于 VS Code 深度改造的 AI-Native IDE，核心优势在于AI 与编辑器的深度融合：
选择 Claude 作为背后的大模型，原因很直接：
长上下文理解：Claude 支持超长上下文窗口。在企业系统开发中，一个业务模块往往涉及十几个文件、上千行代码。Claude 能一次性理解整个模块的上下文，生成的代码与现有代码风格一致。
代码质量稳定：经过半年的实际使用，Claude 生成的 Java/TypeScript 代码质量明显优于其他模型——变量命名规范、异常处理完整、边界条件考虑充分。
中文理解能力强：企业系统中有大量中文业务术语（"用印申请""请假销假""转正审批"），Claude 能准确理解这些概念并映射到代码层面。
最终选择 Cursor + Claude 的决定性因素是 Agent 模式 + 长上下文——企业系统开发不是改一个函数那么简单，往往一个需求涉及跨模块的 10+ 文件修改，这正是 Cursor Agent 的强项。
▲ 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 是基于 RuoYi-Vue-Pro（Yudao）深度定制的企业管理一体化平台，支持单体和微服务双模式部署。它不是一个 demo，而是一套面向真实企业场景的生产级系统。
以"办公用品管理"模块为例，完整展示从需求描述到代码生成的全过程。
在 Cursor 中打开对话窗口，输入需求描述：
帮我设计并生成"办公用品管理"模块： 1. 业务概述：管理企业的办公用品台账、员工申请领用、行政发放、借用品归还 2. 数据模型： - oa_supply_info（用品台账）：名称、类型（消耗品/借用品）、单位、库存、预警值 - oa_supply_apply（申请单）：申请人、申请日期、审批状态、BPM流程ID - oa_supply_item（申请明细）：关联申请单、关联用品、申请数量、发放数量、归还数量、状态 3. 业务规则：消耗品发放后即完结，借用品需追踪归还 4. 请参考 @oa_seal_apply 用印申请模块的代码结构和命名规范 关键技巧在最后一行——用 @引用 让 AI 学习已有模块的代码模式。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 从 @引用的模块中学到了这个约定 - 索引和约束在生成的完整版本中也包含（这里省略了部分字段和索引以节省篇幅）
接下来让 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
createSupplyInfo( @Valid @RequestBody SupplyInfoSaveReqVO reqVO) { return success(supplyInfoService.createSupplyInfo(reqVO)); } @GetMapping("/page") @Operation(summary = "获取办公用品分页") @PreAuthorize("@ss.hasPermission('oa:supply-info:query')") public CommonResult
> getSupplyInfoPage( @Valid SupplyInfoPageReqVO pageReqVO) // ... 更新、删除、详情接口 }
Service 层——包含完整的业务逻辑和事务管理：
@Service @Validated public class SupplyInfoServiceImpl implements SupplyInfoService @Override public void updateSupplyInfo(SupplyInfoSaveReqVO reqVO) @Override public void deleteSupplyInfo(Long id) { validateSupplyInfoExists(id); supplyInfoMapper.deleteById(id); } private void validateSupplyInfoExists(Long id) } // ... 分页查询、库存操作 } AI 生成的代码有几个亮点：
- 自动使用了项目封装的
BeanUtils.toBean做对象转换 - 异常处理用了全局错误码机制
throw exception(SUPPLY_INFO_NOT_EXISTS) @Validated注解自动加上@Resource注入（而非@Autowired）符合项目约定
前端代码生成同样使用 Agent 模式，AI 会参照已有模块生成 Vben Admin 风格的页面：
表单 Schema 定义——声明式配置，自动关联字典和远程数据源：
export function useFormSchema(): VbenFormSchema[] { return [ { fieldName: 'supplyName', label: '物品名称', component: 'Input', rules: 'required', componentProps: { placeholder: '请输入物品名称' }, }, , }, { 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' }] }, }); 
从需求描述到生成一个完整的 CRUD 模块（3 张表、后端 Controller/Service/Mapper/VO、前端列表页/表单页/详情页），AI 总共花了约 30 分钟，人工审查和微调又花了 30 分钟。同样的工作量，纯手写至少需要 2-3 天。
CRUD 生成相对标准化，真正考验 AI 能力的是BPM 工作流集成——这涉及到 Flowable 引擎的回调机制、状态流转、异步通知等复杂逻辑。
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); } 这个接口不复杂，但实现逻辑涉及：状态同步、业务校验、异常处理、事务一致性。新人手写很容易遗漏边界情况。
让 AI 参考 @oa_seal_apply（用印申请）的 FlowBillService 实现，为办公用品申请生成对应代码：
@Service @Validated public class SupplyApplyFlowBillServiceImpl implements FlowBillService @Override @Transactional(rollbackFor = Exception.class) public void afterReject(String processInstanceId, Long businessId) @Override @Transactional(rollbackFor = Exception.class) public void cleanProcess(Long businessId) // ... afterSubmit, afterCancel } AI 理解了几个关键模式：
- 审批通过后需要联动子表状态（明细项从"申请中"变为"待领用"）
- 事务注解不能遗漏，状态流转必须原子性
- 异常校验在操作前执行
- 状态枚举使用项目统一的
BpmProcessStatusEnum
这段代码几乎不需要人工修改就能直接使用——因为 AI 从 @引用 的用印申请模块中完整学习了回调模式。
BPM 集成是我们使用 AI 编程最"惊艳"的场景之一。原因是：
- 模式高度一致：所有业务模块的 FlowBillService 实现结构相似，AI 善于识别和复现模式
- 上下文决定质量：提供一个高质量的参考实现（@引用），AI 的输出质量显著提升
- 边界条件完整：AI 不会"忘记"处理拒绝、取消、清理等边缘路径，而人手写时经常遗漏
RuoyiOffice 的 PC 端基于 Vben Admin（Ant Design Vue），移动端基于 UniApp（wot-design-uni）。两端的组件库、布局方式、交互模式完全不同。
将一个 PC 端页面转换为移动端页面，涉及：
传统做法是开发者一个页面一个页面地手工"翻译"，每个页面需要 2-4 小时。
我们为 Cursor 编写了专门的 Skill（技能文件），告诉 AI 如何做 PC→移动端转换。AI 会：
- 读取 PC 端页面代码：理解数据结构、API 调用、业务逻辑
- 转换 API 层：将
import from '@/api/oa/xxx'转为 UniApp 的 API 调用方式 - 生成列表页：VxeTable → wd-card 卡片列表，包含下拉刷新和分页加载
- 生成表单页：VbenForm Schema → wd-form 手写表单，包含数据校验
- 生成详情页：信息展示 + 审批操作按钮
- 注册路由和菜单：自动添加到 UniApp 的 pages.json 和菜单配置
一次性生成 5 个文件（API 层 + 列表页 + 创建页 + 详情页 + 搜索页），从执行到完成大约 30 分钟——这在手工转换中需要 2-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 自动转换为卡片式列表：
{{ item.applyNo }}
}
申请人：{{ item.userName }}
申请时间：{{ formatDate(item.createTime) }}
AI 在转换过程中自动处理了：
- 布局变化：横向表格 → 纵向卡片
- 交互变化：分页按钮 → 下拉刷新 + 滚动加载
- 组件替换：
wd-tag替代dict-tag - 导航方式：
router.push→uni.navigateTo
经过 3 个月的实践，我们总结了一套让 AI 编程效果最大化的技巧：
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 已经知道了。
@引用 是 Cursor 最强大的功能之一。在我们的实践中，最有效的引用策略是：
- 新建模块时：
@一个已完成的同类模块，让 AI 学习完整的代码结构 - 改 Bug 时：
@报错的文件 + @相关的配置文件，给 AI 足够的上下文 - 写测试时：
@被测试的 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 的光鲜面。在 3 个月的实战中，我们也遇到了不少 AI 搞不定的场景。
AI 擅长"模式化"的代码生成，但面对复杂的业务规则组合时会力不从心。
例如，差旅报销模块中的费用校验逻辑：
- 交通费需要根据员工职级匹配差旅标准（飞机/高铁/火车） - 住宿费不能超过出差城市的限额 - 餐补按实际天数自动计算，跨城市需要拆分 - 超标部分需要走额外审批 这种"多维度交叉"的业务逻辑，AI 能生成一个大致框架，但细节经常出错——比如忽略了跨城市的餐补拆分场景。最终方案是 AI 生成 70% 的骨架代码，人工补充 30% 的细节逻辑。
任何涉及权限校验、数据隔离、SQL 注入防护的代码，我们都会进行逐行人工审查。AI 生成的代码在安全方面有两个隐患：
- 权限校验不够精细：AI 可能只加了
@PreAuthorize注解，但遗漏了数据权限（如"部门经理只能看本部门数据"） - SQL 拼接风险：在复杂查询场景中，AI 偶尔会使用字符串拼接而非参数化查询
应对策略：安全相关代码的 Code Review 永远由人工完成，不依赖 AI 的自信判断。
AI 能写出正确的代码，但不一定能写出高性能的代码。典型场景：
- N+1 查询：AI 在处理关联查询时倾向于循环调用 Mapper，而非使用 Join 或批量查询
- 缓存策略：AI 不了解实际的流量特征，无法判断哪些数据适合缓存
- 索引设计：AI 能创建基本索引，但复合索引的列顺序需要根据实际查询模式判断
应对策略：AI 生成初版代码后，由有经验的开发者做性能审查，重点关注数据库查询和缓存逻辑。
AI 能生成基础的单元测试（Happy Path），但对边界条件的覆盖不够全面。例如：
- 并发场景（两人同时申请最后一件库存物品）
- 异常流程（审批中途发起人撤回，同时审批人已通过）
- 数据边界（超大数量、负数、空值）
应对策略：AI 生成基础测试用例作为起点，人工补充边界条件和异常路径测试。
以下数据基于 RuoyiOffice 项目中多个模块的实际开发耗时统计（取平均值），对比了纯手工开发和 AI 辅助开发的时间消耗：
需要澄清一点：效率提升不等于"AI 写了所有代码"。
更准确的表述是——AI 接管了大量重复性、模式化、低创造性的编码工作（CRUD 骨架、页面模板、接口定义、数据转换逻辑），让开发者能将精力集中在架构设计、业务逻辑、性能优化、安全审计等高价值环节。
这就像有了洗碗机，厨师还是要自己做菜，但再也不用花时间洗碗了。
AI 编程不仅是个人效率工具，在团队协作中同样发挥了重要作用。
RuoyiOffice 项目有完善的 Cursor Rules 和提示词模板（存放在 ruoyi-office-prompt/ 目录下）。新成员加入后：
- 第 1 天：阅读
project-overview.mdc，了解项目架构 - 第 2 天：跟着提示词模板，用 AI 生成一个简单模块
- 第 3 天：已经能独立使用 AI 进行业务模块开发
传统方式下，新人至少需要 1-2 周 才能独立写出符合项目规范的代码。AI 将这个时间压缩到了 2-3 天。
14 个业务模块由不同的开发者完成，但代码风格高度一致——这不是因为大家都严格遵守了代码规范文档（说实话没几个人会认真读规范文档），而是因为AI 始终在遵守 Cursor Rules 中定义的规范。
命名风格、包结构、异常处理、日志规范、注释格式——这些细节全部由 AI 统一保证。
我们将常用的需求描述模式整理成了提示词模板：
用 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）
💬 技术咨询：添加微信 ，备注「RuoYi Office」
⭐ 如果觉得不错，请给个 Star 支持一下！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/266074.html