https://blog.twotigers.xyz/tags/openspec/ Recent content in openspec on Two Tigers Engineering Hugo -- gohugo.io en-us Tue, 12 May 2026 00:00:00 +0800 https://blog.twotigers.xyz/posts/openspec-superpowers-workflow/ Tue, 12 May 2026 00:00:00 +0800 https://blog.twotigers.xyz/posts/openspec-superpowers-workflow/ 最近我尝试把 OpenSpec 和 Superpowers 结合起来，用 Claude Code 做一个“英语自然拼读学习网站”。这篇文章整理这次探索过程：为什么要同时使用这两个工具、每个阶段应该产出什么文件、提示词应该怎么写，以及实现完成后如何归档 spec。 核心结论很简单： Superpowers 负责过程纪律。 OpenSpec 负责长期规格事实。 实现阶段只以 OpenSpec change 为需求来源。 如果只用 Superpowers，AI agent 的执行过程会更稳，但需求容易停留在聊天或临时设计文档里。 如果只用 OpenSpec，需求和规格更清楚，但 agent 执行时仍可能跳步骤、少测试或扩范围。 两者结合后，比较理想的分工是： Superpowers：帮助想清楚、拆清楚、按 TDD 做清楚。 OpenSpec：把确认后的需求变成仓库里的正式规格。 整体流程 我最终采用的流程是： Superpowers brainstorming/spec -> OpenSpec change -> OpenSpec validate/review -> Superpowers implementation plan -> Superpowers TDD execution -> Review/verify -> OpenSpec archive 每一步都有明确边界。最关键的一点是：Superpowers 先帮助形成设计共识，但一旦 OpenSpec change 被确认，OpenSpec 就成为唯一需求基线。 这样做是为了避免需求源冲突： Superpowers 草稿说 A OpenSpec change 说 B 代码到底按哪个做？ 所以进入实现阶段后，规则应该是：