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

面对复杂项目开发中需求澄清难、任务复杂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 工作流

传统方式（混乱模式）：

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

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

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

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

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

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

# CLARIFY_用户管理系统.md

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

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

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

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

# DESIGN_用户管理系统.md

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

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

# TASK_用户管理系统.md

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

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

四、痛点解决方案对照表

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

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

1. 自定义模板

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

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

2. 团队协作优化

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

3. 质量把控

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

六、常见问题

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

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

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

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

Q: 如何说服团队使用？

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

七、总结：告别 AI 偷懒时代

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

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

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

立即行动建议

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

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

# 身份定义
你是一位资深的软件架构师和工程师，具备丰富的项目经验和系统思维能力。你的核心优势在于：
 
- 上下文工程专家：构建完整的任务上下文，而非简单的提示响应
- 规范驱动思维：将模糊需求转化为精确、可执行的规范
- 质量优先理念：每个阶段都确保高质量输出
- 项目对齐能力：深度理解现有项目架构和约束
 
# 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文件管理
 
### 文档同步
 
代码变更同时更新相关文档
 
### 测试策略
**- 测试优先：**先写测试，后写实现
**- 边界覆盖：**覆盖正常流程、边界条件、异常情况
 
## 交互体验优化
 
## 进度反馈
- 显示当前执行阶段
- 提供详细的执行步骤
- 标示完成情况
- 突出需要关注的问题
 
## 异常处理机制
 
### 中断条件
- 遇到无法自主决策的问题
- 觉得需要询问用户的问题
- 技术实现出现阻塞
- 文档不一致需要确认修正
 
### 恢复策略
- 保存当前执行状态
- 记录问题详细信息
- 询问并等待人工干预
- 从中断点任务继续执行

一、前言

TRAE + Figma 将 AI 能力深度集成到产品设计的每个环节：从自然语言需求描述到可验证的交互原型。通过 TRAE 的语义理解与约束生成能力，我们将业务目标、用户场景与交互规则进行结构化处理，自动映射为 Figma 的页面架构、组件库与设计令牌，确保设计的一致性与可复用性。

本文档旨在提供一套轻量且可落地的闭环解决方案：

需求捕获与澄清
规格化产物生成（PRD 片段、用户流程、状态矩阵）
原型自动化生成与同步
评审迭代与版本追踪

无论你是产品经理、设计师还是前端开发者，都能以更低的沟通成本快速达成共识，将模糊的想法迅速转化为可测试、可交付的原型。

二、成果展示

动图

三、环境配置

第一步：安装基础环境

# 1. 克隆项目 git clone https://github.com/grab/cursor-talk-to-figma-mcp.git # 2. 进入项目目录 cd cursor-talk-to-figma-mcp/ # 3. 安装 Bun（如已安装请跳过） curl -fsSL https://bun.sh/install | bash # 4. 项目初始化 bun setup # 5. 启动服务 bun socket

运行成功如下：

第二步：配置 TRAE

1. 打开 TRAE 应用

2. 选择 Solo 模式3. 点击 Figma 选项

4.启动 MCP 插件

5.确认配置成功

第三步：配置 MCP 工具

选择手动添加，按照以下配置进行设置：

第四步：添加上下文

1. 为项目配置 6A 工作流

6A工作流介绍：https://zhuanlan.zhihu.com/p/1938254002941846667

以下为「6A 工作流规范」完整内容

激活方式

用户输入以下 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. 添加 Figma 设计规范指南

以下为「Figma设计规范指南」完整内容

概述

本文档专门为Figma设计软件制定，基于UI界面设置指南和规范，提供在Figma中实施设计系统的具体方法和最佳实践。

1. Figma文件组织结构

1.1 文件命名规范

项目名称_模块名称_版本号_日期例如：电商平台_用户中心_v2.1_20240101

1.2 页面组织结构

🎨 Design System - 设计系统页面
📱 Components - 组件库页面
🖼️ Templates - 模板页面
📄 Pages - 具体页面设计
🔍 Prototypes - 原型交互
📋 Documentation - 设计文档

1.3 图层命名规范

组件类型/状态_描述例如： - Button/Primary_登录按钮 - Input/Default_用户名输入框 - Card/Hover_产品卡片 - Icon/24px_搜索图标

2. Figma设计系统搭建

2.1 颜色样式 (Color Styles)

创建颜色样式步骤：

选择颜色 → 右侧面板 → 颜色选择器
点击样式图标 → 创建样式
按照以下命名规范：

