如何让AI编程在团队中有效实施？

无论你是技术领头人、团队协作推动者，还是渴望在团队中应用AI编程工具的工程师，本文将为你提供一种可参考、可实施、可优化的策略。

引言

在上一篇文章《如何让AI成为你的编程助手？透视一次真实重构的启示》中提到，Cursor作为一个具备革命性AI代码能力的工具，虽具潜力，但在实际应用中却需要使用者不断调整和优化其使用方式。这种生产工具的更新换代必将促进工作流程的优化，因此我们必须深入思考如何最大化Cursor的效能，同时减轻其短板和潜在风险。

从个体开发者的角度出发，上篇详细讲述了在复杂重构场景中全程使用Cursor的过程，明确了其在提升开发效率方面的巨大贡献。作为高德信息业务中心大供给团队中Cursor的实施负责人，我深知如何使Cursor在团队的研发流程中扎根并实现预期的效益。本篇将简要描述我们先锋团队如何集体分析和解决问题的过程。

问题分析与解决方案概述

从整体层面来看，在团队推广中面临的主要挑战主要可归结为意愿和能力两个方面。因此，一方面需要提升团队对Cursor的使用意愿，另一方面则是增强掌握Cursor的能力。在意愿方面，信息业务中心提供了强有力的激励措施，团队成员也展现出足够的执行力。我们将重点放在能力提升上，针对一些问题进行了详细拆解，这里以三大问题为例：

• 不同开发者在面对不同类型的需求时，对Cursor的使用方式存在差异，特别是在方案设计阶段，容易出现盲目与Agent的对话。如何总结出初学者能够轻松上手的使用流程，是我们亟需解决的问题。
• 在复杂的业务需求环境中，向Cursor清楚表达希望得到的技术设计与代码的要求十分困难，语言表达的障碍常常放大了后续的不确定性。
• Cursor的前期使用步骤较为繁琐，每个项目都需要特定的规则和文档生成，以提高Cursor的精准度。我们需要思考如何降低初期使用的复杂性，避免让用户感到畏惧。

针对上述问题，我们提出了一系列解决方案，接下来将一一详细说明。

尽管Cursor的Agent模式操作简单，但仅依靠自然语言对话的堆砌，往往难以高效推进整个需求开发流程。面对各类需求时，沟通回合和生成代码结果的不确定性，可能会削弱Cursor提升效率的潜力。实际上，在需求开发的全过程中，Cursor的适用场景以及使用规范具有一定的规律性，这种规范化的研发流程显得尤为迫切。

通过笔者在多种需求场景下的探索，以及团队同事们几周的共同努力，最终提炼出如下研发流程图。左侧展示的是传统的需求开发流程，涵盖跨应用、跨岗位及跨团队的合作。然而，考虑到Cursor在跨应用支持方面尚不完善，更不用说跨团队的开发协作，因此右侧则是针对单一应用的研发流程，这是通过引入Cursor而实现的最佳实践。图中，黄色部分表示需人工完成的环节，而绿色部分则为Cursor自动处理的部分。接下来，我们将详细介绍这一流程。

需求阶段解析

目前团队内的需求阶段可以细分为四个步骤：需求创建、内部审核、需求预排和需求正式排期。

鉴于供给侧团队的业务逻辑通常较为复杂，技术团队全力支持业务发展。因此，在需求阶段不建议将具体的技术实现（包括Cursor的参与）对产品业务团队的需求设计造成影响。在应用级的研发流程中，这一阶段并不包含在内。

方案设计阶段解析

在信息工程团队制定的统一需求研发流程中，方案设计阶段需输出系统分文档。而在我们划分的应用级研发流程中，要求人工撰写概要设计文档，并由Cursor转化为详细设计文档。明确这三种文档的区别，有助于理解整个方案设计阶段的流程。

