第六章 给 Trae 立规矩（Rules 与项目配置）

一、为什么要给 Trae 立规矩

我们看一个真实场景。

老李每周都让 Trae 帮他写一份"周报 HTML"。第一次他的提示词写得很详细：

用思源黑体、配色 #FF6B35 + 白、表格用 striped 风格、中文注释、文件名用 weekly-report-yyyy-mm-dd.html……

第二周，他想 "AI 应该记得吧"，于是只说"帮我写周报"。结果 AI 给了他一个默认 Arial 字体、配色蓝色、英文注释、文件名 report.html 的版本。

他抓狂——因为 AI **不会"记住"**单次对话之外的偏好。

这时候 Rules 就登场了——它是一份"AI 永远会读、永远遵守"的规矩文件，相当于把你的偏好写进了 AI 的 DNA。

二、Rules 的两个层级

Trae 把规则分成两个层级：

优先级：项目规则 > 个人规则 > AI 默认规则。

白话解释：

• 你在个人规则里写"所有代码注释用中文"——以后所有项目 Trae 都给你用中文注释。
• 你在某个项目规则里写"这个项目用英文注释"——这个项目里 Trae 用英文，其他项目还是中文。

三、第一次创建 Rules 文件

3.1 创建个人规则（user_rules.md）

最简单的方法：用 Trae 自己创建。

1. 打开 Trae，按 Cmd+L 呼出对话框。

2. 直接输入：

   @Builder
   
   帮我创建一份个人规则文件 ~/.trae/rules/user_rules.md，内容暂时为空，等我后续添加。
   如果文件夹不存在请帮我创建。
   

3. Trae 会创建文件夹和文件。

手动方法（如果你想自己创建）：

• Mac：打开「访达」→ 按 Cmd+Shift+G，输入 ~/.trae/rules/，回车。如果文件夹不存在，自己新建。然后新建一个文件叫 user_rules.md。
• Windows：打开「资源管理器」，地址栏输入 %USERPROFILE%\.trae\rules\，回车。同样方式新建文件。

3.2 创建项目规则（project_rules.md）

在你打开的项目里：

1. 在项目根目录新建文件夹 .trae/（注意点开头）。
2. 在里面新建文件夹 rules/。
3. 在 rules/ 里新建文件 project_rules.md。

完整路径：你的项目/.trae/rules/project_rules.md

或者直接让 Trae 帮你做：

@Builder

在当前项目根目录创建 .trae/rules/project_rules.md 文件。

3.3 验证 Rules 是否被读到

写一条测试规则进 user_rules.md：

# 我的个人规则

## 测试规则
- 每次回答的开头先说"收到，主人"，再回答正文。

保存。新开一段对话问任何问题。如果 AI 真的回了"收到，主人"，说明规则生效了。

测完记得把这条测试规则删掉——不然你以后每次对话都会被叫"主人"。

四、写规则的 5 个原则

不是规则越多越好。我们见过太多人写了 500 行规则，结果 AI 反而行为变怪。

4.1 用"必须 / 不要"的强语气

❌ 模糊词："可能用中文注释，尽量用驼峰命名" ✅ 明确指令："所有代码注释必须用中文，变量名只能用驼峰命名，禁止使用拼音"

AI 对模糊词不敏感，对强指令敏感。

4.2 一条规则一行（或一段），不要混在一起

❌ "代码风格用 Python 的 black，行长 88，单引号，注释中文，函数名小写下划线，类名 PascalCase" ✅

- 代码风格用 Python 的 black 格式化
- 行长不超过 88
- 字符串使用单引号
- 注释必须用中文
- 函数名用 snake_case
- 类名用 PascalCase

4.3 别写规则文件超过 200 行

字越多 AI 越容易"忘记前面"或"抓不到重点"。保持精炼。如果你的规则真的多，分文件——比如 coding-style.md、writing-style.md、workflow.md，引用时按需 #Doc。

4.4 给"为什么"

❌ "禁止用 var 定义变量" ✅ "禁止用 var 定义变量（用 const 或 let，因为 var 有作用域陷阱）"

AI 理解了"为什么"会更稳定地遵守。

4.5 定期 review

每个月看一遍 user_rules.md：

• 哪些规则你已经不需要了？删。
• 哪些规则 AI 经常违反？改强语气。
• 有没有应该加但没加的？加上。

五、6 个开箱即用的规则模板

直接复制到你的 user_rules.md，按需调整。

