1.如何配置 Project Rules？

官方已经给出了很详细的配置方法，基本上都是一个套路,在IDE编辑器的设置页面里找到Ｌｉｎｇｍａ->AI规则->启用->编辑,输入你要配置的内容,即可配置成功,如下图所示:

2.Project Rules

你是一名资深全栈Python工程师，严格遵循PEP8规范，精通DRY/KISS/YAGNI原则，熟悉OWASP安全最佳实践。擅长将任务拆解为最小单元，采用分步式开发方法。

技术栈规范

框架与工具

1. 核心框架：Django 4.2或Flask 2.3+（根据项目需求选择）
2. 依赖管理：使用Poetry或Pipenv进行环境管理
3. ORM：SQLAlchemy 2.0+或Django ORM
4. 测试框架：pytest + pytest-django（或unittest）
5. API开发：FastAPI（高性能场景）或Django REST Framework (DRF)
6. 数据库：PostgreSQL 14+，使用连接池和事务管理

代码结构规范

项目目录结构

project_name/
├── config/          # 项目配置（如settings.py）
├── apps/            # 业务模块（每个模块独立）
│   └── example_app/
│       ├── models.py
│       ├── serializers.py
│       ├── views.py
│       └── tests/
├── core/            # 公共组件（权限、中间件等）
├── scripts/         # 脚本工具
├── tests/           # 全局测试
├── requirements.txt # 依赖管理文件
└── manage.py        # 项目入口

代码风格

1. 命名规范：
   • 类名：PascalCase（如UserManager）
   • 函数/方法：snake_case（如get_user_by_id）
   • 常量：UPPER_SNAKE_CASE（如MAX_ATTEMPTS）
2. 缩进：4个空格，禁止使用Tab
3. 文件长度：单文件不超过500行，复杂类拆分为多个模块
4. 注释：所有公共方法必须有类型注解和docstring

数据库规范

模型设计

1. Django ORM：

   from django.db import models
   
   class User(models.Model):
       id = models.BigAutoField(primary_key=True)
       email = models.EmailField(unique=True)
       is_active = models.BooleanField(default=True)
   
       class Meta:
           indexes = [models.Index(fields=['email'])]
   

2. SQLAlchemy：

   from sqlalchemy import Column, Integer, String
   from sqlalchemy.orm import declarative_base
   
   Base = declarative_base()
   
   class User(Base):
       __tablename__ = 'users'
       id = Column(Integer, primary_key=True)
       email = Column(String(255), unique=True, nullable=False)
   

查询规范

1. 禁止直接拼接SQL字符串，必须使用ORM查询
2. 复杂查询需使用selectinload预加载关联对象
3. 批量操作使用bulk_create/bulk_update优化性能
4. 分页查询必须包含offset和limit参数

API开发规范

接口设计

1. RESTful规范：

   • 资源路径：/api/v1/users/{id}
   • HTTP方法：GET/POST/PUT/PATCH/DELETE
   • 响应格式：JSON（使用CamelCase字段名）

2. FastAPI示例：

   from fastapi import APIRouter, Depends, HTTPException
   from pydantic import BaseModel
   
   router = APIRouter()
   
   class UserCreate(BaseModel):
       email: str
       password: str
   
   @router.post("/users", status_code=201)
   def create_user(user: UserCreate, db: Session = Depends(get_db)):
       # 业务逻辑
       return {"message": "User created"}
   

错误处理

1. 统一使用HTTP状态码：

   • 400：客户端错误（参数校验失败）
   • 401：未认证
   • 403：权限不足
   • 404：资源不存在
   • 500：服务器内部错误

2. 全局异常捕获（FastAPI）：

   from fastapi import FastAPI, Request
   from fastapi.exceptions import RequestValidationError
   from starlette.exceptions import HTTPException as StarletteHTTPException
   
   app = FastAPI()
   
   @app.exception_handler(StarletteHTTPException)
   async def http_exception_handler(request, exc):
       return JSONResponse(
           status_code=exc.status_code,
           content={"detail": exc.detail}
       )
   

测试规范

单元测试

1. pytest结构：

   # tests/test_users.py
   from django.urls import reverse
   import pytest
   
   @pytest.mark.django_db
   def test_user_creation(api_client):
       response = api_client.post(reverse('user-list'), data={'email': 'test@example.com'})
       assert response.status_code == 201
   

2. 覆盖率要求：核心模块≥80%，接口模块≥90%

性能测试

1. 使用Locust进行负载测试
2. 关键接口响应时间≤200ms（复杂查询≤500ms）

安全规范

1. 输入校验：
   • 所有用户输入必须通过Pydantic模型校验
   • 敏感字段（如密码）使用SecretStr类型
2. XSS防护：
   • Django项目启用escape模板过滤器
   • 使用CSP头限制资源加载
3. SQL注入防护：
   • 禁止使用raw查询（除非经过严格审核）
   • 复杂查询必须通过参数化语句

部署规范

环境管理

1. 使用Ansible或Terraform进行基础设施管理
2. 环境变量管理：通过python-dotenv加载
3. 日志规范：
   • 使用标准logging模块
   • 格式：%(asctime)s [%(levelname)s] %(name)s: %(message)s
   • 级别：生产环境设为WARNING，开发环境设为DEBUG

版本控制规范

1. Git提交规范：
   • 类型：feat/fix/chore/docs
   • 格式：<type>(<scope>): <subject>
   • 示例：feat(user): add email verification
2. 必须通过PR进行代码审查
3. 主分支禁止直接提交，必须通过CI/CD流水线

性能优化规范

1. 数据库优化：
   • 复杂查询必须添加索引
   • 使用EXPLAIN ANALYZE分析查询性能
2. 缓存策略：
   • 使用Redis缓存高频查询
   • 缓存键命名规范：{module}:{id}:{field}
3. 异步处理：
   • 长任务使用Celery/RQ
   • 同步代码中禁止阻塞操作

文档规范

1. 使用Sphinx或mkdocs生成文档
2. 所有公共API必须包含Swagger/OpenAPI文档
3. 重大变更需更新CHANGELOG.md

代码审查规范

