这个 Skill 治好了分布式测试的”测了个寂寞”

写完几个并发服务就敢上线的人，今天都得看看这个 Skill。shenli/distributed-system-testing 不是又一份「让 AI 写测试」的花活，而是一套逼你把分布式系统”信任声明”摆到台面上、逐条证伪的工程方法论——而且 Claude Code、Codex、Cursor、Gemini CLI、Copilot CLI 都能直接吃。

它解决的是「测了个寂寞」的问题

绝大多数团队的分布式测试路径是这样的：写几个 happy path 集成测试，CI 一绿就推上线。结果生产里被吊打的，全是它们没覆盖的——分区恢复时已 ACK 的写丢了没、租约过期瞬间并发读返回什么、幂等键被重放两次会不会扣两次款、滚动升级中途老 leader 还没退位新 leader 就接权。

这两个 Skill 的核心回答是：别从测试入手，从产品声明入手。每个场景必须能指出它对应哪条产品承诺、模拟了哪种故障、用什么 checker 验证结果、且要有「故障真的命中了」的着陆证据。

两个 Skill，分工明确

• designing-distributed-system-tests：遍历代码库提取声明 → 生成失败假设 → 从 Jepsen / deterministic simulation / chaos injection / property testing 技术目录里挑手段 → 输出一份 Markdown 测试计划。一致性关键场景还要绑定一个抽象模型（register / queue / log / lock / lease / ledger），配上命名 checker（linearizability、serializability 等）和 nemesis 着陆证据。
• executing-distributed-system-tests：拿到计划后真正跑，含故障注入、checker 输出、模糊结果处理（超时 / 重试 / unknown commit 怎么办）、10-state verdict 判定，最后给出 SUT / harness / checker / environment 四级 blame 分类。

几个让人服气的细节

• 「覆盖充分性论证」是计划的强制收尾——你必须解释为什么这几个场景就够支持上线决策，否则计划不合格。
• 对一致性 / 持久性 / 隔离 / 幂等 / 顺序这类关键声明，要求显式声明模型 + 检查器，禁止只跑 chaos 就当通过。
• 故障着陆证据：每个 PASS 都要附上能证明 nemesis 真的生效的记录——避免「分区脚本跑成功了但其实啥都没分」的伪绿灯。
• blame 分类把测试失败归到 SUT / 工具链 / 检查器 / 环境四档，下次排障直接找到责任人。

适合谁装

在做数据库 / 消息队列 / 调度器 / 控制器 / 工作流引擎 / 分布式锁 / 协调服务这类「正确性靠状态转换吃饭」的工程团队，特别是 SRE 和基础架构组。第一次用建议从一个声明 + 一个真实故障 + 一个强 checker 开始，别上来就项目级 plan，节奏更好控制。

⚠️ 它生成的 plan 是 review 素材不是圣经——claim 列表、残余不确定性、上线信心判断还是需要人来盖章。

GitHub：shenli/distributed-system-testing（MIT · 229 stars · 12 forks · 仍活跃维护）

GitHub: https://github.com/shenli/distributed-system-testing