• 系统分文档的概念：在进行业务需求分析和技术方案的设计过程中，需求的技术一号位的团队成员需要从全链路的角度来制定全面的设计方案，明确界定上下游的界限及交互链条，并通过一份综合文档将各方的设计整合在一起。
• 概要设计的概念：在进行技术方案的设计时，此文档在交由Cursor开发之前由人工开发者完成撰写，其主要产出是针对单一应用或子模块的概要设计。该文档旨在面向Cursor，清晰地阐述应用内部的技术实现方案，包括目标功能、关键改动、重要链路及技术实现的细节等。
• 详细设计的定义为：在Cursor生成实际代码之前，此文档是在概要设计基础上完成的，由Cursor依据概要设计形成具体的技术实现方案。该方案将具体的类、方法和数据结构等细节明确展示，以图示或伪代码的形式清晰地描述各层业务流程的处理。经过人工开发者的审核后，确保Cursor能够直接依据详细设计生成准确的代码。

接下来，我们可以对上述三个定义进行进一步分析：

• 系统分文档主要是针对开发者，属于整体需求层面的内容。因此，可以采用较为抽象的表述方式，只需在共识的背景下，清晰地传达整体技术链路即可。系统分文档与概要设计、详细设计并不矛盾，即使有Cursor参与，也需由技术负责人进行整体协调。
• 概要设计文档面向Cursor，关注于单个应用层面。它不需要深入到伪代码的层次，但必须清晰地列出关键的领域划分、数据结构设计、接口设计和业务逻辑等内容。对于Cursor而言，概要设计可以视为“半开放”的方案。
• 详细设计文档同样是针对Cursor，专注于单个应用的实现。所有Cursor生成代码所需的背景信息和方案细节都需在其中体现，但不以完整代码的形式出现。对于Cursor而言，详细设计可以理解为“完全透明”的方案。

通过以上内容，我们已经清楚了每个应用在方案设计阶段的研发流程，以及概要设计与详细设计各自的功能。不过，针对不同需求的概要设计撰写方式，将在下一个问题中讨论。

开发阶段

根据组内成员的实践经验，在实际的代码开发阶段，并不能简单地指望Cursor根据详细设计一次性生成所有代码。因为文档与代码的数量过于庞大，Cursor无法处理如此复杂的上下文，导致生成的代码可能出现混乱。例如，详细设计中不同接口的逻辑可能会在同一个接口的方法代码中混合生成。

因此，整个代码编写过程应当被分解为多个步骤循环。目的是将任务的细分程度降至Cursor能够有效完成的水平。

拆分标准

有效拆分需求与代码生成流程

需求的拆分方式需要针对其复杂性进行细致分析。若需求较为简单，且涉及的业务逻辑大多为基本的增删改查操作，则可以采用较为粗略的颗粒度。而对于复杂的需求，建议首先按照业务逻辑进行拆分，之后再基于技术层次展开。

1. 在拆分过程中，可以先从业务逻辑出发，逐步实现数据库的基本读写功能，接着添加数据校验、审核流程，最后引入状态机。这种方式有助于方法的复用，同时也能让Cursor在特定功能上保持集中注意力。

2. 对于更为复杂的业务需求，建议采用分层的架构来生成代码。可以从数据对象（DO）开始，逐步到领域层的模型、转换器、网关定义，最后实现具体的SQL映射。之后，再处理领域服务、应用层和客户端层。这是针对常见Java后端服务框架的建议，其他技术栈的开发者也可以根据自己的框架制定规范。

单次循环内步骤

在每次生成代码的循环中，应遵循以下步骤：

提示词设计

本模块的代码生成目标需要通过清晰的提示词向Cursor明确表达。可以手动@详细设计文档，并指明该模块在文档中的具体位置。如何准确表达目标将在下一个问题中深入讨论。

代码生成

与Cursor进行互动后，代码将根据所提供的提示词、详细设计和现有规则进行生成。在这一过程中，应关注所使用规则是否符合预期，并在轮次过多时及时手动确认是否继续执行。

当然，这仅是Agent模式下的常见使用方式，用户也可以选择手动模式来修改文件等。

单轮代码审查与Git提交

