一、功能详解

什么是规则（Rules）

规则是你提前写给 AI 的长期行为指引。它可以约束 AI 在 TRAE Work 中的回答方式、代码风格、技术偏好、项目边界和协作方式。

举例：

您是一位专精于使用 Go 标准库的 net/http 包和 Go 1.22 中引入的新 ServeMux 构建 API 的专家 AI 编程助手。

始终使用最新稳定版的 Go（1.22 或更新版本），并熟悉 RESTful API 设计原则、最佳实践和 Go 语言惯用法。

- 严格按照用户的要求一字不差地执行。
- 首先逐步思考 - 详细描述您的 API 结构、端点和数据流计划，用伪代码详细写出。
- 确认计划后，开始编写代码！
- 为 API 编写正确、最新、无错误、功能完整、安全且高效的 Go 代码。
- 使用标准库的 net/http 包进行 API 开发：
  - 利用 Go 1.22 中引入的新 ServeMux 进行路由
  - 正确处理不同的 HTTP 方法（GET、POST、PUT、DELETE 等）
  - 使用适当签名的方法处理程序（例如，func(w http.ResponseWriter, r *http.Request)）
  - 在路由中利用通配符匹配和正则表达式支持等新功能
- 实现适当的错误处理，在有益时包括自定义错误类型。
- 使用适当的状态码并正确格式化 JSON 响应。
- 为 API 端点实现输入验证。
- 在对 API 性能有益时利用 Go 的内置并发功能。
- 遵循 RESTful API 设计原则和最佳实践。
- 包含必要的导入、包声明和任何必需的设置代码。
- 使用标准库的 log 包或简单的自定义日志记录器实现适当的日志记录。
- 考虑为横切关注点（如日志记录、身份验证）实现中间件。
- 在适当时实现速率限制和身份验证/授权，使用标准库功能或简单的自定义实现。
- 在 API 实现中不留任何待办事项、占位符或缺失部分。
- 解释要简洁，但为复杂逻辑或 Go 特定惯用法提供简短注释。
- 如果对最佳实践或实现细节不确定，请直说而不是猜测。
- 提供使用 Go 的 testing 包测试 API 端点的建议。
在 API 设计和实现中始终优先考虑安全性、可扩展性和可维护性。利用 Go 标准库的强大功能和简洁性创建高效且符合惯用法的 API。

作为我的AI助手，请遵循以下沟通原则：

- 回答应简洁明了，直接切入主题，避免不必要的铺垫
- 技术解释应分层次：先给出简短概述，再根据需要深入细节
- 使用列表、表格和代码块增强可读性
- 解释复杂概念时使用类比和实例
- 提供多个解决方案时，明确指出推荐选项及理由
- 当不确定时，坦诚表明并提供可能的方向
- 文档应包含：目的、使用方法、参数说明、返回值和示例
- 避免使用过于专业的术语，除非上下文明确需要，涉及专业术语的时候要同时给出解释

请根据这些原则调整你的回答风格，使沟通更加高效。

你可以把规则理解成一组可复用的“长期工作约束”：不是每次对话都重新说明，而是把稳定、反复出现的要求沉淀下来，让 AI 在后续任务中持续参考。

需要注意的是，规则不是让 AI 永久记住所有聊天内容，也不是替代项目文档。

更适合写入规则或项目规则文件的内容，通常是稳定、明确、可反复使用的偏好与规范。

什么是记忆（Memory）

记忆就是允许 AI 记住你历史对话中的相关上下文，保存对后续协作有价值的偏好与规则，让 AI 在之后的对话里更自然地延续你的常用要求。

和规则相比，记忆更像是从对话中沉淀出的轻量偏好：它可以由系统自动捕捉，也可以由你主动要求 AI 记住。

TRAE Work 支持「全局记忆」和「项目记忆」：

• 全局记忆：在当前用户本地的所有项目中生效，适合语言偏好、称呼、常用输出习惯等个人偏好。
• 项目记忆：只在当前用户本地的当前项目中生效，适合当前项目里反复出现的协作偏好或规则。

需要注意的是，记忆数据存储于本地，无法跨电脑共享；全局记忆和项目记忆各最多 20 条。当你提出新的

稳定要求时，AI 可以覆盖更新相关记忆；不需要的记忆也可以在设置中心的记忆列表里删除。

更适合稳定、明确、后续会复用的偏好，例如称呼、语言偏好、输出习惯、项目协作方式。

规则 、记忆 VS 其他功能

