微软否认使用人工智能用Rust语言重写Windows 11

微软首席技术官表示，预计到2030年将有高达95%的代码由人工智能生成
💬 95 条评论 | ///|

微软向Windows Latest澄清，公司无意使用比C和C更安全的编程语言Rust通过AI重写Windows 11。但此次澄清并非空穴来风——微软一位顶级工程师曾大胆宣称将用AI取代C/C转用Rust。

“我的目标是在2030年前清除微软所有C/C++代码。我们的策略是结合AI与算法重写微软最大规模的代码库，核心目标是实现’1名工程师、1个月、100万行代码’。” 微软杰出工程师盖伦·亨特在现已编辑的领英帖子中写道。

元素周期表

“在2030年前从微软消除所有C和C代码行”的表述，显然表明这位负责多个大型研究项目的微软顶级工程师所指的是Windows等产品。需要说明的是，Windows的大部分API层代码乃至内核都是用C语言编写的，而C则驱动着部分应用程序。

在该微软顶级工程师删除帖子前，我已截取了原始内容：

图0：微软否认使用人工智能用Rust语言重写Windows 11

原始领英帖子(现已编辑)

坦白说，若非出自微软顶级工程师之口，多数人不会对此认真对待。当这样头衔显赫且资历深厚的员工谈论淘汰C/C++并用AI重写大型代码库时，听起来更像是微软至少在探索的方向，而非随意的想法。

更关键的是，该LinkedIn帖文反复使用“我们”一词，暗示其发言具有公司立场。

针对“2030年前清除微软所有C/C++代码”计划引发的舆论风波，微软向Windows Latest澄清并无此类计划。

微软高管兼传播主管Frank X. Shaw也向Windows Latest确认，公司无意用AI重写Windows 11系统。

最初宣称将用AI以Rust语言替代C/C++的Galen Hunt，随后在领英帖文补充说明：

“我的帖文引发的关注远超预期…引发诸多过度解读… 特此澄清：Windows系统绝非通过AI重写为Rust语言。

*我团队的项目属于研究性质，旨在构建跨语言迁移技术。该帖旨在招募志同道合的工程师参与这项多年期项目的下一阶段工作，绝非为Windows 11+制定新战略，亦不暗示Rust是最终目标。 *”

尽管盖伦·亨特称人们是在“解读字里行间”，但这种反应并非无中生有。他的帖子用极其直白的措辞提及“2030年前淘汰C/C++”、‘运用AI算法重写大型代码库’，并抛出“1名工程师，1个月，100万行代码”的口号。

事实上，这位顶级工程师修改后的帖子仍保留了“1名工程师，1个月，100万行代码”的说法。

正是原始措辞让人们误以为这超出了小规模研究的范畴，但没有人会反对使用Rust。事实上，Rust确实是更优的选择，安全性也远超其他语言。但我们大多数人担忧的是，使用人工智能和算法大规模修改代码。

微软多次公开宣称将用AI编写代码

这并非微软首次确认计划用AI编写自家产品代码。

首席执行官萨蒂亚·纳德拉曾自豪宣称公司30%的代码由AI编写，且这一比例将持续攀升。

“我估计目前我们代码库中约20%-30%的代码，以及部分项目代码，很可能全部由软件生成，”纳德拉在2025年4月Meta首届LlamaCon人工智能开发者大会上解释道。

同月，微软首席技术官表示，预计到2030年将有高达95%的代码由人工智能生成。

Windows 11面临更大问题：WebView2或Electron

正如Windows Latest此前报道，最受欢迎的Windows应用因消耗大量内存而臭名昭著，这主要源于微软自身制定的标准。

图1：微软否认使用人工智能用Rust语言重写Windows 11

例如，Discord承认其Windows应用程序最多可占用4GB内存 Discord基于Electron框架开发，其内存占用问题实际上比WebView2更严重。

基于WebView2的Microsoft Teams在空闲状态下持续占用1-2GB内存。微软可能不知如何降低这类网页应用的资源消耗，因此转而采取将Teams通话功能迁移至独立进程以减少崩溃的策略。

但Teams并非唯一在内存价格即将飙升时引发问题的网页应用，WhatsApp同样存在类似问题。WhatsApp初登Windows平台时采用Electron框架开发。但Meta后续将其升级为WinUI/XAML(即Windows原生代码)，最终使WhatsApp跻身最佳应用之列。

