Superpowers、OpenSpec、Spec Kit 与 Anthropic Skills 的使用场景和真实反馈

研究截止：2026 年 10 月 14 日｜迭变笔记 · Everiter

让 AI 写一个上传按钮，通常很快。让它把文件大小限制、解析失败提示、后台任务、下载结果和已有权限一起处理好，就需要持续核对。到了下一次改需求，还要弄清楚：哪些决定已经作废，哪些约定仍然有效？

Superpowers、OpenSpec、GitHub Spec Kit 和 Anthropic Skills，都在帮助人把方法交给 AI，但着力点不同。Superpowers 组织开发行为；OpenSpec 管理需求变更；Spec Kit 提供结构化开发过程；Anthropic Skills 展示怎样把具体任务的方法、脚本和资料装进技能。理解这种差别，比同时装上四套工具更有用。

图 1｜迭变笔记原创关系图，依据四个项目的官方文档整理。各块表示不同着力点，不表示开发步骤或已经存在自动集成。

先把两个词说清楚。Skill 是供 Agent 按需读取的一组说明与配套资源，里面可以有脚本、模板和参考材料。规范驱动开发，常缩写为 SDD，是先明确想要的行为，再据此规划、实现和检查的一种开发方式。技能可以承载这种过程，规范工具也可以通过技能向 Agent 提供指引。它们并不处于完全互斥的分类中。Anthropic 仓库说明、Spec Kit 官方说明

下面贯穿一个说明性案例：给现有应用增加“文件上传与解析”，先支持文本型 PDF 与 DOCX，扫描件另行处理。四种资源分别怎样参与？使用者又在哪些地方感受到帮助或负担？公开反馈是具体人的经历，阅读时需要同时看日期、版本和任务背景。

一 Superpowers 把开发方法组织成可执行过程

从一句需求走到有证据的交付

Superpowers 是 Jesse Vincent 与 Prime Radiant 团队维护的开发方法体系。其技能覆盖需求讨论、计划、实现、测试、调试和评审，官方将相关流程作为需要遵守的工作约定。项目仓库

在文件解析案例中，需求讨论应先问清：用户要正文、表格还是版面？解析在哪运行？大文件是否进入后台？失败之后怎样重试？这些答案改变产品行为，不能让模型在写代码时顺手决定。

明确设计之后，writing-plans 把决定交给实现者：改哪些位置、提供什么接口、哪些输入必须测试。当前技能要求记录必要的签名、约束与断言，避免把计划写成整份代码的预演。计划的价值，是让下一位实现者知道已经决定了什么。计划技能

执行可以走两条路线：用子 Agent 分任务实现和评审，或者在当前会话执行整份计划，再进行一次独立的整体评审。当前子 Agent 流程的任务评审同时看规范符合度和代码质量；不要沿用旧教程，把两项检查理解成永远必须调用两个不同评审者。执行技能、版本记录

测试驱动开发要求先观察测试失败，再写实现使它通过。对于我们的例子，一个有用的断言是“超出大小限制的文件得到明确拒绝，且没有进入解析队列”。只证明上传函数被调用，保护不了这个行为。验证技能还要求取得新的执行证据，才报告完成；调试技能则要求先调查原因，再尝试修复。验证技能、调试技能

优势来自减少遗漏和反复猜测

独立开发者常常同时担任产品、开发和测试。Superpowers 把这些职责对应的动作写出来，有助于人在长任务中保持方向：先确认用户行为，再拆分工作，最后检查结果。它尤其适合跨几个模块、容易遗漏异常路径的功能。

但指令只能影响 Agent 的行动。有没有实际运行环境，测试是否覆盖真实问题，执行工具能否调度子 Agent，仍然需要在使用时确认。流程再完整，也不会凭空获得外部系统权限或业务判断。

使用者既重视评审 也会质疑成本

2026 年 6 月 18 日，用户 larya-dot-eu 在 #1803 报告，经过九十多次会话，自己每天依赖 Superpowers，但计划仍可能出现错误测试命令、环境激活遗漏等问题。他使用 Superpowers 6.0.2、Claude Code，并列出了 Opus、Sonnet 等模型环境，主张在执行前增加专门挑战计划假设的检查。作者 obra 回应，5.0 曾有类似机制，却因额外耗时和 token 支出受到用户反对。原始讨论