主色调： Primary/100 - #E6F7FF Primary/200 - #BAE7FF Primary/300 - #91D5FF Primary/400 - #69C0FF Primary/500 - #40A9FF Primary/600 - #1890FF (主色) Primary/700 - #096DD9 Primary/800 - #0050B3 Primary/900 - #003A8C 中性色： Neutral/White - #FFFFFF Neutral/50 - #FAFAFA Neutral/100 - #F5F5F5 Neutral/200 - #F0F0F0 Neutral/300 - #D9D9D9 Neutral/400 - #BFBFBF Neutral/500 - #8C8C8C Neutral/600 - #595959 Neutral/700 - #434343 Neutral/800 - #262626 Neutral/900 - #1F1F1F Neutral/Black - #000000 功能色： Success/Default - #52C41A Warning/Default - #FA541C Error/Default - #F5222D Info/Default - #1890FF

2.2 文字样式 (Text Styles)

创建文字样式步骤：

选择文本 → 右侧面板 → 文字属性
设置字体、大小、行高、字重
点击样式图标 → 创建样式

标题样式： Heading/H1 - 36px/43px, Bold Heading/H2 - 28px/34px, Bold Heading/H3 - 24px/29px, Semibold Heading/H4 - 20px/24px, Semibold Heading/H5 - 18px/22px, Medium Heading/H6 - 16px/19px, Medium 正文样式： Body/Large - 18px/27px, Regular Body/Default - 16px/24px, Regular Body/Small - 14px/21px, Regular Body/Caption - 12px/18px, Regular 特殊样式： Button/Large - 16px/24px, Medium Button/Default - 14px/21px, Medium Button/Small - 12px/18px, Medium

2.3 效果样式 (Effect Styles)

阴影效果： Shadow/Level1 - Drop Shadow: 0px 1px 3px rgba(0,0,0,0.1) Shadow/Level2 - Drop Shadow: 0px 2px 8px rgba(0,0,0,0.1) Shadow/Level3 - Drop Shadow: 0px 4px 16px rgba(0,0,0,0.15) Shadow/Level4 - Drop Shadow: 0px 8px 32px rgba(0,0,0,0.2) 模糊效果： Blur/Light - Background Blur: 4px Blur/Medium - Background Blur: 8px Blur/Heavy - Background Blur: 16px

3. 组件库构建

3.1 基础组件 (Base Components)

按钮组件 (Button) 变体属性设置：

Type: Primary, Secondary, Text, Danger
Size: Large(48px), Default(40px), Small(32px)
State: Default, Hover, Active, Disabled

组件结构： Button (Main Component) ├── Background (Rectangle) ├── Content (Auto Layout) │ ├── Icon (Optional) │ └── Label (Text) └── States (Variants) Auto Layout设置：

Direction: Horizontal
Spacing: 8px
Padding: 水平16px, 垂直8px
Alignment: Center

输入框组件 (Input) 变体属性设置：

Size: Large(48px), Default(40px), Small(32px)
State: Default, Focus, Error, Disabled
Type: Text, Password, Search

组件结构： Input (Main Component) ├── Container (Rectangle) ├── Content (Auto Layout) │ ├── Prefix Icon (Optional) │ ├── Placeholder/Value (Text) │ └── Suffix Icon (Optional) └── Helper Text (Text) 卡片组件 (Card) 变体属性设置：

Elevation: Level1, Level2, Level3
State: Default, Hover
Border: True, False

组件结构： Card (Main Component) ├── Background (Rectangle) ├── Content (Auto Layout) │ ├── Header (Optional) │ ├── Body (Auto Layout) │ └── Footer (Optional) └── Shadow (Effect Style)

3.2 复合组件 (Composite Components)

导航栏组件 (Navigation) 组件结构： Navigation (Main Component) ├── Container (Auto Layout) ├── Logo Area (Auto Layout) ├── Menu Items (Auto Layout) │ └── Menu Item (Component Instance) └── Actions (Auto Layout) └── Button (Component Instance) 表单组件 (Form) 组件结构： Form (Main Component) ├── Form Container (Auto Layout) ├── Form Group (Auto Layout) │ ├── Label (Text Style) │ ├── Input (Component Instance) │ └── Helper Text (Text Style) └── Actions (Auto Layout) └── Button (Component Instance)

4. 网格系统设置

4.1 布局网格 (Layout Grid)

桌面端网格 (Desktop ≥1200px) 类型：Columns 列数：24 间距：24px 边距：48px 颜色：rgba(255, 0, 0, 0.1) 平板端网格 (Tablet 768px-1199px) 类型：Columns 列数：12 间距：16px 边距：32px 颜色：rgba(0, 255, 0, 0.1)

移动端网格 (Mobile <768px)

类型：Columns 列数：4 间距：16px 边距：16px 颜色：rgba(0, 0, 255, 0.1)

4.2 基线网格 (Baseline Grid)

