第十章：常见问题解答

常规问题

如果你刚接触 Superpowers，以下是推荐的阅读路径：

之后，深入研究适合你工作流程的章节：TDD（第五章）、调试（第六章）、代码审查（第七章）或 Git Worktrees（第八章）。

另外，请查看**实际应用案例**部分，了解 Superpowers 如何在实际场景中应用——从独立功能开发到团队调试和并行重构。

Superpowers 设计为可与多个 AI 编程平台配合使用：

每个平台使用相同的 skill 文件和 CLAUDE.md 配置。特定平台的差异（如有）记录在引入该支持的版本的发布说明中。

不使用 Superpowers 的 AI 编程 agent，就像使用强大工具却没有安全手册一样。Agent 有能力，但没有关于质量的强制纪律、没有系统化的调试规范，也没有针对最常见失败模式的保障措施。

使用 Superpowers：

结果不是一个更慢的 agent——而是一个你可以信任其工作成果的 agent。在调试、回滚和整理混乱代码库上节省的时间，远远超过了前期严谨性所花费的时间。

可以。Superpowers 特别适合团队环境，因为它在所有使用 AI agent 的团队成员之间强制执行一致的实践。

推荐的团队设置：

将 CLAUDE.md 提交到仓库。 所有团队成员使用相同的配置。在项目上工作的 AI agent 遵循相同的规则。
提交 .claude/skills/ 目录。 Skills 是共享的。为项目创建的自定义 skills 对所有人都可用。
执行 worktree 隔离策略。 每个开发者和每个 AI agent 都在隔离的 worktree 中工作。Main 分支保护规则防止直接 commit。
使用基于 PR 的代码审查。 代码审查规范（第七章）直接与 GitHub/GitLab 工作流集成。

通过这种设置，为一个团队成员工作的 AI agent 遵循与为另一个人工作的 AI agent 相同的标准——或者遵循团队编码标准的人类开发者。

是的。TDD 是强制的。没有例外。

这是铁律一："没有先有失败测试，就不得编写任何生产代码。"

常见的例外论点及其被拒绝的原因：

"这只是小变更。" 小变更也会引入 bug。为小变更编写测试的时间成本以分钟计。调试未经测试的小变更造成的回归的时间成本以小时计。

"我们在快速推进，以后再加测试。" 实现后添加的测试是围绕实现而非需求塑造的。它们测试代码做了什么，而不是它应该做什么。它们提供虚假的信心。"以后"很少真的到来。

"代码是 UI，很难测试。" UI 行为是可以测试的。组件测试、快照测试、交互测试和端到端测试都存在。难度不是豁免的理由。

"我知道这段代码是正确的。" 这是最危险的论点。你未来的自己，或一位同事，不会分享你当前的确定性。测试记录了这种确定性并将其保存下来。

模型选择取决于任务需求：

对于 Gemini CLI 用户：Gemini 2.0 Flash 推荐用于实现任务；Gemini 2.5 Pro 用于架构和规划。

对于 Cursor 用户：在 Cursor 的 composer 中使用 Claude Sonnet 模型进行功能工作。Cursor 内置聊天可以使用较小的模型来回答快速问题。

本指南中描述的铁律和规范，无论你使用哪个平台都适用。具体的调用机制不同，但它们强制执行的行为是相同的。

检查 skill 文件是否存在于你平台的正确位置。
验证 skill 文件中的触发描述。 触发条件必须与你用来调用它的语言匹配。
明确指定。 不要期待 agent 推断正确的 skill，而是直接命名它："对此使用 superpowers:systematic-debugging skill。"
检查冲突。 如果两个 skills 具有重叠的触发条件，agent 可能会选择错误的一个。检查你的 skill 配置。
重新阅读 skill 文件。 当代码库更改时，skills 可能会过时。Skill 可能触发正确，但产生的建议不再适用。