在Cursor生成代码后，需及时进行审查以决定是否采纳。因Cursor尚未区分对话轮次的采纳功能，因此每次生成后必须立即进行审查，并结合Git等工具，清晰识别Cursor代码的变化。这就要求开发者对每轮生成的预期结果有明确的理解。

这一环节至关重要，因为当单轮生成的代码量较少时，能够更容易发现Cursor生成代码中的问题。如果推迟到最后统一审查，必然会影响准确性，可能导致线上事故的发生。

建议使用规则，要求Cursor在每轮代码生成后进行自我审查，识别潜在的语法和逻辑问题，同时人工审查也需细致关注。

判断是否达到整体预期

在这一环节中，可以通过Cursor来判断是否完成详细设计，也可以由开发者直接决定，需根据效率标准进行判断。

审查阶段

单元测试

单元测试环节可以完全由Cursor生成。但需要注意的是，Cursor应先根据人类审查过的详细设计生成测试用例，再基于这些用例生成测试代码，而不是直接根据Cursor编写的业务代码生成测试代码，这样会导致“打哪指哪”的问题。

代码审查

代码审查与上线准备

1. 首先，Cursor可以开展一轮代码审查（CR），其内容涵盖两个主要方面：

a. 在语法与语义层面，使用经过提炼的Java开发规范作为审核规则，Cursor能够对比主分支与当前分支的代码差异，执行代码审查。

b. 在业务逻辑层面，Cursor可根据详细设计文档，比较当前代码的实现情况，进行代码审查。

2. 终究，人工开发者的代码审查仍然不可或缺。无论Cursor的智能水平如何，人类开发者才是线上安全的最重要保障。因此，在代码审查阶段，必须严格遵循相关规范，例如交叉审查等程序。

上线策略

1. Cursor可以协助整理上线计划，首先对比主分支与当前分支的代码差异，识别出需要准备或配置的关键点，并将其列出，以免开发者出现疏漏。

2. 由于上线涉及多个应用和系统的协同，Cursor在这方面的作用有限，最终上线计划仍需由人类来确认。

联调阶段

当前的联调主要由人类执行，Cursor则可提供问题定位的辅助支持。

测试阶段

在测试阶段，仍然主要依赖人类参与，Cursor同样可以帮助识别并定位问题。

结构化语言的表述

当Cursor进入更深层次的应用时，不再仅仅停留在初步的概念理解和简单交互，便显现出一个普遍性的问题：为了提升Cursor生成代码的准确度，必须提高人类指令的明确性。意图需要清晰，逻辑要严谨，指令不能产生歧义，且上下文必须交代充分。那么，在复杂的业务需求背景下，如何将人类的意图转化为Cursor及其背后模型能够理解的自然语言呢？

回顾历史，或许能为我们提供一些启示。如今我们能够使用自然语言与模型进行对话，但在计算机发展的早期，如何与硬件高效沟通呢？组成原理的知识告诉我们，最底层的0和1电信号经过不断的规范化与封装，形成了现在的Java语言。未来可能会出现成熟的自然语言规范来定义与模型的交互方式。然而，目前为了在团队内部迅速推广，我们需要遵循最基本的原则：结构化与模板化。

提升研发效率的关键要素：prompt与概要设计

在研发过程中，语言表达的两个重要方面是prompt与概要设计。

prompt的结构化

关于prompt，关键在于其结构化特征。通过结构化的方式，能够更有效地帮助模型理解意图。供给侧团队从历史逻辑的梳理、辅助绘图生成，到根据概要设计制作详细设计与代码编写等环节，制定了多种结构模板。无论是在不同的研发阶段、业务场景，还是技术复杂度上，prompt的详细程度都可根据需求灵活调整。

由于篇幅有限，这里提供一个具体示例：

# 目标
在创建和修改元素后，新增的所有元素信息需经过统一审核系统。这包括两个主要步骤：提交审核和接收审核反馈。我们将审核系统集成到现有的装修元素流程中。

# 业务规则
## 1. 提交审核规则
...