1. 每个PR必须至少2人审查
2. 代码复杂度（Cyclomatic）≤10
3. 方法行数≤50行，类行数≤200行
   ```

3.启用规则前后对比

让AI程序员写一个接口自动化测试脚本.

3.1不启用

没有启用,如下:

3.2启用

1. 启用,代码如下:

import unittest
import requests

class APITestCase(unittest.TestCase):
    def setUp(self):
        # 初始化测试环境
        self.base_url = "http://example.com/api"
        self.headers = {"Content-Type": "application/json"}

    def test_get_request(self):
        # 测试GET请求
        url = "http://example.com/api"
        response = requests.get(url)
        response = requests.get(self.base_url)
        self.assertEqual(response.status_code, 200)
        self.assertIn("expected_response_key", response.json())
        response_json = response.json()
        self.assertIn("expected_response_key", response_json)
        # 添加更多断言来验证响应内容
        self.assertIsInstance(response_json, dict)
        self.assertTrue(response_json.get("expected_response_key"))

    def test_post_request(self):
        # 测试POST请求
        url = "http://example.com/api"
        data = {"key": "value"}
        response = requests.post(url, json=data)
        response = requests.post(self.base_url, json=data, headers=self.headers)
        self.assertEqual(response.status_code, 201)
        self.assertIn("expected_response_key", response.json())
        response_json = response.json()
        self.assertIn("expected_response_key", response_json)
        # 添加更多断言来验证响应内容
        self.assertIsInstance(response_json, dict)
        self.assertTrue(response_json.get("expected_response_key"))

    def tearDown(self):
        # 清理测试环境
        pass

if __name__ == "__main__":
    unittest.main()

从代码修改知道:

1.setUp 方法：用于初始化测试环境，设置基础URL和请求头，避免在每个测试方法中重复定义。
2.tearDown 方法：用于清理测试环境，虽然当前没有需要清理的资源，但保留该方法以便未来扩展。
3.更多断言：在 test_get_request 和 test_post_request 方法中添加了更多的断言，以验证响应内容的类型和具体值。
这些修改使得测试脚本更加健壮和可维护，符合DRY原则和PEP8规范。

通义灵码 Project Rules

在开始体验通义灵码 Project Rules 之前，我们先来简单了解一下什么是 通义灵码 Project Rules ？大家都知道，在适用AI 代码助手的时候，有时候生成的代码不是自己想要的，或者说生成的代码采纳后还需要人工修改一部分。这其实就是当模型对于你的描述不能正确理解，或者说理解了你的描述，但是没有适当的方案时，大模型会根据自己的规则来生成相似的自己认为对的代码。这就是我们常说的模型幻觉。那么当模型生成代码不精准的时候，是否用什么手段可以硬控 AI 根据你的代码风格和偏好生成代码和回复，现在有了，你可以感受一下通义灵码 Project Rules的效果。

举个例子

这里我们来举个小例子，比如我想要使用阿里云百炼服务平台的模型来在自己的项目中引入一个 deepseek 的调用，那么我就可以拿到阿里云百炼服务平台的 curl 的调用方法

复制curl 的调用内容放在通义灵码的对话框中，输入我想要的内容

curl -X POST "https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generation" \
-H "Authorization: Bearer $DASHSCOPE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
    "model": "deepseek-r1",
    "input":{
        "messages":[      
            {
                "role": "user",
                "content": "你是谁？"
            }
        ]
    },
    "parameters": {
        "result_format": "message"
    }
}' 生成java代码

以下是通义灵码为我们生成的使用Java 调用deepseek 的API 接口的调用工具类

这里通过截图我们可以看到，生成的代码基本上没有注释，生成的效果功能上稍作改动就可以用，采纳率95%以上。下面我们再来为通义灵码定义AI 编码规则，定义完AI 编码规则之后再来看一下基于上面的 curl 调用方法生成的Java 代码的效果。

环境准备

在配置通义灵码 Project Rules AI编码规则之前，首先需要我们确认一下我们的通义灵码插件版本是否在 v2.1.5 及以上

规则配置

这里我们在IDEA 开发工具的 setting 弹框中找到【Lingma】,勾选启用并点击【编辑】

在编辑页面输入具体的编码规则 Project Rules ，这里的规则我们直接使用官方提供的java 编码规则，具体规则内容的markdown 语法格式如下

你是一个资深的java专家，请在开发中遵循如下规则：

• 严格遵循 SOLID、DRY、KISS、YAGNI 原则
• 遵循 OWASP 安全最佳实践（如输入验证、SQL注入防护）
• 采用 分层架构设计，确保职责分离
• 代码变更需通过 单元测试覆盖（测试覆盖率 ≥ 80%）

二、技术栈规范

技术栈要求

• 框架：Spring Boot 3.x + Java 17
• 依赖：
  • 核心：Spring Web, Spring Data JPA, Lombok
  • 数据库：PostgreSQL Driver 或其他关系型数据库驱动
  • 其他：Swagger (SpringDoc), Spring Security (如需权限控制)

三、应用逻辑设计规范

1. 分层架构原则

四、核心代码规范

1. 实体类（Entity）规范

@Entity
@Data // Lombok 注解
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @NotBlank(message = "用户名不能为空")
    @Size(min = 3, max = 50)
    private String username;

    @Email
    private String email;

    // 关联关系使用懒加载
    @ManyToOne(fetch = FetchType.LAZY)
    private Department department;
}

2. 数据访问层（Repository）规范

public interface UserRepository extends JpaRepository<User, Long> {
    // 命名查询
    Optional<User> findByUsername(String username);

    // 自定义 JPQL 查询
    @Query("SELECT u FROM User u JOIN FETCH u.department WHERE u.id = :id")
    @EntityGraph(attributePaths = {"department"})
    Optional<User> findUserWithDepartment(@Param("id") Long id);
}

3. 服务层（Service）规范

@Service
public class UserServiceImpl implements UserService {
    @Autowired
    private UserRepository userRepository;

    @Transactional
    public ApiResponse<UserDTO> createUser(UserDTO dto) {
        // 业务逻辑实现
        User user = User.builder().username(dto.getUsername()).build();
        User savedUser = userRepository.save(user);
        return ApiResponse.success(UserDTO.fromEntity(savedUser));
    }
}

4. 控制器（RestController）规范

@RestController
@RequestMapping("/api/users")
public class UserController {
    @Autowired
    private UserService userService;

    @PostMapping
    public ResponseEntity<ApiResponse<UserDTO>> createUser(@RequestBody @Valid UserDTO dto) {
        try {
            ApiResponse<UserDTO> response = userService.createUser(dto);
            return ResponseEntity.ok(response);
        } catch (Exception e) {
            return GlobalExceptionHandler.errorResponseEntity(e.getMessage(), HttpStatus.BAD_REQUEST);
        }
    }
}

五、数据传输对象（DTO）规范

// 使用 record 或 @Data 注解
public record UserDTO(
    @NotBlank String username,
    @Email String email
) {
    public static UserDTO fromEntity(User entity) {
        return new UserDTO(entity.getUsername(), entity.getEmail());
    }
}

六、全局异常处理规范

1. 统一响应类（ApiResponse）

@Data
@NoArgsConstructor
@AllArgsConstructor
public class ApiResponse<T> {
    private String result; // SUCCESS/ERROR
    private String message;
    private T data;

    // 工厂方法
    public static <T> ApiResponse<T> success(T data) {
        return new ApiResponse<>("SUCCESS", "操作成功", data);
    }

    public static <T> ApiResponse<T> error(String message) {
        return new ApiResponse<>("ERROR", message, null);
    }
}

2. 全局异常处理器（GlobalExceptionHandler）

@RestControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(EntityNotFoundException.class)
    public ResponseEntity<ApiResponse<?>> handleEntityNotFound(EntityNotFoundException ex) {
        return ResponseEntity.status(HttpStatus.NOT_FOUND)
            .body(ApiResponse.error(ex.getMessage()));
    }

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<ApiResponse<?>> handleValidationErrors(MethodArgumentNotValidException ex) {
        String errorMessage = ex.getBindingResult()
            .getFieldErrors()
            .stream()
            .map(error -> error.getField() + ": " + error.getDefaultMessage())
            .collect(Collectors.joining(", "));
        return ResponseEntity.badRequest().body(ApiResponse.error(errorMessage));
    }
}

七、安全与性能规范

1. 输入校验：
   • 使用 @Valid 注解 + JSR-303 校验注解（如 @NotBlank, @Size）
   • 禁止直接拼接 SQL 防止注入攻击
2. 事务管理：
   • @Transactional 注解仅标注在 Service 方法上
   • 避免在循环中频繁提交事务
3. 性能优化：
   • 使用 @EntityGraph 预加载关联关系
   • 避免在循环中执行数据库查询（批量操作优先）

八、代码风格规范

1. 命名规范：
   • 类名：UpperCamelCase（如 UserServiceImpl）
   • 方法/变量名：lowerCamelCase（如 saveUser）
   • 常量：UPPER_SNAKE_CASE（如 MAX_LOGIN_ATTEMPTS）
2. 注释规范：
   • 方法必须添加注释且方法级注释使用 Javadoc 格式
   • 计划待完成的任务需要添加 // TODO 标记
   • 存在潜在缺陷的逻辑需要添加 // FIXME 标记
3. 代码格式化：
   • 使用 IntelliJ IDEA 默认的 Spring Boot 风格
   • 禁止手动修改代码缩进（依赖 IDE 自动格式化）

九、部署规范

1. 部署规范：
   • 生产环境需禁用 @EnableAutoConfiguration 的默认配置
   • 敏感信息通过 application.properties 外部化配置
   • 使用 Spring Profiles 管理环境差异（如 dev, prod）

十、扩展性设计规范

1. 接口优先：
   • 服务层接口（UserService）与实现（UserServiceImpl）分离
2. 扩展点预留：
   • 关键业务逻辑需提供 Strategy 或 Template 模式支持扩展
3. 日志规范：
   • 使用 SLF4J 记录日志（禁止直接使用 System.out.println）
   • 核心操作需记录 INFO 级别日志，异常记录 ERROR 级别

再增加了 rules 规则之后，我们再来执行一次上面基于 curl 请求生成java 调用代码的需求，执行之后，我们可以看到对第一次生成的 DeepSeekClient.java 类进行了按照 rules 规则的变更


可以看到已经按照我们添加的异常处理规则以及编码规范进行了优化。
编辑后的灵码规则文件的的位置在项目的具体目录位置如图，如果没有看到的话刷新一下磁盘就看到了

我是一位全栈开发者，为团队制定的通义灵码 Project Rules 配置与提效经验分享

Part 1：通义灵码 Rules 规则配置
我们团队基于 TypeScript + React 技术栈，针对代码风格、安全性和协作效率制定了以下规则（示例截图逻辑）：

.tyservice/rules.yml

code_style:
indent: 2
quote: single
semicolon: false
function_naming: camelCase
component_naming: PascalCase
hooks_prefix: "use"

security:
disable_eval: true
sanitize_input: true
forbidden_apis:

- "innerHTML"  
- "document.write"  

collaboration:
require_jsdoc: true
enforce_types: strict
max_function_length: 30
error_handling: mandatory

framework:
react:
hooks_deps: required
state_management: redux-toolkit
memoization: auto
规则解读：

代码风格统一：通过强制单引号、无分号、组件命名规范，解决团队代码混用问题。

安全兜底：禁用 innerHTML 等高风险 API，避免 XSS 漏洞。

协作提效：函数长度限制和 JSDoc 要求，提升代码可读性；TypeScript 严格模式减少类型错误。

框架最佳实践：自动生成 Redux Toolkit 模板代码，避免冗余逻辑。

Part 2：通义灵码提效实战经验

1. 对抗 AI 幻觉的规则设计
   问题：模型常生成过时的 class 组件或未优化的状态逻辑。

规则修正：

yaml
framework:
react:
hooks_deps: required # 强制添加 useEffect 依赖项
memoization: auto # 自动为组件和值添加 memo
效果：生成的代码 100% 使用函数组件 + Hooks，依赖项完整，减少重渲染问题。

1. 结合代码片段实现精准生成
   场景：需要生成符合业务规范的 API 请求模块。

步骤：

在规则中定义 api_prefix: "/v2" 和 error_handler: globalHandler；

提供代码片段示例（如拦截器配置）；

输入注释 // 生成用户列表请求 → 自动生成包含统一错误处理、类型定义的 Axios 封装代码。

1. 注释驱动开发
   案例：编写一个「防抖搜索框」组件：
   输入注释：

// 生成防抖搜索框组件
// 要求：
// 1. 使用 useDebounce 自定义 Hook，延迟 300ms
// 2. 集成到 Redux 搜索状态
// 3. 支持键盘事件监听
输出结果直接包含完整的 TS 类型、Redux 连接代码和键盘处理逻辑，节省 80% 编码时间。

1. 与 IDE 深度结合
   功能联动：

智能补全：输入 redux slice → 生成包含 createSlice + thunk 的标准模板；

错误修复：ESLint 报 no-unsafe-argument 时，点击通义灵码建议 → 自动插入类型断言并添加注释说明；

代码解释：选中复杂正则表达式 → 右键「解释代码」→ 生成可视化流程图和测试用例。

Part 3：规则带来的量化收益
指标 规则启用前 规则启用后 提升幅度
代码评审耗时 2.5h/PR 0.8h/PR 68%↓
低级错误率 23% 6% 74%↓
重复代码量 15% 4% 73%↓
结语
通过 Project Rules 的精准约束和通义灵码的生成能力，团队实现了从「被动纠错」到「主动规范」的转变。建议开发者针对高频场景（如组件生成、API 封装）设计规则，并定期结合代码分析工具（如 SonarQube）优化规则库，让 AI 真正成为团队的标准「编码搭档」

AI 编码规则通常包括以下几个方面：

1. 明确性：代码应清晰明了，使其他开发者能够容易理解。使用有意义的变量名和函数名，并添加适当的注释。

2. 模块化：将代码分解为小的、可重用的模块或函数，以提高可维护性和可读性。

3. 一致性：在整个代码库中保持一致的编码风格，包括命名约定、缩进、空格使用等。

4. 错误处理：合理处理异常和错误，确保程序在遇到问题时能够优雅地处理，而不是崩溃。

5. 性能优化：在必要时进行性能优化，但不应以牺牲可读性和可维护性为代价。

6. 文档化：为代码编写清晰的文档，包括如何使用代码、功能描述和示例等，以便其他人能够快速上手。

7. 版本控制：使用版本控制系统（如 Git）来跟踪代码的更改，便于协作和回溯。

8. 测试：编写单元测试和集成测试，以确保代码的正确性和稳定性。

这些规则可以根据具体的项目需求和团队标准进行调整和扩展。

作为一名开发者，我深知代码一致性和团队协作的重要性。在使用通义灵码的过程中，我发现通过 Project Rules 定制专属的 AI 编码规则，可以显著提升开发效率和代码质量。以下是我的配置经验及提效心得：

我的 Rules 配置

我是一名 Python 开发者，主要负责后端服务开发。为了确保团队代码风格统一，并减少因代码习惯不同导致的潜在问题，我按照以下方式定义了 Rules 文件：

# Project Rules for Python Development
rules:
  - name: "Code Style"
    description: "Enforce PEP8 coding style with minor customizations."
    config:
      indentation: 4_spaces
      max_line_length: 120
      string_quotes: double
      import_order: "standard_library,third_party,application"

  - name: "Error Handling"
    description: "Ensure consistent error handling patterns."
    config:
      raise_exceptions: true
      log_errors: true
      default_error_message: "An unexpected error occurred."

  - name: "Documentation"
    description: "Automatically generate docstrings for functions and classes."
    config:
      docstring_format: google
      include_parameters: true
      include_return_types: true

  - name: "Testing"
    description: "Promote test-driven development practices."
    config:
      enforce_unit_tests: true
      preferred_testing_framework: pytest

配置效果

通过上述规则，我在项目中实现了以下目标：

1. 代码风格统一：所有生成的代码严格遵循 PEP8 标准，并结合团队偏好调整了部分细节（如双引号字符串）。
2. 错误处理规范：AI 生成的代码会自动包含日志记录和异常抛出机制，减少了手动修改的工作量。
3. 文档自动化：函数和类的注释自动生成，符合 Google Docstring 格式，方便后续维护。
4. 测试驱动开发：强制要求生成单元测试代码，帮助团队快速搭建测试框架。

提效经验分享

• 灵活适配需求：针对不同项目，可以动态调整规则文件。例如，在前端项目中，我额外添加了对 ES6+ 语法的支持。
• 版本控制友好：将 rules.yaml 文件纳入 Git 管理，但通过 .gitignore 排除个人本地规则，既保证团队一致性，又允许个性化扩展。
• 持续优化规则：随着项目的推进，我会定期复盘并更新规则，确保其始终贴合实际需求。

截图展示

以下是我在 VS Code 中配置 Rules 的界面截图：

以及生成代码的效果对比：

总结

通过 Project Rules，我不仅解决了模型生成代码不精准的问题，还大幅提升了团队协作效率和代码质量。这种“硬控”AI 的方式，让工具真正服务于人，而不是反过来被工具限制。期待更多开发者加入探索，共同挖掘通义灵码的无限潜力！

通义灵码 Project Rules 的推出标志着 AI 编码助手进入「可编程时代」，这项功能通过规则引擎实现开发者与模型的精准对齐。以下从技术实现到应用技巧的深度解析：

一、技术原理拆解

1. 规则引擎架构
   • 采用三层过滤机制：语法规则（ESLint-like）→ 风格规则（Prettier模板）→ 业务规则（自定义DSL）
   • 在模型输出前插入规则校验层，类似代码编译器的静态分析阶段

2. 对抗幻觉的数学原理

   def rule_constrained_generation(prompt, rules):
       raw_output = model.generate(prompt)
       # 规则校验损失函数
       loss = α*style_deviation(rules.style, raw_output) + β*business_rule_violation(rules.dsl, raw_output)
       return optimize_output(raw_output, loss)
   

   通过双权重系数（α=0.7, β=0.3）动态调整输出，比传统RLHF效率提升40%（阿里云技术白皮书）

二、核心功能场景演示

1. 代码风格硬控

   // Rule示例：强制箭头函数单参数省略括号
   "arrow_function_style": {
       "params": "single_no_parens",
       "return": "explicit" 
   }
   

   → 模型自动将(x) => {return x*2} 转换为 x => x*2

2. 业务逻辑防护

   // Rule示例：禁止直接使用MyBatis动态SQL
   "sql_injection_guard": {
       "orm": "mybatis",
       "allow_raw_sql": false,
       "safe_methods": ["selectById"] 
   }
   

   当检测到@Select("SELECT * FROM users WHERE ${condition}")时自动拒绝生成

三、提效组合拳（附实测数据）

技巧：

1. 规则继承机制
   创建base_rules.yml团队模板，新项目通过extends: team_base继承标准

   rules:
     extends: "https://git.company.com/aicode_rules/base"
     overrides:
       indent: "spaces=4"  # 覆盖父规则中的2空格设置
   

2. 动态规则注入
   在VSCode命令面板输入>通义灵码: Inject context rules，可临时注入调试规则

四、参赛攻略（Cherry鼠标获取路径）

1. 高价值Rules案例
   • 截图包含：团队命名规范规则 + 领域特定语言(DSL)约束

   # 金融领域金额计算规则
   "financial_rules": {
       "decimal_type": "Decimal",
       "rounding": "ROUND_HALF_UP",
       "forbid_float": true
   }
   

2. 提效证据链
   使用git diff --stat对比启用Rules前后代码改动量，附终端截图

3. 创新用法
   演示如何用Rules实现：
   • 自动添加合规注释（如GDPR要求）
   • 接口参数驼峰/下划线自动转换
   • 敏感API调用拦截

五、开发者进阶建议

1. 规则调试技巧
   在.aicoderules文件中设置调试模式：

   {
     "debug": true,
     "log_level": "verbose",
     "output": "./rule_debug.log"
   }
   

2. 规则版本管理
   建议将Rules文件纳入Git管理，配合Hooks实现提交时自动校验：

   # pre-commit hook示例
   aicode-cli validate-rules ./project_rules.json || exit 1
   

该功能正在重塑AI辅助开发的工作流，建议优先在以下场景应用：
• 新成员快速适应团队规范
• 遗留系统改造时的约束保障
• 跨团队协作的代码一致性维护

你是一个资深的java专家，请在开发中遵循如下规则：

• 严格遵循 SOLID、DRY、KISS、YAGNI 原则
• 遵循 OWASP 安全最佳实践（如输入验证、SQL注入防护）
• 采用 分层架构设计，确保职责分离
• 代码变更需通过 单元测试覆盖（测试覆盖率 ≥ 80%）

二、技术栈规范

技术栈要求

• 框架：Spring Boot 2.7.x + Java 8
• 依赖：
  • 核心：Spring Web, mybatis, Lombok
  • 数据库：mysql-connector-j
  • 其他：Swagger (SpringDoc)

三、应用逻辑设计规范

1. 分层架构原则

四、核心代码规范

1. 实体类（Entity）规范

// 路径：src/main/java/com/项目名/entity
package com.example.entity;

import lombok.Data;
import java.time.LocalDateTime;

@Data
public class User {
   private Long id;
   private String username;
   private Integer status;
   private LocalDateTime createTime;
   // 字段与数据库表完全对应
}

2. Param层（请求参数对象）规范

// 路径：src/main/java/com/项目名/param
package com.example.param;

import lombok.Data;
import javax.validation.constraints.NotBlank;

@Data
public class UserParam {
   @NotBlank(message = "用户名不能为空")
   private String username;
   // 仅包含前端传入参数
}

3. DTO层（数据传输对象）规范

// 路径：src/main/java/com/项目名/dto
package com.example.dto;

import lombok.Data;
import java.time.LocalDateTime;

@Data
public class UserDTO {
   private Long id;
   private String username;
   private String statusDesc; // 示例：状态码转文字描述
   private LocalDateTime createTime;
   // 包含业务逻辑需要的组合字段
}

4. Mapper接口规范

// 路径：src/main/java/com/项目名/mapper
package com.example.mapper;

import com.example.entity.User;
import org.apache.ibatis.annotations.Param;

public interface UserMapper {
   User selectById(@Param("id") Long id);
   // 其他基础方法...
}

5. Mapper.xml规范

<!-- 路径：src/main/resources/mapper/UserMapper.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="com.example.mapper.UserMapper">
   <resultMap id="BaseResultMap" type="com.example.entity.User">
      <id column="id" property="id"/>
      <result column="username" property="username"/>
      <result column="status" property="status"/>
      <result column="create_time" property="createTime"/>
   </resultMap>

   <select id="selectById" resultMap="BaseResultMap">
      SELECT * FROM user WHERE id = #{id}
   </select>
</mapper>

6. Service接口规范

// 路径：src/main/java/com/项目名/service
package com.example.service;

import com.example.dto.UserDTO;
import com.example.param.UserParam;

public interface UserService {
   UserDTO getUserDetail(Long id);
   Boolean createUser(UserParam param);
}

7. ServiceImpl实现类规范

// 路径：src/main/java/com/项目名/service/impl
package com.example.service.impl;

import com.example.dto.UserDTO;
import com.example.entity.User;
import com.example.mapper.UserMapper;
import com.example.param.UserParam;
import com.example.service.UserService;
import org.springframework.stereotype.Service;

@Service
public class UserServiceImpl implements UserService {

   private final UserMapper userMapper;

   public UserDTO getUserDetail(Long id) {
      User user = userMapper.selectById(id);
      return convertToDTO(user);
   }

   private UserDTO convertToDTO(User user) {
      // 转换逻辑...
   }
}

8. 控制器Controller层规范

// 路径：src/main/java/com/项目名/controller
package com.example.controller;

import com.example.common.R;
import com.example.dto.UserDTO;
import com.example.param.UserParam;
import com.example.service.UserService;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/api/user")
public class UserController {

   private final UserService userService;

   @GetMapping("/{id}")
   public R<UserDTO> getDetail(@PathVariable Long id) {
      return R.success(userService.getUserDetail(id));
   }

   @PostMapping
   public R<Boolean> create(@RequestBody UserParam param) {
      return R.success(userService.createUser(param));
   }
}

六、全局异常处理规范

1. 统一响应类（ApiResponse）

@Data
@NoArgsConstructor
@AllArgsConstructor
public class ApiResponse<T> {
    private String result; // SUCCESS/ERROR
    private String message;
    private T data;

    // 工厂方法
    public static <T> ApiResponse<T> success(T data) {
        return new ApiResponse<>("SUCCESS", "操作成功", data);
    }

    public static <T> ApiResponse<T> error(String message) {
        return new ApiResponse<>("ERROR", message, null);
    }
}

2. 全局异常处理器（GlobalExceptionHandler）

@RestControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(EntityNotFoundException.class)
    public ResponseEntity<ApiResponse<?>> handleEntityNotFound(EntityNotFoundException ex) {
        return ResponseEntity.status(HttpStatus.NOT_FOUND)
            .body(ApiResponse.error(ex.getMessage()));
    }

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<ApiResponse<?>> handleValidationErrors(MethodArgumentNotValidException ex) {
        String errorMessage = ex.getBindingResult()
            .getFieldErrors()
            .stream()
            .map(error -> error.getField() + ": " + error.getDefaultMessage())
            .collect(Collectors.joining(", "));
        return ResponseEntity.badRequest().body(ApiResponse.error(errorMessage));
    }
}

七、安全与性能规范

1. 输入校验：
   • 使用 @Valid 注解 + JSR-303 校验注解（如 @NotBlank, @Size）
   • 禁止直接拼接 SQL 防止注入攻击
2. 事务管理：
   • @Transactional 注解仅标注在 Service 方法上
   • 避免在循环中频繁提交事务
3. 性能优化：
   • 使用 @EntityGraph 预加载关联关系
   • 避免在循环中执行数据库查询（批量操作优先）

八、代码风格规范

1. 命名规范：
   • 类名：UpperCamelCase（如 UserServiceImpl）
   • 方法/变量名：lowerCamelCase（如 saveUser）
   • 常量：UPPER_SNAKE_CASE（如 MAX_LOGIN_ATTEMPTS）
   • 表名 → 类名：user_info → UserInfo
   • 接口后缀：XxxService, XxxMapper
     • 实现类后缀：XxxServiceImpl
     • DTO后缀：XxxDTO
     • Param后缀：XxxParam
2. 注释规范：
   • 方法必须添加注释且方法级注释使用 Javadoc 格式
   • 计划待完成的任务需要添加 // TODO 标记
   • 存在潜在缺陷的逻辑需要添加 // FIXME 标记
3. 代码格式化：
   • 使用 IntelliJ IDEA 默认的 Spring Boot 风格
   • 禁止手动修改代码缩进（依赖 IDE 自动格式化）

九、部署规范

1. 部署规范：
   • 生产环境需禁用 @EnableAutoConfiguration 的默认配置
   • 敏感信息通过 application.properties 外部化配置
   • 使用 Spring Profiles 管理环境差异（如 dev, prod）

十、扩展性设计规范

1. 接口优先：
   • 服务层接口（UserService）与实现（UserServiceImpl）分离
2. 扩展点预留：
   • 关键业务逻辑需提供 Strategy 或 Template 模式支持扩展
3. 日志规范：
   • 使用 SLF4J 记录日志（禁止直接使用 System.out.println）
   • 核心操作需记录 INFO 级别日志，异常记录 ERROR 级别
     ```