间距：8px 颜色：rgba(0, 0, 0, 0.05)

5. Auto Layout最佳实践

5.1 Auto Layout设置原则

方向选择： 根据内容排列选择Horizontal或Vertical
间距设置： 使用8的倍数（8px, 16px, 24px, 32px）
对齐方式： 合理选择主轴和交叉轴对齐
尺寸调整： 使用Hug contents或Fill container

5.2 常用Auto Layout模式

水平排列 (Horizontal) 用途：按钮组、导航菜单、标签页设置： - Direction: Horizontal - Spacing: 16px - Alignment: Center - Padding: 16px 垂直排列 (Vertical) 用途：表单、卡片内容、列表设置： - Direction: Vertical - Spacing: 24px - Alignment: Top - Padding: 24px 嵌套布局 (Nested) 用途：复杂组件、页面布局设置： - 外层：Vertical (页面结构) - 内层：Horizontal (内容排列) - 合理使用Fill和Hug

6. 约束和响应式设计

6.1 约束设置 (Constraints)

固定元素

导航栏：Left & Right + Top 侧边栏：Left + Top & Bottom 底部栏：Left & Right + Bottom 自适应元素 主内容区：Left & Right + Top & Bottom 卡片：Left & Right + Top 按钮：Center + Top

6.2 响应式组件设计

断点设置

移动端：375px (iPhone) 平板端：768px (iPad) 桌面端：1200px (Desktop) 大屏幕：1600px (Large Desktop) 组件适配策略 按钮：保持固定高度，宽度自适应输入框：宽度100%，高度固定卡片：宽度自适应，内容Hug 导航：移动端折叠，桌面端展开

7. 原型交互设计

7.1 交互类型

基础交互

On Click - 点击跳转
On Hover - 悬停效果
On Drag - 拖拽操作
While Pressing - 按压状态

高级交互

After Delay - 延时触发
Mouse Enter/Leave - 鼠标进入/离开
Key/Gamepad - 键盘操作

7.2 动画设置

过渡动画

微交互： - Duration: 150ms - Easing: Ease Out - 用途：按钮悬停、输入框聚焦标准动画： - Duration: 300ms - Easing: Ease In Out - 用途：页面切换、模态框复杂动画： - Duration: 500ms - Easing: Spring - 用途：列表展开、内容加载

Smart Animate

使用场景： - 组件状态变化 - 页面间元素连续性 - 列表项动画设置要点： - 保持图层命名一致 - 使用相同组件实例 - 合理设置动画时长

8. 团队协作规范

8.1 权限管理

角色分配

Owner：项目负责人 - 完全访问权限 - 管理团队成员 - 发布组件库 Editor：设计师 - 编辑设计文件 - 创建和修改组件 - 添加评论 Viewer：开发者/产品经理 - 查看设计文件 - 添加评论 - 检查设计规范

8.2 版本控制

版本命名规范

v主版本.次版本.修订版本例如：v2.1.3 主版本：重大功能更新次版本：新增功能或组件修订版本：Bug修复或小调整 分支管理 Main：主分支（稳定版本） Develop：开发分支（新功能开发） Feature：功能分支（具体功能开发） Hotfix：修复分支（紧急修复）

8.3 评论和反馈

评论规范

设计评论： - 明确指出问题位置 - 提供具体修改建议 - 使用@提及相关人员开发评论： - 标注技术实现难点 - 确认交互细节 - 询问设计意图

9. 设计交付规范

9.1 设计稿交付

文件整理 交付前检查： □ 页面命名规范 □ 图层命名清晰 □ 组件使用正确 □ 样式应用一致 □ 原型交互完整 标注说明 必要标注： - 尺寸标注（间距、大小） - 颜色标注（色值、透明度） - 字体标注（字号、行高、字重） - 交互标注（状态、动画）

9.2 开发者模式 (Dev Mode)

使用指南

开发者功能： - 自动生成CSS代码 - 获取精确尺寸数据 - 导出切图资源 - 查看组件属性 代码导出 CSS属性： - 自动生成样式代码 - 支持多种单位（px, rem, %） - 包含响应式断点资源导出： - SVG图标导出 - 图片资源导出 - 支持多倍图

10. 插件推荐

10.1 设计效率插件

必装插件

Content Reel： - 快速填充文本内容 - 支持中文假数据 - 提高设计效率 Unsplash： - 高质量图片素材 - 直接插入设计稿 - 免费商用 Iconify： - 海量图标库 - 支持多种风格 - 一键插入 辅助插件 Figma to Code： - 设计稿转代码 - 支持多种框架 - 提高开发效率 Contrast： - 颜色对比度检查 - 无障碍设计辅助 - WCAG标准检测 Component Inspector： - 组件使用情况分析 - 设计系统维护 - 组件优化建议

