15 个月用 AI 写开源 Azure 模拟器：Sonnet 4.6 是最佳搭档

一位独立开发者近日在 Hacker News 发布长文，回顾自己用 15 个月时间构建开源 Azure 本地模拟器 Topaz 的完整历程，并分享了 AI（尤其是 LLM 编程助手）在不同阶段带来的增益与局限。文章的核心结论是：Claude Sonnet 4.6 配合「低思考强度」是他目前找到的最佳组合。

项目缘起：从 LocalStack 到 Topaz

作者此前长期参与一个 AWS 项目，体验过 LocalStack 带来的便利——无需依赖基础设施团队即可在本地完成测试。他反问：「为什么 Azure 没有类似的东西？」Azurite、Service Bus Emulator 和 Cosmos DB Emulator 各自分散，缺乏统一的二进制入口和一致的接口，远不如 LocalStack 那样能在 15 分钟内跑起来。

2025 年 4 月，他提交了 Topaz 的第一个 commit，从 Table Storage 模拟、简易 Azure Resource Manager mock 以及 Azure Key Vault 基础功能起步。

第一阶段：模板与响应模型自动化

Topaz 的架构分为三层：路由匹配端点、端点提取请求并下传控制层、控制层调用资源提供方执行 Azure 业务逻辑。这种分层让作者可以用「复制—粘贴—替换」的方式快速产出模板代码。

真正的瓶颈在于响应模型的实现——为了避免引入 Azure 官方包导致二进制膨胀，他需要手写每一个响应模型。这时 LLM 第一次派上用场：让模型抓取响应 schema 并生成对应模型。当时仍是 Copilot 与早期 Claude 的时代，模型仍会幻觉字段、缺乏推理能力，但「能并行处理」本身就是巨大收益。

不过 AMQP 协议实现是 AI 完全帮不上忙的环节。Event Hub 勉强可用，Service Bus 则漏洞百出；任何让 LLM 修正的尝试都以「疯狂幻觉、提出不存在的方法、破坏协议规范」告终。作者最终选择手动基于 AMQP 协议规范和 AMQPNetLite 示例完成，并在后续聚焦于扩充服务覆盖范围。

第二阶段：LLM 质量仍不够稳定

2026 年 1 月至 4 月期间，作者忙于其他项目，直到要为同事代讲 AzureDay 2026 的演讲，才加速推进了两个关键特性：RBAC 支持与 Entra ID 模拟。

这段时间他对 LLM 仍持保留态度，主要原因是模型质量不足以稳定遵循规则。但 LLM 在分析想法、挑战方案、准备样板代码方面确实让他能把精力集中在难点上；编写测试、生成文档等「枯燥工作」可以交给模型。

当前阶段：Sonnet 4.6 低思考强度成甜点配置

最近两个月，作者系统测试了多种模型、不同思考强度以及不同上下文窗口，得出以下经验：

主力模型：Claude Sonnet 4.6，配合「低思考强度」效果最佳。
太小不行：Haiku 等小模型无法理解 Topaz 的整体架构与代码约定。
太大浪费：更大的模型对多数任务属于过度配置。
高思考强度反效果：Sonnet 4.6 在中高思考强度下会「过度思考」，反而降低产出质量。

他的总结是：「能做事且直接做事的模型」，比「反复思考要不要做事」的模型更适合日常编码工作流。

另一个被作者称为「游戏规则改变者」的细节，是 VS Code 的 Agent 自定义能力「Ponytail skill」——它强制模型优先选择最简方案。不过原文此处被截断，具体机制有待后续补充。