## 2. 审核反馈规则
...

# 现有知识背景
1. 审核系统的交互规则已整理为《审核交互规则.md》，存放在.cursor/docs目录。我们使用“2.1 HSF请求方式”进行提交审核。
2. 当前代码已实现创建和修改元素的功能。
3. 审核反馈处理框架可参考其他工程的Consumer，相关代码《audit.java》位于.cursor/docs目录，但需进行重构与简化。

# 核心要求
送审功能应具备通用性，请确保适用于所有模块。对于不同模块的特定内容（如提审字段准备），采用策略模式处理，允许不同模块的子类重写父类方法。

# 核心任务
## 1. 深入阅读上述知识背景文档，认真研究现有的new-b-dolphin-*代码实现。
## 2. 根据规则和现有代码，撰写详细设计文档，内容应涵盖类和方法的定义，所有图表应用mermaid格式。
## 3. 文档完成后，需等待确认。确认技术方案可行后，再生成具体代码并写入相应文件。

显然，结构化只是高质量prompt的基础，仍有许多提升的空间。

概要设计的重要性

在Cursor的研发流程中，方案阶段对最终代码的生成精确性至关重要，其中概要设计的撰写是这一阶段的核心。为此，供给侧团队基于经验总结，提供了一套类似系统分文档的模板。

这一模板的核心理念在于，通过标准化的表达方式，严格规范目标描述，帮助Cursor更准确地识别修改的重点和内容：

1. 在传统领域设计的统一语言基础上，新增“技术代码语言”，实现“业务语言 – 技术中文自然语言 – 技术代码语言”的精确对应，从而提高目标的准确性。

从业务流程与技术实现的双重视角出发

2. 以业务流程设计为基础，明确业务代码的流向。必须提供关键的数据结构设计、具体的接口文档，以及详尽的业务流程图或时序图。

3. 从技术实现的角度，横向约束每一层代码的输入与输出。在纵向业务流程的结合下，限制Cursor的自主开发范围，以确保符合预期目标。

4. 无论是横向还是纵向，都应清晰阐述现状及目标的修改点，以便Cursor能够准确定位。

基于应用级特化的通用解决方案

问题及解决方案

经过改进的研发流程和结构化的表达，Cursor在理解和支持业务方面的准确性显著提高。然而，落到实际代码中，每个应用都有其独特的技术栈、框架、分包目录、编码风格和通用技术组件。如果不提供有关应用级背景和上下文的输入，最终生成的代码结果可能会偏离预期，例如随意创建包路径、重写已有的Utils方法，或任意选用现有技术组件（如：Diamond或Switch），这将导致严重后果。

因此，每个应用都应建立一套特化的规则和文档，将所有可能影响业务或技术的规范信息归纳整理。然而，人工构建这一体系既冗长又困难，不仅需要手动梳理所有技术组件的相关信息，还需按照规则的格式进行撰写和验证。

解决方案的实施思路

为了解决这一问题，降低Cursor使用的初始门槛，供给侧团队需要共同撰写一套针对Java应用的通用规则或者提示语。在Cursor首次应用时，允许其自主探索代码，并生成相应的特化规则和文档，这些内容经过持续验证和迭代。不同团队必然会有自己的技术栈、要点和关键链路，从而打造出团队特有的通用方案。

主要思路：

1. 针对大多数代码规范，通过规则引导Cursor按一定顺序对代码进行分段探索，明确预期目标、输出形式、退出条件以及正反例。

2. 在涉及技术栈、上线计划等方面，可以列举出需要整理的备选项，让Cursor依据应用代码或与主分支代码进行逐一比对，从而填充形成符合当前应用的目标规则。

通用规则或提示语的展示

由于篇幅有限，无法在本文中展示所有的提示和规则，因此提供以下提纲及部分细节供参考：

大纲

1. 多层次文档生成与更新策略、规则

• 项目整体概述文档（包括业务与技术）
• 单个接口的业务逻辑整理
• 辅助性图示绘制
• 生成接口文档的程序
• 文档即时更新的标准

