10万行Rust代码+AI开发经验总结

过去几个月里，我一直在进行压力测试，想看看 AI 编程 Agent 在构建真正达到生产级别的分布式系统时，究竟能把我们带多远。

最终成果是一个基于 Rust 的 multi-Paxos 共识引擎。它不仅实现了 Azure Replicated State Library（RSL）[1] 的全部功能——后者是 Azure 大多数主要服务的底层基础——还针对当今的硬件进行了现代化改造。

整个项目耗时约 3 个月：其中约 4 周完成了 10 万行 Rust 代码，又用约 3 周进行性能优化，将吞吐量从每秒 2.3 万次操作提升到了每秒 30 万次操作。

除了前所未有的生产力提升，我还发现了几种发挥了关键作用的方法。本文将分享我最有价值的经验，包括：如何通过代码契约确保正确性，如何采用轻量级的 Spec-Driven Development，以及如何进行激进的性能优化——此外还有我对 AI 辅助编程未来发展的一些期待。

Azure 的 RSL 实现了 multi-Paxos 共识协议，是许多 Azure 服务实现复制的核心基础。然而，RSL 编写于十多年前。它虽然足够稳健，却没有随着现代硬件和工作负载一起演进。

这个项目主要由 RSL 的三个关键缺口推动：

• 不支持流水线：当一个投票请求正在传输时，新请求必须等待，从而增加延迟。

• 不支持 NVM：非易失性内存如今在 Azure 数据中心已经十分常见，可以大幅缩短提交时间。

• 对硬件特性的利用有限：RSL 在设计时并未考虑 RDMA，而 RDMA 如今已经广泛应用于 Azure 数据中心。

消除这些限制，可以显著降低延迟并提高吞吐量——这对于现代云工作负载和 AI 驱动的服务至关重要。

出于我对 Rust 和 AI 加速开发的兴趣，我决定从零开始构建一个现代化的 RSL 等价实现。

生产力大幅提升

在大约六周时间里，我驱动 AI 完成了超过 13 万行 Rust 代码，实现了 RSL 的完整功能集，包括 multi-Paxos、Leader 选举、日志复制、快照和配置变更。

我使用了许多现有的 AI 编程 Agent：GitHub Copilot、Claude Code、Codex、Augment Code、Kiro 和 Trae。我的工作流演进得很快，不过目前主要使用 Claude Code 和 Codex CLI，由 VS Code 负责查看 diff 和进行小幅修改。

我发现，通过 CLI 编程可以形成一种非常理想的异步工作流，最大限度地提高我的生产力。我还发现了一个简单的心理技巧：

我每月花 100 美元订阅 Anthropic 的 Max 套餐。这成了一种强制约束——如果睡觉前没有给 Claude 启动一个编程任务，我就会觉得自己在浪费钱。

Codex CLI 推出后，我又增加了第二个 ChatGPT Plus 订阅来应对速率限制——一个订阅用于周一到周三，另一个用于周四到周日。

代码契约——由 AI 编写，也为 AI 服务

别人最常问我的问题是：AI 怎么可能正确实现 Paxos 这样复杂的系统？

测试是第一道防线。我的系统现在包含 1,300 多个测试——从单元测试，到最小化集成测试（例如只测试 proposer 和 acceptor），再到注入故障的多副本完整集成测试。具体请参阅项目状态。

但真正的突破来自 AI 驱动的代码契约。

代码契约为关键函数规定前置条件、后置条件和不变量。在测试期间，这些契约会被转换成运行时 assert；而在生产构建中，则可以为了性能将其禁用。虽然我很早以前使用 .NET [2] 时就开始采用这种方法，但 AI 让代码契约变得强大得多。

我从三个层面应用代码契约：

1. 让 AI 编写契约。Opus 4.1 写出的契约不错，但 GPT-5 High 写得非常出色。我的重点是审查和完善契约。例如，process_2a 方法（负责处理 Paxos 中的 phase 2a 消息）包含 16 个契约，其中包括下面这一条：

2. 根据契约生成测试。定义好契约后，我会让 AI 为每个后置条件创建有针对性的测试用例。AI 非常擅长这项工作，可以自动生成有意义的边界情况。

3. 为契约创建基于属性的测试。这是我最喜欢的做法。AI 会把契约转换成基于属性的测试，通过大量随机输入探索广阔的状态空间。任何契约违规都会触发 panic，从而尽早暴露深层缺陷。

例如，一个由 AI 生成的契约发现了一处隐蔽的 Paxos 安全性违规：

仅仅这一条契约，就避免了一个可能造成严重复制一致性问题的缺陷——而且是在它有机会进入生产环境之前就发现了。

轻量级 Spec-Driven Development

我尝试过各种 Spec-Driven Development（SDD）工具。事实上，早期组件——例如 Leader 选举、proposer、acceptor 和 learner——全都是按照严格的 SDD 方法实现的。我会先编写需求 markdown，再将其转化成设计 markdown，最后生成任务列表 markdown。但我逐渐发现，这套流程过于僵化；在开发过程中进行修改，并确保所有文档始终保持一致，变成了一件令人头疼的事。

