两种模式深度分析

Compound Engineering 模式详解

方法论架构

Compound Engineering 采用 分层架构设计，每一层都有明确的职责边界和交付物标准。这种架构设计使得 CE 不仅是一个 workflow 工具，更是一套完整的 Agent 工程体系。

flowchart TB
    subgraph "决策层"
        A1[用户需求] --> A2[/ce:plan<br/>知识感知规划]
        A2 --> A3[结构化 Plan
        包含历史 Learnings]
    end
    
    subgraph "执行层"
        A3 --> B1[/ce:work<br/>增量执行]
        B1 --> B2[Feature 1]
        B1 --> B3[Feature 2]
        B1 --> B4[Feature N]
    end
    
    subgraph "审查层"
        B2 --> C1[/ce:review<br/>多维度审查]
        B3 --> C1
        B4 --> C1
        C1 --> C2[6-15 个专项 Reviewer]
        C2 --> C3[P0-P3 级别报告]
    end
    
    subgraph "知识层"
        C3 --> D1[/ce:compound<br/>知识提取]
        D1 --> D2[结构化文档]
        D2 --> D3[docs/solutions/]
        D3 --> D4[知识库<br/>供未来 Session 搜索]
    end
    
    D4 -.->|Learnings Research| A2
    
    style D4 fill:#9f6

核心优势深度分析

1. 知识感知规划（Knowledge-Aware Planning）

传统 AI Agent 的 planning 存在 context 局限性：只基于当前 prompt 的上下文，忽略了项目的历史知识。CE 通过 /ce:plan 的 research agents 解决了这个问题。

运作机制：

sequenceDiagram
    participant User
    participant PlanAgent as /ce:plan
    participant Research1 as Research Agent 1
    participant Research2 as Research Agent 2
    participant Research3 as Research Agent 3
    participant Knowledge as Knowledge Base
    participant Output as 结构化 Plan
    
    User->>PlanAgent: 提交任务
    par 并行 Research
        PlanAgent->>Research1: 搜索历史经验
        Research1->>Knowledge: 查询 docs/solutions/
        Research1-->>PlanAgent: 相关 Learnings
    and
        PlanAgent->>Research2: 扫描 Codebase
        Research2->>PlanAgent: 现有 Patterns
    and
        PlanAgent->>Research3: 读取 Git History
        Research3->>PlanAgent: 近期变更
    end
    PlanAgent->>PlanAgent: 综合分析
    PlanAgent->>Output: 生成知识感知 Plan
    Output-->>User: 包含历史坑点提醒

实际价值案例：

假设你在开发一个 Next.js 项目，需要处理 Edge Runtime 的兼容性问题：

• 传统方式：Agent 可能会重复尝试之前失败的方案，浪费大量 token 和时间
• CE 方式：/ce:plan 的 learnings-researcher 自动发现三周前记录的相关 learning，Plan 中直接标注：“注意：之前遇到 Edge Runtime fetch API 兼容性问题，解决方案参考 docs/solutions/edge-runtime-fetch-fix.md”

量化效果：

根据实际使用反馈，知识感知规划可以将 重复问题的解决时间减少 60-80%。因为你不需要重新踩一遍别人（或你自己）已经踩过的坑。

2. 多维度并行审查（Multi-dimensional Parallel Review）

CE 的 /ce:review 不仅仅是代码审查，更是一个 系统性质量保障体系。

Reviewer 矩阵：

并行执行架构：

flowchart LR
    A[代码变更] --> B[Orchestrator]
    B --> C1[Correctness]
    B --> C2[Security]
    B --> C3[Performance]
    B --> C4[Testing]
    B --> C5[Maintainability]
    B --> C6[Adversarial]
    B --> C7[Learnings]
    B --> C8[Standards]
    
    C1 --> D[汇总报告]
    C2 --> D
    C3 --> D
    C4 --> D
    C5 --> D
    C6 --> D
    C7 --> D
    C8 --> D
    
    D --> E{是否存在 P0?}
    E -->|是| F[阻止合并]
    E -->|否| G[通过审查]

对比分析：

Superpowers 的 2 个 reviewer（spec + quality）在覆盖面上的局限：

• 可能遗漏安全漏洞（security reviewer 缺失）
• 可能忽略性能隐患（performance reviewer 缺失）
• 无法识别历史模式重复（learnings-researcher 缺失）

CE 的 6-15 个 reviewer 确保 每个维度都有专家把关。

3. 指数型知识积累（Exponential Knowledge Accumulation）

这是 CE 最具革命性的特性，也是与 Superpowers 的本质区别。

线性 vs 指数：

