企业级AI编程落地实战-研发篇

本文分享了企业级研发流程中如何深度应用Cursor AI工具提升研发效能的实践经验。文章对比了传统与AI辅助的研发流程差异，详细介绍了从概要设计、详细设计、编码、单测到代码审查各阶段的人机协作模式。重点展示了如何通过结构化文档、定制化提示词和分步验证机制，使AI成为高效的结对编程伙伴。同时分析了当前AI编程在准确性、代码库理解深度和业务上下文把握方面的局限性，展望了未来AI在自动化工作流和产品设计

遥远666

2054人浏览 · 2025-09-16 13:17:19

遥远666 · 2025-09-16 13:17:19 发布

3.4.1. 准备生成单测用例清单的提示词

3.4.2. Cursor生成单测用例清单

3.4.3. 准备生成单测代码的提示词

3.4.4. Cursor生成单测代码

3.5. CR阶段

3.5.1. 准备需要review的git commit的代码改动

3.5.2. 准备生成review报告的提示词

3.5.3. Cursor生成review报告

在AI重塑软件开发流程的浪潮中，工具选型是落地的第一步。面对市场上众多的AI编程工具，如Cursor、Claude Code、Trae、CodeBuddy、Qoder等，我们经过深入的对比与实践，最终选择Cursor作为核心的AI编程工具，以期为企业运营、产品、研发、测试及运维的全流程效能提升注入新动力。

本篇文章将作为系列分享的研发篇(Java后端为例)，详细阐述我们如何在设计、编码与团队协作中，将Cursor深度融合，使其成为每一位工程师的高效“结对编程”伙伴。

1. 前提

本篇文章主要聚焦分享Cursor在研发流程中的企业级实践案例，默认读者已经掌握了Cursor的安装、配置、rule、prompt等基础知识，因此关于这部分的内容不再赘述，有需要了解的读者可以阅读官方文档。

2. 研发流程对比

2.1. 传统研发流程

由下图可见，传统研发流程中所有阶段均由人类参与且开发为主要参与人员，具有环节多、任务繁重的特点。

2.2. AI研发流程

由下图可见，引入AI后一定程度释放了底层人力，人类角色由一级劳工进阶为更高一阶的设计、监督角色。

3. AI研发流程实践案例

下面详细介绍2.2.AI研发流程中的概设、详设、开发编码等各环节在企业实践中人类具体是怎么跟AI协作的。

3.1. 概要设计阶段

难易度：

关键词：沟通、理解、设计、拆分

人类职责：理解需求，熟悉业务和项目，能够将业务语言转化为面向AI的结构化‘技术自然语言’并拆分任务

AI职责：无

考虑团队内需求阶段产出的prd的复杂性(有些复杂需求涉及多个上下游、多个入口改动点等)及AI在当前阶段的融合还不够成熟，本阶段仍由人类进行概要设计，但是跟以往不同的是，产出的概要设计文档是面向Cursor的，因此概设文档中的任务拆解要足够细、足够具体、内容要结构化，以便于AI高质量地完成。下面给出一个简化后的电商履约业务需求的实现用于说明面向Cursor的概设文档应该如何拆分任务：

3.1.1. 简化后的业务需求说明

大致需求内容是退款模块应业务方要求需要增加一些字段，涉及新增字段赋值和在多个上下游之间传递参数。

3.1.2. 概设文档示例

3.1.3. 概设文档总结

如果涉及多个服务或多个上下游交互的，需要先按服务划分功能，然后每个功能需要细分到单一职责的可实现点，比如退款单新增字段，这个新增字段涉及到数据库表加字段、页面加字段展示、加字段后的业务代码中的赋值、下游取值传参等都需要拆分成单独的一个功能点，对于这样每个实现范围足够小、职责单一的任务AI再结合代码库的情况下能够做得比较好。

3.2. 详细设计阶段

难易度：

关键词：输入、输出、模板、提示词

人类职责：整理详设模板和设计提示词，提供输入材料给AI，并对AI输出结果进行复核和调整

AI职责：接收输入，规划、分析、执行，按要求输出结果

AI输出质量和准确性：

详设阶段由人类提供概设文档、详设文档模板和生成详设的提示词作为AI的输入，AI则负责输出详设文档，输出后人类需进行复核、勘误。下面给出Cursor操作步骤：

3.2.1. 准备详设文档模板

一般团队内部都有自己的详设文档模板，如果没有可以让cursor先生成一个然后自己再结合项目去调整。将文档模板转为markdown格式放到当前打开的项目目录下，我一般习惯放在.cursor/docs/input/template目录：

