Appearance
Trae 的项目规则示例
本文档展示了两个实际项目中的 Trae 规则示例，供参考和学习。
示例 1：Vitepress 文档项目规则 (common-rule.md)
这是一个 Vitepress 文档项目的规则示例，适用于文档编写类项目。
规则内容
markdown
1. 项目使用的框架版本及依赖
- "vitepress": "1.6.4"
- "vue": "3.5.13"
- "typescript": "5.7.2"
2. 编写的文档必须按照 Vitepress 的规范进行编写
3. 编写的文档请自动加入到 themeConfig 里面的 sidebar 配置中
4. 编写教程文档时，尽量举例说明
5. 当我在执行复杂任务前，请先输出一个简单的 [Plan]（步骤计划），等我确认后再进行下一步规则解析
| 规则项 | 说明 | 应用场景 |
|---|---|---|
| 框架版本 | 明确指定 Vitepress、Vue 和 TypeScript 版本 | 确保文档编写符合特定版本规范 |
| Vitepress 规范 | 要求按照 Vitepress 规范编写文档 | 保持文档格式一致性 |
| Sidebar 自动更新 | 新文档自动添加到 sidebar 配置 | 维护导航结构完整性 |
| 举例说明 | 教程文档需要提供具体示例 | 提高文档可读性和实用性 |
| Plan 步骤计划 | 复杂任务前先输出步骤计划 | 确保任务执行符合预期 |
使用建议
- 适用于文档站点、博客、知识库等项目
- 可根据实际技术栈调整版本号
- 建议结合
.traerules文件使用
示例 2：6A 工作流项目规则 (project-6a-rules.md)
这是一个完整的软件开发项目规则示例，采用 6A 工作流方法论。
规则概述
yaml
alwaysApply: false
description: 6A 工作流执行规则 - 从需求对齐到交付评估的完整开发流程6A 工作流阶段
阶段 1: Align (对齐阶段)
目标: 模糊需求 → 精确规范
执行步骤：
项目上下文分析
- 分析现有项目结构、技术栈、架构模式、依赖关系
- 分析现有代码模式、现有文档和约定
- 理解业务域和数据模型
需求理解确认
- 创建
docs/任务名/ALIGNMENT_[任务名].md - 包含项目和任务特性规范
- 包含原始需求、边界确认、需求理解、疑问澄清
- 创建
智能决策策略
- 自动识别歧义和不确定性
- 生成结构化问题清单（按优先级排序）
- 优先基于现有项目内容和查找类似工程和行业知识进行决策
- 有人员倾向或不确定的问题主动中断并询问关键决策点
中断并询问关键决策点
- 主动中断询问，迭代执行智能决策策略
最终共识
- 生成
docs/任务名/CONSENSUS_[任务名].md - 包含明确的需求描述和验收标准
- 包含技术实现方案和技术约束和集成方案
- 包含任务边界限制和验收标准
- 生成
质量门控：
- 需求边界清晰无歧义
- 技术方案与现有架构对齐
- 验收标准具体可测试
- 所有关键假设已确认
- 项目特性规范已对齐
阶段 2: Architect (架构阶段)
目标: 共识文档 → 系统架构 → 模块设计 → 接口规范
执行步骤：
- 系统分层设计
- 基于 CONSENSUS、ALIGNMENT 文档设计架构
- 生成
docs/任务名/DESIGN_[任务名].md
文档内容：
- 整体架构图（mermaid 绘制）
- 分层设计和核心组件
- 模块依赖关系图
- 接口契约定义
- 数据流向图
- 异常处理策略
设计原则：
- 严格按照任务范围，避免过度设计
- 确保与现有系统架构一致
- 复用现有组件和模式
质量门控：
- 架构图清晰准确
- 接口定义完整
- 与现有系统无冲突
- 设计可行性验证
阶段 3: Atomize (原子化阶段)
目标: 架构设计 → 拆分任务 → 明确接口 → 依赖关系
执行步骤：
- 子任务拆分
- 基于 DESIGN 文档生成
docs/任务名/TASK_[任务名].md
- 基于 DESIGN 文档生成
每个原子任务包含：
- 输入契约（前置依赖、输入数据、环境依赖）
- 输出契约（输出数据、交付物、验收标准）
- 实现约束（技术栈、接口规范、质量要求）
- 依赖关系（后置任务、并行任务）
拆分原则：
- 复杂度可控，便于 AI 高成功率交付
- 按功能模块分解，确保任务原子性和独立性
- 有明确的验收标准，尽量可以独立编译和测试
- 依赖关系清晰
质量门控：
- 任务覆盖完整需求
- 依赖关系无循环
- 每个任务都可独立验证
- 复杂度评估合理
阶段 4: Approve (审批阶段)
目标: 原子任务 → 人工审查 → 迭代修改 → 按文档执行
执行步骤：
执行检查清单
- 完整性：任务计划覆盖所有需求
- 一致性：与前期文档保持一致
- 可行性：技术方案确实可行
- 可控性：风险在可接受范围，复杂度是否可控
- 可测性：验收标准明确可执行
最终确认清单
- 明确的实现需求（无歧义）
- 明确的子任务定义
- 明确的边界和限制
- 明确的验收标准
- 代码、测试、文档质量标准
阶段 5: Automate (自动化执行)
目标: 按节点执行 → 编写测试 → 实现代码 → 文档同步
执行步骤：
逐步实施子任务
- 创建
docs/任务名/ACCEPTANCE_[任务名].md记录完成情况
- 创建
代码质量要求
- 严格遵循项目现有代码规范
- 保持与现有代码风格一致
- 使用项目现有的工具和库
- 复用项目现有组件
- 代码尽量精简易读
- API KEY 放到 .env 文件中并且不要提交 git
异常处理
- 遇到不确定问题立刻中断执行
- 在 TASK 文档中记录问题详细信息和位置
- 寻求人工澄清后继续
逐步实施流程
- 按任务依赖顺序执行
- 对每个子任务执行：
- 执行前检查（验证输入契约、环境准备、依赖满足）
- 实现核心逻辑（按设计文档编写代码）
- 编写单元测试（边界条件、异常情况）
- 运行验证测试
- 更新相关文档
- 每完成一个任务立即验证
阶段 6: Assess (评估阶段)
目标: 执行结果 → 质量评估 → 文档更新 → 交付确认
执行步骤：
- 验证执行结果
- 更新
docs/任务名/ACCEPTANCE_[任务名].md
- 更新
整体验收检查：
- 所有需求已实现
- 验收标准全部满足
- 项目编译通过
- 所有测试通过
- 功能完整性验证
- 实现与设计文档一致
- 质量评估指标
- 代码质量（规范、可读性、复杂度）
- 测试质量（覆盖率、用例有效性）
- 文档质量（完整性、准确性、一致性）
- 现有系统集成良好
- 未引入技术债务
- 最终交付物
- 生成
docs/任务名/FINAL_[任务名].md（项目总结报告） - 生成
docs/任务名/TODO_[任务名].md（精简明确哪些待办的事宜和哪些缺少的配置等）
- TODO 询问
- 询问用户 TODO 的解决方式
- 精简明确哪些待办的事宜和哪些缺少的配置等
- 同时提供有用的操作指引
技术执行规范
安全规范
- API 密钥等敏感信息使用 .env 文件管理
文档同步
- 代码变更同时更新相关文档
测试策略
- 测试优先： 先写测试，后写实现
- 边界覆盖： 覆盖正常流程、边界条件、异常情况
交互体验优化
进度反馈
- 显示当前执行阶段
- 提供详细的执行步骤
- 标示完成情况
- 突出需要关注的问题
异常处理机制
中断条件：
- 遇到无法自主决策的问题
- 觉得需要询问用户的问题
- 技术实现出现阻塞
- 文档不一致需要确认修正
恢复策略：
- 保存当前执行状态
- 记录问题详细信息
- 询问并等待人工干预
- 从中断点任务继续执行
规则对比
| 特性 | Vitepress 规则 | 6A 工作流规则 |
|---|---|---|
| 适用场景 | 文档编写、内容管理 | 软件开发、系统工程 |
| 复杂度 | 简单、直接 | 复杂、结构化 |
| 执行方式 | 即时响应 | 分阶段执行 |
| 文档要求 | 基础规范 | 完整文档体系 |
| 质量控制 | 基础检查 | 多阶段门控 |
| 适用团队 | 个人、小团队 | 中大型团队 |
如何选择合适的规则
选择 Vitepress 规则当：
- 项目以文档编写为主
- 需要快速迭代内容
- 团队规模较小
- 技术栈相对固定
选择 6A 工作流规则当：
- 项目涉及复杂软件开发
- 需要严格的流程控制
- 团队规模较大
- 对质量要求较高
混合使用
也可以将两种规则结合使用：
- 使用 6A 工作流管理整体开发流程
- 在文档编写阶段使用 Vitepress 规则的具体要求
最佳实践
- 从简单开始：先使用基础规则，逐步完善
- 团队共识：确保团队成员理解并同意规则
- 定期回顾：根据项目进展调整规则
- 文档化：将规则纳入项目文档
- 工具化：利用 Trae 的
.traerules文件自动化规则应用
总结
这两个规则示例展示了 Trae 项目规则的灵活性：
- Vitepress 规则 展示了针对特定类型项目的简洁规则
- 6A 工作流规则 展示了完整的软件开发流程规范
根据您的项目特点和团队需求，可以选择或定制适合的规则，以提升开发效率和代码质量。