OpenSpec + Superpowers 实战：规范驱动开发(SDD)指南

本文基于内部培训内容整理，结合 OpenSpec 框架与 Superpowers 技能系统，带你掌握下一代 AI 辅助开发范式。

---

一、为什么需要规范驱动开发(SDD)？

1.1 传统开发模式的痛点

在现代 AI 辅助开发中，开发者经常面临以下问题：

痛点	具体表现	后果
需求漂移	在聊天中讨论需求，越说越多，最后偏离最初目标	功能与预期不符
上下文丢失	换会话或重启后，之前的讨论全部丢失	重复沟通成本高
实现不可预测	AI 理解 A，做出来却是 B，反复修改	时间浪费，士气低落
缺乏文档	代码写了，但设计思路和决策过程没有记录	维护困难，知识断层

1.2 SDD 的核心理念

Spec-Driven Development（规范驱动开发，简称 SDD） 是一种新的软件开发范式，其核心思想是：

"在写代码之前，先与 AI 对齐思路------把要做什么、为什么要做、怎么做都写成规范的文档，然后再让 AI 基于这些文档去实现。"

SDD 的关键优势：

• ✅ 可预测性：AI 的输出基于明确的规范，减少"做出来不对"的情况
• ✅ 可维护性：每个功能都有完整的文档记录，便于后续迭代
• ✅ 可协作性：团队成员可以基于规范进行异步协作
• ✅ 可追溯性：从需求到实现再到测试，全程可追踪

1.3 OpenSpec：SDD 的开源实践框架

OpenSpec 是 Fission-AI 团队开源的 SDD 框架实现，它将 SDD 理念落地为一套可操作的流程和工具。

OpenSpec 的核心特点：

特点	说明
轻量级	基于 Node.js，全局安装即可使用，零配置上手
工具无关	支持 25+ 种 AI 编程助手（Claude、GPT、Cursor、Copilot 等）
灵活迭代	没有繁琐的流程，随时可以调整规范
棕色地带友好	特别适合在已有代码库上进行功能添加和改造
可扩展	从个人项目到企业级团队都能适用

---

二、OpenSpec 核心工作流程详解

OpenSpec 的工作流程可以用 "提案 → 应用 → 归档" 三个环节来概括，形成一个完整的开发闭环。

2.1 第一步：PROPOSE（提案）

当你想要开发一个新功能时，首先使用 /opsx:propose 命令：

# 在你的项目目录中
/opsx:propose "添加深色模式支持"

AI 会为你创建一个规范目录 openspec/changes/add-dark-mode/，包含以下文件：

openspec/
└── changes/
    └── add-dark-mode/
        ├── proposal.md       # 提案说明：为什么要做这个功能
        ├── specs/
        │   └── *.md          # 需求规格：功能要求、验收标准、测试场景
        ├── design.md         # 技术设计：架构、接口、数据模型
        └── tasks.md          # 任务清单：具体实施步骤

每个文件的作用：

文件	作用	内容示例
proposal.md	阐明为什么需要这个功能	用户反馈、业务价值、竞品分析
specs/	明确功能的具体要求	用户故事、验收标准、边界条件
design.md	描述技术实现方案	架构图、接口定义、数据库设计
tasks.md	拆解具体实施步骤	开发任务、测试任务、部署任务

2.2 第二步：APPLY（应用）

当你审查并确认了规范无误后，执行 /opsx:apply 命令：

/opsx:apply

AI 会读取 tasks.md 中的任务清单，并逐个实现：

[✓] 1.1 添加主题上下文提供者
[✓] 1.2 创建主题切换组件
[✓] 2.1 添加 CSS 变量
[✓] 2.2 接入 localStorage 持久化
[✓] 3.1 编写单元测试
[✓] 3.2 验证手动切换和系统偏好跟随

在这个过程中，你可以：

• 随时打断并提出修改意见
• 要求 AI 解释某段代码的设计思路
• 让 AI 回滚到上一步重新实现
• 添加新的任务到 tasks.md 并让 AI 继续

2.3 第三步：ARCHIVE（归档）

功能开发完成后，执行 /opsx:archive 命令：

/opsx:archive

这会将该功能的所有文档归档到 openspec/changes/archive/ 目录：

openspec/
└── changes/
    └── archive/
        └── 2025-01-23-add-dark-mode/    # 按日期归档
            ├── proposal.md
            ├── specs/
            ├── design.md
            ├── tasks.md
            └── implementation-notes.md  # 实现过程中的备注

