Trae作为一款实用工具，虽然功能强大，但在兼容OpenSpec这类编程规范时仍存在局限性。经过多次实验和调整，最终探索出一种可行的替代方案，实际测试表明其效果令人满意。

        TRAE工具下载官网：

TRAE - The Real AI Engineer | TRAE - The Real AI Engineerhttps://www.trae.cn/        OpenSpec工具下载地址：        Fission-AI/OpenSpec: Spec-driven development (SDD) for AI coding assistants.https://github.com/Fission-AI/OpenSpec

具体操作如下：

1. 在.trae/rule创建以下几个文件，并将匹配的复制进相对应的位置

openspec-apply.md

# OpenSpec Apply 工作流规则

实现已批准的 OpenSpec 变更并保持任务同步。

## 准则

- 优先采用简单、最小化的实现方案，只在明确需要时才增加复杂度
- 保持变更范围紧密聚焦于请求的目标
- 如需了解 OpenSpec 的额外约定或说明，请参考 `openspec/AGENTS.md`

## 步骤

将这些步骤作为 TODO 跟踪，逐一完成：

1. 阅读 `changes/<id>/proposal.md`、`design.md`（如有）和 `tasks.md`，确认范围和验收标准

2. 按顺序完成任务，保持编辑最小化并聚焦于请求的变更

3. 在更新状态前确认完成——确保 `tasks.md` 中的每一项都已完成

4. 所有工作完成后更新检查清单，使每个任务都标记为 `- [x]` 并反映实际情况

5. 需要额外上下文时参考 `openspec list` 或 `openspec show <item>`

## 参考命令

- 实现时如需从提案中获取额外上下文，使用 `openspec show <id> --json --deltas-only`

openspec-archive.md

# OpenSpec Archive 工作流规则

归档已部署的 OpenSpec 变更并更新 specs。

## 准则

- 优先采用简单、最小化的实现方案，只在明确需要时才增加复杂度
- 保持变更范围紧密聚焦于请求的目标
- 如需了解 OpenSpec 的额外约定或说明，请参考 `openspec/AGENTS.md`

## 步骤

1. **确定要归档的变更 ID**：
   - 如果提示中已包含特定的变更 ID（例如在 `<ChangeId>` 块中由斜杠命令参数填充），在去除空格后使用该值
   - 如果对话中松散地引用了变更（例如通过标题或摘要），运行 `openspec list` 找出可能的 ID，分享相关候选项，并确认用户的意图
   - 否则，查看对话，运行 `openspec list`，并询问用户要归档哪个变更；在继续之前等待确认的变更 ID
   - 如果仍然无法确定单一的变更 ID，停止并告知用户目前无法归档任何内容

2. 通过运行 `openspec list`（或 `openspec show <id>`）验证变更 ID，如果变更缺失、已归档或未准备好归档则停止

3. 运行 `openspec archive <id> --yes`，让 CLI 移动变更并应用 spec 更新而无需提示（仅对纯工具类工作使用 `--skip-specs`）

4. 查看命令输出，确认目标 specs 已更新且变更已落入 `changes/archive/`

5. 使用 `openspec validate --strict` 验证，如有异常使用 `openspec show <id>` 检查

## 参考命令

- 归档前使用 `openspec list` 确认变更 ID
- 使用 `openspec list --specs` 检查刷新后的 specs，在交接前解决任何验证问题

openspec-proposal.md
 

# OpenSpec Proposal 工作流规则

创建新的 OpenSpec 变更提案并进行严格验证。

## 准则

- 优先采用简单、最小化的实现方案，只在明确需要时才增加复杂度
- 保持变更范围紧密聚焦于请求的目标
- 如需了解 OpenSpec 的额外约定或说明，请参考 `openspec/AGENTS.md`
- 识别任何模糊或不明确的细节，在编辑文件之前提出必要的后续问题
- **提案阶段不要编写任何代码**。只创建设计文档（proposal.md、tasks.md、design.md 和 spec deltas）。实现在批准后的 apply 阶段进行

## 步骤

1. 查阅 `openspec/project.md`，运行 `openspec list` 和 `openspec list --specs`，检查相关代码或文档（如通过 `rg`/`ls`），以当前行为为基础制定提案；记录任何需要澄清的空白点

2. 选择一个唯一的动词开头的 `change-id`，在 `openspec/changes/<id>/` 下创建 `proposal.md`、`tasks.md` 和 `design.md`（如需要）

3. 将变更映射为具体的能力或需求，将多范围的工作拆分为具有明确关系和顺序的独立 spec deltas

4. 当解决方案跨越多个系统、引入新模式或需要在提交 specs 前进行权衡讨论时，在 `design.md` 中记录架构推理

5. 在 `changes/<id>/specs/<capability>/spec.md` 中草拟 spec deltas（每个能力一个文件夹），使用 `## ADDED|MODIFIED|REMOVED Requirements`，每个需求至少包含一个 `#### Scenario:`，并在相关时交叉引用相关能力

