AI 编程工作流选型三件组合拳：Qode + OpenSpec + Superpowers 的 SDD 后端开发最佳实践一、需求背景1. Al Coding发展1.1第一阶段：智能补全AI介入

AI 编程工作流选型三件组合拳：Qode + OpenSpec + Superpowers 的 SDD 后端开发最佳实践

一、需求背景

1. Al Coding发展

1.1第一阶段：智能补全

AI介入编程的最初形态。以GitHub Copilot为代表，模型基于光标位置的上下文进行预测，实时给出代码建议。

本质：更聪明的自动补全一一快，但浅。无法理解跨文件的复杂逻辑。

1.2第二阶段：对话式编程

大模型能力飞跃，AI开始具备理解复杂指令、维持多轮对话、处理超长上下文的能力，能够从零搭建完整的功能模块。

本质：从补全一行代码，进化到生成一整个函数甚至模块。开发者的输入方式从"写代码"变成了"说需求"。

1.3第三阶段：氛围编程（VibeCoding）

开发者不再关心代码本身，只需用自然语言描述意图，AI端到端地输出实现。人类的角色从"编码者”转变为"指导者"和”验收者”。

优势：对个人开发者或小型团队而言，能将灵感极速转化为可运行原型，大幅压缩创意到落地的周期。

瓶颈：在规模化实践中，这一范式暴露出两个结构性问题：

1.生成质量不稳定一AI产出的代码经常"形似而神非"：语法正确、结构合理，但逻辑不可用。开发者被迫花大量时间逐段排查和修补，提效反成负担。

2.缺乏上下文认知一在企业级系统中，代码背后是多年积累的架构约束、技术债务和定制化业务逻辑。即使资深工程师换到新团队也需要漫长的上手期。A对这些隐性知识一无所知，生成的代码往往无法融入现有体系一一表面光鲜，实则不可集成。

在复杂协作场景下，AI的定位应是增强者而非替代者一一加速理解、辅助编码、提早暴露风险，但无法独自交付。

1.4第四阶段：规范驱动编程（SpecCoding）

根本性的范式转换：从"代码优先"走向"规范优先”。

核心思路是将形式化、可执行的规范确立为开发的唯一真实来源。AI不再是自由发挥的生成器，而是规范的忠实执行者一一在明确的边界和约束内产出代码。

本质：规范驱动、结构化流程、团队可协作、质量可追溯。

2. SDD落地实战与思考

团队引入 AI 编程工具后，经历了从“效率飙升”到“技术债暴雷”的过山车。其根源在于“氛围编程”（Vibe Coding）模式——用自然语言简单描述需求，让 AI 直接生成代码。这种模式虽然初期见效快，却导致设计共识随着长对话消失，AI 缺乏主动写测试和维护工程质量的纪律，最终演变为“AI 制造技术债”。这种“你提需求 → AI 写代码 → 发现不对 → 反复修改”的循环，就是典型的“氛围编程”。它最大的问题在于，设计意图完全依赖脆弱的、容易丢失的对话上下文，而工程纪律则完全依赖开发者的个人经验去约束 AI。AI 能秒出几百行代码，但这些代码真的是我们想要的吗？它符合设计意图吗？有没有超出范围？有没有遗漏场景？破局的关键，是从“代码优先”转向“规范先行”。

2025 年 10 月，一个名为 Superpowers 的插件上线 Claude Code 插件市场，五个月内斩获 107,000 GitHub stars、8,600 forks，成为开发者工具仓库史上增长最快的项目之一。与此同时，Fission AI 推出的 OpenSpec 也在 AI 编码圈掀起波澜——二者共同指向同一个命题：“AI 写代码”从来不是软件开发的难点，“写对代码”才是。

传统 AI 编程的“Vibe Coding”模式——靠直觉写 Prompt(提示)、反复修改、直到“看起来能跑通”——在企业级后端系统中根本走不通。AI 在长对话中会遗忘早期约束，brainstorm(头脑风暴) 中否决的方案可能在第 50 轮对话时被重新提出；/clear 释放上下文后，之前达成的共识全部丢失。AI 有能力写代码，但没有纪律维护工程质量——它不会主动先写测试，不会系统定位 bug 根因，也不会在写代码前检查 spec(规格)。