另一条反馈来自 notchrisbutler：2026 年 4 月，他在 OpenCode、GPT 5.4 与 Superpowers 5.0.7 环境中，觉得仓库设置、脚手架等小任务也经过完整评审，付出与任务价值不匹配。7 月，用户 sukris 又报告同版本的一次长会话：同一完整构建重复十三次。两位用户的记录

8 月 18 日，协作者 arittr 回应，小任务批处理、合并任务评审和缩小复审范围已经引入。当前发布记录也记载了这些调整。因此，这些案例能说明旧流程的成本，不能充当今天每次使用的费用估计。回应、发布记录

图 2｜官方技能列表局部截图。这里展示两个入口；测试、执行、调试和评审还有各自技能。原始页面。

图 3｜2026 年 4 月 23 日，crisog 对评审成本讨论的回应。截图保留账号、日期和完整短评论；后续流程改动见正文，不能将这条旧意见当作当前版本评测。原评论。

对个人开发者，更合理的采用标准是：这个功能的遗漏代价，是否值得付出计划和评审成本？给上传入口加一个提示，与调整解析任务的失败处理，需要的检查力度显然不同。

二 OpenSpec 让需求变更留下可维护的记录

分清现在的行为和这次要改的行为

OpenSpec 在项目中建立规范与变更材料。官方示例中，一次提案会形成 proposal、specs、design 和 tasks 等 Markdown 文件；完成后归档，并把变更合入规范。安装 CLI 后在项目里初始化，再到 AI 助手的聊天中提出、实施和归档变更。项目说明

对现有应用，其关键设计是增量规范：以新增、修改、移除的要求描述本次变化，无需先给整个代码库补齐说明。官方现有项目指南明确建议，只为即将触及的部分建立规范，随着真实变更逐步积累。现有项目指南

文件解析功能第一版可能只处理正文。第二版要增加表格和扫描件时，新的提案需要说明哪些行为改变，哪些边界继续保留。长期来看，维护者需要既能读懂当前功能，也能追查为什么做过某次调整。

需求在实现中变化也很正常。OpenSpec 允许随时修改材料；但改完需求后，要核对设计、任务和已有代码是否仍然一致。工具允许迭代，不等于替你证明所有关联材料都已更新。变更编辑指南

哪些场景更容易受益

对于不断增加功能的个人产品，OpenSpec 可以把散落在聊天里的决定移到仓库中。换会话、换开发者或者隔几周回来维护时，有机会从变更材料恢复上下文。对协作团队，提案也提供一个在代码大量产生之前讨论范围的入口。

当前官方还提供把规范与计划放到独立仓库的 Stores，用于跨仓库共享，但 README 明确标为 beta。可以关注这条路线，不能把测试阶段能力描述成已经验证的大规模团队方案。官方说明

用户认可清晰结构 大仓库采用仍需处理上下文

2025 年 11 月 5 日，贡献者 yha9806 在 #281 中评价，提案、应用、归档的结构符合自己的变更思路，Markdown 材料也便于理解。他描述了用 OpenSpec 改进其增量解析器的经历，并关联 PR #280。该帖注明由 Claude Code 辅助写作，属于参与贡献者的体验，适合用来理解为何有人喜欢这套结构。贡献者反馈

2025 年 10 月 14 日，orbiri-ns 表示自己在独立全栈项目中体验良好，准备引入约百名开发者参与的大型系统仓库，却担心 Agent 找不到正确上下文。维护者 TabishB 回应，大仓库遍历与上下文管理也受 Agent 和模型限制，并坦言当时没有在更大规模中实践过，不能给出确定最佳方案。原始讨论

这段讨论表达的是当时的采用疑问。今天已有更多官方指导和跨仓库功能，仍需用具体仓库验证是否适合。我的建议是从一个边界清楚的变更开始，观察提案是否减少误解、归档后规范能否准确解释功能，再扩大使用范围。

图 4｜官方发布的 Dashboard 预览图片，展示变更与状态的组织方式；画面中的项目数据是官方展示内容。图片所在 README。

