戴明循环的 AI 版本：用复利工程让代码库越来越好改

发表于 | 更新于 | 分类于 | 评论数： | 阅读次数：
本文字数： 12k | 阅读时长 ≈ 11 分钟

PDCA（Plan-Do-Check-Act）是戴明提出的持续改进闭环，核心思想是让每轮循环都比上一轮更聪明。复利工程把这个思想搬进 AI 编码时代：AI 不只是写代码的工具，更是把每次开发的知识固化下来的载体，让每一次工作都站在上一次的积累上。

AI 代替人写代码，这件事已经发生了。但大多数人的用法停留在「给 AI 一个需求，拿回一段代码」。这种用法有个隐患：代码在变多，但对代码库的理解没有同步增长——知识存在人脑里，人会忘、会离职，下一个人仍然踩同样的坑。

传统 PDCA 在软件工程里卡在「Act」这步。问题找到了，就是没人把改进固化成规则让所有人用上。AI 的出现让这件事的成本接近零：让 AI 总结一次 Review、写几条规则进文件，30 秒。这就是复利工程想做的事。

第一章：复利思想，以及为什么 AI 时代更需要它

传统开发的负复利

软件项目有个规律：随着代码库变大，每次改动的成本越来越高。技术债堆积，依赖耦合，新人上手越来越难，老人开始谨慎改动。这是「负复利」——越做越难。

工程实践（测试、文档、Code Review）是对抗负复利的手段，但它们依赖人去执行，执行质量参差不齐，而且学到的东西大多留在人的记忆里而非系统里。

AI 时代的新问题

AI 写代码的速度比人快十倍，这反而放大了一个旧问题：执行速度越快，积累知识的窗口越短。

一天写出一周的代码量，但对「这段代码为什么这样写」的理解却没有跟上。AI 每次启动都是全新的，不知道上次踩过什么坑，不知道这个项目有什么隐性规约。

表面上看是提速了，实际上是在快速积累技术债，只是债的形式从「烂代码」变成了「无法理解的 AI 生成代码」。

复利工程的核心想法

把 PDCA 的每一步都交给 AI 来执行和记录：

PDCA 复利工程
Plan 先研究代码库和最佳实践，产出可执行的技术方案
Do AI 按计划执行，MCP 工具做实时验证
Check 多个 AI 从不同角度审查代码
Act 把发现的问题和解法写进项目文件，永久留存

关键在最后一步——「Act」。每次 Review 结束后，把发现固化进 CLAUDE.md、AGENTS.md 或 skills 文件。下次 AI 启动，自动读这些文件，不会再犯同样的错。知识不再依赖人记，而是沉淀在代码库里，对所有人、所有 AI 永久有效。

这就是「复利」：每次循环结束，系统比上次更聪明，下次工作比这次更快。

时间分配也要反直觉调整：80% 的时间花在计划和 Review，20% 花在执行。计划越扎实，AI 执行时跑偏越少，返工成本越低。

第二章：compound-engineering-plugin 的安装与使用

安装

Claude Code（原生支持）：

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

其他工具（OpenCode、Codex、Gemini 等），通过 CLI 转换安装：

1
2
3
4
5
6
7
8
9
10
11
# OpenCode
bunx @every-env/compound-plugin install compound-engineering --to opencode

# Codex
bunx @every-env/compound-plugin install compound-engineering --to codex

# Gemini CLI
bunx @every-env/compound-plugin install compound-engineering --to gemini

# 自动检测并安装到所有已有工具
bunx @every-env/compound-plugin install compound-engineering --to all

基本工作流

1
/ce:brainstorm → /ce:plan → /ce:work → /ce:review → /ce:compound → 下一轮

一个功能的完整流程：

  1. 需求不清晰时，先跑 /ce:brainstorm 探索方向，输出需求文档到 docs/brainstorms/
  2. 需求明确后，跑 /ce:plan 产出技术方案到 docs/plans/
  3. 执行：/ce:work docs/plans/xxx-plan.md
  4. 代码写完，跑 /ce:review 做多 Agent 审查
  5. Review 结束，跑 /ce:compound 把这次学到的写进 docs/solutions/

项目根目录会多出这样的结构：

1
2
3
4
5
6
7
your-project/
├── CLAUDE.md / AGENTS.md    # 项目规约、偏好、经验积累
├── docs/
│   ├── brainstorms/         # 需求探索文档
│   ├── plans/               # 技术方案文档
│   └── solutions/           # 解决方案知识库（复利的核心）
└── todos/                   # Review 发现的待处理问题

个人配置同步

如果在多个工具之间切换，可以把 Claude Code 的个人配置同步到其他工具：

1
2
3
4
5
6
# 同步到所有检测到的工具
bunx @every-env/compound-plugin sync

# 同步到指定工具
bunx @every-env/compound-plugin sync --target opencode
bunx @every-env/compound-plugin sync --target codex

同步内容包括：~/.claude/skills/（技能文件，以符号链接方式同步，Claude Code 里的修改会立即生效）、~/.claude/commands/（自定义命令）、~/.claude/settings.json 中的 MCP 服务器配置。

第三章：核心 Skill 的设计思路与多工具接入

