Mentoring the Machine：AI 代理時代的軟體開發新範式

這個影片由 Augment Code 的技術人員 Eric Hou 分享，深入探討了如何透過 AI 代理來徹底改變軟體開發的工作流程。雖然標題「Mentoring the Machine」可能不太直觀，但內容相當豐富，特別是針對團隊如何有效運用 AI 進行協作開發的議題。

工程師的日常挑戰與痛點

Eric 開場就描述了一個典型的「糟糕的星期二」情境，這個場景相信許多工程師都深有感觸：

設計系統元件延遲：產品經理催促設計系統元件的進度，需要花費大量時間研究現有程式碼庫，理解架構模式，然後撰寫技術規格文件（RFC）。

測試環境緊急狀況：正當專注於開發時，測試環境突然出現問題，需要立即切換注意力去排查問題，可能涉及查看大量日誌檔案和執行 Git 二分查找來定位問題。

指導新進工程師：同時還需要回答新進工程師的各種問題，協助他們理解專案架構和開發流程。

這些情境揭露了現代軟體開發的核心痛點：

• 工作中斷成本高昂：研究顯示，工程師被中斷後需要約 23 分鐘才能重新進入專注狀態
• 維護工作占比過高：工程師有 2/3 的時間花在維護現有系統，而非開發新功能
• 經濟損失巨大：每年因為情境切換而造成的損失高達約 3,000 億美元

這些數據清楚地說明了為什麼我們需要新的工作模式來提升開發效率。

AI 代理如何轉變工作流程：以 Eric 的「星期二」為例

Eric 接著展示了同樣的星期二，但這次有了 AI 代理的協助，工作流程變得截然不同：

設計系統元件開發的轉變

傳統方式：工程師需要手動探索龐大的程式碼庫，花費數小時理解現有模式，然後手工撰寫 RFC 文件。

AI 代理協助後：AI 代理能夠快速掃描整個程式碼庫，識別相關的設計模式和架構決策，自動生成初始的 RFC 草稿。工程師只需要進行最終的審核和調整。

測試環境問題處理的平行化

傳統方式：當緊急問題發生時，工程師必須停下手邊的工作，切換到問題排查模式，一步步檢查日誌和執行除錯。

AI 代理協助後：可以同時啟動多個 AI 代理：

• 一個代理專門分析伺服器日誌，快速識別異常模式
• 另一個代理執行 Git 二分查找，定位可能的問題提交
• 第三個代理檢查相關的設定檔案和環境變數

這種平行化處理大幅縮短了問題診斷時間。

新進工程師指導的自動化

傳統方式：資深工程師需要經常中斷工作來回答問題，而且相同的問題可能被重複詢問。

AI 代理協助後：Augment 的 Slack 機器人能夠：

• 根據新進工程師的具體問題提供個人化的回答
• 參考專案的實際程式碼和文件來給出精確建議
• 學習團隊的開發慣例和最佳實務

驚人的效率成果

Eric 強調，原本需要三週才能完成的工程工作，在 AI 代理的協助下，竟然在半天內就完成了。這不是誇大其詞，而是透過合理的任務分工和平行處理達成的實際成果。

指導機器：AI 作為「永久的初級工程師」

Eric 提出了一個很有趣的類比：AI 就像是一個永久的初級工程師。這個比較幫助我們更好地理解如何與 AI 協作。

AI 與初級工程師的相似之處

缺乏背景資訊：初級工程師剛加入團隊時，不了解專案的歷史脈絡、設計決策的原因，以及業務需求的細節。AI 也是如此，它需要被提供足夠的上下文資訊才能做出正確的判斷。

需要組織上下文：初級工程師需要學習團隊的工作流程、編碼規範、審查標準等。AI 同樣需要這些組織層面的知識來產生符合團隊期望的輸出。

缺乏系統工作經驗：初級工程師可能不了解複雜系統的運作方式、常見的陷阱、以及最佳實務。AI 也需要透過學習來累積這些實務經驗。

AI 與初級工程師的關鍵差異

處理速度的差異：這是最明顯的差異。AI 能夠在幾秒鐘內處理大量資訊，而人類需要數小時甚至數天。

記憶特性的差異：這是很重要的一點。初級工程師雖然學習較慢，但學會的知識會持續累積。而 AI 可能會「忘記」先前對話中的重要資訊，每次互動都需要重新建立上下文。

人類工程師的角色轉變

在這個新模式下，人類工程師的角色從「執行者」轉變為「永久的技術主管」：

• 設定方向：明確定義任務目標和成功標準
• 提供上下文：確保 AI 了解專案背景和業務需求
• 質量把關：審核 AI 的輸出，確保符合技術和業務標準
• 知識傳承：將團隊的經驗和最佳實務傳授給 AI

這種角色轉變讓資深工程師能夠專注於更高層次的技術決策和架構設計。

組織層級的挑戰與解決方案：知識基礎設施

個人層面的 AI 協作只是開始，真正的挑戰在於如何讓整個組織都能有效運用 AI。Eric 提出了建立「知識基礎設施」的三個步驟：