10.2 团队协作插件

沟通协作 FigJam： - 在线白板协作 - 头脑风暴 - 流程图绘制 Miro： - 项目规划 - 用户旅程图 - 团队协作

11. 质量检查清单

11.1 设计质量检查

视觉检查

□ 颜色使用符合设计系统 □ 字体样式应用正确 □ 间距遵循8点网格 □ 组件状态完整 □ 阴影效果合理 □ 圆角使用一致 交互检查 □ 原型流程完整 □ 动画时长合理 □ 交互反馈明确 □ 错误状态处理 □ 加载状态设计

11.2 技术检查

开发友好性

□ 图层命名规范 □ 组件结构清晰 □ 约束设置正确 □ 样式可复用 □ 代码导出准确 性能优化 □ 文件大小合理 □ 组件实例使用 □ 图片格式优化 □ 不必要元素清理

12. 常见问题解决

12.1 组件问题

组件不更新

解决方案： 1. 检查组件实例是否被覆盖 2. 重置组件实例 3. 更新组件库 4. 重新链接组件 样式不生效 解决方案： 1. 检查样式是否被覆盖 2. 确认样式应用层级 3. 重新应用样式 4. 清除本地样式

12.2 性能问题

文件加载慢

优化方案： 1. 减少页面数量 2. 优化图片大小 3. 清理无用元素 4. 使用组件实例 操作卡顿 解决方案： 1. 关闭不必要的插件 2. 清理浏览器缓存 3. 重启Figma应用 4. 检查网络连接

13. 更新日志

版本 1.0.0 (2024-01-01)

初始版本发布
建立Figma设计系统规范
定义组件库标准
制定团队协作流程

14. 参考资源

官方文档

Figma官方文档：https://help.figma.com/hc/en-us
Figma设计系统指南：https://www.figma.com/design-systems/
Figma最佳实践：https://www.figma.com/best-practices/

社区资源

Figma Community：https://www.figma.com/community
Design Systems Repo：https://designsystemsrepo.com/
Figma插件市场：https://www.figma.com/community/plugins

学习资源

Figma Academy：https://www.figma.com/academy/
YouTube Figma频道：https://www.youtube.com/figmadesign
设计系统案例研究：https://www.designsystems.com/

本指南将根据Figma功能更新和团队实践持续优化，确保与最新的设计趋势和工具功能保持同步。

第五步：连接 MCP 服务

使用 MCP 时需要将 Connected to server in channel: 124a3i4t 信息提供给 AI，以便调用 MCP 链接对应的频道，否则无法正常调用 Figma MCP 服务。

四、实践应用

需求梳理阶段

1. 使用 TRAE 编辑器， 结合 6A 工作流第一阶段对需求进行梳理2. 如果生成的需求不符合预期，可以通过与 AI 对话继续完善需求

动图

原型生成阶段

1. 利用 TRAE 完善需求文档 TRAE 会检索项目所用的技术栈，并据此完善需求文档。

动图

2. 根据需求生成原型和页面

动图

转码实现阶段

1. 点击编辑器中的 Figma 标签，登录到 Figma2. 找到需要实现的页面，选择后点击添加到对话 3. 指定使用 6A 文档，执行 6A 工作流完成转码需求

动图

通过以上流程，你可以实现从需求描述到可交付原型的完整自动化设计流程，大幅提升产品设计效率。

6A 工作流实战｜TRAE + Figma 产品设计自动化解决方案 - 哔哩哔哩

Trae之项目6A工作流配置_trea规则-CSDN博客

内容来源：

OIAPI/6A-TRAE: TRAE Rules 实践：为项目配置 6A 工作流https://github.com/OIAPI/6A-TRAE

废话少说，直接上内容：

# 身份定义
你是一位资深的软件架构师和工程师，具备丰富的项目经验和系统思维能力。你的核心优势在于：
- 上下文工程专家：构建完整的任务上下文，而非简单的提示响应
- 规范驱动思维：将模糊需求转化为精确、可执行的规范
- 质量优先理念：每个阶段都确保高质量输出
- 项目对齐能力：深度理解现有项目架构和约束
# 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文件管理
### 文档同步
代码变更同时更新相关文档
### 测试策略
**- 测试优先：**先写测试，后写实现
**- 边界覆盖：**覆盖正常流程、边界条件、异常情况
## 交互体验优化
## 进度反馈
- 显示当前执行阶段
- 提供详细的执行步骤
- 标示完成情况
- 突出需要关注的问题
## 异常处理机制
### 中断条件
- 遇到无法自主决策的问题
- 觉得需要询问用户的问题
- 技术实现出现阻塞
- 文档不一致需要确认修正
### 恢复策略
- 保存当前执行状态
- 记录问题详细信息
- 询问并等待人工干预
- 从中断点任务继续执行

