一個人，管理開發5款產品，而且80% 時間不在寫代碼，靠這一步...
整理版優先睇
複利工程嘅核心：每次完成功能後多做一步固化，令 AI 下次自動避坑
呢篇文章係由 Every 團隊親自介紹佢哋嘅「複利工程」方法論。Every（every.to）係一間 2020 年成立嘅媒體加軟件公司，CEO 係 Dan Shipper。佢哋每日出一份講科技下一步嘅付費 newsletter，同時自己開發多款軟件產品，包括 Cora、Monologue、Sparkle、Spiral 同官網。佢哋發現傳統工程團隊往往喺 Review 階段就停低，但其實仲差一步：Compound（固化）。
複利工程嘅核心係一個四步循環：Plan → Work → Review → Compound。傳統團隊行完頭三步就收手，但 Every 主張一定要行埋第四步，將每次解決問題嘅解法變成系統嘅記憶，等 AI 下次自動避開同類錯誤。呢個差距隨住時間累積，效率會越拉越大。
文章詳細講解咗呢套方法點樣運作，包括點樣用 80% 時間做計劃同審查、寫 code 只佔 20%，同埋佢哋開發嘅開源插件點樣透過多 agent 並行工作（例如一次 review 出動 14 個專項 agent）嚟大幅提升效率。總括嚟講，複利工程嘅核心係將每一次工程工作都變成系統嘅資產，而非負擔。
- 四步循環：Plan → Work → Review → Compound，第四步 Compound 係關鍵，將解法寫入系統令 AI 下次自動避坑。
- 時間分配反直覺：80% 用喺 Plan 同 Review，只有 20% 用嚟寫 code 同固化。
- 開源插件提供 26 個專項 agent、23 條工作流命令、13 項技能，零配置即用，支援 Claude Code / OpenCode / Codex。
- /workflows:review 一次併發 14 個專項 agent 審查代碼，/workflows:plan 開 ultrathink 模式可併發 40+ 個 agent。
- 透過 CLAUDE.md 同 docs/solutions/ 累積知識，每完成一次 Compound 就多一條規則，系統越用越聰明。
複利工程插件開源地址
GitHub 上嘅 plugin 倉庫，包含所有 agent、工作流同技能，可用於 Claude Code、OpenCode、Codex。
Every 原文《Compound Engineering》
Every 官方 guide，詳細解釋方法論同實踐。
邊個提出呢套方法？
Every（every.to）係一間 2020 年成立嘅媒體加軟件公司，CEO 係 Dan Shipper。佢哋每日出一份講「科技下一步」嘅付費 newsletter，同時自己做軟件產品，包括 Cora、Monologue、Sparkle、Spiral 同埋官網 Every.to。每個產品基本上由一個人維護，所以「複利工程」係佢哋從實戰中攞出來嘅方法。
四步循環：Plan → Work → Review → Compound
呢個循環係複利工程嘅核心。無論係 fix bug 定做功能，都行呢四步，只係每步時間唔同。前三步任何開發者都熟，但第四步 Compound 先係真正嘅分界線。
- 1 Plan：將諗法變成藍圖，包括需求約束、研究代碼庫、查框架文檔、設計方案同校驗。
- 2 Work：用 git worktree 開隔離環境，agent 按計劃逐步實現，每改一處就跑測試、linting 同類型檢查。
- 3 Review：多個專項 agent 並行審查，將問題標成 P1（必須修）、P2（應該修）、P3（可以修）。
- 4 Compound：將解法抽成可複用嘅知識寫返入系統，產出嘅係一個每次都能做得更好嘅系統。
好多人以為寫 code 佔最多時間，但 Every 話 Plan 同 Review 加埋佔 80%，真正寫 code 同固化只佔 20%。呢個反直覺嘅分配係因為大部分思考發生喺 code 被寫之前同之後。
第四步 Compound 點樣做？
Compound 嘅產出唔係 code，而係「系統下次自動避開同類問題」嘅能力。具體做四個動作：
- 1 記錄解法：記低咩有效、咩冇用、邊度可以複用。
- 2 加元數據：用 YAML frontmatter 打標籤，方便日後檢索。
- 3 更新 CLAUDE.md：將新模式寫入 agent 每次啟動都會讀嘅操作手冊。
- 4 驗證學到嘢：測試下次 agent 係咪自動應對同類問題。
CLAUDE.md 就係項目根目錄嘅「AI 操作手冊」，每解決一個新問題就加一條規則。docs/solutions/ 就係一座機構知識庫，每個解決過嘅問題都存成帶 YAML frontmatter 嘅 markdown，用 /workflows:compound 命令會併發六個子 agent 處理。
14 個 AI 同時幫你審 code，點樣運作？
一條 PR 提交，/workflows:review 命令會一次性派出 14 個專項 agent，同時開跑，每個只盯一個維度。包括安全（security-sentinel）、性能（performance-oracle）、架構（architecture-strategist）、數據完整性（data-integrity-guardian）等。
- 審查結果合併去重，歸成 P1、P2、P3 清單。
- 之後可以用 /resolve_pr_parallel 自動處理全部問題，先修 P1 再修 P2，每個修復各自隔離。
- 如果想先篩選，用 /triage 逐條決定批准、跳過或改優先級。
除咗 review，/workflows:plan 開 ultrathink 模式可以併發 40+ 個研究 agent。成個插件包含 26 個專項 agent、23 條工作流命令同 13 項技能。
點樣安裝同開始用？
插件支援 Claude Code（實驗性支援 OpenCode 同 Codex），安裝好簡單：
# Claude Code
claude /plugin marketplace add https://github.com/EveryInc/every-marketplace
claude /plugin install compound-engineering
# OpenCode / Codex
bunx @every-env/compound-plugin install compound-engineering --to opencode
bunx @every-env/compound-plugin install compound-engineering --to codex裝好之後，一條命令 /lfg 就可以跑完整條流水線：你只描述功能，系統會派出 50 幾個 agent，最後交一個可以直接合併嘅 PR。
深度 · 小互解讀
被所有團隊跳過嘅第四步，先係 AI 工程嘅關鍵
Every 單人團隊營運 5 款產品，核心係每次完成功能後多做嘅一步：將解法存落系統，等 AI 下次自動避坑。
速覽
01 Every 用「複利工程」（Compound Engineering）方法論，以基本單人嘅工程團隊維護旗下 5 款產品，核心係 Plan → Work → Review → Compound 四步循環。
02 傳統工程去到 Review 就停咗，第四步 Compound 將每次解決嘅問題變成系統知識，等 AI 下次自動避開同類錯誤，效率差距就嚟自呢度。
03 呢套方法主張工程師 80% 嘅時間用喺 Plan 同 Review，只有 20% 用來實際寫程式碼。
04 配套插件已開源，支援 Claude Code / OpenCode / Codex，含 26 個專項 agent、23 條工作流命令、13 項技能，零配置即用。
05 /workflows:review 一次調用並發 14 個專項 agent 審查程式碼，/workflows:plan 開 ultrathink 模式可並發 40 幾 個研究 agent。
⚑ 立場提示
本文係 Every 團隊自述其「複利工程」方法論同自家開源插件嘅實踐，文入面嘅並發規模、時間分配、產品數量都係官方口徑。下面只講佢點樣運作、每個數字代表啲乜。
▸ 先認識下 Every
Every（every.to）係一間 2020 年成立嘅媒體 ＋ 軟件公司，CEO 兼聯合創辦人係 Dan Shipper。佢每日出一份講「科技下一步」嘅付費 newsletter，同時自己動手做軟件產品——文入面嘅 Cora、Monologue、Sparkle、Spiral 都係出自佢，另外仲做 AI 課程同諮詢。所以「複利工程」唔係紙上談兵，而係一間又寫又做、日日浸喺 AI 裏面嘅公司，從自家實戰入面攢出嚟嘅方法。
01一個人撐五款產品，點樣做到
Every 團隊最近公開咗一套叫「複利工程」（Compound Engineering）嘅方法論，外加一個配套嘅開源插件，講佢哋點樣用基本係單人配置嘅工程團隊，同時維護旗下五款產品。
五款產品 Cora、Monologue、Sparkle、Spiral，加上官網 Every.to，每個產品嘅工程團隊基本得一個人。撐住呢套規模嘅唔係更長嘅工時，而係一個四步循環入面俾大多數團隊省略咗嘅最後一步。
◆ 點解值得睇
Every 將平時只喺內部行嘅嘢開源咗，包括 14 個 AI 同時睇一段程式碼、計劃階段並發 40 幾 個研究 agent，再加 26 個專項 agent。呢個係目前公開嘅多 agent 並行工程實踐入面，數字最具體嘅開源參考之一。
02程式碼越寫越難搞，根源喺邊
大多數程式碼庫隨時間越嚟越難維護，原因唔複雜：每加一個功能，就注入一份新嘅複雜度，新功能要同所有舊功能「傾數」。十年落嚟，團隊花喺同歷史程式碼角力嘅時間，仲多過花喺整新嘢上面，程式碼變得越嚟越難明、難改、難信賴。
複利工程將呢條曲線反轉。功能唔再係加負擔，而係教識系統一項新本領；修一個 bug，順手消滅將來一整類同類 bug；一個解法被固化落嚟，就變成下次可以直接複用嘅工具。迭代越多，系統越好用。
同一條橫軸（功能 / 迭代越來越多），兩種走向：傳統程式碼庫改一處越來越辛苦，複利工程就令每次迭代都將系統墊得更加順手。
03四步循環：80% 嘅時間根本唔係寫程式碼
支撐呢套規模嘅，係一個四步循環：Plan（計劃）、Work（執行）、Review（審查）、Compound（固化），然後重複。無論你係用五分鐘修一個 bug，定係用幾日做一個功能，都係行呢四步，只係每一步花嘅時間多少唔同。
前三步任何開發者都熟，第四步 Compound 先係複利工程同普通工程嘅分界線。跳過佢，你做嘅就只係「有 AI 助手嘅傳統工程」。
Plan
計劃
Work
執行
Review
審查
Compound
固化
傳統工程到此收手
去到 Review 就停
複利工程多行一步
將呢輪學到嘅留俾下一輪
傳統工程到 Review 收手，複利工程就行多 Compound 一步，將呢輪學到嘅嘢留俾下一輪。
▪ 反直覺嘅地方：寫程式碼只佔兩成時間
Plan 同 Review 加埋佔工程師 80% 嘅時間，真正動手寫（Work）加上固化（Compound）只佔 20%。大部分思考發生喺程式碼被寫出嚟之前同之後。
▪ 四步各自做緊啲乜
Plan計劃
將想法變成藍圖。搞清楚需求同限制、研究程式碼庫入面同類功能點樣實現、查框架文檔同最佳實踐、設計方案、再驗證方案係咪站得住。
Work執行
先用 git worktree（你倉庫嘅一個隔離沙盒副本，多個任務可以各開一份並行行、互不幹擾）開出隔離環境，agent 按計劃逐步實現，每改一處就行測試、linting（自動程式碼檢查）同類型檢查。
Review審查
多個專項 agent 並行審，將問題標成 P1（必須修）/ P2（應該修）/ P3（可以修），修完再驗證，並記錄呢次出咗咩問題。
Compound固化
將解法抽成可複用嘅知識寫返入系統，下面一節專門講。
▪ 幾個 Every 建議掉咗嘅舊觀念
✕ 「程式碼一定要手寫」 你嘅職責係產出可維護、解決到問題嘅好程式碼，邊個打字唔重要。
✕ 「第一版就應該寫好」 佢哋嘅經驗入面，第一版 95% 係垃圾、第二版仲有 50%，呢個係過程，目標係迭代夠快，令第三版落地仲快過第一版。
✕ 「唔親手打就學唔到」 今日理解比肌肉記憶重要，審 10 個 AI 實現比手打 2 個學到嘅模式更多。
✕ 「程式碼係自我表達」 程式碼從來唔屬於你個人，佢屬於團隊、產品同用戶。
04第四步具體點樣做：將解法變成系統嘅記憶
前三步（計劃、執行、審查）產出嘅係「一個功能」。第四步 Compound 產出嘅係「一個每次都能夠將功能做得更好嘅系統」。佢落到地上係四個動作。
1記錄解法乜嘢有用、乜嘢冇用、可複用嘅點係邊個。
2加元數據用 YAML frontmatter 打標籤，方便日後檢索。
3更新 CLAUDE.md將新模式寫入 agent 每次啟動都會讀嘅文件。
4驗證學到咗下次佢能夠自動接住同類問題嗎。
▸ 順帶科普 · YAML frontmatter
佢係文檔頂部嘅一段元數據標籤（標題、分類、關鍵詞），令呢條解法日後可以被按條件搜到、精確拎返出嚟，而唔係寫完就埋咗落一堆文檔入面揾唔到。
複利嘅來源
傳統開發停喺第三步審查，複利工程就多行呢一步：將啱啱解決嘅問題寫入系統。呢一步唔產出程式碼，產出嘅係「系統下次自動避開同類問題」嘅能力。效率差距就嚟自呢度。
▸ 打個比喻 · CLAUDE.md
CLAUDE.md 就係放喺項目根目錄嘅「AI 操作手冊」，agent 每次啟動都會先讀佢。佢好似新員工入職必讀嘅 SOP 手冊：每當有人解決咗一個之前未遇過嘅問題，就加一條規則落去，下一個人嚟就會自動明，唔使再踩多次同一條坑。
下面呢個對照，可以直接睇到呢條規則累積落嚟之後嘅差別：
✕冇累積，純靠現場處理
agent 唔知呢個坑，你同佢一齊除錯、定位、修好。修完，Compound 步驟將「點解會出、點樣避開」寫入 CLAUDE.md，並存一份帶 YAML 標籤嘅文檔落 docs/solutions/。呢次用多咗啲時間記錄。
✓系統已經記住咗
agent 一啟動就讀到咗嗰條規則，docs/solutions/ 入面都搜到上次嗰份解法。於是在 Plan 計劃階段，佢就主動繞開咗同類問題，根本行唔到出 bug 嗰一步。之前記錄嘅時間，喺呢度連本帶利賺返嚟。
▪ 每完成一次 Compound，CLAUDE.md 就多一條知識
迭代 1
1
條知識
迭代 3
3
條知識
迭代 5
8
條知識
每完成一次 Compound，CLAUDE.md 就多一條知識，系統越用越聰明。
▪ docs/solutions/ 點樣累積成一座機構知識庫
每個解決過嘅問題都被存成一份帶 YAML frontmatter 嘅 markdown，自動歸類打標籤。Every 用 /workflows:compound 命令行呢一步，佢會並發派出六個子 agent，日後任何一次會話，都能夠自動從呢堆文檔入面翻到過去嘅解法，而唔使靠某個資深工程師記喺個腦度。
/workflows:compound · 並發六個子 agent
1 理解問題
2 抽取解法
3 揾出相關舊文檔並互相連結
4 寫「點樣避免復發」
5 做分類標籤
6 排版成文檔
0514 個 AI 同時幫你睇程式碼
一條 PR（程式碼改動提交）入嚟，/workflows:review 呢條命令會一次過派出 14 個專項 agent，同時開行，每個只盯一個維度：安全、性能、架構、數據、程式碼質量、框架規範等。佢哋各自查各自嘅，最後將結果合併成一份按 P1（必須修）/ P2（應該修）/ P3（可以修）排好優先級嘅清單。
一條 PR 同時輻射俾 14 個 agent，顏色對應維度分組（磚紅＝風險/數據完整，琥珀＝性能/運維/前端，森林綠＝架構/質量/Agent-native）。佢哋並發行，唔係排隊行。
01security-sentinel· 安全
掃 OWASP Top 10（公認最常俾人利用嘅十類網絡安全漏洞）、注入攻擊、認證同越權。
02performance-oracle· 性能
捉 N+1 查詢、欠索引、可緩存點、算法瓶頸。
03architecture-strategist· 架構
評估系統設計、組件邊界、依賴方向。
04pattern-recognition-specialist· 架構
識別設計模式、反模式、程式碼壞味道。
05data-integrity-guardian· 數據
校驗數據庫遷移、事務邊界、引用完整性。
06data-migration-expert· 數據
檢查 ID 映射、回滾安全、生產數據校驗。
07code-simplicity-reviewer· 質量
執行 YAGNI（唔好為可能用得到嘅功能提早寫程式碼），捉多餘複雜度。
08kieran-rails-reviewer· 質量
Rails 規範、Turbo Streams、模型同控制器職責劃分。
09kieran-python-reviewer· 質量
PEP 8 規範、類型註解、Pythonic 寫法。
10kieran-typescript-reviewer· 質量
類型安全、現代 ES 寫法、整潔架構。
11dhh-rails-reviewer· 質量
37signals 風格：簡單優先於抽象。
12deployment-verification-agent· 部署
產生上線前檢查清單、上線後驗證步驟、回滾預案。
13julik-frontend-races-reviewer· 前端
捉 JavaScript 同 Stimulus 控制器入面嘅競態。
14agent-native-reviewer· Agent-native
確保功能唔止人用得，agent 都用得。
▸ 順帶科普 · N+1 查詢
02 號 agent 專盯嘅 N+1 查詢，係數據庫性能入面嘅常見陷阱：查一張 100 條嘅列表，寫法唔啱就會變成每條再單獨查一次，總共 101 次請求。好似去超市買 10 樣嘢但係行咗 11 趟，先去睇下有啲乜（1 趟），然後每樣嘢再單獨去拎一次（10 趟）。
▪ 14 路並發結果合併去重，歸到一份帶優先級嘅清單
P1 · 必須修
☐ 搜索查詢有 SQL 注入漏洞 security-sentinel
☐ 建立用戶缺少事務包裹 data-integrity-guardian
P2 · 應該修
☐ 留言加載有 N+1 查詢 performance-oracle
☐ 控制器入面塞咗業務邏輯 kieran-rails-reviewer
P3 · 可以修
☐ 有一個未使用嘅變數 code-simplicity-reviewer
▪ 清單出咗之後點樣處理
/resolve_pr_parallel 自動處理曬所有問題，先修 P1 再修 P2，每個修復各自隔離行，互不踩腳，最後由你人手過一次生成嘅改動。
如果想篩咗先再修，用 /triage：逐條俾人決定批准（入待辦）、跳過（刪咗）或者改優先級，批准咗嘅標成 status: ready，再交俾 /resolve_todo_parallel 幹。
06插件入面有啲乜，裝咗點樣用
成個流程打包成一個插件，裝咗就用得，零配置。支援 Claude Code，亦實驗性支援 OpenCode 同 Codex。
26專項 agent
每個只專注一件事：14 個 review 專家，加埋研究型、設計型、自動化、文檔型。
23工作流命令
主循環命令（plan / work / review / compound）加一批實用工具命令。
13技能
即取即用嘅領域知識，例如 agent-native 架構技能、風格指南技能。
▪ 各個文件管啲乜
CLAUDE.md — agent 每次啟動必讀嘅操作手冊：偏好、約定、踩過嘅坑。
docs/solutions/ — 每個解決過嘅問題存成可搜尋文檔，下次會話自動揾到。
docs/plans/ · brainstorms/ — /plan 同 /brainstorm 嘅產出。
todos/ — review 查出嘅問題，帶優先級同狀態。
▪ 兩行命令裝好（Claude Code）
claude /plugin marketplace add https://github.com/EveryInc/every-marketplace
claude /plugin install compound-engineering
▪ OpenCode / Codex 安裝命令
bunx @every-env/compound-plugin install compound-engineering --to opencode
bunx @every-env/compound-plugin install compound-engineering --to codex
▪ 一條命令行完整條流水線
/lfg：你只描述功能，佢就將成條流水線串埋自動行，全程派出 50 幾 個 agent，最後交俾你一個可以直接合併嘅 PR。中途只係喺計劃批准度停一停。
07關鍵數字：並發 agent 嘅規模到底有幾大
將呢套系統嘅規模落到幾個具體數字上。
5 款
Every 用呢套方法維護嘅產品數量，工程團隊基本為單人配置。
80 / 20
計劃＋審查佔工程師 80% 時間，執行＋固化只佔 20%。
14 個
/workflows:review 一次調用同時運行嘅專項審查 agent 數量。
40+ 個
/workflows:plan 開 ultrathink 模式後派出嘅研究 agent 數量。
26 / 23 / 13
插件包含嘅專項 agent 數 / 工作流命令數 / 技能數。
“
每一份工程工作，都應該令後續嘅工作更容易，而唔係更難。
Every《Compound Engineering》
本文為 Every 團隊自述其「複利工程」方法論與開源插件實踐，文中並發規模、時間分配、產品數量均為其官方口徑。
原文：Every《Compound Engineering》
every.to/guides/compound-engineering
插件開源地址：
github.com/EveryInc/compound-engineering-plugin
深度 · 小互解讀
被所有團隊跳過的第四步，才是 AI 工程的關鍵
Every 單人團隊運營 5 款產品，核心是每次完成功能後多做的一步：把解法存進系統，讓 AI 下次自動避坑。
速覽
01 Every 用「複利工程」（Compound Engineering）方法論，以基本單人的工程團隊維護旗下 5 款產品，核心是 Plan → Work → Review → Compound 四步循環。
02 傳統工程走到 Review 就停了，第四步 Compound 把每次解決的問題變成系統知識，讓 AI 下次自動避開同類錯誤，效率差距就來自這裏。
03 這套方法主張工程師 80% 的時間花在 Plan 和 Review，只有 20% 用來實際寫代碼。
04 配套插件已開源，支持 Claude Code / OpenCode / Codex，含 26 個專項 agent、23 條工作流命令、13 項技能，零配置即用。
05 /workflows:review 一次調用併發 14 個專項 agent 審查代碼，/workflows:plan 開 ultrathink 模式可併發 40 多 個研究 agent。
⚑ 立場提示
本文是 Every 團隊自述其「複利工程」方法論與自家開源插件的實踐，文中的併發規模、時間分配、產品數量都是官方口徑。下面只講它怎麼運作、每個數字代表什麼。
▸ 先認識下 Every
Every（every.to）是一家 2020 年成立的媒體 ＋ 軟件公司，CEO 兼聯合創始人是 Dan Shipper。它每天發一份講「科技下一步」的付費 newsletter，同時自己動手做軟件產品——文中的 Cora、Monologue、Sparkle、Spiral 都出自它，另外還做 AI 課程和諮詢。所以「複利工程」不是紙上談兵，是一家又寫又做、天天泡在 AI 裏的公司，從自家實戰裏攢出來的方法。
01一個人撐五款產品，怎麼做到的
Every 團隊最近公開了一套叫「複利工程」（Compound Engineering）的方法論，外加一個配套的開源插件，講他們怎麼用基本是單人配置的工程團隊，同時維護旗下五款產品。
五款產品 Cora、Monologue、Sparkle、Spiral，加上官網 Every.to，每個產品的工程團隊基本只有一個人。撐住這套規模的不是更長的工時，而是一個四步循環裏被大多數團隊省掉的最後一步。
◆ 為什麼值得看
Every 把平時只在內部跑的東西開源了，包括 14 個 AI 同時審一段代碼、計劃階段併發 40 多 個研究 agent，外加 26 個專項 agent。這是目前公開的多 agent 並行工程實踐裏，數字最具體的開源參考之一。
02代碼越寫越難碰，根子在哪
大多數代碼庫隨時間越來越難維護，原因不復雜：每加一個功能，就往系統裏注入一份新的複雜度，新功能要和所有舊功能「談判」。十年下來，團隊花在跟歷史代碼較勁上的時間，比花在造新東西上的還多，代碼變得越來越難懂、難改、難信任。
複利工程把這條曲線反過來。功能不再是往系統里加負擔，而是教會系統一項新本領；修一個 bug，順手消掉未來一整類同類 bug；一個解法被固化下來，就變成下次能直接複用的工具。迭代越多，系統越好用。
同一條橫軸（功能 / 迭代越來越多），兩種走向：傳統代碼庫改一處越來越費勁，複利工程讓每次迭代都把系統墊得更順手。
03四步循環：80% 的時間根本不是在寫代碼
支撐這套規模的，是一個四步循環：Plan（計劃）、Work（執行）、Review（審查）、Compound（固化），然後重複。不管你是花五分鐘修個 bug，還是花幾天做個功能，走的都是這四步，只是每步花的時間多少不同。
前三步任何開發者都熟，第四步 Compound 才是複利工程和普通工程的分界線。跳過它，你做的就只是「有 AI 助手的傳統工程」。
Plan
計劃
Work
執行
Review
審查
Compound
固化
傳統工程到此收手
走到 Review 就停
複利工程多走一步
把這輪學到的留給下一輪
傳統工程到 Review 收手，複利工程多走 Compound 一步，把這一輪學到的東西留給下一輪。
▪ 反直覺的地方：寫代碼只佔兩成時間
Plan 和 Review 加起來佔工程師 80% 的時間，真正動手寫（Work）加上固化（Compound）只佔 20%。大部分思考發生在代碼被寫出來之前和之後。
▪ 四步各自在做什麼
Plan計劃
把想法變成藍圖。弄清需求和約束、研究代碼庫裏同類功能怎麼實現、查框架文檔和最佳實踐、設計方案、再校驗方案是否站得住。
Work執行
先用 git worktree（你倉庫的一個隔離沙盒副本，多個任務可以各開一份並行跑、互不干擾）開出隔離環境，agent 按計劃逐步實現，每改一處就跑測試、linting（自動代碼檢查）和類型檢查。
Review審查
多個專項 agent 並行審，把問題標成 P1（必須修）/ P2（應該修）/ P3（可以修），修完再校驗，並記錄這次出了什麼問題。
Compound固化
把解法抽成可複用的知識寫回系統，下面一節專門講。
▪ 幾個 Every 建議丟掉的舊觀念
✕ 「代碼必須手寫」 你的職責是產出可維護、解決對問題的好代碼，誰敲鍵盤不重要。
✕ 「第一版就該寫好」 他們的經驗裏第一版 95% 是垃圾、第二版還有 50%，這是過程，目標是迭代夠快讓第三版落地比第一版還省時。
✕ 「不親手敲就學不到」 今天理解比肌肉記憶重要，審 10 個 AI 實現比手敲 2 個學到的模式更多。
✕ 「代碼是自我表達」 代碼從來不屬於你個人，它屬於團隊、產品和用戶。
04第四步具體怎麼做：把解法變成系統的記憶
前三步（計劃、執行、審查）產出的是「一個功能」。第四步 Compound 產出的是「一個每次都能把功能做得更好的系統」。它落到地上是四個動作。
1記錄解法什麼管用、什麼沒用、可複用的點是哪個。
2加元數據用 YAML frontmatter 打標籤，方便日後檢索。
3更新 CLAUDE.md把新模式寫進 agent 每次啓動都讀的文件。
4驗證學到了下次它能自動接住同類問題嗎。
▸ 順帶科普 · YAML frontmatter
它是文檔頂部的一段元數據標籤（標題、分類、關鍵詞），讓這條解法日後能被按條件搜到、精確取回，而不是寫完就埋進一堆文檔裏找不着。
複利的來源
傳統開發停在第三步審查，複利工程多走這一步：把剛解決的問題寫進系統。這一步不產出代碼，產出的是「系統下次自動避開同類問題」的能力。效率差距就來自這裏。
▸ 打個比方 · CLAUDE.md
CLAUDE.md 就是放在項目根目錄的「AI 操作手冊」，agent 每次啓動都會先讀它。它像新員工入職必讀的 SOP 手冊：每當有人解決了一個之前沒遇到的問題，就往裏加一條規則，下一個人來就自動懂了，不用再踩一遍同樣的坑。
下面這個對照，能直觀看到這條規則攢下來之後的差別：
✕沒有積累，純靠現場排
agent 不知道這個坑，你和它一起調試、定位、修好。修完，Compound 步驟把「為什麼會出、怎麼避開」寫進 CLAUDE.md，並存一份帶 YAML 標籤的文檔進 docs/solutions/。這一次多花了點時間記錄。
✓系統已經記住了
agent 一啓動就讀到了那條規則，docs/solutions/ 裏也能搜到上次那份解法。於是在 Plan 計劃階段，它就主動繞開了同類問題，根本走不到出 bug 那一步。前面那次記錄的時間，在這裏連本帶利賺回來。
▪ 每完成一次 Compound，CLAUDE.md 就多一條知識
迭代 1
1
條知識
迭代 3
3
條知識
迭代 5
8
條知識
每完成一次 Compound，CLAUDE.md 就多一條知識，系統越用越聰明。
▪ docs/solutions/ 怎麼攢成一座機構知識庫
每個解決過的問題都被存成一份帶 YAML frontmatter 的 markdown，自動歸類打標籤。Every 用 /workflows:compound 命令跑這一步，它會併發派出六個子 agent，日後任何一次會話，都能自動從這堆文檔裏翻到過去的解法，而不用靠某個資深工程師記在腦子裏。
/workflows:compound · 併發六個子 agent
1 理解問題
2 抽取解法
3 找出相關舊文檔並互鏈
4 寫「怎麼避免復發」
5 做分類標籤
6 排版成文檔
0514 個 AI 同時幫你審代碼
一條 PR（代碼改動提交）進來，/workflows:review 這條命令會一次性派出 14 個專項 agent，同時開跑，每個只盯一個維度：安全、性能、架構、數據、代碼質量、框架規範等。它們各查各的，最後把結果合併成一份按 P1（必須修）/ P2（應該修）/ P3（可以修）排好優先級的清單。
一條 PR 同時輻射給 14 個 agent，顏色對應維度分組（磚紅＝風險/數據完整，琥珀＝性能/運維/前端，森林綠＝架構/質量/Agent-native）。它們併發跑，不是排隊跑。
01security-sentinel· 安全
掃 OWASP Top 10（公認最常被利用的十類網絡安全漏洞）、注入攻擊、認證與越權。
02performance-oracle· 性能
揪 N+1 查詢、缺索引、可緩存點、算法瓶頸。
03architecture-strategist· 架構
評估系統設計、組件邊界、依賴方向。
04pattern-recognition-specialist· 架構
識別設計模式、反模式、代碼壞味道。
05data-integrity-guardian· 數據
校驗數據庫遷移、事務邊界、引用完整性。
06data-migration-expert· 數據
檢查 ID 映射、回滾安全、生產數據校驗。
07code-simplicity-reviewer· 質量
執行 YAGNI（別為可能用到的功能提前寫代碼），揪多餘複雜度。
08kieran-rails-reviewer· 質量
Rails 規範、Turbo Streams、模型與控制器職責劃分。
09kieran-python-reviewer· 質量
PEP 8 規範、類型註解、Pythonic 寫法。
10kieran-typescript-reviewer· 質量
類型安全、現代 ES 寫法、整潔架構。
11dhh-rails-reviewer· 質量
37signals 風格：簡單優先於抽象。
12deployment-verification-agent· 部署
生成上線前檢查單、上線後驗證步驟、回滾預案。
13julik-frontend-races-reviewer· 前端
揪 JavaScript 和 Stimulus 控制器裏的競態。
14agent-native-reviewer· Agent-native
確保功能不只人能用，agent 也能用。
▸ 順帶科普 · N+1 查詢
02 號 agent 專盯的 N+1 查詢，是數據庫性能裏的常見陷阱：查一張 100 條的列表，寫法不對就變成每條再單獨查一次，一共 101 次請求。像去超市買 10 樣東西卻跑了 11 趟，先去看看有什麼（1 趟），然後每樣東西再單獨去取一次（10 趟）。
▪ 14 路併發結果合併去重，歸到一份帶優先級的清單
P1 · 必須修
☐ 搜索查詢有 SQL 注入漏洞 security-sentinel
☐ 創建用戶缺少事務包裹 data-integrity-guardian
P2 · 應該修
☐ 評論加載有 N+1 查詢 performance-oracle
☐ 控制器裏塞了業務邏輯 kieran-rails-reviewer
P3 · 可以修
☐ 有一個未使用的變量 code-simplicity-reviewer
▪ 清單出來之後怎麼處理
/resolve_pr_parallel 自動處理全部問題，先修 P1 再修 P2，每個修復各自隔離跑，互不踩腳，最後由你人工過一遍生成的改動。
如果想先篩再修，用 /triage：逐條讓人決定批准（進待辦）、跳過（刪掉）或改優先級，批准的標成 status: ready，再交給 /resolve_todo_parallel 幹。
06插件裏有什麼，裝上怎麼用
整套流程打包成一個插件，裝上就能用，零配置。支持 Claude Code，也實驗性支持 OpenCode 和 Codex。
26專項 agent
每個只精一件事：14 個 review 專家，外加研究型、設計型、自動化、文檔型。
23工作流命令
主循環命令（plan / work / review / compound）加一批實用工具命令。
13技能
即取即用的領域知識，比如 agent-native 架構技能、風格指南技能。
▪ 各個文件管什麼
CLAUDE.md — agent 每次啓動必讀的操作手冊：偏好、約定、踩過的坑。
docs/solutions/ — 每個解決過的問題存成可搜索文檔，下次會話自動找到。
docs/plans/ · brainstorms/ — /plan 與 /brainstorm 的產出。
todos/ — review 查出的問題，帶優先級和狀態。
▪ 兩行命令裝好（Claude Code）
claude /plugin marketplace add https://github.com/EveryInc/every-marketplace
claude /plugin install compound-engineering
▪ OpenCode / Codex 安裝命令
bunx @every-env/compound-plugin install compound-engineering --to opencode
bunx @every-env/compound-plugin install compound-engineering --to codex
▪ 一條命令跑完整條流水線
/lfg：你只描述功能，它把整條流水線串起來自動跑，全程派出 50 多 個 agent，最後交給你一個能直接合並的 PR。中途只在計劃批准處停一下。
07關鍵數字：併發 agent 的規模到底有多大
把這套系統的規模落到幾個具體數字上。
5 款
Every 用這套方法維護的產品數量，工程團隊基本為單人配置。
80 / 20
計劃＋審查佔工程師 80% 時間，執行＋固化只佔 20%。
14 個
/workflows:review 一次調用同時運行的專項審查 agent 數量。
40+ 個
/workflows:plan 開 ultrathink 模式後派出的研究 agent 數量。
26 / 23 / 13
插件包含的專項 agent 數 / 工作流命令數 / 技能數。
“
每一份工程工作，都應該讓後續的工作更容易，而不是更難。
Every《Compound Engineering》
本文為 Every 團隊自述其「複利工程」方法論與開源插件實踐，文中併發規模、時間分配、產品數量均為其官方口徑。
原文：Every《Compound Engineering》
every.to/guides/compound-engineering
插件開源地址：
github.com/EveryInc/compound-engineering-plugin