Trae 规则概述

Trae 规则概述#

参考：TRAE 规则（Rules）配置指南：个人习惯、团队规范与最佳实践

小技巧

推荐使用英语编写自定义规则，大多数情况下效果会更好

场景一：定义个人习惯#

通过配置个人规则，可以避免重复输入相同的要求。例如，希望模型默认遵循程序员的最佳实践，生成简洁、解耦的代码，而不是冗长的实现。配置规则后，模型生成的代码会更符合个人编码习惯和标准。

常见用例：

  1. 设定对话语言

Please always reply to me in Chinese.

  1. 定制TRAE人设 例如，定义温和的编程鼓励师：

You are my supportive programming partner and cheerful encourager.  
Your mission is to help me solve coding challenges while also bringing me comfort and motivation.  
Please answer my questions in a warm, gentle, and easygoing tone, like a caring little sister.  
When it feels right, add playful or lively expressions to make programming less monotonous and more fun.  
And remember, always address me as "Dear Master".

还有心理辅导师、郭德纲、于谦、林志玲、金星、鲁迅都可以成为你的AI编程伙伴，可以自己改写 Rules 描述。

场景二：定义团队规范#

如果团队已有规范，可直接复制到 project_rules.md 中。如果没有，可以尝试以下方法生成：

  1. 方法一：使用 TRAE 输入框生成项目规范

    • 输入框中输入：Generate project rules，示例：

    Please summarize the current project guidelines from the existing project content and document them in project_rules.md.

    • 模型会根据项目需求和团队习惯，生成符合规范的项目规则

  2. 方法二：参考社区最佳实践

    • 参考开源项目的规则，学习其规范描述方法并应用到自己的项目中。常见规范维度包括：单测规范、文档规范、命名规范、项目规范、样式规范、语言规范、demo规范等。

规则样例#

# 用户编码规范与重构指南

---

## 基础交互规则

1. **语言要求：**请始终使用中文回答。  
2. **代码注释：**若回答包含代码，请为关键节点与较难理解的部分添加简洁、准确的中文注释。  
3. **代码颗粒度：**当生成的代码超过 20 行时，请考虑适度聚合或拆分，并评估颗粒度是否合理。

---

## 通用编码规范

1. **对象管理：**避免不必要的对象复制或克隆。  
2. **控制流优化：**减少多层嵌套，优先使用提前返回以提升可读性。  
3. **并发与同步：**根据场景选择合适的并发控制机制（如锁、队列、原子操作），确保线程安全。

---

## Python 语言规范

### 1. 基础风格（遵循 PEP 8）
- 使用 **4 个空格缩进**，不使用 Tab。  
- 单行代码不超过 **79 个字符**，文档字符串不超过 **72 个字符**。  
- 函数、类之间使用两个空行分隔；类内方法之间使用一个空行。  
- 导入顺序：标准库 → 第三方库 → 本地模块，组间空一行。  
- 命名规范：  
  - 变量、函数：`snake_case`  
  - 类名：`PascalCase`  
  - 常量：`UPPER_CASE`  
  - 私有成员：前缀 `_`  

### 2. 文档与注释
- 公共模块、类、函数必须编写 **docstring**，推荐三引号 `"""`，遵循 [PEP 257]。  
- 注释应解释 **为什么**，避免冗余的“做什么”。  
- 推荐使用 **类型注解**（type hints），并结合 `mypy` 或 `pyright` 做静态检查。  

### 3. 代码组织
- 函数应保持简短，单一职责。  
- 每个模块聚焦一个主题，避免“上帝模块”。  
- 合理使用 `__init__.py` 控制导出接口，避免污染命名空间。  

### 4. 异常与错误处理
- 捕获具体异常类型，避免裸 `except:`。  
- 不要随意吞掉异常，必要时记录日志并重新抛出。  
- 为业务逻辑定义清晰的自定义异常类，继承自 `Exception`。  

### 5. Pythonic 写法
- 优先使用 `enumerate`、`zip`、`any`、`all` 等内置函数。  
- 适度使用推导式，避免过度嵌套。  
- 使用 `with` 管理资源（文件、锁、连接等）。  
- 根据场景选择合适的数据结构（`list`、`dict`、`set`、`tuple`）。  

### 6. 测试与工具
- 推荐使用 `pytest`，保持单元测试覆盖率。  
- 使用 `flake8`、`black`、`isort`、`mypy` 等工具保证风格一致与类型安全。  
- 使用 `venv` 或 `poetry` 管理依赖，避免全局污染。  

### 7. 性能与优化
- 避免不必要的导入，延迟加载大模块。  
- 优先使用生成器处理大数据集，避免内存爆炸。  
- 根据场景选择 `threading`、`multiprocessing` 或 `asyncio`。  

---

## 代码坏味道识别与处理

基于 Martin Fowler《重构》的核心观点，以下坏味道与处理策略应优先关注：

1. **神秘命名**：使用描述性命名，避免晦涩。  
2. **重复代码**：提取公共函数或模块，减少冗余。  
3. **过长函数**：拆分为职责单一的小函数。  
4. **过大的类/结构体**：提取类，按领域聚合。  
5. **过长参数列表**：引入参数对象，简化调用。  
6. **发散式变化**：按变化原因拆分类，分离关注点。  
7. **霰弹式修改**：将相关功能集中到同一类或模块。  
8. **依恋情结**：将函数移至更合适的类。  
9. **数据泥团**：提取为对象，显式表达聚合关系。  
10. **基本类型偏执**：用值对象替代基本类型。  

---

## 重构过程原则

1. **小步前进**：每次只做一个小改动并立即测试，频繁提交。  
2. **测试保障**：确保测试覆盖率，修改后运行测试保证行为不变。  
3. **代码审查**：重构后进行评审，分享经验提升团队能力。  

---

## 代码可读性优化

1. **命名约定**：语义明确，风格统一，避免随意缩写。  
2. **代码组织**：高内聚、单一职责、抽象层次一致。  
3. **注释与文档**：注释解释“为什么”，API 提供清晰文档，随代码更新。  

---

## 性能相关重构

1. **内存优化**：避免不必要的对象创建，及时释放资源，防止内存泄漏。  
2. **计算优化**：避免重复计算，选择合适的数据结构与算法，按需延迟计算。  
3. **并行优化**：识别可并行任务，避免过度同步，确保线程安全。  

---

## 附加实践建议

- **日志管理：**区分调试、信息、警告与错误等级，减少噪音。  
- **错误处理：**返回明确的错误类型与提示，避免吞错。  
- **配置外置：**将环境与敏感配置外置，避免硬编码。  
- **依赖隔离：**通过接口或适配器隔离第三方依赖，便于替换与测试。  
- **边界用例：**覆盖异常路径与边界条件，提升稳健性。
目录