一个人，约 3 个月，13 万多行 Rust，1300 多个测试，把一个类 Azure RSL 的 multi-Paxos 系统重写出来。测试代码占比超过 65%。单机笔记本上，吞吐从约 23K ops/sec 优化到约 300K ops/sec。

这组数字很抓眼，也很容易被读歪。它不是 Azure 官方替代品，不是公开云生产验证，更不能翻译成“AI 已经能独立写生产级 Paxos”。它更像一次边界实验：AI 编程代理在复杂基础设施里，能被一个懂系统的人用到什么程度。

我更在意的不是 13 万行。行数最会骗人。真正要看的是：这些代码被什么约束，被谁审阅，怎么测试，怎么证明性能不是偶然跑出来的。

这次到底做到了什么

项目目标，是用 Rust 实现一个现代化的 RSL 类系统。RSL 是 Azure 早年使用的 Replicated State Library，核心是 multi-Paxos，用来处理复制、选主、日志等分布式基础能力。

作者覆盖了 leader election、log replication、snapshotting、configuration changes。还处理了原 RSL 的两个短板：pipelining 和 NVM 支持。RDMA 仍未完成。

维度事实锚点该怎么读
开发周期约 3 个月个人实验，不是工业交付结论
代码规模13 万行以上 Rust规模很大，但可靠性不能按行数计价
测试规模1300+ 测试说明作者知道自己在碰硬问题
测试占比65%+ 为测试代码重点不是多，而是把风险压进测试里
性能变化约 23K → 300K ops/sec单台笔记本结果，不能外推到生产集群
优化周期约 3 周价值在实验闭环，不在一次性灵感
主要缺口RDMA 未完成现代数据中心关键路径还没闭环

这件事对两类人最有参考价值。

一类是基础设施工程师。它说明 AI 可以参与硬核系统开发，但前提是人类能写出边界、审出漏洞、跑出反例。

另一类是正在评估 AI 编程代理的技术负责人。别再只看 demo 能生成多少文件。要看它能不能进入团队的工程闭环：规格怎么写，测试怎么来，回归怎么跑，失败谁解释。

目前看不清的是可复现性。不同模型、不同代码库、不同工程师，结果可能差很多。原文更像经验复盘，不是可直接采购的 benchmark。

真正有用的是三道约束

这篇文章最值得抄的，不是工具清单。Claude Code、Codex CLI、Copilot、Augment、Kiro、Trae 这些名字都会变。工作流更耐看。

第一道约束，是 contracts。

作者让 AI 给关键函数写 precondition、postcondition、invariant，再由人类审阅。测试时，这些 contract 可以转成 runtime assert；生产构建中可以关闭。比如 Paxos phase 2a 的处理函数，作者提到有 16 条 contract。

这一步很关键。AI 不是先被要求“写更多代码”，而是先被要求“说清不能违反什么”。复杂系统里，最贵的 bug 往往不是语法错，而是不变量被悄悄打穿。

第二道约束，是从 contracts 生成测试。

包括普通测试，也包括 property-based tests。这里的重点不是凑测试数量，而是让测试从约束长出来。AI 不只是补几个 happy path，而是在随机输入空间里撞边界。作者提到，contract 曾抓到一次 Paxos safety violation。

这比“让 AI 多写单测”更接近工程现实。单测可以很勤快，也可以很空。property-based tests 的价值，是逼系统在更大的输入空间里交代自己。

第三道约束，是性能实验闭环。

AI 加指标，跑 trace，写 Python 脚本算分位数，定位锁竞争、重复拷贝、多余 task spawn。然后改一项，测一项，再循环。

三周把吞吐推到约 300K ops/sec，靠的不是一句“模型聪明”。靠的是把性能优化拆成可测的小实验。AI 擅长做这种苦活：重复、记录、对比、改脚本、补指标。

“工欲善其事，必先利其器。”今天这句话要反过来看。利器已经很锋利，稀缺的是管住利器的制度。

对工程团队的影响：不是少招人，是换考题

我不太买账“AI 代理很快独立完成复杂基础设施”这种说法。至少从这个案例看，AI 的强项是执行、枚举、补测试、做实验。真正的分水岭还在人这里。

你得知道 Paxos 哪些不变量不能破。你得知道 snapshot 和 configuration change 不是普通 CRUD。你也得知道，单机吞吐数字漂亮，不代表网络抖动、磁盘故障、脑裂恢复、滚动升级都没坑。

AI 写基础设施，最危险的地方不是它写错。写错很正常。危险在于它写得太快、太完整、太像真的。

没有 contracts、审阅、property tests 和性能回归，它就是大型幻觉放大器。有这些约束，它才可能变成杠杆。

这会改变团队里的分工。

普通开发者要补的，不只是“会不会用 AI 工具”。更实际的动作是：给核心模块补 contract，给状态机补 property-based tests，给性能路径补可复测脚本。少一点“让 AI 帮我写功能”，多一点“让 AI 帮我找边界”。

技术负责人更该延后的是采购冲动，而不是试点。先拿一个非核心但足够复杂的模块做试验：要求 AI 生成规格、测试、指标和变更记录。评估标准也别只看速度，要看缺陷密度、回归成本、审阅压力和性能波动。

接下来最该盯的，不是又多了多少行代码。

要看 RDMA 能不能完成；多节点环境下能不能扛住故障注入；是否有类似 Jepsen 思路的外部一致性验证；性能数字能不能从单机笔记本走到真实网络、真实磁盘、真实升级流程。

这些地方过不了，13 万行就是漂亮的工程样本。过得了，才有资格讨论生产级基础设施。

所以，这篇文章的价值不是证明 AI 能替代工程师。它证明了另一件更现实的事：AI 会把工程师推向架构师、审计员和实验调度员的位置。

手少敲一点代码，脑子要多盯一点后果。这个变化不浪漫，但很硬。