AI - Tony Bai

本文永久链接 – https://tonybai.com/2025/09/14/code-complete-with-steve-mcconnell

大家好，我是Tony Bai。

二十年前，Steve McConnell 的《代码大全》(Code Complete 2nd) 以其近 900 页的体量，成为软件工程领域一座难以逾越的丰碑。二十年后，它依然是无数工程师书架上的必备经典。在一场深度的访谈(https://www.youtube.com/watch?v=iPKmcLxuS_A)中，McConnell分享了这部巨著背后的故事、对职业发展的深刻洞见，以及对 AI 时代的冷静思考。

尽管技术浪潮已更迭数代，但 McConnell 的核心思想依然闪耀着永恒的光芒。我从中提炼出三大“启示”，它们穿越了语言和工具的变迁，直指软件开发的本质，为每一位追求卓越的工程师提供了清晰的行动指南。

启示一：“软件构建”远不止编码，它是专业性的基石

访谈中，McConnell 反复强调一个核心概念：他所著述的领域是“软件构建” (Software Construction)，而这远不止我们通常理解的“编码” (Coding)。这是一个至关重要的区分，是从业余爱好者迈向专业工程师的第一道分水岭。

软件构建是一个广阔的领域，它涵盖了详细设计、编码、调试、测试集成、可读性与长期维护等一系列与代码紧密相关的活动。

在 McConnell 看来，只关注“编码”的工程师，如同只知道砌砖的建筑工人；而懂得“软件构建”的工程师，则是在思考整面墙的结构、承重与美学。

这意味着，在你编写每一行代码之前和之后，都需要思考：

设计：这个函数或类的内部结构是否清晰、易于理解？
验证：我将如何测试这段代码，以确保它的正确性？
可读性：几个月后，我自己或同事还能轻松读懂这段代码吗？
维护性：我的实现是否为未来的修改和扩展留下了空间？

这个启示提醒我们，卓越的软件并非代码的堆砌，而是深思熟虑的“构建”过程的产物。

启示二：战略性构建你的生涯，而非随机“跳荷叶”

在访谈最发人深省的部分，McConnell 分享了他对抗职业生涯随机性的强大心智模型：“职业金字塔” (Career Pyramid) vs. “跳荷叶” (Lily Pad Hopping)。

“跳荷叶”：工程师们从一个项目跳到另一个项目，看似在不断学习新技术、接触新业务，但这些经历是零散的、不连贯的。年复一年，知识面变广了，但核心价值并未实现质的飞跃，因为这些努力“没有累积成任何东西”。
“职业金字塔”：这是一种战略性思维。将职业生涯视为一座需要亲手建造的金字塔，每一次选择——无论是学习一门技术，还是参与一个项目——都是在为这座金字塔添砖加瓦。所有努力都服务于一个长远目标，层层叠加，最终形成一个深厚、独特且极具价值的能力体系。

这个启示提醒我们要时常自省，有意识地规划你的成长路径，让每一次努力都成为你“职业金字塔”的一部分。

我当前的工作，是在随机跳向下一片看似新奇的荷叶，还是在为我的金字塔奠定坚实的基础？
我应该学习什么，才能让我的能力体系更加稳固和高耸？
McConnell 给出了一个终极评判标准：“这个选择，能让我对我的组织或整个世界变得更有价值吗？”

启示三：AI 时代，工程师的终极价值是追求“完全正确”

面对 AI 能快速生成代码的现实，McConnell 并未表现出焦虑，反而给出了一个极其深刻的洞见，精准地定义了人类工程师在未来的核心价值。

他引用了 Fred Brooks 的“本质复杂性” (Essential Complexity) 概念，指出软件工程的真正挑战，在于处理由真实世界的混乱所带来的无数异常和边界情况。

“编程，我们不能做到‘近似正确’ (approximately right)，我们必须做到‘完全正确’ (exactly right)。”

AI 或许能高效地处理“近似正确”的部分——即生成“快乐路径” (Happy Path) 的代码。但这恰恰凸显了人类工程师的价值。

这意味着工程师的角色正在演进，目标是成为“完全正确”的最终守护者，具体来说，我们要：

从代码的创作者，到质量的审查者：我们的核心职责，是审查 AI 生成的代码，并用我们的经验和洞察力，去发现并修复其中所有微妙的、潜在的错误。
从执行者，到需求的诠释者：将模糊的业务需求，转化为精确、无歧义、能够指导 AI 的技术规格，这本身就是一种不可替代的高级智力活动。
从实现细节，到系统思考：将精力更多地投入到更高层次的“构建”活动中——架构设计、模块划分、API 契约定义，以及对系统长期健康度的深思熟虑。

小结

McConnell 的访谈如同一座灯塔，为在技术浪潮中航行的我们指明了方向。这三大启示——将编码提升为构建，将工作升华为事业，将价值定位于正确。无论工具如何演变，对质量的追求、对成长的规划、对责任的担当，将永远是定义一位卓越工程师的真正标尺。

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/09/11/microsoft-is-getting-rusty

大家好，我是Tony Bai。

近日，微软 Azure CTO、技术巨擘 Mark Russinovich 在一场 Rust 技术会议上发表了闭幕演讲，以前所未有的坦诚和力度，揭示了微软内部正在进行的一场深刻的技术变革：全面拥抱 Rust，并战略性地替代 C/C++。

他不仅分享了 Rust 在 Windows 内核、Office、Azure 云等核心产品中的惊人实践案例，还首次披露了微软正在研发的、利用 AI 大模型自动将 C/C++ 代码转换为安全 Rust 的前沿工具。这既是一次技术分享，也是一份来自行业顶层的宣言。

在这篇文章中，我们就来看看微软在走向Rust的路上究竟做了哪些工作和改变，用户和社区的反馈又是如何。

战略驱动：为何微软必须转向 Rust？

演讲开篇，Mark Russinovich 就抛出了一个触目惊心的数据，这也是驱动微软进行这场变革的根本原因：

在过去十几年中，微软所有产品中 70% 的安全漏洞，均由 C/C++ 中的内存安全问题导致。

他直言，这种趋势仍在继续，这已不仅仅是技术债，更是持续不断的安全事件和威胁。正是基于此，他个人早已成为 Rust 的坚定拥护者，并分享了一段有趣的往事：2022年，他在看到编程语言排行榜后，有感而发地发布了一条推文——“是时候停止在任何新项目中使用 C/C++ 了，业界应该转向 Rust”。

这条推文成为了他有史以来互动量最高的内容，甚至引来了微软 CEO Satya Nadella 的电话询问。而他的回答坚定不移：“是的，我坚信如此。”

这并非一时冲动，而是一场席卷微软的、自下而上与自上而下相结合的运动。从美国国家安全局 (NSA) 呼吁业界放弃内存不安全的语言，到微软自身因不安全代码被攻击后发起的“安全未来倡议 (Secure Future Initiative)”，微软上下已经形成共识：必须摆脱不安全的语言。

实践版图：Rust 在微软核心产品中的落地生根

Mark Russinovich 随后详细介绍了 Rust 在微软内部的实践版图，其广度和深度令人瞩目。

Windows：从内核“阿喀琉斯之踵”开始

Project Mu (UEFI 固件): 微软选择从安全性要求极高的系统引导固件入手，用 Rust 重写了 UEFI 实现（Project Mu）。该项目已应用于 Azure 数据中心和 Surface 笔记本，并已开源，旨在推动整个硬件生态采用 Rust。
DirectWrite (核心图形组件): 团队选择了一个漏洞频发的独立组件——负责字体解析的 DirectWrite 进行移植。两名开发者耗时六个月，将 15.4 万行 C/C++ 代码移植为 Rust。结果不仅消除了安全隐患，还意外获得了 5% 到 15% 的性能提升。
Win32k.sys (GDI 模块): 这是 Windows 安全的“阿喀琉斯之踵”，过去20年间漏洞不断。微软选择用 Rust 重写了其中的 GDI Regions 子系统。两名开发者耗时三个月，移植了 6.3 万行 代码进入内核态。尽管 C++/Rust 的互操作边界带来了巨大挑战，但项目最终成功，且没有性能衰退。如今，在 Windows 系统目录中，你甚至能找到带有 _rs 后缀的内核模块文件。

Office 与 Azure 云：性能与安全的双重胜利

Office (DISKANN 向量搜索): Office 团队将一个前沿的向量搜索算法（DISKANN）从 C++ 移植到 Rust，用于 Office 365 和 Azure Cosmos DB。结果是惊人的：在实现同等 QPS 的情况下，召回率显著提升，内存占用反而下降。
Azure (CTO 的铁腕): Mark Russinovich 透露，早在发布那条著名推文的两三年前，他就已在 Azure 内部颁布指令：“Azure 中不再有新的 C++ 系统代码”。这一指令推动了 Rust 在 Azure 基础架构中的全面应用：
- 硬件层面: 云服务器的开源可信根项目 Caliptra、深入每台服务器的 Azure Integrated HSM 硬件安全模块，其固件均由 Rust 编写。
- 硬件卸载卡: 负责网络和存储处理的智能网卡（DPU）上的新组件，已全部使用 Rust 开发，部分已有 C++ 组件也被迁移到了 Rust。
- 虚拟化: Hyper-V 的 Arm64 模拟代码已用 Rust 重写；最近开源的 Open VMM（一个准虚拟化监视器）完全由 Rust 构建；而革命性的 Hyper-V Lite 项目，能以微秒级速度启动一个超轻量级虚拟机来运行 WASM 负载，其原型虽为 C#，但最终的开源实现完全是 Rust。
Azure 服务:
- Azure Data Explorer (ADX): 这个每天处理 PB 级数据的日志分析平台，其 V2 版本后完全用 35 万行 Rust 代码 重写，性能超越 C++ 版本，成为微软内部 Rust 实践的标杆案例。
- Azure SDK for Rust: 顺应客户需求，Azure 官方已发布了 Rust SDK 的 Beta 版本，标志着 Rust 正式成为 Azure 的一等公民语言。

真实反馈：来自一线开发者的收获与挑战

这场变革并非一帆风顺。Mark Russinovich 坦诚地分享了一线开发者的真实反馈：

** 收获 (The Positives):**

“如果它能编译，它就能工作”: 这是开发者们提到最多的一点，与 C++ 编译通过后仍充满不确定性的体验形成鲜明对比。
减少摩擦，专注创新: 消除了内存安全和数据竞争等底层心智负担。
“两个月的转变”: 一个常见的模式是，C++ 开发者最初会对所有权和借用检查器感到痛苦，但大约两个月后，他们会转变为 Rust 的忠实拥护者。

** 挑战 (The Negatives):**

C++ 互操作性是第一大难题: 在逐步替换大型 C++ 项目时，处理两种语言的边界问题耗费了大量精力。
工具链仍有待成熟。
Crate 生态系统: 开发者不确定应该使用和信任哪些第三方库。
部分依赖的特性尚未稳定。
动态链接: 在 Windows 生态中常见的动态链接，与 Rust 的结合存在问题。

尽管存在这些挑战，但 Mark Russinovich 强调，优点已经足够让微软“全身心投入 (all in)”。

展望未来：用 AI 加速 “去 C++” 进程

演讲的最后，Mark Russinovich 揭示了微软正在探索的、旨在加速 Rust 迁移的“终极武器”——自动化代码翻译。

微软正在从两个方向推进这项工作：

专用转译器 (Transpiler): 针对特定领域，如经过形式化验证的加密库。微软研究团队已开发出一个工具，能将严格遵循特定规范的 C 代码自动、安全地转译为 100% safe 的 Rust 代码，并确保其数学验证在转译后依然有效。
通用 AI 翻译器 (GenAI + GraphRAG): 这是更宏伟的目标。传统的 LLM 在处理多文件、复杂的 C++ 项目时效果不佳。微软正在利用一种名为 GraphRAG (图检索增强生成) 的先进技术。该技术能将代码解析为抽象语法树，并构建一个多层次的、包含代码摘要和依赖关系的图谱。当进行翻译时，AI 可以基于这个图谱进行更精准、更具上下文感知的代码生成。

他现场演示了一个将多文件 Python 小游戏翻译为 Rust 的例子。普通的 GPT-4o 生成的代码无法编译，而 GraphRAG 驱动的翻译器则一次性生成了可完美运行的、100% safe 的 Rust 代码。