跨 IDE 的 Compound Engineering 插件：工程上下文统一与技能可移植架构

问题背景：工程上下文的碎片化

当开发团队在多个 AI 编程工具间切换时，一个核心痛点浮现：每个 IDE 或 Agent 工具都维护自己的上下文理解，导致工程知识无法累积。传统开发中，技术债随功能增加而累积；而在多工具协作场景下，这种碎片化进一步加剧了认知负担 ——Claude Code 中完成的代码审查逻辑无法直接迁移到 Codex，Cursor 中沉淀的策略文档对 Copilot 不可见。

Every 团队提出的 Compound Engineering（复合工程）方法论，正是针对这一痛点的系统性回应。其核心理念是 "每个工程单元都应让后续单元更容易，而非更难"—— 通过将 80% 的精力投入规划与评审、20% 投入执行，实现知识的可复用与可累积。

Compound Engineering 方法论概述

Compound Engineering 并非简单的工具链整合，而是一套完整的工作流设计。其核心循环包括：策略制定（/ce-strategy）、创意发散（/ce-ideate）、需求脑暴（/ce-brainstorm）、实现规划（/ce-plan）、任务执行（/ce-work）、问题调试（/ce-debug）、代码审查（/ce-code-review）、知识沉淀（/ce-compound）以及产品脉搏（/ce-product-pulse）。

这套方法论的关键在于 "复合" 二字 —— 每次迭代产生的洞察（如审查中发现的模式、调试中定位的根因）都被显式文档化，供后续 Agent 直接引用，避免重复学习。这与传统开发中 "修复即遗忘" 的模式形成鲜明对比。

插件架构：技能 - 代理双层模型

Every 开源的 compound-engineering-plugin 采用 "技能（Skills）+ 代理（Agents）" 的双层架构设计，这是其实现跨 IDE 可移植性的技术基础。

技能层（Skills） 提供用户交互入口，表现为各 IDE 中的斜杠命令（如 /ce-plan、/ce-code-review）。技能层负责解析用户意图、收集上下文、触发相应工作流。目前插件包含 37 个技能，覆盖从策略制定到产品监控的完整工程生命周期。

代理层（Agents） 执行具体任务，如并行代码审查、深度研究、子任务分解等。代理层包含 51 个专用 Agent，它们被技能层按需调用。例如，/ce-code-review 技能会触发多代理审查流程，由不同 Agent 分别负责安全性检查、性能分析、可维护性评估等维度。

这种分层设计的价值在于：技能层与 IDE 的具体接口绑定，而代理层保持平台无关。当需要支持新的 IDE 时，只需为技能层编写适配代码，代理层的核心逻辑可完全复用。

跨 IDE 可移植性实现机制

插件支持 Claude Code、Codex、Cursor、GitHub Copilot、Factory Droid、Qwen Code、OpenCode、Pi、Gemini CLI 和 Kiro CLI 等十余种工具，其跨平台能力源于三层抽象：

统一 Manifest 格式：插件核心采用 Claude Code 兼容的插件清单格式作为 "源格式"，定义技能描述、参数模式、代理映射等元数据。这份清单成为各平台转换的单一事实来源。

平台适配层：针对不同 IDE 的插件规范差异，项目提供 Bun/TypeScript 转换器（@every-env/compound-plugin）。该转换器读取统一 Manifest，生成目标平台所需的配置文件。例如，Codex 需要额外的 Agent 注册步骤，而 Cursor 使用 /add-plugin 命令，这些差异由转换器自动处理。

环境隔离与清理：为避免版本冲突，插件在各 IDE 的配置目录中保持独立存储。转换器提供 cleanup 命令，可将旧版本 artifacts 迁移至 legacy-backup/ 目录，确保平滑升级。

实战配置参数与迁移清单

对于希望在不同 IDE 间迁移 Compound Engineering 工作流的团队，以下是关键配置参数：

Claude Code（原生支持）：

/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering

Codex（需额外 Agent 安装）：

# 步骤 1：注册市场
codex plugin marketplace add EveryInc/compound-engineering-plugin

# 步骤 2：安装 Agents（必需，因 Codex 原生插件暂不支持自定义 Agents）
bunx @every-env/compound-plugin install compound-engineering --to codex

# 步骤 3：通过 TUI 安装技能
codex
# 在 Codex 中运行 /plugins，选择 Compound Engineering，安装 compound-engineering

Cursor：

/add-plugin compound-engineering
# 或在插件市场搜索 "compound engineering"

GitHub Copilot CLI：

copilot plugin marketplace add EveryInc/compound-engineering-plugin
copilot plugin install compound-engineering@compound-engineering-plugin

OpenCode / Pi / Gemini / Kiro（转换器安装）：

bunx @every-env/compound-plugin install compound-engineering --to opencode
bunx @every-env/compound-plugin install compound-engineering --to pi
bunx @every-env/compound-plugin install compound-engineering --to gemini
bunx @every-env/compound-plugin install compound-engineering --to kiro

多目标批量安装：

bunx @every-env/compound-plugin install compound-engineering --to all

环境变量配置：

• COMPOUND_PLUGIN_GITHUB_SOURCE：指定插件源码仓库（默认 https://github.com/EveryInc/compound-engineering-plugin）
• CODEX_HOME：指定 Codex 配置目录（用于多 Profile 管理）

迁移检查清单：

1. 运行 bunx @every-env/compound-plugin cleanup --target <ide> 清理旧版本
2. 确认目标 IDE 的插件市场已注册 EveryInc/compound-engineering-plugin
3. 对于 Codex，务必执行 Bun Agent 安装步骤，否则审查和研究代理将不可用
4. 验证 /ce-setup 命令可正常运行，检查环境依赖
5. 测试核心工作流：/ce-brainstorm → /ce-plan → /ce-work → /ce-code-review → /ce-compound

局限性与演进方向

当前实现存在若干技术约束。Codex 的原生插件规范尚不支持自定义 Agents，因此需要额外的 Bun 安装步骤作为补充。OpenCode、Pi、Gemini、Kiro 等平台的支持依赖于转换器，其输出格式可能随目标平台演进而需更新。此外，插件包含 37 个技能和 51 个代理，规模较大，在资源受限环境中可能面临加载性能挑战。

从演进角度看，Compound Engineering 插件代表了 AI 辅助开发工具向 "可移植工程能力" 迈进的早期探索。随着各 IDE 插件规范的成熟，理想状态是实现真正的 "一次编写，随处运行"—— 工程技能不再绑定于特定工具，而成为可跨平台复用的数字资产。

资料来源

• EveryInc/compound-engineering-plugin GitHub 仓库
• Every.to: "Compound Engineering: How Every Codes With Agents"

ai-systems