诚然，原生版WhatsApp并非完美无缺，但其内存占用低于200MB，动画更流畅，加载速度更快。遗憾的是，Meta在裁员中解散了原生客户端开发团队，并用基于WebView2的解决方案取代了WhatsApp，其内存占用量是旧版原生客户端的七倍。

图2：微软否认使用人工智能用Rust语言重写Windows 11

基于Chromium的WhatsApp内存占用达UWP版7倍

但若以为“网页垃圾”问题仅限于这些应用，那就大错特错了。

Windows Latest近日发现微软已开始使用WebView2构建部分Windows 11功能。更近期的观察显示，即将推出的“日程视图”功能(可在通知中心查看Outlook日程)同样基于WebView2构建。

这意味着当启用日程视图并打开通知中心时，你将发现新的Edge相关进程占用高达100MB内存。

议程视图功能曾在微软推出Windows 11时被移除，现因用户强烈要求而回归。但与Windows 10版本不同，新版议程视图采用基于网页的实现方式。

我认为引入人工智能并不会让Windows变得更好。真正需要改变的是管理层的意图，而我怀疑这种转变永远不会发生。

元素周期表抱枕

共有{95}条精彩评论

  1. 这篇领英原文真是够离谱的。真不知道他写这篇之前是不是嗑了大剂量可卡因，还是说这居然是经过周密策划的具体方案。

    回复

    1. | 我的目标…

      稍后

      | …我们的…

      我认为盖伦重写所有C/C++代码的目标是他个人的，而非微软的。

      回复

    2. 作为2030年的目标，这似乎不算离谱。志存高远

      回复

      1. 重写微软数千万甚至上亿行原生代码只需四年，这在你听来不算疯狂？

        回复

        1. Windows的衰落终将催生Linux桌面崛起，Omarchy的流行趋势和良好反响已初现端倪

          回复

          1. 又一个不知由谁维护、不知打过哪些补丁的发行版，几年后就会失去支持？才怪。

            回复

        3. “别出错”的话，几天就能搞定…

          回复

        4. 不？他们要用AGI代理重写所有Rust代码。听起来不错。

          回复

            1. 不，我们有AGI。我们缺的是ASI。

              回复

                1. 山姆·阿尔特曼说这是真的。

                  回复

                  1. 那个没AI就养不活孩子的家伙？这种事我才不信他的意见。

                    回复

                    1. 他说的有道理。首先，有了AI家教就过时了。

                    1. 说不定他用AI查的

          2. 炒作泡沫最糟糕的点在于，我真的分不清别人是不是在开玩笑了。

            回复

            1. 我明明用了“驾驭力量”这种专用于胡扯的套话，你难道没听出讽刺意味？

              回复

              1. 确实多半是胡扯，但在炒作泡沫中，很多用这个词的人根本没意识到自己在胡说八道，还当真了。

                回复

      2. 它依然荒谬，因为基本毫无用处。重写几个核心组件或许能稍微提升安全性，但对终端用户而言毫无改变。这正是无聊程序员缺乏产品和商业视野时惯用的套路——华而不实的项目。

        回复

    3. >真是荒唐

      为何疯狂？社交媒体上充斥着人们错误预判最终目标需要手动阅读百万行代码的言论。这更像是人们编造理由发泄怒火或试图贬低作者。

      回复

      1. 大型语言模型会产生大量安全隐患和漏洞。仅凭“Rust”特性无法自动解决问题。生成如此海量代码意味着完全无法人工审核。这怎么可能不导致灾难性后果？

        回复

        1. 人类编写的代码才真正制造了更多安全隐患和漏洞，人类编程怎么可能不导致灾难性后果…

          回复

          1. 所以AI既基于不安全且漏洞百出的人类代码，又无法独立思考？当然，到2025年……不，2027年，它就会为我们所有人编程。

            回复

          2. 你有可供查阅的研究来验证其方法的有效性吗？

            如果没有，看，我也能告诉你我的观点：不，你说的完全错误。

            回复

            1. 你有研究能让我们读到并评估数百万软件工程师编写代码的方法有效性吗？如果没有……？

              回复

      2. 如果你“产出”百万行代码(相当于每个工作日5万行)，却不阅读它们，那更糟糕。

        回复

      3. 我理解的意思是：每位工程师每月重写百万行代码，并用机器学习处理繁重工作。

        这简直疯了。即便把所有代码审查工作都推给其他团队，也绝对不可能完成规范审查。

        回复

        1. 开发速度终将放缓。生产环境中处理边界案例时增删几行代码，或是回溯修复错误变更，都会消耗大量时间。

          回复

        2. 你说的没错，代码风格、清晰度和连贯性确实无法有效审查。但正确性方面，Windows以坚持数十年级别的向后兼容性著称，这必然需要高度自动化的保障机制。

          作为2000年代末的第三方开发者，我记得老板曾给我一整套微软历代操作系统光盘资料夹(是单个还是多个？)。想必是微软开发者关系代表提供的。我和团队用它确保代码能在所有目标MS-DOS/Win*平台上运行。

          我推测Windows团队内部拥有海量资源，足以构建史上最全面的回归测试套件。至少在这种层面上，即便不阅读代码本身，也能判断Rust版本是否实现了旧代码的功能。

          回复

          1. 不过说句公道话，Windows向来以坚持数十年级的向后兼容性著称，这必然需要高度自动化的实现机制。

            但几十年来，这早已不是主要目标了。

            例如《孤岛危机》在Win10及更高版本系统上根本无法运行。

            更何况安全漏洞这类问题，在无人有精力实际审查的重写过程中，根本无法靠自动化解决。

            回复

        3. 凭什么认为近期添加到Windows的现有代码经过了任何人审查？这可是连续两次更新就搞砸开始菜单和登录界面的公司。

          回复

          1. 我听过微软内部人士透露的内幕。

            他们确实仍在审查代码，但2022年第一轮裁员主要针对首席工程师及以上职位——因为某些财务人员宣称“这些工程师的人均成本最高”，如今简直是疯人院里疯子当家。

            我认为他们最大的罪过在于：自90年代末起的代码总带着20%的过度精巧。这印证了那句经典调侃——调试代码耗费的脑力是编写时的两倍，若编写时已竭尽全力，那调试时便更显力不从心。这正是功能看似发布1.0版后，往往直接被替换而非迭代改进的半数原因(另一半则是FAANG式的内部激励机制)。

            我们目睹的正是他们清理内部“武器化自闭症”的后果——这种病态思维曾勉强维系着公司运转。他们虽有代码审查机制，却已丧失大规模有效审查的能力。这使得重写全部代码的决定显得更加疯狂。

            回复

          2. 还有那家因开始菜单广告导致界面卡顿的公司，他们的“解决方案”竟是预加载冗余代码。

            回复

        4. 抱着这种思维，恐怕连升级C++编译器工具链都觉得不可能——毕竟代码生成机制可能发生各种变化。如今这已是常态，同样存在技术层面所有代码可能受影响的问题，但实际操作并非通过人工逐行审查来实现。

          回复

          1. 升级编译器版本与用其他语言重写代码之间存在着几乎无法估量的差异。

            回复

            1. C编译器将C代码转换为汇编语言。本项目旨在将C++转换为另一种语言，其概念本质并无二致。

              回复

              1. 从高级语言向低级语言转换远比不同高级语言间的转换更为直接。

                此言并非贬低编译器的价值，但本质上是将复杂形式还原为语义可控的构建模块。

                改变高级语言会引入根本不同的语义。虽然两者都能分解为相同的通用构建块，但组合方式未必相同。

                最简单的例子是：编译器后端(你描述的部分)无法处理数据访问规则。这是语言编译器前端的领域，也是C++与Rust之间无法直接推导的根本差异。

                回复

              2. 编译器不会采用复杂到终生钻研也无法理解的语言统计模型进行翻译，它遵循标准翻译规范。若你足够重要(微软内部团队对MSVC就是如此)，还能提前获知具体变更内容以便定位问题。

                这简直是泡沫顶峰时常见的“把Postgres数据库搬上区块链，因为我觉得区块链很酷”级别的垃圾。

                回复

          2. 所有C开发者都遵循统一的C标准，新版本通常兼容旧版，无论工具链版本如何。工具链行为不应改变。最坏情况下，若真出现行为变更，可借助确定性可靠工具自动检测问题位置(例如编译器警告/错误)。

            AI代码生成具有非确定性且无法保证行为一致性，因此除非容忍错误代码，否则必须进行人工审查。

            回复

            1. >AI代码生成具有非确定性

              代码生成工具不必依赖AI技术，或可要求提供等效性证明来验证生成的代码。

              回复

  2. 初始帖文指出：

    > 我的目标是在2030年前彻底清除微软所有C和C++代码。我们的策略是结合人工智能与算法重写微软最大规模的代码库

    后续补充说明：

    看来我的帖子引发的关注远超预期……还引来诸多字里行间的揣测。在此澄清：Windows系统并非正在用Rust语言配合人工智能进行重写。

    所以要么他根本不认为Windows是用C/C++编写的，要么他觉得这不属于“微软出品”，要么他根本不懂“字里行间”的含义——因为这些字面意思正是他所说的。当然他也提到“以及算法”，但我认为要推断出这构成重大差异，恐怕需要更深的字里行间解读。

    或许他还能狡辩说“消除微软所有C和C++代码”指的是编写新代码而非保留现有代码——但这种解读既违背多数人的理解逻辑(若我说要消除地球上所有水，没人会认为我指的是消除雨水却保留海洋)，从技术角度看也颇为牵强 (毕竟保留现有Windows代码库原样，几乎不可能完全避免偶尔需要用原有语言编写新代码的情况)。

    回复

    1. 我的目标是重写每一行C/C++代码。

      我的目标。不是微软的，也不是SpaceX的，更不是…

      当盖伦说“我的目标是…”时，我认为这是字面意思，但属于理想化的追求。

      回复

  3. 他们不得不否认这件事本身，意味着这种荒谬说法已被广泛视为可信——这恰恰反映了他们的声誉。

    回复

    1. 最近用过微软软件吗？自从几年前他们裁掉测试团队后，我在工作中发现的回归问题简直多得离谱。

      回复

      1. 测试团队裁撤的事都过去十年了。

        回复

    2. 不，这只是说明人们过度解读了LinkedIn上那些随机的猜测性帖子。

      回复

      1. 我不理解这种观点。根据本帖讨论内容，谁能说网友对帖子解读过度？微软资深工程师公开宣称要用AI重写/替换所有C/C++代码转用Rust，这不正是评论区反应的核心内容吗？没人过度解读，纯粹是直白解读。尽管帖子因引发关注而被编辑过，但仍明确表示其团队目标是“1名工程师，1个月，100万行代码”。

        更何况这并非随意猜测的帖子，而是发布者团队的职位招聘公告。

        回复

        1. 微软拥有数千名资深工程师，其中一人参与此项目并可能招聘少量人员，并不等同于公司层面的整体规划。

          回复

          1. 确实如此，人们过度强调他的帖子，仿佛它代表了微软未来的目标和政策。从帖子夸张的语气来看，他竟只是个研究团队负责人，这让我有些意外。

            我承认写评论时没考虑到这点，但仍觉得讨论微软看似头脑发热地投入大规模AI代码生成领域很有趣——即便这重要性远不及CEO发帖时那般重大(甚至可能毫无意义)。

            回复

          2. 他并非普通高级工程师，而是杰出工程师。其薪酬待遇堪比总监或副总裁级别，绝非数千名高级工程师中的一员。

            回复

    3. 要知道，当年最终演变为Windows Vista的系统曾计划采用以.NET为基础的用户空间架构，甚至还有个开发.NET内核的项目。微软搞些明显行不通的怪异项目，倒也不算难以置信。

      回复

    5. 可惜他们不是谷歌——要是能在愚人节宣布这个消息，万一反响不佳还能声称只是个玩笑。

      回复

  4. 要不是Rust的公关圈总让人联想到某些我早已免疫的全能网络势力，我或许会对Rust这门语言更感兴趣。我并非指认他们就是那些挖隧道发射卫星的同一群人，只是我的免疫系统被激活时，总觉得他们就是。

    回复

    1. 本以为知道这条评论要说什么，结果它越说越离谱。

      千万别让他们用编程语言给你的系统接种计算机病毒疫苗。

      祝好运。

      回复

  5. > 我们的北极星目标是“1名工程师，1个月，100万行代码”

    有人能解释这个吗？他们是在暗示(最终)一名工程师能在一个月内产出100万行Rust代码？还是说要替换100万行C代码？

    使用全新的“强大代码处理基础设施”……但它能理解语义吗？这些语义是否已明确记录？

    回复

    1. 我的解读是：用Rust™重写整个微软原生语言代码库，但由AI承担重写的主力工作。不过重写中最繁重的是代码审查环节，希望他们不会主要依赖机器学习来完成这项工作。

      回复

      1. 他们很可能也会用AI审查代码，拜托，我们讨论的是微软啊

        回复

    2. 这不过是反应式夸大营销的口号，艾伦·凯曾嘲讽商务舱高管们热衷此道。

      有篇关于seL4的论文提到：某耗时12年完成的工程项目，每行源代码成本高达350美元，其代码质量才勉强达到QNX的预期标准。

      回复

    3. 这句根本说不通。项目中的人工智能应用是二元选择(要么需要人工，要么不需要，不存在三人团队适用而两人团队不适用的情况)。况且我们现在几秒/几分钟就能一次性生成极其复杂的应用程序。为什么生成百万行代码居然要耗费整整一个月？

      归根结底就是AI编写百万行代码的问题。

      我认为它现在可能已经能处理大量模板代码了。

      回复

  7. 这整个事情简直滑稽可笑。

    当萨蒂亚·纳德拉种下的恶果开始显现——Windows就是最明显的例子，他们的大部分AI项目也即将步其后尘——嘲笑他们的愚蠢倒成了某种安慰奖。

    微软过去犯过无数错误，但他们曾拥有绝对的市场统治力，以及庞大的人才库和知识储备，足以支撑他们东山再起。时移世易，许多人已退休或被裁员，为下一批以合同工形式出现的“廉价年轻”人才让路。

    如今他们押注云计算，我不确定Windows部门这次能否扭转乾坤。Xbox早已成为预警信号。

    回复

    1. Xbox本可成为游戏行业的地震级产品，却因执行不力而功亏一篑。此番裁员正是为了平息市场风波。

      微软其他部门恐将步其后尘。此刻我终于体会到1989年凝视IBM时的感受。

      回复

        1. 正是这台IBM。1989年，他们掌控着个人电脑市场。那本是他们的天下。尽管裂痕日益加深，IBM本可维持行业领导地位直至今日。然而他们过度压榨，导致个人电脑市场从铁腕掌控中滑落。

          IBM至今仍存续且地位重要的事实无关紧要。他们失去了对事实上的计算标准的掌控权。微软同样可能失去控制权。

          回复

          1. 或许吧，但市场也在变迁。企业需要进化。旧产品逐渐淡出舞台，新商品与服务应运而生。如今他们的公司价值已达历史巅峰。

            我不确定是否愿意看到IBM持续掌控如此庞大市场的世界——那时的开放生态系统恐怕会小得多。

            回复

            1. 没错，但微软如今面临同样处境。若他们失去PC市场控制权，只会让局面更趋完善。

              回复

              1. 我的意思是，十多年前关于微软的传闻是他们放弃操作系统，全面转向基于云的SaaS模式。本质上就是将精力集中在利润所在之处。

                回复

        2. 空谈无益。等“将要建造”变成“已建成”时，请提醒我这句话。

          回复

          1. 若你所在的摩根大通或航天企业正在使用量子计算，极大可能采用的是IBM Heron 156量子位可扩展计算机。他们已持续向大型企业推广量子计算机多年。

            谷歌目前仍处于纯研究阶段，但正在开展大量扎实的工作。

            回复

    2. 能否举例说明雇佣“廉价年轻”合同工开发产品功能的具体案例？你似乎掌握大量信息，具体案例或许更有说服力。

      回复

    3. > 时代变迁，许多人退休或被裁员，为下一批以合同工形式出现的“廉价年轻”人才让位。

      摘录自上文：

      基于WebView2的Microsoft Teams在闲置状态下持续占用1-2GB内存。微软可能尚未掌握优化这些网页应用资源消耗的技术，因此转而将Teams通话功能迁移至独立进程以降低崩溃率。

      但当内存价格即将飙升之际，引发问题的网页应用不止Teams，WhatsApp同样如此。WhatsApp初登Windows平台时采用Electron框架开发。但Meta后来将其升级为WinUI/XAML(即Windows原生代码)，最终使WhatsApp成为内存占用低于200MB、动画更流畅、加载更快速的顶级应用之一。"

      如今多数开发者似乎专注于Web专属技术，试图将桌面级和系统级程序强行纳入这一范式。

      如今掌握C、C++和C#的程序员难道比凤毛麟角还稀少？

      高校是否已不再教授这些语言？这是否是“云优先”战略的症结——因“直接用JavaScript搞定一切”更省事，抑或源于开发者懒于学习另一门“底层语言”？

      我实在不理解JavaScript和TypeScript这类以网页为中心的语言为何能在桌面和系统领域吸引开发者——它们既缺乏标准库(这点令我真正感到恐惧：供应链攻击…)，又可能加剧内存消耗问题(开发者为弥补某个库缺失的功能不断堆砌依赖包)，更无法原生编译成不依赖运行时环境或臃肿解释器的精简二进制文件。

      诚然C#在.NET中也存在类似缺陷，但至少它拥有由企业(尽管微软有诸多问题)而非网络散户维护的完整标准库。

      https://xkcd.com/2347/

      微软允许Windows 11核心组件用Web封装重写的做法，只会随着内存价格危机持续，进一步将用户推向Linux阵营。

      回复

      1. Electron应用确实是资源消耗大户，但这并非团队表现糟糕的根源。正如XAML并非WhatsApp应用优秀的理由。

        开发者投身Web领域，只因那里才是金矿。谁愿意踏上桌面应用这条收入微薄且日渐式微的道路？

        同样地，我认为UI设计应当采用声明式方法。许多桌面UI框架采用过程式编程，这不仅拖慢UI开发效率，其规模和支持力度也远不及React等框架。

        更何况硬件性能持续提升。若无人抱怨性能问题，自然缺乏优化动力。少数技术人员高呼Electron应用占用资源过多，并不能定义何为高效。

        回复

        1. > 少数技术人员高呼Electron应用占用资源过多，这并不能决定何为高效。

          难道只有技术人员才受限于内存容量？

          回复

      2. 我感觉随着AI辅助开发普及，这种“云优先”策略只会愈演愈烈。我注意到个人用AI辅助的C#项目复杂度远超使用JS框架时。

        若非高校所致，那AI在JS/TS领域的训练水平绝对更胜一筹。

        回复

      3. 因为JavaScript能让开发者周末在Hetzler上搞个SaaS就成亿万富翁。

        这套说辞已经灌输十五年了。

        回复

  8. 发展到这种地步实在荒谬可笑

    回复

  9. 我怀疑这篇帖子是否充满讽刺。难道是某位沮丧工程师对高层管理层期望的投射？

    回复

  11. 真搞不懂大家为何如此沉迷网络关注这事。就像Rust在Linux上也是长久之计，预计10-20年内内核大部分代码都会用Rust编写。显然这篇帖子是在炫耀，本质上是招聘广告。他们可能真因此招到几个靠谱候选人。

    回复

    1. 将Rust引入内核合情合理。但要求工程师每月移植百万行代码简直疯狂——无论用何种语言(按总计约600毫秒/行计算，含代码审查、测试等环节)。任何听闻此要求还觉得合理的人，都算不上合格候选人。

      回复

        1. 仅仅因为某件事有益，并不意味着它会被社区采纳。我的问题是(这也是我目前最感兴趣的)：究竟是什么让Rust的普及不可避免？是否有人为此付费推动？内核级安全漏洞是否已严重到必须紧急迁移到Rust的程度？你明白我的意思吗？

          (再次澄清：我并非质疑任何人。只是世上编程语言数以百计，Rust也存在多年，为何偏偏是现在？回到最初的问题——究竟是什么让它的普及成为必然？)

          回复

      2. 好问题，其实不然。你不过是在回应又一个自诩能预见未来的Rust和/或LLM狂热分子罢了。这种人在这论坛上多如牛毛。

        回复

          1. 抱歉戳破你的幻想，但Linux的诞生可不止靠Linus一人。

            回复

        2. 嘿，别把Rust狂热分子和LLM兄弟们混为一谈。一个是安全的编程语言，另一个不过是长大的Lorem Ipsum文本生成器。我们可不一样 🙂

          回复

          1. 你们俩被扔进同个托儿桶的事实，值得你们深思。

            回复

            1. 没错，我停下来评论了，然后就走开了

              回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

你也许感兴趣的：