使用 compound-engineering 增强 Claude Code

约 8257 字大约 28 分钟

Compound Engineering软件工程开发方法论Claude Code

次阅读

2026-04-03

什么是 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 命令

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

这个命令会:

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

高级模式 - ultrathink 模式:

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

2. Work (工作)

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

关键行动

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

Claude Code 命令

/workflows:work

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

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

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

3. Review (审查)

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

关键行动

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

Claude Code 命令

/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)

自动化解决

/resolve_pr_parallel

自动处理所有发现:

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

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

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

关键行动

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

Claude Code 命令

/workflows:compound

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

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

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

为什么推荐 Compound Engineering?

1. 指数级效率提升

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

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

2. 系统化知识积累

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

3. 多代理并行审查

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

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

4. 可扩展的工程实践

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

如何在 Claude Code 中使用

安装 Compound Engineering 插件

# 添加 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. 头脑风暴(不确定要构建什么时使用)

/workflows:brainstorm Add user notifications

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

2. 一键完整流程

/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 输出之前问这三个问题:

"你在这里做出的最难的决定是什么?" 强制 AI 揭示棘手的部分以及它在哪里做出判断调用。
"你拒绝了哪些替代方案,为什么?" 显示它考虑的选项,帮助捕获是否做出了错误选择。
"你最不自信的是什么?" 让 AI 承认它可能在哪里出错。

4. 代理原生架构

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

开发环境

Git 操作

调试

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

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

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. 清晰的交接

交接工作时包括:

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

## 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(用于快速原型)

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

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

适用于:

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

不适用于:

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

Vibe Coding 悖论:

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

5. 用户研究结构化

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

# 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` - 头脑风暴

点击查看详情

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

用法:

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

使用场景:

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

核心原则:

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

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

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

点击查看详情

描述: 将功能描述或需求转化为结构化的实施计划。回答 HOW（如何构建）的问题。

用法:

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

使用场景:

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

核心原则:

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

计划质量标准:

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

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

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

点击查看详情

描述: 高效执行工作同时保持质量并完成功能。执行计划中的实现步骤。

用法:

/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: 快速启动

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

Phase 2: 执行循环

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

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

点击查看详情

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

用法:

/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` - 知识复利

点击查看详情

描述: 记录最近解决的问题，复利团队知识。这是 Compound Engineering 的核心步骤。

用法:

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

使用场景:

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

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

执行流程:

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

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

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

点击查看详情

描述: 一键运行完整的工程管道，从计划到视频演示。

用法:

/lfg [功能描述]

执行流程:

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

步骤:

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

使用场景:

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

🔷 辅助工作流 Skills

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

点击查看详情

描述: 生成并批判性评估当前项目的改进想法。在 ce:brainstorm 之前使用。

用法:

/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 提交

点击查看详情

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

用法:

/git-commit

使用场景:

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

工作流程:

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

提交消息约定优先级:

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

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

点击查看详情

描述: 提交更改、推送到远程并创建带有自适应描述的 PR。

用法:

/git-commit-push-pr

使用场景:

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

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

点击查看详情

描述: 管理 Git worktrees，用于隔离的并行开发。处理创建、列出、切换和清理 worktrees。

用法:

/git-worktree

功能:

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

使用场景:

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

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

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

点击查看详情

描述: 清理本地分支，这些分支的远程跟踪分支已不存在。

用法:

/git-clean-gone-branches

使用场景:

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

🔷 调试和测试 Skills

12. `reproduce-bug` - Bug 复现

点击查看详情

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

用法:

/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` - 浏览器测试

点击查看详情

描述: 在受 PR 或分支更改影响的页面上运行端到端浏览器测试。

用法:

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

使用场景:

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

前置条件:

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

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

点击查看详情

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

用法:

# 导航
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 应用
登录站点
自动化浏览器操作

命令链式调用:

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

🔷 文档和知识 Skills

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

点击查看详情

描述: 生成或重新生成 ONBOARDING.md，帮助新贡献者理解代码库。

用法:

/onboarding

使用场景:

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

核心原则:

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

执行流程:

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

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

点击查看详情

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

用法:

/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` - 协作文档编辑

点击查看详情

描述: 通过 Proof 的 Web API 和本地桥接创建、编辑、评论和共享 markdown 文档。

用法:

# 创建共享文档
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` - 批量解决待办事项

点击查看详情

描述: 使用并行处理批量解决已批准的待办事项，记录经验教训，然后清理。

用法:

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

使用场景:

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

工作流程:

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

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

点击查看详情

描述: 创建结构化的待办事项文件。

用法:

/todo-create [描述]

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

点击查看详情

描述: 对待办事项进行分类和优先级排序。

用法:

/todo-triage

🔷 特定技术 Skills

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

点击查看详情

描述: 按照 DHH 独特的 37signals 风格编写 Ruby 和 Rails 代码。

用法:

/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 编写器

点击查看详情

描述: 按照 Andrew Kane 经过验证的模式和哲学编写 Ruby gems。

用法:

/andrew-kane-gem-writer

使用场景:

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

核心哲学:

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

入口点结构:

# 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 应用

点击查看详情

描述: 使用 DSPy.rb 构建类型安全的 LLM 应用程序。

用法:

/dspy-ruby

使用场景:

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

核心概念:

1. Signatures（签名）:

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` - 前端设计

点击查看详情

描述: 构建具有真正设计质量的 Web 界面。

用法:

/frontend-design [描述]

使用场景:

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

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

点击查看详情

描述: 记录功能的视频演示并将其添加到 PR 描述中。

用法:

/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` - 云存储传输

点击查看详情

描述: 使用 rclone 在云存储提供商之间上传、同步和管理文件。

用法:

# 检查安装和配置
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` - 变更日志

点击查看详情

描述: 管理变更日志。

用法:

/changelog

28. `setup` - 设置

点击查看详情

描述: 设置和配置 Compound Engineering 插件。

用法:

/setup

核心原则总结

每个工作单元使后续工作更容易 代码、文档和工具应该相互构建,使未来工作更快,而不是更慢。
品味属于系统,不属于审查 将判断融入配置、模式和自动检查中。
教系统,不要自己做工作 花时间给代理更多上下文会带来指数级回报。
构建安全网,而不是审查流程 通过构建验证基础设施来建立对 AI 的信任。
使环境代理原生 构建项目以便 AI 代理可以自主导航和修改它们。
随处应用复合思维 每个产物 - 代码、文档、测试、提示 - 都应该使下一次迭代更快。
拥抱放手的 discomfort 当你委托给 AI 工具时,你必须接受不完美但可扩展的结果。
发布更多价值,输入更少代码 你的输出应该通过解决的问题数量来衡量,而不是记录的击键次数。

开始使用

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

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

参考资料:

版权所有

版权归属：AkaChou

许可证：署名 4.0 国际 (CC-BY-4.0)