6. 将 `tasks.md` 草拟为有序的小型可验证工作项列表，能够交付用户可见的进展，包括验证（测试、工具），并突出依赖关系或可并行化的工作

7. 使用 `openspec validate <id> --strict` 验证，在分享提案前解决所有问题

## 参考命令

- 验证失败时使用 `openspec show <id> --json --deltas-only` 或 `openspec show <spec> --type spec` 检查详情
- 编写新需求前使用 `rg -n "Requirement:|Scenario:" openspec/specs` 搜索现有需求
- 使用 `rg <keyword>`、`ls` 或直接读取文件探索代码库，确保提案与当前实现现实一致

project_rules.md

# OpenSpec 项目规则

## 通用准则 (Guardrails)

- 优先采用简单、最小化的实现方案，只在明确需要时才增加复杂度
- 保持变更范围紧密聚焦于请求的目标
- 如需了解 OpenSpec 的额外约定或说明，请参考 `openspec/AGENTS.md`（位于 `openspec/` 目录下，可运行 `ls openspec` 或 `openspec update` 查看）

## 代码风格

- 实现应当最小化且聚焦
- 在编辑文件时保持变更范围紧凑
- 完成所有工作后再更新状态

## OpenSpec CLI 命令参考

常用命令：
- `openspec list` - 列出所有变更
- `openspec list --specs` - 列出所有规格文档
- `openspec show <id>` - 显示指定变更详情
- `openspec show <id> --json --deltas-only` - 以 JSON 格式显示变更增量
- `openspec show <spec> --type spec` - 显示规格文档
- `openspec validate <id> --strict` - 严格验证变更
- `openspec archive <id> --yes` - 归档变更

## 搜索与探索

- 使用 `rg <keyword>` 搜索代码库
- 使用 `rg -n "Requirement:|Scenario:" openspec/specs` 搜索现有需求
- 使用 `ls` 或直接读取文件了解当前实现

2. 确保项目有 OpenSpec 结构（如果没有需要初始化）

your-project/
├── .trae/
│   └── rules/
│       ├── project_rules.md
│       ├── openspec-proposal.md
│       ├── openspec-apply.md
│       └── openspec-archive.md
├── openspec/
│   ├── project.md          # 项目说明
│   ├── AGENTS.md           # AI 约定
│   ├── specs/              # 规格文档
│   └── changes/            # 变更记录
└── src/                    # 你的代码目录

3. 在Trae中打开项目

用 Trae IDE 打开你的项目文件夹。

4. 使用规则修改指定文件夹

假设你要修改 `src/components/` 这个文件夹下的内容：

 场景 1：创建新功能提案

在 Trae 对话框中输入：

#openspec-proposal 我要修改 src/components/ 文件夹，添加一个 UserProfile 组件，要求：
1. 显示用户头像、名称、邮箱
2. 支持编辑模式
3. 使用 React + TypeScript

AI 会：

• 创建 openspec/changes/add-user-profile/ 目录
• 生成 proposal.md、tasks.md、design.md
• 不会写代码，只做设计

场景 2：实现变更

提案确认后，输入：

#openspec-apply 实现 add-user-profile，修改 src/components/ 文件夹

AI 会：

• 读取提案文档
• 在 src/components/ 下创建/修改文件
• 按 tasks.md 顺序完成任务
• 更新任务状态

场景 3：直接修改（不走完整流程）

如果是小改动，可以只用通用规则：

#project_rules 请修改 src/components/Button.tsx，添加 loading 状态支持

实际示例对话

你：#openspec-proposal 我要重构 src/utils/ 文件夹，将所有工具函数改为 TypeScript 并添加单元测试

AI：好的，我来创建提案...

    1. 检查 openspec/project.md 了解项目背景
    2. 运行 openspec list 查看现有变更
    3. 扫描 src/utils/ 了解当前文件结构
    
    已创建 openspec/changes/refactor-utils-typescript/
    - proposal.md: 重构方案说明
    - tasks.md: 
      - [ ] 将 helpers.js 转换为 helpers.ts
      - [ ] 将 validators.js 转换为 validators.ts
      - [ ] 添加类型定义
      - [ ] 编写单元测试
    - design.md: 类型设计方案
    
    已通过 openspec validate refactor-utils-typescript --strict

你：#openspec-apply 实现 refactor-utils-typescript

AI：好的，开始实现...

    阅读 changes/refactor-utils-typescript/tasks.md
    
    任务 1: 将 helpers.js 转换为 helpers.ts
    [修改文件...]
    
    任务 2: 将 validators.js 转换为 validators.ts
    [修改文件...]
    
    ...
    
    所有任务完成，tasks.md 已更新

你：#openspec-archive 归档 refactor-utils-typescript

AI：好的，归档变更...
    
    运行 openspec archive refactor-utils-typescript --yes
    变更已移至 changes/archive/
    验证通过