用AI智能体测试分布式系统：一场从“集成测试”到“索赔驱动”的范式迁移
分布式系统和有状态系统的测试一直是个棘手问题。传统的集成测试方法——写几个测试用例然后收工——在真实生产环境中能捕获的Bug只占很小一部分。Hacker News上最近一篇热门文章提出了一套新思路：用AI编码智能体（AI coding agents）来设计和执行“索赔驱动”（claim-driven）的测试，并给出了两个具体的Skill文件（SKILL.md）来实现这一流程。
核心流程：Plan + Execute
这套方案由两个智能体技能协作完成：Plan Skill 负责设计测试计划，Execute Skill 负责执行。两者输出的产物是一份结构化的Markdown测试计划（plan）和一份发现报告（findings report）。报告包含9种状态裁决（9-state verdicts）以及明确的故障归属分类（SUT / Harness / Checker / Environment），评审者只需阅读这两份文档即可决定是否发布，无需重新运行任何测试。
索赔驱动：从产品承诺出发
与传统测试驱动开发（TDD）不同，这套方法的核心是“索赔驱动”（claim-driven）。测试计划从产品的承诺（claims）出发，为每个承诺生成假设，并编写以该承诺命名的场景，每个场景试图在一种故障条件下证伪（falsify）该承诺。文章强调：“一个以承诺命名的测试，比一个以设置命名的测试更难被削弱。”
模型 + 历史 + 检查器：不只是混沌
对于一致性关键场景（如安全性、持久性、幂等性、隔离性、排序、成员关系等），每个场景还需绑定一个抽象模型（register | queue | log | lock | lease | ledger …）、一个操作历史模式、一个命名检查器（线性一致性、可序列化性、会话一致性、无丢失确认、恰好一次等），以及如何处理模糊结果（超时、未知提交、重试）。文章称这种组合为“混沌 + 模型 + 检查器，而不仅仅是混沌”。
覆盖充分性作为可交付物
测试计划以一个覆盖充分性论证（coverage adequacy argument）和一份保守的置信度声明（conservative confidence statement）结尾。计划会诚实地列出哪些场景未经验证，并论证已选场景足以支撑发布的理由。这改变了以往测试“做完就好”的模糊状态，让测试的覆盖边界变得透明。
兼容性与复用性
这套方法兼容主流的AI编码工具，包括 Claude Code、Codex、Copilot CLI、Cursor、Gemini 等——任何能阅读Markdown并运行shell的智能体都适用。同时，Execute Skill 会优先发现被测系统（SUT）已有的测试、runbook和故障注入脚手架，复用现有工具箱，而非从头发明。
行业视角
随着AI编码智能体在软件开发中的渗透率持续提升，将智能体用于测试——尤其是分布式系统测试——正在成为一个自然且强大的应用方向。传统测试工具（如Jepsen）虽然能发现深层Bug，但门槛高、自动化程度低。而AI智能体可以自动生成测试计划、执行并生成结构化报告，大幅降低分布式系统测试的准入门槛。
不足与局限：文章中的方案目前仍依赖人工评审最终报告，且智能体对测试计划的“覆盖充分性论证”质量取决于底模型的能力。此外，9种状态裁决如何定义、模型与检查器的选择是否完备等细节尚需更多实践验证。
小结
“索赔驱动测试”为分布式系统测试提供了一种可落地、可复用的方法论，尤其适合与AI编码智能体结合。它从产品承诺出发，用模型和检查器强化测试的可验证性，并通过覆盖论证让测试边界透明化。如果你正在为分布式系统的测试质量发愁，不妨试试这套思路。