用 BMAD 做“大脑”来思考,用 Superpowers 做“双手”来干活
BMAD 的心法是“谋定而后动”。它认为代码只是文档的副产品。如果你不能用自然语言清晰地描述它,AI 就无法正确地编写它。Superpowers 的心法是“实践出真知”。它认为代码是会撒谎的,只有运行起来的测试不会。不管 AI 觉得自己写得多好,跑不通测试就是垃圾。
·
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:
- Red: 先写测试,确认它失败(防止假阳性测试)。
- Green: 写最少的代码通过测试。
- 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 可能会因为上下文过载而晕头转向。
- 操作:
- 用 Superpowers 创建一个 Worktree。
- 写一个复现 Bug 的测试用例(Reproduction Script)。
- 让 Agent 修补代码直到测试通过。
- 合并。
场景 C:日常功能迭代 (Feature Development)
- 推荐:融合模式 (Hybrid Mode)。
- 最佳实践流程:
- [BMAD] 在 IDE 里与 PM Agent 对话,更新
tech-spec.md,明确新功能的接口。 - [Superpowers] 打开终端,告诉 Claude:“Read
docs/tech-spec.md. Implement the feature using TDD in a new worktree.” - [Superpowers] Claude 自动跑测试、提交代码。
- [Human] Merge 代码。
- [BMAD] 在 IDE 里与 PM Agent 对话,更新
6. 总结:心法口诀
- BMAD 的心法是“谋定而后动”。它认为代码只是文档的副产品。如果你不能用自然语言清晰地描述它,AI 就无法正确地编写它。
- Superpowers 的心法是“实践出真知”。它认为代码是会撒谎的,只有运行起来的测试不会。不管 AI 觉得自己写得多好,跑不通测试就是垃圾。
更多推荐


所有评论(0)