Logo
Published on

Test-Driven Development：駕馭 AI Agent 時代的軟體設計心智模型

文章整理自 YouTube 影片「This Mental Model Changed How I Design Software FOREVER」的相關內容

影片深入探討了在 AI Agent 時代，軟體工程師如何透過 TDD（測試驅動開發）的心智模型，有效地與 AI 協作並保持人類工程師的核心價值。以下是影片的重點精華分享

當 AI Agent 接管程式碼：人機協作時代的軟體設計新思維

如影片中所提及的，在軟體開發領域，人工智慧（AI）的浪潮正以前所未有的速度席捲而來，特別是「AI Agent」的崛起，為產業帶來了翻天覆地的變革。這些能夠自主規劃、執行任務，甚至使用工具的 AI 系統，正改變我們對「程式碼撰寫」的認知。

然而，當 AI 代理人能夠以驚人的效率產生程式碼時，人類工程師的價值究竟體現在何處？我們真正的貢獻，並非在於敲打鍵盤的速度，而是在於我們所具備的深厚工程技能與設計智慧。這引出了一個關鍵問題：在 AI Agent 盛行的時代，什麼樣的軟體設計心智模型，才能引導我們有效地駕馭這股力量？

面對這種「程式碼精靈」（coding genie）——正如 Kent Beck 所形容的那樣，它們的解決方案有時看似變幻莫測——我們需要一個強健的框架。這個框架不僅能讓我們與 AI 協同工作，更能確保我們所創造的軟體既高品質又具備可維護性

這不僅僅是關於採用新工具，更是關於重新定義我們作為軟體工程師的核心職能

駕馭精靈：透過精準規範引導 AI 協作者

在與 AI Agent 協作的過程中，最顯著的轉變之一，是我們從「程式碼撰寫者」轉變為「行為定義者」。這一切從「驗收測試驅動開發」（Acceptance Test-Driven Development, ATDD）的核心理念開始。與 AI 工具協作時，我們必須清晰地定義程式碼應該做什麼，而自動化驗收測試正是實現此目標的有效途徑

這意味著，我們需要以自然語言，更詳細地描述功能需求，其精確度可能超越以往手動編碼時的需求。有趣的是，這些 AI 工具本身也能協助我們撰寫這些規範

當投入足夠的精力，以合理的細節來指定程式碼行為後，實際的程式碼撰寫工作便會落入生成式 AI 工具的能力範圍內。它們通常能產生具備良好命名約定且符合測試與規範語彙的可用程式碼。有了這些測試作為回歸防護網，我們可以循序漸進地擴展功能

這強調了迭代式工作的重要性：一次專注於一個新的測試，逐步構建出更宏大的解決方案。這種透過精準規範來引導 AI 的過程，實質上是將人類的意圖，轉化為 AI 可理解且可執行的指令，確保產出的程式碼符合預期

設計品質：人類工程師的永恆職責

即便程式碼的大部分是由 AI 產生，程式碼品質依然舉足輕重。如果程式碼能夠清晰地傳達其意圖，不僅方便未來的程式設計師理解與維護，對於 AI 工具本身後續的協作與改進也大有裨益。因此，在每個新測試通過之後，我們仍需審視程式碼，判斷其設計是否足夠優良

為了確保 AI 在一開始就能產出相對良好的設計，我們可以預先設置額外的「防護措施」。Llewellyn Falco 提供了一個絕佳範例，他會在專案中包含一個標準提示詞，指示 AI 遵循特定的程式碼原則：「我們偏好簡單、清晰、可維護的解決方案，而非巧妙或複雜的。可讀性與可維護性是首要考量。透過命名和程式碼本身來實現自我文件化。使用小型函式，並在類別與函式中遵循單一職責原則（Single Responsibility Principle）」

若在審視程式碼後，我們仍認為設計有改進空間，那麼此時最大的優勢便是可以要求生成式 AI 工具「再試一次」。這與傳統的「重構」（refactoring）有所不同。重構通常涉及基於語法樹的安全轉換，而 AI 則更像是根據既定約束條件，從頭產生一套新的設計

雖然部分程式碼可能保持不變，但本質上它並未對現有程式碼結構進行安全轉換。若需要更精確的、基於語法樹的重構，我們目前仍需借助整合開發環境（IDE）中的工具，或親自進行這些設計改進。然而，未來 AI 具備執行這些確定性工具的能力，指日可待

