指导委员会关于JIT项目的公告
一句话看懂：Python 指导委员会正式要求社区为 CPython 的实验性即时编译器（JIT）撰写一份标准流程 PEP，在通过之前停止新增开发，否则六个月后 JIT 代码将从主分支移除。这意味着 JIT 从实验性功能走向正式特性的节奏被强制标准化。
事件核心：发生了什么
Python 指导委员会于近日发布公告，针对 CPython 主分支中已存在多年的实验性 JIT 编译器做出正式裁定。委员会承认了开发者的技术成果，但明确指出当前 JIT 仅靠一份信息性的 PEP 744 进入仓库，缺乏正式的标准流程 PEP 来定义其维护承诺、安全审查、调试支持、对下游打包方的义务等关键问题。委员会要求社区在六个月内提交一份标准流程 PEP，由委员会正式批准或拒绝。在此期间，除 bug 修复和安全更新外，禁止在 main 分支上添加新的 JIT 功能、优化或性能工作。若六个月内无 PEP 被接受，JIT 代码必须从主分支移除。
为什么重要
这一决定直接影响了 CPython 未来数年的性能演进方向。JIT 编译是 Python 性能优化的关键路径之一，实验阶段在 main 分支上已经经历了多次架构重写。指导委员会通过流程约束，实际上是在要求项目方明确 JIT 的长期维护责任、兼容性保障（包括自由线程、调试器、分析器等已有特性）以及性能目标（如具体提升倍数、平台覆盖范围、内存开销）。这也为第三方 JIT 实现（如 CinderX、Numba、PyTorch）提供了明确的交互接口预期——委员会暗示 JIT 基础设施应支持多种追踪策略，而非绑定单一方案。简言之，这是一次从“代码先行”到“提案先行”的治理升级，影响 Python 生态底层的开发节奏和合作方式。
对用户/开发者/创作者的影响
对于普通 Python 开发者，短期内不会感受到变化——JIT 目前仍是实验性功能，未默认激活。但若 PEP 未通过或 JIT 被移除，未来版本（如 Python 3.14 或 3.15）的性能提升幅度可能低于预期。对于 CPython 核心开发者、第三方库维护者以及下游打包方（如 Anaconda、Linux 发行版），需关注 PEP 中关于长期维护的承诺：JIT 子系统复杂度极高，若没有明确的人员和资金承诺，维护负担可能转嫁给现有核心开发者。对于使用 Python 做 AI 推理或高频计算的用户，应同时评估 CinderX、Numba 等外围 JIT 方案作为替代或补充。
值得关注的后续
1. 谁将在六个月内牵头撰写这份 PEP，以及是否能覆盖委员会要求的所有点（维护计划、兼容性、成功指标、第三方 JIT 关系）。2. 如果 PEP 无法达成共识而被拒绝，CPython 团队是否会采用替代方案（例如支持多种 JIT 后端的基础设施），或者彻底放弃主分支内建 JIT 路线。3. 社区讨论可能重新激活是否应将实验性开发移至 feature 分支或外部仓库的长期争论，这会影响未来大型功能的集成流程。
