本文作者：管云凤，TRAE 技术专家
如何配置规则
1. 点击右侧 AI 功能管理 设置按钮
2. 进入 规则面板 进行新建
3. 在 左侧编辑器 填写规则
配置指南
💡 推荐使用英语编写自定义规则，大多数情况下效果会更好
场景一：定义个人习惯
通过配置个人规则，可以避免重复输入相同的要求。例如，希望模型默认遵循程序员的最佳实践，生成简洁、解耦的代码，而不是冗长的实现。配置规则后，模型生成的代码会更符合个人编码习惯和标准。
常见用例：
1. 设定对话语言
Please always reply to me in Chinese.
复制代码
2. 定制 TRAE 人设
例如，定义一个温和的编程鼓励师：
You are my programmer partner and encourager. You need to help me solve code problems and provide emotional value. I hope you can answer my questions gently and easily like a caring little sister. When necessary, you can add expressions to help me reduce the boredom of programming and increase the fun of it. By the way, please call me "Dear Master".
复制代码
还有心理辅导师、郭德纲、于谦、林志玲、金星、鲁迅都可以成为你的 AI 编程伙伴，可以自己改写 Rules 描述。
场景二：定义团队规范
如果团队已有规范，可直接复制到 project_rules.md 中。如果没有，可以尝试以下方法生成：
💡 建议：配置完成后尽量避免频繁修改，特别是大型团队项目。修改前应先在团队内部达成共识，再更新规则。
💡 团队规范转换技巧： 将团队现有的规范文档上传到 TRAE 的文档集中，然后在聊天框中引用该文档，告诉 AI：“我想把这个文档变成一个团队规范，请帮我聚合以及凝练一下。” AI 会根据文档内容和要求生成优化后的规则，可以直接复制到 project_rules.md 中。
1. 方法一：使用 TRAE 输入框生成项目规范
输入参考：
Please help me summarize the current project norms based on the current project content and write them into the project_rules.md.
复制代码
还有一些有想法的同学的实践，可以参考下：
2. 方法二：参考社区最佳实践
参考开源项目的规则，学习其规范描述方法并应用到自己的项目中。常见规范维度包括：单测规范、文档规范、命名规范、项目规范、样式规范、语言规范、demo 规范等。
示例：Changlog 规范（来自 antdesign ）
# 文档和 Changelog 规范
## 基本要求
- 提供中英文两个版本- 新的属性需要声明可用的版本号- 属性命名符合 antd 的 API 命名规则：https://github.com/ant-design/ant-design/wiki/API-Naming-rules
## Changelog 规范
- 在 CHANGELOG.en-US.md 和 CHANGELOG.zh-CN.md 书写每个版本的变更- 对用户使用上无感知的改动建议（文档修补、微小的样式优化、代码风格重构等等）不要提及，保持 CHANGELOG 的内容有效性- 非 antd 组件的改动（如工程化、构建工具、开发流程等）在 changelog 区块中写 "-"- 用面向开发者的角度和叙述方式撰写 CHANGELOG，不描述修复细节，描述问题和对开发者的影响；描述用户的原始问题，而非你的解决方式
### 示例
- 不好的例子：修复组件 Typography 的 dom 结构问题- 好的例子：修复了 List.Item 中内容空格丢失的问题
### 其他要求
- 新增属性时，建议用易于理解的语言补充描述用户可以感知的变化- 尽量给出原始的 PR 链接，社区提交的 PR 改动加上提交者的链接- 底层模块升级中间版本要去 rc-component 里找到改动，给出变动说明- 建议参考之前版本的日志写法- 将同组件的改动放在一起，内容子级缩进
### Changelog Emoji 规范
- 🐞 Bug 修复- 💄 样式更新或 token 更新- 🆕 新增特性，新增属性- 🔥 极其值得关注的新增特性- 🇺🇸🇨🇳🇬🇧 国际化改动- 📖 📝 文档或网站改进- ✅ 新增或更新测试用例- 🛎 更新警告/提示信息- ⌨️ ♿ 可访问性增强- 🗑 废弃或移除- 🛠 重构或工具链优化- ⚡️ 性能提升
# 文档规范
- 提供中英文两个版本- 新属性需声明可用的版本号- 属性命名符合 API 命名规则- 组件文档包含：使用场景、基础用法、API 说明- 文档示例应简洁明了- 属性的描述应清晰易懂- 对复杂功能提供详细说明- 加入 TypeScript 定义- 提供常见问题解答- 更新文档时同步更新中英文版本
复制代码
设计规范(来自 ArcoDesign )
请遵守下列设计原则：....科技风格请实现成科技、极客风格的设计，最好是软暗色，有科技背景，不给人简陋感。
突出重点用户的浏览动作不是读，不是看，而是扫。设计中应该突出重点，弱化和剔除无关信息。重要对话中不应该包含无关紧要的信息。....
复制代码
3. 方法三：使用自动生成工具
场景三：Rules + 自定义智能体 + MCP 场景
自定义智能体管理页面提供了为每个智能体编写个性化提示词的功能，但这些提示词仅限于单个智能体使用，智能体之间不能共享这些提示词。
如果希望所有智能体都能使用某些项目规范或个人习惯，应该将其放在 project_rules.md 或 user_rules.md 中，例如
Always chat in Chinese.Add function-level comments when generating code.My system is Mac.Use pnpm instead of npm.
复制代码
最佳规则示例
根据《重构》这本书的核心要求形成 User Rule
# 用户编码规范与重构指南
## 基础交互规则1. 请用中文回答我2. 如果回答的是代码，请给每个关键节点，比较难懂的代码增加中文注释3. 当生成的代码行数超过 20 行时，请考虑聚合代码以及考虑其颗粒度是否适合
## 代码质量与重构规范
### 通用编码规范1. 避免不必要的对象复制或克隆2. 避免多层嵌套，提前返回3. 使用适当的并发控制机制
## 代码坏味道识别与处理基于Martin Fowler《重构》一书的核心观点，以下是应当注意的代码坏味道及其处理方法：
### 1. 神秘命名- **问题**：变量、函数、类或模块的名称不能清晰表达其用途和含义- **处理**：重命名为具有描述性的名称，使代码自解释- **示例**：将`fn p()`改为`fn calculate_price()`
### 2. 重复代码- **问题**：相同或相似的代码出现在多个地方- **处理**：提取为函数、类或模块；应用模板方法模式- **示例**：将重复的验证逻辑提取为共享函数
### 3. 过长函数- **问题**：函数过长，难以理解和维护- **处理**：提取函数，将大函数分解为多个小函数- **示例**：将200行的处理函数分解为多个职责单一的小函数
### 4. 过大的类/结构体- **问题**：类或结构体承担了过多责任，字段和方法过多- **处理**：提取类，将相关字段和方法组合成新的类- **示例**：将User类中的地址相关字段提取为Address类
### 5. 过长参数列表- **问题**：函数参数过多，难以理解和使用- **处理**：引入参数对象，将相关参数组合成对象- **示例**：将`fn create_user(name, email, phone, address, city, country)`改为`fn create_user(user_info: UserInfo)`
### 6. 发散式变化- **问题**：一个类因为多种原因而被修改- **处理**：按照变化原因拆分类- **示例**：将既处理数据库又处理业务逻辑的类拆分为两个类
### 7. 霰弹式修改- **问题**：一次修改需要改动多个类- **处理**：将相关功能移到同一个类中- **示例**：将分散在多个类中的订单处理逻辑合并到一个OrderProcessor类
### 8. 依恋情结- **问题**：一个函数对其他类的兴趣超过自己所在的类- **处理**：移动函数或提取函数- **示例**：将过度使用另一个类数据的方法移动到那个类中
### 9. 数据泥团- **问题**：相同的数据项总是一起出现- **处理**：提取为对象- **示例**：将经常一起出现的起始日期和结束日期提取为DateRange类
### 10. 基本类型偏执- **问题**：使用基本类型表示有特定含义的数据- **处理**：使用小对象替代基本类型- **示例**：用PhoneNumber类替代表示电话的字符串
## 重构过程原则
### 1. 小步重构- 每次只做一个小改动，然后测试- 频繁提交，保持代码随时可工作
### 2. 测试保障- 重构前确保有足够的测试覆盖- 每次修改后运行测试确保行为不变
### 3. 代码审查- 重构后进行代码审查，确保质量- 分享重构经验，提高团队能力
## 代码可读性优化
### 1. 命名约定- 使用有意义的、描述性的名称- 遵循项目或语言的命名规范- 避免缩写和单字母变量（除非是约定俗成的，如循环中的i）
### 2. 代码组织- 相关代码应该放在一起- 函数应该只做一件事- 保持适当的抽象层次
### 3. 注释与文档- 注释应该解释为什么，而不是做什么- 为公共API提供清晰的文档- 更新注释以反映代码变化
## 性能相关重构
### 1. 内存优化- 避免不必要的对象创建- 及时释放不再需要的资源- 注意内存泄漏问题
### 2. 计算优化- 避免重复计算- 使用适当的数据结构和算法- 延迟计算直到必要时
### 3. 并行优化- 识别可并行化的任务- 避免不必要的同步- 注意线程安全问题
复制代码
FAQ
规则最多能支持多少字
最多能支持 20000 字节。
为什么有的时候规则不会被遵循
2.1 规则中的概念模型无法理解
Bad Rule Case ❌
Comments should be in English
分析：用户希望 AI 返回的代码里的注释都是英文的，但是模型不知道这里的“Comments”是什么，所以模型吐出来的代码注释不符合预期。
Good Rule Case ✅
All the code comments you generate should be in English.
注意点：写清楚自己想要什么
2.2 文件路径不是相对于项目根目录的相对路径
Bad Rule Case ❌
Please help me form the code by referring to "templates.md".
分析：templates.md 只是文件名，而不是相对于项目根路径的相对路径，所以 AI 智能体 在回答时会找错文件，返回 404 或者错误的内容
Good Rule Case ✅
Please help me form the code by referring to "src/.TRAE/rules/templates.md".
注意点：写清楚文件路径
2.3 规则内容被覆盖
规则优先级：用户输入 > 自定义智能体的提示词 > user_rules.md > project_rules.md
如果这些规则相互矛盾或覆盖，模型可能会产生困惑。
2.4 规则无法理解侧边对话的功能概念
Bad Rule Case ❌
Help me generate the code format that can be applied to Code Apply.
分析：用户希望 MCP 输出的格式可以直接变成 Code Apply 的格式，但是模型无法理解什么是“Code Apply”
Good Rule Case ✅
Please help me generate a code result similar to this one.
// ... existing code ...
{{ code1 }}
// ... existing code ...
{{ code2 }}
// ... existing code ...
复制代码
注意点：比如说 Diff、Apply、Reject、Accept、Run Command 按钮等这些 AI Sidechat 里的概念模型都无法理解
2.5 历史对话记录与规则矛盾
建议新开对话解决
2.6 为什么生成的代码没有遵循规则？
当项目中已有大量不符合规范的代码时，模型可能倾向于参考现有代码风格而非规则。这种情况下，建议：
明确告知模型当前任务是重构；
在特定场景下强制要求遵循新规则；
考虑启动专门的重构项目，逐步改善代码质量。
拓展阅读
编写自定义规则本质上是在编写提示词。如果自动优化工具无法满足需求，可以参考以下学习资源：https://www.promptingguide.ai/zh
评论