建構像 RAG 遷移這樣複雜的多階段雲端專案，編排和程式碼編寫同樣重要。您需要管理基礎架構（ Terraform ）、後端服務（ Python ）、前端 UI（ Next.js ）、資料管道（ BigQuery / AlloyDB ）和文件——所有這些都必須保持一致的技術策略。
標準的 IDE 程式碼補全功能對於程式碼片段來說非常實用，但它們缺乏此類工程所需的系統級上下文。為了建立這個參考架構，我並不是只使用 AI 來編寫程式碼，而是使用 AI 來協調整個專案。
在這篇最後的文章中（請參閱前文第 1 部分和第 2 部分），我將分享使用Gemini CLI和Conductor 擴充功能來編排此遷移的幕後故事。
本文將介紹：
-
如何利用終端優先的AI助理進行系統級工程
-
如何使用Conductor 擴充實作規格驅動開發
-
如何使用 AI 驅動的測試驅動開發 (TDD) 實現可靠的程式碼生成
-
如何使用「人機協作」模式與人工智慧代理協作
在深入探討工作流程之前，讓我們先簡單討論為什麼編排是 AI 輔助開發的下一個合乎邏輯的步驟。
開發者體驗
讓我們一步一步地了解我的開發過程。完整的規格、計劃和實作邏輯都可以在rag-migration程式碼庫的conductor目錄中找到。
使用 Conductor 進行規範驅動開發
Conductor 擴充是我工作流程的核心。它是基於規範驅動開發 (spec-driven development)的原則建構。我們不會直接編寫程式碼，而是先在 Markdown 文件中定義「真理來源」。
-
產品定義（
product.md）：我們正在建構什麼？ -
技術堆疊（
tech-stack.md）：我們正在使用哪些工具？ -
曲目註冊表（
tracks.md）：主要里程碑有哪些？ -
實施計劃（每個方向的
plan.md）：具體步驟是什麼？ -
工作流程（
workflow.md）：我們如何建立解決方案？
透過將這些文件放在程式碼庫中，AI 代理程式（Gemini CLI）始終能夠獲得做出明智決策所需的高階上下文資訊。此外，與團隊共享這些文件也是一個很好的做法，這樣每個人（包括 AI 代理）都能對專案的方向達成共識。
導體初始化
專案初始化的第一步是建立產品定義和技術堆疊檔案。這可以透過執行以下命令來完成：
/conductor:setupGemini CLI 會詢問您一系列問題，以幫助您定義專案，其中包括：
-
你們的產品名稱是？
-
主要用戶是誰？
-
你們使用的技術棧是什麼？
-
您希望實現的主要功能有哪些？
-
你想採用什麼樣的工作流程？
然後它將在conductor目錄中建立初始專案結構，包括product.md和tech-stack.md檔案。
賽道的生命週期
本專案中的每個主要功能都以「軌道」的形式實現。典型的軌道生命週期包括：
- 軌道初始化（
/conductor:newTrack）：
-
代理商會建立一個
spec.md文件，用於描述賽道的目標。 -
該代理程式會映射現有程式碼庫並驗證假設。
-
代理程式會建立一個
plan.md文件，其中描述了實現目標所需的步驟
- 追蹤執行（
/conductor:implement）：
- 代理程式使用「計劃 -> 執行 -> 驗證」循環來迭代執行任務。
- 賽道完成情況：
-
代理人核實追蹤過程中所做的更改。
-
代理程式會徵求使用者對實作方式的回饋意見。
- 曲目存檔：
- 音軌完成後，Gemini CLI 會將該音軌歸檔到
conductor/archive目錄中。
例如，當我啟動初始嵌入軌道時，我使用以下方式初始化它：
/conductor:newTrackGemini CLI 會研究程式碼庫，提出澄清問題，並建立spec.md和plan.md檔。只有在我審核並批准之後，才會開始實際的實施工作。
Terraform 用於基礎架構即程式碼
我的product.md檔案指示 Gemini CLI 為專案期間建立的所有資源編寫 Terraform 程式碼。這種方式非常有效，因為所有資源都由原始碼統一管理，而且需要時可以輕鬆啟動新環境。
您可以在infra目錄中看到第一個軌道中使用的所有 Terraform 檔案和基礎設施腳本。
此外，在專案建立過程中，我指示 Gemini CLI 始終在執行terraform apply之前執行terraform plan 。將此資訊保存在workflow.md檔案中，可確保所有專案分支都採用此方法。
使用人工智慧代理進行測試驅動開發
這個工作流程最強大的方面之一是人工智慧驅動的測試驅動開發（TDD）。我並沒有直接讓代理商“編寫程式碼”，而是讓它遵循一套嚴格的流程：
-
編寫失敗的測試：代理程式在新測試檔案中定義預期行為
-
紅色階段：執行測試並確認測試失敗。
-
綠色階段：它只編寫通過測試所需的最少程式碼
-
重構：它重構實作程式碼和測試程式碼，以提高清晰度、消除重複程式碼並提高效能，同時不改變外部行為。
-
驗證覆蓋率：驗證測試覆蓋率是否符合專案要求（目標：新程式碼覆蓋率 >80%）。
-
提交程式碼變更：代理程式提交與任務相關的程式碼變更。
這確保了AI生成的程式碼不僅“語法正確”，而且在功能上也符合我的要求。此工作流程在workflow.md檔案中進行了描述。
檢查點和品質關卡
在每個階段結束時，Gemini CLI 都會執行一個「檢查點」協定。這包括：
-
自動驗證：執行完整的測試套件。
-
手動驗證：向使用者提供逐步說明，以驗證變更。
-
可審計記錄：使用
git notes將驗證報告附加到 git 提交，並使用新的提交雜湊值更新plan.md
Conductor 提交以示範檢查點協定。
有效的人機交互
為了實現人工智慧代理與人類開發之間的有效協同，我主要依賴以下解決方案：
這種方法提供了安全的保障，讓我可以在人工智慧處理這個專案的同時，投入其他專案。由於及時的通知，我總是能快速返回之前的專案。此外，Conductor 的檢查點機制讓我始終可以撤銷不必要的更改，或從已知的有效狀態重新開始。
我還使用Antigravity來優化產生的程式碼和文件。它對於修改或重構 Gemini CLI 產生的程式碼尤其有用。
代幣使用
在整個專案過程中，我使用了多種型號的閃光燈（Gemini 3 Pro、Gemini 3 Flash 和 Gemini 2.5 Flash Lite）。總代幣消耗量為：
-
輸入標記數：約 1900 萬
-
快取的輸入標記：約 6,600 萬
-
輸出令牌數：約 40 萬
請注意快取的輸入令牌數量很高，這會顯著影響支出。 Vertex AI 令牌的總成本約為 30 美元。對於幾天的 AI 輔助工作來說，這還不錯。
更多詳情請查看價格頁面，並請注意實際里程可能有所不同。
概括
軟體工程正在從編寫程式碼演變為編排智能體工作流程。透過使用 Gemini CLI 等工具和 Conductor 等框架，您可以擴大作為架構師的影響力，同時確保實現的一致性和高品質。
準備好建立自己的人工智慧輔助開發專案了嗎？
感謝閱讀
如果您覺得這篇文章對您有幫助，請長按👏按鈕，並為這篇文章按讚50次。這將有助於其他人看到這篇文章。您也可以在社群媒體上分享給您的朋友。
我一直都渴望分享我的經驗或與同行開發者和人工智慧愛好者交流，所以歡迎在LinkedIn 、 X或Bluesky上關注我。
原文出處：https://dev.to/googleai/how-i-used-gemini-cli-to-orchestrate-a-complex-rag-migration-43ga
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
