*CUDA 与进阶扩展¶
这一页是明确的进阶内容。如果你现在还没把 DecisionModule -> Play -> Skill -> Action 的主链走顺，先完全可以把它放后面。因为对大多数日常战术开发来说，CUDA 不是起步门槛，而是进一步做性能增强时才会真正碰到的层。
CUDA 模块在仓库里的位置¶
当前可选 GPU 模块主要位于：
根 CMake 里通过：
控制是否启用。这件事本身就说明了它的定位：它是可选增强，而不是当前整个比赛系统必须依赖的绝对基础设施。
它主要想加速什么¶
从代码结构和初始化逻辑看，当前 CUDA 层更多是围绕“候选点评估”这类问题做加速尝试，比如最佳传球点、最佳射门点、某些空间评分或大规模候选位置搜索。
这类问题的共同点是：单次逻辑不一定复杂，但候选点很多、重复计算频繁，因此天然适合做 GPU 并行化。而像状态机切换、角色注册、pybind 包装这种更偏流程控制的事情，就并不是它的主战场。
在运行时，它和 CPU 回退路径是并存的¶
你在 runLoop() 或 SystemRunner::init() 一类初始化逻辑里，会看到这样的分流思路：
- 如果启用了 CUDA，就初始化
ZCUDAModule； - 如果没有，就走
ZGetBestUtils/ZBestPosCalculate这一类 CPU 路线。
这意味着当前工程在设计上默认接受“同一类能力可以有 GPU 增强版，也可以有 CPU 回退版”。这个取向对比赛工程其实很重要，因为它保证了系统不会因为某一层可选加速不可用，就整套跑不起来。
对新人来说，最实用的理解姿势是什么¶
最实际的理解并不是立刻去啃 CUDA 内核，而是先记住三件事：
第一，CUDA 不是入门主线。你不会因为暂时不懂它，就无法写 Play、改 Skill.py 或看 DecisionModule。
第二，它更接近“高开销评估问题的性能增强层”，而不是“顶层比赛逻辑的组织层”。
第三，它和普通 Play / Skill 开发是弱耦合的。也就是说，大多数时候你可以先把战术逻辑写对、跑顺，再回头决定是否值得为某类计算上 GPU。
真要动它之前，建议先问自己三个问题¶
- 当前构建链路真的启用了
USE_CUDA吗？ - 你改的是比赛主线强依赖功能，还是可选加速增强？
- 如果 CUDA 不可用，系统是否还有明确的 CPU 回退路径？
这三个问题其实很朴素，但它们决定了你是在做“稳定的比赛工程”，还是在把某个局部实验不小心做成全系统单点依赖。
这页更想顺带提醒你：进阶扩展不只有 CUDA¶
对当前仓库来说，真正常见、也更容易立刻产生收益的进阶扩展，其实还有两类：
Pybind11Module/：把更多 C++ 能力安全暴露给 Python；PhysicalModel/和 Python 力度模型工具：把球模型、数据拟合和 GUI 编辑器接进战术层。
如果你的目标是“让顶层开发更顺手、更好调、更好写”，通常先看 pybind 会更划算；如果你的目标是“某一类大规模评估计算太慢”，再考虑 CUDA 会更自然。