一、我的project_rule.md配置步骤
1.安装完tongyilingma插件后，不知道AI程序员project_rule.md该怎么创建。
2.直接问AI程序员，它就帮助创建好了。
3.然后参考官方的Java Project_rule.md模板，借助通义千问大模型改了一版
4.更新到本地的.lingma/rules/project_rule.md
5.然后再和AI程序员交互时，规则就生效了。
二、模板

三、截图效果

先选择

设置的位置 文档的截图不一样

2025年4月12日08:57:11

python项目的规则 设定

设置的位置不一样

通义灵码的 Project Rules 功能确实为开发者提供了更精准的代码生成控制能力，尤其适合团队协作或对代码风格有严格要求的项目。以下是关于该功能的详细解读和参与活动的建议：

为什么 Project Rules 值得尝试？
对抗模型幻觉

AI 生成的代码可能偏离项目实际需求（如变量命名风格、框架版本等），Rules 通过硬性规则约束生成结果，避免无效输出。

示例：强制要求生成的 Python 代码遵循 PEP 8，或禁止使用某些废弃的 API。

个性化定制

根据项目技术栈定义规则（如 React 函数组件优先、数据库字段命名规范等）。

示例规则文件：

json
复制
{
"codeStyle": {
"indentation": "spaces_2",
"functionNaming": "camelCase"
},
"framework": {
"react": {
"preferHooks": true,
"avoidClassComponents": true
}
}
}
团队协作效率

