目录
一、目的
二、解决方案
2.1 给智能体一个身份
2.2 规则定义
2.2.1 个人规则
2.2.2 项目规则
2.2.3 规则优先级
三、常见问题
3.1 历史对话记录导致模型输出冲突
3.2 如何查看"6A工作流"生成的文档
四、文章总结
一、目的
AI工具从代码补全、错误修复，到可以直接对话就能够写代码，已经发展越来越快了。但是在使用过程，如果仅仅通过简单提示词去说明问题，可能往往效果会差强人意。例如想要开发一款微信小程序，提供相关页面效果和功能描述，他的理解可能会有一些偏差，同时一些设计规范可能和团队现有的方式不一致等问题。
那在Trae使用时，如何让AI即可以解决复杂需求、又按照符合规范的方式输出成果呢？答：智能体、规范、上下文设置。
可访问官网下载Trae：https://www.trae.ai/s/gHAQml
https://www.trae.ai/s/gHAQml
二、解决方案
让AI按照专业项目管理流程执行。通过给AI智能体设置对应角色身、工作流程、规则规范的方式，来管理AI执行过程。了解AI的执行过程，明确开发任务边界，避免AI的肆意发散。
2.1 给智能体一个身份
自定义智能体，定义角色身份、工作流程和规则规范，可以构建出更专业、可靠、易用的智能体，让智能体清楚能力范围，并使用专业领域知识回复问题。
示例(智能体提示词)：
你是一位资深的软件架构师和工程师，具备丰富的项目经验和系统思维能力。你的核心优势在于：
1、上下文工程专家：构建完整的任务上下文，而非简单的提示响应。
2、规范驱动思维：将模糊需求转化为精确、可执行的规范。
3、质量优先理念：每个阶段都确保高质量输出。
4、项目对齐能力：深度理解现有项目架构和约束。
2.2 规则定义
2.2.1 个人规则
如果希望所有智能体都能使用某些项目规范或个人习惯，应该将其放在 project_rules.md 或 user_rules.md 中，例如
结合个人习惯和《重构》这本书的核心要求形成 User Rule：
ps：可以把面向对象的设计原则等内容放进去，以下内容可以根据需要进行调整。
# 通用规范
## 基本规范
1. 始终用中文交流。
2. 生成代码时添加函数级别的注释。
3. 我的系统是 Window10专业版。
4. 使用 pnpm 而不是 npm。
# 用户编码规范与重构指南
## 基础交互规则
1. 请用中文回答我
2. 如果回答的是代码，请给每个关键节点，比较难懂的代码增加中文注释
3. 当生成的代码行数超过 20 行时，请考虑聚合代码以及考虑其颗粒度是否适合
## 代码质量与重构规范
### 通用编码规范
1. 避免不必要的对象复制或克隆
2. 避免多层嵌套，提前返回
3. 使用适当的并发控制机制
## 代码坏味道识别与处理
基于Martin Fowler《重构》一书的核心观点，以下是应当注意的代码坏味道及其处理方法：
### 1. 神秘命名
– **问题**：变量、函数、类或模块的名称不能清晰表达其用途和含义
– **处理**：重命名为具有描述性的名称，使代码自解释
– **示例**：将`fn p()`改为`fn calculate_price()`
### 2. 重复代码
– **问题**：相同或相似的代码出现在多个地方
– **处理**：提取为函数、类或模块；应用模板方法模式
– **示例**：将重复的验证逻辑提取为共享函数
### 3. 过长函数
– **问题**：函数过长，难以理解和维护
– **处理**：提取函数，将大函数分解为多个小函数
– **示例**：将200行的处理函数分解为多个职责单一的小函数
### 4. 过大的类/结构体
– **问题**：类或结构体承担了过多责任，字段和方法过多
– **处理**：提取类，将相关字段和方法组合成新的类
– **示例**：将User类中的地址相关字段提取为Address类
### 5. 过长参数列表
– **问题**：函数参数过多，难以理解和使用
– **处理**：引入参数对象，将相关参数组合成对象
– **示例**：将`fn create_user(name, email, phone, address, city, country)`改为`fn create_user(user_info: UserInfo)`
### 6. 发散式变化
– **问题**：一个类因为多种原因而被修改
– **处理**：按照变化原因拆分类
– **示例**：将既处理数据库又处理业务逻辑的类拆分为两个类
### 7. 霰弹式修改
– **问题**：一次修改需要改动多个类
– **处理**：将相关功能移到同一个类中
– **示例**：将分散在多个类中的订单处理逻辑合并到一个OrderProcessor类
### 8. 依恋情结
– **问题**：一个函数对其他类的兴趣超过自己所在的类
– **处理**：移动函数或提取函数
– **示例**：将过度使用另一个类数据的方法移动到那个类中
### 9. 数据泥团
– **问题**：相同的数据项总是一起出现
– **处理**：提取为对象
– **示例**：将经常一起出现的起始日期和结束日期提取为DateRange类
### 10. 基本类型偏执
– **问题**：使用基本类型表示有特定含义的数据
– **处理**：使用小对象替代基本类型
– **示例**：用PhoneNumber类替代表示电话的字符串
## 重构过程原则
### 1. 小步重构
– 每次只做一个小改动，然后测试
– 频繁提交，保持代码随时可工作
### 2. 测试保障
– 重构前确保有足够的测试覆盖
– 每次修改后运行测试确保行为不变
### 3. 代码审查
– 重构后进行代码审查，确保质量
– 分享重构经验，提高团队能力
## 代码可读性优化
### 1. 命名约定
– 使用有意义的、描述性的名称
– 遵循项目或语言的命名规范
– 避免缩写和单字母变量（除非是约定俗成的，如循环中的i）
### 2. 代码组织
– 相关代码应该放在一起
– 函数应该只做一件事
– 保持适当的抽象层次
### 3. 注释与文档
– 注释应该解释为什么，而不是做什么
– 为公共API提供清晰的文档
– 更新注释以反映代码变化
## 性能相关重构
### 1. 内存优化
– 避免不必要的对象创建
– 及时释放不再需要的资源
– 注意内存泄漏问题
### 2. 计算优化
– 避免重复计算
– 使用适当的数据结构和算法
– 延迟计算直到必要时
### 3. 并行优化
– 识别可并行化的任务
– 避免不必要的同步
– 注意线程安全问题
2.2.2 项目规则
基于“6A工作流执行规则”，通过文档先行、任务递归的方式，让AI按照专业项目管理流程执行，将模糊需求逐步转化为可交付的代码。项目规则对于不同智能体都有效。
```markdown
# 6A工作流执行规范
## 前言
本规范定义了一套结构化的6阶段软件开发流程（Align→Architect→Atomize→Approve→Automate→Assess），通过严格的文档驱动和自动化检查机制，确保项目从需求到交付的全过程质量可控。
—
## 阶段1: Align（需求对齐）
**目标**：将模糊需求转化为精确规范
### 执行流程
1. **项目上下文分析**
– 分析现有：项目结构/技术栈/架构模式/依赖关系
– 检查已有：代码规范/文档/业务域模型
2. **需求确认文档**
```
docs/[task_name]/ALIGNMENT_[task_name].md
├── 原始需求
├── 任务边界（Scope）
├── 业务理解（现有系统）
└── 待澄清问题（优先级排序）
```
3. **智能决策策略**
– 自动识别歧义点
– 生成结构化问题清单（按优先级排序）
– 基于以下要素决策：
– 现有项目内容（70%）
– 类似工程案例（20%）
– 行业通用方案（10%）
4. **关键决策干预**
– 当存在以下情况时中断：
– 人员倾向性需求
– 技术方案冲突
– 架构兼容性问题
5. **最终共识产出**
```
docs/[task_name]/CONSENSUS_[task_name].md
├── 验收标准（SMART原则）
├── 技术实现方案（含架构约束）
└── 风险控制清单
```
### 质量标准
✅ 需求边界无二义性
✅ 技术方案与现有架构兼容
✅ 所有关键假设均有验证依据
—
## 阶段2: Architect（系统设计）
**目标**：生成可执行的技术方案
### 设计文档规范
```
docs/[task_name]/DESIGN_[task_name].md
├── 架构图（Mermaid语法）
├── 分层设计（核心组件+依赖）
├── 接口契约（Swagger格式）
└── 异常处理策略
```
### 核心原则
▸ **克制设计**：严格限定在共识范围内
▸ **一致性**：复用率需≥80%现有组件
▸ **可验证性**：每个模块需定义验证方式
### 质量检查
🔍 架构图经过可行性验证
🔍 接口定义覆盖所有业务场景
🔍 无隐性技术债务引入
—
## 阶段3: Atomize（任务分解）
**目标**：生成原子级开发任务
### 任务文档模板
```
docs/[task_name]/TASK_[task_name].md
├── 输入契约（前置依赖/环境要求）
├── 输出标准（可验证产物）
├── 技术约束（框架/工具限定）
└── 依赖关系图（Mermaid语法）
```
### 拆分原则
1. **原子性**：每个任务应满足：
– 独立编译/测试
– 实现时长≤4小时
– 明确输入输出
2. **可视化**：生成任务依赖图，确保：
– 无循环依赖
– 关键路径标识
—
## 阶段4: Approve（方案审批）
**目标**：人工验证可执行性
### 审查清单
| 维度 | 检查要点 |
|————|—————————–|
| 完整性 | 覆盖所有CONSENSUS需求 |
| 一致性 | 与ALIGNMENT文档无冲突 |
| 可测性 | 每个任务有明确验收标准 |
### 审批通过标准
📌 所有TODO标记已解决
📌 风险评级≤中等
📌 测试方案已就绪
—
## 阶段5: Automate（自动化实施）
**目标**：高质量代码交付
### 执行规范
1. **代码标准**
– 风格一致性（通过ESLint/Checkstyle）
– 复杂度控制（Cyclomatic≤10）
– 敏感信息隔离（.env管理）
2. **异常处理**
```mermaid
graph TD
A[执行失败] –> B{是否自主解决?}
B –>|是| C[记录问题并重试]
B –>|否| D[中断并生成ISSUE报告]
```
3. **文档同步**
– 代码变更需同步更新：
– 接口文档
– 测试用例
– 部署手册
—
## 阶段6: Assess（交付评估）
**目标**：闭环质量验证
### 验收流程
1. **自动化检查**
```bash
# 执行验证套件
./verify.sh –full –task=[task_name]
```
2. **交付产物**
```
docs/[task_name]/FINAL_[task_name].md
├── 性能基准测试报告
├── 代码质量扫描结果
└── 待办事项清单（TODO_*.md）
```
3. **质量KPI**
| 指标 | 合格阈值 |
|—————|———|
| 代码覆盖率 | ≥85% |
| 静态扫描警告 | ≤5 |
| API响应延时 | ≤300ms |
2.2.3 规则优先级
规则优先级：用户输入 > 自定义智能体的提示词(角色身份定义) > user_rules.md > project_rules.md
ps:如果这些规则相互矛盾或覆盖，模型可能会产生困惑。
三、常见问题
3.1 历史对话记录导致模型输出冲突
建议新创建对话解决。就像一个类中只解决一种问题，在侧边栏的AI对话框中一个会话内建议询问一种类型的问题。
3.2 如何查看"6A工作流"生成的文档
需求对齐、功能设计阶段最好进行审查，确保AI理解的功能内容和需求一致。
四、文章总结
大模型AI的使用可以很简单，但是在现有情况下想要通过AI完成复杂项目，就需要学习掌握更深层次的应用。现在主流对AI工具的应用从传统"提示词"工程，转变为对"上下文"工程。“上下文”工程包括历史对话记录、文档参考、系统预设角色等，构成模型理解当前请求的背景框架。
因为现在大模型Token容量变大，可支持更长的上下文内容，给AI的输入内容也更加丰富。同时根据提示词工程，给AI设定范围边界，让其按照指定的工作流输出。
引用参考：
Docs
Docs
