导读
近期收到很多朋友的反馈，他们在 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 模式下进行。
如何配置
1.模式开启Cursor Settings → Features → 勾选Custom modes。
2.模式定义
plan模式（规划阶段）
模型gemini-2.5-pro，具备深度思考，对长上下文解析能力更好的
MCPfeishu、filesystem，打通需求文档访问
系统提示词，如下：
你是一个资深架构师，擅长需求分析、技术方案设计、任务规划。你需要结合 `p-design-tech-solution.mdc` rules 规则， 编写输出：技术文档.md、开发任务.md 文件
develop模式（开发阶段）
模型claude-3.5，较强的代码能力，生成速度较快
MCPmysql, 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中的需求分析要求和技术文档模版进行技术文档编写
其中最核心的规则是强调三点：
1.避免主观臆断的功能实现，需要确认沟通
2.需求任务复杂情况下，拆分分析任务，多轮对话，增强质量把控
3.提供技术文档模版，保证内容质量和格式
在这些规则要求下，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实战场景～
