AI 编码代理工作流选型：GSD、OpenSpec、Superpowers 等五类工具怎么选

AI Coding Agent 已经从"帮我补一个函数"走向"帮我完成一个功能、修一个复杂 Bug、重构一段历史代码"。问题也随之变化：过去我们担心模型不会写代码，现在更常见的问题是上下文腐化、需求漂移、没有验证闭环、多 Agent 并行失控，以及规格和实现脱节。

这正是 GSD、planning-with-files、OpenSpec、mattpocock/skills 和 Superpowers 这类工具出现的背景。它们都在尝试回答同一个问题：如何让 AI Agent 不只是生成代码，而是按照可复盘、可验证、可协作的工程流程完成任务。

这五个工具并不是同一类产品的简单横向竞品。更准确地说，它们分别站在五个层面解决 AI 辅助开发的问题：持久化记忆、工程技能、完整流程、变更管理，以及项目级上下文编排。你提供的报告也将它们归纳为不同层级：planning-with-files 是最小可用的持久化工作记忆，mattpocock/skills 是工程方法论技能集合，Superpowers 是完整开发周期框架，OpenSpec 是 spec-first 变更管理，GSD 则是更重量级的上下文工程与多阶段 Agent 编排系统。

一句话看懂五个工具

GSD 适合大型、多阶段、长上下文任务。它把开发拆成 initialize、discuss、plan、execute、verify、ship 等循环，并通过 fresh context、并行 waves 和原子提交降低长任务失控风险；其 README 将自己描述为面向 Claude Code、OpenCode、Gemini CLI、Codex、Cursor 等运行时的 meta-prompting、context engineering 与 spec-driven development 系统。([GitHub][1])

planning-with-files 适合轻量持久化上下文。它用 task_plan.md、findings.md、progress.md 三个 Markdown 文件把 Agent 的工作记忆写入磁盘，核心原则是"Context Window = RAM，Filesystem = Disk"；官方 README 也明确把它定位为面向计划、进度跟踪和知识存储的持久化 Markdown 工作流。([GitHub][2])

OpenSpec 适合 brownfield 项目中的增量变更管理。它不是让你一次性写完整系统说明，而是围绕一次变更生成 proposal、tasks、design 和 spec delta，让评审者先看"意图和需求如何变化"，再看代码。OpenSpec 官网将其描述为 lightweight spec-driven framework，并强调 spec 存在仓库中、与代码一起成为持久上下文。([OpenSpec][3])

mattpocock/skills 适合想把 Agent 拉回真实工程节奏的开发者。它不是大型框架，而是一组小而可组合的 skills，用来解决需求误解、输出冗长、反馈缺失、代码腐化等问题；仓库 README 明确说这些 skills 设计目标是 small、easy to adapt、composable，并可用于不同模型。([GitHub][4])

Superpowers 适合希望 Agent 覆盖完整开发闭环的团队。它将 brainstorming、规格澄清、计划、TDD、子代理执行、验证和审查组织成一套可复用的方法论；官方 README 称其为 "complete software development methodology for your coding agents"，并支持 Claude Code、Codex CLI、Gemini CLI、OpenCode、Cursor 等工具。([GitHub][5])

选型的核心不是"哪个最强"，而是"你缺哪一层"

很多团队选 AI 辅助开发工具时会犯一个错误：直接问"哪个工具最好"。更合理的问题是：

你的 Agent 当前最常失败在哪里？

如果失败在"做着做着忘了目标"，你需要的是持久化记忆，planning-with-files 的三文件模式就足够轻。 如果失败在"还没理解需求就开始写代码"，你需要的是 grill、brainstorming 或 spec proposal。 如果失败在"需求变更后没人知道系统意图如何变化"，OpenSpec 更合适。 如果失败在"长任务、多阶段、多 Agent 协作会失控"，GSD 或 Superpowers 更接近问题本身。 如果失败在"写完就算完成，没有测试、审查和收尾"，Superpowers 或 mattpocock/skills 的 TDD/debug/review 类技能更有价值。

这也是五个工具最大的差异：它们分别解决不同粒度的问题。你提供的对比报告中，GSD 覆盖完整项目生命周期，planning-with-files 主要负责工作记忆，OpenSpec 负责变更管理，mattpocock/skills 偏工程方法论，Superpowers 则覆盖 brainstorming 到 finishing 的完整开发周期。

GSD：适合"长任务不想崩"的项目级开发

