AI 编程业务开发提效 30+% 实战：Cursor 配置 + 工具 + 全流程拆解-CSDN博客

本文链接：https://blog.csdn.net/m0_59235945/article/details/148083427

近期收到许多同事和朋友的反馈，他们在 AI 编程中遇到了各类问题：

如何高效使用 Rules 和 MCP？当前使用门槛较高，是否有最佳实践？
如何让 AI 在处理复杂需求时表现更优？
面对架构复杂的老项目，AI 处理效果不佳，如何解决？
希望生成简单代码时，AI 输出却过于复杂，如何优化？

经过数月在业务场景中深度应用 AI 编程（覆盖全新项目开发、老项目代码重构及新模块扩展），我深刻体会到 AI 的优势与局限。经过团队对AI 工程化建设、MCP 工具开发等实践，探索出一套低门槛、高质量的 AI 编程落地方案。本文将从以下两部分展开：

AI 编程基础配置：详解项目中 Rules、MCP 及自定义模式的配置实践。
AI 开发全流程：剖析不同场景下（新项目 / 老项目）的完整开发流程，涵盖计划、编码、复盘核心环节，通过标准化流程释放 AI 编程效能。

相信看完这篇文章对上面的问题会有答案并将AI编程更好的落地业务开发。

AI 编程基础配置

1. Rules 配置;

前置条件：确认项目已具备以下核心 Rules 文档：

项目架构（包含目录结构、技术栈、业务分层）
技术方案编写规范
代码开发规范（命名、注释、格式）
功能开发流程模板
代码提交与评审规范

文档价值：传统开发中，系统化文档可降低重复培训成本；而 AI 缺乏长期记忆，每次会话相当于 “新成员入职”，标准化文档是 AI 理解项目的核心依据

文档组织最佳实践

集中存储：将 Rules 统一存放于项目根目录 .cursor/rules 下，便于 Cursor 自动引用。
场景化分类：按开发阶段命名文件前缀，示例目录结构如下：

.
├── plan
│   └── p-design-tech-solution.mdc            // 技术方案编写规范、模板
├── develop
│   ├── d-gen-data-center-crud-from-sql.mdc   // d-gen 开头的是总结的某类功能的代码生成模版、开发流程。
│   ├── d-gen-cronjob.mdc                     // cronjob 开发流程、代码模板;
│   ├── d-gen-api.mdc                         // http api 开发流程、代码模板;
│   └── d-test-unit-test.mdc                  // 单元测试规范、模板
└── review
├── r-code-review.mdc                      // 代码评审规范
├── r-git-commit.mdc                       // commit message 规范
├── r-merge-request.mdc                    // 创建远程合并请求流程
└── r-summary-sop.mdc                      // 总结本次代码修改的标准流程生成 p-gen-xx 文件，供下次开发使用
├── g-code-spec.mdc                            // 项目代码规范
├── g-project-hotkey.mdc                       // 项目中的 hotkey 比如\`提示语中出现 cr 则参考 xxx.rules 执行\`
├── g-project-structure.mdc                    // 项目结构、技术架构、业务架构...
├── g-system.mdc                               // 项目 AI 聊天规范，比如强调多轮对话、引导补全...

根目录规则文件：作为项目默认规范，配置 RuleType 为 Always、Auto Attached、Auto Request，在对话中自动携带。

子目录规则文件：仅在特定场景使用，配置 RuleType 为 Manul、Auto Request。

rules 统一整理到了 https://github.com/xyzbit/AI-Coding

Rules 维护技巧

老项目规则生成：结合 /Generate Cursor Rules 快捷命令生成部分规则。
开发后总结：代码提交阶段，让 AI 结合代码变更和聊天记录总结生成功能开发规范。

优质 Rules 参考：Cursor.directory/rules

2.自定义模式配置

在开发不同阶段配置不同自定义模式，模式的名称可与规则子目录一致，分为 plan、develop

最开始还有一个 review 模式，用于代码提交、本地Code Review等，但是使用一段时间发现经常会忘记切换模式。分析了一下原因，主要是因为以前没有本地 Code Review、总结代码模版等操作，这是为了更好的AI编程效果而无中生有的步骤，大多数人没有这个使用习惯。所以最终还是让这些步骤统一在 develop 模式下进行。

如何配置

模式开启Cursor Settings → Features → 勾选 Custom modes。
模式定义

plan 模式（规划阶段）
- 模型 gemini-2.5-pro，具备深度思考，对长上下文解析能力更好的
- MCP feishu、filesystem，打通需求文档访问
- 系统提示词，如下：

你是一个资深架构师，擅长需求分析、技术方案设计、任务规划。
你需要结合 `p-design-tech-solution.mdc` rules 规则， 编写输出：技术文档.md、开发任务.md 文件

develop 模式（开发阶段）
- 模型 claude-3.5，较强的代码能力，生成速度较快
- MCP mysql, gitlab, codeup等，打通数据库，代码仓库
- 系统提示词，如下：

你是一个资深开发，擅长各种语言、设计模式、算法，你对代码的质量有极高的要求。

# 开发阶段流程规范
## 任务维护
1. 详细阅读 `技术文档.md`,`开发任务.md`，明确任务目标、功能需求和技术要求
2. 每完成一个子任务，立即更新 `开发任务.md` 中的对应任务状态
## 开发执行
1. 按照`开发任务.md`逐步进行代码实现，每完成一个任务后，简要说明完成情况和主要改动点，提交给用户进行 review 确认
2. 确保代码符合项目架构和设计模式，如无必要尽量保持简单实现
3. 对核心功能，可根据 `d-test-unit-test.mdc` 规则编写单元测试，保证代码质量和功能正确性

