https://www.knightli.com/zh-tw/tags/compound-engineering/ Recent content in Compound Engineering on KnightLi的博客 Hugo -- gohugo.io zh-tw Fri, 01 May 2026 03:15:39 +0800 https://www.knightli.com/zh-tw/2026/05/01/compound-engineering-plugin-ai-coding-workflow/ Fri, 01 May 2026 03:15:39 +0800 https://www.knightli.com/zh-tw/2026/05/01/compound-engineering-plugin-ai-coding-workflow/ <p><code>Compound Engineering Plugin</code> 是 Every Inc 開源的一個 AI 編程工作流插件。</p> <p>它關注的不是「讓 AI 更快寫一段程式碼」，而是把 AI 編程放進一個更像工程團隊的循環裡：先計劃，再實現，再評審，再把經驗沉澱下來。對經常使用 Claude Code、Codex、Cursor、Copilot 這類工具的人來說，這類插件解決的是工作流問題，而不只是提示詞問題。</p> <p>AI 編程工具越來越強，但真實專案裡最難的往往不是生成程式碼，而是讓它持續按專案規則做事、理解任務邊界、避免重複犯錯，並在多輪迭代中積累上下文。</p> <h2 id="它解決什麼問題">它解決什麼問題 </h2><p>很多人使用 AI 編程助手時，流程大概是這樣：</p> <ol> <li>直接描述需求</li> <li>讓 AI 改程式碼</li> <li>看結果是否能跑</li> <li>出錯後繼續補充說明</li> <li>下次新任務再從頭解釋一遍</li> </ol> <p>這種方式能完成小任務，但在複雜專案裡很容易遇到問題：</p> <ul> <li>需求沒有先拆清楚，AI 直接開始改</li> <li>改完程式碼後缺少系統性 review</li> <li>專案規範靠使用者反覆提醒</li> <li>同類錯誤下次仍然出現</li> <li>多個 Agent 工具之間缺少統一工作方法</li> <li>經驗沒有沉澱成可複用規則</li> </ul> <p><code>Compound Engineering Plugin</code> 想解決的就是這類問題。它把 AI 編程拆成多個階段，讓 Agent 不只是執行命令，而是參與一個更完整的工程流程。</p> <h2 id="什麼是-compound-engineering">什麼是 Compound Engineering </h2><p>從專案 README 的描述看，Compound Engineering 可以理解為一種 AI 輔助軟體開發方法。</p> <p>它強調一個循環：</p> <ul> <li>計劃：先理解目標、拆分任務、確認路徑</li> <li>執行：按計劃修改程式碼、執行命令、處理問題</li> <li>評審：檢查實現品質、風險和測試覆蓋</li> <li>學習：把經驗沉澱成後續可複用的規則</li> </ul> <p>這個循環很像真實工程團隊的工作方式。</p> <p>一個可靠的工程師不會拿到需求就立刻亂改，也不會改完就直接交差。他會先判斷影響範圍，再動手實現，之後檢查風險和測試結果，最後把踩過的坑記錄下來。AI Agent 也需要類似約束。</p> <h2 id="為什麼需要插件">為什麼需要插件 </h2><p>提示詞可以告訴 AI「請先計劃再執行」，但提示詞本身不一定穩定。</p> <p>一旦會話變長、上下文變複雜，模型可能會跳過計劃、忽略規則，或者為了完成任務而過度自信。插件的價值在於把流程固化下來，讓不同 Agent 環境都能遵循類似方法。</p> <p>這類插件通常會把工作流拆成命令、規則、模板或子流程。使用者不需要每次手寫完整提示詞，而是透過固定入口觸發某個階段。</p> <p>比如：</p> <ul> <li>先讓 Agent 生成計劃</li> <li>再按計劃逐步實現</li> <li>改完後觸發 review</li> <li>發現問題後返回修正</li> <li>把值得保留的經驗寫入記憶或規則</li> </ul> <p>這會讓 AI 編程更像「受控協作」，而不是一次性聊天。</p> <h2 id="支援哪些-agent-環境">支援哪些 Agent 環境 </h2><p>README 中提到，專案支援多個 AI 編程環境，包括：</p> <ul> <li>Claude Code</li> <li>Codex</li> <li>Cursor</li> <li>GitHub Copilot</li> <li>Amp</li> <li>Factory</li> <li>Qwen Code</li> </ul> <p>這點值得注意。</p> <p>很多工作流工具只綁定一個客戶端，換工具後規則就不能複用。<code>Compound Engineering Plugin</code> 更像一套跨 Agent 的工程方法，把類似的計劃、執行、評審流程帶到不同工具裡。</p> <p>如果你同時使用多個 AI 編程助手，這類統一工作流會更有價值。不同工具能力不同，但專案規範、評審習慣和任務拆解方法應該盡量一致。</p> <h2 id="計劃階段有什麼用">計劃階段有什麼用 </h2><p>計劃階段的價值，是防止 AI 過早動手。</p> <p>複雜任務裡，真正重要的問題通常是：</p> <ul> <li>要改哪些檔案</li> <li>哪些模組可能受影響</li> <li>現有模式是什麼</li> <li>有沒有測試</li> <li>風險點在哪裡</li> <li>是否需要先閱讀文件</li> <li>能不能拆成更小步驟</li> </ul> <p>如果 Agent 沒有先想清楚這些問題，就直接開始寫程式碼，很容易做出看似完成、實際偏離專案結構的實現。</p> <p>計劃並不一定要很長。好的計劃應該短、具體、可執行。它的目的不是製造文件，而是讓後續實現有邊界。</p> <h2 id="執行階段要避免什麼">執行階段要避免什麼 </h2><p>AI 執行程式碼任務時，最容易出現幾類問題：</p> <ul> <li>順手重構無關程式碼</li> <li>覆蓋使用者已有修改</li> <li>只改 happy path</li> <li>忽略錯誤處理</li> <li>不按專案已有風格寫</li> <li>沒有執行必要驗證</li> <li>遇到錯誤後盲目嘗試</li> </ul> <p>工作流插件無法保證這些問題完全消失，但可以透過規則和階段約束減少發生機率。</p> <p>比如，執行階段可以要求 Agent 按計劃逐步推進；遇到超出計劃範圍的發現時，先說明風險；修改共享模組時，補充測試或至少執行相關驗證。</p> <p>這種約束對大型程式碼庫尤其重要。AI 寫程式碼越快，越需要流程來限制它的慣性。</p> <h2 id="評審階段為什麼重要">評審階段為什麼重要 </h2><p>很多 AI 編程失敗，不是因為程式碼完全不能執行，而是因為細節有問題：</p> <ul> <li>邊界條件沒處理</li> <li>狀態更新不一致</li> <li>API 合約被悄悄改了</li> <li>測試覆蓋不到關鍵路徑</li> <li>錯誤提示不清楚</li> <li>效能或安全風險沒有被提到</li> </ul> <p>評審階段就是把 Agent 從「作者模式」切換到「審查模式」。</p> <p>作者模式容易為自己的實現找理由；審查模式則要主動找漏洞、回歸風險和遺漏測試。把這兩個階段分開，會比讓同一個回覆裡同時完成實現和自我審查更可靠。</p> <p>對使用者來說，評審輸出也更有價值。它能幫助你快速判斷這次修改是否值得合併，還是需要繼續返工。</p> <h2 id="學習和記憶的意義">學習和記憶的意義 </h2><p>專案名字裡的 “Compound” 暗示了一個重要想法：工程經驗應該複利增長。</p> <p>如果 AI 每次犯錯後只是當場修好，下次又犯同樣錯誤，效率提升就很有限。更好的方式是把有價值的經驗沉澱下來：</p> <ul> <li>這個專案的目錄約定</li> <li>某類錯誤的排查方法</li> <li>測試命令和注意事項</li> <li>不要觸碰的生成檔案</li> <li>程式碼風格偏好</li> <li>常見實現模式</li> </ul> <p>這些經驗可以變成規則、記憶、文件或模板。後續任務中，Agent 先讀取這些沉澱，再開始工作。</p> <p>這就是 AI 編程從「單次問答」走向「長期協作」的關鍵。</p> <h2 id="適合什麼場景">適合什麼場景 </h2><p><code>Compound Engineering Plugin</code> 適合這些場景：</p> <ul> <li>長期使用 AI Agent 寫程式碼</li> <li>一個專案會被多次、多輪修改</li> <li>希望 AI 先計劃再實現</li> <li>希望改完後自動進入 review 思維</li> <li>團隊想統一 AI 編程流程</li> <li>同時使用 Claude Code、Codex、Cursor 等多個工具</li> <li>希望把專案經驗沉澱成可複用規則</li> </ul> <p>如果只是偶爾讓 AI 寫一個小腳本，完整流程可能顯得偏重。</p> <p>但如果你正在把 AI 編程助手當成日常開發夥伴，計劃、執行、評審、學習這套循環就會明顯有用。</p> <h2 id="和普通提示詞模板有什麼區別">和普通提示詞模板有什麼區別 </h2><p>普通提示詞模板通常解決的是「怎麼說清楚任務」。</p> <p>比如：</p> <ul> <li>請一步步思考</li> <li>請先閱讀檔案</li> <li>請保持程式碼風格一致</li> <li>請執行測試</li> <li>請總結修改內容</li> </ul> <p>這些提示當然有用，但它們還是依賴使用者每次正確使用。</p> <p><code>Compound Engineering Plugin</code> 更偏工作流層。它把這些要求組織成可重複的過程，並適配不同 Agent 工具。這樣你不是每次從零寫提示詞，而是在一套流程裡推進任務。</p> <p>簡單說，提示詞模板像提醒，工作流插件像制度。</p> <h2 id="使用時要注意">使用時要注意 </h2><p>第一，不要把流程變成負擔。</p> <p>小任務不一定需要完整計劃和長篇評審。好的工作流應該能根據任務複雜度調整，簡單問題快速處理，複雜問題再走完整循環。</p> <p>第二，評審不能替代測試。</p> <p>Agent review 能發現很多問題，但它仍然可能漏掉真實執行時錯誤。最終判斷還要看測試、型別檢查、構建結果和人工審查。</p> <p>第三，規則要持續清理。</p> <p>沉澱經驗很重要，但規則越積越多也會變成噪音。過時規則、重複規則、只適合某次任務的臨時經驗，都應該定期整理。</p> <p>第四，跨工具一致不等於完全相同。</p> <p>Claude Code、Codex、Cursor、Copilot 等工具能力和互動方式不同。統一的是工作方法，不一定是每個命令、每個配置細節都完全一樣。</p> <h2 id="適合怎樣的團隊">適合怎樣的團隊 </h2><p>如果一個團隊已經允許 AI Agent 修改真實程式碼，那麼只討論「哪個模型更強」是不夠的。</p> <p>更應該關心：</p> <ul> <li>AI 修改前是否理解任務</li> <li>AI 修改中是否遵守專案邊界</li> <li>AI 修改後是否主動審查風險</li> <li>AI 是否能從歷史錯誤中學習</li> <li>團隊是否有統一的 Agent 使用規範</li> </ul> <p><code>Compound Engineering Plugin</code> 這類專案的意義就在這裡。它把 AI 編程從個人技巧，往團隊可複用流程推進了一步。</p> <h2 id="參考">參考 </h2><ul> <li><a class="link" href="https://github.com/EveryInc/compound-engineering-plugin" target="_blank" rel="noopener" >EveryInc/compound-engineering-plugin</a></li> </ul> <h2 id="最後一句">最後一句 </h2><p><code>Compound Engineering Plugin</code> 值得關注的地方，不是多一個 AI 編程命令，而是把 AI 編程組織成可循環改進的工程流程。</p> <p>當 AI Agent 開始參與真實專案，計劃、執行、評審和經驗沉澱會比單次生成程式碼更重要。</p>