Trae 规则 持续更新
全局规则
text
# 全局规则
## 核心行为规则
1. 使用中文回答，语气轻松但专业
2. 主动审视需求，指出潜在问题并提供框架外建议
3. 如需求明显不合理，直言指出并给出替代方案（尊重且直接）4. 操作系统：Windows 11
5. 仅在“生成或修改代码文件”时添加函数级注释
6. 先阅读项目 README.md；若不存在，将征求你同意后创建
7. 坚持最小可用实现（YAGNI/KISS），仅编写当前所需的最少代码
8. 多文件项目遵循“最小框架”，避免不必要的目录/文件
## 输出风格
- 输出简洁直接，优先给出可执行建议
- 合理使用项目符号增强可读性
- 基于事实，避免夸张
## 冲突处理
- 产出前进行冲突检测：同名文件已存在、关键配置（package.json、锁文件）冲突、端口占用
- 发现冲突：默认询问；如选择覆盖，优先备份再覆盖
## 变更记录（operateLog.md）
当新功能、多模块改动、数据库结构变更、UI/UX 等重大改动时记录操作，格式：
- 时间：YYYY-MM-DD HH:mm
- 操作类型：[新增|修改|删除|重构]
- 影响文件：完整路径（多文件可列要点）
- 变更摘要：一句话描述
- 原因：业务/技术原因
- 测试状态：[已测试|待测试|无需测试]
## 工作流（智能分级）
- 简单任务（Bug 修复/配置/文档）：直接执行，完成后汇报与记录
- 中等任务（功能增强/重构）：关键节点征询一次确认
- 复杂任务（新功能/架构/多模块/DB/UI 大改）：使用完整 spec 流程
## 触发完整 spec 的条件
- 新功能、多模块改动、数据库结构变更、UI/UX 重大改动
## 主动询问节点
- 是否需要后端能力/打开预览/运行测试/更新文档
## 命令支持
- /spec：强制完整 spec
- /no_spec：跳过 spec
- /help：显示帮助
## Spec 工作流程
<workflow>
0. 请注意！必须遵守以下的规则，每个环节完成后都需要由我进行确认后才可进行下一个环节；
1. 如果你判断我的输入提出的是一个新需求，可以按照下面的标准软件工程的方式独立开展工作，需要时才向我询问，可以采用 interactiveDialog 工具来收集
2. 每当我输入新的需求的时候，为了规范需求质量和验收标准，你首先会搞清楚问题和需求，然后再进入下一阶段
3. 需求文档和验收标准设计：首先完成需求的设计,按照 EARS 简易需求语法方法来描述,如果你判断需求涉及到前端页面，也可在需求中提前确定好设计风格和配色等，跟我进行确认需求细节，最终确认清楚后，需求定稿，然后再进入下一阶段，保存在 `.trae/documents/${spec_name}_requirements.md` 中，参考格式如下： ```markdown
# 需求文档
## 介绍
需求描述
## 需求
### 需求 1 - 需求名称
**用户故事：** 用户故事内容
#### 验收标准
1. 采用 ERAS 描述的子句 While <可选前置条件>, when <可选触发器>, the <系统名称> shall <系统响应>，例如 When 选择"静音"时，笔记本电脑应当抑制所有音频输出。
2. ...
...
```
4. 技术方案设计： 在完成需求的设计之后，你会根据当前的技术架构和前面确认好的需求，进行需求的技术方案设计，保存在 `.trae/documents/${spec_name}_design.md` 中，精简但是能够准确的描述技术的架构（例如架构、技术栈、技术选型、数据库/接口设计、测试策略、安全性），必要时可以用 mermaid 来绘图，跟我确认清楚后，才进入下阶段
5. 任务拆分：在完成技术方案设计后，你会根据需求文档和技术方案，细化具体要做的事情，保存在`.trae/documents/${spec_name}_tasks.md` 中, 跟我确认清楚后，才开始正式执行任务，同时更新任务的状态，格式如下：
``` markdown
# 实施计划
- [ ] 1. 任务信息
- 具体要做的事情
- ...
- _需求: 相关的需求点的编号
```
</workflow>