引言：从"AI瞎写"到"精准交付"的实战手册

最近带团队做一个电商后台重构，让AI帮忙开发用户权限模块，结果差点把我送走——AI上来就直接写代码，完全没考虑我们现有架构的权限模型；改了三次还是不对，一问才发现它连数据库表结构都没搞清楚。这种"需求对齐靠猜、代码质量靠蒙"的开发模式，相信很多用过AI编程的同学都感同身受。

直到半年前接触了TRAE的规则配置功能，我才找到破局之道：用6A工作流管项目流程，用5S规则规范个人执行，两者结合让AI从"野生程序员"变身"可控助手"。今天就把这套实战经验分享出来，带你彻底摆脱AI开发的混乱状态。

一、什么是Rules：让AI"听话"的底层逻辑

很多人把TRAE的Rules功能简单理解为"提示词模板"，这就大错特错了！Rules 是一项强大的代码规范管理工具 ，它允许团队或开发者自定义并强制执行代码风格和最佳实践。它解决了三个核心痛点：

1. 告别重复指令疲劳

刚开始用AI时，我每天要重复输入"用Python 3.9语法"“遵循PEP8规范”“注释要包含参数校验说明”，直到配置了Rules，这些要求被"固化"到AI行为中。现在不管是新同事还是老员工，调用AI时都不用再强调基础规范，效率直接提升40%。

2. 实现"千人千面"的个性化适配

我带的团队里，前端同学喜欢AI给出"代码+效果图"的完整方案，后端同学只要"核心逻辑+测试用例"。通过个人Rules区分这些偏好后，AI输出的内容精准度提高了80%，再也不会出现"前端要UI示例，AI只给代码"的尴尬。

3. 构建"项目级"的约束边界

去年做支付系统时，AI擅自使用了已废弃的requests库旧API，导致线上bug。现在通过项目Rules明确"禁止使用requests <2.25.0版本"，这类问题直接从源头杜绝。规则就像给AI装了"护栏"，确保它在安全范围内发挥能力。

二、TRAE规则配置使用指南：从"配置"到"生效"的全流程

TRAE IDE（0.5.1+版本）支持两类规则，我总结为"个人规则定风格，项目规则定标准"，两者配合使用效果最佳。
请添加图片描述
在这里插入图片描述

ps：规则冲突怎么办？
遇到"个人规则要求简洁，项目规则要求详细"的冲突时，TRAE会优先遵循项目规则。我的建议是：个人规则聚焦表达风格，项目规则专注技术约束，这样能从根本上减少冲突。

三、6A工作流项目规则：给AI套上"项目管理紧箍咒"

6A工作流（Align-Architect-Atomize-Approve-Automate-Assess）是TRAE最核心的项目规则体系，本质是通过标准化流程让AI"不敢偷懒、不能瞎写"。我带团队落地3个月，项目返工率直接从40%降到5%，这背后每个阶段都有"反AI偷懒"的小心机。

1. 6A工作流项目规则介绍

在这里插入图片描述

阶段1：Align（对齐）

把模糊需求锤成"钢印级"规范，杜绝AI"我以为"式开发。记住：需求边界不清，后面全是坑。

阶段2：Architect（架构）

从共识文档到系统架构，Align阶段确认需求后，AI会自动生成DESIGN_任务名.md，用mermaid画架构图，拒绝AI"拍脑袋写代码"。

阶段3：Atomize（原子化）

拆分任务到AI"不可能失败"的粒度，复杂任务拆成20行内代码块。

阶段4：Approve（审批）

拿着TASK_任务名.md逐条检查，重点看"验收标准是否可测试"——比如"用户注册接口"不能写"功能正常"，必须写"输入重复手机号返回code=1001错误"

阶段5：Automate（自动化执行）

AI按任务顺序执行，每写完一个函数必须先写单元测试（我加了规则：测试不通过不准提交代码）

阶段6：Assess（评估）

最终生成FINAL_任务名.md，包含代码质量评分（用SonarQube扫描）、测试覆盖率（要求≥80%）、遗留TODO（比如"性能优化待后续迭代"）
在这里插入图片描述

2. 附6A工作流项目规则：project_rules.md（即拿即用）

下载地址：TRAE通用开发规则配置之6A工作流项目规则和敏捷开发5S个人规则
在这里插入图片描述

四、5S敏捷开发个人规则：让自己成为"AI驯兽师"

6A解决了项目流程问题，但个人执行不到位还是白搭。我总结的5S个人规则，专治"AI依赖症"和"开发拖延症"。

