开发者们常常陷入一种尴尬的境地：AI确实Neng写代码，但它记不住上下文；它Neng生成片段，却难以驾驭庞大的系统架构。当你关掉对话窗口，那些关于“为什么要这么设计”的精妙思路往往随风而散。为了打破这一僵局，我们需要一种geng深层次的协同机制——这就是 OpenSpec 与 Superpowers 登场的时候。

这不仅仅是两个工具的简单叠加，而是一场关于“记忆”与“执行”的完美联姻。OpenSpec 充当了项目的永久大脑，负责存储需求、设计规范和任务清单；而 Superpowers 则是那双不知疲倦的手，利用 Git Worktree、子代理驱动开发以及测试驱动开发等硬核技Neng，将蓝图转化为现实。今天我们就来深入剖析这两者是如何在复杂的开发流程中并肩作战的。

构建三层记忆架构：告别“健忘症”

在深入具体流程之前，我们必须先理解这套体系如何解决AIZui大的痛点——上下文丢失。通过将信息分层固化在磁盘上，我们构建了一个坚不可摧的记忆堡垒。

第一层：项目级的永久记忆

想象一下Ru果每次新开一个对话，AIdouNeng自动阅读一份“项目圣经”，那该多省心？这就是 openspec/config.yaml 的核心使命。它不仅仅是一个配置文件，geng是跨会话的记忆载体。

# openspec/config.yaml
context: |
  这里的内容，每次新对话 AI dou会读到。
  等于给 AI 的"永久记忆"。

在这里我们通常会写入技术栈选型、代码风格约定、核心业务逻辑的约束等。这就好比给新入职的资深开发发了一份详尽的手册，确保它不会在写代码时“随心所欲”。

第二层：功Neng级的需求记忆

当我们要开发一个具体功Neng时所有的细节dou需要被妥善安放。OpenSpec 的 changes/ 目录结构为此提供了完美的归宿。

openspec/changes/supplier-review/
├── proposal.md    ← Zuo什么、范围、Neng力列表
├── design.md      ← 文件结构、组件拆分、API 设计
└── tasks.md       ← checkbox 任务清单

proposal.md 回答了“这个功Neng是干嘛的”，design.md 阐释了“代码该怎么组织”，而 tasks.md 则清晰地记录了“我们Zuo到了哪一步”。这种结构化的存储，让需求不再是稍纵即逝的聊天记录，而是变成了可追溯、可审查的文档资产。

第三层：代码级的状态记忆

Zui后落实到代码层面Git 本身就是Zui好的状态机。配合 Superpowers 的 git-worktree 技Neng，我们Ke以为每个功Neng创建隔离的工作区。

+ .worktrees/supplier-review/          ← 完整项目副本，独立工作区

分支名即功Neng名，提交历史即进度条。这种物理上的隔离，保证了主工作区的整洁，同时也让多任务并行开发成为可Neng。

协同工作流：从灵感到落地的完整链路

有了记忆作为基础，接下来就是如何利用这套体系进行实战开发。我们将整个过程拆解为几个关键阶段，kankan OpenSpec 与 Superpowers 是如何在每个环节咬合的。

阶段一：需求梳理与探索

hen多时候，我们拿到手的只是一张模糊的产品截图或者一份字段表。这时候，直接写代码是大忌。我们需要先让 AI “思考”。

此时我们Ke以使用 OpenSpec 的 Explore 模式。它就像一个只读的思考伙伴，帮助我们理清思路。

/opsx:explore supplier-review
产品给了「供应商审核」的原型截图和字段文档：

在这个阶段，AI 不会修改任何磁盘文件，而是专注于理解业务逻辑，梳理页面结构，确定数据模型。这种“谋定而后动”的策略，Neng有效避免后期的返工。

阶段二：生成结构化制品

当思路理顺后就需要将其固化为文档。OpenSpec 的 propose 指令Ke以一键生成标准化的制品。

/opsx:propose supplier-review
开发 admin-portal 的「供应商审核」模块。
包含：审核列表页+ 审核详情页。

执行后磁盘上会自动生成 proposal.mddesign.md 和 tasks.md。特别是 tasks.md，它将庞大的功Neng拆解成了一个个可执行的 Checkbox 任务，这是后续自动化执行的基石。

阶段三：制定精细作战计划

对于复杂的功Neng，直接让 AI 蒙头写代码往往不可控。Superpowers 的 writing-plans 技Neng派上了用场。它会读取 OpenSpec 的设计文档，生成一份精确到“5分钟粒度”的执行计划。

我要实现供应商审核模块，设计文档在 openspec/changes/supplier-review/design.md，
请用 writing-plans 生成实现计划。

这会产出类似 docs/superpowers/plans/---supplier-review.md 的文件。在这个计划里每一步dou清晰定义了：创建什么文件、写入什么代码、运行什么测试、预期结果是什么。这种颗粒度的控制，是高质量代码的保障。

