AI驅動的軟件工程（下）：AI輔助的質檢與交付

📚 系列文章導航
AI驅動的軟件工程（上）：人機協同的設計與建模
AI驅動的軟件工程（中）：文檔驅動的編碼與執行
AI驅動的軟件工程（下）：AI輔助的質檢與交付

大家好，我是阿威。

在系列的前兩篇文章中，我們走過了一段激動人心的旅程。首先，我們作為“架構師”，通過結構化的三階段設計流程，引導AI將一個模糊的想法，轉化為了一套完整的工程藍圖。接著，我們化身“項目經理”，通過AIDC這套文檔驅動的開發方法論，成功地讓AI像一個遵守紀律的工程師一樣，將藍圖一行行地變成了真實的代碼。

至此，我們的項目代碼庫已經初具規模，git log里充滿了AI自己生成的、格式規范的提交記錄。自動化檢查工具也告訴我們，代碼風格良好，沒有低級的語法錯誤。

一個尖銳的問題擺在了面前：代碼存在，就等于項目完工了嗎？

答案顯然是否定的。靜態檢查無法保證業務邏輯的正確性。單元測試（即使有）也難以覆蓋所有集成場景。代碼在AI的“模擬環境”（它的上下文中）里是正確的，但在我這臺真實的、有著復雜環境依賴的機器上，能順利運行嗎？

這就是我們收官之篇要解決的核心問題：如何對一個主要由AI構建的項目，進行最終的、可靠的“終局質檢”？

事實證明，直接讓人類從頭到尾審查AI的全部代碼，是極其低效且不現實的。我們必須設計一套全新的、依然以AI為核心執行者，但由人類掌握最終控制權的協同工作流。在這個階段，我們的角色將再次發生轉變，上演一出人機協同的“終局之戰”。

終局之戰中的角色再定位

在編碼完成后的這個新階段，人與AI的角色分工需要重新定義，以確保最高的效率和絕對的安全。

AI的角色：轉型為分析師、建議者和配對伙伴。它的核心任務，是通過靜態分析深度掃描代碼庫，找出邏輯上、結構上的潛在問題，并提出精準的代碼修復建議。最關鍵的一點是：在這個階段，AI不直接操作我的執行環境。它不運行任何pip install，也不啟動任何服務。
我的角色：成為執行者、驗證者和最終決策者。我負責執行所有AI建議的終端命令，在我的本地或測試環境中部署服務，親眼驗證服務的狀態，并對AI提出的每一處代碼變更進行審查和批準。我，是接觸真實環境的唯一一人。

這種角色劃分，完美地利用了雙方的優勢：AI擁有無與倫比的分析速度和廣度，能快速發現隱藏在代碼角落里的問題；而人類則掌握著對真實環境的最終控制權和驗證能力，確保了項目的安全性和最終交付質量。

這套后協同工作流，我將其劃分為四個主要階段，它將帶領我們從靜態的代碼，走向一個經過完整驗證、可隨時交付的“準產品”。

四階段質檢：從靜態分析到運行時驗證

階段一：靜態分析與代碼完整性檢查 (AI主導)

這是我們質檢流程的第一步，我稱之為對AI代碼的“全面體檢”。目標是在不運行項目任何一行代碼的前提下，通過AI強大的靜態分析能力，識別出所有潛在的代碼級問題。

我會給AI下達一個高級指令：

“現在，請對整個AgentWeaver代碼庫進行一次完整的靜態分析和完整性檢查。你需要完成以下任務，并最終匯總成一個TODO任務列表：

代碼調用可達性分析：檢查所有函數和方法的調用關系，找出所有參數不匹配、方法未實現、模塊導入錯誤等硬傷。
依賴與配置分析：檢查requirements.txt，分析是否存在版本沖突或不兼容問題。檢查所有配置文件，確保其完整性和一致性。
代碼規范復查：再次模擬運行black和ruff，找出任何在開發過程中可能遺漏的格式問題。”

AI接到指令后，會像一個資深的靜態代碼分析工具一樣，開始它的工作。

在可達性分析中，它可能會發現一個API路由函數調用了一個需要傳入3個參數的服務層方法，但只傳入了2個。或者，一個類繼承了某個抽象基類，卻沒有實現其中一個必須實現的方法。這些都是自動化Linter很難發現的、深層次的邏輯錯誤。
在依賴分析中，它可能會發現requirements.txt中某個庫的版本過低，與另一個庫產生了不兼容。或者提醒我.env.template中定義了一個數據庫密碼，但在任何配置文件中都未被使用。
在規范復查后，它會把所有分析產出的問題，匯總成一個結構化的、清晰可執行的TODO任務列表。

例如：

