自動化程式設計在特定場景下、由合適的人來使用時，能大幅加快軟體撰寫的速度。以我的經驗來看，其產出還達不到最頂尖手寫程式在結構品質與複雜度掌控上的水準。不過，並非所有軟體都寫得那麼出色，我的感覺是，只要妥善運用，自動化程式設計多數時候都能超越一般水準的手寫程式碼品質。

然而，用 AI 來撰寫新軟體時，品質與時間之間確實存在取捨。在我做過的某些專案裡，這種取捨非常極端——原本可能要花好幾個月才能完成的專案，幾週內就做完了。不過，也有些領域中，LLM 帶來的是純粹更強大的自動化方式，完全不需要在品質上妥協，其中一個領域就是軟體的 QA 與測試。

傳統上，軟體測試是靠測試套件來進行，由局部範圍的測試與整合測試所組成（以 Redis 為例，一種是測試 SET foo 10 之後 GET foo 是否會回傳 => 10，另一種則是測試在這種情況下的複寫機制是否正常）。除此之外，還有通常以手動執行的 QA 流程，用來補足可執行測試套件中遺漏的部分。眾所皆知，涵蓋所有程式碼行數，並不代表涵蓋了所有可能的狀態。再者，整合測試在結構上本就困難：存在許多時序問題、環境設定，以及某些只能靠肉眼檢視、無法自動檢查的品質輸出，使得大量測試機會因為時間或後勤上的限制而始終沒有被好好利用。

LLM 在現有測試方法之上，提供了一種全新的 QA 方式。想法是建立一個 markdown 檔案，要求 AI 代理人以 QA 工程師的身分，針對新版本執行一系列手動測試。舉例來說，以 DwarfStar（一個用於開放權重 LLM 的推論引擎）為例，我的做法如下。在這個 markdown 檔案中，會要求代理人先檢視在已發布版本之上新增了哪些 commit。接著，再告訴模型需要執行的一系列項目，例如：

• 確認分散式推論在 MacBook A 和 MacBook B 之間能正常運作，確保輸出一致，且在兩台機器上的所有 GGUF 檔案都能正常推論……
• 確保這個版本沒有出現速度衰退。

諸如此類。值得注意的是，在速度衰退的檢測部分，我不需要告訴代理人先前預期的速度是多少，因為這是一個會隨著新版本與新最佳化不斷變動的目標。同樣地，分散式推論的整合測試也不需要太多指令，在檔案開頭只要提供 SSH 連線位置、要使用的金鑰、路徑等資訊就夠了。

會要求代理人根據新增的 commit 來檢視這一長串 QA 項目——特別是針對這些異動——先檢視變更內容，並判斷可能影響了哪些部分，讓這次 QA 流程能更專注於找出特定的回歸問題。

以 Redis Arrays 為例，我也用了類似的方法，要求代理人建構一個大型的、基於陣列的 Redis 應用程式，架設具備複寫與持久化機制的正式環境，模擬多位使用者連續數天的使用情境，並檢查是否有任何異常。

採用這些方法的測試，甚至可以觸及軟體品質中更偏心理層面的部分，要求代理人找出所有可能讓人感到意外、文件說明不足，或整體上從使用者角度來看顯得粗糙的新功能。這些都是過去需要手動執行、而多數時候幾乎都會被跳過的事項。

我有種感覺，自動化 QA 的引入或許能拉高軟體新版本的品質門檻，並在某種程度上彌補因高速使用自動化程式設計而產生的程式碼品質下滑。