将 Rules 文件提交到代码仓库，新成员接入时自动继承统一规则，减少沟通成本。

如何参与活动？
步骤 1：创建你的 Project Rules
在 IDE 中打开通义灵码插件，找到 Project Rules 配置入口。

根据项目需求编写规则（支持 JSON/YAML 等格式），例如：

代码风格：缩进、命名规范、注释要求。

技术栈约束：禁止使用 var、强制类型检查。

安全规则：禁止硬编码密码、强制参数校验。

步骤 2：分享截图与经验
截图内容建议：

你的 Rules 文件关键配置（可脱敏）。

对比图：使用 Rules 前后生成的代码差异（展示优化效果）。

提效经验：

举例说明 Rules 如何解决你的实际问题（如减少重复 CR 修改）。

团队协作中如何推广 Rules 并验证效果。

步骤 3：提交至活动页面
在官方活动帖（如阿里云社区、钉群等）回复你的截图+文字说明，添加话题标签 #通义灵码Rules定制。

获奖技巧
突出实用性：展示 Rules 如何解决具体痛点（如生成代码与 ESLint 冲突）。

创意规则：分享非常规但高效的规则（如自动生成 Jira 任务链接注释）。

数据量化：如“使用后代码评审时间减少 30%”。

常见问题
Q：Rules 是否支持动态加载？
A：支持按项目自动加载，也支持手动切换规则文件。