1. 5S敏捷开发个人规则介绍

1S：文档管理（核心中的核心）

血泪教训：去年有个项目文档没及时更新，接手的同事不知道"用户表已添加last_login字段"，结果新功能上线直接报错。现在我团队强制：

创建时机：新项目第一天必须建说明文档.md，包含"项目规划+实施方案+进度记录"
更新要求：每次开发前先读文档，改一行代码就同步更新文档，完成任务后必须写"结果说明"

2S：开发流程（顺序化思考，拒绝跳步）

用分析法拆解需求，比如开发"商品列表页"：

先写接口文档（输入参数、返回格式）
再写单元测试（边界条件：空列表、分页越界）
最后实现功能

关键原则：完成一个任务打勾一个，绝不允许"这个功能差不多了，先做下个"。我见过有人同时开5个文件改代码，最后自己都不知道改了啥。

3S：问题解决（官方文档是爹，搜索引擎是儿子）

AI不是万能的！上次遇到Python的asyncio问题，AI给的代码有bug，查也没解决。最后翻Python官方文档才发现是"事件循环策略"用错了。现在我定了规矩：

技术问题先查，解决不了必须翻官方文档（Python查Python.org，Java查Oracle）
严禁"百度一下复制粘贴"，谁用非官方方案谁背锅

4S：执行约束（三大"绝不允许"）

这是我从军队管理学来的——用铁律杜绝侥幸心理：

绝不允许项目延期：提前3天识别风险，延期必须同步更新文档并说明原因
绝不允许超出计划：加功能可以，但必须先改规划文档，评估影响
绝不允许出错：编译错误、测试不通过、文档不一致，这三类错误零容忍

5S：环境与输出（细节决定成败）

开发环境：例如全团队统一用Windows（避免Linux/macOS路径分隔符坑），IDE插件版本锁定（比如Prettier用2.8.0）

代码输出：所有函数必须加注释，格式固定为：

def login(username: str, password: str) -> dict:  
    """  
    用户登录接口  
    :param username: 用户名（长度6-20位）  
    :param password: 密码（包含大小写+数字）  
    :return: {code:0,data:{token:str,user:dict}}  
    """

python

2.附5S敏捷开发个人规则：user_rules.md（即拿即用）

下载地址：TRAE通用开发规则配置之6A工作流项目规则和敏捷开发5S个人规则
在这里插入图片描述

五、6A+5S协同：1+1>10的实战效果

单独用6A或5S效果有限，但结合起来简直是"降维打击"。我带的电商项目用这套组合拳后：

返工率：从40%→5%（Align阶段解决需求偏差，5S文档避免信息断层）
开发效率：单人日产出从3个功能点→8个（Atomize拆分后AI执行更快，5S顺序执行减少切换成本）
代码质量：SonarQube问题数从平均20个/千行→3个（Automate阶段强制测试，5S约束注释规范）

举个真实案例：最近开发"优惠券系统"，6A确保架构对齐现有营销系统，5S让每个开发按"文档→测试→代码"顺序执行，结果提前5天上线，零bug。

六、常见问题

Q：6A 工作流会不会太复杂？小项目能用吗？
A：初期可能感觉步骤多，但相比后期的返工和维护成本，绝对值得！而且 AI 会自动执行，你只需要确认关键节点。

Q：适合什么规模的项目？
A：从小功能到大项目都适用。小项目可以简化某些阶段，大项目则能充分发挥威力。

Q：如何说服团队使用？
A：先在一个小项目上试用，效果立竿见影，自然就能说服大家。

结语：从"被AI带跑"到"驾驭AI"

工欲善其事，必先利其器。AI编程的终极目标不是让AI替我们干活，而是用规则把AI变成"超级工具"。

6A工作流管项目流程，5S个人规则管执行细节，两者结合才能真正释放AI威力。通过系统化的流程管理，我们可以：

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

最后送大家一句话：好的AI助手不是天生的，是调教出来的。现在就打开Trae IDE，配置你的第一条规则吧！

TRAE调教指南：用6A工作流项目规则+5S敏捷个人规则打造高效AI开发流程_trae个人规则-CSDN博客

哈喽，小伙伴们！今天给大家带来一个超级干货，堪称“程序员的外挂大脑”——Trae/Cursor/Claude 通用智能体提示词合集！ 😄
在这里插入图片描述

你是不是也经常觉得，虽然现在的AI编码助手很强，但让它写特定领域（比如数据库优化、安全审计）的代码时，它还是有点“泛”，不够“专精”？别急，今天介绍的这套合集，就是来解决这个痛点的！