三 GitHub Spec Kit 把原则 需求和任务连起来

将项目约定带入每一次开发

Spec Kit 提供结构化过程、可复用模板和过程记录。核心 SDD 路径包括项目原则 constitution，以及每个功能的 specify、plan、tasks、implement 与 converge。当前项目还提供按需安装的修复问题和评估想法扩展，它们是独立入口，不要求先走完功能开发过程。官方 README

在文件解析案例中，项目原则可以约定：沿用现有权限边界；不改变旧接口；异常需要面向用户的反馈。需求写“用户能获得段落顺序正确的正文”，技术计划再决定解析库、存储和后台任务。先分清目标，再决定方法，有助于避免某个库的能力反过来定义用户需求。

analyze 检查规范、计划和任务之间的冲突与遗漏。converge 在实现之后检查是否还有差距，必要时追加任务，再交给实现过程处理。这些能力使规范可以参与核对，但不会让一份漂亮 Markdown 自动成为软件正确性的证明。SDD 命令参考

Spec Kit 同样能引入现有项目。官方建议保留可评审的基线，按已有架构与测试约定规划一个有限变更。初始化不会自动推导整个旧系统的规范；不要为了采用工具，先给产品安排一次无必要的全面重写。现有项目指南

价值在交接和一致性 成本在持续维护

当一个功能需要产品、前端、后端和测试共同完成，规范、计划和任务可以承接不同层面的讨论。独立开发者也能用这些材料给未来的自己留下交接信息：想解决什么，接受哪些取舍，还缺哪些行为。

实际成本则包括审阅和同步。把含糊目标扩写成许多条目，可能只是让误解更难发现。如果任务跟着旧需求走，文档越齐全，越容易给人已经考虑周全的错觉。每条要求都应对应真实用户行为或必要约束。

项目评估和小功能反馈给出了不同提醒

2026 年 4 月 22 日，ourchitectureio 发布对其 pre-alpha IDP 项目的采用评估，认可 Spec Kit 把规范作为可指导交付的材料，以及提前对齐和改善交接的方向。他们也希望规范更直接连接契约测试、运行行为和跨技术栈验证。这是早期评估，不能写成已经完成团队生产采用并测得效率提升。评估原文

2026 年 5 月 28 日，用户 qurore 使用 Claude Code 与 Opus 4.7 时，观察到不同规模功能往往生成十三至二十条功能要求，担心小任务被扩写。项目答复者 mnriem 解释，当时命令没有规定条目数量，模型会采用自己的默认方式，并建议用本地 preset 调整要求颗粒度。观察与回应

它们共同提醒：材料要帮助确认行为。对上传解析功能，“有效文件产生可读结果”“无效文件得到明确反馈”“结果只对有权用户可见”，可能比十几条同义表述更便于验证。需要多少要求，应由实际行为决定。

图 5｜官方 README 标识与短说明截图。当前工具已提供不同过程入口，不能只用早期的单一路径介绍其全部能力。原始页面。

四 Anthropic Skills 将专业任务的方法交给 Agent

一个目录可以装下说明 脚本和经验

Anthropic Skills 是官方的技能示例仓库。每个技能有独立目录与 SKILL.md，可以携带脚本、资料和素材。这里既有网页测试、MCP 开发等技术任务，也有品牌、沟通和文档处理示例。仓库说明

webapp-testing 指导使用 Python Playwright 检查本地应用，提供启动服务的辅助脚本，并强调先查看页面，再选择元素执行操作。用于案例时，它可以帮助组织上传、错误反馈和结果展示的浏览器检查。网页测试技能

mcp-builder 指导开发让模型调用外部服务的 MCP 工具，涉及接口研究、工具设计、实现和评估。若希望其他 Agent 调用文件解析能力，它能帮助设计调用入口；解析引擎本身仍需另行实现。MCP 开发技能

brand-guidelines 写入的是 Anthropic 的品牌配色与字体，不会自动理解迭变笔记的视觉规范。借鉴这个组织方式时，需要把自己的规范、示例和检查方式写进去。品牌技能

