|
| 1 | +# Trae 规则概述 |
| 2 | + |
| 3 | +参考:[TRAE 规则(Rules)配置指南:个人习惯、团队规范与最佳实践](https://lcnziv86vkx6.feishu.cn/wiki/GlLPw7PaqijeiWkPpXrc9v1Nnxb) |
| 4 | + |
| 5 | +```{tip} |
| 6 | +推荐使用英语编写自定义规则,大多数情况下效果会更好 |
| 7 | +``` |
| 8 | + |
| 9 | +## 场景一:定义个人习惯 |
| 10 | + |
| 11 | +通过配置个人规则,可以避免重复输入相同的要求。例如,希望模型默认遵循程序员的最佳实践,生成简洁、解耦的代码,而不是冗长的实现。配置规则后,模型生成的代码会更符合个人编码习惯和标准。 |
| 12 | + |
| 13 | +常见用例: |
| 14 | + |
| 15 | +1. 设定对话语言 |
| 16 | +``` |
| 17 | +Please always reply to me in Chinese. |
| 18 | +``` |
| 19 | +2. 定制TRAE人设 |
| 20 | +例如,定义温和的编程鼓励师: |
| 21 | +``` |
| 22 | +You are my supportive programming partner and cheerful encourager. |
| 23 | +Your mission is to help me solve coding challenges while also bringing me comfort and motivation. |
| 24 | +Please answer my questions in a warm, gentle, and easygoing tone, like a caring little sister. |
| 25 | +When it feels right, add playful or lively expressions to make programming less monotonous and more fun. |
| 26 | +And remember, always address me as "Dear Master". |
| 27 | +``` |
| 28 | + |
| 29 | +还有心理辅导师、郭德纲、于谦、林志玲、金星、鲁迅都可以成为你的AI编程伙伴,可以自己改写 Rules 描述。 |
| 30 | + |
| 31 | +## 场景二:定义团队规范 |
| 32 | + |
| 33 | +如果团队已有规范,可直接复制到 `project_rules.md` 中。如果没有,可以尝试以下方法生成: |
| 34 | + |
| 35 | +1. 方法一:使用 TRAE 输入框生成项目规范 |
| 36 | + - 输入框中输入:`Generate project rules`,示例: |
| 37 | + ``` |
| 38 | + Please summarize the current project guidelines from the existing project content and document them in project_rules.md. |
| 39 | + ``` |
| 40 | + - 模型会根据项目需求和团队习惯,生成符合规范的项目规则 |
| 41 | +2. 方法二:参考社区最佳实践 |
| 42 | + - 参考开源项目的规则,学习其规范描述方法并应用到自己的项目中。常见规范维度包括:单测规范、文档规范、命名规范、项目规范、样式规范、语言规范、demo规范等。 |
| 43 | +
|
| 44 | +## 规则样例 |
| 45 | +
|
| 46 | +``` |
| 47 | +# 用户编码规范与重构指南 |
| 48 | + |
| 49 | +--- |
| 50 | + |
| 51 | +## 基础交互规则 |
| 52 | + |
| 53 | +1. **语言要求:**请始终使用中文回答。 |
| 54 | +2. **代码注释:**若回答包含代码,请为关键节点与较难理解的部分添加简洁、准确的中文注释。 |
| 55 | +3. **代码颗粒度:**当生成的代码超过 20 行时,请考虑适度聚合或拆分,并评估颗粒度是否合理。 |
| 56 | + |
| 57 | +--- |
| 58 | + |
| 59 | +## 通用编码规范 |
| 60 | + |
| 61 | +1. **对象管理:**避免不必要的对象复制或克隆。 |
| 62 | +2. **控制流优化:**减少多层嵌套,优先使用提前返回以提升可读性。 |
| 63 | +3. **并发与同步:**根据场景选择合适的并发控制机制(如锁、队列、原子操作),确保线程安全。 |
| 64 | + |
| 65 | +--- |
| 66 | + |
| 67 | +## Python 语言规范 |
| 68 | + |
| 69 | +### 1. 基础风格(遵循 PEP 8) |
| 70 | +- 使用 **4 个空格缩进**,不使用 Tab。 |
| 71 | +- 单行代码不超过 **79 个字符**,文档字符串不超过 **72 个字符**。 |
| 72 | +- 函数、类之间使用两个空行分隔;类内方法之间使用一个空行。 |
| 73 | +- 导入顺序:标准库 → 第三方库 → 本地模块,组间空一行。 |
| 74 | +- 命名规范: |
| 75 | + - 变量、函数:`snake_case` |
| 76 | + - 类名:`PascalCase` |
| 77 | + - 常量:`UPPER_CASE` |
| 78 | + - 私有成员:前缀 `_` |
| 79 | + |
| 80 | +### 2. 文档与注释 |
| 81 | +- 公共模块、类、函数必须编写 **docstring**,推荐三引号 `"""`,遵循 [PEP 257]。 |
| 82 | +- 注释应解释 **为什么**,避免冗余的“做什么”。 |
| 83 | +- 推荐使用 **类型注解**(type hints),并结合 `mypy` 或 `pyright` 做静态检查。 |
| 84 | + |
| 85 | +### 3. 代码组织 |
| 86 | +- 函数应保持简短,单一职责。 |
| 87 | +- 每个模块聚焦一个主题,避免“上帝模块”。 |
| 88 | +- 合理使用 `__init__.py` 控制导出接口,避免污染命名空间。 |
| 89 | + |
| 90 | +### 4. 异常与错误处理 |
| 91 | +- 捕获具体异常类型,避免裸 `except:`。 |
| 92 | +- 不要随意吞掉异常,必要时记录日志并重新抛出。 |
| 93 | +- 为业务逻辑定义清晰的自定义异常类,继承自 `Exception`。 |
| 94 | + |
| 95 | +### 5. Pythonic 写法 |
| 96 | +- 优先使用 `enumerate`、`zip`、`any`、`all` 等内置函数。 |
| 97 | +- 适度使用推导式,避免过度嵌套。 |
| 98 | +- 使用 `with` 管理资源(文件、锁、连接等)。 |
| 99 | +- 根据场景选择合适的数据结构(`list`、`dict`、`set`、`tuple`)。 |
| 100 | + |
| 101 | +### 6. 测试与工具 |
| 102 | +- 推荐使用 `pytest`,保持单元测试覆盖率。 |
| 103 | +- 使用 `flake8`、`black`、`isort`、`mypy` 等工具保证风格一致与类型安全。 |
| 104 | +- 使用 `venv` 或 `poetry` 管理依赖,避免全局污染。 |
| 105 | + |
| 106 | +### 7. 性能与优化 |
| 107 | +- 避免不必要的导入,延迟加载大模块。 |
| 108 | +- 优先使用生成器处理大数据集,避免内存爆炸。 |
| 109 | +- 根据场景选择 `threading`、`multiprocessing` 或 `asyncio`。 |
| 110 | + |
| 111 | +--- |
| 112 | + |
| 113 | +## 代码坏味道识别与处理 |
| 114 | + |
| 115 | +基于 Martin Fowler《重构》的核心观点,以下坏味道与处理策略应优先关注: |
| 116 | + |
| 117 | +1. **神秘命名**:使用描述性命名,避免晦涩。 |
| 118 | +2. **重复代码**:提取公共函数或模块,减少冗余。 |
| 119 | +3. **过长函数**:拆分为职责单一的小函数。 |
| 120 | +4. **过大的类/结构体**:提取类,按领域聚合。 |
| 121 | +5. **过长参数列表**:引入参数对象,简化调用。 |
| 122 | +6. **发散式变化**:按变化原因拆分类,分离关注点。 |
| 123 | +7. **霰弹式修改**:将相关功能集中到同一类或模块。 |
| 124 | +8. **依恋情结**:将函数移至更合适的类。 |
| 125 | +9. **数据泥团**:提取为对象,显式表达聚合关系。 |
| 126 | +10. **基本类型偏执**:用值对象替代基本类型。 |
| 127 | + |
| 128 | +--- |
| 129 | + |
| 130 | +## 重构过程原则 |
| 131 | + |
| 132 | +1. **小步前进**:每次只做一个小改动并立即测试,频繁提交。 |
| 133 | +2. **测试保障**:确保测试覆盖率,修改后运行测试保证行为不变。 |
| 134 | +3. **代码审查**:重构后进行评审,分享经验提升团队能力。 |
| 135 | + |
| 136 | +--- |
| 137 | + |
| 138 | +## 代码可读性优化 |
| 139 | + |
| 140 | +1. **命名约定**:语义明确,风格统一,避免随意缩写。 |
| 141 | +2. **代码组织**:高内聚、单一职责、抽象层次一致。 |
| 142 | +3. **注释与文档**:注释解释“为什么”,API 提供清晰文档,随代码更新。 |
| 143 | + |
| 144 | +--- |
| 145 | + |
| 146 | +## 性能相关重构 |
| 147 | + |
| 148 | +1. **内存优化**:避免不必要的对象创建,及时释放资源,防止内存泄漏。 |
| 149 | +2. **计算优化**:避免重复计算,选择合适的数据结构与算法,按需延迟计算。 |
| 150 | +3. **并行优化**:识别可并行任务,避免过度同步,确保线程安全。 |
| 151 | + |
| 152 | +--- |
| 153 | + |
| 154 | +## 附加实践建议 |
| 155 | + |
| 156 | +- **日志管理:**区分调试、信息、警告与错误等级,减少噪音。 |
| 157 | +- **错误处理:**返回明确的错误类型与提示,避免吞错。 |
| 158 | +- **配置外置:**将环境与敏感配置外置,避免硬编码。 |
| 159 | +- **依赖隔离:**通过接口或适配器隔离第三方依赖,便于替换与测试。 |
| 160 | +- **边界用例:**覆盖异常路径与边界条件,提升稳健性。 |
| 161 | +``` |
0 commit comments