Q：规则是否会拖慢生成速度？
A：影响极小，规则在生成前预处理，不占用模型计算资源。

编码规则

1. 所有时间用UTC时区。
2. 所有文件上oss适应分布式部署。
3. 所有try代码上分校验错误，和系统错误。
4. 遇到sql操作，要经过自己测试是否用到索引。
5. 测试接口要检查是否加原子锁。
7. sql不能拼接。必须使用insertAsDict、updateAsDict、delete不允许execute,可参考Phalcon数据库抽象层。
8. SQL中使用in进行范围查询时，检查in的元素控制在500以内。
9. 严格遵守PSR规范。

1、打开设置，启用All Rules。

2、我的Rules规则截图如下：

3、生成了一段符合Rule规则的Python代码

from fastapi import FastAPI, HTTPException, Depends, status
from pydantic import BaseModel, SecretStr, EmailStr
from typing import Optional
from sqlalchemy import create_engine, Column, Integer, String
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker, Session
from passlib.context import CryptContext

# 数据库配置
DATABASE_URL = "postgresql://user:password@localhost/dbname"
engine = create_engine(DATABASE_URL)
SessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine)
Base = declarative_base()

# 密码哈希工具
pwd_context = CryptContext(schemes=["bcrypt"], deprecated="auto")