3.2.2. 准备生成详设的提示词

提示词内容如下：

# 目标
使用浏览器打开概设文档，并根据概设文档内容输出详设文档。

# 详设文档模板
详设文档模板放在.cursor/docs/input/template/详设文档模板.md

# 详设文档瀚出要求
## 1.日录要求
严格按照详设文档模板的目录输出详设文档，不要新增或删减模板的目录
## 2.内容要求
- 根据概设文档和当前项目代码输出详设内容，对于不确定的内容清在详设文档中备注'todo，请人工补充'，不要擅自捏造不存在的内容。
- 详设文档中梳理出的需要修改或删除的代码要严格从当前代码库中获取，不要擅自提造不存在的代码;需要新增的代码则要严格遵循当前代码库中代码风格去新增。
- 如果涉及画图，请使用plantUML
## 3.输出路径
输出的详设文档存放在.cursor/docs/output目录下

(注意：提示词中提到“使用浏览器打开概设文档”是因为内部在线文档设置了访问权限，因此安装了一个playwright的MCP工具，让cursor使用浏览器打开链接并读取)

3.2.3. Cursor生成详设

在cursor聊天窗口新建一个对话选择Agent模式和claude-4-sonnet模型，然后直接@概设在线文档链接、@详设文档模板和@生成详设的提示词即可

3.3. 开发编码阶段

难易度：

关键词：输入、输出、代码规范、提示词

人类职责：制定代码规范和设计提示词，提供输入材料给AI，并对AI输出结果进行复核和调整

AI职责：接收输入，规划、分析、执行，按要求输出结果

AI输出质量和准确性：

开发编码阶段由人类提供详设文档、代码规范rule和生成代码的提示词作为AI的输入，AI则负责输出代码，输出后人类需进行复核、勘误。下面给出Cursor操作步骤：

3.3.1. 准备代码规范rule

同理，这个跟项目相关的rule需要花时间自己结合项目具体情况去编写并在实践过程中不断调整优化，如果没有可以让cursor先生成一个然后自己再结合项目去调整。比如：

3.3.2. 准备生成代码的提示词

提示词示例：

# 目标
请你按照提供的详设文档，生成代码。

# 核心任务
## 1.文档分析与理解阶段
在动手编写代码前请确保已经理解提供的详设文档和项目代码。

## 2.代码生成阶段
根据我输入的功能点先实现详设文档中这一功能点章节的代码编写。

# 要求
1.你必须遵循以下核心原则:
(1)你生成的代码必须参考当前项目的代码风格、iava-coding-standards.mdc编码规范和阿里巴巴Java编码规范。
(2)如项目已有可用方法，必须考虑复用、或在现有方法上扩展、或进行方法重载，保证最小粒度改动，减少重复代码。

3.3.3. Cursor生成代码

在cursor聊天窗口新建一个对话选择Agent模式和claude-4-sonnet模型，然后直接@详设文档和@生成代码的提示词，并指定要实现的功能点(Tips：不要一次性让cursor实现详设的全部内容，一次实现一个功能点AI会做得更好，也方便人类review。一个功能点没问题后再继续下一个功能点的实现，直到完成详设的全部内容)

3.4. 单测编写阶段

难易度：

关键词：输入、输出、单测case、提示词

人类职责：设计提示词，提供输入材料给AI，并对AI输出结果进行复核和调整

AI职责：接收输入，规划、分析、执行，按要求输出结果

AI输出质量和准确性：

单元测试编写阶段由人类提供详设文档、生成单测用例清单的提示词和生成单测代码的提示词作为AI的输入，AI则负责先输出单测用例清单，然后人类进行复核、调整，再把合格的单测用例清单输入给AI，AI根据清单生成单测代码，最终人类对单测代码进行复核、勘误。下面给出Cursor操作步骤：

3.4.1. 准备生成单测用例清单的提示词

提示词示例：

# 生成单测用例清单

## 单测用例设计任务

### 背景
我有一个已经通过人类Review的详细设计文档，现在需要为其生成完整的单测用例清单

### 任务要求
请基于我提供的详细设计文档，生成完整的单测用例清单。需要覆盖以下维度:
1.功能测试用例
**正常流程测试**:基于设计文档中的主要业务流程
**边界条件测试**:针对设计中提到的边界值和限制条件
**业务规则测试**:验证设计文档中定义的所有业务规则