说白了，这套合集就是61个“专家身份”的说明书。你只要把对应的“说明书”（提示词）交给AI（Trae、Cursor或Claude都行），它就会立刻“变身”为那个领域的专家，输出的代码和建议专业度直接拉满！下面，我就手把手带大家玩转这个神器。

一、这到底是什么“黑科技”？

简单来说，这是一套由61个高度专业化提示词（Prompt）组成的工具箱。每一个提示词都精心设计，用于将通用的AI编程助手，“调教”成某个特定领域的高手，特别是Trae的SOLO模式会根据需要自动调用不同的智能体专家。
在这里插入图片描述

它的核心价值在于：

极大减少“幻觉”：给AI划定明确的职责和知识边界，让它更专注于提供领域内最可靠的答案。
提升代码质量与效率：无需你再反复解释背景和细节要求，AI从一开始就以专家视角思考。
覆盖开发全生命周期：从系统架构、写代码、做测试、部署运维，到写文档、做市场分析，都有对应的专家替你干活。

个人体验：用它之后，最明显的感受就是和AI的沟通成本骤降。以前需要说“请用Java写一个并发安全的池，注意上下文和错误处理”，现在只需要说“我是Java专家，任务：实现一个并发安全的资源池”，它给出的方案从一开始就非常地道。

二、合集里都有哪些“专家”？（超全目录）

这61个智能体分门别类，堪称一个完整的“数字公司”。主要分为以下几大类：

1. 开发与架构团队

这是你的核心产研团队！

后端架构师：设计API、微服务拆分不在话下。
前端开发者 & UI/UX设计师：一个负责实现，一个负责美感，完美搭配。
移动开发者 / Flutter专家 / iOS开发者：搞定跨平台和原生App。
架构评审员：扮演严厉的Tech Lead，专门帮你审代码、把质量关。

2. 各编程语言“大神”

这是你的高级工程师团队，精通各种技术栈！

Python专家、Golang专家、Rust专家、JavaScript/TypeScript专家……几乎主流语言全覆盖。
甚至还有 C语言专家（搞嵌入式的同学狂喜）、Scala专家（大数据领域必备）、Minecraft Bukkit专家（没想到吧！）。

3. 基础设施与运维（SRE）团队

确保你的应用跑得稳、撑得住！

DevOps故障排查员：线上出问题了？让它帮你看日志、定位根因。
云架构师 & Terraform专家：设计云上架构，用代码管理基础设施。
数据库优化师 & 数据库管理员(DBA)：慢查询优化、备份容灾方案都交给它。
应急响应员：发生P0级故障时的“消防员”，指令直接、精准。

4. 质量与安全团队

你的代码“质检员”和“保安”！

Security-Auditor（安全审计员）：用OWASP标准扫你的代码，找出安全漏洞。
Code-Reviewer：比普通CR更严格，特别关注配置安全和生产可靠性。
Test-Automator & Debugger：一个负责写各种测试用例，一个负责消灭Bug。

5. 数据与AI团队

AI工程师 & Prompt工程师：帮你构建RAG系统、优化大模型提示词。
MLOps工程师：搭建机器学习项目的流水线和实验跟踪平台。

6. 文档与支持团队

再也不用头疼写文档了！

Docs-Architect（文档架构师）：基于你的代码生成完整的技术文档。
Mermaid-Expert：一键生成流程图、时序图、架构图，颜值超高。
Tutorial-Engineer：把你的项目变成一步步的教程，新手福音。

7. 商业与市场团队（彩蛋功能）

Legal-Advisor（法律顾问）：帮你草拟隐私政策、免责声明！（亲测有用）
Content-Marketer：写博客、社交媒体文案手到擒来。

三、手把手教你如何使用

使用起来简单到哭，就两步：

第一步：复制
找到你想用的那个智能体提示词（合集文件里都有），全选复制。

第二步：粘贴
打开你的 Trae、Cursor 或 Claude，找到设置或对话中“自定义指令”、“系统提示词”、“角色设定”这类输入框（不同工具位置不同），把复制的内容粘贴进去。

举个栗子，在Trae里设置上下文管理专家：
1.找到Trae中关于智能体的设置，点击创建智能体在这里插入图片描述
2.将md 文件中的内容复制到相应位置，点击保存即可创建成功

四、实战技巧：什么时候该召唤哪位专家？

这是最关键的一步！用对了专家，事半功倍。下面是我的使用心法：

1. 当你开始一个新项目时（规划期）

头脑风暴/定技术栈：召唤 cloud-architect (云架构师) + backend-architect (后端架构师) + frontend-developer (前端开发者)，一起讨论技术选型和架构图。
设计界面：直接交给 ui-ux-designer (UI/UX设计师)，让它出原型图（用Mermaid或文字描述）。

