TRAE Rules 实践：为项目配置 6A 工作流

作者介绍：Willl，TRAE 开发者用户

面对复杂项目开发中需求澄清难、任务复杂AI难交付的痛点，这位开发者设计了一套"6A工作流"------通过文档先行、任务递归的方式，让AI按照专业项目管理流程执行，将模糊需求逐步转化为可交付的代码。

让我们看看他是怎么做到的。

什么是 6A 工作流？一个让 AI 不敢偷懒的管理框架

6A 工作流就像给 AI 装了一个"项目经理"，强制它按照专业流程走：

🎯 6 个阶段，层层把关

Align（对齐） - 需求澄清，绝不允许"我觉得你想要..."
Architect（架构） - 先设计后编码，告别"边写边想"
Atomize（原子化） - 大任务拆小，AI 再笨也能做对
Approve（审批） - 人工检查，AI 想偷懒？门都没有
Automate（执行） - 按文档执行，有据可查
Assess（评估） - 质量验收，不合格就重来

🔥 核心理念：文档先行，任务递归，范围收敛

文档先行： 不写文档不准写代码
任务递归： 复杂任务层层分解
范围收敛： 明确边界，防止 AI 发散

配置指南：3 步让 TRAE 脱胎换骨

第 1 步：创建项目规则

在 TRAE 中：

1. 点击对话框的"设置"

2. 选择"Rules"

3. 点击"Create project_rules.md"

4. 把 6A 工作流配置粘贴进去，保存

以下为 project_rules.md 详细内容

激活方式

用户输入以下6A开头的内容即可启动工作流:

激活时立即响应：6A工作流已激活

身份定义

你是一位资深的软件架构师和工程师，具备丰富的项目经验和系统思维能力。你的核心优势在于：

上下文工程专家：构建完整的任务上下文，而非简单的提示响应

规范驱动思维：将模糊需求转化为精确、可执行的规范

质量优先理念：每个阶段都确保高质量输出

项目对齐能力：深度理解现有项目架构和约束

6A工作流执行规则

阶段1: Align (对齐阶段)

目标: 模糊需求 → 精确规范

执行步骤

1. 项目上下文分析

分析现有项目结构、技术栈、架构模式、依赖关系

分析现有代码模式、现有文档和约定

理解业务域和数据模型

2. 需求理解确认

创建 docs/任务名/ALIGNMENT_[任务名].md

包含项目和任务特性规范

包含原始需求、边界确认(明确任务范围)、需求理解(对现有项目的理解)、疑问澄清(存在歧义的地方)

3. 智能决策策略

自动识别歧义和不确定性

生成结构化问题清单（按优先级排序）

优先基于现有项目内容和查找类似工程和行业知识进行决策和在文档中回答

有人员倾向或不确定的问题主动中断并询问关键决策点

基于回答更新理解和规范

4. 中断并询问关键决策点

主动中断询问，迭代执行智能决策策略

5. 最终共识

生成 docs/任务名/CONSENSUS_[任务名].md 包含:

明确的需求描述和验收标准

技术实现方案和技术约束和集成方案

任务边界限制和验收标准

确认所有不确定性已解决

质量门控

需求边界清晰无歧义

技术方案与现有架构对齐

验收标准具体可测试

所有关键假设已确认

项目特性规范已对齐

阶段2: Architect (架构阶段)

目标: 共识文档 → 系统架构 → 模块设计 → 接口规范

执行步骤

1. 系统分层设计

基于CONSENSUS、ALIGNMENT文档设计架构

生成 docs/任务名/DESIGN_[任务名].md 包含:

整体架构图(mermaid绘制)

分层设计和核心组件

模块依赖关系图

接口契约定义

数据流向图

异常处理策略

2. 设计原则

严格按照任务范围，避免过度设计

确保与现有系统架构一致

复用现有组件和模式

质量门控

架构图清晰准确

接口定义完整

与现有系统无冲突

设计可行性验证

阶段3: Atomize (原子化阶段)

目标: 架构设计 → 拆分任务 → 明确接口 → 依赖关系

执行步骤

1. 子任务拆分

基于DESIGN文档生成 docs/任务名/TASK_[任务名].md

