15個月構建開源Azure模擬器的歷程：AI助力與人力協作

15個月前，當我開始着手開發Topaz時（我於2025年4月中旬提交了第一次提交），我完全無法預料到軟件工程的格局在撰寫本文時會如何改變。我想總結整個旅程，並描述AI如何改變了我設計、開發和測試Topaz的方式——這是一個我一直在開源構建的本地Azure模擬器。

2025年4月——熱身階段

我決定將Topaz作為一個挑戰來開始。那時我正深度參與一個基於AWS的項目，在該項目中，我能夠模擬底層基礎設施，不是通過自己編寫模擬代碼——我發現了LocalStack並迅速愛上了它。對AWS基礎設施的本地模擬幫助我快速測試變更，只需極少的努力，最重要的是，無需基礎架構團隊的參與。我自問：“為什麼我們沒有一個類似Azure的平台？”當然，有Azurite、Service Bus模擬器、Cosmos DB模擬器——但它們並不相同。沒有單一的二進制文件，沒有統一的接口——這（現在仍然是）幾乎無法像LocalStack那樣在15分鐘內實現。

於是我開始了自己的Azure模擬器工作，從最基本的功能開始，比如表存儲模擬、簡單的Azure資源管理器模擬以及Azure Key Vault的基礎。這是一個有前途的開端，但很快發現，在我能專注於功能之前，需要克服某些挑戰，而不是重複做同樣的事情。

模板和AMQP地獄

我意識到構建模擬器包含兩層：模擬標準CRUD操作（這些操作在Azure服務間幾乎相同）和模擬數據平面與邊緣情況（這比簡單的“我收到HTTP POST請求，創建資源並返回響應”要複雜得多）。它們需要完全不同的方法和心態，但有一共同點——它們消耗時間。這時我決定在Rider（我的主要IDE）中構建一組模板，這幫助我加速了基礎功能的構建。Topaz CLI命令和ARM端點可以通過簡單的複製/粘貼/替換方法創建。經過簡單改進後，它們可用於服務標準請求。這得益於模擬器的架構：路由器找到匹配的端點並調用它，提供整個HTTP上下文；每個端點實現相同的接口，其唯一目的是提取相關信息並將其傳遞給控制平面；控制平面與資源提供者通信並執行繁重的工作——執行所有Azure特定邏輯。 採用正確的方法，我能在幾分鐘內生成所有必要的代碼。不過有一個警告——生成API響應。我不想將Azure包集成到Topaz中以避免二進制文件膨脹，因此我需要手動實現每個響應模型。這時LLM首次發揮作用——我能指示模型獲取響應模式併為我實現模型。它們仍然喜歡幻化某些字段，幾乎沒有推理（我們談論的是Copilot和Claude模型的早期），但能並行處理事情是巨大的增益。

然而還有一個挑戰，任何使用的模型都無法解決——Topaz中的AMQP實現。初始版本完全基於AMQP協議規範和AMQPNetLite示例手動完成，坦率地説，這些示例遠非理想。Event Hub實現尚可，但Service Bus接口有錯誤且遺漏了許多細節。任何用LLM修正的嘗試都完全失敗——模型瘋狂幻化，提出不存在的方法或破壞協議規範。我決定將其推遲到將來，專注於擴大支持的服務和功能範圍（例如，添加對Azure資源管理器部署的支持）。

加大努力（2026年1月至4月）

幾周內，Topaz並未得到我太多關注，主要是因為我參與了其他項目和計劃。然而，當我準備為一位無法在AzureDay 2026上演講的同事代替時，我想進行一些額外的概念驗證。我在CFP期間提出了關於Topaz的演講，因此進行有意義的改進是有意義的，即使只是為了會議。這時添加了新功能的初始版本：RBAC支持和Entra ID模擬。 在此期間我仍然對使用LLM猶豫不決，主要是因為它們缺乏質量來完成任務並遵循規則。但有些事情開始改變遊戲規則——能夠快速分析和挑戰想法。準備樣板代碼也更簡單、更快速、更精簡。我再次有時間專注於困難的事情，因為我能將無聊的事情（設置新服務、編寫更多測試用例、生成文檔）委託給模型。

加速（2026年5月至今）

在過去的幾個月裏，我深入思考了哪種模型、哪種設置和哪種方法最適合我。我使用了各種模型、不同的思考努力，並測試了較小和較大的上下文窗口。有趣的事情？一個半月多以來，我一直在使用Claude Sonnet 4.6配合低思考努力，效果非常好。較小的模型（如Haiku）無法理解架構並“感受”約定。較大的模型對大多數任務來説過於強大。Sonnet 4.6中/高思考努力只會過度思考。我的最佳點是“有能力的模型它只是做事而不是思考如何做”。