我们的破局点，是引入了 SDD（Specification Driven Development，规范驱动开发）。SDD 不是要抛弃 AI，而是要为它装上“导航仪”和“纪律手册”。它的核心思想极其简单却有力：先写一份机器和人都能理解的“说明书”（规范），再让 AI 严格按照说明书来生产代码。从此，规范成为项目唯一的、可信的事实来源（Single Source of Truth），代码只是规范的派生品。

SDD 到底是什么？核心理念与工作流拆解

SDD 的核心思想是：先写规范，后产代码。

如果把 AI 比作一支施工队，那么 SDD 就是在动工之前，先为它提供一份详尽、清晰的“工程图纸”，这份“图纸”就是 “规范”。

AI 不再“凭感觉”即兴创作，而是严格按照这份蓝图来施工，确保最终成果准确、可控。

一份高质量的规范通常会包括：

• 明确的需求与业务目标：不仅描述功能，也阐明其商业价值。

• 清晰的技术架构和约束：规定技术选型、系统边界与核心数据流。

• 具体的实现任务清单：将目标拆解为可被追踪、执行的具体步骤。

三位一体工具能力矩阵 OpenSpec+Superpowers+Qoder 核心定位规范定义、标准制定过程管控、质量保障代码落地、效能提升关键价值统一需求真相源，避免 AI 跑偏强制纪律约束，杜绝随意开发全自动执行，释放人力专注高价值产出物 proposal/design/specs/tasks

工具维度	OpenSpec	Superpowers	Qoder
核心定位	规范定义、标准制定	过程管控、质量保障	代码落地、效能提升
关键价值	统一需求真相源，避免AI跑偏	强制纪律约束，杜绝随意开发	全自动执行，释放人力专注高价值
产出物	proposal/design/specs/tasks文档	边界清单、微任务、测试用例	可运行代码、测试覆盖、注释

文档边界清单、微任务、测试用例可运行代码、测试覆盖、注释

SDD 核心工具能力详解：三位一体闭环体系

OpenSpec ：先写规范，再写代码

规范层｜管方向、定标准

🎯 核心定位

将模糊需求转化为结构化规格文档，统一「做什么、为什么、约束是什么、如何验收」，是 AI 开发的唯一真相源

📋 四大核心标准产物

• proposal.md：定义「为什么做」，记录商业价值、需求背景、目标范围、风险概述

• design.md：定义「怎么做」，包含技术选型、架构设计、核心流程、依赖关系、风险与降级方案

