Validation Strategy

---
name: validation-strategy
description: Use when 为 CPython/CinderX 实验选择验证范围或成本预算，决定是否扩大测试。
---

# 验证策略：准确与高效

选择足以支撑当前结论的验证范围。等级描述证据范围，不是每次都要逐级执行的清单。

| 等级 | 用途 | 典型产物 |
|------|------|----------|
| L0 静态审计 | 查配置、代码、版本与命令口径 | 环境指纹、候选路径 |
| L1 最小功能验证 | 检查相关行为或环境可用性 | import、smoke、目标单元测试 |
| L2 单 benchmark 复现 | 复现目标性能、崩溃或热点 | 单用例数据、HIR、perf、gdb |
| L3 小集合验证 | 覆盖预期受影响的用例 | Runtime/pyperformance 子集 |
| L4 全量验证 | 用户要求全量或广泛风险需要覆盖 | 全量结果与聚合报告 |

## 选择与停止

- 文档、描述或路由提示修改使用本仓布局与相关 hook 检查，不触发 CPython/CinderX 构建或远程实验。
- 代码行为修改先验证相关功能；性能收益不能替代功能正确性证据。
- 调试从目标失败或 benchmark 开始。L2 现象未复现时，先修正假设，避免为不存在的现象改代码。
- L3 只覆盖受影响集合，结论不能外推到全量。
- L4 依据明确请求、发布要求或已发现的广泛风险选择；提交代码或写报告本身不要求全量。
- 所需检查通过即交付；仅在新改动、失败、噪声或未解风险出现时补测。保留已有有效日志与结果，避免重复运行。

## 成本与授权

优先复用匹配当前源码和环境指纹的 wheel/cache、容器、增量构建和实验产物。变更使哪些证据失效，就重做哪些检查。

用户已要求构建、测试或环境准备时，执行范围内必要的可逆步骤，包括增量构建、隔离安装、相关测试和失败后的修复重跑，不按 L3 标签再次索要授权。全量近千条 RuntimeTests 功能测试或近三小时 pyperformance 性能测试不作为调试默认动作。

开始昂贵实验前说明预计耗时、资源、命令与产物位置；明确请求已覆盖这些成本时继续执行。只有明显超出任务范围/预算、影响共享资源或需删除用户产物时才询问。缺少预算数字不阻塞低成本查证和已授权范围内的工作。

远端无输出先查进程、日志、exit status 和缓存，按已有 timeout/进度策略处理；不要把诊断、等待一次进度或使用现成缓存变成新的审批步骤。

## 证据与结论

运行实验记录环境指纹、真实命令、stdout/stderr、exit status 和产物路径。性能结论还需 baseline 含义、A/B 唯一差异轴、样本与方差；根因结论需热点、HIR/LIR/机器码或 perf/gdb 支撑。缺少证据时标为假设或受限观察，并指出可补证据；不要把低等级或不配对数据写成正式收益。