10 万行 Rust 代码开发实测封神！AI 应用经验大揭秘

从 10 万行 Rust 代码开发中获得的 AI 应用经验2025 年 12 月 1 日在过去几个月里对 AI 编码工具在构建实际生产级分布式系统方面的能力进行了压力测试。结果是开发出了一个基于 Rust 的多 Paxos 共识引擎。它不仅实现了 Azure 复制状态库Replicated State LibraryRSL[ [1](https://github.com/Azure/RSL) ]的所有功能RSL 是大多数主要 Azure 服务的基础还针对现代硬件对其进行了升级。整个项目历时约 3 个月其中约 4 周内编写了 10 万行 Rust 代码约 3 周内将性能从每秒 2.3 万次操作提升到了每秒 30 万次操作。除了实现前所未有的开发效率外还发现了一些非常有用的技术。本文将分享在以下方面最有价值的经验通过代码契约确保代码正确性、采用轻量级规范驱动开发方法、积极进行性能优化以及对未来 AI 辅助编码的期望。为何要升级 RSLAzure 的 RSL 实现了多 Paxos 共识协议是许多 Azure 服务复制功能的核心。然而RSL 是十多年前编写的。尽管它很健壮但未能跟上现代硬件和工作负载的发展。推动这个项目的主要有三个关键差距1. 缺乏流水线机制当一个投票正在进行时新请求必须等待这会增加延迟。2. 不支持非易失性内存NVM非易失性内存在 Azure 数据中心已很常见它可以显著减少提交时间。3. 对硬件的感知有限RSL 没有针对远程直接内存访问RDMA进行优化而 RDMA 在 Azure 数据中心已广泛使用。消除这些限制可以显著降低延迟并提高吞吐量这对于现代云工作负载和 AI 驱动的服务至关重要。鉴于对 Rust 和 AI 加速开发的兴趣决定从头开始构建一个现代版的 RSL。开发效率大幅提升在大约六周的时间里借助 AI 实现了超过 13 万行 Rust 代码涵盖了 RSL 的所有功能包括多 Paxos、领导者选举、日志复制、快照和配置更改等。使用了许多可用的 AI 编码工具如 GitHub Copilot、Claude Code、Codex、Augment Code、Kiro 和 Trae。工作流程不断演变目前主要使用的是 Claude Code 和 Codex CLI同时用 VS Code 处理代码差异和进行小的编辑。发现从命令行界面CLI进行编码能形成完美的异步工作流程极大地提高了开发效率。还发现了一个简单的心理技巧 每月支付 100 美元订阅 Anthropic 的高级计划。这成了一种驱动力——如果睡前不使用 Claude 启动一个编码任务就会觉得在浪费钱。当 Codex CLI 推出后又订阅了第二个 ChatGPT Plus 账号来应对速率限制一个账号用于周一至周三另一个用于周四至周日。由 AI 生成、为 AI 服务的代码契约最常被问到的问题是“AI 如何能正确实现像 Paxos 这样复杂的算法”测试是第一道防线。系统现在有 1300 多个测试从单元测试到最小集成测试如仅测试提议者和接受者再到包含故障注入的多副本全集成测试。具体项目状态可查看相关内容。但真正的突破来自于 AI 驱动的 代码契约 。代码契约为关键函数指定了 前置条件 、 后置条件 和 不变量 。这些契约在测试时会转换为运行时断言但在生产环境中为了性能可以禁用。虽然很久以前就在 .NET 中使用过这种方法 [ [2](https://learn.microsoft.com/en-us/dotnet/framework/debug-trace-profile/code-contracts) ]但 AI 让契约的功能变得更强大。从三个层面应用代码契约1. 让 AI 编写契约Opus 4.1 能编写不错的契约而 GPT - 5 High 编写的契约更出色。主要负责审查和完善。例如process_2a 方法处理 Paxos 协议中的 2a 阶段消息有 16 个契约其中一个如下2. 根据契约生成测试用例定义好契约后让 AI 为每个后置条件创建有针对性的测试用例。AI 在这方面表现出色能自动生成有意义的边界情况。3. 基于属性的契约测试这是最喜欢的方法。AI 将契约转换为基于属性的测试探索大量随机输入。任何契约违反都会触发程序崩溃从而尽早发现深层次的 bug。例如一个由 AI 生成的契约发现了一个微妙的 Paxos 安全漏洞这个契约避免了一个可能严重影响复制一致性的问题而且是在问题进入生产环境之前就被发现了。轻量级规范驱动开发尝试过各种规范驱动开发Spec - Driven DevelopmentSDD工具。实际上早期的组件如领导者选举、提议者、接受者和学习者都是按照严格的 SDD 方法实现的。会从需求文档开始将其转化为设计文档再转化为任务列表文档。然而逐渐发现这个过程过于僵化在开发过程中进行更改并确保所有文档保持一致变得很麻烦。现在转向了更轻量级的方法。当开发一个功能如快照功能时使用 spec kit [ [3](https://github.com/github/spec-kit) ] 中的 /specify 命令生成一个规范文档。这个规范文档包含几个用户故事和验收标准。以下是一个关于快照功能的用户故事示例然后使用 /clarify 命令让 AI 对用户故事和标准进行自我审查和改进并让它提出初始规范中未涵盖的其他用户故事。大部分时间都花在这一步。满意后进入 计划模式 让 AI 为特定的用户故事生成一个计划。鉴于当今 AI 编码工具的能力单个用户故事似乎是它们能有效处理的“最佳”工作单元。在这个过程中可能会发现一些需要添加或调整的地方这些在同一个编码会话中很容易处理AI 可能会压缩上下文但通常不担心会丢失太多信息。以下是一个关于配置更改的 /clarify 交互示例● 问题 4起始槽位确定新配置的起始槽位应如何相对于结束槽位来确定建议选项 A - 始终为结束槽位 1这确保了槽位序列没有间隙并保持配置之间的连续性防止任何槽位被孤立或未分配。| 选项 | 描述 || ---- | ---- || A | 始终为结束槽位 1 || B | 允许操作员指定任何大于结束槽位的值 || C | 结束槽位之后的下一个 1000 的倍数以获得更清晰的边界 || D | 与结束槽位相同两个配置共享最后一个槽位 |你可以回复选项字母如“A”通过说“是”或“建议”接受建议或提供你自己的简短答案。积极的性能优化性能优化是 AI 真正发挥作用的地方。在确保代码初始正确性后花了大约三周时间专门进行吞吐量调优AI 成为了性能优化的得力助手。通过迭代循环在一台笔记本电脑上将吞吐量从每秒约 2.3 万次操作提高到了每秒约 30 万次操作。反复遵循以下步骤1. 让 AI 在所有代码路径上插入延迟指标。2. 运行性能测试并输出跟踪日志。3. 让 AI 分析延迟分布它会编写 Python 脚本来计算分位数并识别瓶颈。4. 让 AI 提出优化建议实施其中一个建议重新测量然后重复这个过程。这个过程揭示了一些可能会忽略的问题例如异步路径上的锁竞争、冗余的内存复制和不必要的任务创建。Rust 的安全模型让可以放心地进行这些优化。关键的改进来自于减少内存分配、应用零拷贝技术、避免使用锁以及有选择地消除异步开销。每一次改进都像是从高性能引擎上剥去一层延迟而且不用担心内存损坏的问题。对 AI 辅助编码的期望回顾开发历程一直在思考 AI 还能在哪些方面发挥更大的价值。以下是一些期望1. 端到端用户故事执行仍然更喜欢自己定义用户故事。作为架构师觉得自己更清楚要构建什么以及如何构建。然而相信 AI 在完美执行方面会越来越出色。目前仍然需要花很多时间引导 AI比如在它暂停时让它继续工作、建议重构、审查测试覆盖率并建议添加额外的测试。希望 AI 能在端到端的执行过程中拥有更多自主权。2. 自动化契约工作流应用契约的流程似乎大部分可以自动化。虽然仍然希望审查契约并提出建议但希望 AI 能完成其余的工作如根据契约生成测试、调试单个测试用例、确保测试和契约的一致性以及编写基于属性的测试。当测试失败时希望 AI 能自动调试并修复一些小问题只有在契约或实现中存在真正的正确性问题时才通知。3. 自主性能优化性能调优似乎很适合进一步自动化。所做的很多工作都是重复性的且可以并行进行。像 AlphaEvolve或 OpenEvolve这样的项目在这方面展现出了潜力。理想情况下只需提出潜在的优化方向AI 就能完全自主地进行实验。虽然目前的工具只能处理小代码块但将类似的技术应用于更大的代码库并进行端到端的测量似乎是可行的。附录项目状态这个项目的灵感来源于微软研究院的 Jay Lorch 撰写的一份优雅的设计文档 [ [4](https://jaylorch.net/) ]。这份设计大大简化了多 Paxos 中的所有组件使其更易于实现和理解。到目前为止RSL 的三个限制中已经解决了两个流水线机制和 NVM 支持Jay 集成了在 OSDI 2025 会议上发表的 PoWER Never Corrupts 论文 [ [5](https://www.usenix.org/conference/osdi25/presentation/leblanc) ] 中经过完全验证的 NVM 持久化日志。RDMA 支持仍有待实现。到目前为止项目已发展到超过 13 万行 Rust 代码有 1300 多个测试占代码库的 65% 以上。一个学习与分享的小天地