第一步：知識收集（Knowledge Collection）

探索現有知識庫：許多組織已經有大量的文件、程式碼註解、設計文件等，但這些知識可能分散在不同的系統中。需要系統性地整理和索引這些資源。

填補關鍵缺口：識別哪些重要的知識沒有被記錄下來。例如：

• 為什麼選擇某個技術架構？
• 過去遇到的問題和解決方案
• 團隊的開發慣例和決策流程

整合數據來源：將分散在 Slack、Jira、Confluence、Git 提交訊息等不同地方的知識整合起來，形成統一的知識庫。

第二步：熟悉工具（Tool Familiarity）

團隊熟悉 AI 工具：這不只是學會使用工具，更重要的是理解如何有效地與 AI 互動：

• 如何撰寫清晰的提示（prompt）
• 如何提供適當的上下文資訊
• 如何驗證和改進 AI 的輸出

AI 學習團隊模式：讓 AI 了解團隊的工作模式：

• 程式碼風格和架構偏好
• 測試策略和品質標準
• 溝通方式和決策流程

這是一個雙向的學習過程，團隊和 AI 都需要適應彼此。

第三步：深入應用（Deep Application）

擴展成功模式：當某個團隊找到有效的 AI 協作模式後，將這些經驗推廣到其他團隊：

• 建立最佳實務文件
• 提供培訓和工作坊
• 建立內部分享機制

委託複雜任務：隨著 AI 對組織的了解加深，可以委託更複雜的任務：

• 跨系統的影響分析
• 架構重構建議
• 自動化測試生成

跨團隊分享成功經驗：建立組織層面的學習機制，讓不同團隊的成功經驗能夠相互借鑑。

未來展望：平行探索與軟體開發的科學化

Eric 對未來軟體開發模式的展望特別令人興奮：

從線性開發轉向平行探索

傳統線性開發：需求分析 → 設計 → 實作 → 測試 → 部署，每個階段依序進行。

平行探索模式：多個 AI 代理可以同時：

• 探索不同的技術方案
• 進行概念驗證（POC）
• 分析各方案的優缺點
• 預測實作的複雜度和風險

快速原型開發與迭代

AI 的高速處理能力讓我們能夠：

• 快速建立原型：在幾分鐘內生成可運行的概念驗證
• 快速迭代：根據回饋快速調整設計和實作
• 快速測試：自動生成測試案例並執行驗證

決策模式的轉變

從追溯式轉為前瞻性：

• 追溯式決策：「為什麼這個設計不好？」「這個 bug 是怎麼產生的？」
• 前瞻性決策：「如果選擇方案 A，可能的風險是什麼？」「這個架構在未來六個月會面臨什麼挑戰？」

軟體開發的科學化

Eric 認為這種轉變讓軟體開發變得更像科學研究：

• 假設驅動：提出技術假設，然後快速驗證
• 實驗導向：透過快速實驗來驗證想法的可行性
• 數據支持：基於實際數據和測試結果來做決策
• 可重現性：建立標準化的流程和工具鏈

這種科學化的方法讓軟體開發從「手工藝」升級為「工程學科」。

個人觀點與總結

對於這個主題，我有幾點個人觀察：

關於主題命名

「Mentoring the Machine」這個標題確實不太直觀，容易讓人不清楚內容要討論什麼。如果改為「AI 代理時代的軟體開發」或「如何有效指導 AI 進行程式開發」可能會更清楚地傳達主題。

內容的豐富性和實用性

儘管標題有些模糊，但內容相當豐富且實用。Eric 不只是展示了 AI 工具的強大功能，更重要的是提供了系統性的思考框架：

• 個人層面：如何改變工作方式來善用 AI
• 團隊層面：如何建立有效的協作模式
• 組織層面：如何建設知識基礎設施

對團隊 AI coding 的見解

這個分享特別有價值的地方在於，它不只關注個人如何使用 AI 工具，而是深入探討了團隊層面的 AI 協作。這包括：

• 如何標準化 AI 的使用方式
• 如何確保 AI 的輸出符合團隊標準
• 如何讓新進成員快速學會與 AI 協作
• 如何建立組織的 AI 知識庫

實踐建議

基於這個分享，我認為團隊可以從以下幾個方面開始：

1. 建立 AI 使用規範：制定清楚的指導原則，說明何時使用 AI、如何驗證輸出
2. 文件化團隊知識：將隱性的團隊知識明確記錄下來，讓 AI 能夠學習
3. 培養 AI 協作技能：投資時間讓團隊成員學會有效的 AI 互動方式
4. 建立回饋機制：定期檢討和改進 AI 協作的效果

這個分享為我們描繪了一個令人興奮的未來：AI 不會取代工程師，而是成為我們最得力的助手。關鍵在於我們如何學會「指導機器」，讓 AI 成為團隊中有價值的一員。

支持創作

如果這篇文章對您有幫助，歡迎透過 贊助連結 支持我持續創作優質內容。您的支持是我前進的動力！

圖片來源：AI 產生