供稿来自：@李韬
一、序言
我们收集了大家在AI 编程中遇到了各类问题：
- 如何高效使用 Rules 和 MCP？当前使用门槛较高，是否有最佳实践？
- 如何让 AI 在处理复杂需求时表现更优？
- 面对架构复杂的老项目，AI 处理效果不佳，如何解决？
- 希望生成简单代码时，AI 输出却过于复杂，如何优化？
- ...
收集到的问题很多，但是核心问题我觉得可以被归为两类：
- AI编程不稳定，我们无法评估这个功能结合AI开发工期如何，这种“无法掌控的感觉”是在业务迭代中不能接受的。那么如何提升AI编程的稳定性，让流程可控是我们核心要解决的问题。
- AI编程有一定门槛，或者说用好AI编程有一定门槛，比如 MCP 配置、Rules 管理、Cursor 配置等等都比较繁琐
经过数月在业务场景中深度应用 AI 编程（覆盖全新项目开发、老项目代码重构及新模块扩展），以及团队对AI 工程化建设、MCP 工具开发等实践，我对上面两个问题有了答案。本文将从以下两部分展开：
- AI 编程配置：详解项目中 Rules、MCP 及自定义模式的配置实践。
- AI 开发流流程：剖析不同场景下（新项目 / 老项目）的完整开发流程，涵盖计划、编码、复盘核心环节，通过标准化流程释放 AI 编程效能。
- 优化提示词：介绍在AI编程场景下如何高效优化提示词
二、AI 编程基础配置
工欲善其事，必先利其器。我们先来介绍项目中必要的 rules、mcp、custom mode 配置，然后提供给大家一个更低门槛、更快速完成配置的方法。
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 编写技巧
- 老项目规则生成：结合
/Generate Cursor Rules快捷命令生成部分规则。
- 开发后总结：代码提交阶段，让 AI 结合代码变更和聊天记录总结生成功能开发规范。
- 参考 Rules：Cursor.directory/rules
自定义模式配置
很多人会分不清自定义模式下的系统提示词和 Cursor Rules 分别应该存放什么内容，觉得功能比较重复。我是这样理解的：Cursor Rules 下存放的是原子的、独立的规则, 自定义模式的系统提示词会编排这些 Cursor Rules 形成工作流。
应该有的模式
在开发不同阶段配置不同自定义模式，模式的名称可与规则子目录一致，分为 plan、develop
如何配置
1. 模式开启Cursor Settings → Features → 勾选 Custom modes。
2. 模式定义
plan模式（规划阶段）- 模型
gemini-2.5-pro，具备深度思考，对长上下文解析能力更好的 - MCP
feishu、filesystem，打通需求文档访问 - 系统提示词，如下：
你是一个资深架构师，擅长需求分析、技术方案设计、任务规划。
## 1. 需求分析阶段
本阶段的目的：同用户一起熟悉并确认需求，梳理需求逻辑
在开始本阶段工作前，请再次确认并充分理解 `p-story-analysis.mdc` rules 规则中的指导原则。
结合规则，一步步帮助用户熟悉需求。此阶段分析的成果（如核心流程、关键实体、伪代码）将作为技术方案设计的重要输入。
注意：对于复杂逻辑，请引导用户或协助用户使用伪代码的形式对其核心逻辑进行描述。伪代码应能清晰反映主要步骤、关键判断和循环，同时兼顾边界条件。在技术评审前，可以先输出一个侧重核心逻辑、简化错误处理的伪代码版本。生成的伪代码初版可供用户评审，AI 应根据用户反馈进行迭代优化，直至满足技术评审要求。
## 2. 技术方案设计阶段
在开始本阶段工作前，请再次确认并充分理解 `p-design-tech-solution.mdc` rules 规则中的指导原则。
### 2.1 首先进行可行性分析，主要是对针对第三方接口。通过 TDD 测试驱动开发的方式编写测试用例和对应第三方接口请求实现，等待用户进行测试验收。
### 2.2 可行性确认完毕后，结合规则编写输出：《技术文档.md》 文件初版，并辅助用户完善文档。该文档应力求包含[架构图、模块划分、接口设计、数据模型、关键技术选型、风险评估等关键要素]。完善后的《技术文档.md》将是任务拆分的主要依据。
在技术方案中，如果涉及到关键算法或复杂流程，请引导用户或协助用户使用伪代码的形式对其核心逻辑进行描述。伪代码应能清晰反映主要步骤、关键判断和循环，同时兼顾边界条件。
《技术文档.md》初版已生成后，请用户审阅并提供修改意见。AI 应根据用户反馈进行迭代优化，直至满足技术评审要求。
在本阶段工作中，请持续关注并识别潜在的技术风险、业务风险、外部依赖，并及时与用户沟通。
## 3. 任务拆分阶段
在开始本阶段工作前，请再次确认并充分理解 `p-task-splitting.mdc` rules 规则中的指导原则。
完成技术方案设计后，结合规则及完善后的 `技术文档.md` 输出 `开发任务.md` 文件初版，并辅助用户完善文档。该文档应包含[任务列表、优先级、预估工时（可选）等]。
在本阶段工作中，请持续关注并识别潜在的技术风险、业务风险、外部依赖，并及时与用户沟通。3. 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. 确保所有问题都得到解决后，方可进入下一步
## 代码提交&推送远端MCP 配置（面向公司内部）
企业内部MCP
目前最常用的是需求平台和代码平台打通的 MCP 工具，主要提供搜索未完成需求、查询需求文档内容、提交合并请求等 tools。你可以使用 DevOpsCTL 工具去获取配置，如下：
企业外部MCP
你可以去网站寻找开源工具：
如何快速完成项目配置
- 对于改动较为频繁的
rules, 我们将它单独维护在 https://codeup.aliyun.com/qimao/public/cursor-rules 项目中，你可以提交自己团队的rules. 然后可以通过devopsctl rules install命令安装团队的 rules 到项目中 - 对于修改低频的
mode、mcp我们将配置内置在了 devopsctl，你可以 通过devopsctl mode genconfig,devopsctl mcp genconfig获取配置
三、AI 编程流程
AI编程流程的固化是为了提升AI编程的稳定性，如何设计这个流程呢？
其实现实中的敏捷迭代流程已经给了我们答案，为了保证流程、工期可控，整个迭代流程被拆分成了 需求分析、需求澄清、技术方案设计、任务拆分、开发... 等等阶段。我们无需去创新工作流，只需考虑如何在原有的迭代流程加上AI辅助提效即可。
在研发视角下，开发流程可被大致划分为下面三个阶段，在此过程中编码体检和效率应不断提升。
简单解释一下几个阶段的作用和目的：
- 计划阶段：对应需求迭代的 需求分析、需求澄清、技术方案设计、任务拆分 等前置工作，是保证开发质量的重要因素
- 编码阶段：参考计划阶段输出的文档进行开发
- 复盘阶段：CodeReview、Rules 生成（代码模版、某类功能的开发流程）..., 保证后续计划阶段、编码阶段的质量、效率
下面我们通过不同的研发场景进行详细解释。
场景一：新项目或新模块开发
✏️ 计划阶段
好了完成了前置配置工作，终于可以开始愉快的开发工作了。第一步我们需要进行 需求分析、方案设计、任务拆分，与AI达成共识，最终产出技术文档，并通过该文档指导AI后续编码工作。
切换到 plan 模式后，输入需求链接或需求文档链接+实现要求，AI 会根据 p-design-tech-solution.mdc 中的需求分析要求和技术文档模版进行技术文档编写
其中最核心的规则是强调三点：
- 避免主观臆断的功能实现，需要确认沟通
- 需求任务复杂情况下，拆分分析任务，多轮对话，增强质量把控
- 提供技术文档模版，保证内容质量和格式在这些规则要求下，AI会先生成一份大纲，比如：包含核心流程、数据库设计、API设计，核心功能伪代码等，但是每一部分内容比较简略，AI会与我们多轮沟通逐渐完善每一个部分。
如下是一个实际功能开发的plan流程：【暂不支持视频】
最终我们会得到两份文档：技术文档.md、开发任务.md（简单功能可能会合成一份）、基础代码（三方接口的验证测试用例，核心代码框架），用户可以在后续编码阶段使用。
这里强调一点，技术文档和开发任务都要尽量具体，比如标明涉及的文件（我们AI没有生成出来，我们自己补充上），比如:
- 图1中，是一个是比较简单的功能，AI帮我们梳理出来了涉及文件。
- 图2中，是一个复杂的任务，我给缺少相关文件的任务进行了补充。
⌨️ 编码阶段切
换到 develop 模式后，结合开发任务.md+技术文档.md我们让AI进行开发。同时如果有同类功能开发的模版或SOP Rules，可以提供AI参考，提示词如下：
接着，我们需要不断对AI完成的任务做出反馈, 或者直接动手修改，完成后再进入下一个任务。下面是develop流程的部分录屏：【暂不支持视频】
开发完成后我们可以通过两种方式进行代码提交：
- 手动提交
通过Cursor中的Git插件进行 commit message 生成很好用,就是格式不易控制，可能需要自己微调一下（调整后 Cursor 也能学习到）。
- Agent
提交我们通过 develop 自定义模式 触发提交，可以看到 Agent 执行了 代码评审并将修改划分成两个Commit提交，甚至贴心的帮我把一些不该提交的文件添加了 .gitignore
🧠 复盘阶段
在复盘阶段我会选择性的执行如下三个流程：
- 生成代码模版：如果你已经知道某个场景可以总结为反复利用的代码模版，那么直接手动触发，生成 Rules。
- 总结某类功能开发的SOP：当某次功能开发涉及到一个较完整的模块时，我会让 Agent 根据当前分支和主分支的差异生成开发某个模块的标准流程，提示词如下：
生成结果如下, 可以看到内容包含了开发这类功能应该新增｜修改哪些文件，并整理了代码依赖关系，这个文档既可以给人参考，也可以帮助AI更高效的生成代码！
场景二：老项目逻辑调整
在复杂的老项目对某个模块进行修改时，我们用 AI辅助分析+Tab辅助编码 的形式的AI编码模式。因为我们要让AI全面理解项目的时间较长、难度较大，并且代码本来也不会特别多，所以这样更省时间。
✏️ 计划阶段
对老项目的改动我们求稳，让AI根据需求生成技术文档.md和开发任务.md时着重强调找到相关代码并确认改动点和风险点，这对刚接手项目的人也是一个快速了解项目的方式。
⌨️ 编码阶段
结合上一步的生成的 技术文档.md和开发任务.md，我们找到对应的改动点进行手动编码，Cursor 中的Tab模型在 0.5.0 后，使用体验上有质的飞跃，可以跨文件提示非常智能。
🧠 复盘阶段
同场景一
四、优化提示词
在涉及到AI的场景，提示词就是核心，它决定了我们AI编程的效果。所以在新加入 Custom mode 或 Rules 时我们要慎重，需要保证它的质量。
我们可以分两个阶段进行优化：
- 结构优化 这一点，任何的AI平台都可以做，我们可以直接在Cursor里让它参考
RICE框架优化提示词结构，输出格式为 xml 或者 markdown - 内容优化内容优化涉及到相关代码库、业务知识，所以我们在Cursor里进行调优效果更好。
AI编程场景，我们无法获取Cursor最终拼接的Prompt是什么，Cursor会在服务端进行相关代码配置、提示词修改最终给到大模型去回复，所以在其他平台进行提示词优化无法到达最好的效果。
我通过 Cursor-Agent 的方式搭建了一个提示词优化工作流，主要流程为：填入提示词 v1-> 填入测试用例 -> 生成回复 -> 人工提供反馈 -> 生成优化提示词V2；文章篇幅有限，不在这里展开说了，详细内容可以参考：Prompt 调优Agent。
五、总结通过
标准化的 Rules 配置、场景化的模式设计及全流程的工具链打通，AI 编程从 “实验性工具” 转变为 “可落地的生产力”。
我觉得AI在编程领域一个很大的价值在于：可以将团队的研发流程快速统一。在以前这些经验只能通过文档分享的方式让团队成员吸收，效率很低。而现在，通过AI，我们可以快速将我们宝贵的经验以工作流 prompt 的形式分享并落地。
这里总结一下本文的核心要点：
- 文档先行：用结构化 Rules 降低 AI 理解成本。
- 流程驱动：分阶段（计划→开发→复盘）规范操作，通过每个阶段对应的自定义模式让研发流程更规范、可控，也降低了使用门槛。
- 人机协同：复杂分析与简单编码交给 AI，关键逻辑由人工把控。
- 注重提示词质量：提示词需要维护，我们要及时的更新、优化