五个核心 Skill 的设计思路

/ce:brainstorm：先想清楚再动手

这个 Skill 的设计前提是：需求模糊时直接开干，是最贵的错误。

它不是一次性的「给我写个需求文档」，而是一个交互式的需求探索过程——每次只问一个问题，探索 2-3 个实现方向并列出利弊，最后产出一份轻量的 PRD 格式文档（docs/brainstorms/YYYY-MM-DD-<topic>-requirements.md）。

有一个细节值得注意：它会自动判断「这个需求是否已经足够清楚」，如果是，就短路跳过，直接进入 Plan。仪式感不是目的，清晰才是。

/ce:plan：把需求变成可执行的技术方案

Plan 的核心是并行研究。它会同时启动多个子 Agent：一个分析代码库现有模式，一个查外部最佳实践文档，一个研究 git 历史找类似改动。研究结束后综合成一份方案文档（docs/plans/YYYY-MM-DD-NNN-<type>-<name>-plan.md）。

方案的粒度有三档：

  • Minimal（2-5 分钟）：小 bug、简单功能
  • More（10-15 分钟）：普通功能、复杂 bug
  • A Lot（30 分钟以上）：大功能、架构调整

方案文档里，每个实现单元都会列出：目标、依赖文件、具体实现思路、测试场景（正常路径、边界情况、错误路径）。不写代码，只写思路——足够清晰，足够可执行，任何 AI 拿到都能按图索骥。

/ce:review：多 Agent 并行审查

单个 AI 审查代码有盲区。/ce:review 的方案是同时跑 17+ 个有角色分工的子 Agent：

必跑的几个：

  • correctness-reviewer：逻辑错误、边界情况、状态 bug
  • testing-reviewer：测试覆盖缺口、断言是否有效
  • maintainability-reviewer：耦合度、命名、死代码
  • project-standards-reviewer：是否符合 CLAUDE.md 中的规约
  • learnings-researcher：检索 docs/solutions/，看有没有处理过同类问题

按改动内容触发的：

  • security-reviewer（改动涉及认证、权限时）
  • performance-reviewer（涉及 DB 查询、缓存时）
  • data-migrations-reviewer（有 schema 变更时）
  • 还有针对 Rails、TypeScript、前端 race condition 等的专项审查

发现的问题按严重程度分四级（P0-P3），并标注是否可以自动修复。有四种运行模式：

模式 行为
Interactive（默认） 展示发现，询问修复策略
Autofix 静默修复可安全自动改的问题
Report-only 只报告，不修改任何文件
Headless 返回结构化 JSON，供其他 Skill 调用

/ce:compound：这一步决定有没有复利

Review 结束后，大多数人会直接 merge 进 main。/ce:compound 做的事是：在 merge 之前，把这次解决的问题记录下来。

它启动 5 个并行子 Agent：分析问题根因、提取解法、对比历史文档、提炼预防策略、给问题分类。最终写入 docs/solutions/<category>/ 下的 Markdown 文件，带 YAML frontmatter 方便检索。

分类会自动判断：build-errors/、test-failures/、performance-issues/、security-issues/ 等。

learnings-researcher 这个 Reviewer 在下次 Review 时会主动检索这个目录，把历史解法带入当前 Review。循环闭合了——知识在系统里流动，而不是停在人脑里。

第一次遇到同类问题：30 分钟研究 + 15 分钟修复 + 5 分钟文档 = 50 分钟。第二次：2 分钟查找 + 3 分钟修复 = 5 分钟。这就是复利在数字上的体现。

/ce:work：执行

相对直接：读取 Plan 文档，建 git worktree，把实现单元变成 Todo，逐步执行，持续跑测试，增量提交。对于多个独立任务，并行启动多个子 Agent。执行完自动创建 PR。

多工具接入的技术实现

插件提供了一个 Bun/TypeScript CLI（@every-env/compound-plugin），把 Claude Code 的 Skill 格式转换成各平台原生格式：

目标平台 输出格式 写入路径
OpenCode .md 命令文件 + MCP 配置 ~/.config/opencode/
Codex prompts + skills ~/.codex/
Gemini CLI agents（.toml）+ skills .gemini/
GitHub Copilot .agent.md + MCP env vars .github/
Cursor cursor-plugin 格式 .cursor-plugin/
Windsurf 用户级配置 ~/.codeium/windsurf/
Kiro CLI JSON + .md prompts .kiro/

转换时会处理工具差异：命令调用方式、子 Agent 的启动方式、用户交互接口（问答 UI）都会映射到目标平台的原生实现。同一套工作流，在 OpenCode 里跑和在 Claude Code 里跑，行为是一致的。

如果需要同时安装到多个工具：

1
bunx @every-env/compound-plugin install compound-engineering --to codex --also opencode

戴明说，95% 的问题来自系统，5% 来自人。

工程师换了一批又一批，同样的坑换个人继续踩。原因不是人不够聪明，是系统没有记忆。复利工程想做的，是给工程系统装上记忆——AI 每次工作后，系统比上次聪明一点，下次工作比上次容易一点。

这件事在 AI 之前做起来很贵，现在不贵了。

参考资料：