现在，我改用了一种更轻量的方法。当我开发某项功能时，例如快照，我会使用 spec kit [3] 的 /specify 生成一份 spec markdown。这份 spec 由几条用户故事和验收标准组成。

下面是一条关于快照的用户故事示例：

接下来，我会使用 /clarify，让 AI 自我批判并改进这些用户故事和验收标准。我还会让它提出初始 spec 没有覆盖到的其他用户故事。我会把大部分时间花在这个阶段。

满意之后，我会直接进入 plan mode，让 AI 针对某一条具体的用户故事生成计划。考虑到当前 AI 编程 Agent 的能力，单条用户故事似乎正好是它们能够有效处理的“最佳粒度”工作单元。在这个过程中，我们可能会发现需要补充或调整的地方，这些都很容易在同一个编程会话中处理（Agent 可能会压缩上下文，但我通常不太担心会因此丢失太多信息）。

下面是一次针对配置变更的 /clarify 交互示例：

● Question 4: Starting Slot Determination

  How should the starting slot for the new configuration be determined relative to the ending slot?

  Recommended: Option A - Always exactly ending_slot + 1

  This ensures no gaps in the slot sequence and maintains continuity between configurations, preventing any slots from being orphaned or unassigned.

  | Option | Description                                                    |
  |--------|----------------------------------------------------------------|
  | A      | Always exactly ending_slot + 1                                 |
  | B      | Allow operator to specify any value > ending_slot              |
  | C      | Next multiple of 1000 after ending_slot for cleaner boundaries |
  | D      | Same as ending_slot (both configs share final slot)            |

  You can reply with the option letter (e.g., "A"), accept the recommendation by saying "yes" or "recommended", or provide your own short answer.

激进的性能优化

性能优化是 AI 真正大放异彩的领域。在确保初步正确性之后，我用了大约三周时间专门进行吞吐量调优——而 AI 成了我进行性能工程时的副驾驶。

经过多轮迭代，我们在一台普通笔记本电脑上将吞吐量从每秒约 2.3 万次操作提升到了每秒约 30 万次操作。下面是我反复执行的循环：

• 让 AI 在所有代码路径中加入延迟指标检测。

• 运行性能测试并输出 trace 日志。

• 让 AI 分析延迟明细（它会编写 Python 脚本来计算分位数并识别瓶颈）。

• 让 AI 提出优化方案，实现其中一项，重新测量，然后重复这一过程。

这套流程揭示出了一些我自己可能会遗漏的问题，例如异步路径中的锁竞争、冗余的内存复制，以及不必要的任务创建。

Rust 的安全模型让我可以充满信心地推进这些优化。主要的性能提升来自减少内存分配、应用零拷贝技术、避免锁，以及有选择地消除异步开销。每一项改进，都像是从一个高性能引擎上剥掉一层延迟——同时又无须担心内存损坏。

对 AI 辅助编程的期待

回顾这段经历，我一直在思考 AI 还能在哪些方面创造更多价值。下面是我的一些愿望：

• 端到端执行用户故事：我仍然倾向于自己定义用户故事。作为架构师，我觉得自己更清楚要构建什么，以及希望以什么方式构建。不过，我相信 AI 会越来越擅长实现完美交付。如今，我仍然需要投入相当多的时间来引导 AI——当它暂停时告诉它继续，建议重构，审查测试覆盖率，以及建议补充测试。我希望 AI 能拥有更高的自主性，端到端地推动整个过程。

• 自动化契约工作流：应用契约的流程看起来很大程度上可以自动化。我仍然希望审查契约并提出建议，但我想让 AI 推动其余工作：基于契约生成测试、调试单个测试用例、确保测试与契约保持一致，以及编写基于属性的测试。当测试失败时，我希望 AI 能自动调试并修复简单问题，只有当契约或实现中确实存在正确性问题时才通知我。

• 自主性能优化：性能调优似乎非常适合进一步实现自动化。我所做的许多工作都具有重复性，而且可以并行执行。AlphaEvolve（或 OpenEvolve）这样的项目已经展示了这方面的潜力。理想情况下，我只需提出可能的优化方向，AI 就能完全独立地执行实验。当前工具虽然主要处理规模较小的代码，但将类似技术应用到更大的代码库，并进行端到端测量，看起来是可行的。

附录：项目状态

这个项目的起点，是 Microsoft Research 的 Jay Lorch [4] 编写的一份优雅的设计 markdown。这份设计极大简化了 multi-Paxos 中的所有组件，让系统更容易实现和推理。

目前，RSL 的三项限制中已经解决了两项：流水线和 NVM 支持。Jay 集成了面向 NVM、经过完整验证的持久化日志；该成果发表于 OSDI 2025 的 PoWER Never Corrupts 论文 [5]。RDMA 支持仍有待完成。

截至目前，该项目已经增长到超过 13 万行 Rust 代码，并拥有 1,300 多个测试；测试代码占整个代码库的 65% 以上。