你知道什麼也改變了遊戲規則嗎？Ponytail技能——一個VS Code代理自定義，強制模型尋求最簡單的解決方案而不是過度工程化。在此之前，我有許多特定於代理的指令文件（如CLAUDE.md）。它們已過時，膨脹了上下文窗口，LLM仍然喜歡每其他指令就忽略它們。啓用Ponytail後，Claude Sonnet仍然有能力“多走一步以滿足用户”——只是少做了很多。

那麼現在LLM在Topaz開發中如何使用？有些領域幾乎100%由AI生成：文檔、樣板代碼（端點存根、測試、通用邏輯）、更大的重構（主要是因為代碼庫規模）、處理迴歸測試（如包升級後）、調試時的橡皮鴨。不過，獨特功能、核心邏輯、低級模式不值得通過LLM生成。不是因為不可能。只是因為LLM仍然不“感受”代碼庫，並將每個新功能視為通用。我也不真的覺得值得在一次請求上消耗1000積分，因為我的LLM不理解運行測試、檢查日誌並得到答案會更簡單——而不是試圖通過10k LOC和20個不同包來猜測（同時失去上下文）。

Topaz中的LLM——經驗教訓

通過將LLM和編碼助手納入Topaz，我能夠深入測試各種方法和模式，並找到最適合我的那個。讓我們詳細總結它們。

使用“計劃”模式而非純代理方法

我不會説使用“計劃”模式是實現優雅解決方案的銀彈，但它確實有助於捕捉模型可能做出的所有奇怪決定。從積分消耗的角度來看，我不覺得它有什麼不同——是的，模型會遵循計劃，但計劃需要從上下文中推斷。我將其用於更大的任務，其中錯誤決策的衝擊力很大。

推理努力只會膨脹上下文窗口

LLM思考得越多，它試圖獲取的信息就越多，考慮的選擇就越多。我很少期望模型向我展示所有可能性。我面臨的大多數非常重的查詢都是由LLM過度思考並試圖找到從未期望的黃金解決方案引起的。

通過測試套件引入驗證機制

截至目前，Topaz每天運行超過1500個測試。LLM實現的任何東西都可以自動驗證，只需很少的努力。如果需要，模型也可以自動驗證其方法，但有一個問題——這完全取決於場景。在更復雜的情況下，需要仔細跟蹤實際發生了什麼，LLM往往會迷失。上下文太多，約定太多，問題太具體。人工干預仍然是循環的一部分。

保持簡單

是的，久經考驗的IT規則仍然有效。一件件做事，期望簡單，避免過度闡述。我知道模型能夠寫詩——問題是我希望它們寫。

結論

目前可用的LLM對開發開源項目有幫助嗎？絕對有。有幾件事我很樂意委託給我的AI助手。是否可能通過“氛圍編碼”來開發像Topaz這樣的項目？當然——但問題是這不值得。生成API存根很容易。設計整個生態系統是當前模型無法做到的。也許Claude Opus會改變我的看法。也許Fable會解決我的問題。事實是我不需要它們。

我在第一次提交400次提交後引入了LLM到Topaz代碼庫，並在達到1000次提交後更認真地開始使用它們。我不是通過指令而是通過我自己的設計和測試套件建立了規則和架構。我不需要告訴模型做什麼以及如何做，因為它們可以從代碼庫推斷出來。同樣的代碼庫在進行任何真正的代碼生成之前已經過充分測試和驗證。

我還證明了什麼？我測試並正在使用的模型缺少一個關鍵成分——直覺。Topaz中有許多錯誤，我在閲讀日誌1分鐘後就能清楚。對於LLM，即使明確指示它們始終先讀取日誌，它們也會為所欲為。有時它們讀日誌，有時它們試圖證明自己很聰明並繞着圈子30分鐘，燃燒積分並證明它們什麼都不懂。

我不認為沒有LLM的幫助，Topaz能取得同樣的成就。對我來説，它們已經證明是有用的工具——它們幫助我更快地構建模擬器，提高質量，並確保一切是最新的。但負擔得起的模型仍然遠未進行實際的工程。它們看起來像是知道自己在做什麼。它們似乎是偉大的分析師。但在表面之下，它們只是更復雜的代碼生成器，需要被編排和仔細監督。