Compound Engineering 速查手册

Compound Engineering 使用教程

以 Android（Kotlin / Jetpack Compose） 为例 · 33 个技能按使用频率讲解 · 知识复利对抗技术债（brainstorm → plan → work → simplify → review → compound）

GitHub 仓库 Cursor / Claude Code / Codex 必用 · 高频 · 中频 · 低频 Android 举例

1这是什么

一套面向 AI 编码客户端的复合工程插件：把「对齐需求 → 出计划 → 执行 → 精简 → 审查 → 沉淀」固化成可复用技能。

核心闭环是六步：/ce-brainstorm → /ce-plan → /ce-work → /ce-simplify-code → /ce-code-review → /ce-compound。学到的东西写进 docs/solutions/，下次 brainstorm/plan 会读到——这就是「复利」。
必用 / 高频几乎每次改动或每周都会用 中频 / 低频按场景触发；特定环节才用

2安装与初始化

先装才能用；装完必跑 /ce-setup。

Cursor

/add-plugin compound-engineering

Claude Code

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

Codex CLI

codex plugin marketplace add EveryInc/compound-engineering-plugin
codex plugin add compound-engineering@compound-engineering-plugin

装完必跑

/ce-setup   # 健康检查 + 建 .compound-engineering/config.yaml
换机或重装后也先跑一次 /ce-setup，确认可选工具能力与本地配置齐全。

3推荐黄金路径

标准功能开发：对齐需求 → 出计划 → 执行 → 精简 → 审查 → 沉淀。

① brainstorm→ ② plan→ ③ work→ ④ simplify→ ⑤ review→ ⑥ compound
点目录里「每次改动必用」六条技能，把闭环走熟；高频路径见文末「三条抄作业路径」。

4必用 · 核心循环六步

每次改动几乎都会用到 · 高频必会

/ce-brainstorm · 盘问式需求对齐 必用

把模糊/宏大的想法通过问答收敛成仅含需求的统一计划，落到 plans/。用于探索范围、盲区排查。不写代码。

/ce-brainstorm 做一个离线可浏览的图片列表，断网也能看
Android 示例：它会追问缓存策略（LRU 上限 / Room 还是 DataStore）、失效时间、占位图与错误重试、是否用 Paging3——只定需求，不替你决定产品行为。加 [output:html] 可出网页版讲解。

/ce-plan · 需求 → 实现就绪计划 必用

把需求计划丰富为实现就绪的技术计划：分层、依赖、步骤、风险。偏好用本技能而非自己拍脑袋拆解。

/ce-plan plans/离线图片列表.md
Android 示例：生成 Repository + Paging3 + Coil + Room 的落地计划，含 ViewModel 状态、协程调度（Dispatchers.IO）、缓存失效与测试点。

/ce-work · 端到端执行计划 必用

按计划或明确任务实现，保留主机验证与提交；只做实现 + 本地校验，不带「发布尾巴」。

/ce-work plans/离线图片列表-plan.md
Android 示例：按计划写 Kotlin/Compose，跑 ./gradlew assembleDebug / 单测做本地验证，不自动开 PR。留空用最新计划。

/ce-simplify-code · 审查前精简 必用

在审查之前精炼刚改动的代码——提升清晰度、复用、质量、效率，行为不变。优先可读显式，而非「少几行」。

/ce-simplify-code
Android 示例：把刚写的 Compose @Composable 抽成可复用小组件、合并重复 StateFlow、去掉不必要的大括号嵌套。

/ce-code-review · 合并前多代理审查 必用

结构化审查：bug、回归、测试、规范。合并前用；本地应用需显式 apply:local。

/ce-code-review
/ce-code-review apply:local
Android 示例：审查协程泄漏（未绑定 viewModelScope）、Lifecycle、Paging 配置、主线程 IO、Compose 重组陷阱。

/ce-compound · 写进 solutions（复利） 必用

把刚解决的问题写成可持久的仓库学习，落到 docs/solutions/。下一次 brainstorm/plan 会读取它。

/ce-compound 用 Paging3+Room 做离线缓存的失效处理模式
Android 示例：记下「Room + Paging3 RemoteMediator 的失效边界」这一课，下次同类需求直接复用。可用 depth:lightweight|full、mode:non-interactive。

5高频 · 功能 / PR 常用

几乎每周都会碰到

/lfg · 无人值守完整交付 高频

plan → work → simplify → review → 修 → 浏览器测试 → commit → 推 PR → 看 CI。只在你明确要求「自主交付到开 PR」时用。

/ce-brainstorm 深色模式设置页; /lfg
先 brainstorm 再 lfg，别只给一行 prompt。有 remote 才推；不自动 merge；修到预算上限可能留尾巴。

/ce-debug · Bug 诊断循环 高频

针对 bug / 失败行为的诊断循环。开放性问题用它，而非 ce-work。

/ce-debug 列表滑动掉帧且偶发 ANR，疑似协程泄漏
先建可复现反馈循环，再猜原因。示例：定位全局 CoroutineScope 未取消导致的内存上涨。

/ce-commit · 清晰本地提交 高频

用清晰、传达价值的 message 创建本地 git commit。只提交不推、不开 PR。

/ce-commit

/ce-commit-push-pr · 提交 + 推 + 开 PR 高频

提交、推送、开 PR 一条龙；PR 描述自动写好。babysit:continuous 可在开 PR 后持续看护 CI。

/ce-commit-push-pr

/ce-worktree · 隔离 git worktree 高频

建立隔离工作区——新分支做新活，或挂到已有分支/PR/commit，不打扰主工作区。