[ ] [Bug] api/routes.py:56: create_agent函數調用services.agent.create時缺少user_id參數。
[ ] [Refactor] core/workflow.py: WorkflowEngine類未實現抽象基類Runnable的get_status方法。
[ ] [Chore] requirements.txt: fastapi版本(0.95.0)與pydantic版本(2.1.0)存在已知的兼容性問題，建議將fastapi升級到0.103.0以上。
[ ] [Style] utils/parser.py: 文件末尾缺少空行。

這份清單，就是我們進入下一階段的“作戰地圖”。

階段二：協同代碼修復 (人機結對)

這個階段，我們進入了一種高效的“人機結對編程”模式。我們的目標，是根據上一階段生成的TODO列表，逐一修復所有問題。

這個循環非常簡單、高效：

AI選擇任務：AI從TODO列表中選擇優先級最高的任務，并標記為“進行中”。
AI生成修復代碼：針對該問題，AI使用edit_file工具，生成一個最小化的、精確的代碼變更。它不會返回整個文件，而只會提供需要修改的那幾行以及足夠的上下文。
我審查并批準：我作為人類開發者，審查AI提出的代碼變更。確認這個修改是正確的、無害的之后，我批準應用該變更。
我本地驗證：對于一些風格問題，我會在本地運行black .和ruff --fix來確保修復后代碼的規范性。
循環：AI將已完成的任務在TODO列表中標記為“已完成”，然后繼續處理下一個任務。

這個過程會一直持續，直到TODO列表中的所有問題都被清空。這種模式避免了我親自去定位和修改這些瑣碎但重要的問題，極大地提升了修復效率。

階段三：運行時環境驗證 (人類主導, AI輔助)

當所有靜態問題都被修復后，代碼在“理論上”已經變得更加健壯。但理論必須接受實踐的檢驗。現在，是時候“點火”了。

在這個階段，控制權完全轉移到我的手中，AI的角色變成了我的“遠程技術支持”。

環境設置 (AI指導，我執行)：
- AI會提供清晰、分步的環境設置指令，就像一份部署手冊。例如：“請首先創建一個Python 3.10的虛擬環境。然后，請執行pip install -r requirements.txt來安裝所有依賴。”
- 我，是那個在終端里按下回車鍵的人。我會嚴格按照它的指令執行。
錯誤處理與調試 (我報告，AI分析)：
- 這是最能體現人機協作價值的環節。在執行pip install時，我可能會遇到某個依賴包（比如bcrypt）因為缺少系統庫而編譯失敗。或者在啟動應用時，我看到一個數據庫連接超時的報錯。
- 我的任務，是將終端中完整的、未經刪改的錯誤日志，原封不動地反饋給AI。
- AI的任務，是分析這段通常很長、充滿技術術語的錯誤日志，并定位問題的根源。它可能會告訴我：“這個gcc編譯錯誤表明你的系統中缺少C語言編譯器和Python的開發頭文件。在Debian/Ubuntu系統上，請執行sudo apt-get install build-essential python3-dev來解決。”或者“這個數據庫連接錯誤，請檢查你的.env文件中的DB_HOST和DB_PORT是否正確配置，并確認你的數據庫Docker容器正在運行中。”
- AI提供具體的解決方案，甚至修復代碼，我來執行和驗證。這個過程極大地縮短了環境問題的排查時間。
服務初始化與健康檢查 (AI指導，我驗證)：
- 當環境配置完成，應用成功啟動后，AI會繼續指導我進行數據初始化等操作。例如：“請執行python -m db_models.manage init-db來初始化數據庫表結構。”
- 我會執行命令，并將結果反饋給它。最后，AI會讓我調用應用的健康檢查API（如/health），并讓我將返回的JSON結果告訴它，以確認所有核心服務（數據庫、緩存、AI模型服務等）都已正常連接。

當健康檢查通過時，我們就可以滿懷信心地說：這個由AI編寫的項目，在真實的運行環境中，活了過來。

階段四：最終化與文檔更新 (AI主導)

在所有代碼修復和環境驗證都完成后，我們進入最后的收尾工作。

代碼提交 (AI生成信息，我執行)：
- AI會基于本次質檢的所有工作，生成一條清晰、規范、信息量豐富的Git提交信息。例如：fix(all): 完成交付前完整性檢查與運行時驗證，并在詳細描述中列出修復的主要問題。
- 我來執行git add .和git commit，完成這最后一次、也是最重要的一次提交。
文檔更新 (AI的最后一項任務)：
- AI負責更新項目的“外部記憶”，以反映項目的最終狀態。它會自動修改README.md，更新其中的安裝和運行指南；它會更新開發日志.md，記錄本次質檢的完成；它還會將項目開發計劃.md中的所有任務狀態都更新為“已交付”。
- 我最后一次審查這些文檔的準確性和完整性。