现在 Claude 写实现代码# zodiac.py ZODIAC_DATES [ (1, 20, 水瓶座), (2, 19, 双鱼座), (3, 21, 白羊座), (4, 20, 金牛座), (5, 21, 双子座), (6, 21, 巨蟹座), (7, 23, 狮子座), (8, 23, 处女座), (9, 23, 天秤座), (10, 23, 天蝎座), (11, 22, 射手座), (12, 22, 摩羯座), ] def get_zodiac(month: int, day: int) - str: 根据月份和日期返回对应星座名称。 Args: month: 月份整数 1-12 day: 日期整数 1-31 Returns: str: 中文星座名称 Raises: ValueError: 当 month 或 day 超出有效范围时 if not (1 month 12): raise ValueError(f月份必须在 1-12 之间收到: {month}) if not (1 day 31): raise ValueError(f日期必须在 1-31 之间收到: {day}) for cutoff_month, cutoff_day, zodiac_name in ZODIAC_DATES: if month cutoff_month or (month cutoff_month and day cutoff_day): return zodiac_name # 12 月 22 日及之后都是摩羯座 return 摩羯座再次运行测试pytest test_zodiac.py -vtest_zodiac.py::TestGetZodiac::test_aries PASSED test_zodiac.py::TestGetZodiac::test_taurus PASSED test_zodiac.py::TestGetZodiac::test_gemini PASSED test_zodiac.py::TestGetZodiac::test_cancer PASSED test_zodiac.py::TestGetZodiac::test_leo PASSED test_zodiac.py::TestGetZodiac::test_virgo PASSED test_zodiac.py::TestGetZodiac::test_libra PASSED test_zodiac.py::TestGetZodiac::test_scorpio PASSED test_zodiac.py::TestGetZodiac::test_sagittarius PASSED test_zodiac.py::TestGetZodiac::test_capricorn PASSED test_zodiac.py::TestGetZodiac::test_aquarius PASSED test_zodiac.py::TestGetZodiac::test_pisces PASSED test_zodiac.py::TestGetZodiac::test_boundary_capricorn_to_aquarius PASSED test_zodiac.py::TestGetZodiac::test_boundary_pisces_to_aries PASSED test_zodiac.py::TestGetZodiac::test_invalid_month_zero PASSED test_zodiac.py::TestGetZodiac::test_invalid_month_thirteen PASSED test_zodiac.py::TestGetZodiac::test_invalid_day_zero PASSED test_zodiac.py::TestGetZodiac::test_invalid_day_thirty_two PASSED 18 passed in 0.12s所有测试通过GREEN 状态。第 5 步Code Review/superpowers:requesting-code-reviewClaude 会按 critical/warning/info 三个级别对代码做评审。典型输出Critical: 无 Warning: - day 验证只检查 1-31但 2 月没有 29-31 日4/6/9/11 月没有 31 日。 建议如果业务不关心这个精度可以在 docstring 里注明不验证日期是否在该月真实存在。 Info: - ZODIAC_DATES 数据结构可以改用 namedtuple 提高可读性 - 函数在处理 12 月 22 日之后的边界依赖 遍历完都不匹配则返回摩羯座 的逻辑建议加注释明确这个意图没有 critical 问题可以继续。Warning 里的日期精度问题是一个真实的边界条件这里根据 Brainstorming 阶段的约定用固定边界日期不精确验证选择接受在 docstring 里加注明即可。整个流程走下来大约 25-30 分钟。这个时间里你不只是得到了一个能跑的函数——你得到了一个有 18 个测试用例覆盖、清晰文档、通过 Code Review 的函数以及一份记录了所有设计决策的对话历史。这就是 Superpowers 的工作方式。和裸用 Claude Code 的真实差距说「有用」不够得说清楚差在哪里在什么量级上有差距。裸 Claude Code 的典型问题模式第一次跑90% 功能正常测试覆盖 40-60%代码风格因上下文而异。这个阶段感觉很爽。第五次迭代开始看到函数长度膨胀边界条件处理不一致某些模块和别的模块存在隐式假设耦合。这个阶段开始有点烦。第十次迭代遇到 regression bug 的概率显著上升。因为没有系统性测试修一个问题可能破坏另一个你没意识到的地方。这个阶段开始让人头疼。用 Superpowers 之后的差异任务颗粒度强制细化2-5 分钟一个任务这意味着每次子 Agent 出错影响范围被限制在一个原子任务内而不是蔓延到整个功能。这个设计让第三小时的代码质量接近第一小时——在裸 Claude Code 模式下通常到第二小时中段质量就开始明显下滑。测试覆盖目标 85-95%不是有测试就行。chardet v7.0.0 的案例是迄今为止有记录的 Superpowers 最大规模实测41 倍性能提升、准确率从 94.5% 提升到 96.8%覆盖 2161 个测试文件、99 种编码。这不是统计噪音是系统性 TDD 约束带来的可信结果。但代价也是真实的一个简单的 bug fix套完整 7 阶段流程会明显比直接让 Claude 修慢。Superpowers 的设计取向是明确的——它是为中大型功能开发优化的不是为一行代码的快速修改。评估是否值得用最简单的判断标准是这个改动如果出了问题修复成本是否超过 30 分钟是的话走 Superpowers 流程值得。和 GSD、gstack 的定位差异Claude Code 生态里现在有三个主要的工作流框架值得认真比一下定位方便你选型——它们解决的根本上是三种不同的问题不是同一个问题的三种解法。Superpowers204K stars约束开发流程本身。核心假设是AI 写的代码在没有测试约束的情况下会随时间积累隐患。框架的解法是把 TDD、计划先行、子 Agent 隔离这些工程实践强制编码进每次开发流程让 Claude 没有机会走捷径。适合需要测试覆盖和代码质量保证的功能开发尤其是那些三个月后还要维护的代码。弱点是单一协调 Agent 在极长任务超过一天的工作量中仍然会遇到上下文限制这个问题 GSD 处理得更好。GSD51K stars约束执行环境。核心假设是Agent 上下文会随工作时间增长而腐化导致质量下滑。框架的解法是 phase-based orchestration——把工作拆成原子任务每个任务派一个新的 Claude 实例新鲜 200K token 上下文执行协调 Agent 始终保持在上下文容量的 50% 以内状态通过 Markdown 文件持久化。Pulumi 的数据显示GSD 在 50 文件的大型项目上可以把第三小时的代码质量维持在接近第一小时的水平。适合跨天的长任务、多个并行工作流、或者需要在中途 crash 后恢复的场景。弱点是相比 Superpowers它对 TDD 的约束要弱一些——它更关注任务能完成不强制关注测试覆盖率。gstack71K stars约束决策视角。核心假设是单一 Agent 视角会有盲点代码写出来了但可能方向本身就是错的。框架的解法是 23 个角色CEO、产品经理、QA 负责人、工程师、安全审计员……让 Claude 以不同身份审视同一段代码防止只有工程师视角的判断盲区。对需要产品和技术并行思考的独立开发者很有价值——做一个面向消费者的产品时纯工程视角往往会忽略用户体验和商业逻辑的优先级。但写代码本身不是它的强项它更像是一个决策审查工具而不是开发流程工具。选择思路如果你的核心问题是AI 写的代码缺少工程纪律三个月后会成为技术债选 Superpowers。如果你的问题是长任务超过 4 小时中途 Claude 开始犯错上下文腐化选 GSD。如果你的问题是代码写出来了但不确定方向对不对需要从 PM 和用户视角再看一遍试试 gstack。三个框架定位基本不重叠用错了框架解决不了问题。图三个主流 Claude Code 工作流框架的核心定位对比数据截至 2026 年 5 月常见问题QSuperpowers 会不会让 Claude Code 变得很慢会增加时间但这个时间花得值不值取决于任务规模。对于一个需要 3-5 个迭代周期、后续还要维护的功能模块整个 Superpowers 流程通常比直接开写慢 20-30%——前期 Brainstorming 和 Writing Plans 大约多花 10-20 分钟但产出的代码有 85% 测试覆盖后续遇到需求变更时的修改成本大幅降低。对于单行 bug fix 或 quick prototype不打算长期维护直接用裸 Claude Code 更合适。一个实用的判断标准这个改动如果出了问题修复成本超过 30 分钟吗是的话走 Superpowers 流程值得。QSKILL.md 文件能自定义吗完全可以。每个 SKILL.md 就是普通的 Markdown 文件可以修改 TDD 的覆盖率要求、调整 Brainstorming 的问题列表、加入团队特有的代码规范检查比如加一条所有函数必须有 type hints。框架把工程文化编码成文件而不是锁进平台。v5.1.0 还加入了writing-skills这个元技能帮你规范地写出新的 Skill——这个设计很有意思框架本身的扩展也要走 TDD 和 Code Review 流程保证新 Skill 的质量。Q只用 Claude Code不用 Cursor / Copilot还有必要装吗有。Superpowers 最核心的价值——TDD 强制、子 Agent 任务隔离、Brainstorming 前置——和你用哪个 IDE 无关和 AI 写代码时如何防止隐式假设积累直接相关。这是方法论层面的问题不是工具兼容性问题。Superpowers 同时支持 Claude Code、Cursor、Gemini CLI、Codex CLI、GitHub Copilot CLI同一套 Skill 文件在这些工具里都能工作。Q子 Agent 跳过 TDD 的问题解决了吗截至 v5.1.0 仍是已知问题部分缓解但未完全解决。问题根源是子 Agent 启动时不会自动继承主会话注入的 Superpowers 引导文档导致它有时不知道 TDD 的约束存在。框架在 SubagentStart hook 方向上做了部分缓解但没有完全解决。遇到子 Agent 跳过了测试直接写实现的情况手动触发一次using-superpowersSkill 可以把它拉回来——这个 Skill 的作用就是重新激活工程约束。Q这个框架在 Windows 上能用吗能。Superpowers 的执行层是 Claude Code平台兼容性由 Claude Code 本身保证。SKILL.md 文件本身是纯文本没有 OS 依赖。框架在 macOS、Linux、WindowsWSL 和原生上均有社区报告的成功使用案例。Q安装之后 Claude 的上下文消耗会增加多少引导注入大约 2000 tokens相当于 Claude 每次对话会多消耗约 1-2% 的上下文。对于 200K token 窗口的 Claude这个消耗可以忽略不计。框架设计的出发点之一就是极度轻量——2000 tokens 的引导是刻意控制的不是技术限制导致的。