flowchart TB
    subgraph "传统模式 Linear"
        A1[Session 1] --> A2[Session 2]
        A2 --> A3[Session 3]
        A3 --> A4[...]
        
        style A1 fill:#f96
        style A2 fill:#f96
        style A3 fill:#f96
    end
    
    subgraph "CE 模式 Exponential"
        B1[Session 1] --> B2[Session 2]
        B2 --> B3[Session 3]
        B3 --> B4[...]
        
        B1 -.->|compound| K1[Knowledge 1]
        B2 -.->|compound| K2[Knowledge 2]
        B3 -.->|compound| K3[Knowledge 3]
        
        K1 -.->|searchable| B2
        K1 -.->|searchable| B3
        K2 -.->|searchable| B3
        K1 -.->|searchable| B4
        K2 -.->|searchable| B4
        K3 -.->|searchable| B4
        
        style K1 fill:#9f6
        style K2 fill:#9f6
        style K3 fill:#9f6
    end

关键洞察：

• 传统模式（包括 Superpowers）：每个 session 独立，知识无法传递
• CE 模式：每个 session 产生的知识成为公共资产，所有未来 session 都能受益

知识库的复利效应：

数据基于典型中型项目的实际使用经验估算

文档质量标准：

CE 对 compound 生成的文档有严格的结构要求：

---
category: runtime-compatibility
tags: [edge-runtime, fetch-api, bug-fix]
components: [api-routes, middleware]
symptoms: ["TypeError: fetch is not a function"]
severity: P1
---

# Edge Runtime Fetch API 兼容性问题

## Problem
在 Edge Runtime 中使用原生 fetch API 时出现 TypeError，原因是...

## What Didn't Work
1. ❌ 尝试使用 node-fetch - Edge Runtime 不支持 Node.js 模块
2. ❌ 尝试使用 cross-fetch - 同样的问题
3. ❌ 尝试在 next.config.js 中配置 - 不生效

## Solution
使用 Next.js 内置的 fetch polyfill：