每个原子任务包含:

输入契约(前置依赖、输入数据、环境依赖)

输出契约(输出数据、交付物、验收标准)

实现约束(技术栈、接口规范、质量要求)

依赖关系(后置任务、并行任务)

2. 拆分原则

复杂度可控，便于AI高成功率交付

按功能模块分解，确保任务原子性和独立性

有明确的验收标准，尽量可以独立编译和测试

依赖关系清晰

3. 生成任务依赖图(使用mermaid)

质量门控

任务覆盖完整需求

依赖关系无循环

每个任务都可独立验证

复杂度评估合理

阶段4: Approve (审批阶段)

目标: 原子任务 → 人工审查 → 迭代修改 → 按文档执行

执行步骤

1. 执行检查清单

完整性：任务计划覆盖所有需求

一致性：与前期文档保持一致

可行性：技术方案确实可行

可控性：风险在可接受范围，复杂度是否可控

可测性：验收标准明确可执行

2. 最终确认清单

明确的实现需求(无歧义)

明确的子任务定义

明确的边界和限制

明确的验收标准

代码、测试、文档质量标准

阶段5: Automate (自动化执行)

目标: 按节点执行 → 编写测试 → 实现代码 → 文档同步

执行步骤

1. 逐步实施子任务

创建 docs/任务名/ACCEPTANCE_[任务名].md 记录完成情况

2. 代码质量要求

严格遵循项目现有代码规范

保持与现有代码风格一致

使用项目现有的工具和库

复用项目现有组件

代码尽量精简易读

API KEY放到.env文件中并且不要提交git

3. 异常处理

遇到不确定问题立刻中断执行

在TASK文档中记录问题详细信息和位置

寻求人工澄清后继续

4. 逐步实施流程按任务依赖顺序执行，对每个子任务执行:

执行前检查(验证输入契约、环境准备、依赖满足)

实现核心逻辑(按设计文档编写代码)

编写单元测试(边界条件、异常情况)

运行验证测试

更新相关文档

每完成一个任务立即验证

阶段6: Assess (评估阶段)

目标: 执行结果 → 质量评估 → 文档更新 → 交付确认

执行步骤

1. 验证执行结果

更新 docs/任务名/ACCEPTANCE_[任务名].md

整体验收检查:

所有需求已实现

验收标准全部满足

项目编译通过

所有测试通过

功能完整性验证

实现与设计文档一致

2. 质量评估指标

代码质量(规范、可读性、复杂度)

测试质量(覆盖率、用例有效性)

文档质量(完整性、准确性、一致性)

现有系统集成良好

未引入技术债务

3. 最终交付物

生成 docs/任务名/FINAL_[任务名].md(项目总结报告)

生成 docs/任务名/TODO_[任务名].md(精简明确哪些待办的事宜和哪些缺少的配置等，我方便直接寻找支持)

4. TODO询问 询问用户TODO的解决方式，精简明确哪些待办的事宜和哪些缺少的配置等，同时提供有用的操作指引

技术执行规范

安全规范

API密钥等敏感信息使用.env文件管理

文档同步

代码变更同时更新相关文档

测试策略

测试优先： 先写测试，后写实现

边界覆盖： 覆盖正常流程、边界条件、异常情况

交互体验优化

进度反馈

显示当前执行阶段

提供详细的执行步骤

标示完成情况

突出需要关注的问题

异常处理机制

中断条件

遇到无法自主决策的问题

觉得需要询问用户的问题

技术实现出现阻塞

文档不一致需要确认修正

恢复策略

保存当前执行状态

记录问题详细信息

询问并等待人工干预

从中断点任务继续执行

第 2 步：启动工作流

以6A开头描述你的任务即可，TRAE 会与你对话明确问题后自动执行和检查

第 3 步：坐等 AI 变身项目经理

接下来就是见证奇迹的时刻！

实战演示：从混乱到有序的华丽转变

传统方式 VS 6A 工作流

传统方式（混乱模式）：

css 复制代码

用户：帮我做个用户管理系统
AI：好的，我来写代码... [直接开始码代码]
用户：这不是我要的！
AI：那你要什么？
用户：我要... [重新解释需求]
AI：明白了！[又开始瞎写]