二、使用场景

规则（Rules）

当你发现自己反复对 AI 说同一类要求时，就可以考虑把它写成规则。

• 统一语言和交互方式：例如要求 AI 默认使用中文、回答先给结论、必要时列出风险。
• 统一代码风格：例如命名规范、注释原则、目录结构、测试要求、错误处理方式。
• 统一团队标准：例如代码审查口径、提交信息格式、接口文档格式、上线检查清单。
• 减少低价值沟通：例如每次生成方案都需要包含背景、目标、步骤、风险和验收标准。
• 保障质量边界：例如遇到高风险操作必须先确认，遇到不确定信息要说明假设。

记忆（Memory）

当你没有提前整理规则，但又发现某些偏好会在合作中反复出现时，更适合让它沉淀成记忆。

• 保存个人习惯：例如默认用中文、先给结论、称呼偏好、输出更简洁等长期稳定的个人习惯。
• 减少重复提醒：如果你经常在对话里反复说“以后都这样回答”，这类内容就适合被记住。
• 承接项目内默契：某个项目里常用的表达方式、沟通口径、交付顺序，如果会持续复用，也适合放进项目记忆。
• 适合自然沉淀：有些要求一开始并不清楚，但在多轮协作里逐渐稳定下来，这时记忆比手动写规则更省事。

三、在 TRAE Work 中使用

运行环境说明

• TRAE Work 的规则会根据任务运行位置区分本地和云端。创建规则前，先判断你希望它服务哪类任务。
• 现在规则（Rules）和记忆（Memory）都是，本地和云端各自生效，不重合。

规则 & 记忆的创建路径

你可以在设置中心创建一条或多条规则。建议一条规则只解决一个明确问题，后续维护会更轻松。

1. 在界面左下角点击头像，进入 设置。

1. 在设置中心左侧导航栏中选择 「规则与记忆」。

1. 如果你使用 TRAE Work 桌面版，先选择规则运行环境：本地 或 云端。

1. 点击 对应按键

1. 个性化设置

如何写好规则

• 一条好规则通常包括四个要素：适用场景、明确动作、边界条件和输出标准。

如何创建和管理记忆

• 好的记忆是让 AI 清楚知道：这是不是一个稳定习惯、适用于哪里、以后要怎么延续。

四、规则类型

全局规则

目前，TRAE Work 支持全局规则。你在设置中心配置的规则会跨项目生效。

项目级规则

AGENTS.md

AGENTS.md 通常放在项目根目录，用于向 AI 智能体提供当前项目的行为指引。它适合写项目专属规范，例如目录说明、开发命令、测试要求、分支策略和注意事项。

AGENTS.md 更像“项目说明书”，只服务当前项目。相比全局规则，它更适合写那些不应该影响其他项目的要求。

CLAUDE.md 和 CLAUDE.local.md

TRAE Work 兼容 CLAUDE.md 和 CLAUDE.local.md。如果你已经在 Claude Code 项目中维护过这些文件，把项目导入 TRAE Work 后可以继续复用。

• CLAUDE.md：适合放团队共享的项目说明、代码规范和常用命令。
• CLAUDE.local.md：适合放更偏个人本地环境的说明，例如个人调试脚本、临时路径或本机注意事项。

如何让项目规则文件生效

1. 打开 设置，进入 规则。
2. 找到 导入设置。
3. 打开 将 AGENTS.md 包含在上下文中。
4. 如果项目中使用 CLAUDE.md，也打开 将 CLAUDE.md 包含在上下文中。
5. 回到项目中开启新对话，让 AI 在新的上下文中读取这些说明。

AGENTS.md 可以写什么

# 项目协作规则

技术栈
- 前端使用 React + TypeScript。
- 样式优先使用项目已有组件和工具类。

开发要求
- 修改前先阅读相关组件和已有样式。
- 新增逻辑必须补充必要的边界处理。
- 完成后运行 npm run lint 和相关测试。

输出要求
- 汇报时说明改动文件、验证结果和未覆盖风险。
- 不要主动改动与当前任务无关的文件。

项目文件不需要一开始写得很复杂。先写最稳定、最常被重复提醒的内容，再根据真实任务逐步补充。

五、记忆类型

全局记忆

• 适合保存：默认语言、称呼方式、回答结构、常用输出口径。
• 适合人群：经常跨项目协作，但个人表达习惯比较稳定的用户。
• 使用提醒：全局记忆是“通用习惯”，不要塞进只适用于某一个项目的细节。