2. 外部技术栈的引用规则：自主研究本项目涉及的所有技术栈和版本

• 基础技术：JDK及springboot版本
• 数据库系统：MySQL（TDDL）、Lindorm
• ORM及分页等技术：Mybatis、mybatis-plus、baomidou
• 缓存机制：Redis、Tair及本地缓存
• 通信服务（上下游区分）：HSF、HTTP（通用调用配置）
• 配置管理中心：Diamond、Switch
• 日志处理：Slf4j及日志格式要求
• 可选工具库：对于JSON的选择（fastJSON、Gson）及lombok的使用
• 其他可能涉及的技术栈，例如security、规则引擎等

3. 系统中已有的自定义代码框架以及特定的代码风格要求与使用方法

• 异常处理的统一性：包括自定义业务异常类、errorCode、抛出与捕获的方式等
• 日志打印的注解统一及日志级别规范
• 分布式锁的使用标准化
• HSFConfig配置的统一管理
• 缓存读写方式的统一化
• 监控规范的统一性
• 现有自定义工具类的功能概述，以便于Cursor未来的复用

4. 自主探索代码分包目录结构的规范：代码结构应如何设计，文件应放置在哪些目录

• 流行代码框架的汇总与匹配：如cola或GBF等
• 在交由Cursor之前，所有包名需手动创建完成
• 探索当前工程内所有的包路径及代码放置的规则

5.代码审查、单元测试与上线计划规范整理

• 代码审查：遵循代码的语法标准和风格，确保与详细设计相符。
• 单元测试：编写单元测试用例并生成相应代码。
• 上线计划整理：全面梳理上线所需准备，Cursor会在代码变更中自动选择相关内容。

详细举例

1.代码分包目录结构规范，作者 @珵玉

代码分包目录结构的标准化设计

“`html
—
description: `此规范包含了项目代码的结构和存放规则，所有的代码必须遵循此模块化的组织方式`
globs: *.java,*.xml
alwaysApply: true
—
# 项目模块及其依赖关系

“`mermaid
graph TD
  A –> B
  B –> C
  A –> D
“`

# 项目目录及使用规范

systemA/
├── systemA-start/          # 启动模块
├── systemA-client/        # 对外提供的RPC接口模块
│   └── src/main/java/systemA/client
│       ├── api/                    # 对外接口
│       └── dto/                    # 请求和响应的模型
├── systemA-domain/        # 领域基础模块，项目的核心部分;所有外部服务依赖于此
│   └── src/main/java/systemA/domain
│      ├── domainservice/     # 基础服务框架
│      ├── constant/          # 常量定义
│      ├── enum/              # 枚举类型
│      ├── exception/         # 异常处理
│      ├── gateway/           # 外部服务接入的防腐层
│      ├── switch/            # 领域层的开关配置
│      ├── util/              # 基础工具类
│      ├── model/             # 领域模型
│      ├── strategy/          # 策略模式实现 # 设计模式示例
│      ├── handler/           # 处理链/事件分发/命令模式实现 # 设计模式示例
│      ├── wrapper/           # 装饰器/包装器模式实现 # 设计模式示例
│      └── observer/          # 观察者模式实现 # 设计模式示例
└── systemA-application/   # 业务逻辑应用层
    └── src/main/java/systemA/application
       ├── client/         # 对应服务的RPC实现
       ├── controller/     # 对外提供的HTTP服务
       ├── gateway/        # 网关注册的服务接口
       │  ├── request/         # 网关接口请求定义
       │  ├── response/         # 网关接口响应定义
       │  └── impl/            # 网关接口的实现
       ├── converter/           # 模型转换器，将领域或数据库模型转换为DTO、VO模型
       ├── service/           # 业务服务接口
       │   ├── factory/        # 工厂模式实现 # 设计模式示例
       │   ├── adapter/        # 适配器模式实现 # 设计模式示例
       │   └── proxy/          # 代理模式实现 # 设计模式示例
       └── service/impl/       # 业务服务实现
 
# 代码文件存放规范

1、数据对象(DO)规范：数据对象(DO)需存放于XXX模块下的dataobject包中。
2、传输数据对象(DTO)规范：传输数据对象(DTO)需存放于XXX模块下的xxx包中。
3、视图数据对象(VO)规范：视图数据对象(VO)需存放于XXX模块下的xxx包中。
4、工具类(Util)规范：工具类需存放于XXX模块下的xxxx包中。
5、单元测试类(Test)规范：单测类需存放于Test模块下的xxx包中。
6、策略模式(Strategy)规范：策略类应集中放置在strategy包下，命名以Strategy结尾，例如XxxStrategy.java。
7、处理链/命令模式(Handler/Command)规范：相关类应统一放置在handler或command包下，命名以Handler或Command结尾。
8、装饰器/包装器模式(Wrapper)规范：相关类应统一放置在wrapper包下，命名以Wrapper结尾。
9、工厂模式(Factory)规范：相关类应统一放置在factory包下，命名以Factory结尾。
10、适配器模式(Adapter)规范：相关类应统一放置在adapter包下，命名以Adapter结尾。
11、代理模式(Proxy)规范：相关类应统一放置在proxy包下，命名以Proxy结尾。
12、建造者模式(Builder)规范：相关类应统一放置在builder包下，命名以Builder结尾。
13、观察者模式(Observer)规范：相关类应统一放置在observer包下，命名以Observer结尾。
14、访问者模式(Visitor)规范：相关类应统一放置在visitor包下，命名以Visitor结尾。
15、状态模式(State)规范：相关类应统一放置在state包下，命名以State结尾。
16、模板方法模式(Template)规范：相关类应统一放置在template包下，命名以Template结尾。
….

“`