駕馭複雜性：工程師的核心使命

無論工具如何演進，人類工程師的核心職責始終如一：管理軟體的複雜性。我們必須致力於使程式碼易於理解和操作，避免不必要的複雜。這要求我們尋找良好的抽象（abstractions）、模組化（modularize）程式碼的機會、劃分功能（partition functionality），並分離關注點（separate concerns）

正如 Dave Farley 在他的著作《現代軟體工程》（Modern Software Engineering）中所述，管理軟體複雜性是我們軟體工程師最根本的職責之一

另一個同樣根本的職責是持續優化與學習。這意味著我們不斷地學習所要解決的問題本身，以及我們所使用的媒介（即程式碼）的優勢與局限性。當我們與 AI Agent 協作時，我們依然是進行工程設計的主導者。這是一個基於迭代、經驗性的過程，逐步趨近最終解決方案

此時，限制我們進度的關鍵因素，不再是 AI 快速產生有效語法的程式碼的能力，而是我們學習問題的速度，以及我們管理複雜性的能力。換言之，真正驅動進步的是人類的洞察力與設計智慧

「迭代式工程」心智模型：TDD 與 AI 時代的設計基石

回顧上述的協作模式，不難發現一個強大的心智模型正在浮現，它與「測試驅動開發」（Test-Driven Development, TDD）有著驚人的相似之處。這絕非巧合。對許多軟體工程師而言，TDD 的引入才是設計思維上最根本的轉變，而非僅僅是學會使用 AI Agent

這個「迭代式工程」心智模型可以這樣概括

  • 從使用者需求出發： 始終將最終用戶的痛點與需求置於核心
  • 問題拆解與分塊： 將大問題拆解為更小、可獨立解決的功能塊
  • 詳細行為與規範： 選擇一個功能塊，詳細指定其預期行為，並輔以程式碼標準（例如 Llewellyn Falco 的原則）
  • AI 程式碼產生： 指導 AI 工具撰寫符合這些規範的程式碼
  • 審查與改進： 仔細審查 AI 產生的程式碼，若設計有改進空間，則要求 AI 重新嘗試
  • 迭代推進： 當前功能塊完善後，選擇下一個功能塊，重複上述步驟

在整個過程中，還有一個額外但至關重要的因素，尤其是在與 AI Agent 協作時：你需要持續優化 AI 工具的「上下文」（context window），使其能夠完全專注於當前的任務。這恰好與 TDD 過程中管理認知負荷（cognitive load）的理念不謀而合——透過一次只專注於設計的一個特定方面，減少需要同時處理的資訊量，從而降低壓力，提高效率

TDD 作為一種經驗性的工程方法，提供了一種系統化的方式來進行軟體設計。它迫使我們專注，將設計問題分解成可管理的小塊，從而降低人類的認知負荷，同時也為 AI 代理人提供了清晰的、受限的任務範圍。這種心智模型不僅能讓我們在 AI 時代保持效率，更能讓我們的工程實踐變得更為精煉

超越程式碼：軟體設計的永恆真理

最終，無論技術如何日新月異，測試驅動開發所蘊含的，其實是軟體設計的永恆真理：一種經驗性的工程方法，旨在系統性地管理複雜性並促進持續學習。如果你已經具備紮實的軟體工程技能，熟悉這些原則，那麼 AI Agent 將成為你能力的放大器，讓你更快、更輕鬆地實現卓越的設計

然而，如果缺乏良好的軟體設計與工程心智模型， AI Agent 很可能只會加速混亂的產生。你將無法有效地將問題分解為可管理的小塊，也無法妥善處理複雜性。那些關於 AI Agent 「失敗」的案例，往往正是源於未能建立模組化、低耦合的程式碼，最終被複雜性的高牆所阻擋

因此，真正關鍵的並非學會如何使用 AI，而是掌握軟體工程的本質。學習測試驅動開發，是為駕馭 AI Agent 時代的軟體工程打下堅實基礎的重要一步。它不僅是一種開發實踐，更是一種深植於心、指導我們在複雜世界中航行的設計哲學

在 AI 不斷演進的今天，人類工程師的智慧與設計能力，比任何時候都更顯珍貴

支持創作

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

圖片來源：AI 產生