/ce-worktree 新分支 feature/offline-cache
并行修两个互不相关的 bug 时各开一个 worktree，避免相互污染 Gradle 状态。

/ce-resolve-pr-feedback · 处理 PR 反馈 高频

处理 PR 上已留下的审查反馈。审代码本身用 ce-code-review，这里只处理反馈。

/ce-resolve-pr-feedback 123

6中频 · 周期 / 按需

按场景触发

/ce-ideate · 生成并评估改进想法 中频

在选定方向前，生成并评估有依据的改进想法。已有想法用 brainstorm，要评判已有方案用 pov。

/ce-ideate 提升首页冷启动速度的方向
可产出「懒加载 Fragment / App Startup 收敛 / Baseline Profile」等多条可落地思路。

/ce-pov · 果断的技术选型观点 中频

/ce-pov Jetpack Compose 还是传统 XML 做这个新详情页
示例结论：「新页面用 Compose；存量 XML 列表页暂不迁移」——带分级理由。

/ce-prototype · 可丢弃原型验证 中频

造一个可丢弃原型来回答「某东西该怎么工作/感觉/读」。代价高错不起、草图又定不了时才用。

/ce-prototype 验证手势返回与底部导航的冲突处理

/ce-optimize · 指标驱动优化 中频

/ce-optimize 把冷启动从 2.1s 降到 1.2s 以内

/ce-explain · 持久化可视化教学工件 中频

/ce-explain Paging3 的 RemoteMediator 工作原理
学习向，不是仓库文档；适合新人留存讲解。

/ce-compound-refresh · 刷新已沉淀学习 中频

对照当前代码库刷新已沉淀的学习，清理过时/重叠/被取代的条目。别拿它做普通重构。

/ce-compound-refresh 缓存相关

/ce-strategy · 创建/更新 STRATEGY.md 中频

/ce-strategy metrics
启动产品、换方向或 roadmap 时用；给 brainstorm/plan 上游产品锚点。

/ce-sweep · 周期性扫描整理语境 中频

/ce-sweep
周期性扫待办/技术债清单，作为下一轮 plan 的上下文输入。

7低频 · 测试 / 协作 / 发布

特定环节才用

指令用途用法
/ce-test-browser对当前分支/PR 影响的页面跑浏览器测试（WebView / PhotoKit H5）/ce-test-browser current
/ce-test-xcodeXcode 模拟器测 iOS（需 macOS + Xcode）/ce-test-xcode current
/ce-polish实时浏览器反馈打磨 UX（仅手动）/ce-polish
/ce-dogfood无人值守浏览器 QA：跑用户流、修小问题、写报告/ce-dogfood
/ce-doc-review角色视角审需求/计划/规格/ce-doc-review plans/xx.md
/ce-handoff会话交接 / 恢复/ce-handoff create 离线缓存功能
/ce-proof在 Proof 里发布/评论 markdown 规格与计划/ce-proof
/ce-promote为已发布功能起草宣发文案（仅手动）/ce-promote 一条推特线程…
/ce-product-pulse时间窗口产品脉冲报告（仅手动）/ce-product-pulse 7d
/ce-babysit-pr长期看护 PR 到可合并/ce-babysit-pr 123 continuous
/ce-polish、/ce-dogfood、/ce-promote、/ce-product-pulse、/ce-test-xcode 多为仅手动调用；不要在无人值守管道里默认串进。

8安装与维护（一次性）

装后 / 换机 / 换模型时跑

/ce-setup · 健康检查与本地配置

/ce-setup

报告可选工具能力、建 .compound-engineering/config.yaml。装后第一件事。

/ce-retune · 为新模型重调技能语料

/ce-retune gpt-5.5
先建基线、定噪声地板、对抗审计，再分轮切入。需有 A/B 基准 harness，否则拒绝。

/ce-riffrec-feedback-analysis · 解析产品反馈录音

/ce-riffrec-feedback-analysis
消费端：需先有 riffrec-*.zip（屏幕 + 语音 + 事件），再解析成 bug/需求证据喂给 debug / brainstorm。

9三条高频路径（直接抄）

把常用组合固化下来，省去每次想下一步。

A：标准功能开发（最常用）

/ce-brainstorm 做一个支持离线浏览、下拉刷新、分页加载的图片列表
/ce-plan
/ce-work
/ce-simplify-code
/ce-code-review apply:local
/ce-compound 离线图片列表的 Paging3+Room 缓存模式
/ce-commit-push-pr

B：修一个难搞的 Bug

/ce-debug 滚动时偶发 ANR，profiler 显示主线程被 IO 阻塞
# 定位后
/ce-code-review apply:local
/ce-compound 主线程 IO 的排查清单（Dispatchers.IO 检查点）
/ce-commit

C：自主交付到 PR（你没空盯时）

/ce-brainstorm 深色模式设置页，跟随系统且可手动覆盖
/lfg
# 它自主 plan→work→simplify→review→测试→commit→推 PR→看 CI

10常见问题

必用六步一定要全走吗？
小修可以跳过 brainstorm；但只要改动有决策空间，先 brainstorm/plan 再 work 更稳。审查前尽量 simplify；合并前尽量 review；学到新模式就 compound。
/lfg 和手动六步有什么区别？
/lfg 是无人值守管道，会做到开 PR、盯 CI；不自动 merge。你需要收口时再人工合并。手动六步适合你想逐步确认的时候。
完整技能列表在哪？
本页已覆盖插件公开 README 与 33 个技能的主用法。更多参数与边界见 EveryInc/compound-engineering-plugin 仓库内各 SKILL.md。