2. 当你正在编码时（开发期）

写核心业务逻辑：对应语言专家，如 python-pro, golang-pro。
写数据库操作： sql-pro (SQL专家) 和 database-optimizer (数据库优化师) 交替使用，一个写查询，一个做优化。
处理难题：遇到并发问题找 golang-pro；遇到内存安全问题找 rust-pro；要重构老代码找 legacy-modernizer (遗留系统现代化专家)。

3. 当你写完代码后（测试与交付期）

代码质量检查：一定要让 code-reviewer 审一遍！
安全检查：上线前，务必请 security-auditor 做一次扫描。
写测试：把需求丢给 test-automator，让它生成单元测试、集成测试用例。
部署上线： deployment-engineer (部署工程师) 和 terraform-specialist (Terraform专家) 可以帮你写部署脚本和IaC代码。

4. 当项目上线后（运维期）

监控与排错： devops-troubleshooter (DevOps故障排查员) 和 error-detective (错误侦探) 是分析日志、定位线上问题的黄金搭档。
性能优化：感觉系统慢了？performance-engineer (性能工程师) 帮你找瓶颈。

5. 别忘了“组合技”！

这是官方也提到的终极技巧：你可以同时为AI赋予多个专家身份！

例如，你想开发一个带好看界面的数据分析工具：

提示词开头可以这样写：“现在你同时具备 Python专家 和 UI/UX设计师 的能力。请设计并编写一个用于股票数据可视化分析的桌面应用，要求界面现代简洁…”

AI就会以双重视角来思考，给出的方案既有稳健的Pandas/Matplotlib后端代码，又有关于前端布局、配色方案的设计建议，真正做到全栈输出！

五、总结与获取方式

总而言之，这套 Trae/Cursor/Claude 通用智能体提示词合集，就像为你配备了一个按需调用、永不疲倦的顶尖技术团队。它极大地拓宽了AI编程助手的边界，将其从一个“什么都懂一点”的助手，变成了一个“在某个领域极其精通”的专家。

61个通用智能体提示词合集获取地址：IT 开发技术 + 智能体提示词 + 61 个多领域专家角色 + 指导项目开发与效率提升

希望这篇教程能帮你打开AI编程的新世界大门！赶紧挑几个你需要的“专家”，去试试吧！如果你有更酷的用法或组合，欢迎在评论区分享哦！

61个智能体提示词让AI变成你的全栈开发团队！Trae/Cursor/Claude通用智能体合集详解_trae智能体提示词-CSDN博客

posted @ 2026-04-10 16:33 charyGao 阅读(494) 评论(0) 收藏举报

刷新页面返回顶部

硅基文明

代码改变不了世界，但是改变世界需要代码。 正在找工作，欢迎发 JD 到我邮箱，坐标上海浦东新区。

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

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

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

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

第 1 步：创建项目规则

激活方式

身份定义

6A工作流执行规则

阶段1: Align (对齐阶段)

阶段2: Architect (架构阶段)

阶段4: Approve (审批阶段)

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

阶段6: Assess (评估阶段)

技术执行规范

安全规范

文档同步

测试策略

交互体验优化

进度反馈

异常处理机制

中断条件

恢复策略

第 2 步：启动工作流

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

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

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

四、痛点解决方案对照表

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

六、常见问题

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

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

Q: 如何说服团队使用？

七、总结：告别 AI 偷懒时代

一、前言

二、成果展示

三、环境配置

第一步：安装基础环境

第二步：配置 TRAE

第三步：配置 MCP 工具

第四步：添加上下文

激活方式

身份定义

6A 工作流执行规则

阶段1: Align (对齐阶段)

阶段2: Architect (架构阶段)

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

阶段4: Approve (审批阶段)

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

阶段6: Assess (评估阶段)

技术执行规范

文档同步

测试策略

交互体验优化

进度反馈

异常处理机制

中断条件

恢复策略

概述

1. Figma文件组织结构

1.1 文件命名规范

1.2 页面组织结构

1.3 图层命名规范

2. Figma设计系统搭建

2.1 颜色样式 (Color Styles)

2.2 文字样式 (Text Styles)

2.3 效果样式 (Effect Styles)

3. 组件库构建

3.2 复合组件 (Composite Components)

4. 网格系统设置

4.1 布局网格 (Layout Grid)

4.2 基线网格 (Baseline Grid)

5. Auto Layout最佳实践

5.1 Auto Layout设置原则

5.2 常用Auto Layout模式

6. 约束和响应式设计

6.1 约束设置 (Constraints)

固定元素

6.2 响应式组件设计

代码改变不了世界，但是改变世界需要代码。正在找工作，欢迎发 JD 到我邮箱，坐标上海浦东新区。