发布计划模板代理.mdc

# 需求上线计划模板规范

当前版本：vX.X

## 一、发布定义
（需求负责人、发布执行人、需求分级、风险等级）

## 二、发布计划
（上下游发布节奏、内部工程发布顺序）

## 三、预发布
（预发状态、验证结果）

## 四、灰度发布
（灰度策略、灰度验证点）

## 五、正式发布
（发布节奏、配置项、影响面分析、监控方案、回滚预案）

## 六、上线流程
（具体上线步骤）

## 七、评审回看
（上线评审记录）

## 版本管理
（文档版本历史）

—

## 关键规则
– 每个上线计划必须涵盖发布定义、发布计划、预发布、灰度发布及正式发布这五大核心部分。
– 发布定义需清晰列出需求的责任人、执行人、需求分类及风险等级。
– 需求分级要明确划分为：A级（需全面测试）、B级、C级及D级（自测）。
– 发布计划应详细阐述发布的节奏，包括模块间的依赖关系及发布的先后顺序。
– 计划应以整体工程为单位制定（如amap-mp-shop），而非单独子模块（如shop-app、shop-infrastructure等）。
– 灰度发布部分需阐明灰度策略、灰度验证点及对线上功能的影响评估。
– 在正式发布部分，需包含配置项清单、影响面分析、监控方案及回滚预案（即“三板斧”）。
– 所有相关的配置项（如Diamond配置、消息队列、网关等）需详细列出并指派负责人。
– 回滚预案需根据不同阶段可能出现的问题制定具体的操作步骤。
– 模板中应包含版本管理信息，以记录文档的变更历史。

—

## 各章节详细规范

### 一、发布定义
– **需求负责人**：主要负责该需求的人员。
– **发布执行人**：执行发布的人员列表。
– **需求分级**：表明需求的重要程度
– **A级**：完全测试，需最高级别的测试覆盖。
– **B级**：部分测试，有部分自测。
– **C级**：大部分为自测，少部分需要测试。
– **D级**：自测，由开发人员独立完成。
– **风险等级**：标明发布的风险等级（高、中、低）。