• specs/*.md：通过 GIVEN/WHEN/THEN 语法穷举业务场景、边界条件、异常流程

• tasks.md：拆解可落地、可勾选、可验收的最小开发任务

🚀 可执行指令体系

分步精细化模式：

• /opsx:explore - 探索模式，只讨论思路、不生成文档

• /opsx:propose - 生成提案与文档骨架

• /opsx:specs/design/tasks - 单独迭代更新对应模块

• /opsx:apply - 依据 tasks.md 逐条落地代码

• /opsx:verify - 校验代码与规范一致性

• /opsx:archive - 归档变更，合并至项目主规范基线

⚠️ 关键约束

模糊需求必须人工审查补全为精确规格，禁止模糊描述进入开发，避免 AI 随意生成、Token 浪费、逻辑跑偏

Superpowers：自动化最佳实践

纪律层｜管过程、控质量

🎯 核心定位

流程的质量锁与纪律锁，自动介入开发全流程，强制 AI 遵循标准化链路，杜绝跳过步骤、省略测试、遗漏边界

🎮 触发指令

基于已有设计文档，启用 Superpowers 规范开发

🔗 五大强制技能链（固定执行顺序）

1. Brainstorming（边界穷举）：主动追问边缘场景、异常情况、潜在风险，未确认完整边界不允许写代码

2. Writing-Plans（微任务拆解）：将大任务拆解为 2-5 分钟/步的微步骤，明确文件路径、代码示例、提交规范

3. TDD 测试先行（铁律）：严格遵循「先写测试、后写实现」，测试不通过禁止进入下一环节，永远先写测试，再写代码，用契约先行来防止过渡设计

4. Systematic Debugging（系统排错）：Bug 修复遵循「复现→隔离→修正→验证」四步法，禁止盲改

5. Code Review（自我审校）：开发完成后 AI 切换 QA 角色，自动审查代码规范、逻辑漏洞、安全风险

强制走一套结构化流程：头脑风暴 → 写计划 → TDD 执行 → 代码审查，它有个核心设计叫 SDD（Subagent-Driven Development，子代理驱动开发）每个任务由三个角色协作完成：

1. Implementer（实现者） — 写代码、写测试、跑测试

2. Spec Compliance Reviewer（规格审查员） — 逐行对比代码和规格是否一致

3. Code Quality Reviewer（质量审查员） — 规格通过后，审查代码质量

💎 核心价值

强制前置锁定需求风险，通过多轮追问规避后期返工，实现一次开发、零返工落地，解决 AI 开发「改不完的 Bug」死循环

Qoder

执行层｜管落地、提效能

🎯 核心定位

智能 Agent 执行载体，依托 Quest 模式承接规范与纪律，实现无人干预、全自动闭环

🔄 全自动执行流程

• 规范解析：基于 OpenSpec 规范自动解析业务意图

• 任务拆解：智能拆分复杂任务为可执行单元

• 代码生成：生成高质量、符合规范的业务代码

• 自测验证：自动运行测试，确保代码质量

• 提交归档：完成代码提交、PR 创建、变更归档

🏆 核心能力

• 无损落地：实现规范到代码的无损转化

• 智能适配：根据不同项目类型自动调整执行策略

• 状态持久：全流程状态追踪，支持断点续做

• 进度透明：实时展示执行进度，便于人工监控

📈 效能提升

• 开发效率：相比传统开发提升 3-5 倍

• 代码质量：通过规范约束实现质量内建

• 知识沉淀：执行过程自动形成可复用资产

• 团队协作：标准化执行降低沟通成本

openSpec安装和项目初始化

2.1 openSpec安装 需要 Node.js 20.19.0 或更⾼版本。

npm install -g @fission-ai/openspec@latest

2.2 Qoder ⼯作空间初始化

安装完毕后，在下面根目录下 运⾏ openspec init 命令开始执⾏⼯作流，初始化项⽬，开发环境选择 Qoder

安装好之后，观察项目变化，实际产生的效果如下

1._在.qoder/commands/opsx 目录下添加了四个项目级指令(参考 Qoder Commands 文档 https://docs.goder.com/zh/user-guide/commands)

2.添加了四个 skills，功能与四个指令完全对应

3.创建了 openspec 初始目录，此时可以在项目中使用 openspec 工作流。

Superpowers 工具安装下载路径

https://gitcode.com/GitHub_Trending/su/superpowers?utm_source=highlight_word_gitcode&word=superpowers&isLogin=1&from_link=cfed8e6f4f5cabcaf78199453a3f3fc1

4.2.1 安装 superpowers 到 Qoder

只使用 skills 能力，将 skills 拷贝到 .qoder/skills 下即可。

安装完毕后验证可以应用相关 skills。

二、SDD 规范驱动开发工作流

Phase 1：需求梳理 入口选择（两条路径可选）

路径A：/opsx:explore - 偏「理解现有系统」，读代码、梳理既有架构，需求探索（如果已有清晰 PRD 可跳过）,只是围绕需求，把需求讨论明白，可以反复和它对话，直到把需求完全理解到位之后，再进入下一步

将产品的原型截图和字段文档拖入对话，Explore 模式是只读思考伙伴——从截图提取页面结构、画 ASCII 图理清状态流转、不写代码，只输出理解。这一步投入 30 分钟澄清 需求业务理解当中不确定、业务流细节的等问题，远比编码阶段返工划算。

路径B：/brainstorming - 偏「设计新功能」，从零探索需求方案、对比权衡

Superpowers 自动进入 brainstorming 流程：探索项目结构 → 一次问一个问题澄清需求 → 提出 2-3 种方案 → 分段展示设计逐段确认 → 写入 docs/superpowers/specs/ 并 commit

通用纪律：

• 逐个提问，避免信息过载

• ✅/⏳标注机制：已确认打✅，待确认打⏳

• 结束前不能有⏳，所有疑问必须由用户拍板

Phase 2：建档（OpenSpec 工件生成）使用 OpenSpec Propose 一步到位生成结构化制品

执行指令：/opsx:propose 「功能名称」

架构师需回答什么关键要素 proposal.mdWhy / What 业务背景、价值、影响范围、Out of Scopedesign.md 关键技术决策与权衡架构决策、技术选型、风险点 specs.md 规格场景（WHEN / THEN）可执行的 QA 验收标准 tasks.md 任务清单 + 验收契约可并行任务、TDD

工件	回答什么	关键要素
proposal.md	Why / What	业务背景、价值、影响范围、Out of Scope
design.md	关键技术决策与权衡	架构决策、技术选型、风险点
specs.md	规格场景（WHEN / THEN）	可执行的QA验收标准
tasks.md	任务清单 + 验收契约	可并行任务、TDD第一层契约

第一层契约

关键改进：tasks.md 每条任务必须附验收契约（1-3 句 SHALL/MUST 断言）

Phase 3：写实施计划（可选）

执行指令：superpowers:writing-plans # 读取 tasks.md，产出 plan.md

架构师维度 tasks.mdplan.md 视角「做什么」任务清单「怎么做」实施路径粒度原子任务（2-5 分钟）阶段划分、依赖关系用途 OpenSpec 归档依据 Superpowers

维度	tasks.md	plan.md
视角	"做什么"任务清单	"怎么做"实施路径
粒度	原子任务（2-5分钟）	阶段划分、依赖关系
用途	OpenSpec归档依据	Superpowers执行蓝图

Phase 4：并行开发执行

执行指令：superpowers:subagent-driven-development

并行执行机制：

1. 根据 plan.md 划分并行阶段

2. 每个阶段启动多个子代理并行执行

3. 每个子代理内部遵循严格 TDD 循环

4. 返回完成报告，主线勾选 tasks

TDD 三层嵌入：

1. 契约层 - tasks.md 中的验收契约

2. 实现层 - 子代理按 RED-GREEN-REFACTOR 循环

3. 集成层 - 跨模块联调验证

Phase 5：自动化验证

执行指令：superpowers:verification-before-completion

验证内容：

• ✅ 单元测试通过率

• ✅ 集成测试覆盖

• ✅ Lint 规范检查

• ✅ 构建流程通过

• ✅ 性能基准测试

Phase 6：代码审查

执行：code-reviewer 子代理全量审查

审查重点：

• P0 问题：必须修复（安全漏洞、功能错误）

• P1 问题：强烈建议修复（代码质量、可维护性）

• P2 问题：可延迟修复（代码风格、注释）

Phase 7：归档与基线升级

执行指令：/opsx:verify → /opsx:archive

归档流程：

1. 验证代码与规格一致性

2. 同步增量 specs 到项目主规范

3. 更新 CHANGELOG 记录变更

4. 升级项目规范基线版本

三、SDD项目实战一：从0到1 需求开发

先说清楚一个事实：OpenSpec 和 Superpowers 是两个独立开源项目，彼此不知道对方的存在。 它们之间没有 API 集成，也没有文件格式的约定。

两个工具各自都有完整的闭环：

OpenSpec 的闭环：/opsx:propose → /opsx:apply（自己实现代码）→ /opsx:archive(归档)

Superpowers 的闭环：brainstorming（自动触发）→ writing-plans（自动跳转）→ subagent-driven-development（自动执行）→ finishing-a-development-branch（收尾）

所谓"联动"，是架构师把两个闭环串起来——用 OpenSpec 做规格定义（它擅长这个），用 Superpowers 做代码实现（它擅长 TDD 和代码审查），跳过 OpenSpec 自己的 /opsx:apply。

项目实操：

我们目标是体验一遍默认工作流，以一个简单项目开发和迭代为例：开发一个基于IOT用户设备管理平台，完成后迭代用户登录模块。

Step1 OpenSpec：锁定意图，管理变更

架构师要做的第一件事，就是告诉 OpenSpec 你想做什么

/opsx:explore D:\kuntingProject 是一个基于物联网iot用户设备管理系统平台，目前系统前后台已经已经实现：用户登录、设备管理、用户管理功能，我想添加一个系统设置-系统角色管理-权限管理 功能，这里可以给创建不同的系统角色（超管、管理员、运营商），每个角色分配不同的页面及按钮权限，超管及管理员可以创建系统角色的增删改查及分配用户角色

/opsx:propose D:\kuntingProject 是一个基于物联网iot用户设备管理系统平台，目前该文件下已经有基于spring boot微服务架构的后端系统：common是公共基础模块组件库、 gateway(9000端口)为Spring Cloud Gateway 网关层应用服务、sysUserPermission (9001)为用户权限服务、deviceManager (9002)为设备管理服务，webView为前端项目，web前端基于Vue3+Vite+TypeScript+Element Plus开发web界面，请在webView文件夹下先初始化前端项目，页面端需实现用户登录、设备查询功能

这条命令执行后，OpenSpec 会自动生成一套完整的规划文档。

先看 proposal.md 的 规划与提案 关键内容：

然后是 specs/ 目录下的需求design.md设计文档：

最后是 tasks.md 拆分好的任务清单：

审查设计文档时候发现，前端通过 Vite DevServer 代理 /api → Gateway(9000)，避免跨域问题，跟我系统实现方式有所出入，可以通过指令告诉Qoder进行修改specs/ 目录下对应的 proposal.md、design.md、tasks.md

微服务（如 sys-user-permission、device-manager）启动并注册到 Nacos 服务注册中心，网关就会自动为它们生成路由规则 实现内部微服务调用。访问路径：默认路径格式为 /{服务名}/{请求路径}（例如：http://localhost:9000/sys-user-permission/user/list），不需要对路径做特殊重写或复杂的断言过滤。前端访问不需要通过 Vite DevServer 代理 /api 请调整tasks.md，确保

Step 2：技术规划与桥接

需求文档就绪后，该进入实现了。这里有个选择：你可以直接执行 /opsx:apply 让 OpenSpec 自己实现代码。但如果你想要严格的 TDD 流程和代码审查，就轮到 Superpowers 接手了。

触发 Superpowers 的 brainstorming：在同一个 Qode 会话中，直接告诉 AI 你的实现意图。Superpowers 安装后会自动注入一个 SessionStart 钩子，AI 在检测到你要做创造性工作时，会自动激活 brainstorming 技能——不需要手动输入任何命令。

方式一：从 /opsx:explore ->创建 proposal-> 需求审查后直接进入/brainstorming

/brainstorming 请帮我实现上述任务列逐步推进表，我已经用 OpenSpec 定义好了需求，规格文档在 openspec/changes/rbac-role-permission-management/ 目录下

方式二：从 /opsx:explore ->创建 proposal-> 需求审查时间间隔比较长 保险起见：重新说明一下需求，再加上上次通过 /opsx:propose 生成的需求规格路径openspec\changes\XXXX\目录

/brainstorming 在D:\kuntingProject\webView文件夹为前端项目 我想前端基于Vue3+Vite+TypeScript+Element Plus 技术栈用开发web界面，请在webView文件夹下先初始化前端项目，页面端需实现用户登录、设备查询功能。我已经用 OpenSpec 定义好了需求，规格文档在 D:\kuntingProject\openspec\changes\iot-webview-frontend\ 目录下,用TDD方式实现，完成后帮我做代码审查。

AI 会自动加载 brainstorming 技能，进入苏格拉底式提问流程：

1. 探索项目上下文 — AI 检查现有文件、文档、最近提交

2. 逐个提问 — 确认目的、约束、成功标准（一次只问一个问题）

3. 提出 2-3 个方案 — 带权衡分析和推荐

4. 分段展示设计 — 每段 200-300 字，逐段确认

5. 写设计文档 — 保存到 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md

6. 自检 — 检查占位符、矛盾、歧义、范围

7. 用户审批 — 架构师确认设计文档

如果在设计文档审查阶段发现AI生成的功能设计存在业务缺陷或者需求遗漏的地方，根据我们对业务的理解调整相关任务进行变更调整功能设计，直到审查文档没问题，重新生成设计文档

注意：brainstorming 过程中，AI 会读取会话上下文。因为前面已经执行了 /opsx:propose，OpenSpec 生成的 proposal、specs、tasks.md 的内容都在上下文里。架构师不需要手动复制粘贴，但需要确认 AI 理解了这些规格。brainstorming 完成后，AI 自动跳转到 writing-plans 技能——同样不需要手动输入命令。writing-plans 读取的是 brainstorming 产出的设计文档（docs/superpowers/specs/ 目录），而不是 OpenSpec 的 openspec/changes/ 目录。但因为两个阶段都在同一个会话里，OpenSpec 的规格内容已经在 AI 的上下文窗口中了。

生成的 Superpowers 计划文档长这样：

架构师审完这份计划，觉得没问题，告诉 AI "go" 就行。

Step 3：TDD 执行

计划通过后，AI 自动激活 subagent-driven-development 技能——同样不需要手动输入命令。计划文档的头部明确声明了：自动切换到子代理驱动模式。

每个任务完成后，Spec Compliance Reviewer 会逐行对比代码和 Superpowers 自己的实现计划是否一致。通过后，Code Quality Reviewer 再审一轮代码质量。两轮审查都过了，这个任务才算完成。

需要注意的一点：TDD每次执行完任务计划都会提交一次git记录

项目完成后进行自测，如果遇到问题 也是通过上传截图及现象描述通过AI 修复bug

Step 4：验收签字与归档确认

实现完成后，回到 OpenSpec 做验收签字。

项目启用了 expanded workflow（通过 openspec config profile 配置），可以执行 /opsx:verify 做三维度的自动检查——完整性（任务是否都完成）、正确性（实现是否匹配规格意图）、一致性（设计决策是否反映在代码中）。

验收通过后，执行归档确认：

/opsx:archive iot-webview-frontend

archive 命令会提示：增量 specs 还没有同步到主 specs，是否现在同步？选择是——delta specs 合并到 openspec/specs/，变更文件夹移动到 openspec/changes/archive/ 目录。从此任何人（包括未来的 AI）都能追溯到：当初为什么设计退款功能、做了哪些技术选型、考虑了哪些替代方案。下一轮迭代又可以开始了。

四、SDD项目实战二：增量迭代与变更管理

Iot设备管理平台跑起来了。现在产品经理说：登录成功后页面在左侧加一个菜单栏，默认选中是设备管理，右侧则显示设备列表, 在菜单栏中添加 用户管理，点击用户管理，右侧则显示用户列表（用户列表页面需要实现增删改查按钮功能），再次点击设备管理，右侧则显示设备列表，右侧页面内容可根据左侧菜单点击进行切换。

传统做法是改数据库、改模型、改 API、改前端、改测试——至少牵涉五个文件。看看 OpenSpec + Superpowers 怎么处理。

Step 1：变更提案

架构师发起增量更新：

OpenSpec 不会重新生成整套文档。它只生成增量规格：

架构师要做的是审查增量规格和 tasks.md，确认变更范围合理、场景覆盖完整。审查通过后，继续实现。

Step 2：自动化注入

这是关键环节。架构师审查完增量规格后，在同一个 Qode 会话中告诉 AI "按照新的增量规格来实现"。因为 OpenSpec 的增量 tasks.md 已经在会话上下文中，Superpowers 的子代理会基于这些上下文来注入变更。

/brainstorming 在登录成功后页面左侧填加一个菜单栏，默认选中是设备管理，右侧则显示设备列表,在菜单栏中添加用户管理，点击用户管理，右侧则显示用户列表（用户列表页面需要实现增删改查按钮功能），再次点击设备管理，右侧则显示设备列表，右侧页面内容可根据左侧菜单点击进行切换,我已经用 OpenSpec 定义好了需求，规格文档在 D:\kuntingProject\openspec\changes\add-sidebar-menu-user-crud\ 目录下,用TDD方式实现，完成后帮我做代码审查。

子代理跑完测试，RED → GREEN 循环完成。Spec Compliance Reviewer 对比实现计划和实际代码，确认 Priority 的三个场景（显式指定、默认值、非法值）都覆盖了。通过。

所有任务完成后，Superpowers 自动进入 finishing-a-development-branch 技能——验证测试、选择合并或保持分支。这一步也是自动触发，不需要手动输入命令。

Step 3：验收签字与归档确认

实现完成后，回到 OpenSpec 做验收签字。

如果项目启用了 expanded workflow（通过 openspec config profile 配置），可以执行 /opsx:verify 做三维度的自动检查——完整性（任务是否都完成）、正确性（实现是否匹配规格意图）、一致性（设计决策是否反映在代码中）。

如果用的是默认 core profile，没有 /opsx:verify 命令。架构师需要手动审查代码和测试，确认变更符合增量规格中的场景定义。

验收通过后，执行归档确认：

/opsx:archive add-sidebar-menu-user-crud

archive 命令会提示：增量 specs 还没有同步到主 specs，是否现在同步？选择是——delta specs 合并到 openspec/specs/，变更文件夹移动到 openspec/changes/archive/ 目录。下一轮迭代又可以开始了。

五、架构师的权力清单

整个流程下来，架构师需要签字的关键节点：

节点	什么时候	架构师做什么	工具
需求探索	需求梳理 理清楚业务细节	执行/opsx:explore 探索需求读代码、梳理既有架构	OpenSpec
生成提案	每轮迭代开始，把探索需求清晰后，生成设计和技术方案	执行 /opsx:propose ，根据上述需求探索完需求细节之后，梳理生成提案需求方案文件	OpenSpec
方案审查	propose 之后	审查 proposal、spec、design、tasks	OpenSpec
桥接传递	规划阶段	在同一会话中触发 brainstorming，确认 AI 理解了 OpenSpec 规格	Superpowers（自动触发）
计划审批	brainstorming 之后	审查 writing-plans 输出的实现计划	Superpowers（自动跳转）
验收签字	执行之后	expanded profile 用 /opsx:verify ；core profile 手动审查代码	OpenSpec
归档确认	验收通过后	/opsx:archive ，按提示同步增量 specs	OpenSpec

说白了，架构师不再写代码，但每个关键决策点都需要你的判断。AI 可以自动生成文档和代码，但需求是否准确、方案是否合理、实现是否达标——这些判断只有人能做。

六、建议与未来展望

1. 从小开始：选一个痛点明确、边界清晰的小模块试点，用成功案例说话。

2. 培训先行：花时间让团队理解“规范先行”的价值，而不仅是工具操作。

3. 核心：推动从“代码荣耀”到“规范荣耀”的价值观转变。好的规范文档胜过千行代码，说清楚“要什么”比“怎么做”更重要。

展望未来，SDD本身也在进化。AI增强的规范编写（用AI将自然语言需求初步转化为结构化规范）、智能代码生成（基于规范生成更优化、更安全的代码）、以及与云原生、Serverless架构的深度集成，将是重要趋势。SDD并非要颠覆传统软件工程，而是为AI时代提供了一套工程化的“驾驭术”。

作为技术人员，我们不仅是追赶技术潮流，更是为团队建立可持续、高质量、可控的研发体系。SDD规范驱动开发，正是在AI编程狂潮中，帮助我们找回确定性与纪律性的那座灯塔。

从“写代码的人”到“定义规则的人”。Qode + OpenSpec + Superpowers 的组合，代表的不是工具的简单堆叠，而是 AI 辅助软件开发的工程范式跃迁。这套体系恰恰将我们从“代码的生产者”升级为“规范的定义者”。我们最值钱的从来不是打字速度，而是理解复杂业务、设计稳健架构、做出正确技术决策的能力。

2026 年的后端开发，拼的不再是“谁加班多”，而是“谁的规范更清晰、谁的 AI 协作更高效、谁的工程纪律更严谨”。