文档技能则展示了更具体的操作路线：PDF 技能区分文字、表格、扫描件 OCR 等任务；DOCX 技能涉及读取、创建、修改及校验。这种分工提示我们，“解析文件”不能只按扩展名理解，扫描 PDF 和文本 PDF 的处理目标并不相同。PDF 技能、DOCX 技能

优势是复用判断和工具调用方式

把“先识别文件特征，再选择处理工具，最后检查输出”写成技能，可以减少每次从头讲解，也便于持续改进。企业常需要的定制内容正是这些细节：允许什么输入、用什么工具、表格如何保留、失败如何反馈、结果怎样验收。

但技能中的环境假设必须检查。库、浏览器、转换工具、字体和客户端发现技能的方式，都会影响执行。目录能加载，与任务能完成，是两项需要分别验证的能力。

许可证也要落实到具体技能

官方 README 区分了 Apache 2.0 开源技能和文档处理技能的 source-available 状态。本文核对的网页测试、MCP、品牌技能许可证为 Apache 2.0；DOCX 许可证含复制、衍生和分发限制，不能按普通开源模板任意复制改造。涉及复用时，应阅读对应目录的条款。仓库声明、Apache 许可证示例、DOCX 条款

三条反馈说明技能也需要具体评估

2026 年 1 月 5 日，开发者 Justin Wetch 在个人复盘中介绍了修改官方 frontend-design 的过程。他认为部分原则难以直接执行，于是改写指令，并用 Haiku、Sonnet、Opus 4.5 生成结果，再由模型评审。这个案例说明技能可以针对工作方式继续调整；其自报比较结果针对自己的修改版，不能视为官方技能的普遍收益，也不能替代人的设计判断。作者复盘

9 月 29 日，用户 sergiodanielale 报告，在 Windows 11、Python 3.14 环境中，docx 的校验脚本遇到读取 XML 与控制台输出的编码错误。帖中给出空白文档的复现过程以及自己的绕行方式，问题指向校验环境，并非所有文档都无法生成。DOCX 用户报告

9 月 27 日，用户 sxh313 报告，网页测试技能的元素发现示例把下拉框等控件标成文本输入，随后调用错误的填写方法会失败。他提供了页面、环境和对照结果。这类反馈更具体地展示了配套脚本怎样影响 Agent 的判断；发布修复是否已经解决目标环境，仍需另行确认。网页测试报告

图 6｜基础模板的元数据片段。名称和描述帮助识别技能，具体步骤与配套资源还需要在其后编写。原始页面。

五 怎样选择以及组合使用

四种资源有重叠，但可以先按眼前最需要解决的问题来选择：

图 7｜迭变笔记原创采用流程。顺序表示先找到问题再验证收益，不是资源能力排名。

回到文件解析案例，可以让 OpenSpec 或 Spec Kit 承担需求与变更材料，让 Superpowers 的方法参与实现、调试与交付检查，再调用适用的专业技能完成测试或文档操作。这是一种组合设想，并非四套工具已经自动互通。

组合时需要明确：哪份材料维护需求，哪套过程负责执行，哪个技能完成具体任务。 如果两个系统都生成完整计划、都要求独立批准、都重复执行同一测试，就可能增加工作而没有增加信息。OpenSpec 与 Spec Kit 应先选一个作为主要规范入口，待确有需要再设计映射。

从一次真实的小变更开始，记录总耗时、返工原因、遗漏行为和模型用量，再判断是否扩大采用。评价依据应是用户需求有没有得到解决、交接是否更清楚、结果是否经过有效验证。文件数量、技能数量与 Agent 数量，都无法直接回答这些问题。

对希望编写 Skills 的人，这些资源提供了可研究的方法：把判断条件写清楚，把必要操作连接工具，把验收落实到行为，再根据反馈继续修改。为别人解决“如何解析 PDF”这样的具体问题，正是让方法接受现实检验的起点。

附录 事实核验与来源

下表记录关键说法的证据性质。访问日期均为 2026-10-14；官方功能以当日读取的文档与技能为准，用户经历只代表其说明的环境。资料版本与反馈背景详见来源与版本记录。

---

资料留档：来源与分析记录 · 图片来源与权利记录。