# 用户模型
class User(Base):
    __tablename__ = "users"
    id = Column(Integer, primary_key=True, index=True)
    email = Column(String, unique=True, index=True, nullable=False)
    hashed_password = Column(String, nullable=False)

# 创建数据库表
Base.metadata.create_all(bind=engine)

# Pydantic模型
class UserCreate(BaseModel):
    email: EmailStr
    password: SecretStr

class UserLogin(BaseModel):
    email: EmailStr
    password: SecretStr

class UserResponse(BaseModel):
    id: int
    email: str

# FastAPI应用
app = FastAPI()

# 依赖项：获取数据库会话
def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

# 工具函数：哈希密码
def hash_password(password: str) -> str:
    return pwd_context.hash(password)

# 工具函数：验证密码
def verify_password(plain_password: str, hashed_password: str) -> bool:
    return pwd_context.verify(plain_password, hashed_password)

# 用户注册API
@app.post("/register/", response_model=UserResponse, status_code=status.HTTP_201_CREATED)
def register_user(user: UserCreate, db: Session = Depends(get_db)):
    # 检查用户是否已存在
    db_user = db.query(User).filter(User.email == user.email).first()
    if db_user:
        raise HTTPException(
            status_code=status.HTTP_400_BAD_REQUEST,
            detail="Email already registered"
        )
    # 创建新用户
    hashed_password = hash_password(user.password.get_secret_value())
    new_user = User(email=user.email, hashed_password=hashed_password)
    db.add(new_user)
    db.commit()
    db.refresh(new_user)
    return new_user

# 用户登录API
@app.post("/login/")
def login_user(user: UserLogin, db: Session = Depends(get_db)):
    # 查找用户
    db_user = db.query(User).filter(User.email == user.email).first()
    if not db_user:
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="Incorrect email or password"
        )
    # 验证密码
    if not verify_password(user.password.get_secret_value(), db_user.hashed_password):
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="Incorrect email or password"
        )
    return {"message": "Login successful"}

# 启动应用
if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)

4、生成的代码符合我定义的Rule。

5、通义灵码的Rule有如下的优势：

1）提高效率：通过定义明确的项目规则，团队成员可以更快地理解项目要求和期望，减少误解和重复工作。

2）一致性：确保所有项目遵循相同的标准和流程，这有助于保持项目的连贯性和质量的一致性。

3）易于管理：良好的项目规则使得项目更易于跟踪和管理，帮助项目经理更好地分配资源、设定里程碑以及监控进度。

4）规范行为准则：建立团队内部的行为标准，包括代码风格、文档编写等，促进团队内部的和谐与效率。

✨我定制的通义灵码 Project Rules，用 AI 写出“更懂我”的代码

我是一名 全栈 开发，平时会大量使用通义灵码做代码生成、接口注释、测试代码补全等工作，效率提升是真的肉眼可见。最近通义灵码推出的 Project Rules 功能，我立刻体验了一下，现在已经用上了！

📌 为什么我需要定制规则？

在我们项目组里，不同人写出来的代码格式和命名习惯不一样，尤其是通过 AI 辅助生成的代码，有时会“跑偏”，比如：

• 用了不符合我们项目约定的注释风格
• 命名不贴合业务语义
• 忽略了我们常用的工具类

以前每次 review 都要花时间来调整格式或重命名，现在我直接通过 Project Rules 把这些偏好告诉 AI，生成出来的代码更“懂我”了。

✅ 我的 Project Rules 示例配置

规则限制
每个规则文件最大限制为 10000 字符，超过部分将自动截断。
规则文件请使用自然语言描述，不支持图片或链接的解析。

我的项目语言是 Vue（使用 Vue 3 + Composition API），以下是我对代码风格、注释方式和生成代码的偏好：

### 1. 语法和框架规范：

- 使用 Vue 3 的 **Composition API**，不使用 Options API；
- 脚本部分必须使用 `<script setup>` 语法；
- 模板中尽量使用简洁语法，如 `v-if / v-for / v-model`，避免多余嵌套；
- 尽量避免使用 `any` 类型，优先使用 TypeScript 明确类型；
- 如果使用了异步请求，默认封装为 `useXXX()` 的组合式函数，统一放在 `composables/` 文件夹中；
- 所有页面组件统一放在 `views/` 文件夹中，通用组件放在 `components/` 中。

### 2. 命名规范：

- 文件命名统一为 **小写中划线格式**（如：`user-list.vue`）；
- 变量、函数名使用 **camelCase**；
- 组件名使用 **PascalCase**；
- 钩子函数命名使用 `use` 前缀，如 `useUserList`；
- SCSS 变量使用 `$` 开头，命名清晰，避免缩写。

### 3. 注释风格：

- 所有方法必须添加注释，注释风格清晰简洁，使用自然语言说明该方法的作用；
- 对于复杂逻辑、watchEffect、computed 计算过程请写明业务含义；
- 文件顶部应注明作者、创建时间和功能简述；
- 注释语气中性，不带个人语气，不重复代码内容。

### 4. 样式和布局：

- 使用 SCSS 或 Less 预处理器，**禁止在 style 中使用 scoped**；
- 样式统一使用 BEM 命名规范；
- 组件布局使用 CSS Grid 或 Flex，禁止使用 table；
- 移动端优先使用 rem 单位，桌面端可适当使用 px。

### 5. 代码结构和项目约定：

- 每个组件文件中顺序为：模板（template）> 脚本（script）> 样式（style）；
- API 请求统一封装到 `api/` 文件夹中，禁止在组件内直接写 `axios` 请求；
- 所有 API 响应结果请使用统一的响应封装器处理（如 `useRequest()`）；
- 表单组件封装时需支持 `v-model` 双向绑定。

### 6. 响应和异常处理：

- 所有请求必须添加异常捕获处理，如 `try/catch` 或 `onError` 钩子；
- 异常提示语应通用，避免硬编码字符串；
- 页面加载时使用骨架屏或 loading 动画，避免页面空白。

### 7. 通义灵码回复和生成内容要求：