2.异常测试用例
**输入参数异常**:nu11值、空值、格式错误、超长等
**业务异常**:设计文档中定义的各种业务异常场景
**系统异常**:数据库连接失败、外部服务调用失败等

3.集成测试用例
**数据库操作**:验证设计中的CRUD操作
**外部服务调用**:验证与其他服务的交互
**缓存操作**:验证缓存的读写逻辑

4.性能测试用例
**响应时间**:验证关键操作的性能要求
**井发处理**:验证并发场景下的行为

## 输出路径
输出的单测用例清单放在docs/output日录下

## 输出格式要求
请按以下格式输出测试用例:
```
## 用例清单
### 功能测试用例
#### TC-001: [用例名称]
- **测试目标**: [基于设计文档的具体目标]
- **前置条件**: [测试执行前的必要条件]
- **输入数据**: [具体的测试数据]
- **预期结果**: [基于设计文档的预期行为]
- **覆盖的设计点**: [对应设计文档的哪些部分]

### 异常测试用例
#### TC-101: [异常用例名称]
- **测试目标**: [异常场景验证目标]
- **触发条件**: [如何触发该异常]
- **输入数据**: [导致异常的测试数据]
- **预期异常**: [预期的异常类型和消息]
- **覆盖的设计点**: [对应设计文档的异常处理部分]

### 集成测试用例
#### TC-201: [集成用例名称]
**测试目标**: [集成点验证目标]
**依赖服务**: [涉及的外部依赖]
**Mock策略**: [如何模拟外部依赖]
**预期交互**: [期望的服务间交互行为]
**覆盖的设计点**: [对应设计文档的集成部分]
```

## 注意事项
1. 测试用例必须严格基于设计文档，不能基于现有代码实现
2. 每个用例都要明确标注覆盖的设计点
3. 确保测试用例的完整性和覆盖度
4. 考虑业务场景的复杂性和边界情况

3.4.2. Cursor生成单测用例清单

在cursor聊天窗口新建一个对话选择Agent模式和claude-4-sonnet模型，然后直接@详设文档和@生成单测用例清单的提示词：

3.4.3. 准备生成单测代码的提示词

提示词示例：

# 生成单测代码
## 单测代码生成任务
### 背景
基于我提供的测试用例清单，现在需要生成具体的单测代码实现。

### 目标代码信息
- **类名**: [待测试的类名]
- **方法名**: [待测试的方法名]
**技术栈**: Java 1.8 + Spring Boot + MyBatis-Plus + JUnit 5 + Mockito

### 代码生成要求
1.测试类结构
```java
@ExtendWith(MockitoExtension.class)
class[className]Test {

    @Mock
    private [Dependency] mockDependency;

    @InjectMocks
    private [Targetclass] targetclass;

    // 测试方法按用例清单实现
}
```

2. 测试方法命名规范
- 功能测试: `test[MethodName]_[scenario]_[ExpectedResult]()`
- 异常测试: `test[MethodName]_[Exceptionscenario]_ThrowsException()`
- 集成测试: `test[MethodName]_[IntegrationPoint]_[ExpectedBehavior]()`

3. 测试方法结构
```java
@Test
@Displayame("Tc-001:[测试用例描述]")
void test[MethodName][scenario][ExpectedResult]() {
    // Given -基于测试用例的前置条件和输入数据

    // when-执行被测试方法
    
    // Then验证预期结果(基于测试用例的预期结果)
```

4. Mock策略
- **数据库操作**: Mock Repository/Mapper
- **外部服务**: Mock Feign client
- **缓存操作**: Mock Redis Template
- **工具类**: Mock静态方法(使用Mockedstatic)

5. 断言要求
- 使用Assert进行流畅断言
- 验证方法返回值
- 验证Mock对象的调用次数和参数
- 验证异常类型和消息

6. 测试数据构造
- 使用Builder模式构造复杂对象
- 提取公共的测试数据构造方法
- 保持测试数据的可读性和维护性

## 输出要求
1. 生成完整的测试类代码，如果已有单测则无需重复生成
2.每个测试方法都要有详细注释，说明对应的测试用例
3. 包含必要的import语句
4. 代码要符合Java编码规范
5. 确保测试代码的可维护性和可读性

## 输出路径
单测代码输出在对应工程的src/test/java日录下

## 验证清单
生成代码后，请检查:
- 所有测试用例都有对应的测试方法
- Mock对象配置正确
- 测试数据构造合理
- 断言覆盖所有预期结果
- 异常测试正确验证异常类型
- 代码符合命名规范
- 注释清晰完整

