---
url: /ai/zyh2cpbt/index.md
description: >-
  Compound Engineering 方法论介绍，通过 Plan → Work → Review → Compound
  循环让代码库随时间变得更容易维护和扩展。
---
# 使用 Compound Engineering 增强 Claude Code

## 什么是 Compound Engineering?

Compound Engineering 是由 Every 团队提出的一种新型软件开发方法论。它的核心理念是:**每一个工程工作单元都应该让后续的工作变得更容易,而不是更难**。

传统的代码库会随着时间的推移变得越来越难维护,因为每个新功能都会注入更多的复杂性。而 Compound Engineering 通过让每个功能、每次 bug 修复都能教会系统新的能力,使得代码库随着时间推移变得更容易理解、修改和信任。

## 核心哲学

### 传统开发的困境

大多数代码库随着时间的推移会变得越来越难维护:

* 每个新功能都增加复杂性
* 10年后,团队花在对抗系统上的时间比构建新功能的时间还多
* 代码库变得难以理解、修改和信任

### Compound Engineering 的解决方案

通过系统化的方法,让每次工作都能积累价值:

* Bug 修复能消除整类未来 bug
* 模式被编码后成为未来工作的工具
* 代码库随着时间变得更容易理解和修改

## 主循环:Plan → Work → Review → Compound

Compound Engineering 的核心是一个四步循环:

```
Plan → Work → Review → Compound → Repeat
```

前三个步骤(计划、工作、审查)对任何开发者来说都很熟悉。但第四个步骤(复利)才是 Compound Engineering 与其他工程方法的关键区别,也是价值积累的地方。

### 时间分配原则

* **计划和审查应该占工程师时间的 80%**
* **工作和复利占另外的 20%**
* 换句话说,大部分思考发生在代码编写之前和之后

## 1. Plan (计划)

计划将想法转化为蓝图,更好的计划产生更好的结果。

### 关键行动

* **理解需求**:要构建什么?为什么?存在什么约束?
* **研究代码库**:类似功能如何工作?存在什么模式?
* **外部研究**:框架文档说什么?既定的最佳实践是什么?
* **设计解决方案**:采用什么方法?哪些文件需要更改?
* **验证计划**:这是否合理?是否完整?

### Claude Code 命令

```bash
/workflows:plan Add email notifications when users receive new comments
```

这个命令会:

1. 启动三个并行研究代理:
   * `repo-research-analyst`:代码库模式
   * `framework-docs-researcher`:文档
   * `best-practices-researcher`:行业标准
2. `spec-flow-analyzer` 代理分析用户流程和边缘情况
3. 结果合并为结构化计划,包含受影响的文件和实施步骤

**高级模式** - `ultrathink` 模式:

* 启用扩展推理和更深入的研究
* 计划创建后自动运行 `/deepen-plan`
* 启动超过 40 个并行研究代理

## 2. Work (工作)

执行遵循计划,代理实现时开发者监控。

### 关键行动

* **设置隔离**:Git worktrees(仓库的隔离副本)或分支保持工作分离
* **执行计划**:代理逐步实现
* **运行验证**:每次更改后运行测试、linting 和类型检查
* **跟踪进度**:检查已完成的工作和剩余的工作
* **处理问题**:当出现问题时,调整计划

### Claude Code 命令

```bash
/workflows:work
```

这个命令分四个阶段运行:

1. **快速启动**:创建 git worktree 并设置分支
2. **执行**:实现每个任务并进行进度跟踪
3. **质量检查**:可选启动超过 5 个审查代理(Rails、TypeScript、安全、性能)
4. **交付**:运行 linting,创建 PR

每个阶段都有明确的进入和退出标准。

## 3. Review (审查)

此步骤在问题发布之前捕获它们。更重要的是,它为下一个循环捕获学习内容,成为 Compound Engineering 的基础。

### 关键行动

* **让多个代理审查输出**:多个专业审查者并行检查代码
* **优先级排序**:标记发现为 P1(必须修复)、P2(应该修复)或 P3(最好修复)
* **解决发现**:代理根据审查反馈修复问题
* **验证修复**:确认修复正确且完整
* **捕获模式**:记录出错的内容以防止复发

### Claude Code 命令

```bash
/workflows:review PR#123
```

启动超过 14 个专业代理并行运行:

#### 审查代理列表

**安全**

* `security-sentinel`:扫描 OWASP 十大漏洞、注入攻击、身份验证缺陷

**性能**

* `performance-oracle`:检测 N+1 查询、缺失索引、缓存机会

**架构**

* `architecture-strategist`:评估系统设计决策、组件边界
* `pattern-recognition-specialist`:识别设计模式、反模式和代码异味

**数据**

* `data-integrity-guardian`:验证迁移、事务边界
* `data-migration-expert`:检查 ID 映射、回滚安全性

**质量**