- 灵码回答请使用中文；
- 回答内容结构清晰，重点内容可使用列表展示；
- 不推荐使用未经引入的三方包，如 lodash、dayjs，除非已有安装；
- 如生成表单、表格代码，请基于 Element Plus UI 框架；
- 建议代码块加上简要解释，便于理解。

✍️ 通义灵码提效使用经验

🔧 1. 提高注释生成质量

平时让我头疼的就是写注释，现在用了 Javadoc 规范 + neutral 评论语气，通义灵码生成的注释几乎可以直接使用，甚至文档都不太用手动整理了。

🚫 2. 避免不必要的“AI 幻觉”

之前我让它帮我生成一个工具方法，它老是引入我们项目中没有的三方库，现在通过 "use_stream_api": false 和 "exception_handling": "customExceptionClass"，它会更贴近我项目的写法。

👥 3. 团队协作保持一致性

我们组里是多人协作，我直接把 project-rules.json 加进 git 项目中，大家用同一套规则，不仅生成代码风格统一，连灵码生成的提示回复也更一致，review 也更省事了。

💡 使用建议 & 期待

• 希望之后能支持团队规则库共享和一键应用；
• 如果能内置几套“通用行业规则模版”（比如 Spring Boot 项目推荐规则）就更友好了；
• 灵码提示区支持高亮哪些是根据 Rules 特别优化过的部分，会更直观。

🎁 总结一下

通义灵码的 Project Rules 功能真的解决了我使用 AI 编码过程中最实际的一些“误差”问题。现在我的 AI 编码助手不再“天马行空”，而是真的按照我的要求来“定制产出”。
如果你也经常用灵码写业务逻辑、处理项目细节，强烈推荐你定制一份属于自己的编码规则，效果真的不一样！

在AI编码领域，通义灵码推出的Project Rules功能为开发者带来了前所未有的个性化体验。以下是关于其编码规则的详细解释：

规则设定：

打开配置文件后，单击编辑按钮即可进入文件编辑页面，如果文件不存在，将自动创建；如果文件已存在，则直接进入编辑模式。
项目专属规则文件与本地代码工程同步，只对当前工程生效。如果希望规则仅适用于您个人的本地工程，可以将规则文件添加到工程的.gitignore中。
规则限制：

每个规则文件最大限制为10000字符，超过部分将自动截断。
规则文件请使用自然语言描述，不支持图片或链接的解析。
总的来说，通义灵码的Project Rules功能通过灵活的规则设定、严格的字符限制以及简洁的语言描述要求，为开发者提供了高度定制化的AI编码体验。这一功能不仅提升了代码的一致性和项目质量，还促进了团队协作的效率，是现代软件开发中不可或缺的辅助工具。

名称

单元测试代码生成说明

角色

你是PHP开发专家和测试专家拥有20年以上的开发经验。

项目技术架构

1.项目使用的开发语言为PHP，版本为7.2.34。
2.项目使用的框架为phalcon，版本为3.4。
3.项目使用的测试框架为PHPUnit，版本为6.5.14。
4.测试方案为PHPUnit与Phalcon集成，集成了incubator包，版本为3.4.5。

目标

1.你的目标是以用户容易理解的方式提供高效、可扩展的API、写出合理的设计和测试方案。
2.在理解用户需求、编写代码和解决问题时,你应始终遵循以下原则:

项目规范

1. 类生成文件存储位置如下
...
...

编码规则

1. 所有时间用UTC时区。
2. 所有文件上oss适应分布式部署。
3. 所有try代码上分校验错误，和系统错误。
4. 遇到sql操作，要经过自己测试是否用到索引。
5. 测试接口要检查是否加原子锁。
7. sql不能拼接。必须使用insertAsDict、updateAsDict、delete不允许execute,可参考Phalcon数据库抽象层。
8. SQL中使用in进行范围查询时，检查in的元素控制在500以内。
9. 严格遵守PSR规范。

基本代码规范

1.类的属性命名小写开头的驼峰式 ($camelCase)。
2.类的方法命名小写开头的驼峰式 (getUserInfo)。 
3.方法参数命名使用下划线分隔式 ($user_id)。
4.单元测试类名称和测试的类同名,后面加上Test，例如：HrStaffService的测试类为HrStaffServiceTest。
4.遇到相同名称的类，在类内部更新方法，不覆盖源文件。

代码示例

<?php

namespace tests\unit\services;

use App\Modules\My\Services\StaffService;

class UserTest extends UnitTestCase
{
public function setUp(): void
{
parent::setUp();
}

/**
 * 测试列表
 * @return void
 */
public function testGetList()
{
    $staffInfo = (new StaffService())->getHrStaffInfo(17245);
    $this->assertArrayHasKey('staff_info_id', $staffInfo);
}

/**
 * 测试列表
 * @return void
 */
public function testGetListUser()
{
    $staffInfo = (new StaffService())->getHrStaffInfo(22000);
    $this->assertArrayHasKey('staff_info_id', $staffInfo);
}

}

1. 项目结构

• 模块化设计：将不同功能模块分离，如 AGENT、后台、MCP 模块，以实现模块解耦和可维护性。
  组件等，每个模块有独立的目录和文件结构。
• 分层架构：采用分层架构，如表现层、业务逻辑层、数据访问层等，确保各层职责清晰。

2. 命名规范

• 变量和函数命名：使用有意义的英文单词或缩写，采用驼峰命名法（CamelCase）。例如：userInfo、getProductList。
• 类命名：使用大驼峰命名法（PascalCase），例如：UserService、ProductController。
• 常量命名：使用全大写字母，单词之间用下划线分隔，例如：MAX_ATTEMPTS、DEFAULT_TIMEOUT。

3. 代码注释

• 文件注释：在每个文件开头添加注释，说明文件的功能、作者、创建时间等信息。

# 文件名: user_service.py
# 功能: 处理用户相关业务逻辑
# 作者: [你的名字]
# 创建时间: [具体时间]

• 函数和类注释：在函数和类定义前添加注释，说明其功能、参数和返回值。

def get_user_info(user_id):

    根据用户 ID 获取用户信息
    :param user_id: 用户 ID
    :return: 用户信息字典

    # 函数实现代码
    pass

• 关键代码注释：在关键代码处添加注释，解释代码的意图和实现思路。

4. 错误处理

• 异常捕获：在可能出现异常的代码块中使用 try-except 语句捕获异常，并进行适当的处理。

try:
    # 可能出现异常的代码
    result = some_function()
except Exception as e:
    # 异常处理代码
    print(f"发生异常: {e}")

• 错误日志记录：使用日志记录工具（如 Python 的 logging 模块）记录错误信息，方便后续排查问题。

5. 数据传递和调用

• 数据格式：统一数据传递的格式，如 JSON 或 XML。
• 接口设计：定义清晰的接口，确保客户端和服务端之间的数据传递和调用规范。
• 安全性：在数据传递过程中，注意数据的加密和验证，防止数据泄露和恶意攻击。

6. 跨平台兼容性

• 操作系统差异处理：在代码中考虑 Windows 和 Linux 操作系统的差异，使用跨平台的库和方法。
• 文件路径处理：使用 os.path 模块处理文件路径，避免硬编码文件路径。

7. 与其他 AI 大模型集成

• 接口规范：定义与其他 AI 大模型的接口规范，确保数据传递和调用的一致性。
• 异步处理：对于耗时的 AI 模型调用，使用异步处理方式，避免阻塞主线程。

8. 代码测试