\`\`\`typescript
// 不需要 import，直接使用全局 fetch
const res = await fetch(url, options);
\`\`\`

## Prevention
- Edge Runtime 只能使用 Web 标准 API
- 避免依赖 Node.js 特定模块
- 参考 docs/architecture/edge-runtime-limitations.md

这种结构化的文档使得 learnings-researcher 可以 精确匹配 问题类型、组件、症状，提供高度相关的建议。

局限性与挑战

1. 学习曲线较陡

CE 的复杂性带来了更高的学习门槛：

• 需要理解 /ce:plan、 /ce:work、 /ce:review、 /ce:compound 四个命令的协作关系
• 需要建立维护知识库的意识（什么时候 compound，如何组织文档）
• 需要适应多 reviewer 的审查报告解读

适用人群：

• ✅ 有软件工程背景，理解模块化、分层架构的开发者
• ✅ 需要长期维护项目的团队
• ❌ 偶尔使用 AI 编程的 casual user
• ❌ 追求快速原型验证的探索型开发者

2. 工具链依赖

CE 目前主要面向 Claude Code 设计，虽然最近添加了 CLI 转换工具支持多种格式，但：

• 原生体验最佳的仍是 Claude Code
• 其他工具（Cursor、Codex CLI）可能需要额外配置
• 生态成熟度不如 Superpowers

3. 知识库维护成本

知识库需要主动维护，否则会产生问题：

• 文档膨胀：如果不筛选，低价值文档会淹没高质量知识
• 过时知识：技术栈升级后，旧文档可能产生误导
• 分类混乱：缺乏规范会导致文档难以检索

最佳实践建议：

• 建立文档review机制，定期清理过时内容
• 严格执行 YAML frontmatter 规范，确保可检索性
• 作者建议的 “compound janitor” 方案值得尝试

Superpowers 模式详解

方法论架构

Superpowers 采用 线性工作流设计，强调简洁和标准化。其架构清晰直观：

flowchart LR
    A[Brainstorm<br/>头脑风暴] --> B[Plan<br/>规划]
    B --> C[Execute<br/>执行]
    C --> D[Review<br/>审查]
    D --> E[Done<br/>完成]
    
    style A fill:#9f6
    style B fill:#9f6
    style C fill:#9f6
    style D fill:#9f6

核心优势深度分析

1. 极低的学习门槛

Superpowers 的最大优势在于 零门槛上手。

用户旅程：

第 1 分钟：安装 skill
第 5 分钟：理解四个阶段
第 15 分钟：完成第一个任务

对比 CE 的学习曲线：

第 1 分钟：安装 skill
第 30 分钟：理解四个命令的关系
第 2 小时：完成第一个任务
第 1 周：建立使用知识库的意识

为什么重要：

对于绝大多数开发者，AI Agent 工具是辅助手段而非核心工作流。他们不愿意投入大量时间学习复杂的工具链。Superpowers 的完美之处在于：它以最小的认知负担提供了显著的效率提升。

2. 跨工具兼容性

Superpowers 的一个独特优势是 原生跨工具兼容：

实际价值：

如果你的团队使用多种 AI 编程工具，Superpowers 可以提供一致的工作流体验。这对于：

• 多工具实验阶段（评估哪个工具最适合团队）
• 个人在不同项目间切换（不同项目使用不同工具）
• 避免 vendor lock-in

3. 标准化价值

Superpowers 帮助团队建立 统一的 AI 辅助开发标准：

之前：

• 开发者 A：“我跟 AI 聊聊天就写好了”
• 开发者 B：“我会先写详细 prompt”
• 开发者 C：“我让 AI 直接改代码”

之后：

• 所有人：“按照 brainstorm → plan → execute → review 的流程走”

这种标准化带来的好处：

• 可预测性：每个任务都经过相同的质量控制环节
• 可协作性：团队成员可以接手他人的任务，因为流程一致
• 可改进性：可以基于标准流程做系统性优化

局限性与挑战

1. Plan 阶段的 Context 局限

Superpowers 的 plan 阶段仅在当前 context 内进行，不主动挖掘项目历史知识。

问题场景示例：

假设你在维护一个遗留项目，需要添加一个新功能：

• Superpowers：Agent 根据当前代码写 plan，可能提出与项目架构不符的方案
• CE：Agent 搜索历史 learnings，发现 “项目使用 Repository Pattern 而非直接数据库访问”，plan 中体现这一约束

量化影响：

在大型或遗留项目中，缺乏历史知识可能导致：

• 30-50% 的 plan 需要重新调整
• 架构不一致带来的技术债务
• 重复踩之前解决过的问题

2. Review 覆盖面不足

Superpowers 的 2 个 reviewer（spec + quality）在复杂场景下可能遗漏重要问题：

典型遗漏场景：

// 示例：SQL 注入漏洞可能被 quality reviewer 遗漏
app.get('/user', (req, res) => {
  const query = `SELECT * FROM users WHERE id = ${req.query.id}`;
  // 这里存在 SQL 注入风险
  // spec reviewer：功能符合需求 ✅
  // quality reviewer：代码风格正确 ✅
  // security reviewer（Superpowers 缺失）：发现注入风险 ❌
});

风险评估：

3. 关键缺陷：无知识积累机制

这是 Superpowers 的根本性局限，也是作者选择切换到 CE 的核心原因。

影响分析：

flowchart TB
    subgraph "第 1 个月"
        A1[Session 1] --> A2[Session 2]
        A2 --> A3[Session 3]
    end
    
    subgraph "第 3 个月"
        B1[Session 50] --> B2[Session 51]
        B2 --> B3[Session 52]
        
        note1[和第一个月一样的效率<br/>每次从零开始]
    end
    
    subgraph "第 6 个月"
        C1[Session 100] --> C2[Session 101]
        C2 --> C3[Session 102]
        
        note2[仍然一样的效率<br/>没有积累，没有复利]
    end

对比 CE 的积累效应：

• Superpowers 用户：6 个月后，解决第 100 个问题的时间和解决第 1 个问题的时间基本相同
• CE 用户：6 个月后，解决第 100 个问题可能只需要第 1 个问题的 20% 时间，因为 80% 的问题类型已经在知识库中有记录

何时这个缺陷致命：

• ✅ 长期维护的项目（6 个月以上）
• ✅ 多人协作的团队（知识需要共享）
• ✅ 复杂领域（学习成本高，需要积累）

何时这个缺陷可接受：

• ✅ 一次性原型/POC
• ✅ 短期项目（<1 个月）
• ✅ 个人 side project
• ✅ 探索性开发（快速验证想法）

两种模式的 Trade-off 分析

架构复杂度 vs 长期价值

quadrantChart
    title 复杂度 vs 长期价值矩阵
    x-axis 低长期价值 --> 高长期价值
    y-axis 低复杂度 --> 高复杂度
    
    quadrant-1 短期使用
    quadrant-2 生产项目首选
    quadrant-3 避免使用
    quadrant-4 值得投资
    
    "Superpowers": [0.4, 0.2]
    "Compound Engineering": [0.9, 0.8]
    "gstack": [0.6, 0.3]
    "Raw Prompting": [0.1, 0.1]

适用场景对比

团队成熟度匹配

flowchart LR
    A[团队 AI Agent 成熟度] --> B{阶段判断}
    
    B -->|初级<br/>刚接触 AI 编程| C[Superpowers<br/>建立标准化意识]
    B -->|中级<br/>有使用经验| D[评估切换 CE<br/>开始积累知识]
    B -->|高级<br/>深度使用| E[CE + 自定义<br/>优化知识库流程]
    
    C --> F[目标：建立流程规范]
    D --> G[目标：提升长期效率]
    E --> H[目标：团队知识资产化]