* `code-simplicity-reviewer`:强制执行 YAGNI,标记不必要的复杂性
* `kieran-rails-reviewer`:Rails 约定、Turbo Streams 模式
* `kieran-python-reviewer`:PEP 8 合规性、类型提示
* `kieran-typescript-reviewer`:类型安全、现代 ES 模式
* `dhh-rails-reviewer`:37signals 约定,简单胜于抽象

**部署**

* `deployment-verification-agent`:生成预部署检查清单和回滚计划

**前端**

* `julik-frontend-races-reviewer`:检测 JavaScript 和 Stimulus 控制器中的竞态条件

**代理原生**

* `agent-native-reviewer`:确保功能对代理可访问,不仅是对人类

### 输出格式示例

```
P1 - CRITICAL (must fix):
[ ] SQL injection vulnerability in search query (security-sentinel)
[ ] Missing transaction around user creation (data-integrity-guardian)

P2 - IMPORTANT (should fix):
[ ] N+1 query in comments loading (performance-oracle)
[ ] Controller doing business logic (kieran-rails-reviewer)

P3 - MINOR (nice to fix):
[ ] Unused variable (code-simplicity-reviewer)
[ ] Could use guard clause (pattern-recognition-specialist)
```

### 自动化解决

```bash
/resolve_pr_parallel
```

自动处理所有发现:

* P1 问题首先修复,然后是 P2
* 每个修复在隔离中运行,避免相互干扰
* 最后仍然需要手动审查生成的修复

## 4. Compound (复利) - 最重要的步骤

传统开发在第三步就停止了,但复利步骤才是价值所在。前三步(计划、工作、审查)产生一个功能。第四步产生一个每次都能更好地构建功能的系统。

### 关键行动

* **捕获解决方案**:问自己:什么有效?什么无效?可重用的见解是什么?
* **使其可查找**:添加 YAML frontmatter,确保用正确的元数据、标签和类别标记以便检索
* **更新系统**:将新模式添加到 CLAUDE.md(代理在每个会话开始时读取的文件)。必要时创建新代理
* **验证学习**:问自己:系统下次会自动捕获这个吗?

### Claude Code 命令

```bash
/workflows:compound
```

这个命令启动六个并行子代理:

1. `context analyzer`:理解问题
2. `solution extractor`:捕获有效的方法
3. `related docs finder`:链接到现有知识
4. `prevention strategist`:记录如何避免复发
5. `category classifier`:标记以便发现
6. `documentation writer`:格式化最终文档

它创建一个可搜索的 markdown 文档,带有 YAML frontmatter,未来的会话可以找到它。

## 为什么推荐 Compound Engineering?

### 1. 指数级效率提升

每个工作单元都让后续工作更容易,而不是更难:

* Bug 修复消除整类未来 bug
* 模式成为未来工作的工具
* 系统随着时间变得更智能

### 2. 系统化知识积累

