用途 当你在 ONNX Runtime 中修改 CUTLASS fused-MHA 头文件（onnxruntime/contrib_ops/cuda/bert/cutlass_fmha/ 下，例如 kernel_forward.h、fmha_launch_template.h）后，本技能说明如何正确做增量重建与验证，避免“假绿”问题。
问题 nvcc 生成的 depfile 不追踪 cutlass_fmha 下的头文件依赖，而这些头文件被 fmha_sm*.cu 翻译单元 #include。因此修改头文件后运行 build.sh 不会重编译 fmha_sm*.cu，却仍报告 [100%] Built 并返回 0，fmha_sm*.cu.o 与 libonnxruntime_providers_cuda.so 的 mtime 保持编辑前状态，实际仍运行旧内核，使 FAIL→PASS / PASS→FAIL 验证失效。
用法 修改任一 cutlass_fmha/.h 头文件后、重建之前先执行： touch onnxruntime/contrib_ops/cuda/bert/cutlass_fmha/.cu 然后运行正常构建命令，强制重编译相关翻译单元及下游产物。
验证 不要只看测试 EXE 的 mtime：在 shared-provider 默认构建中，provider 是共享模块，fmha_sm*.cu.o 链接进 libonnxruntime_providers_cuda.so，测试 exe 通过 dlopen 加载该 .so，并不重新链接，因此正确重建后 exe mtime 仍为旧值。可靠信号是被重编译的 .o 与 .so 的 mtime。共享库构建检查 build/<dir>/<cfg>/libonnxruntime_providers_cuda.so；静态链接 provider 则检查 onnxruntime_provider_test 可执行文件。可 stat 两者确认均比头文件编辑更新，命令示例： stat -c '%y %n' onnxruntime/contrib_ops/cuda/bert/cutlass_fmha/kernel_forward.h stat -c '%y %n' libonnxruntime_providers_cuda.so find . -name 'fmha_sm80.cu.o' -exec stat -c '%y %n' {} + 若 .so 或 .o 不比头文件新，说明构建过期，touch .cu 后重建。最可靠信号是行为：原本失败的测试现在通过。
相关注意 attention/MEA/Flash 边界 gtests（如 FlashStructuralEmptyRows*、Attention_Causal_NonPadKVSeqLen_MEA_）位于 onnxruntime_provider_test，onnxruntime_test_all 不含这些测试，会给出假绿。共享 GPU 机器上注意磁盘空间，构建目录可能达数十 GB；重建前检查空间： df -h /home du -sh build/ | sort -h 只清理明确过期、可再生的构建目录，不要删除他人正在使用的构建目录。