测试清单 50 条，压成 10 张能力卡

程序员圈有本名著叫《清单革命》，测试圈对应的是 Elfriede Dustin 的《有效软件测试——提高测试的 50 条建议》。50 条建议的问题和所有清单一样：太长，没人真的照着做。effective-software-testing-skill 的解法很「Agent 原生」：把 50 条压成 1 个入口 + 10 张原子能力卡，按意图路由加载——你要审需求，它只加载可测试性审查那张卡，49 条别的建议不进上下文。

这就是清单文化在 Agent 时代的形态变化：清单从「贴在墙上」变成「按需注入」。

十张卡，挑三张压箱底的

需求可测试性审查（requirements-testability-review）：十属性清单逐条打分——每条需求是否可观察、可测量、有明确边界？附带质量测度标准和奖惩打分。测试左移的第一道工序就是它：需求都测不了，后面全白搭。

回归冲击矩阵 + 阻断式流水线（regression-smoke-pipeline）：编译 → 烟雾 → 回归的阻断链路，配一张「改了什么、冲击哪里」的矩阵。回归测试的量永远不够，矩阵决定了有限的量往哪打。

自动化候选八判据（automation-expectations-and-tool-selection）：哪些用例值得自动化？八条判据过一遍——执行频率、稳定性、数据依赖、人力成本……这个判据表救过无数「想当然全自动化」的团队。

flowchart TD
    A["《有效软件测试》50 条建议<br/>Elfriede Dustin"] --> B["cangjie-skill 编译<br/>single + workflow 模式"]
    B --> C["1 个入口 Skill<br/>意图路由表"]
    C --> D["10 张原子能力卡<br/>需求·估算·数据·设计·单元"]
    D --> E["按任务加载单卡<br/>其余不进上下文"]

值得一提的编译选项

这个技能包用了 --output single --purpose workflow 编译——同一份能力 Bundle 可以编成 single（单入口）也可以编成 pack（多技能）。这暴露了拆书流水线的一个设计洞察：知识的组织形式应该匹配使用场景，个人速查用 pack，工作流嵌套用 single。数据本身没变，变的是打包方式。

边界与判断

适用：测试流程的体系化盘点、团队建立测试规范时的底稿、给 Agent 配一个「测试流程顾问」。不适用：当作即战力——50 条建议是 2002 年的书，Web 时代的新战场（小程序、LLM 应用）得自己补卡。

版权处理也值得注意：能力卡含不超过 150 字的原文摘引用于溯源——这是「蒸馏」和「搬运」的法律边界，做拆书的人都该学。

我的判断：50 条建议最大的价值从来不是每条都执行，而是知道它们存在、在特定时刻能捞出来。Agent 恰好是这种「存在感低、调用时准」的载体——清单革命的下半场，大概就是这样。

如果你也被「50 条建议只记得 3 条」困扰过，点个在看，这套压缩方法值得被看见。

仓库：https://github.com/Fen9pi-Max/effective-software-testing-skill（MIT 精神，≤150 字摘引溯源）