项目记忆

• 适合保存：当前项目的沟通方式、交付顺序、文档组织习惯、常见说明口径。
• 适合人群：在某个项目里需要长期配合，但这些习惯不应该带到其他项目中的用户。
• 使用提醒：如果内容已经上升到团队统一规范，仍然更适合写入项目规则文件，而不是只依赖项目记忆。

六、规则与记忆的核心使用技巧

规则的拆分与迭代

• 一条规则只解决一个问题。不要把语言偏好、代码规范、测试要求和发布流程全部写进同一条规则。
• 避免规则之间互相冲突。例如一条规则要求“输出尽量简短”，另一条又要求“每次都写完整背景和细节”，AI 会更难判断。
• 路径尽量写相对路径。如果规则中需要提到项目文件，使用相对于项目根目录的路径，方便 AI 定位。
• 新建或修改规则后，建议开启新对话。这样可以减少旧上下文与新规则之间的干扰。
• 旧项目要明确任务性质。如果项目里已有大量不符合新规范的代码，AI 可能会沿用现状。此时可以明确说明“本次任务是重构，请严格遵循新规则”。
• 把稳定内容写进规则，把临时背景留在当前对话。需求背景、一次性资料、临时决策不适合长期写入规则。
• 规则不是越多越好。优先沉淀高频、稳定、低歧义的要求，定期清理过期规则。

拆分

当规则数量开始增加时，可以先分层，再按单一职责拆分。一个简单判断是：这条规则能不能用一句话说清楚它在约束什么行为？如果不能，就继续拆。

三个常用拆分维度：

• 按职责拆：把 React 组件规范、状态管理规范、错误处理规范、日志规范拆开。
• 按范围拆：能写清属于哪个目录或文件类型的规则，就适合独立出来，例如 apps/web/**、**/*.sql。
• 按风险拆：误触发代价很大的内容单独拆出，例如发布、回滚、删除数据、权限变更。

迭代

规则不是一次写完就不再变化的配置，而应该像工程资产一样边用边迭代。尤其是团队协作时，要定期判断哪些规则仍然有价值，哪些已经变成噪音。

记忆的使用小技巧

• 把稳定偏好交给记忆。例如语言、称呼、回答顺序这类长期习惯，最适合让 AI 自动延续。
• 把临时任务留在当前对话。今天才有效的安排、一次性的要求，不要急着让 AI 记住。
• 记忆要短、要清楚。越像一句明确习惯，越容易被正确使用；越模糊，越容易在不该出现的时候冒出来。
• 发现偏了就及时改。如果 AI 记住了过时习惯，不要一直忍着用，尽快更新或删除，后面体验会轻松很多。
• 项目记忆不要冒充项目规范。如果已经是团队共识、会影响多人协作，最好还是写进 AGENTS.md、CLAUDE.md 或项目文档。
• 对“本地生效”要有预期。记忆保存在本地设备上，换电脑或换环境后，不一定能直接延续。

七 、猜你想问

Q1：规则和普通提示词最大的区别是什么？

A：普通提示词通常只影响当前任务；规则用于长期约束 AI 的行为。如果你发现同一段要求经常重复输入，就适合沉淀成规则。

Q2：规则会不会影响所有项目？

A：设置中心里的规则目前是全局规则，会跨项目生效。项目专属要求建议写到 AGENTS.md、CLAUDE.md 或项目文档中，避免影响其他项目。

Q3：我写了规则，为什么 AI 还是没有完全遵守？

A：常见原因包括规则太模糊、规则之间冲突、当前对话里有旧上下文、项目现有代码风格和新规则不一致。可以把规则改得更具体，开启新对话，并在任务中强调必须遵循的新约束。

Q4：什么内容不适合写成规则？

A：一次性需求、临时资料、过期流程、大段业务背景、只适用于单个项目的细节，都不适合写成全局规则。它们更适合放在当前对话、上下文资料或项目级规则文件里。

Q5：AGENTS.md、CLAUDE.md 和规则可以同时用吗？

A：可以。比较推荐的分工是：全局规则写个人或团队的通用偏好；AGENTS.md 和 CLAUDE.md 写当前项目的专属规范；当前对话里补充本次任务的目标和临时背景。

Q6：规则和 Skill 应该怎么取舍？

A：如果只是长期偏好或底线要求，用规则；如果是一套固定工作流，例如“按步骤做代码审查”“生成固定格式周报”，更适合做成 Skill。

