如何让AI准确理解业务逻辑和技术要求

如何确保生成代码的架构一致性和质量标准

如何在团队中推广和维护统一的开发模式

如何避免规范冲突和维护成本过高的问题

# 规则名称

## 基础规范
- 明确的技术要求和实现标准

## 强制行为
- 必须执行的具体操作和约束

## 禁止行为  
- 严格禁止的操作和做法，需要避免的常见错误

## 示例代码
- 具体的代码示例和最佳实践
- 也通过 [文件名](mdc:路径) 引用外部示例

※  该格式优势

结构清晰：每个部分的职责明确，便于AI理解。

可执行性：强制/禁止行为都有明确的操作指导。

示例驱动：用实际代码代替抽象描述。

# AI协作执行规则

## 规则分类
- basic/下的通用规则: 必须调用，通用基础规范
- modules/下的模块规则: 按需调用，架构分层规范  
- workflow/下的流程规则: 按需调用，业务场景规范

## 执行流程
1. 识别场景 → 调用相关规则
2. 读取示例代码 → 作为生成参考
3. 执行强制/禁止行为 → 确保代码质量
4. 应用设计原则 → 组件化、单一职责、分层设计

## 质量保障
- 所有规则必须100%执行，重点关注强制行为和禁止行为

职责明确：每个文件只关注一个特定领域。

维护便利：修改某个规范不会影响其他领域。

学习友好：新人可以逐个理解每个规范的要求。

# 代码质量分规范（通用规则）

## 强制行为

- 所有请求必须采用 HTTPS 协议
- 确保第三方库安全可靠

## 禁止行为

- 代码复杂度限制
  - 单个文件不得超过 500 行
  - 条件复杂度不得超过 10
  - 单个函数不得超过 199 行
  - 超过限制时，应优先按功能模块拆分为多个函数或文件
- 禁止使用非得物域名的外部 CDN 资源
- 禁止在代码中包含明文密码或硬编码 token
- 禁止出现敏感词
- 避免重复代码块
- 不允许单词拼写错误或不符合命名规范
- 避免在前端直接进行金额计算(导致精度丢失)
- 禁止使用魔数(如 a === '3')，应使用常量(如 a === statusMap.login)

表现层：components.mdc（组件规范）、pages.mdc（页面规范）

业务逻辑层：hooks.mdc（状态管理）、utils.mdc（工具函数）

数据服务层：service.mdc（API接口）、constants.mdc（配置管理）

路由层：route.mdc（路由配置和导航）

# API接口生成规范（模块规则）

## 存放位置规范（按优先级）
- [p0] 页面级API：src/pages/{pageName}/services/{modules}.ts
- [p1] 全局API：src/services/{modules}.ts
- 类型文件：对应的 .interface.ts 文件

## 标准代码模板
```
import { request } from '@/utils/request';
import { UniversalResp } from '@/utils/request-operation';
import { IUserListReq, IUserListDataRes } from './interface';

/**
 * 获取用户列表
 * @param data 请求参数
 */
export const fetchUserListApi = async (data: IUserListReq) => {
  return request.post<UniversalResp<IUserListDataRes>>(
    '/api/user/list',
    data
  );
};
```
## 强制行为
- 使用MCP Server的mooncake_get_api_details工具获取接口详情
- 响应数据必须使用UniversalResp<T>泛型包装
- 接口命名采用fetch{ApiFileName}Api格式
- 类型定义必须完整，包含完整字段注释

※  该流程确保

开发效率：标准化流程减少决策时间。

质量一致性：所有表格页面都遵循相同的标准。

维护性：统一的结构便于后期维护。

# pro-table生成新页面（流程规则）
深入研究代码并理解[insert feature]是如何工作的。一旦你明白了，让我知道，我将提供我的任务给你。

##  工作流程
按以下流程进行任务执行，如果评估存在非必须流程，可跳过。
- MCP读取接口信息
- 从用户输入中提取以下信息：
   - 列表名称
   - 筛选项（需标记hideInTable）
   - 展示项（需标记hideInSearch）
   - 操作项
   - 工具栏按钮
- 评估完整的需求内容复杂度，考虑未来的扩展性，合理设计分层目录结构
    - 各个模块保持单一职责，考虑合理的业务组件拆分，避免大量代码都在页面主入口文件
    - 使用命令行批量创建目录文件（包含各类文件ts、tsx、less等）
    - 文件暂不生成代码
- 配置页面的路由信息
- 生成类型文件，确保所有类型定义清晰
- 生成constants文件，定义所需常量
- 生成services文件，实现数据服务
- 生成所需的 hooks 文件
- 生成页面（必需）和components（如需）文件 完成UI层

## 强制行为
- 使用pro-table进行开发，包括筛选表单，符合最佳实践
- 筛选项和列表项配置创建useColumns.tsx声明，筛选项（需标记hideInTable）、展示项（需标记hideInSearch）
- 左侧字段按需固定，操作项右侧固定，最多显示两个，超出折叠显示
- 文本左对齐，数字右对齐，状态枚举居中显示
- 分页设置支持10、20、50、100
- .....

# 禁止行为
.....

.cursor/rules/
├── ai.mdc              # AI协作总纲
├── basic/              # 基础规范目录
│   ├── basic.mdc
│   ├── code-quality.mdc
│   ├── ts.mdc
│   ├── style.mdc
│   ├── comment.mdc
│   ├── code-names.mdc
│   └── lint.mdc
├── modules/            # 模块规范目录
│   ├── components.mdc
│   ├── pages.mdc
│   ├── hooks.mdc
│   ├── service.mdc
│   ├── constants.mdc
│   ├── utils.mdc
│   └── route.mdc
└── workflow/           # 流程规范目录
    ├── curd-page.mdc
    ├── log.mdc
    └── send-buried.mdc
    └── ......

# AI协作执行规则

## 规则分类
- basic/下的通用规则: 必须调用，通用基础规范
- modules/下的模块规则: 按需调用，架构分层规范  
- workflow/下的流程规则: 按需调用，业务场景规范

## 执行流程
1. 识别场景 → 调用相关规则
2. 读取示例代码 → 作为生成参考
3. 执行强制/禁止行为 → 确保代码质量
4. 应用设计原则 → 组件化、单一职责、分层设计

## 质量保障
所有规则必须100%执行，重点关注强制行为和禁止行为

文 / 阳凯

关注得物技术，每周一、三更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。