阶段四：子代理驱动执行

这是整个流程中Zui精彩的部分。Superpowers 启动 subagent-driven-dev 模式，主 Agent 变成了指挥官，而具体的脏活累活则派发给一个个全新的 Subagent。

主 Agent
  │
  ├─ 读 tasks.md，提取 Task 1 的完整描述
  │
  ├─ 派发 Subagent 1 实现 Task 1
  │   └─ Subagent 遵循 TDD：写测试 → 红 → 实现 → 绿 → 重构
  │
  ├─ 派发 Spec Reviewer 检查是否符合 design.md
  │   └─ 不符合 → Subagent 修复 → 再审
  │
  ├─ 派发 Code Reviewer 检查代码质量
  │   └─ 有问题 → Subagent 修复 → 再审
  │
  ├─ tasks.md 中 Task 1 打勾 
  │
  └─ 派发 Subagent 2 实现 Task 2 ...

这种模式的优势在于“隔离”与“专注”。每个 Subagent dou拥有全新的上下文窗口，专注于解决眼前的一个小任务，不会因为对话过长而产生幻觉。同时双重审查机制确保了代码既符合设计规范，又具备高质量。

阶段五：验证与收尾

当所有的 Checkbox dou被打勾，并不意味着结束。Superpowers 会触发 verification-before-completion，进行Zui后的完整性、正确性和一致性检查。

/opsx:verify supplier-review

通过后finishing-a-development-branch 技Neng会自动处理 Git Worktree 的清理、分支合并或 PR 创建。整个过程行云流水，仿佛有一个隐形的 DevOps 专家在幕后操作。

应对中断：随时恢复的“复活”机制

现实开发中，中断是常态。可Neng是网络波动，可Neng是窗口误关，也可Neng是上下文耗尽导致 AI 开始“胡言乱语”。在传统模式下这简直是灾难。但在 OpenSpec 与 Superpowers 的协同下恢复工作变得异常简单。

场景一：对话意外中断

不用担心，所有的进度dou写在磁盘上。你只需要新开一个对话，输入简单的指令：

/opsx:apply supplier-review

AI 会自动读取 tasks.md，识别出哪些任务Yi经完成，哪些任务还待处理，然后无缝地从断点继续执行。新对话拥有清爽的上下文，比在旧对话里死磕要高效得多。

场景二：上下文窗口耗尽

当对话变得过长，AI 开始遗忘之前的约定，代码风格开始跑偏。这时候，千万不要试图在旧对话里修补。正确的Zuo法是：让 AI 把当前的结论写入 OpenSpec 的笔记文件，然后结束对话。

把刚才讨论的结论写入 openspec/changes/supplier-review/notes.md

下次开始时AI 会读取这些笔记，迅速找回状态。这种“外挂大脑”的设计，彻底解决了长对话的记忆衰减问题。

策略选择：因地制宜的组合拳

并不是所有功Nengdou需要动用全套“核武器”。根据任务的大小和重要性，我们Ke以灵活选择不同的组合策略。

组合 A：快速通道

适用场景： 小功Neng、占位页替换、简单的 CRUD 操作。

策略： 直接使用 /opsx:apply。AI 会在当前会话中逐个完成任务，不生成复杂的计划文件，也不启用 Subagent。简单粗暴，但效率极高。

组合 B：质量卫士

适用场景： 核心业务模块、不允许返工的关键功Neng。

策略： /opsx:propose + writing-plans + subagent-driven-dev。

这是Zui重量级的打法。从需求梳理到精细计划，再到子代理执行加双重审查，每一步dou追求极致。虽然 Token 消耗较大，但换来的是Zui高质量的代码产出和Zui低的维护成本。

组合 C：混合战术

适用场景： 中等规模的功Neng，或者部分逻辑复杂、部分逻辑简单。

策略： 灵活切换。例如前几个简单的 Task 用组合 A 直接Zuo，遇到复杂的算法逻辑或核心组件时切换到组合 B 用 Subagent 攻坚。OpenSpec 的 tasks.md 是唯一的进度源，无论怎么切换，进度douNeng完美同步。

迈向工程化的 AI 协作

Superpowers 与 OpenSpec 的结合，标志着 AI 辅助编程从“聊天式”向“工程化”的质变。我们不再是在乞求 AI 帮忙写几行代码，而是在指挥一支纪律严明的数字军队。

OpenSpec 负责定义“Zuo什么”，将模糊的需求转化为结构化的契约；Superpowers 负责解决“怎么Zuo好”，利用隔离环境、自动化计划和多重审查确保交付质量。两者相辅相成，不仅解决了 AI 记忆力差的缺陷，geng通过流程化的协作，将人类的创造力与 AI 的执行力无缝融合。

在这个框架下开发者不再仅仅是代码的编写者，geng是这支 AI 军队的指挥官。掌握这套协同机制，你将在未来的软件开发竞争中，占据降维打击的优势。

---