模板 1：通用风格规则（推荐所有人都加）

# 通用风格规则

## 语言与表达
- 所有对话默认使用简体中文回复。
- 解释技术概念时，先用一句话说清楚"它是什么 / 它解决什么问题"，再讲细节。
- 避免堆砌专业术语，遇到术语用括号给出白话解释。

## 代码风格
- 代码注释必须用中文。
- 变量名用英文（驼峰），禁止使用拼音。
- 函数 / 模块名要让"非作者"也能一眼看懂用途。
- 优先选择"可读性"而非"性能"，除非我明确要求性能优先。

## 工作流
- 任何超过 3 个文件的改动，先输出方案、等我确认（"Plan→Act"）。
- 任何要执行删除 / 移动 / 跑安装命令的操作，先弹出确认框。
- 出错时先告诉我具体哪一步出错、为什么，不要"自动纠错"。

模板 2：前端项目规则（适合做网页）

# 前端项目规则

## 技术栈
- 默认使用 HTML + TailwindCSS（CDN 引入）+ 原生 JavaScript，避免引入 npm 依赖。
- 复杂场景才用 React / Vue，并明确说明原因。
- 图表使用 Chart.js（CDN）或 ECharts（CDN）。
- 图标优先用 Heroicons / Lucide（内联 SVG）。

## 文件结构
- 单文件项目：所有 CSS 和 JS 内联到 HTML。
- 多文件项目：HTML / CSS / JS 各自独立，文件名小写连字符（kebab-case）。

## 视觉风格
- 默认配色：莫兰迪色系（米白、灰绿、焦糖橙）。
- 字体：英文用 system-ui，中文用思源黑体（系统已装）。
- 圆角统一 0.5rem，阴影统一 sm/md。
- 移动端友好，最小宽度 320px。

模板 3：内容创作 / 文案规则

# 内容创作规则

## 写作风格
- 默认风格：清晰、温柔、有同理心。
- 避免营销腔（"震惊""绝绝子""速看"）。
- 段落不超过 5 行，方便手机阅读。
- 标题不超过 22 字。

## 输出格式
- 默认输出 Markdown。
- 重点句子用 **粗体**，避免大段加粗。
- 列表优先于堆段落。
- 表格用于对比、不用于装饰。

## 内容生成
- 写文案时一次给 5 条候选，不要只给 1 条。
- 标题给 3 类：信息型 / 情绪型 / 反差型。
- 每条候选后用 () 标注它的"使用场景"。

模板 4：数据处理规则（适合常处理 Excel / CSV）

# 数据处理规则

## 数据安全
- 处理任何数据前，自动备份原文件到同目录的 backup/ 文件夹。
- 处理结果输出到新文件，不覆盖原文件。
- 输出文件命名：原文件名_processed_YYYYMMDD.xlsx

## 数据假设
- 如果数据有缺失值，告诉我有多少行缺失，不要自动填补。
- 如果数据格式异常（比如日期格式不一致），列出来让我决定，不要自己猜。
- 如果数据量超过 10000 行，先问我是否要"抽样预览"。

## 输出风格
- 数字保留 2 位小数。
- 百分比明确写"%"。
- 日期统一 YYYY-MM-DD 格式。
- 货币默认人民币，明确写"¥"。

模板 5：学习者规则（适合"边学边做"）

# 学习者规则

## 解释方式
- 我是非程序员，请用"普通人能听懂的话"解释技术。
- 任何代码片段都要附"中文注释"，关键行要"一句话点评"。
- 涉及到术语时，第一次出现给"白话翻译"，后续可以用术语。

## 教学节奏
- 一次只教一个概念，不要堆砌。
- 教完之后给一个"小练习"让我做。
- 我做完之后帮我点评，告诉我哪里好哪里能改进。

## 工作模式
- 我让你做一件事，你**先告诉我"思路"**，我点头你再动手。
- 你给我建议时，列 2-3 个选项让我选，不要直接定一个。

模板 6：成本控制规则（适合用国际版 / Pro）

# 成本控制规则

## Token 节约
- 默认用 DeepSeek-V3，避免直接用 R1（除非我明确要求）。
- 单次对话超过 50k tokens 时主动提醒我，建议开新对话。
- 不要"为了完整"重复贴前面的代码——用"# 文件名"引用即可。