GSD 的关键词是 context engineering、phase、wave、verify、ship。它更像一个围绕 Agent 构建的项目执行系统，而不是单个 skill。

它的优势在于把长任务切成阶段，每个阶段经过 discuss → plan → execute → verify → ship 的闭环。官方 README 中也描述了类似六步循环：先初始化并形成 research、requirements、roadmap；再通过 discuss 捕获布局、API、错误处理、数据结构等灰区；plan 阶段会研究、计划、验证；execute 阶段以 parallel waves 执行，并为任务生成 atomic commit；最后 verify 和 ship。([GitHub][1])

适合它的场景是：

场景	是否适合 GSD
从 0 到 1 构建产品原型	适合
多阶段、多天的大型功能	适合
需要多 Agent、worktree、并行执行	适合
单文件小改动	偏重
快速问答或一次性脚本	不推荐

GSD 的代价也很明显：它的概念和文件系统更重。phase、wave、workspace、state、roadmap 等机制会带来学习成本。如果团队还没有稳定需求、测试体系和代码审查习惯，直接引入 GSD 可能会感觉"流程比问题还大"。

选型建议： 当你已经明确要做一个跨多模块、多阶段、需要持续几天甚至几周推进的任务，并且希望 Agent 具备清晰计划、分阶段交付和验证闭环时，GSD 值得优先评估。

planning-with-files：最轻量的 Agent 外置记忆

planning-with-files 的价值在于它没有试图发明复杂方法论，而是解决一个非常具体的问题：Agent 的上下文窗口是易失的，任务目标、调研发现、失败原因和进度需要被写到文件系统里。

它的三文件模式非常直接：

task_plan.md   # 阶段、任务、检查项
findings.md    # 调研发现、关键判断、资料摘录
progress.md    # 会话日志、测试结果、失败记录

官方 README 将问题归纳为 volatile memory、goal drift、hidden errors 和 context stuffing，并给出三文件模式作为解决方案：复杂任务中创建 task_plan.md、findings.md、progress.md，让重要信息写入磁盘，而不是塞进上下文窗口。([GitHub][2])

它适合：

场景	推荐理由
研究型任务	findings 文件能沉淀资料
多步骤但不复杂的开发任务	成本低，不强制大流程
跨会话继续工作	progress 能恢复上下文
不确定是否需要完整框架	可作为默认轻量底座

它不适合替代 TDD、代码审查、变更管理或多 Agent 编排。它解决的是"记忆"问题，不解决"工程纪律"问题。

选型建议： 如果你不知道该先引入哪个工具，planning-with-files 往往是最低风险起点。它不会强迫团队改变开发流程，却能显著降低上下文丢失和目标漂移。

OpenSpec：把"本次要改什么"固定下来

OpenSpec 的核心不是"写文档"，而是"用 spec delta 管理变更意图"。这对于已有系统特别重要，因为 brownfield 项目中最危险的不是不知道代码怎么写，而是不知道这次变更到底改变了哪些系统行为。

OpenSpec 官网强调每次 change 会生成 spec delta，捕捉系统需求变化，让开发者和评审者理解"系统将如何被修改"。它还强调 specs 存在代码仓库中，按能力组织，作为 Agent 和新成员都能读取的持久上下文。([OpenSpec][3])

它适合：

场景	推荐理由
已有系统增量功能	关注本次 change，而不是重写全量说明
多人评审	proposal、tasks、design、spec delta 便于讨论
需求容易漂移	先评审 intent，再写代码
多 Agent/多工具切换	specs 在仓库中，不依赖单一会话

OpenSpec 的边界也要说清楚：它不能自动保证代码质量，也不能替你决定产品方向。官网 FAQ 也直接提醒，specs 只有在人真正阅读、思考、参与时才有效；它不是无脑自动规划工具。([OpenSpec][3])

选型建议： 如果你的主要痛点是"Agent 写出来的代码看似对，但需求边界、行为变化和评审上下文不清楚"，优先考虑 OpenSpec。

mattpocock/skills：把 Agent 当工程师训练，而不是当魔法按钮

mattpocock/skills 的风格非常工程师化。它不试图接管整个开发流程，而是提供一组小 skill，帮助 Agent 做需求澄清、TDD、诊断、架构改进、issue triage、写作和知识沉淀。

README 中对第一个失败模式的描述很典型：软件开发中最常见的问题是 misalignment，你以为开发者理解了需求，看到结果才发现并没有；在 AI 时代也是一样，所以需要 grilling session，让 Agent 在开始前提出详细问题。([GitHub][4])