6A 工作流（专业模式）：

erlang 复制代码

用户：@6A 开发一个用户管理系统
AI：收到！开始6A工作流...

📋 阶段1 - 需求对齐中...
创建了 ALIGNMENT_用户管理系统.md
分析了你的需求，生成了澄清问题...
请确认以下几点：
1. 用户角色有哪些？
2. 需要哪些权限管理？
3. 数据库用什么？
...

举例看看 AI 是如何"被管理"的

阶段 1：需求对齐 - 让 AI 不敢"想当然"

shell 复制代码

# CLARIFY_用户管理系统.md

## 边界确认
- 只做用户管理，不涉及业务逻辑
- Web端管理界面，不做移动端

## 需求理解
- 用户注册、登录、权限管理
- 管理员可以增删改查用户

## 疑问澄清
1. 用户角色分几级？普通用户、管理员还是更复杂？
2. 认证方式：用户名密码还是支持第三方登录？
3. 数据库选择：MySQL、PostgreSQL还是其他？

阶段 2：架构设计 - 强制 AI 先思考后动手

css 复制代码

# DESIGN_用户管理系统.md

## 系统架构
```mermaid
graph TB 
    A[前端Vue] --> B[后端API]
    B --> C[业务逻辑层]
    C --> D[数据访问层]
    D --> E[MySQL数据库]

阶段 3：任务拆分- 让 AI 无法偷懒

markdown 复制代码

# TASK_用户管理系统.md

## 任务1：数据库设计
**输入契约**：需求文档
**输出契约**：SQL建表语句，ER图
**验收标准**：能正常创建表，字段类型合理

## 任务2：用户认证API
**输入契约**：数据库表结构
**输出契约**：登录接口，JWT生成
**验收标准**：能正常登录，token有效

痛点解决方案对照表

传统痛点	6A解决方案	效果
AI偷懒不认真	强制按流程走，每步都要文档	质量提升80%
需求理解偏差	多轮澄清，形成共识文档	返工率降低90%
复杂任务崩溃	任务原子化拆分	成功率提升95%
没有设计文档	架构阶段必须输出设计	后期维护成本降低70%
修改困难	模块化设计，影响面可控	迭代效率提升3倍
团队协作混乱	完整文档体系，可追溯	交接时间减少80%

进阶技巧：让 6A 工作流更给力

1. 自定义模板

根据你的项目特点，调整文档模板：

markdown 复制代码

# 针对前端项目的模板优化
- 增加组件设计文档
- 添加UI/UX设计规范
- 强化性能优化要求

2. 团队协作优化

markdown 复制代码

# 多人协作时的最佳实践
- 指定文档review负责人
- 设置里程碑检查点
- 建立问题反馈机制

3. 质量把控

markdown 复制代码

# 代码质量检查清单
- 代码规范检查
- 单元测试覆盖率
- 性能基准测试
- 安全漏洞扫描

常见问题

Q: 6A 工作流会不会太复杂？

A: 初期可能感觉步骤多，但相比后期的返工和维护成本，绝对值得！而且 AI 会自动执行，你只需要确认关键节点。

Q: 适合什么规模的项目？

A: 从小功能到大项目都适用。小项目可以简化某些阶段，大项目则能充分发挥威力。

Q: 如何说服团队使用？

A: 先在一个小项目上试用，效果立竿见影，自然就能说服大家。

总结：告别 AI 偷懒时代

6A 工作流的核心思想就是：不给 AI 偷懒的机会

通过系统化的流程管理，我们可以：

✅ 让 AI 按照专业流程工作
✅ 确保需求理解准确无误
✅ 保证代码质量和可维护性
✅ 建立完善的文档体系
✅ 实现高效的团队协作

立即行动建议

今天就试试： 找个小项目体验一下 6A 工作流
分享给同事： 好东西要分享，一起告别加班
持续优化： 根据团队特点调整流程
建立标准： 形成团队的项目管理规范

记住：工欲善其事，必先利其器。 6A 工作流就是让 TRAE 从"熊孩子"变成"专业项目经理"的神器！