* **CLAUDE.md**: 代理每个会话读取的指令文件
* **docs/solutions/**: 构建机构知识,每个解决的问题成为可搜索文档
* **todos/**: 跟踪工作项及其优先级和状态

### 3. 多代理并行审查

不是一个人审查代码,而是 14+ 专业代理并行审查:

* 每个代理专注于特定领域
* 发现按优先级排序
* 可以自动解决发现

### 4. 可扩展的工程实践

* 一个人可以维护多个产品
* 知识不依赖于特定的人
* 新团队成员可以快速上手

## 如何在 Claude Code 中使用

### 安装 Compound Engineering 插件

```bash
# 添加 Every 市场
claude /plugin marketplace add https://github.com/EveryInc/every-marketplace

# 安装 compound-engineering 插件
claude /plugin install compound-engineering
```

### 插件包含内容

* **26 个专业代理**:每个代理针对特定工作训练
* **23 个工作流命令**:包括主循环和实用程序
* **13 个技能**:提供领域专业知识,如代理原生架构技能和风格指南技能

### 目录结构

```
your-project/
├── CLAUDE.md           # 代理指令、偏好和模式
├── docs/
│   ├── brainstorms/    # /workflows:brainstorm 输出
│   ├── solutions/      # /workflows:compound 输出(分类)
│   └── plans/          # /workflows:plan 输出
└── todos/              # /triage 和审查发现
    ├── 001-ready-p1-fix-auth.md
    └── 002-pending-p2-add-tests.md
```

### 核心工作流命令

#### 1. 头脑风暴(不确定要构建什么时使用)

```bash
/workflows:brainstorm Add user notifications
```

帮助你头脑风暴构建什么以及如何构建的答案。在需求模糊时使用。

#### 2. 一键完整流程

```bash
/lfg Add dark mode toggle to settings page
```

这个命令链接完整的管道:

```
plan → deepen-plan → work → review → resolve findings → browser tests → feature video → compound
```

* 暂停等待计划批准
* 然后自主运行
* 在所有阶段启动超过 50 个代理
* 一个命令完成整个功能

## 如何用得更好

### 1. 采用新的思维方式

#### 放弃的信念

* ❌ "代码必须手写"
* ❌ "每行都必须手动审查"
* ❌ "解决方案必须源于工程师"
* ❌ "代码是主要产物"
* ❌ "编写代码是核心工作职能"
* ❌ "第一次尝试应该是好的"(实际上 95% 是垃圾,50% 第二次尝试仍是垃圾)
* ❌ "代码是自我表达"
* ❌ "更多打字等于更多学习"

#### 采用的信念

* ✅ **将品味提取到系统中**:将偏好记录在 CLAUDE.md 或 AGENTS.md 中
* ✅ **50/50 规则**:50% 时间构建功能,50% 时间改进系统
* ✅ **信任流程,构建安全网**:设置测试、自动审查和监控等防护栏
* ✅ **使环境代理原生**:如果开发者能看或做某事,代理也应该被允许
* ✅ **并行化是你的朋友**:同时运行多个代理和功能
* ✅ **计划是新代码**:计划文档是你产生的最重要的东西

### 2. 遵循采用阶段

#### Stage 0: 手动开发

不使用任何 AI 的传统开发方式。

#### Stage 1: 聊天辅助

将 AI 用作智能参考工具,复制粘贴有用的代码片段。

#### Stage 2: 代理工具与逐行审查

允许 AI 读取文件并直接在代码库中进行更改,但作为守门人批准或拒绝所有内容。

#### Stage 3: 计划优先,仅 PR 审查 ⭐

这是 Compound Engineering 真正开始的地方:

* 与 AI 协作制定详细计划
* 开发者离开,让 AI 在没有监督的情况下实现计划
* 输出是一个 pull request,然后你审查

#### Stage 4: 想法到 PR(单机)

提供想法,代理处理一切:

* 代码库研究
* 计划
* 实现
* 测试执行
* 自我审查
* 问题解决
* PR 创建

你的参与缩小到三个步骤:构思、PR 审查和合并。

#### Stage 5: 并行云执行(多设备)

将执行移至云端并并行运行:

* 可以从任何地方指导代理
* 同时启动三个功能
* 三个代理独立工作
* 在完成时审查 PR

### 3. 三个关键问题

即使没有多代理审查系统,在批准任何 AI 输出之前问这三个问题:

1. **"你在这里做出的最难的决定是什么?"**
   强制 AI 揭示棘手的部分以及它在哪里做出判断调用。

2. **"你拒绝了哪些替代方案,为什么?"**
   显示它考虑的选项,帮助捕获是否做出了错误选择。

3. **"你最不自信的是什么?"**
   让 AI 承认它可能在哪里出错。

### 4. 代理原生架构

确保代理具有与你相同的能力。使用检查清单验证:

#### 开发环境

* \[ ] 在本地运行应用程序
* \[ ] 运行测试套件
* \[ ] 运行 linter 和类型检查器
* \[ ] 运行数据库迁移
* \[ ] 填充开发数据

#### Git 操作

* \[ ] 创建分支
* \[ ] 进行提交
* \[ ] 推送到远程
* \[ ] 创建 pull request
* \[ ] 读取 PR 评论

#### 调试

* \[ ] 查看本地日志
* \[ ] 查看生产日志(只读)
* \[ ] 截取 UI 屏幕截图
* \[ ] 检查网络请求
* \[ ] 访问错误跟踪(Sentry 等)

### 5. 跳过权限(高级用户)

对于 Stage 3 或更高阶段,使用 `--dangerously-skip-permissions` 标志:

```bash
alias cc='claude --dangerously-skip-permissions'
```

**何时使用:**

* ✅ 信任流程
* ✅ 在安全环境中工作
* ✅ 想要速度

**何时不使用:**

* ❌ 正在学习
* ❌ 在生产环境中
* ❌ 没有良好的回滚机制

**安全机制:**

* Git 是你的安全网:`git reset --hard HEAD~1`
* 测试捕获错误
* 合并前审查
* Worktrees 隔离风险

## 最佳实践

### 1. 团队协作

**新的团队动态:**

* 传统:人员 A 编写代码 → 人员 B 审查 → PR 评论讨论 → 批准后合并
* Compound:人员 A 创建计划 → AI 实现 → AI 代理审查 → 人员 B 审查 AI 审查 → 人工批准后合并

**团队标准:**

* **计划批准**:沉默不是批准 - 需要明确的签署
* **PR 所有权**:发起工作的人拥有 PR,无论谁(或什么)编写了代码
* **人工审查焦点**:关注意图,而不是实现

### 2. 异步默认

Compound Engineering 很好地异步工作:

* 计划可以在不安排会议的情况下创建、审查和批准
* 尝试"我创建了一个计划文档 - 请在一天结束前评论"而不是"让我们见面讨论方法"

### 3. 清晰的交接

交接工作时包括:

* 状态
* 已完成的内容
* 剩余内容
* 上下文
* 如何继续

```markdown
## Handoff: Email Notifications
From: Kieran → To: Dan
Status: Plan approved, implementation 50 percent
What's left: User preference settings, unsubscribe flow
How to continue: Run /work in the feature branch
```

### 4. Vibe Coding(用于快速原型)

当不关心代码本身,只想要结果时:

```bash
/lfg Create a web app that lets me track my daily habits with checkboxes
```

**适用于:**

* 个人项目
* 原型
* 实验
* "这甚至可行吗?"调查
* 内部工具
* UX 探索

**不适用于:**

* 有用户的生产系统
* 其他人将维护的代码
* 安全敏感应用
* 性能关键系统

**Vibe Coding 悖论:**

* 在不知道要构建什么时生成原型
* 与用户分享并收集反馈
* 然后删除所有内容并使用适当的计划重新开始
* 规范总是赢得最终实现,但 vibe coding 加速发现

### 5. 用户研究结构化

结构化研究以便 AI 可以使用它:

```markdown
# research/interviews/user-123.md
---
participant: Marketing Manager, B2B SaaS
date: 2025-01-15
focus: Dashboard usage patterns
---

## Key Insights

### Insight: Morning dashboard ritual
**Quote**: "First thing every morning, I check for red flags."
**Implication**: Dashboard needs to surface problems quickly.
**Confidence** (4/5 participants)
```

## Skills 详细参考

Compound Engineering 插件提供了丰富的 skills（技能）来增强开发工作流。以下是每个 skill 的详细介绍、用法和使用场景。

### 🔷 核心工作流 Skills

#### 1. `ce:brainstorm` - 头脑风暴

::: details 点击查看详情
**描述**: 在编写需求文档和计划实现之前，通过协作对话探索需求和方法。回答 **WHAT**（构建什么）的问题。

**用法**:

```bash
/ce:brainstorm [功能想法或问题描述]
```

**使用场景**:

* 功能想法还在探索阶段
* 问题框架不清晰
* 用户说"让我们头脑风暴一下"
* 描述模糊或宏大的功能请求
* 询问"我们应该构建什么"
* 不确定范围或方向

**核心原则**:

* 先评估范围 - 匹配工作的大小和模糊性
* 做思考伙伴 - 建议替代方案，挑战假设
* 在这里解决产品决策 - 用户行为、范围边界、成功标准
* 默认不包含实现细节 - 不包含库、模式、端点等

**输出**: 生成需求文档（`docs/brainstorms/*-requirements.md`）
:::

***

#### 2. `ce:plan` - 技术计划

::: details 点击查看详情
**描述**: 将功能描述或需求转化为结构化的实施计划。回答 **HOW**（如何构建）的问题。

**用法**:

```bash
/ce:plan [功能描述或需求文档路径]
/ce:plan docs/brainstorms/my-feature-requirements.md
```

**使用场景**:

* 用户说"计划这个"、"创建计划"、"编写技术计划"
* 需求文档已准备好进行技术规划
* 需要深化现有计划

**核心原则**:

* 使用需求作为真理来源
* 捕获决策而非代码 - 方法、边界、文件、依赖、风险
* 结构化之前先研究 - 探索代码库、学习、外部指导
* 适当大小的产物 - 小工作用紧凑计划，大工作用更多结构

**计划质量标准**:

* 清晰的问题框架和范围边界
* 具体的需求可追溯性
* 仓库相对路径的文件列表
* 明确的测试文件路径
* 有理由的决策
* 现有模式或代码引用
* 枚举的测试场景

**输出**: 生成计划文档（`docs/plans/*.md`）
:::

***

#### 3. `ce:work` - 工作执行

::: details 点击查看详情
**描述**: 高效执行工作同时保持质量并完成功能。执行计划中的实现步骤。

**用法**:

```bash
/ce:work                           # 自动使用最新的计划文档
/ce:work docs/plans/my-plan.md     # 指定计划文档
/ce:work "添加用户认证功能"        # 简单描述
```

**使用场景**:

* 计划已批准，需要实现
* 执行计划中的任务
* 完成功能开发

**执行流程**:

**Phase 0: 输入分类**

* 计划文档 → 跳到 Phase 1
* 简单提示 → 扫描工作区域，评估复杂度

**复杂度评估**:
| 复杂度 | 信号 | 行动 |
|-------|------|------|
| 微小 | 1-2 文件，无行为变更 | 直接实现 |
| 小/中 | 范围清晰，<10 文件 | 构建任务列表 |
| 大 | 跨切面，架构决策，10+ 文件 | 建议先运行 `/ce:brainstorm` 或 `/ce:plan` |

**Phase 1: 快速启动**

1. 读取计划并澄清
2. 设置环境（分支或 worktree）
3. 验证开发环境

**Phase 2: 执行循环**

* 实现每个任务
* 运行验证
* 处理问题
* 跟踪进度
  :::

***

#### 4. `ce:review` - 代码审查

::: details 点击查看详情
**描述**: 使用分层角色代理、置信度门控发现和合并/去重管道进行结构化代码审查。

**用法**:

```bash
/ce:review                    # 审查当前分支
/ce:review 123                # 审查 PR #123
/ce:review https://github.com/owner/repo/pull/123
/ce:review mode:autofix       # 自动修复模式
/ce:review mode:report-only   # 仅报告模式
/ce:review base:origin/main   # 指定基准分支
```

**模式**:
| 模式 | 触发 | 行为 |
|------|------|------|
| **交互式** (默认) | 无模式标记 | 审查、自动修复、展示发现、询问策略决策 |
| **自动修复** | `mode:autofix` | 无用户交互，应用 `safe_auto` 修复 |
| **仅报告** | `mode:report-only` | 严格只读，审查并报告 |
| **无头** | `mode:headless` | 程序化模式，用于技能间调用 |

**严重性等级**:
| 级别 | 含义 | 行动 |
|------|------|------|
| **P0** | 关键损坏、可利用漏洞、数据丢失 | 合并前必须修复 |
| **P1** | 高影响缺陷，可能正常使用中遇到 | 应该修复 |
| **P2** | 中等问题（边缘情况、性能回归） | 如果简单则修复 |
| **P3** | 低影响、窄范围、小改进 | 用户决定 |

**审查代理** (14+ 并行代理):

* **安全**: `security-sentinel` - OWASP 漏洞扫描
* **性能**: `performance-oracle` - N+1 查询检测
* **架构**: `architecture-strategist`, `pattern-recognition-specialist`
* **数据**: `data-integrity-guardian`, `data-migration-expert`
* **质量**: `code-simplicity-reviewer`, `kieran-rails-reviewer`, `kieran-python-reviewer`, `kieran-typescript-reviewer`
* **部署**: `deployment-verification-agent`
* **前端**: `julik-frontend-races-reviewer`
* **代理原生**: `agent-native-reviewer`
  :::

***

#### 5. `ce:compound` - 知识复利

::: details 点击查看详情
**描述**: 记录最近解决的问题，复利团队知识。这是 Compound Engineering 的核心步骤。

**用法**:

```bash
/ce:compound                    # 记录最近的修复
/ce:compound [简短上下文]       # 提供额外上下文提示
```

**使用场景**:

* 解决了一个复杂问题后
* 发现了可复用的模式
* 学到了值得记录的经验

**为什么叫"复利"?**
每个记录的解决方案都会复利团队知识。第一次解决问题需要研究。记录它，下次遇到只需要几分钟。知识会复利增长。

**执行流程**:

1. **上下文分析器** - 提取对话历史，确定问题类型
2. **解决方案提取器** - 捕获有效的方法
3. **相关文档查找器** - 链接现有知识
4. **预防策略师** - 记录如何避免复发
5. **类别分类器** - 标记以便发现
6. **文档编写器** - 格式化最终文档

**输出**: 生成解决方案文档（`docs/solutions/[category]/*.md`）
:::

***

#### 6. `lfg` - 完整自主工程工作流

::: details 点击查看详情
**描述**: 一键运行完整的工程管道，从计划到视频演示。

**用法**:

```bash
/lfg [功能描述]
```

**执行流程**:

```
plan → work → review → resolve → browser tests → feature video → compound
```

**步骤**:

1. 可选: `/ralph-loop` (如果可用)
2. `/ce:plan $ARGUMENTS` - 创建计划
3. `/ce:work` - 执行实现
4. `/ce:review mode:autofix` - 审查并自动修复
5. `/todo-resolve` - 解决待办事项
6. `/test-browser` - 浏览器测试
7. `/feature-video` - 录制功能视频
8. 输出 `<promise>DONE</promise>`

**使用场景**:

* 想要完全自主的功能开发
* 从想法到 PR 的完整流程
* 快速原型开发
  :::

***

### 🔷 辅助工作流 Skills

#### 7. `ce:ideate` - 创意生成

::: details 点击查看详情
**描述**: 生成并批判性评估当前项目的改进想法。在 `ce:brainstorm` 之前使用。

**用法**:

```bash
/ce:ideate                           # 开放式创意
/ce:ideate DX improvements           # 聚焦开发者体验
/ce:ideate plugins/compound-engineering/  # 聚焦特定路径
/ce:ideate low-complexity quick wins # 聚焦低复杂性
```

**使用场景**:

* 询问应该改进什么
* 请求创意生成
* 探索令人惊讶的改进
* 希望 AI 主动建议项目方向

**核心原则**:

* 创意之前先接地 - 先扫描实际代码库
* 判断之前先发散 - 先生成完整想法集
* 使用对抗性过滤 - 质量机制是明确拒绝
* 早期保留产物 - 在展示结果之前编写文档

**输出**: 生成创意文档（`docs/ideation/*.md`）
:::

***

#### 8. `git-commit` - Git 提交

::: details 点击查看详情
**描述**: 使用清晰、价值传达的消息创建 git 提交。遵循仓库约定或默认使用 conventional commit 格式。

**用法**:

```bash
/git-commit
```

**使用场景**:

* 用户说"提交"、"提交这个"、"保存我的更改"
* 需要创建提交

**工作流程**:

1. 收集上下文（状态、差异、分支、历史）
2. 确定提交消息约定
3. 考虑逻辑提交（分组相关更改）
4. 暂存文件
5. 创建提交

**提交消息约定优先级**:

1. 仓库约定（AGENTS.md, CLAUDE.md）
2. 最近提交历史的模式
3. 默认: Conventional Commits (`type(scope): description`)
   :::

***

#### 9. `git-commit-push-pr` - 提交、推送、创建 PR

::: details 点击查看详情
**描述**: 提交更改、推送到远程并创建带有自适应描述的 PR。

**用法**:

```bash
/git-commit-push-pr
```

**使用场景**:

* 完成工作后想要创建 PR
* 一键提交和推送
  :::

***

#### 10. `git-worktree` - Git Worktree 管理

::: details 点击查看详情
**描述**: 管理 Git worktrees，用于隔离的并行开发。处理创建、列出、切换和清理 worktrees。

**用法**:

```bash
/git-worktree
```

**功能**:

* 从主分支创建 worktrees
* 列出 worktrees 及当前状态
* 在 worktrees 之间切换
* 自动清理已完成的 worktrees
* 自动复制 `.env` 文件
* 自动信任开发工具配置

**使用场景**:

* 代码审查（在隔离环境中审查 PR）
* 功能工作（并行开发多个功能）
* 并行开发

**⚠️ 重要**: 始终使用 `worktree-manager.sh` 脚本，不要直接调用 `git worktree add`
:::

***

#### 11. `git-clean-gone-branches` - 清理已删除分支

::: details 点击查看详情
**描述**: 清理本地分支，这些分支的远程跟踪分支已不存在。

**用法**:

```bash
/git-clean-gone-branches
```

**使用场景**:

* 远程分支已被删除
* 清理过时的本地分支
  :::

***

### 🔷 调试和测试 Skills

#### 12. `reproduce-bug` - Bug 复现

::: details 点击查看详情
**描述**: 系统地从 GitHub issue 复现和调查 bug。框架无关，假设驱动的工作流。

**用法**:

```bash
/reproduce-bug [GitHub issue 编号或 URL]
```

**使用场景**:

* 用户提供 GitHub issue 编号或 URL
* 需要复现或调查 bug

**执行流程**:

**Phase 1: 理解 Issue**

* 获取 issue 详情
* 提取关键信息：症状、预期行为、复现步骤、环境线索、频率

**Phase 2: 假设**

* 搜索相关代码
* 形成 2-3 个假设
* 按可能性排序

**Phase 3: 复现**

* **路由 A**: 基于测试的复现（后端、逻辑、数据 bug）
* **路由 B**: 基于浏览器的复现（UI、视觉、交互 bug）
  :::

***

#### 13. `test-browser` - 浏览器测试

::: details 点击查看详情
**描述**: 在受 PR 或分支更改影响的页面上运行端到端浏览器测试。

**用法**:

```bash
/test-browser                     # 测试当前分支
/test-browser 123                 # 测试 PR #123
/test-browser feat/my-feature     # 测试指定分支
/test-browser --port 4000         # 指定端口
```

**使用场景**:

* PR 需要浏览器测试
* 验证前端更改
* 端到端测试

**前置条件**:

* 本地开发服务器运行中
* `agent-browser` CLI 已安装
* Git 仓库有更改
  :::

***

#### 14. `agent-browser` - 浏览器自动化

::: details 点击查看详情
**描述**: AI 代理的浏览器自动化 CLI。用于与网站交互、导航页面、填写表单、点击按钮、截图等。

**用法**:

```bash
# 导航
agent-browser open https://example.com

# 获取元素引用
agent-browser snapshot -i
# 输出: @e1 [input], @e2 [button]

# 交互
agent-browser fill @e1 "user@example.com"
agent-browser click @e2

# 等待
agent-browser wait --load networkidle

# 截图
agent-browser screenshot page.png
```

**使用场景**:

* 打开网站
* 填写表单
* 点击按钮
* 截图
* 抓取数据
* 测试 Web 应用
* 登录站点
* 自动化浏览器操作

**命令链式调用**:

```bash
agent-browser open https://example.com && agent-browser wait --load networkidle && agent-browser screenshot page.png
```

:::

***

### 🔷 文档和知识 Skills

#### 15. `onboarding` - 入门文档生成

::: details 点击查看详情
**描述**: 生成或重新生成 `ONBOARDING.md`，帮助新贡献者理解代码库。

**用法**:

```bash
/onboarding
```

**使用场景**:

* 创建入门文档
* 为新开发者记录项目
* 刷新入门文档

**核心原则**:

* 为人类编写 - 清晰的散文
* 展示，不要只告诉 - 使用 ASCII 图表
* 六个部分 - 每个都值得存在
* 陈述可观察的，而非推断的
* 永不包含秘密
* 链接，不重复

**执行流程**:

1. 收集清单（运行 `scripts/inventory.mjs`）
2. 读取关键文件
3. 生成 `ONBOARDING.md`
   :::

***

#### 16. `document-review` - 文档审查

::: details 点击查看详情
**描述**: 使用并行角色代理审查需求或计划文档，发现角色特定的问题。

**用法**:

```bash
/document-review                           # 选择要审查的文档
/document-review docs/plans/my-plan.md     # 审查指定文档
/document-review mode:headless docs/plans/my-plan.md  # 无头模式
```

**使用场景**:

* 需求文档或计划文档存在
* 用户想要改进它

**文档类型**:

* **需求** - 来自 `docs/brainstorms/`，关注构建什么和为什么
* **计划** - 来自 `docs/plans/`，关注如何构建

**审查角色**:

* `product-lens-reviewer` - 产品视角
* `security-lens-reviewer` - 安全视角
* `scope-guardian-reviewer` - 范围守护
* `coherence-reviewer` - 一致性
* `feasibility-reviewer` - 可行性
* `design-lens-reviewer` - 设计视角
* `adversarial-document-reviewer` - 对抗性审查
  :::

***

#### 17. `proof` - 协作文档编辑

::: details 点击查看详情
**描述**: 通过 Proof 的 Web API 和本地桥接创建、编辑、评论和共享 markdown 文档。

**用法**:

```bash
# 创建共享文档
curl -X POST https://www.proofeditor.ai/share/markdown \
  -H "Content-Type: application/json" \
  -d '{"title":"My Doc","markdown":"# Hello\n\nContent here."}'

# 读取共享文档
curl -s "https://www.proofeditor.ai/api/agent/{slug}/state" \
  -H "x-share-token: <token>"
```

**使用场景**:

* 共享文档
* 协作编辑
* 文档评论
  :::

***

### 🔷 待办事项 Skills

#### 18. `todo-resolve` - 批量解决待办事项

::: details 点击查看详情
**描述**: 使用并行处理批量解决已批准的待办事项，记录经验教训，然后清理。

**用法**:

```bash
/todo-resolve                 # 解决所有 ready 状态的待办事项
/todo-resolve 001             # 解决特定待办事项
```

**使用场景**:

* 代码审查或分类会话后
* 批量解决已批准的待办事项

**工作流程**:

1. 分析 - 扫描待办事项，按状态分区
2. 计划 - 创建任务列表
3. 实现（并行）- 为每个项目生成解决代理
4. 提交和解决
5. 复利经验教训
6. 清理
   :::

***

#### 19. `todo-create` - 创建待办事项

::: details 点击查看详情
**描述**: 创建结构化的待办事项文件。

**用法**:

```bash
/todo-create [描述]
```

:::

***

#### 20. `todo-triage` - 待办事项分类

::: details 点击查看详情
**描述**: 对待办事项进行分类和优先级排序。

**用法**:

```bash
/todo-triage
```

:::

***

### 🔷 特定技术 Skills

#### 21. `dhh-rails-style` - DHH Rails 风格

::: details 点击查看详情
**描述**: 按照 DHH 独特的 37signals 风格编写 Ruby 和 Rails 代码。

**用法**:

```bash
/dhh-rails-style
```

**使用场景**:

* 编写 Ruby 代码
* Rails 应用程序
* 创建模型、控制器
* 用户提到 DHH、37signals、Basecamp、HEY 风格

**核心理念**:

* "最好的代码是不写的代码。第二好是明显正确的代码。"
* 原生 Rails 就足够了
* 丰富的领域模型优于服务对象
* CRUD 控制器优于自定义操作

**避免使用**:

* devise（使用自定义 ~150 行认证）
* pundit/cancancan（模型中的简单角色检查）
* sidekiq（Solid Queue 使用数据库）
* redis（数据库用于一切）
* view\_component（partials 工作良好）
* Tailwind（原生 CSS with layers）
  :::

***

#### 22. `andrew-kane-gem-writer` - Andrew Kane Gem 编写器

::: details 点击查看详情
**描述**: 按照 Andrew Kane 经过验证的模式和哲学编写 Ruby gems。

**用法**:

```bash
/andrew-kane-gem-writer
```

**使用场景**:

* 创建新的 Ruby gems
* 重构现有 gems
* 设计 gem API

**核心哲学**:

* 简单性优于聪明
* 零或最小依赖
* 显式代码优于元编程
* Rails 集成但不耦合

**入口点结构**:

```ruby
# 1. 依赖（优先 stdlib）
require "forwardable"

# 2. 内部模块
require_relative "gemname/model"
require_relative "gemname/version"

# 3. 条件 Rails（关键 - 永不直接 require Rails）
require_relative "gemname/railtie" if defined?(Rails)

# 4. 模块配置和错误
module GemName
  class Error < StandardError; end
  # ...
end
```

:::

***

#### 23. `dspy-ruby` - DSPy.rb LLM 应用

::: details 点击查看详情
**描述**: 使用 DSPy.rb 构建类型安全的 LLM 应用程序。

**用法**:

```bash
/dspy-ruby
```

**使用场景**:

* 实现可预测的 AI 功能
* 创建 LLM 签名和模块
* 配置语言模型提供商
* 构建带工具的代理系统
* 优化提示

**核心概念**:

**1. Signatures（签名）**:

```ruby
class EmailClassifier < DSPy::Signature
  description "Classify customer support emails"

  input do
    const :email_content, String
    const :sender, String
  end

  output do
    const :category, String
    const :priority, Priority
    const :confidence, Float
  end
end
```

:::

***

#### 24. `frontend-design` - 前端设计

::: details 点击查看详情
**描述**: 构建具有真正设计质量的 Web 界面。

**用法**:

```bash
/frontend-design [描述]
```

**使用场景**:

* 落地页
* 营销页面
* UI 组件
* 仪表板
* 需要视觉润色的任何前端工作
  :::

***

#### 25. `feature-video` - 功能视频录制

::: details 点击查看详情
**描述**: 记录功能的视频演示并将其添加到 PR 描述中。

**用法**:

```bash
/feature-video 123              # 为 PR #123 录制
/feature-video current          # 当前分支的 PR
/feature-video path/to/video.mp4  # 上传现有视频
```

**使用场景**:

* PR 需要视觉演示
* 用户要求演示功能
* 展示视觉更改

**前置条件**:

* 本地开发服务器运行中
* `agent-browser` CLI 已安装
* `ffmpeg` 已安装
* `gh` CLI 已认证
  :::

***

### 🔷 其他实用 Skills

#### 26. `rclone` - 云存储传输

::: details 点击查看详情
**描述**: 使用 rclone 在云存储提供商之间上传、同步和管理文件。

**用法**:

```bash
# 检查安装和配置
rclone listremotes

# 上传文件
rclone copy /local/path remote:bucket/path

# 同步
rclone sync /local/path remote:bucket/path
```

**使用场景**:

* 上传文件到 S3、Cloudflare R2、Backblaze B2、Google Drive
* 同步文件到云
* 备份文件

**支持的提供商**:
| 提供商 | 类型 | 关键设置 |
|--------|------|----------|
| AWS S3 | `s3` | access\_key\_id, secret\_access\_key, region |
| Cloudflare R2 | `s3` | access\_key\_id, endpoint |
| Backblaze B2 | `b2` | account, key |
:::

***

#### 27. `changelog` - 变更日志

::: details 点击查看详情
**描述**: 管理变更日志。

**用法**:

```bash
/changelog
```

:::

***

#### 28. `setup` - 设置

::: details 点击查看详情
**描述**: 设置和配置 Compound Engineering 插件。

**用法**:

```bash
/setup
```

:::

***

## 核心原则总结

1. **每个工作单元使后续工作更容易**
   代码、文档和工具应该相互构建,使未来工作更快,而不是更慢。

2. **品味属于系统,不属于审查**
   将判断融入配置、模式和自动检查中。

3. **教系统,不要自己做工作**
   花时间给代理更多上下文会带来指数级回报。

4. **构建安全网,而不是审查流程**
   通过构建验证基础设施来建立对 AI 的信任。

5. **使环境代理原生**
   构建项目以便 AI 代理可以自主导航和修改它们。

6. **随处应用复合思维**
   每个产物 - 代码、文档、测试、提示 - 都应该使下一次迭代更快。

7. **拥抱放手的 discomfort**
   当你委托给 AI 工具时,你必须接受不完美但可扩展的结果。

8. **发布更多价值,输入更少代码**
   你的输出应该通过解决的问题数量来衡量,而不是记录的击键次数。

## 开始使用

1. **评估你的阶段**:确定你在采用阶梯上的位置
2. **不要跳过阶段**:每个阶段都为下一个阶段建立必要的心智模型和习惯
3. **从小处开始**:首先尝试一个功能
4. **信任流程**:让系统工作
5. **迭代和改进**:每次循环都会让下一个循环更快

Compound Engineering 不仅仅是关于 AI 辅助编码 - 它是关于构建一个随着时间推移变得更好、更快、更智能的工程系统。每个功能、每次 bug 修复、每个解决方案都为下一个增加价值。

***

**参考资料:**

* [Compound Engineering - Every](https://every.to/guides/compound-engineering)
* [Every GitHub Marketplace](https://github.com/EveryInc/every-marketplace)