3.4.4. Cursor生成单测代码

在cursor聊天窗口新建一个对话选择Agent模式和claude-4-sonnet模型，然后直接@单测用例清单和@生成单测代码的提示词：

3.5. CR阶段

难易度：

关键词：输入、输出、git commit、提示词

人类职责：设计提示词，提供输入材料给AI，参考AI输出的review报告进行代码调整

AI职责：接收输入，规划、分析、执行，按要求输出结果

AI输出质量和准确性：

每个开发将自己的代码合入测试分支前先提供详设文档、代码规范rule、git commit的代码改动、生成review报告的提示词作为AI的输入，让AI先帮忙进行第一轮的CR，开发根据AI输出的review报告修复规范、语法等基础性问题，这样第二轮人类进行代码评审会议时可以更聚焦业务，评审效率也更高。下面给出Cursor操作步骤：

3.5.1. 准备需要review的git commit的代码改动

可以直接cursor中直接@关键词，比如我们的commit都要求贴上需求id，那么可以@需求id：

3.5.2. 准备生成review报告的提示词

提示词示例：

## 目标
根据提供的详设文档和代码规范规则，深入分析指定gitcommit的代码改动，生成全面的代码review报告。

## 分析要求
### 1. 改动范围识别
- 识别本次commit涉及的所有文件类型(Java、properties、xm1等，直接分析本次改动的内容，不用执行git命令
- 按照分层架构对改动文件进行分类
- 统计新增、修改、删除的文件数量和代码行数

### 2. 码规范检查
严格按照iava-coding-standards.mdc规则检查:
- **代码风格**:缩进、命名规范、行长度等
- **分层架构**:模块分层是否正确，依赖关系是否合理
- **响应格式**:API层和ctr1层响应格式是否符合规范
- **异常处理**:是否使用NDSException，异常信息是否支持国际化
- **日志规范**日志级别、格式是否正确
- **注释规范**:JavaDoc和行内注释是否完整

### 3.业务逻辑分析
参考business-module-analvsis.mdc规则:
- **调用链路**:分析新增或修改的业务流程调用链
- **数据处理**:检查集合处理、空值检查、分批处理等
- **外部集成**:分析与xx、xx、xx等防腐层的交互
- **事务管理**:检查事务范围和一致性处理
- **性能考虑**:识别潜在的性能问题

### 4.架构影响评估
参考technology-architecture.mdc规则:
- 分析改动对现有架构的影响
- 检查是否引入新的技术栈或依赖
- 评估对其他模块的潜在影响
- 识别可能的向后兼容性问题

## 瀚岀格式
### 一、改动概览
```
- 涉及文件数:x个(新增个，修改z个，删除w个)
- 代码行数变化:+x-Y
- 主要改动模块:[列出涉及的主要模块]
- 改动类型:[功能新增/Bug修复/重构/配置调整等]
```

### 二、分层架构分析
按照分层结构分析每层的改动:
- **xx层改动**:接口定义变更、请求响应模型变化
- **xx层改动**:业务逻辑变更、外部调用变化
- **xx层改动**:控制器接口变更
- **xx层改动**:定时任务逻辑变更
- **xx层改动**:配置文件、启动脚本变更

### 三、代码规范检查结果
```
符合规范的方面:
-【列出符合规范的检查项】

需要关注的问题:
- [列出轻微违规或需要改进的地方]

违反规范的问题:
- [列出明确违反编码规范的问题]
```

### 四、业务逻辑影响分析
- **新增业务流程**:描述新增的业务处理逻辑
- **修改业务流程**:对比修改前后的业务逻辑差异
- **数据流变化**:分析数据处理流程的变化
- **外部依赖影响**:评估对外部系统调用的影响

### 五、潜在风险识别
```
高风险:
- [可能导致系统故障或数据问题的改动]

中风险:
- [可能影乡响性能或用户体验的改动]

低风险:
- [影乡向较小的改动]
```

### 六、性能影响评估
- **数据库操作**:新增或修改的SQL操作性能分析
- **缓存策略**:缓存使用的合理性
- **资源消耗**:内存、CPU使用评估

### 七、改进建议
- **代码优化**:代码质量改进建议
- **架构优化**:架构设计改进建议
- **最佳实践**:符合团队最佳实践的建议

### 八、总体评价
```
综合评分:X/10分
主要优点:[列出改动的优点]
主要问题:[列出需要解决的主要问题]
是否建议合并:[是/否，并说明理由]
```