BMAD vs. Superpowers的最佳实践对比

1. 核心治理模型 (Governance Model)

维度 BMAD Method Superpowers
治理核心 文档治理 (Document Governance) 测试治理 (Test Governance)
真理来源 Markdown 文档 (tech-spec.md) 是绝对真理。代码必须服从文档。 测试用例 (*.test.ts) 是绝对真理。代码必须通过测试。
错误修正 回到上游:如果代码写错了,首先检查/修改 Spec 文档,然后重新生成。 就地修正:如果测试挂了,分析报错日志,修改代码直到变绿。
人类角色 产品拥有者 (PO):负责验收文档和决策功能范围。 工程主管 (Tech Lead):负责审查测试覆盖率和架构合理性。

2. 规划阶段最佳实践 (Planning Phase)

BMAD: “Scale-Adaptive Planning” (规模自适应规划)

  • 分层推进:严禁直接跳到代码。必须遵循 Product Brief -> PRD -> Tech Spec 的顺序。
  • 上下文工程 (Context Engineering):在生成文档时,显式地将相关文件(如现有的数据库 Schema、API 接口定义)喂给 Agent,而不是让 Agent 猜测。
  • 人类审批门禁 (Human Gate):每个文档生成后,人类必须进行 review。最佳实践是:人类主要修改文档,而不是修改代码。只要文档足够精确,代码生成就是确定性的。
  • Prompt 隔离:使用不同的 Agent 角色(Analyst vs Architect)来避免思维污染。

Superpowers: “Atomic Planning” (原子化规划)

  • 微型计划 (Micro-Plans):使用 /plan 指令。计划不应超过 5 个步骤。最佳实践:如果计划太长,Agent 会迷失,必须拆分。
  • YAGNI 原则:明确指示 Agent “You Aren’t Gonna Need It”。严禁过度设计。
  • Think -> Plan -> Act:在执行任何 shell 命令前,强制 Agent 先输出 <thinking><plan> 标签。
  • 工具先行:在写代码前,先确认工具链(如 npm test 命令)是否可用。

3. 执行与编码最佳实践 (Implementation Phase)

BMAD: “Context-Rich Generation” (富上下文生成)

  • 全量生成优先:倾向于让 Agent 一次性生成或重写整个文件,而不是应用小的 diff(因为 LLM 在定位行号时容易出错)。
  • 引用规范:在 Prompt 中明确引用 tech-spec.md 的具体章节(例如:“根据 Spec 第 3 节实现接口”)。
  • 保持对话清洁:一个 Task 结束后,建议开启新的对话窗口(New Chat),仅重新加载必要的 Markdown 上下文,防止旧对话的幻觉干扰。

Superpowers: “TDD & Isolation” (测试驱动与隔离)

  • Git Worktree 隔离绝对核心的最佳实践。永远不要在 main 分支上直接让 Agent 写代码。
    • 流程git worktree add ... -> npm install -> Coding -> Test -> Merge -> git worktree remove
    • 价值:Agent 搞砸了?直接删掉文件夹,主分支毫发无损。
  • Red-Green-Refactor
    1. Red: 先写测试,确认它失败(防止假阳性测试)。
    2. Green: 写最少的代码通过测试。
    3. Refactor: 在测试保护下重构。
  • 自主循环:允许 Agent 在遇到错误时自主运行 npm test 读取错误日志并重试(Self-Healing)。

4. 上下文与记忆管理 (Context & Memory)

维度 BMAD Method Superpowers
记忆载体 .md 文件。项目根目录下的 docs/ 文件夹是项目的“海马体”。 CLI Scrollback / Token Window。依赖 Claude 的长上下文窗口。
最佳实践 更新文档。如果需求变更,必须先更新 Markdown,再让 Agent 读文档。不要口头告诉 Agent 变更。 /compact 指令。定期使用 /compact 压缩上下文,清除无效的尝试和错误日志,保持 Token 效率。
知识检索 手动/自动引用。用户使用 @file 引用文档。 工具检索。Agent 使用 grep, ls, cat 自主探索代码库。

5. 什么时候用哪个?(场景化建议)

场景 A:从 0 到 1 构建复杂系统 (Greenfield Project)

  • 推荐BMAD 及其最佳实践
  • 理由:在没有代码的时候,你需要的是“结构”。BMAD 的 Analyst 和 Architect 角色能帮你把模糊的想法变成坚固的蓝图。
  • 操作:用 BMAD 生成完整的目录结构和接口定义,直到你看到满意的 tech-spec.md

场景 B:在千万行代码库中修 Bug (Legacy Maintenance)

  • 推荐Superpowers 及其最佳实践
  • 理由:你需要的是“外科手术式的精准度”。BMAD 可能会因为上下文过载而晕头转向。
  • 操作
    1. 用 Superpowers 创建一个 Worktree。
    2. 写一个复现 Bug 的测试用例(Reproduction Script)。
    3. 让 Agent 修补代码直到测试通过。
    4. 合并。

场景 C:日常功能迭代 (Feature Development)

  • 推荐融合模式 (Hybrid Mode)
  • 最佳实践流程
    1. [BMAD] 在 IDE 里与 PM Agent 对话,更新 tech-spec.md,明确新功能的接口。
    2. [Superpowers] 打开终端,告诉 Claude:“Read docs/tech-spec.md. Implement the feature using TDD in a new worktree.”
    3. [Superpowers] Claude 自动跑测试、提交代码。
    4. [Human] Merge 代码。

6. 总结:心法口诀

  • BMAD 的心法是“谋定而后动”。它认为代码只是文档的副产品。如果你不能用自然语言清晰地描述它,AI 就无法正确地编写它。
  • Superpowers 的心法是“实践出真知”。它认为代码是会撒谎的,只有运行起来的测试不会。不管 AI 觉得自己写得多好,跑不通测试就是垃圾。
Logo

有“AI”的1024 = 2048,欢迎大家加入2048 AI社区

更多推荐