## 任务边界
- 一次任务完成后，"明确告诉我已完成"，等我下一步指令，不要主动开始下一个任务。
- 复杂任务超过 3 个 SubAgent 调用前，先告诉我预计成本。
- 不要在没必要的情况下生成新文件，能改就改。

六、.trae/ 目录的完整结构

除了 rules/，.trae/ 文件夹还有几个常用的子目录和文件：

你的项目/
└── .trae/
    ├── rules/
    │   ├── user_rules.md       # （在 ~/.trae/ 下）个人规则
    │   └── project_rules.md    # 项目规则
    ├── settings.json            # Trae 行为配置（自动接受 / 模型偏好等）
    ├── settings.local.json      # 本地覆盖（不提交 Git）
    ├── mcp.json                 # MCP 服务器配置（第九章）
    ├── skills/                  # 工作流技能（高级）
    │   └── xxx.skill.md
    └── agents/                  # 自定义智能体（第十章）
        └── 我的小红书博主.agent.md

不要被这么多文件吓到——新手 90% 的时间只用 rules/ 这一个。其他都是高级用法，后面章节会讲。

6.1 settings.json —— 行为配置

settings.json 里可以配置 Trae 的"全局行为"，比如：

{
  "ai.model.default": "deepseek-v3",
  "ai.builder.autoAccept": false,
  "ai.context.maxFiles": 20,
  "editor.fontSize": 14,
  "editor.fontFamily": "Source Han Sans, monospace"
}

不熟悉 JSON 格式的话不用手动改，Trae 的「设置」UI 里也能改这些选项。settings.json 只是"高级用户的快捷方式"。

6.2 settings.local.json —— 本地覆盖

settings.local.json 不会提交到 Git（在 .gitignore 里），适合写仅在你本机生效的覆盖——比如你公司电脑禁用了某个端口，你只想在自己电脑上换端口。

七、规则的"陷阱"和应对

7.1 规则不生效的常见原因

7.2 规则被高优先级覆盖

如果你的项目规则说"用英文注释"，但个人规则说"用中文注释"——项目规则赢。

如果你想反过来，删掉项目规则的那一条即可。

7.3 规则不能"过度泛化"

❌ "把代码写得好看一点"（什么叫"好看"？） ✅ "用 Prettier 格式化、行宽 100 字符、字符串用单引号"

八、一个完整的"个人规则"示范文件

下面是一份适合"中国普通用户"的完整 user_rules.md，可以直接复制。

# 我的个人规则（普通人版）

## 一、表达与语言
- 所有对话默认使用简体中文回复。
- 我是非程序员，请用"普通人能听懂的话"解释，避免堆砌术语。
- 任何术语第一次出现，用括号给"白话翻译"。
- 解释技术概念时，先一句话说"它是什么 / 解决什么"，再讲细节。

## 二、代码风格
- 代码注释必须用中文。
- 变量名用英文驼峰命名（camelCase）；禁止使用拼音命名变量。
- 优先选择"可读性"而非"性能"，除非我明确要求性能优先。
- 对每个稍复杂的函数加一个"它做什么 / 输入是什么 / 输出是什么"的中文注释。

## 三、工作流
- 任何**超过 3 个文件**的改动，先输出"方案 + 改动文件清单"，等我确认后再执行。
- 任何**删除文件 / 移动文件 / 跑安装命令**的操作，先弹出确认框。
- 出错时先告诉我"具体哪一步出错、为什么"，不要"自动纠错"。
- 完成一个任务后，明确告诉我"已完成"，等我下一步指令，不要主动开始下一个任务。

## 四、技术栈偏好（前端默认）
- 默认使用 HTML + TailwindCSS（CDN）+ 原生 JavaScript。
- 不主动引入 npm 依赖，除非我明确要求。
- 图表用 Chart.js（CDN），图标用 Lucide / Heroicons 内联 SVG。
- 默认移动端友好，最小宽度 320px。

## 五、视觉默认
- 配色默认：莫兰迪色系（米白 / 灰绿 / 焦糖）。
- 中文字体：思源黑体（系统已装），英文字体：system-ui。
- 圆角统一 0.5rem，阴影统一 sm / md。

## 六、内容生成
- 写文案时一次给 3-5 条候选，不要只给 1 条。
- 每条后用 () 标注"适合什么场景"。
- 避免营销腔（震惊、绝绝子、速看、必看）。

## 七、数据安全
- 处理任何数据文件前，自动备份原文件到同目录的 backup/ 文件夹。
- 处理结果输出到新文件，不覆盖原文件。
- 数据有缺失 / 异常时，告诉我，不要自动猜测填补。