# 代码提交阶段流程规范
## 代码审查
1. 提交代码前，必须参考 rules `r-code-review.mdc` 中的规则进行全面的代码审查
2. 确保所有问题都得到解决后，方可进入下一步

## SOP生成（可选）
1. 询问用户是否需要将本次提交总结为代码模版或标准开发流程（SOP）
2. 如果用户需要，参考 rules `r-summary-sop.mdc` 中的规则进行生成
3. 将生成的SOP保存到 `./cursor/rules/develop` 目录下，文件名格式为 `d-gen-{自动分析功能生成的描述}.mdc`，例如 `d-gen-api-user-authentication.mdc`

## 最终提交
1. 检查前置工作是否完成
2. 代码提交参考 rules `r-git-commit.mdc`执行
3. 询问用户是否要推送到远端

很多人会分不清自定义模式下的系统提示词和 Cursor Rules 分别应该存放什么内容，觉得功能比较重复。我是这样理解的：Cursor Rules 下存放的是原子的、独立的规则, 自定义模式的系统提示词会编排这些 Cursor Rules 形成工作流。

3.MCP 配置

配置需求平台和代码平台打通的 MCP 工具。我们公司内部使用的是飞书项目、飞书文档来管理需求，Codeup 进行代码托管，主要提供搜索未完成需求、查询需求文档内容、提交合并请求等 tools，你可以根据公司内部的实际情况去使用或开发MCP工具。你可以先在如下网站寻找开源工具：

地址	特点
https://smithery.ai/	可以通过自然语言查找想要的MCP，复制命令便捷
https://glama.ai/mcp/servers	分类清晰
https://mcp.so/	官方内容

4.如何维护配置？

相信你也看出来了，配置一个项目还是比较繁琐的，如果有多个项目建议将 Rules 和 MCP 配置模版放在统一的代码仓库中统一维护，然后通过一个命令行工具可以快速拉取相关配置到项目中，大概效果如下：

一、AI 编程流程

功能实现可划分为三个阶段，在此过程中编码体检和效率应不断提升。

场景一：新项目或新模块开发

✏️ 计划阶段

好了完成了前置配置工作，终于可以开始愉快的开发工作了。第一步我们需要进行需求分析、方案设计、任务拆分，与AI达成共识，最终产出技术文档，并通过该文档指导AI后续编码工作。

切换到 plan 模式后，输入需求链接或需求文档链接+实现要求，AI 会根据 p-design-tech-solution.mdc 中的需求分析要求和技术文档模版进行技术文档编写其中最核心的规则是强调三点：

避免主观臆断的功能实现，需要确认沟通
需求任务复杂情况下，拆分分析任务，多轮对话，增强质量把控
提供技术文档模版，保证内容质量和格式

在这些规则要求下，AI会先生成一份大纲，比如：包含核心流程、数据库设计、API设计，核心功能伪代码等，但是每一部分内容比较简略，AI会与我们多轮沟通逐渐完善每一个部分。

最终我们会得到两份文档：技术文档.md、开发任务.md，用户可以在后续编码阶段使用。(若部门存在技术评审协作方面的要求，例如采用飞书文档来开展评审工作，这样便于大家进行评论。此时，可通过调用飞书 MCP，将 技术文档.md 转化生成一份飞书文档)

⌨️ 编码阶段

切换到 develop 模式后，结合开发任务.md+技术文档.md我们让AI进行开发。同时如果有同类功能开发的模版或SOP Rules，可以提供AI参考，提示词如下：

接着，我们需要不断对AI完成的任务做出评审反馈，完成后再进入下一个任务。

⚠️ 这里分享一个经验：如果超过2轮生成不符合要求，就可以去手动修改了，Cursor从代码修改中学习的速度比从解释中学习更快。

🧠 复盘阶段

如果你按照上面的前置配置部分内容进行了自定义模式配置，那么你可以通过类似开始提交流程 的关键词触发 代码审查-> sop|代码模版生成（可能有） -> 代码提交 -> 代码推送远端 的流程，如下：

在实际的开发中，我并不会每次提交都触发这个流程。大多数时候仍然是通过命令行或者Cursor中的Git插件提交并推送代码，这样效率更高。只有在代码开发接近尾声时会进行一次该流程，通过对比当前分支和主分支的差异进行完整分析。

ps: 通过Cursor中的Git插件进行 commit message 生成很好用,就是格式不易控制，需要自己微调一下。

场景二：老项目逻辑调整

在复杂的老项目对某个模块进行修改时，我们用 AI辅助分析+Tab辅助编码的形式的AI编码模式。因为我们要让AI全面理解项目的时间较长、难度较大，并且代码本来也不会特别多，所以这样更省时间。

✏️ 计划阶段

对老项目的改动我们求稳，让AI根据需求生成技术文档.md和开发任务.md时着重强调找到相关代码并确认改动点和风险点，这对刚接手项目的人也是一个快速了解项目的方式。

⌨️ 编码阶段

结合上一步的生成的 技术文档.md和开发任务.md，我们找到对应的改动点进行手动编码，Cursor 中的Tab模型在 0.5.0 后，使用体验上有质的飞跃，可以跨文件提示非常智能。

🧠 复盘阶段

同场景一

总结

通过标准化的 Rules 配置、场景化的模式设计及全流程的工具链打通，AI 编程已从 “实验性工具” 转变为 “可落地的生产力”。核心经验可总结为：

文档先行：用结构化 Rules 降低 AI 理解成本。
流程驱动：分阶段（计划→开发→复盘）规范操作，通过每个阶段对应的自定义模式让研发流程更规范、可控，也降低了使用门槛。
人机协同：复杂分析与简单编码交给 AI，关键逻辑由人工把控。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述