用途：当使用 Warp 的代码出现编译时间或启动时间过长时，用该技能定位并减少冷启动编译成本。
主要能力：提供 scripts/warp_compile_probe.py 探针，支持 measure [OPTIONS] -- COMMAND... 与 --help，可隔离冷/热编译与启动并生成 JSON 结果；支持 compare baseline.json candidate.json 对比。探针为每个样本创建私有的 WARP_CACHE_PATH、WARP_CACHE_ROOT、CUDA_CACHE_PATH 目录，启用模块计时并记录启动。
核心模型：Warp 按模块而非单个内核编译，模块身份为（内核与函数集合）×（模块选项）×（CUDA block_dim）×（泛型实例）。冷启动成本约等于不同模块身份数量乘以每个模块的规模。优化方向包括停止身份频繁变动与减少源码重复；跨独立 CUDA 构建的重叠只改变发生时间，不改变编译量。
必要用法：先用探针测量真实成本，例如 python scripts/warp_compile_probe.py measure --samples 3 --json baseline.json -- <用户命令>；修改后再次测量并用 compare 比较。不要用 wp.clear_kernel_cache() 或 wp.clear_lto_cache() 清理在线缓存。模块选项需在模块创建（Python 导入）或首次加载前设置，例如在导入库前设置 wp.config 选项，或用 wp.set_module_options() 与 wp.get_module(name).options 调整；选项改变后应确认模块哈希变化。
适用场景：优化编辑-运行循环或生产启动；诊断一个模块名对应多个哈希、同一模块不同 block_dim 重复编译、每内核独立模块、MathDx/LTO 开销、缓存未复用、并发 CPU JIT 首次加载竞争、展开预算、反向代码生成、预编译头与并行构建等问题。
限制：每次冷样本必须隔离 Warp 与 CUDA 缓存；当加载可能面向 CPU（包括 device=None 与混合设备列表）时保持 max_workers <= 1；测量结果依赖 CPU、GPU、驱动、工具链与 Warp 版本，机制可迁移但数值不可直接照搬。修改 fast_math、max_unroll、MathDx 或实现方式可能影响运行速度或数值，需先确认取舍。具体环境版本、收费与平台支持信息暂未提供。