Q7：规则应该拆多细？

A：拆到“单一职责”即可。你可以用一句话判断：这条规则到底在约束什么行为？如果一句话说不清，或者同时包含规范、偏好、流程三类内容，就应该继续拆。

Q8：User Rule 和 Project Rule 应该怎么分工？

A：User Rule 更适合个人表达偏好和默认行为习惯，例如默认语言、回答粒度、是否总要给验证步骤；Project Rule 更适合团队和项目一致性，例如目录结构、技术栈约定、测试要求、发布流程。个人偏好不要覆盖团队约定，项目规则也不要塞进太多个人习惯。

Q9：记忆和规则到底该怎么选？

A：如果你已经想清楚一条长期要求，并希望 AI 明确、稳定地执行，用规则；如果只是想让 AI 在长期合作里自然记住你的习惯，例如语言、称呼、回答顺序，用记忆会更轻便。

Q10：为什么有些话没有被保存成记忆？

A：因为记忆更适合保存稳定、明确、后续还会复用的偏好。一次性指令、模糊表达、临时安排，通常不会被自动保存。你也可以直接告诉 AI“请记住这条偏好”，提高保存的确定性。

Q11：记忆会不会跟着我换电脑同步？

A：不会。记忆数据保存在本地，主要服务当前设备上的使用体验。所以换电脑、换环境后，之前沉淀的记忆不一定会自动带过去。

Q12：记忆满了怎么办？

A：全局记忆和项目记忆各有数量上限。达到上限后，如果还要新增，系统会优先清理价值较低、近期不常用的记忆。所以更建议定期删掉已经过期的习惯，给真正常用的内容留位置。

Q13：项目记忆和项目规则文件会冲突吗？

A：一般不会，但它们的定位不同。项目记忆更像协作默契，适合轻量偏好；项目规则文件更像正式说明书，适合稳定规范。如果两者都存在，最好让规则文件承载“硬要求”，让记忆承载“常用习惯”。

八、练手小作业

练习一（规则篇）

不是写一条完美规则，而是快速感受“写入规则后，AI 的回答会发生什么变化”。

1. 进入 TRAE Work 设置 > 规则与记忆，点击 创建。
2. 复制下面这条规则，粘贴进去并保存。
3. 开启一个新对话，问 AI：“帮我解释一下 Rules 是什么。”观察它是否先给结论。

回答问题时，请先用一句话给出结论，再补充 2-3 条要点说明。
如果问题不明确，请先提出一个最关键的澄清问题。

完成后，你应该可以看到：

• AI 不再一上来展开长篇解释，而是先给出一句结论。
• 回答结构更稳定，通常会有简短要点。
• 如果你的问题太模糊，AI 会先问一个澄清问题。

练习二（记忆篇）

感受“不是手动写规则，而是让 AI 在协作里把你的习惯记下来”是什么体验。

1. 确认 TRAE Work 设置 > 规则与记忆 中的 记忆 开关已经打开。
2. 开启一个新对话，对 AI 直接说：“请记住：以后默认用中文回答我，并先给结论再展开。”
3. 如果对话中出现了记忆提示，点击查看对应内容，确认这条偏好已经被记录。
4. 再开启一个新对话，问 AI：“帮我解释一下 Memory 和 Rule 的区别。”观察它是否会默认用中文，并先给出结论。

完成后，你应该可以看到：

• AI 更像是在延续你的个人习惯，而不是只执行这一次命令。
• 后续对话里，不用每次都重复提醒“先给结论”“默认用中文”。
• 如果你后来改口，例如希望回答更简短，也可以继续让 AI 更新这条记忆。

附｜一些规则示例

基础交互规则

所有回答默认使用中文。
回答问题时先给结论，再补充必要解释。
如果任务存在明显风险，请先指出风险，再继续给出方案。

通用编码规则

生成代码时优先遵循当前项目已有风格。
优先使用清晰命名和提前返回，避免无意义的多层嵌套。
修改完成后说明改动文件、验证方式和可能影响范围。

代码审查规则

当用户要求 review 时，优先指出 bug、回归风险和缺失测试。
按照严重程度排序，引用具体文件和行号。
如果没有发现问题，明确说明未发现阻塞问题，并补充剩余风险。

重构规则

处理重构任务时，每次只做一个清晰的行为保持型改动。
修改前先确认现有测试或补充最小验证方式。
每轮改动后运行相关测试，并说明行为是否保持一致。