归档的好处：

• 📚 知识沉淀：每个功能的完整历史都被保存
• 🔍 便于追溯：以后需要了解某个功能时，可以快速找到当时的决策依据
• 📈 团队学习：新成员可以通过阅读归档文档快速了解项目历史
• 🔄 支持回滚：如果新功能有问题，可以根据归档文档快速回滚

2.4 完整工作流图示

渲染错误: Mermaid 渲染失败: Lexical error on line 3. Unrecognized text. ...psx:propose/] B --> C[创建规范文档 ----------------------^

---

三、Superpowers 技能系统与 OpenSpec 的结合

Superpowers 是一组用于增强 AI 编程助手能力的技能，可以与 OpenSpec 框架无缝结合，进一步提升开发效率和代码质量。

3.1 Superpowers 核心技能介绍

Superpowers 提供了以下关键技能：

技能名称	功能说明	与 OpenSpec 的结合点
brainstorming	创意构思，将想法转化为设计方案	在 /opsx:propose 阶段使用，帮助完善 proposal.md 和 design.md
writing-plans	编写详细实施计划	辅助生成和优化 tasks.md
test-driven-development	测试驱动开发	在 tasks.md 中集成测试任务，确保代码质量
systematic-debugging	系统化调试	在 /opsx:apply 阶段遇到问题时使用
requesting-code-review	请求代码审查	在 /opsx:archive 前进行代码审查

3.2 结合使用示例

下面展示如何在 OpenSpec 工作流的各个阶段结合 Superpowers 技能：

场景：开发一个用户登录功能

阶段 1：提案阶段（/opsx:propose）+ brainstorming 技能

开发者：/opsx:propose "添加用户登录功能"

AI（使用 brainstorming 技能）：
为了设计一个完善的登录功能，我需要了解一些信息：

1. 你希望支持哪些登录方式？
   A. 仅邮箱+密码
   B. 邮箱+密码 + 手机验证码
   C. 支持第三方登录（微信、Google、GitHub 等）
   D. 以上全部

2. 安全要求如何？
   A. 基础安全（密码加密存储）
   B. 中等安全（+ 登录失败限制）
   C. 高安全（+ 2FA、设备指纹、IP 限制）

3. 是否需要"记住我"功能？
   A. 需要
   B. 不需要

...（根据回答继续细化）...

阶段 2：规范文档生成 + writing-plans 技能

AI（使用 writing-plans 技能）：
基于我们的讨论，我为你生成了以下规范文档：

【proposal.md】
- 背景：用户反馈需要登录功能以保存个人设置
- 目标：实现安全、易用的邮箱+密码登录
- 成功标准：用户能顺利完成注册、登录、找回密码流程

【specs/login.md】
- 用户故事：作为用户，我希望能用邮箱登录，以便保存我的偏好设置
- 验收标准：
  1. 邮箱格式验证
  2. 密码强度检测（至少8位，包含大小写和数字）
  3. 登录失败3次后锁定账户15分钟
  4. ...

【design.md】
- 架构：前端 React + 后端 Node.js + PostgreSQL
- API 设计：
  POST /api/auth/register
  POST /api/auth/login
  POST /api/auth/forgot-password
  ...
- 数据库模型：users 表结构定义

【tasks.md】（由 writing-plans 技能生成详细任务清单）
阶段 1：后端 API 开发
- [ ] 1.1 设置数据库连接和 users 表
- [ ] 1.2 实现 /register API（含密码加密）
- [ ] 1.3 实现 /login API（含 JWT token）
- [ ] 1.4 实现 /forgot-password API（含邮件发送）
- [ ] 1.5 添加速率限制和安全中间件
- [ ] 1.6 编写后端单元测试

阶段 2：前端 UI 开发
- [ ] 2.1 创建登录页面组件
- [ ] 2.2 创建注册页面组件
- [ ] 2.3 创建忘记密码页面组件
- [ ] 2.4 实现表单验证逻辑
- [ ] 2.5 集成后端 API
- [ ] 2.6 添加加载状态和错误提示

阶段 3：测试和优化
- [ ] 3.1 编写端到端测试
- [ ] 3.2 进行安全审计
- [ ] 3.3 性能优化
- [ ] 3.4 浏览器兼容性测试

阶段 3：实施阶段（/opsx:apply）+ test-driven-development 技能

开发者：/opsx:apply

AI：开始执行任务清单...

[使用 test-driven-development 技能]

任务 1.1：设置数据库连接和 users 表

首先，让我编写测试：
```typescript
// tests/database.test.ts
describe('Database Setup', () => {
  it('should connect to PostgreSQL', async () => {
    const connected = await db.testConnection();
    expect(connected).toBe(true);
  });

  it('should create users table with correct schema', async () => {
    const schema = await db.getTableSchema('users');
    expect(schema).toHaveProperty('id');
    expect(schema).toHaveProperty('email');
    expect(schema).toHaveProperty('password_hash');
    expect(schema).toHaveProperty('created_at');
  });
});

现在运行测试（预期失败）：

npm test -- tests/database.test.ts
# 预期结果：FAIL - 数据库连接未配置

现在实现代码：

// src/database.ts
import { Pool } from 'pg';

const pool = new Pool({
  host: process.env.DB_HOST,
  port: parseInt(process.env.DB_PORT || '5432'),
  database: process.env.DB_NAME,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
});

export const db = {
  async testConnection(): Promise<boolean> {
    try {
      await pool.query('SELECT 1');
      return true;
    } catch {
      return false;
    }
  },

  async getTableSchema(tableName: string): Promise<Record<string, string>> {
    const result = await pool.query(`
      SELECT column_name, data_type
      FROM information_schema.columns
      WHERE table_name = $1
    `, [tableName]);

    const schema: Record<string, string> = {};
    for (const row of result.rows) {
      schema[row.column_name] = row.data_type;
    }
    return schema;
  },

  async createUsersTable(): Promise<void> {
    await pool.query(`
      CREATE TABLE IF NOT EXISTS users (
        id SERIAL PRIMARY KEY,
        email VARCHAR(255) UNIQUE NOT NULL,
        password_hash VARCHAR(255) NOT NULL,
        created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
      )
    `);
  }
};

再次运行测试（预期通过）：

npm test -- tests/database.test.ts
# 预期结果：PASS - 所有测试通过

✓ 任务 1.1 完成

**阶段 4：归档阶段（/opsx:archive）+ requesting-code-review 技能**

开发者：/opsx:archive

AI：开始归档流程...

使用 requesting-code-review 技能

---

代码审查请求

功能概述

实现了用户登录功能，包括邮箱注册、登录、忘记密码等完整流程。

变更内容

• 后端：用户认证 API（注册、登录、找回密码）
• 前端：登录页面 UI 组件
• 数据库：users 表设计和连接
• 安全：密码加密、JWT token、速率限制

测试覆盖

• 单元测试（后端 API）
• 集成测试（数据库操作）
• 端到端测试（待补充）

安全审查要点

• 密码使用 bcrypt 加密存储
• JWT token 设置合理过期时间
• 登录失败 3 次后锁定账户 15 分钟
• 所有 API 都有速率限制

文档更新

• API 文档
• 数据库设计文档
• 部署文档（待补充）

请审查以上变更，特别是：

1. 安全实现是否足够
2. 代码结构是否清晰
3. 是否有遗漏的边界情况

---

审查通过后，执行归档...

将文档归档到：openspec/changes/archive/2025-01-23-user-authentication/

归档内容：

✓ proposal.md

✓ specs/

✓ design.md

✓ tasks.md

✓ implementation-notes.md（自动生成，记录实现过程中的关键决策）

归档完成！项目记录已更新，随时准备开始下一个功能。

### 3.3 工作流程图

```mermaid
graph TD
    A[开始新功能] --> B[/opsx:propose/]
    B --> C[创建规范文档<br/>使用 brainstorming 技能]
    C --> D{审查规范}
    D -->|需要修改| E[调整规范]
    E --> D
    D -->|确认无误| F[/opsx:apply/]
    F --> G[AI 按 tasks.md 逐个实现<br/>使用 test-driven-development 技能]
    G --> H{实现完成?}
    H -->|还有任务| G
    H -->|全部完成| I[使用 requesting-code-review 技能<br/>进行代码审查]
    I --> J[/opsx:archive/]
    J --> K[归档到<br/>changes/archive/]
    K --> L[准备下一个功能]
    L --> A

    style B fill:#4CAF50,stroke:#333,stroke-width:2px
    style F fill:#2196F3,stroke:#333,stroke-width:2px
    style J fill:#FF9800,stroke:#333,stroke-width:2px

3.4 与 Superpowers 其他技能的深度结合

场景：开发过程中发现需要重构已有代码

开发者：在实现登录功能时，我发现现有的用户管理模块需要重构

AI：建议创建一个新的 OpenSpec 变更来处理重构

开发者：/opsx:propose "重构用户管理模块，支持新的认证流程"

AI：创建新的规范文档...

在重构过程中：

1. 使用 systematic-debugging 技能处理重构引入的问题
2. 使用 test-driven-development 技能确保重构后功能正常
3. 使用 requesting-code-review 技能让团队成员审查重构方案

重构完成后：

开发者：/opsx:archive

AI：将重构文档归档，更新项目记录

场景：复杂功能需要分解为多个子任务

开发者：/opsx:propose "实现完整的电商订单系统"

AI（使用 writing-plans 技能）：

这个系统比较复杂，我建议分解为以下几个子系统：

1. 商品管理模块
2. 购物车模块
3. 订单生成模块
4. 支付接口模块
5. 订单状态管理模块

让我们先为整个系统创建顶层规范，然后为每个模块创建独立的 OpenSpec 变更。

开发者：同意，开始创建顶层规范

AI：创建顶层 design.md，定义各模块的接口契约

然后依次执行：

/opsx:propose "实现商品管理模块"
/opsx:apply
/opsx:archive

/opsx:propose "实现购物车模块"
/opsx:apply
/opsx:archive

...

---

四、从传统开发到 OpenSpec + Superpowers 的迁移指南

4.1 评估现有项目

在引入 OpenSpec 之前，先评估当前项目的状态：

评估维度：

1. 项目规模
   - 小型项目（< 10 个模块）→ 轻量级使用
   - 中型项目（10-50 个模块）→ 标准使用
   - 大型项目（> 50 个模块）→ 完整使用 + 自定义扩展

2. 团队规模
   - 个人开发者 → 基础功能即可
   - 小团队（2-5人）→ 协作功能
   - 大团队（>5人）→ 完整功能 + 流程规范

3. 项目阶段
   - 新项目 → 从一开始就使用 OpenSpec
   - 进行中项目 → 从下一个功能开始使用
   - 遗留项目 → 先重构核心模块，再全面推广

4. 技术栈
   - 检查 OpenSpec 是否支持你的技术栈
   - 查看文档中的 supported-tools.md

4.2 渐进式迁移策略

阶段一：试点（1-2 周）

目标：在小范围内验证 OpenSpec 的有效性

步骤：
1. 选择 1-2 个新功能进行试点
2. 让 1-2 名团队成员使用 OpenSpec
3. 记录使用过程中的问题和反馈
4. 评估效果：开发效率、代码质量、团队满意度

成功标准：
- 试点功能按时完成
- 团队成员认为有价值
- 发现的问题有解决方案

阶段二：推广（1 个月）

目标：在团队范围内推广 OpenSpec

步骤：
1. 编写团队内部的 OpenSpec 使用规范
2. 组织培训，分享试点经验
3. 在新功能中强制使用 OpenSpec
4. 建立代码审查流程，检查 OpenSpec 文档
5. 收集反馈，持续优化流程

成功标准：
- 80% 以上的新功能使用 OpenSpec
- 团队成员熟练掌握
- 形成可复制的流程文档

阶段三：深化（持续）

目标：将 OpenSpec 融入团队文化

步骤：
1. 探索高级功能（如社区 schemas、自定义扩展）
2. 结合 Superpowers 其他技能，形成完整工作流
3. 贡献开源社区，分享经验
4. 建立度量体系，量化 OpenSpec 带来的价值
5. 持续优化，形成最佳实践

成功标准：
- OpenSpec 成为团队默认工作方式
- 形成可对外分享的案例和最佳实践
- 团队成员积极参与开源社区

4.3 常见问题与解决方案

问题一：团队抵触情绪

表现：
- "又要写文档，太麻烦了"
- "直接写代码更快"
- "AI 本来就能理解我"

原因分析：
- 习惯了旧的开发方式
- 没有看到 OpenSpec 的价值
- 学习曲线带来的短期效率下降

解决方案：
1. 从小处着手，先展示价值
   - 找一个容易出问题的功能
   - 用 OpenSpec 和不用对比演示
   - 让大家看到"做出来对"和"做出来不对"的区别

2. 降低使用门槛
   - 提供模板和示例
   - 编写快速上手指南
   - 安排结对编程，手把手教

3. 建立激励机制
   - 代码审查时关注 OpenSpec 使用
   - 分享会表彰使用好的案例
   - 将 OpenSpec 纳入绩效考核（适度）

4. 持续收集反馈并改进
   - 定期询问使用体验
   - 根据反馈调整流程
   - 让大家感受到自己的声音被听到

问题二：规范文档流于形式

表现：
- 文档写得敷衍，只有框架没有内容
- 文档写完后从不更新
- 实现和文档不一致

原因分析：
- 没有理解文档的真正价值
- 缺乏审查机制
- 变更时忘记同步更新

解决方案：
1. 建立文档质量标准
   - 定义每个文档的必含内容
   - 提供高质量示例
   - 编写文档编写指南

2. 代码审查时检查文档
   - 审查清单中加入文档检查项
   - 实现和文档不一致打回修改
   - 鼓励审查者提出文档改进建议

3. 建立文档更新机制
   - 变更流程中明确文档更新步骤
   - 使用工具检查实现和文档的差异
   - 定期（如每季度）审查和更新文档

4. 让文档产生实际价值
   - 新成员通过文档快速上手
   - 故障排查时参考设计文档
   - 对外分享时展示专业度

问题三：AI 实施阶段出错

表现：
- AI 没有按 tasks.md 执行
- 实现过程中出现意外错误
- 生成的代码不符合设计规范

原因分析：
- tasks.md 描述不够清晰
- AI 上下文理解偏差
- 复杂任务需要更多指导

解决方案：
1. 优化 tasks.md 的编写质量
   - 每个任务描述要具体、可验证
   - 提供输入输出示例
   - 明确验收标准

   ❌ 不好的例子：
   - [ ] 实现登录功能

   ✅ 好的例子：
   - [ ] 实现 POST /api/auth/login 接口
       - 接收 email 和 password 参数
       - 验证 email 格式
       - 查询数据库验证密码
       - 验证成功返回 JWT token
       - 验证失败返回 401 错误
       - 包含单元测试，覆盖成功和失败场景

2. 实施过程中保持沟通
   - 每个任务完成后让 AI 汇报进展
   - 发现问题立即指出并要求修正
   - 复杂任务可以要求 AI 先给出实现思路

3. 利用 Superpowers 技能
   - 使用 `systematic-debugging` 解决实施中的问题
   - 使用 `test-driven-development` 确保代码质量
   - 使用 `requesting-code-review` 让其他 AI 或人类审查代码

4. 建立回滚机制
   - 实施前确保代码已提交到版本控制
   - 重大问题可以回滚到上一步
   - 记录每次变更，方便追溯

问题四：团队协作时的冲突

表现：
- 多人同时修改同一个功能的规范
- 规范文档版本混乱
- 团队成员对规范理解不一致

原因分析：
- 缺乏协同编辑机制
- 版本控制不当
- 沟通不足

解决方案：
1. 使用版本控制管理规范文档
   - 将 openspec/ 目录纳入版本控制
   - 每次修改都提交，写明变更原因
   - 使用分支管理不同功能的规范

2. 建立协作规范
   - 一个人负责一个功能的完整流程
   - 需要协作时使用代码审查机制
   - 定期同步，确保大家对规范理解一致

3. 利用工具支持
   - 使用支持协同编辑的 Markdown 编辑器
   - 使用 Git 的合并请求（Pull Request）流程审查规范变更
   - 使用评论功能讨论规范中的问题

4. 建立沟通机制
   - 每日站会同步进展
   - 规范审查会议
   - 使用即时通讯工具快速沟通

---

五、最佳实践总结

5.1 规范编写最佳实践

1. 保持简洁
   - 每个文档控制在 500-1000 字以内
   - 使用 bullet points 代替大段文字
   - 能用图就不用表，能用表就不用文字

2. 具体可验证
   - 每个需求都有明确的验收标准
   - 每个任务都有可验证的输出
   - 避免模糊的描述如"性能要好"

3. 及时更新
   - 实现过程中发现规范问题立即更新
   - 功能上线后根据反馈调整规范
   - 定期（如每季度）审查和更新所有规范

4. 团队协作
   - 规范文档纳入版本控制
   - 重大变更通过代码审查机制
   - 建立规范编写的团队共识

5.2 AI 协作最佳实践

1. 明确指令
   - 给 AI 清晰、具体的任务描述
   - 提供必要的上下文和约束条件
   - 明确输出格式和验收标准

2. 分步实施
   - 复杂任务分解为小步骤
   - 每完成一步验证结果
   - 发现问题及时纠正

3. 善用技能
   - 根据场景选择合适的 Superpowers 技能
   - 技能组合使用效果更佳
   - 持续学习和实践新技能

4. 保持沟通
   - 与 AI 保持持续的对话
   - 及时反馈结果和期望
   - 建立有效的协作节奏

5.3 团队推广最佳实践

1. 从小处着手
   - 选择 1-2 个功能试点
   - 让愿意尝试的团队成员先用
   - 展示成功案例，建立信心

2. 降低门槛
   - 提供模板和示例
   - 编写快速上手指南
   - 安排培训和答疑

3. 建立规范
   - 编写团队内部的 OpenSpec 使用规范
   - 建立代码审查流程
   - 将 OpenSpec 纳入开发流程

4. 持续优化
   - 定期收集团队反馈
   - 根据反馈调整流程
   - 分享最佳实践和案例

5. 激励认可
   - 表彰使用好的团队和个人
   - 分享成功案例
   - 建立奖励机制

---

六、写在最后

OpenSpec 和 Superpowers 的结合，为我们提供了一种全新的 AI 辅助开发范式。它不仅仅是工具和技能的组合，更是一种思维方式的转变------从"直接写代码"到"先对齐思路再写代码"，从"碰运气"到"可预测"。

这种转变的价值在于：

• 对个人：提升开发效率，减少返工，让编码更有条理
• 对团队：建立共同语言，改善协作，沉淀团队知识
• 对项目：提高代码质量，降低维护成本，增强可扩展性

当然，任何新的工作方式都需要时间去适应。刚开始使用 OpenSpec 时，你可能会觉得"写文档好麻烦"、"直接写代码更快"。但随着实践的深入，你会发现：

前期花在规范上的时间，会在后期节省数倍的调试和返工时间。

最后，希望这篇指南能帮助你快速上手 OpenSpec 和 Superpowers，开启更高效、更愉悦的 AI 辅助开发之旅！

---

📌 OpenSpec 项目地址 ：https://github.com/Fission-AI/OpenSpec

📌 Superpowers 技能文档 ：https://github.com/superpowers/superpowers

📌 官方文档：https://openspec.dev/

有兴趣的朋友，点点关注。每天分享一个AI工具。

定义项目级别的集成规范，要求AI 在工作中必须遵守规矩。

创建OpenSpec+Superpowers rule：(openspec-superpowers.md)

文件存放目录：~/项目根目录/.claude/rules/openspec-superpowers.md

# OpenSpec + Superpowers 集成规范
## 实施前准备工作
1. 检查是否存在活跃的 `spec.md` 文件
2. 如果不存在，使用 `/opsx:new` 创建一个
3. 查看 `archived/` 目录中类似的过往实现
## 实施过程中
1. 遵循 Superpowers TDD 工作流：
- brainstorm → write-tests → implement → run-tests → code-review
2. 使用 `/opsx:continue` 更新 `spec.md` 中的实施决策
3. 保持规范与实际实施同步
## 实施完成后
1. 运行 Superpowers 代码审查
2. 使用 `/opsx:archive` 归档已完成的规范
3. 记录学习经验供将来参考
## 禁止事项
- 没有 spec.md 就进行实施
- 让 spec.md 与实际实施脱节
- 完成后跳过归档步骤

创建supperpowers rule: (supperpowers.md)

文件存放目录：~/项目根目录/.claude/rules/supperpowers.md

# Superpowers TDD 配置
## 强制性工作流
对于每个实施任务：
1. **优先探索**
- 编码前运行头脑风暴技能
- 理解现有代码库模式
- 识别潜在冲突
2. **TDD 循环**
- 首先编写失败的测试
- 实现最小代码以通过测试
- 如有需要进行重构
- 目标覆盖率 80%+
3. **代码审查**
- 实施后运行代码审查技能
- 处理所有 CRITICAL 和 HIGH 级别问题
- 记录任何接受的 MEDIUM 级别问题
## 质量门
- [ ] 所有测试通过
- [ ] 无语法错误
- [ ] 代码审查完成
- [ ] 规范/tasks.md 已更新