好的工程实践应该让后续每个任务都比上一个更容易，而不是更难。
Every Inc.开源了他们内部用的工程 plugin：compound-engineering-plugin。

核心理念叫"复利工程"（Compound Engineering）：80% 的工作在规划和审查，20% 在执行。 每次写完代码，不只是交付了功能，而是给下一个 agent 留下了更好的上下文。
支持 Claude Code、Codex、Cursor、Copilot CLI、Qwen Code、Gemini CLI，一套 plugin 多端复用。

1. 完整工作循环
核心是六步 loop：
1）/ce-strategy：先写 STRATEGY.md。记录产品目标问题、方法、用户画像、关键指标。比如："我们在做的是帮助 indie hacker 用 AI 把 idea 变成可用产品，核心指标是首次成功部署时间"。这是后续所有 agent 的锚点。
2）/ce-brainstorm：交互式 Q&A，把粗糙想法梳理成 requirements doc。比如你说"让后台任务重试更安全"，它会反问：失败原因是幂等问题还是超时？重试要不要有 backoff？需要告警吗？对话完输出一份 requirements。
3）/ce-plan：把 requirements 转成带 task 的实现计划。每个 task 是独立可执行的单元，而不是一大坨"实现功能X"。
4）/ce-work：执行计划，用 worktree 隔离，不污染主分支。
5）/ce-code-review：多 agent 并行审查，合并前强制过一遍。
6）/ce-compound：把这次的学习写成 compound note——这是整个系统复利的来源。

2. /ce-compound 具体做什么
一个真实例子：你修了一个 webhook 有时会创建重复 invoice 的 bug，根因是消息队列的 at-least-once delivery 和业务层没有做幂等。
普通做法：fix 完就合并，下次新人或新 agent 接手同类问题，重新踩坑。
/ce-compound 的做法：自动提炼出一条结构化知识：
问题模式：消息队列消费端缺幂等检查
解法：在 invoice 创建前用 idempotency_key 查重
适用范围：所有涉及外部 webhook 的写操作
这条知识写入项目知识库，下次 agent 处理类似任务时，自动读到，不需要从头发现。

3. /ce-product-pulse 连接数据和决策
另一个值得关注的 skill：/ce-product-pulse。
运行一次，生成指定时间窗口内（24h、7d 等）的产品数据报告：用户遇到了什么错误、性能异常在哪、有哪些需要跟进的信号。报告存到 docs/pulse-reports/，按时间线积累。
实际效果是：下次更新 STRATEGY.md 或写新功能 brainstorm 时，可以直接引用真实数据——"上周 checkout 流程的 P99 是 2.3s，有 12 个 webhook 超时报警"，而不是靠感觉估。

4. 规模
37 个 skills + 51 个 agents。安装后运行 /ce-setup 初始化。

访问：github.com/EveryInc/compound-engineering-plugin

#HOW I AI# #程序员#