技能介绍

要解决的问题

在代码交付环节，验证经常退化成一句承诺：提交记录写着“已测试”，评审里贴着“应该没问题”，真正执行测试的人却找不到可复现的命令。更麻烦的是，变更范围不同，验证强度却一样，纯文档修改和涉及权限、数据库、外部 API 的改动被同等对待。结果是，要么小改动被迫做全量回归，要么高风险改动被快速放行。

xtest 把这个流程拆成可执行的门禁。它不信任口头确认，只认可实际运行过的验证结果；也不允许跳过步骤，尤其是刚由模型自己生成或修改的代码。

工作方式

xtest 采用五步法流程，简称 DTRC：

DEFINE：先判断变更级别。L0 适用于纯文本、注释或配置值微调；L1 适用于单文件修改、新项目、架构变更、安全或数据相关改动。判断依据包括变更文件数量、代码行数、是否影响外部依赖、生产环境或用户数据。
TEST：根据级别生成验证方案。SKILL.md 明确列出了 L1、L2、L3 三个验证层级。
RUN：先跑基础语法检查，例如 Python 使用 python3 -m py_compile，Shell 使用 bash -n；再逐条执行用例，并记录通过或失败、实际输出和失败原因。
CHECK：失败后进入修复循环。第 1 轮分析直接原因；第 2 轮检查是否遗漏依赖或环境问题；第 3 轮仍未通过则拒绝交付。每一轮都必须说明改了什么，以及为什么这么改。
DELIVER：根据最终结果输出通过或拒绝报告。

它还区分了门禁和方法论：xtest 负责决定“要不要验证、验证到什么程度”，test-master 是测试方法论库，只有在 L3 深度验证时才自动加载完整测试框架参考。L1 和 L2 使用内置规则即可。

适用边界

这套技能适合作为交付前的强制门禁，尤其是改完代码后需要明确记录验证结论的场景。它不负责编写业务测试，也不把验证范围扩大到全量回归，只覆盖本次变更。

需要注意，SKILL.md 中列出了 L2 标准验证 和 L3 深度验证，但没有写明这两个层级的具体触发条件和测试清单。实际使用时不能把 L1 的规则直接套到 L3，尤其是安全、数据和架构相关变更，需要补足更完整的用例和环境检查。另外，修复应控制在最小必要范围，不能借修复之名顺手重构。