6A 工作流：让 Cursor、Trae 等AI编程助手按流程交付的实战手册
6A 工作流：让 Cursor、Trae 等AI编程助手按流程交付的实战手册
从"让AI写代码"到"让AI按规范交付"的进阶之路
文章概览
适合人群
- 使用 Cursor、Trae、Claude、Copilot 等 AI 编程工具的开发者
- 想要提升 AI 协作效率和代码质量的技术人员
- 需要标准化 AI 辅助开发流程的团队负责人
你将获得
- 6A 工作流完整方法论与实操清单
- 可直接复制的文档模板和流程图
- 从"模糊需求"到"可交付成果"的标准化路径
- AI 编程工具的高效协作实践
为什么AI编程需要6A工作流？
当你对 Cursor 说"帮我写个用户管理系统"，得到的往往是：
- 代码能跑，但不知道边界在哪
- 功能实现了，但测试用例缺失
- 架构混乱，后续扩展困难
- 文档缺失，交接维护困难
6A 工作流解决的核心问题：把AI从"代码生成器"变成"按规范交付的开发伙伴"
解决什么问题：
- AI 生成的代码质量参差不齐
- 复杂需求拆解困难
- 缺乏系统性的质量保障
- 项目整体架构缺失
为什么你需要这套工作流？
如果你是 Cursor、Trae AI 等 AI 编程工具的重度用户，可能遇到过这些困扰：
常见痛点场景
场景1：需求理解偏差
你：帮我做个用户管理系统
AI：好的，我来写一个简单的用户 CRUD...
你：等等，我要的是企业级的，要有权限、审批、多租户...
场景2：架构缺失导致重构
项目进行到一半：
- 代码结构混乱
- 组件耦合严重
- 难以扩展和维护
- 不得不推倒重来
场景3：质量无法保障
AI 生成的代码：
- 缺少边界检查
- 异常处理不完整
- 测试覆盖不足
- 安全隐患存在
6A 工作流正是为了解决这些核心问题而设计的。
6A工作流核心理念
文档先行 + 任务递归 + 范围收敛 = 可控交付
- 文档先行：不写清楚需求文档，不允许开始编码
- 任务递归：复杂任务层层分解到AI能稳定完成的原子级别
- 范围收敛：明确边界，防止AI"想当然"地扩展功能
六个阶段总览
graph LRA[Align<br/>对齐] --> B[Architect<br/>架构]B --> C[Atomize<br/>原子化]C --> D[Approve<br/>审批]D --> E[Automate<br/>执行]E --> F[Assess<br/>评估]A1[需求澄清<br/>ALIGNMENT.md] --> AB1[架构设计<br/>DESIGN.md] --> BC1[任务拆分<br/>TASK.md] --> CD1[人工检查<br/>检查清单] --> DE1[代码实现<br/>ACCEPTANCE.md] --> EF1[质量验收<br/>FINAL.md] --> F
各阶段核心产出
| 阶段 | 目标 | 关键产出 | AI工具配合要点 |
|---|---|---|---|
| Align | 需求澄清 | ALIGNMENT.mdCONSENSUS.md | 让AI帮助识别需求歧义点 |
| Architect | 系统设计 | DESIGN.md架构图 | AI生成架构图和接口定义 |
| Atomize | 任务拆分 | TASK.md依赖图 | AI拆分复杂任务为原子任务 |
| Approve | 人工把关 | 检查确认 | 人工验证AI的拆分合理性 |
| Automate | 代码实现 | ACCEPTANCE.md测试+代码 | AI按任务清单逐个实现 |
| Assess | 质量验收 | FINAL.mdTODO.md | AI生成总结和待办清单 |
AI工具适配性说明
- Cursor：特别适合 Automate 阶段的代码实现，配合文档能精确生成
- Trae：全流程适配，rules功能可固化6A工作流
- Claude/GPT：适合 Align 和 Architect 阶段的分析和设计
- Copilot：在明确任务边界后，提供高质量代码补全
详细实操手册
以下内容为付费部分，提供完整的实操指南、模板和案例
📋 6A工作流完整模板
重要说明：这是可以直接复制使用的完整6A工作流模板，适用于所有AI编程工具（Cursor、Trae、Claude等）
==== 6A WORKFLOW 完整模板 ====
6A WORKFLOW# 激活方式
用户输入以下6A开头的内容即可启动工作流 :
**激活时立即响应：6A工作流已激活**
* 以下是一个示例，仅供参考
```eg.
用户：@6A 开发一个用户管理系统...
AI：收到！开始6A工作流...📋 阶段1 - 需求对齐中...
创建了 ALIGNMENT_用户管理系统.md
分析了你的需求，生成了澄清问题...
请确认以下几点：
1. 用户角色有哪些？
2. 需要哪些权限管理？
3. 数据库用什么？# 身份定义
你是一位资深的软件架构师和工程师，具备丰富的项目经验和系统思维能力。你的核心优势在于：
* 上下文工程专家：构建完整的任务上下文，而非简单的提示响应
* 规范驱动思维：将模糊需求转化为精确、可执行的规范
* 质量优先理念：每个阶段都确保高质量输出
* 项目对齐能力：深度理解现有项目架构和约束# 6A工作流执行规则## 阶段1: Align (对齐阶段)
---
**目标**: 模糊需求 → 精确规范### 执行步骤
1. **项目上下文分析*** 分析现有项目结构、技术栈、架构模式、依赖关系* 分析现有代码模式、现有文档和约定* 理解业务域和数据模型
2. **需求理解确认*** 创建 `docs/任务名/ALIGNMENT_[任务名].md`* 包含项目和任务特性规范* 包含原始需求、边界确认（明确任务范围）、需求理解（对现有项目的理解）、疑问澄清（存在歧义的地方）
3. **智能决策策略*** 自动识别歧义和不确定性* 生成结构化问题清单（按优先级排序）* 优先基于现有项目内容和查找类似工程和行业知识进行决策并在文档中回答* 有人员倾向或不确定的问题主动中断并询问关键决策点* 基于回答更新理解和规范
4. **中断并询问关键决策点*** 主动中断询问，迭代执行智能决策策略
5. **最终共识*** 生成 `docs/任务名/CONSENSUS_[任务名].md`，包含：* 明确的需求描述和验收标准* 技术实现方案和技术约束和集成方案* 任务边界限制和验收标准* 确认所有不确定性已解决* **质量门控**:* 需求边界清晰无歧义* 技术方案与现有架构对齐* 验收标准具体可测试* 所有关键假设已确认* 项目特性规范已对齐## 阶段2: Architect (架构阶段)
---
**目标**: 共识文档 → 系统架构 → 模块设计 → 接口规范### 执行步骤
1. **系统分层设计*** 基于 `CONSENSUS`、`ALIGNMENT` 文档设计架构* 生成 `docs/任务名/DESIGN_[任务名].md`，包含：* 整体架构图（使用 Mermaid或PlantUML 绘制）* 分层设计和核心组件* 模块依赖关系图* 接口契约定义* 数据流向图* 异常处理策略
2. **设计原则*** 严格按照任务范围，避免过度设计* 确保与现有系统架构一致* 复用现有组件和模式* **质量门控**:* 架构图清晰准确* 接口定义完整* 与现有系统无冲突* 设计可行性验证## 阶段3: Atomize (原子化阶段)
---
**目标**: 架构设计 → 拆分任务 → 明确接口 → 依赖关系### 执行步骤
1. **子任务拆分*** 基于 `DESIGN` 文档生成 `docs/任务名/TASK_[任务名].md`* 每个原子任务包含：* 输入契约（前置依赖、输入数据、环境依赖）* 输出契约（输出数据、交付物、验收标准）* 实现约束（技术栈、接口规范、质量要求）* 依赖关系（后置任务、并行任务）
2. **拆分原则*** 复杂度可控，便于 AI 高成功率交付* 按功能模块分解，确保任务原子性和独立性* 有明确的验收标准，尽量可以独立编译和测试* 依赖关系清晰
3. **生成任务依赖图*** 使用 Mermaid 或 PlantUML 绘制任务依赖图* **质量门控**:* 任务覆盖完整需求* 依赖关系无循环* 每个任务都可独立验证* 复杂度评估合理## 阶段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工具（如Cursor的.cursorrules文件、Trae的自定义规则等）
- 根据具体项目需求调整模板内容
- 建议先在小型项目上试用，熟悉流程后再应用到大型项目
阶段1：Align（对齐阶段）详细实操
执行步骤与AI协作要点
1. 项目上下文分析
提示词模板：
"请分析当前项目的技术栈、架构模式和代码规范。
基于以下项目结构：[贴入项目目录结构]
识别：
1. 使用的技术栈和框架
2. 现有的架构模式
3. 代码组织规范
4. 依赖管理方式"
2. 需求理解确认
创建 docs/任务名/ALIGNMENT_[任务名].md 模板：
# 需求对齐文档 - [任务名]## 原始需求
[从用户/产品方获得的原始需求描述]## 项目上下文
### 技术栈
- 编程语言：
- 框架版本：
- 数据库：
- 部署环境：### 现有架构理解
- 架构模式：
- 核心模块：
- 集成点：## 需求理解
### 功能边界
**包含功能：**
- [ ] 功能点1
- [ ] 功能点2**明确不包含（Out of Scope）：**
- [ ] 功能点A
- [ ] 功能点B### 约束条件
- 性能要求：
- 安全要求：
- 兼容性要求：## 疑问澄清
### P0级问题（必须澄清）
1. 问题描述- 背景：- 影响：- 建议方案：### P1级问题（建议澄清）
1. 问题描述- 背景：- 影响：- 建议方案：## 验收标准
### 功能验收
- [ ] 标准1：具体可测试的描述
- [ ] 标准2：具体可测试的描述### 质量验收
- [ ] 单元测试覆盖率 > 80%
- [ ] 性能基准：响应时间 < XmsΩ
- [ ] 安全扫描无高危漏洞
3. AI辅助澄清策略
提示词模板：
"基于以下需求描述：[需求内容]
请帮我：
1. 识别所有可能的歧义点
2. 按优先级（P0必须/P1建议）生成问题清单
3. 对于技术类问题，基于行业最佳实践提供建议方案
4. 标注哪些问题需要人工决策"
4. 共识文档生成
docs/任务名/CONSENSUS_[任务名].md 模板：
# 共识文档 - [任务名]## 明确的需求描述
[经过澄清后的明确需求]## 技术实现方案
### 技术选型
- 框架：[具体版本]
- 数据库：[具体版本]
- 第三方库：[列出关键依赖]### 技术约束
- 必须复用的组件：
- 必须遵循的规范：
- 性能约束：### 集成方案
- API接口规范：
- 数据库集成：
- 第三方服务集成：## 任务边界
### 本期实现
- [ ] 核心功能1
- [ ] 核心功能2### 后期规划
- [ ] 扩展功能1
- [ ] 扩展功能2## 验收标准
### 功能标准
- [ ] [具体可测试的功能点]### 技术标准
- [ ] [具体可测试的技术指标]
质量门控检查
在进入下一阶段前，必须确认：
- 需求边界清晰无歧义
- 技术方案与现有架构对齐
- 验收标准具体可测试
- 所有关键假设已确认
阶段2：Architect（架构阶段）详细实操
AI辅助架构设计
1. 架构图生成提示词
提示词模板：
"基于CONSENSUS文档内容：[贴入文档]
请设计系统架构，要求：
1. 使用Mermaid语法绘制架构图
2. 体现分层设计（展示层/业务层/数据层）
3. 标注关键组件和数据流
4. 考虑现有系统集成点
5. 突出本次开发的新增部分"
2. DESIGN文档模板
# 设计文档 - [任务名]## 架构概览### 整体架构图