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能取得同样的成就。对我来说，它们已经证明是有用的工具——它们帮助我更快地构建模拟器，提高质量，并确保一切是最新的。但负担得起的模型仍然远未进行实际的工程。它们看起来像是知道自己在做什么。它们似乎是伟大的分析师。但在表面之下，它们只是更复杂的代码生成器，需要被编排和仔细监督。