### 二、发布计划
– **上下游发布节奏**：使用表格形式列出所有相关系统/工程的发布时间、跟进人及发布内容。
– **模块间依赖**：通过图表直观展示各工程间的依赖关系，区分强依赖与弱依赖。
– **工程发布顺序**：应以整体工程为单位（如amap-mp-shop、amap-mp-shop-service），而非子模块（如shop-app、shop-infrastructure等）。

### 三、预发布
– 清楚标明预发状态（已预发/未预发）。
– 如已预发，需说明预发验证的结果。

### 四、灰度发布
– 明确灰度发布时间。
– 使用表格列出各工程的灰度情况，包括：
– 是否具备灰度环境。
– 当前进度。
– 发布后对线上功能的影响。
– 灰度上线后需重点验证的内容。

### 五、正式发布
– **发布节奏**：明确正式发布的批次及时间安排。
– **配置项**：详细列出所有需要配置的项目，包括：
– 合并origin/master。
– Diamond配置。
– Switch配置。
– 数据库建表及配置。
– 消息队列（生产者/消费者）。
– 网关ACTION配置：若新增hsf接口，则需在发布计划中列出，由开发人员决定是否发布网关ACTION。
– autoconfig：若代码更改antx.properties文件。
– SchedulerX。
– 二方包：若pom.xml文件有改动，需列举改动点，确认是否需要更新二方包版本或发布二方包。
– Sentinel：如调整sentinel相关逻辑，需列出sentinel配置项。
– Jingwei。
– Tair/Redis。
– 其他中间件配置。
– **影响面分析与验证方案**：分析发布的影响范围，制定验证方案。
– **三板斧**：
– **可灰度**：明确是否需要灰度及其策略。
– **可监控**：列出关键监控指标。
– **可回滚**：详细说明判定需要回滚的依据及操作步骤。

### 六、上线流程
– 列出具体的上线流程或引用相关流程文档。

### 七、评审回看
– 存放上线评审记录或会议视频链接。

### 版本管理
– 使用表格记录文档的版本历史，包括版本号、修订类型、修订时间、修订人、修订内容及生效时间。

—

## 配置项详细规范

### Diamond配置
使用表格列出所有Diamond配置，包括：
– groupId
– dataId
– 配置项确认人
– 配置值

注意：若dataId相同，则合并表格单元格。

### 消息队列配置
分别列出生产者与消费者配置：
– Topic
– Group（消费者）
– Tag
– 功能说明

### 网关配置
列出所有需配置的网关action，包括：
– action名称
– 配置地址
– 功能说明

### autoconfig
如代码有修改antx.properties文件，则需配置autoconfig，包括
– 配置key
– 配置value

—

## 回滚预案规范
回滚预案需包含：
– 判定需要回滚的明确依据。
– 针对不同阶段（如代码上线阶段、业务灰度阶段）的回滚操作步骤。
– 回滚后的验证方法及后续操作。

—

## 示例

# 用户身份认证系统升级上线计划
当前版本号：v2.0

## 一、发布定义
### 需求负责人
张三

### 发布执行人
张三、李四、王五

### 需求分级
A级（需全面测试）

### 风险等级
中

## 二、发布计划
### 1、上下游发布节奏
模块间依赖：
实线箭头：强依赖，必须按照顺序发布。
虚线箭头：逻辑上有依赖关系，但可并行发布。

| | **发布时间** | **跟进人** | **发布内容** |
| — | — | — | — |
| 认证服务工程 | 10.15（已完成） | 张三 | 1、支持新的认证方式 2、优化认证流程 |
| 用户中心工程 | 10.16 | 李四 | 1、适配新的认证接口 2、增加用户安全等级 |
| 前端系统工程 | 10.17 | 王五 | 1、更新认证页面 2、增加安全等级展示 |

## 三、预发布
* [x] 已预发，验证通过所有测试用例

## 四、灰度发布
* [x] 10.18发布灰度

