25 · 团队协作

.trae/
├── rules/
│   ├── 001-project-context.md      # 项目背景与架构
│   ├── 002-code-style.md           # 代码风格约定
│   ├── 003-component-pattern.md    # 组件设计模式
│   ├── 004-testing-standards.md    # 测试标准
│   ├── 005-api-design.md           # API 设计规范
│   └── team-preferences.json       # 团队 AI 偏好
└── reviews/
    └── pull_request_template.md

# 规则名称
 
**scope**: src/components/**
**severity**: required
**tags**: [react, component-pattern]
 
## 规则内容
 
所有组件必须使用 TypeScript 编写，导出命名组件而非默认导出。
 
### ✅ 正确做法
 
```tsx
export const Button = ({ label }: ButtonProps) => { ... }

export default function Button({ label }: ButtonProps) { ... }

### 团队最佳实践

| 做法 | 说明 |
|------|------|
| 按模块拆分规则 | 每个规则文件聚焦一个主题，避免大而全的单一文件 |
| 明确 scope | 用 `scope` 字段限定规则的应用范围，避免误伤 |
| 版本化维护 | 规则随代码一起 Review，一起迭代 |
| 定期清理 | 过时的规则比没有规则更危险 |

**关键洞察**：Shared Rules 最大的价值不是"约束"，而是**消除不确定性**。每个团队成员打开 Trae 时会自动获得相同的 AI 上下文，无需手动同步配置。

---

## 03 · 团队模型偏好：统一 AI 行为规范

### 模型偏好的层级结构

Trae 的模型偏好设置采用**三层继承体系**：

### 可配置的项目

| 配置项 | 说明 | 示例 |
|--------|------|------|
| 默认模型 | 代码生成/审查使用的 LLM | Claude 4 Sonnet / GPT-4o |
| 温度参数 | 创意度 vs 确定性 | 0.2（代码生成推荐） |
| 最大 Token | 单次生成上限 | 8192 |
| 安全策略 | 敏感代码扫描阈值 | high |
| Review 深度 | 审查严格程度 | thorough / balanced / quick |

### 为什么团队级偏好至关重要

想象一个场景：团队中有人用高创意度的模型生成代码，而其他人用保守模型。代码审查时，AI 的建议每次都不一样，团队无法建立对 AI 输出的稳定预期。

**统一模型偏好 = 统一 AI 输出风格 = 更可预测的协作体验。**

> **实战建议**：在团队刚启用 Trae 时，先锁定模型偏好两周。等团队形成对 AI 输出的默契后，再逐步放开个性化设置。

---

## 04 · 代码审查革命：AI 驱动的 PR Review

### 传统 Code Review 的困境

传统 PR Review 中，审查者面临两个矛盾：

1. **时间矛盾**：审查要深入，但时间有限
2. **范围矛盾**：要发现 Bug，也要关注代码风格，但人不可能面面俱到

### Trae AI Review 的工作流

### AI Review vs 人工 Review 对比

| 维度 | AI Review | 纯人工 Review |
|------|-----------|--------------|
| 速度 | 秒级 | 小时级 |
| 一致性 | 每次都一致 | 受状态影响 |
| 风格检查 | 强制执行规则 | 容易遗漏 |
| 深层 Bug | 可覆盖常见模式 | 取决于经验 |
| 上下文理解 | 局限在单个 PR | 了解整个项目 |
| 人情顾虑 | 无 | 有（面子问题） |

**最佳实践：AI 做"广覆盖"，人类做"深判断"。** AI 负责所有可自动化检查的维度，让人类审查者聚焦在架构设计、业务逻辑等需要深度理解的领域。

### 配置 Review 规则

```yaml
# .trae/review-config.yml
review:
  depth: thorough
  check_categories:
    - security
    - performance
    - testing
    - style
  max_comments: 30      # 避免信息过载
  ignore_patterns:
    - "*.generated.*"
    - "*.test.snap"
  auto_approve:
    enabled: false       # 仅建议，不自动批准
    min_confidence: 0.95

驾驶员（Driver）：编写代码的人
导 航 员（Navigator）：观察 + 思考 + 通过 AI 提供建议

工作流：
1. 驾驶员在 Trae 中编写代码
2. 导航员通过 SOLO 连接，实时查看编辑
3. 导航员向 AI 提问："这个函数的边界条件检查了吗？"
4. AI 在双方屏幕上同时给出建议
5. 驾驶员采纳或讨论后修改

开发者 A ──SOLO── 开发者 B
   │                   │
   └──── AI 助手 ──────┘
         ↑
   .trae/rules（团队的共享上下文）

第 1 天：
  └─ 克隆仓库，打开 Trae
  └─ Trae 根据 .trae/rules 自动配置所有工具链
  └─ 询问 AI："这个项目的目录结构是什么？"

第 2 天：
  └─ 阅读规则文件，理解团队约定
  └─ 用 AI 生成第一个"hello world"组件

第 3~5 天：
  └─ 在 AI 引导下完成第一个小功能
  └─ 提交 PR，AI Review 自动检查风格

第 6~7 天：
  └─ 参与正式 Review，代码已基本符合规范
  └─ 开始产生有效贡献

## 你的 Onboarding 计划（由 AI 根据项目生成）
 
1. [x] 环境搭建（Trae 已自动完成）
2. [x] 阅读核心规则（共 6 条，预计 15 分钟）
3. [ ] 完成 "Quick Start" 任务（estimated: 2h）
4. [ ] 在 AI 辅助下实现第一个组件
5. [ ] 提交首个 PR（AI 会预审）
6. [ ] 参与一次 SOLO 结对编程
7. [ ] 编写一条新的 .trae/rules 规则（反向学习）

第一层：编辑器实时提示
    └─ 在编码过程中，Trae 实时检测代码是否符合团队规则
    └─ 不符合的地方用波浪线标注 + 一键修复建议

第二层：提交前检查
    └─ git commit 时自动触发 pre-commit hook
    └─ 自动格式化不符合的代码
    └─ 严重违规阻止提交

第三层：PR 审查
    └─ CI 中全面检查
    └─ 生成风格一致性报告
    └─ 阻止不合规代码合并

2026-07-02 14:23:01 | 张三 | 修改 rules/002-code-style.md
2026-07-02 14:25:44 | 李四 | 提交 PR #1423（AI Review 通过）
2026-07-02 14:30:12 | AI   | 拒绝生成高危代码（安全策略触发）
2026-07-02 14:31:00 | 管理员 | 更新安全策略阈值