本文基于 Rust 官方 Inside Rust 博客于 2026 年 3 月 27 日发布的《Program management update --- February 2026》，作者为 Tomas Sedovic 与 Nurzhan Saken，代表 Program 团队发布。
内容结构概览
- 新成员 Nurzhan 的自我介绍
- 项目目标（Project Goals）推进情况
- 项目管理工作跟踪基础设施建设
- C++/Rust 互操作性
- 签名与镜像（Signing and Mirroring）
- Style 团队近况
- Rust for Linux
- Rust for CPython
- 近期值得关注的资讯
- 数据统计
一、新成员 Nurzhan 的自我介绍
本期月报由两人联合撰写，其中 Nurzhan Saken 是首次亮相，借此机会做了一番自我介绍。
Nurzhan 于 2022 年接触到 Rust 项目，随即陷入深深的痴迷。无论是语言本身、文档、追踪 issue、更新日志、博客文章、演讲，还是用户与贡献者之间的讨论，都让他找到了一种难以言说的共鸣，并在人生中一段艰难的时期给了他莫大的慰藉。作为一个极度内向的人，他长期以来只是观察，从未参与。直到看到项目管理岗位的招聘，他才如梦初醒------正如 Tomas 在第一篇月报中所说，尽管对自己能否胜任充满疑虑，他还是决定投递简历，因为不去争取的遗憾会更令人难以接受。
2025 年 3 月至 4 月，TC 和 Joel Marcey 对他进行了面试并考虑录用，这让他颇为意外，因为他自我感觉彼时状态一团糟。然而如上一篇月报中所述，事情并未按预期发展，他最终没有在那次录用。但他没有就此退缩，而是开始积极参与 Rust 社区，主导稳定了多个他感兴趣的特性。后来，更多经费陆续到位，他终于被正式录用。
入职第一个月对他来说如梦似幻。那道长久以来的无形屏障突然消失，他发现自己开始与那些曾让他深感敬佩的人共处同一空间，甚至开始真正互动。Tomas 在此之前已经留下了令人叹服的成果，看起来难以超越，这很容易让人觉得是不是哪里搞错了、自己是否真的合适。但所有人都给予了热情的欢迎。Tomas 更是竭尽所能地与他沟通、支持他，并把项目中发生的一切都带他过了一遍。正因如此，他已经感到自己基本融入其中，准备充分，并深感幸运，庆幸事情最终朝着这个方向发展。
二、项目目标（Project Goals）推进情况
二月份的工作重心在于逐一审阅所有提案目标，并推动各个团队对其进行评估。目前所有开放的 Pull Request 已全部处理完毕（Nurzhan 在其中提供了巨大帮助），各目标也已根据团队的规模评估和 champion 反馈进行了相应的调整。
每个目标通常会向一个或多个项目团队（例如 Lang、Compiler、Libs 等）提出若干具体请求（ask）。因此，相关团队审查这些请求非常重要------需要确认请求表达是否清晰，以及所提议的变更是否在项目层面具有合理性。
三月份，团队将对每个目标进行最终检查，确认各目标均有合适的 champion 和正确的规模估算。完成这些工作后，将开放一个 RFC，列出所有提案目标，并征求各团队的反馈意见。
这一环节至关重要。在此之前，各目标基本上是被单独审视的；而通过 RFC，所有目标将被放在一起整体审视，各团队可以综合评估自己在整个年度内的实际承接能力。
团队计划在三月内完成 RFC 评审，并于四月初正式开启新的目标周期。
关于目标进展更新方式的讨论
团队也在讨论项目目标更新的呈现方式。目前自动生成的博客文章在可读性和信息量方面仍有较大提升空间，团队希望听取读者的意见：
- 你认为哪些内容有价值？哪些没有？
- 你希望看到什么？哪些内容可能让你分心？
团队正在与 Content 团队探讨如何在单篇博文或访谈中重点呈现特定目标，也在寻找让更新内容更有实质意义的方式。欢迎在 Zulip 博文讨论帖 上留言，或直接私信 T-program alias。
近期发布的目标进展博客回顾：
三、项目管理工作跟踪基础设施建设
随着项目管理工作由两人全职承担，团队专门建立了相应的跟踪机制。
工作看板 ：团队创建了一个待办事项看板，用于追踪所有进行中的工作。rust-lang 组织下任何仓库中的 issue 都可以被添加到这里。
专属仓库 ：由于部分事项（例如安排签名与镜像会议、撰写月度 PM 更新等）并不适合放入现有的任何仓库，团队还创建了 program-team 仓库，用于存放相关文档和工具。
Zulip 联系方式 ：现在可以通过 T-program alias 在 Zulip 上直接联系项目管理团队，无论是 at 一下提个问题，还是提出正式请求都可以。
这些基础设施的建立，旨在让外界更清楚地知道如何与项目管理团队沟通，提高工作透明度（让大家看到团队实际在做什么），同时也帮助两位 PM 之间更好地协调配合。
撰文时，上述仓库和看板都还相对空白，少量来自其他仓库的 issue 可以链接进来，主要还有待 Tomas 将他个人 Rust org-mode 文件中的内容迁移过来。
四、C++/Rust 互操作性
Rust 基金会聘请了 teor 承担一项短期合同，目标是加速梳理 C++/Rust 互操作的问题全貌。teor 一上来便全速推进。
他通读了团队已有的所有相关文档，为每个问题/问题陈述（如"异常与栈展开"、"不兼容的内存分配器"等）创建了一份模板，随即开始系统整理已知问题，并为在两种语言之间进行集成的各类项目所涉及的使用场景提了相应的 issue。
teor 每周在 Zulip 上发布进度更新，每月在项目目标跟踪 issue 中发布月度总结。
这种专注于技术问题全貌梳理的工作方向，是基金会在听取项目成员和更广泛社区反馈（包括直接反馈，以及通过项目董事和项目管理人员传递的间接反馈）之后所作出的决策。
如果你对这个领域感兴趣，欢迎关注 interop-initiative 仓库和 t-lang/interop Zulip 频道。
五、签名与镜像（Signing and Mirroring）
延续一月份的进展，Walter Pearce 起草了一份项目目标草案。该草案聚焦于构建一个 MVP，为 Rustup 的 target 包建立镜像服务。整个过程将在后端完成，对用户完全透明，目标包括：评估带宽与日志成本的降低效果、搭建安全基础设施，并积累实操信息，为最终完整方案奠定基础。
团队在工作组中增加了几位新成员（包括 Rustup 相关人员），草案正在积极讨论中。技术层面和沟通层面仍有一些问题有待解决，但整体方向已较为明确，有望很快开放 PR。
六、Style 团队近况
过去数月，Style 团队的会议因各种原因频繁取消。1 月底，Tomas 重新安排了双周一次的会议节奏，此后已经顺利召开了两次。
在第一次会议上，团队集中处理了所有被提名（nominated）的 issue。鉴于 Style 团队目前只有三位成员，且其中一位近期能够投入的时间有限，TC 提议在借助外部力量的同时，优先确保事项不被卡住。
具体做法是：当一个 issue 提交进来时，Style 团队评估它在现有指南中的位置，然后请提交者给出具体的提案，而不是由团队成员自己从头撰写。这与 Lang 团队的运作方式类似。
过去两次会议明显更有成效，但人手不足的问题依然存在------团队急需更多人参与。
如果你对 Rust 代码的格式化方式感兴趣，希望为 rustfmt 的行为提供意见，欢迎加入 t-style 频道或参加线上会议。
七、Rust for Linux
团队讨论了 Rust for Linux 路线图，并梳理了该项目正在跟踪的、尚未纳入任何具体目标的其他不稳定特性（参见 issue 列表）。这些特性将被纳入路线图，并在适当的情况下推进为独立的项目目标。
一个重要的时间节点
Rust for Linux 有一个重要的里程碑：即将发布的 Debian 14 稳定版（代号 Forky）。Debian 稳定版所附带的 Rust 工具链版本，正是 Rust for Linux 目前用来决定支持哪个最低版本的依据。举例来说，如果 Debian Forky 大约在 2027 年夏季发布，并随附 Rust 1.104.0，那么当内核的 MSRV 在 Debian 发布后某个时间点被提升时，Rust for Linux 就可以使用该版本中的新特性（包括可能仍处于不稳定状态的特性）。
多工具链兼容带来的挑战
Rust for Linux 同时支持一系列稳定版工具链，每个版本只能访问不稳定特性的一个子集（其中一些是项目所依赖的）。这在同一功能以不同形式出现在所支持的各工具链版本中时，会造成兼容性问题。例如，某个特性可能在最旧的版本中完全不可用，在较新的版本中处于不稳定状态，而在更新的版本中已经稳定。部分情况可以在构建时处理（例如某个标志从 -Z... 改为 -C...），但另一些情况则需要非局部的条件编译（意味着要维护并行代码路径）。前者在不升级 MSRV 的情况下通常容易处理，但后者难度大得多，在这类情况下提升 MSRV 有可能显著减轻兼容性负担。为了避免过高的维护成本，团队有时会选择等到下一次 MSRV 升级再采用某个新特性。
下一次 MSRV 升级后最值得关注的特性
团队重点梳理了一旦 MSRV 升级到位就希望尽快使用的、影响最为显著的特性：
- 任意 self 类型（Arbitrary self types）
- 字段投影（Field projections）
- 不可移动类型与保证析构（Immovable types and guaranteed destructors）
- ADT 常量泛型参数（ADT const params）
rustdoc --output-format=doctest- 放宽孤儿规则（Relaxing Rust's orphan rules） ：年内晚些时候，团队计划将单体的
kernelcrate 拆分为多个子 crate，届时将面临孤儿规则的约束。一个思路是在一组 crate（即"一致性域 coherence domain"）范围内放宽孤儿规则。这一设想在 2022 年曾被非正式地提出，并于近期再度被讨论。团队希望通过持续讨论将其正式化（或考虑其他方案）。
整体策略
总体而言，Rust for Linux 希望在 MSRV 允许的情况下尽快开始使用新的语言能力（尤其是涉及新语法的特性），因为在多个工具链版本中同时支持新旧两种写法会带来较大负担，而推迟采用也可能导致日后的大规模重构。
如果新语法可以隐藏在宏后面，通常是可以接受的；类似地，使用不稳定特性也是可以接受的，前提是有合理的预期认为该特性将以大致相同的形式被稳定，或至少不会被移除。
举一个特殊的例子：原地初始化（in-place initialization）。团队对底层问题已经有了可用的解决方案，且存在与最终语言特性集成的潜在路径，因此其缺失并不像字段投影（field projections）那样迫切------毕竟后者目前在任何形式上都尚不存在。
八、Rust for CPython
二月初，团队邀请了 Rust for Linux 的负责人 Miguel Ojeda，请他分享将 Rust 引入 Linux 内核过程中的经验与洞察。
Rust for Linux 的历史回顾
Miguel 回顾了 Rust for Linux 的大致历程：这一努力在 2020 年底开始获得关注，并于 2021 年初提出了 RFC；最小化的实验性支持于 2022 年底合并进内核主线；实验阶段于 2025 年底宣告结束。与 Rust 项目团队的合作始于 2021 年左右，并于 2024 年初过渡为定期会议机制。
面对质疑的应对策略
项目启动之初，将 Rust 引入一个成熟的 C 代码库这件事本身就引发了相当大的质疑。C 语言长期以来是内核的主力语言，而引入额外语言历来都受到阻力------例如 C++ 曾在 1993 年被短暂尝试，随即被放弃。转向双语言代码库的种种弊端，以及让开发者学习一门新语言和工具链的必要性，而这些付出的收益又并不明朗，这些担忧都是真实存在的。
为此，团队花费了大量时间在邮件列表和会议上与内核维护者和贡献者深入讨论，同时跟进公开讨论和各类报道，思考如何更有效地传达他们的立场。2025 年，Miguel 在当年的 FOSDEM 上发表了主题演讲，展示了内核维护者、团队成员、利益相关方以及各公司对 Rust for Linux 的看法（演讲记录）。
RFC 的坦诚叙述与早期成果
在 Miguel 提出的 RFC 中，他们对 Rust 的优缺点都做了诚实的陈述。许多内核专家认为内存安全是最核心的卖点，但 RFC 强调了更多层面的收益：安全代码与不安全代码之间的清晰分隔（前者不存在未定义行为、内存安全违规或数据竞争）、实用的语言特性（富类型枚举、模式匹配、模块系统、卫生宏），以及强大的一体化工具链（rustfmt、rustdoc、lint 工具）。
RFC 以将 Android Binder IPC 机制移植到 Rust 的实现作为初始用例，由此收到的反馈推动了第一批用 Rust 编写的硬件驱动程序的诞生，包括一个 GPIO 驱动的 Rust 翻译版本，并附有与 C 实现的逐行对比。
对 C 侧代码质量的意外促进
团队在推进 Rust 代码时，高度重视代码质量和文档标准，例如要求在每个 unsafe 块周围添加 SAFETY 注释、统一代码格式、对所有公开 API 进行完整文档记录。随着时间推移，这种 Rust 经验也反过来促进了 C 侧代码质量的提升。例如，为了设计 Rust 抽象而重新审视 C 代码时，有时会发现此前未被注意的问题。更普遍地，团队观察到 Rust 中的一些概念开始渗入到对 C 侧代码的讨论和设计中，近期的一个例子就是围绕面向 C 的 Revocable 机制的讨论。
对 CPython 的启示
上述经历与 CPython 开发者的感受高度共鸣，他们在向 CPython 引入 Rust 的过程中面临着几乎相同的反应和技术挑战。这一努力的主要推动者 Emma Smith 和 Kirill Podoprigora 提到，Rust for Linux 的提案对他们启动 CPython 这项工作起到了巨大的激励作用。
Rust 项目乐见这种跨项目的交叉融合，也希望能看到并协助更多项目将 Rust 引入既有代码库。
目前，Rust for CPython 方面的讨论仍在持续，话题集中在构建系统和链接层面。相比项目启动之初，已经走过了大量最迫切的议题，因此会议频率调整为有足够议题时再召开，目前大约每两周一次。
九、近期值得关注的资讯
Rust 基金会文章
Rust 项目动态
- 与 Daniel Almeida 谈用 Rust 编写 Linux GPU 内核驱动：来自 Kangrejos 2025 的访谈
- Rust 1.94.0 正式发布
- 2025 年 Rust 状态调查结果
- Rust 参与 Google Summer of Code 2026
十、数据统计
以下数据反映了 Program 团队的工作量：
- 会议记录总字数（2025 年 6 月 --- 2026 年 2 月）：396,700 字
- 参加会议总场次：45 场
- 2 月份会议记录字数：73,700 字
- 各团队单次会议平均字数 ：
- Cargo：1,600 字
- Lang triage：2,500 字
- Libs-API：4,800 字
- Leadership Council：2,400 字
原文地址：blog.rust-lang.org/inside-rust... 作者：Tomas Sedovic、Nurzhan Saken，代表 Program 团队