novalon/novalon-manage-system
6
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
24422c2c19088d65788a63aa2d70c504e5bbccda
novalon-manage-system/.trae/rules/project_rules.md
T

7.0 KiB
Raw Blame History

alwaysApply, description
alwaysApply description
false 6A工作流

6A 工作流执行规范

概述

6A 工作流是一种系统化的软件开发方法论，通过六个阶段确保项目高质量交付：

Align(对齐) → Architect(架构) → Atomize(原子化) → Approve(审批) → Automate(自动化) → Assess(评估)

阶段 1: Align 对齐阶段

🎯 目标



模糊需求 → 精确规范

📋 执行步骤

1.项目上下文分析

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

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

  • 理解业务域和数据模型

    2.需求理解确认

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

  • 包含项目和任务特性规范

  • 包含原始需求、边界确认、需求理解、疑问澄清

    3.智能决策策略

  • 自动识别歧义和不确定性

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

  • 优先基于现有项目内容和行业知识进行决策

  • 有人员倾向或不确定的问题主动中断并询问

  • 基于回答更新理解和规范

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

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

    5.最终共识

  • 生成 .trae/docs/任务名/CONSENSUS_[任务名].md 包含：

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

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

  • 任务边界限制和验收标准

  • 确认所有不确定性已解决

✅ 质量门控

  • 需求边界清晰无歧义
  • 技术方案与现有架构对齐
  • 验收标准具体可测试
  • 所有关键假设已确认
  • 项目特性规范已对齐

阶段 2: Architect 架构阶段

🎯 目标



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

📋 执行步骤

1.系统分层设计

  • 基于 CONSENSUS、ALIGNMENT 文档设计架构

  • 生成 .trae/docs/任务名/DESIGN_[任务名].md 包含：

  • 整体架构图(mermaid 绘制)

  • 分层设计和核心组件

  • 模块依赖关系图

  • 接口契约定义

  • 数据流向图

  • 异常处理策略

    2.设计原则

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

  • 确保与现有系统架构一致

  • 复用现有组件和模式

✅ 质量门控

  • 架构图清晰准确
  • 接口定义完整
  • 与现有系统无冲突
  • 设计可行性验证

阶段 3: Atomize 原子化阶段

🎯 目标



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

📋 执行步骤

1.子任务拆分

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

  • 每个原子任务包含：

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

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

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

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

    2.拆分原则

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

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

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

  • 依赖关系清晰

    3.生成任务依赖图

  • 使用 mermaid 绘制任务依赖关系图

✅ 质量门控

  • 任务覆盖完整需求
  • 依赖关系无循环
  • 每个任务都可独立验证
  • 复杂度评估合理

阶段 4: Approve 审批阶段

🎯 目标



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

📋 执行步骤

1.执行检查清单

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

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

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

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

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

    2.最终确认清单

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

  • 明确的子任务定义

  • 明确的边界和限制

  • 明确的验收标准

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

阶段 5: Automate 自动化执行

🎯 目标



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

📋 执行步骤

1.逐步实施子任务

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

    2.代码质量要求

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

  • 保持与现有代码风格一致

  • 使用项目现有的工具和库

  • 复用项目现有组件

  • 代码尽量精简易读

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

    3.异常处理

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

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

  • 寻求人工澄清后继续

    4.逐步实施流程

    按任务依赖顺序执行，对每个子任务执行：

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

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

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

  • 运行验证测试

  • 更新相关文档

  • 每完成一个任务立即验证

阶段 6: Assess 评估阶段

🎯 目标



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

📋 执行步骤

1.验证执行结果

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

  • 整体验收检查：

  • 所有需求已实现

  • 验收标准全部满足

  • 项目编译通过

  • 所有测试通过

  • 功能完整性验证

  • 实现与设计文档一致

    2.质量评估指标

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

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

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

  • 现有系统集成良好

  • 未引入技术债务

    3.最终交付物

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

  • 生成 .trae/docs/任务名/TODO_[任务名].md(待办事宜和缺少的配置等)

    4.TODO 询问

  • 询问用户 TODO 的解决方式

  • 精简明确待办事宜和缺少的配置

  • 提供有用的操作指引

技术执行规范

🔐 安全规范

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

📝 文档同步

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

🧪 测试策略

  • 测试优先：先写测试，后写实现
  • 边界覆盖：覆盖正常流程、边界条件、异常情况

💡 交互体验优化

进度反馈

  • 显示当前执行阶段
  • 提供详细的执行步骤
  • 标示完成情况
  • 突出需要关注的问题

异常处理机制

中断条件
  • 遇到无法自主决策的问题
  • 觉得需要询问用户的问题
  • 技术实现出现阻塞
  • 文档不一致需要确认修正
恢复策略
  • 保存当前执行状态
  • 记录问题详细信息
  • 询问并等待人工干预
  • 从中断点任务继续执行

附录：文档模板索引

| 阶段 | 文档名称 | 用途 |

| --------- | ----------------------- | -------------- |

| Align | ALIGNMENT_[任务名].md | 需求理解与确认 |

| Align | CONSENSUS_[任务名].md | 最终共识与规范 |

| Architect | DESIGN_[任务名].md | 系统架构设计 |

| Atomize | TASK_[任务名].md | 原子任务定义 |

| Automate | ACCEPTANCE_[任务名].md | 执行过程记录 |

| Assess | FINAL_[任务名].md | 项目总结报告 |

| Assess | TODO_[任务名].md | 待办事宜清单 |

Reference in New Issue View Git Blame Copy Permalink