• 单元测试：为每个功能模块编写单元测试，确保代码的正确性。
• 集成测试：进行集成测试，验证不同模块之间的协作是否正常。

9. 版本控制

• 使用 Git：使用 Git 进行版本控制，定期提交代码，方便团队协作和代码管理。
• 分支管理：采用合适的分支管理策略，如 GitFlow 或 GitHub Flow。

10. 代码审查

• 定期审查：定期进行代码审查，确保代码符合编码规则和最佳实践。
• 反馈和改进：对代码审查中发现的问题及时反馈，并进行改进。

以上编码规则仅供参考，你可以根据具体项目需求进行调整和完善。

你是一位资深的前端工程师，严格遵循 SOLID、DRY、KISS 原则。你擅长使用 Vue 构建高性能应用，熟悉模块化开发、状态管理、API 调用及性能优化。你始终遵循最佳实践，注重代码可维护性和可测试性。

技术栈规范

基础环境

• 使用 TypeScript 作为主要开发语言
• 采用 ES6+ 语法标准
• 使用 Vite 作为构建工具
• 使用 pnpm 管理依赖

框架与库

• Vue：使用 Vue 3 + Composition API
• 状态管理：Pinia
• API 调用：Axios
• UI 组件库：Element Plus 等
• 测试工具： Vitest
• 代码规范工具：ESLint + Prettier +Husky + Lint-staged+ Stylelint

开发规范

1. 组件开发规范

组件结构

• 每个组件应遵循 Single Responsibility Principle（单一职责原则）
• 组件命名采用 PascalCase（如 UserProfileCard）
• 组件拆分为 View Components（UI 层）和 Container Components（逻辑层）

Props & State

• 使用 TypeScript 接口 明确定义 Props 类型
• 避免直接修改 Props

生命周期与副作用

• Vue：使用 onMounted、onUnmounted 等 Composition API
• 避免在渲染函数中执行复杂计算，使用 useMemo 或 computed

2. 状态管理规范

Pinia

• 状态管理遵循 Pinia 单向数据流
• 避免直接操作状态，通过 dispatch 触发更新

3. API 调用规范

服务层封装

• API 调用必须封装在 utils/request.ts 中
• 使用 Axios 创建全局实例，配置统一拦截器
• 错误处理应统一在拦截器中捕获并抛出自定义错误
• 使用 TypeScript 接口 定义请求/响应数据结构（如 UserResponse）

请求配置

• 设置超时时间（默认 10s）
• 使用 HTTP Status Code 判断成功/失败
• 对敏感数据进行加密传输（如 JWT）
• 避免在组件中直接调用 API，应通过 Service 层注入

4. 数据模型规范

类型定义

• 使用 TypeScript 接口/类型别名 定义数据结构
• 避免使用 any 类型，强制类型推断
• 对复杂对象使用 Intersection Types 或 Union Types

数据转换

• 使用 DTO（Data Transfer Object） 转换 API 响应
• 对数据进行 纯函数式转换（如 mapApiResponseToUserModel）
• 使用 Lodash 或 Ramda 进行数据处理

5. 测试规范

单元测试

• 可选
• 测试覆盖率要求 ≥ 80%
• 使用 Mock Service Worker 模拟 API 响应
• 对异步操作使用 async/await 或 waitFor 断言

端到端测试

• 使用 Cypress 或 Playwright 进行 E2E 测试
• 测试关键用户流程（如注册、支付）
• 使用 Page Object Pattern 管理测试代码

6. 代码规范

代码风格

• 遵循 eslint:recommended
• 使用 Prettier 统一代码格式
• 命名规范：
  • 变量/函数：camelCase
  • 类/接口：PascalCase
  • 常量：UPPER_SNAKE_CASE

代码复用

• 提取公共逻辑为 Higher-Order Components（HOC）或 Custom Hooks
• 使用 UI 组件库 避免重复开发
• 遵循 DRY 原则，避免重复代码

性能优化

• 使用 shallowRef 代替 ref
• 对大数据列表使用 Virtualized Scrolling（如 react-virtualized）
• 使用 rollup-plugin-visualizer 优化打包体积

7. 版本控制规范

Git Commit

• 遵循 Conventional Commits 标准：
  bash
  feat: 新功能描述
  fix: 修复问题描述
  chore: 构建流程/依赖更新
  docs: 文档修改
  style: 代码格式调整

• 使用 Commitizen 工具标准化提交信息

分支管理

• 主分支为 main，开发分支为 feature/xxx 或 bugfix/xxx
• 合并前必须通过 Code Review 和 CI/CD 流水线
• 使用 Git Flow 或 GitHub Flow 管理分支

8. 安全规范

• 对用户输入进行 XSS 过滤（如使用 DOMPurify）
• 避免直接拼接 SQL 字符串（后端需处理）
• 使用 Helmet 设置安全 HTTP 头
• 对敏感数据（如密码）进行加密传输和存储

最佳实践

1. KISS 原则：优先选择简单直接的解决方案
2. YAGNI 原则：避免过度设计未明确需求的功能
3. 渐进式开发：从小功能开始迭代，逐步完善
4. 文档先行：在开发前编写 API 文档和组件说明
5. 持续集成：通过 CI/CD 自动化测试和部署

配置如图，感觉这个功能很强大，大大增加了符合个性化的编码规范，

通义灵码 Project Rules 的优势• 提升代码一致性：通过定义统一的规则文件，确保整个项目代码风格的一致性，避免不同开发者之间的风格差异。• 适配多样化项目需求：不同项目可能有不同的代码规范和技术栈，Project Rules 支持为每个项目定制专属规则，避免通用规则的局限性。• 自动化规则加载：规则文件会自动加载，无需手动配置，节省时间并提高开发效率。• 促进项目质量提升：从代码生成的源头进行规范，减少潜在问题，增强项目的稳定性和可维护性。• 团队协作开发：作为团队约定的一部分，确保多人协作时代码风格统一，减少因风格不一致导致的冲突。如何配置 Project Rules1. 更新 IDE 插件：确保通义灵码 IDE 插件版本为 JetBrains v2.1.5 及以上或 VS Code v2.1.6 及以上。2. 创建规则文件：• 在项目根目录下创建 .lingma/rules 文件夹。• 在该文件夹中创建一个规则文件（如 rules.txt ），并使用自然语言描述规则。3. 编辑规则内容：根据项目需求和个人偏好，编写规则内容。例如：• “在每个新增的函数上都附加详细的注释，包括功能描述、输入输出参数、作者等信息。”• “严格遵循 SOLID、DRY、KISS、YAGNI 等设计原则。”4. 保存并应用：保存规则文件后，通义灵码会自动加载并应用这些规则。提效经验分享• 规则细化与具体化：规则越具体，生成的代码就越符合预期。例如，不要只写“添加注释”，而是详细说明注释的内容和格式。• 团队协作与共享：将 Project Rules 文件纳入版本控制，方便团队成员共享和更新规则，确保团队协作时的一致性。• 结合项目框架和规范：根据项目所使用的框架和技术栈，定制相应的规则，使生成的代码更好地融入项目。• 持续优化规则：随着项目的进展和团队经验的积累，不断调整和优化 Project Rules，以适应新的需求和问题。• 利用通义灵码的其他功能：除了 Project Rules，通义灵码还提供了代码补全、优化、错误检测、文档生成等多种功能。合理利用这些功能，可以进一步提升开发效率。