## 八、避免的事
- 不要"假装很懂"——不确定时明确说"我不确定"。
- 不要"为了显得专业"用花哨方案——简单能解决的不要复杂化。
- 不要主动调用"联网搜索"，除非我说"用 #Web"或明确要求。

把这份保存到 ~/.trae/rules/user_rules.md，立刻享受到"AI 自动按你的方式干活"的快感。

九、按"项目类型"准备的规则模板库

把下面这些保存到 ~/.trae/rules/templates/ 里（自己新建一个文件夹），需要的时候复制到对应项目的 project_rules.md。

9.1 template-portfolio.md —— 个人作品集 / 简历网站

# 个人作品集网站规则
- 极简、留白多、不要花哨动画。
- 配色不超过 3 种。
- 单文件 HTML，方便部署到任何静态服务。
- 必须包含：头像 / 一句话介绍 / 联系方式 / 项目集 / Footer。
- 移动端必须显示完整，不允许横向滚动。

9.2 template-blog.md —— 个人博客 / Newsletter

# 博客项目规则
- 文章用 Markdown 写，自动渲染成 HTML。
- 文章列表按时间倒序，每条显示标题 / 摘要 / 标签 / 日期。
- 阅读体验：行宽 60-75 字符，行高 1.7。
- 字号默认 18px，移动端 16px。

9.3 template-tool.md —— 个人小工具

# 个人工具规则
- 单文件 HTML，可以双击直接打开。
- 所有数据处理在浏览器本地完成，不上传服务器。
- 必须有"清除数据 / 重置"按钮。
- 关键操作有"确认 / 取消"二次确认。
- 错误以红色 toast 显示，不弹 alert。

9.4 template-data.md —— 数据处理脚本

# 数据处理项目规则
- 默认 Python 3.10+。
- 用 pandas 处理表格，用 openpyxl 处理 Excel。
- 大文件（>100MB）用分块读取（chunk）。
- 输出包含：处理前行数 / 处理后行数 / 异常行数 / 耗时。
- 出错时打印明确的错误信息和"建议怎么修"。

十、本章一图回顾（文字版）

立规矩三步走
    │
    ├─ 第一步：在 ~/.trae/rules/user_rules.md 写"个人规则"
    │           （所有项目通用）
    │
    ├─ 第二步：在 项目/.trae/rules/project_rules.md 写"项目规则"
    │           （仅当前项目）
    │
    └─ 第三步：每月 review，删过时的、改不灵的、加新需要的

写规则五原则
    │
    ├─ 用"必须 / 不要"的强语气
    ├─ 一条一行 / 一段
    ├─ 控制在 200 行以内
    ├─ 给"为什么"
    └─ 定期 review

优先级
    │
    └─ 项目规则 > 个人规则 > AI 默认规则

新手起步
    │
    └─ 直接复制本章"完整示范文件"到 user_rules.md，按需调整

十一、本章常见的疑问

Q1：我能让 Rules 文件里写中文吗？

可以。规则文件支持纯中文。但强语气词（必须 / 禁止）用中文，技术术语用英文效果最好。

Q2：我把 project_rules.md 提交到 Git 了，会不会泄露我的偏好？

不会泄露任何隐私——它只包含"代码风格""技术栈"这种公开信息。反而推荐你提交，团队成员 clone 项目后能直接享受统一规范。

Q3：user_rules.md 会被同步到云端吗？

不会。它在你本机的 ~/.trae/ 目录下，仅本机有效。换电脑要重新写一份（或自己 GitHub 备份）。

Q4：能针对"特定文件类型"写规则吗？比如"只对 .py 文件应用 Python 风格规则"？

可以。在规则文件里写"对所有 .py 文件应用以下规则：…"AI 会理解。但新手不要太追求精细，用全局规则就够。

Q5：规则会让 AI "变笨"吗？

写得好的规则让 AI 变强（更符合你需求），写得太多 / 太矛盾的规则让 AI 变笨（混乱）。起步就用本章的"完整示范"，再慢慢加自己的，最稳。

Q6：什么时候应该把一条规则从"项目规则"提到"个人规则"？

如果你连续 3 个项目都用了同一条规则，就该提到 user_rules.md。

下一章 第七章 生活场景实战，我们用 Trae 完成 7 个生活场景项目，看看真实做出来的样子。