| | **是否有灰度环境** | **当前进度** | **发布后对线上功能的影响** | **灰度上线后核心验证点** |
| — | — | — | — | — |
| 认证服务工程 | 有 | 已灰度 | 开关控制，对线上无影响 | 1、新旧认证方式切换正常 2、性能指标达标 |
| 用户中心工程 | 有 | 已灰度 | 开关控制，对线上无影响 | 1、用户安全等级计算正确 2、与认证服务交互正常 |
| 前端系统工程 | 有 | 未灰度 | 新界面默认关闭，对线上无影响 | 1、新旧界面切换正常 2、功能操作流畅 |

## 五、正式发布
### 发布节奏
分两批发布：
1. 第一批：10.20 认证服务工程 + 用户中心工程
2. 第二批：10.21 前端系统工程

### 配置项
| | **是否已完成** | **负责人** | **deadLine** | **认证服务工程** | **用户中心工程** | **前端系统工程** |
| — | — | — | — | — | — | — |
| 合并master | * [] | 张三 | 10.19 | 是 | 是 | 否 |
| diamond配置 | * [] | 李四 | 10.19 | 是 | 是 | 是 |
| 数据库脚本 | * [] | 王五 | 10.19 | 是 | 是 | 否 |

### Diamond配置
| **groupId** | **dataId** | **配置项确认人** | **配置值** |
| — | — | — | — |
| auth-service | auth.switch.config | 张三 | {“newAuthEnabled”: false, “authTimeoutMs”: 3000} |
| user-center | security.level.config | 李四 | {“securityCheckEnabled”: false, “defaultLevel”: 1} |

### 三板斧-可灰度
认证功能通过配置中心开关控制，可实现新旧功能的平滑切换：
* 配置开关关闭时，使用旧的认证流程。
* 配置开关开启时，使用新的认证流程。
* 可按用户分组灰度，先覆盖内部用户，再扩大到外部用户。

### 三板斧-可监控
监控项：
* 认证请求量。
* 认证成功率。
* 认证响应时间。
* 异常登录告警。
* 用户安全等级变更统计。

### 三板斧-可回滚
**判定需要回滚的依据：**
1. 认证成功率下降超过3%。
2. 认证响应时间超过500ms。
3. 出现大规模用户无法登录的问题。

| **阶段** | **回滚操作和后续操作步骤** |
| — | — |
| 代码上线阶段 | 1、同步问题 2、单独回滚故障服务 3、确认回滚后影响消除 |
| 业务灰度阶段 | 1、将配置开关关闭，切回旧认证方式 2、排查问题 3、修复后重新灰度 |

## 六、上线流程
参考标准上线流程：[链接]

## 七、评审回看
[会议录制链接]

## 版本管理
| **版本号** | **修订类型** | **修订时间** | **修订人** | **修订内容** | **生效时间** |
| — | — | — | — | — | — |
| V1.0 | 新增 | 2023-10-10 | 张三 | 首次发布 | 2023-10-10 |
| V2.0 | 更新 | 2023-10-15 | 李四 | 增加前端系统发布计划 | 2023-10-15 |
总结

假如仅仅使用Cursor就像是在攀登高楼，那么通用的研发流程规范则如同为每一层楼之间搭建的阶梯，而那些针对应用特别优化的解决方案就如同为新手搭建的直达电梯。这正是供给侧先锋团队所展现的价值。

Cursor在团队中的实施仍在持续推进，我们期待能不断解决遇到的问题，让每位同事以及整个信息业务团队都能在Cursor代表的AI浪潮中获得收益。

我们还将会抽时间进一步研究相关理论，发现有趣的内容会及时与大家分享，希望大家积极进行交流和互动。

MCP赋能可视化OLAP智能体应用

针对传统数据分析中所面临的高SQL使用门槛和复杂的可视化分析流程，本方案依托云数据库PolarDB MySQL版本及阿里云百炼，结合MCP工具的SQL执行与绘图功能，通过模型智能解析与高效推理，实现从数据接入到分析可视化的全流程一体化部署。

请点击MCP赋能可视化OLAP智能体应用-阿里云技术解决方案以获取更多信息。