这套 skills 的优势是"轻而可组合"：

需求	可选思路
需求不清	grill 类 skill
Bug 难复现	diagnose/debug 类 skill
想做 TDD	TDD skill
代码架构变差	architecture/refactor 类 skill
issue 混乱	triage skill

它的不足也来自同一个特点：因为它不是完整项目管理系统，所以不会天然处理跨阶段状态、多 Agent 并行、spec 归档或 release 节点。

选型建议： 如果你已经有自己的项目管理、分支策略和代码审查流程，只是希望 Agent 更像一个靠谱工程师，mattpocock/skills 很适合作为"工程行为补丁"。

Superpowers：把完整开发周期变成 Agent 默认行为

Superpowers 更像"方法论 + skills + commands + hooks + agents"的组合。它不像 planning-with-files 那样只解决记忆，也不像 OpenSpec 那样只聚焦变更管理，而是把从需求澄清到计划、TDD、子代理执行、验证、审查和收尾串起来。

官方 README 对其工作方式的描述很清晰：当 Agent 看到你要构建东西时，不会直接写代码，而是先退一步询问真实目标；形成 spec 后分块展示给你确认；确认设计后生成足够清晰的 implementation plan，并强调 red/green TDD、YAGNI、DRY；随后进入 subagent-driven-development，由代理执行、检查、审查并继续推进。([GitHub][5])

它适合：

场景	推荐理由
想给 Agent 一套默认工程流程	从 brainstorming 到 finishing 覆盖完整闭环
需要验证与审查	verification/review 类流程内建
想跨工具保持体验一致	支持多种 coding agent/harness
需要子代理分工	subagent-driven-development 适配并行任务

相比 GSD，Superpowers 更偏"开发方法论框架"；相比 mattpocock/skills，它的流程覆盖更完整；相比 OpenSpec，它对"变更意图"的规格化不如 OpenSpec 专注。

选型建议： 如果你想让 Agent 每次开发都默认先澄清、再规划、再 TDD、再验证、再审查，Superpowers 是更完整的一站式选择。

五工具选型矩阵

你的主要痛点	首选工具	组合建议
Agent 经常忘目标、丢上下文	planning-with-files	可与任意工具叠加
需求没澄清就开写	mattpocock/skills / Superpowers	grill + brainstorming
已有系统的增量变更难评审	OpenSpec	OpenSpec + planning-with-files
大型任务要分阶段推进	GSD	GSD + OpenSpec
想要完整开发闭环	Superpowers	Superpowers + planning-with-files
Bug 修复需要复现和诊断	mattpocock/skills / Superpowers	diagnose/debug + TDD
多 Agent 并行和 worktree 协作	GSD / Superpowers	视任务重量选择
日常轻量开发	planning-with-files	必要时加 TDD/debug skills

推荐组合：不要只装一个"万能工具"

更现实的方案是分层组合。

轻量个人开发者

planning-with-files + mattpocock/skills

适合日常开发、调研、Bug 修复和中等复杂度功能。planning-with-files 负责外置记忆，mattpocock/skills 负责需求澄清、TDD 和诊断。

Brownfield 团队

OpenSpec + planning-with-files + TDD/debug skills

OpenSpec 管理"本次改什么"，planning-with-files 记录调研和执行进度，TDD/debug skills 保障实现质量。这个组合适合已有代码库、多人评审和频繁变更。

大型功能或项目级开发

GSD 或 Superpowers + OpenSpec

如果任务非常长、阶段很多、需要多 Agent 并行，选 GSD。 如果更希望给 Agent 一套默认工程流程，选 Superpowers。 如果涉及多人评审或需求边界复杂，再叠加 OpenSpec 管理变更意图。

最终建议

这五个工具没有绝对第一，只有适用边界。

先从 planning-with-files 开始 ，因为它成本最低，能立刻改善上下文丢失。 需求模糊时加 mattpocock/skills 或 Superpowers 的澄清流程 ，避免 Agent 过早实现。 已有系统做增量变更时引入 OpenSpec ，把"本次改什么"写清楚。 任务变长、阶段变多、并行变复杂时再考虑 GSD 或 Superpowers，用流程、验证和子代理协作降低失控风险。

AI 辅助开发的关键，不是让 Agent 更快写更多代码，而是让它在正确上下文中、围绕明确意图、通过可验证流程交付代码。工具选型也应围绕这个目标展开：记忆要持久，意图要可审，计划要可执行，结果要可验证。