为什么 C++ 在 AI 时代仍然击败 Rust
简介
关于编程语言的争论往往早在成为工程之前就已经成为道德戏剧。一种语言被描述为干净的，另一种语言被描述为沉重的。一个被想象为未来，另一个被想象为过去的包袱。这些故事在情感上令人满足，因为它们让历史变得整洁。它们还误导了那些必须在截止日期、预算、集成限制下交付系统的团队，现在还误导了十年前不存在的额外力量：人工智能编码助理和代理。
一旦代码生成成为日常交付的一部分，问题就会改变。它不再只是“哪种语言是优雅的？”或“默认情况下哪种语言是安全的？”更困难、更实际的问题是：如果一个团队希望人工智能系统帮助编写、重构、基准测试、集成和调试生产代码，那么目前哪种语言为这些系统提供了最丰富的使用环境？我的答案仍然是C++，争论的核心既不是怀旧也不是大男子主义。是密度。
C++ 仍然位于一个比 Rust 更密集的公共代码、部署的基础设施、供应商工具、平台示例、优化民间传说和实际生产伤痕的世界中。人工智能模型从这种密度中学习。他们学习语法，人们如何将大型系统缝合在一起，构建文件如何演变，如何丑陋的集成工作，如何诊断低级错误，以及如何实际上在愤怒而不是理论上编写性能敏感的代码。当这些模型后来被要求帮助进行实际工程时，历史记忆的形状就很重要了。
这并不意味着 Rust 很弱、不严肃或无关紧要。相反，Rust 给系统编程带来了健康的压力。它使内存安全变得不容忽视，改善了许多工程对话的基调，并产生了真正强大的工具和库。但 Rust 优势的存在并不会自动抹掉 C++ 当前在人工智能辅助交付方面的优势。成熟的工程通常需要同时掌握这两个事实。
先有证据，后有口号
仔细的论证首先是将可以公开观察到的内容与必须推断出的内容分开。代码模型研究中使用的公共数据集（例如 The Stack）显示的 C++ 远多于 Rust。公共开发者调查和 GitHub 语言趋势继续显示 C++ 在整个行业中得到更广泛的绝对使用。公共 AI 基础设施，从供应商 C++ 到优化的推理运行时，再到低级数学库，仍然暴露出一个深度由 C 和 C++ 塑造的世界。 CRUST-Bench 等公共基准测试工作还表明，当前模型仍然难以始终如一地生成安全、惯用的 Rust，以体现 Rust 社区所重视的强烈意义。
根据这些事实，我们做出推论，而不是教条。推论是，人工智能系统目前更有可能在许多系统领域生成生产有用、可集成和可优化的C++，因为C++的周围环境更丰富。这是曝光与反馈的结合。一种拥有更多存储库、更多构建脚本、更多面向硬件的示例、更多供应商集成、更多公开错误修复、更多性能调查和更多生产战争故事的语言，为模型提供了更多方法，让模型在人类工程师开始纠正之前就可以近似正确。
这一点常常遭到抵制，因为对于新语言来说这听起来很不慷慨。 Rust 积累公共工程沉积物的时间很短。 C++ 几十年来一直嵌入操作系统、浏览器、数据库、媒体堆栈、安全工具、游戏引擎、电信、科学计算、嵌入式产品和金融系统中。 Rust 增长迅速且令人钦佩，但增长与地质深度不同。人工智能模型吸收深度。
为什么语料库大小比人们承认的更重要
工程师有时将训练数据量视为一个粗俗的话题。在实践中，它以更加人性化的方式发挥着重要作用。在生产代码库中工作的人工智能代理通常不会从第一原理出发发明完美的算法。它正在做一些更混乱的事情。它可能会更新 CMake 文件、适应一个平台上的编译器投诉、替换热路径容器、包装供应商 API、转换图像或张量布局、修复 ABI 不匹配，或者在不破坏周围所有内容的情况下使旧的本机子系统稍微不那么痛苦。
这些任务奖励熟悉普通的、不完美的、活跃的代码。智能体受益于看到干净的教科书示例和解决相邻问题的数千次实际尝试。 C++ 为模型提供了更多此类材料。有更现代的 C++，更多遗留的 C++ 正在慢慢修复，更多基准驱动的 C++，更令人尴尬的 C++ 仍然以某种方式运行着重要的业务，以及更多人们在实际系统所需要的妥协中进行导航的例子。
这就是为什么“混乱的生产C++”仍然是有价值的训练数据。一些工程师听到这句话并认为它削弱了外壳的强度。事实上，它强化了它。生产系统并不完全由优雅的新建模块组成。它们包括遗留接口、奇怪的 ABI 假设、平台条件、硬件怪癖、部分迁移以及因为在变得美观之前有用而幸存下来的代码。如果人工智能系统在 C++ 中看到了更多该环境的示例，那么它就可以更好地准备在这样的环境中提供帮助。一个反例值得公开说明。如果一个团队正在构建一个小型绿地服务，具有强大的 Rust 专业知识、明确的安全要求、适度的集成需求，并且周围没有沉重的本地生态系统，那么 Rust 可能是更好的本地选择。在这种情况下，语料库大小的争论就不那么具有决定性了，因为周围的工程环境更简单，并且人类团队可以将系统保持在更窄的复杂范围内。重点不在于 C++ 赢得了所有争论。关键是，随着问题变得更老、更陌生、对性能更加敏感，并且与现有的本机基础设施更加纠缠，C++ 越来越成为人工智能系统更容易有效提供帮助的语言。
AI 基础设施世界仍处于 C++ 形态
即使我们完全忽略训练数据量，仍然会有第二股力量将默认值拉向C++：现代人工智能产品下的基础设施仍然是强大的原生。 CUDA、优化的数学库、ONNX Runtime 内部结构、oneDNN、OpenVINO、分词器实现、多媒体预处理管道、模型服务加速器、硬件供应商 SDK 以及许多部署运行时都是用 C 或 C++ 编写的，或者在那里公开其最重要的接口。这并不意味着 Rust 无法调用它们。这意味着通过环境的最短路径通常仍然是 C 或 C++ 路径。
这很重要，因为人工智能编码代理在真空中无法发挥作用。它们在依赖图中很有用。当一个模型被要求帮助集成运行时、调试构建、调整热路径或推理跨供应商 SDK 边界的所有权时，当它看到同一语言系列中的许多相邻示例时，它就会具有优势。在大多数性能关键型人工智能基础设施工作中，C++ 仍然比 Rust 更能从环境熟悉度中受益。
这也是关于反馈循环的讨论变得重要的地方。只有当人类能够快速验证人工智能生成的代码时，它才变得真正有价值。 C++ 通常为团队在这些领域提供更丰富的本地验证，因为围绕基准测试、分析、重放、消毒剂、硬件计数器和低级诊断的生态系统非常成熟。当代理建议更改 C++ 推理路径时，团队通常可以对其进行编译、分析、检查分配行为、比较延迟分布并快速迭代。 Rust 绝对也拥有强大的工具，但在许多与 AI 相邻的本机系统中，库、示例、分析器和现有实践的组合密度仍然使 C++ 更容易运行紧密的人机交互校正循环。
为什么团队通常使用 C++ 行动得更快，即使 Rust 看起来更干净
这是容易冒犯意识形态的一点，因为这听起来对清洁很不礼貌。 Rust 在白板上通常看起来更干净。所有权是明确的。编译器会保护重要的错误。围绕正确性的文化令人钦佩。但生产速度并不等同于语言的优雅。真正的交付速度来自整个循环：现有代码库、可用库、人才库、调试工具、部署限制、AI 辅助质量以及下个月再进行一项更改的成本。
C++ 目前在许多人工智能时代的系统中赢得了更广泛的循环，因为团队可以在不离开语言的情况下向周围世界询问更多信息。他们可以集成旧的本机库，附加考虑到本机性能工作而构建的分析器，调整分配器，利用特定于平台的设施，并在出现问题时从更大的公共示例中提取内容。人工智能助手受益于完全相同的现实。当模型周围的世界密集且交通频繁时，模型的草稿改进得更快。
想象一下，两个团队构建一个延迟敏感的推理服务，其中包含一些自定义预处理、复杂的部署矩阵，并且需要重复的性能调整。 Rust 团队可能会产生少量内存安全错误，这很重要。但如果 C++ 团队能够更直接地集成生态系统，在他们拥有的实际代码库中获得更强大的人工智能建议，并使用成熟的本机工具更快地验证性能变化，那么整体交付结果可能仍然有利于 C++。从商业角度来看，这比一种语言是否能在网上赢得哲学争论更重要。
一个有用的反例让我们保持诚实。当具有相对简单依赖关系的新服务中的内存安全是主要风险时，Rust 绝对可以创造更好的组织成果。错误在于接受这一事实并将其不加区别地引入到每个与人工智能相关的系统问题中。语言在语境中胜出，而不是在说教中胜出。
Rust 仍然是正确的
Rust 值得尊重，而 C++ 的论据在讽刺 Rust 时就较弱。 Rust 非常擅长使不安全的假设变得可见。它在所有权和生命周期方面建立了严格的纪律。对于绿地基础设施来说，它通常是一个令人信服的选择，因为在这些基础设施中，正确性和可维护性比与现有本地世界的兼容性占主导地位。在一些团队中，Rust 还提高了招聘的清晰度，因为代码库本身强制执行某种工程严肃性。
同样重要的是要明确地说，仅凭年龄是不够的。不守纪律的 C++ 仍然很危险。如果一个团队的审查文化薄弱，没有分析习惯，测试质量差，并且不尊重可观察性，那么更大的语料库和更丰富的工具也无法拯救它。人工智能系统可以轻松地放大这种混乱，就像它们可以加速良好的工程一样。真正的主张更狭隘、更实用：鉴于纪律严明的团队解决性能敏感、集成繁重、人工智能时代的系统问题，C++ 今天仍然是更强大的默认赌注，因为代理、工具和生态系统引力都强化了它。这就是为什么我更喜欢“默认投注”而不是“万能赢家”这个短语。默认赌注是您选择的赌注，直到另一个选择承担举证责任。 Rust 可以在特定项目中获得这种转变。当这项工作与本机人工智能基础设施、低水平性能、长期生产系统或人工智能代理在大量公众中看到的代码库深深纠缠在一起时，C++ 仍然从更多有利于它的证据开始。
实用的决策方法
如果热路径是本机的，依赖图是本机的，分析故事很重要，并且您希望人工智能助手在混乱的实际生产代码中提供帮助，那么 C++ 值得您第一次认真的语言讨论。如果系统是新建的，安全案例占主导地位，周围的生态系统已经Rust成形，并且问题并不严重依赖于旧的原生地层，Rust变得更具吸引力。如果系统包含两个世界（许多系统都这样做），那么成熟的答案通常是混合架构而不是部落纯粹性。
这个框架使对话平静下来，因为它返回的是工作决定而不是身份。现有 C++ 平台内的本机推理运行时与新的控制平面服务不是同一个问题。低延迟媒体管道与后端 API 不是同一个问题。模型服务边缘组件与链本机状态转换引擎不是同一个问题。一旦我们为实际作品命名，语言的选择通常看起来不那么意识形态化，而且更加明显。
以这种方式做出决定也对人类有利。当团队不再问哪种语言值得钦佩，而是开始问哪种语言最有可能让当前系统变得可靠、易懂和可改进时，他们就会变得更加合作。人工智能的帮助使得这一点变得更加重要。当代理嵌入验证文化中时，它们就会变得强大，而不是当它们被用来用合成的信心来装饰语言狂热时。
真正的机会
人工智能时代更深层次的机会是，代理现在可以参与成熟系统的整个反馈循环：阅读旧代码、提出编辑建议、改进基准、显示分析器线索、将粗略的想法转化为可编译的实验，并帮助工程师比以前更快地从怀疑转向测量。在那个世界里，受益最多的语言不一定是拥有最精彩理论故事的语言。它是一个拥有最厚实的公共、实用、经过战斗考验的现实网络的网络。
今天，对于一大类严重的系统问题，该语言仍然是 C++。这是个好消息，因为团队可以使用大量现有的本地知识，同时继续向 Rust 学习。最富有成效的姿态不是必胜主义。这是感恩。 C++ 积累了数十年的真实工程内存，而人工智能系统现在使这些内存更易于使用。明智的团队会利用它。
动手实验室：构建和改进本机评分管道
如果一篇关于人工智能时代语言选择的文章不包含代码，那么它就有可能成为说教。
因此，让我们构建一个小型的本机 C++ 实用程序，就像真实公司中不断要求改进的 AI 代理一样：一个文本评分管道，用于加载数据、计算简单特征、对结果进行排序并打印顶行。
这是故意的谦虚。大多数生产工程都是适度的。
Rust```cpp
include <algorithm>
include <chrono>
include <cctype>
include <fstream>
include <iostream>
include <string>
include <string_view>
include <vector>
struct Sample { std::string text; double score = 0.0; };
static int count_digits(std::string_view s) { int n = 0; for (unsigned char c : s) { n += std::isdigit(c) ? 1 : 0; } return n; }
static int count_upper(std::string_view s) { int n = 0; for (unsigned char c : s) { n += std::isupper(c) ? 1 : 0; } return n; }
static int count_punct(std::string_view s) { int n = 0; for (unsigned char c : s) { n += std::ispunct(c) ? 1 : 0; } return n; }
static double score_line(std::string_view s) { const auto len = static_cast<double>(s.size()); const auto digits = static_cast<double>(count_digits(s)); const auto upper = static_cast<double>(count_upper(s)); const auto punct = static_cast<double>(count_punct(s)); return len 0.03 + digits 0.7 + upper 0.15 - punct 0.05; }
int main(int argc, char** argv) { if (argc < 2) { std::cerr << "usage: scorer <input-file>\n"; return 1; }
std::ifstream in(argv[1]);
if (!in) {
std::cerr << "cannot open input file\n";
return 1;
}
std::vector<Sample> rows;
rows.reserve(200000);
std::string line;
while (std::getline(in, line)) {
rows.push_back({line, 0.0});
}
const auto t0 = std::chrono::steady_clock::now();
for (auto& row : rows) {
row.score = score_line(row.text);
}
std::sort(rows.begin(), rows.end(), [](const Sample& a, const Sample& b) {
return a.score > b.score;
});
const auto t1 = std::chrono::steady_clock::now();
const auto ms = std::chrono::duration_cast<std::chrono::milliseconds>(t1 - t0).count();
std::cout << "processed " << rows.size() << " rows in " << ms << " ms\n";
const size_t limit = std::min<size_t>(5, rows.size());
for (size_t i = 0; i < limit; ++i) {
std::cout << rows[i].score << " | " << rows[i].text << "\n";
}}
在 Linux 或 macOS 上：```bash
g++ -O2 -std=c++20 -o scorer main.cpp
./scorer sample.txt
```在 Windows 上使用 MSVC：```powershell
cl /O2 /std:c++20 main.cpp
.\main.exe sample.txt
```### 为什么这个小程序很有用
因为这正是人工智能辅助工程变得有形的代码：
* 这是原生的
* 它涉及字符串和内存
* 它有一个可测量的运行时间
* 可以对其进行分析
* 可以逐步改进
这就是当今许多 C++ 代理的真正栖息地：普通的本机程序需要变得更好而不需要重新发明。
## 爱好者测试任务
如果您想将本文变成实际练习，请尝试以下操作：
1. 请您最喜欢的编码代理在不改变输出的情况下优化程序。检查它是否减少了重复通道或不必要的临时通道。
2. 为文件加载、评分和排序添加单独的计时。验证时间到底去哪儿了。
3. 将输入替换为一百万行，并比较不同代理建议的优化质量。
4.将该实用程序移植到Rust并诚实地比较体验：
对于这个具体任务来说，什么感觉更清晰，什么感觉更重，以及周围的工具感觉更成熟。
5. 在分析器下运行 C++ 版本，并记下您对热点的第一次猜测是否确实正确。
这是一个小练习，但这正是它有用的原因。当大多数工程辩论被迫与一个小型真实程序接触时，它们就会变得更加真实。
## 总结
Rust 值得受到尊重。它提高了安全对话的标准，并为系统编程提供了一组更健康的默认值。但人工智能时代并不仅仅奖励违约行为。它是对位于最大的实时代码库、最深的低级集成生态系统、最丰富的优化文化以及从生成的草稿到可测量的生产结果的最快的实际循环的中心的语言的奖励。今天，这仍然比 C++ 更强烈地描述 C++。
这使得 C++ 在特定系统环境中具有交付优势，而 Rust 在其他系统环境中仍然有价值。这仅仅意味着，对于许多严重的本机系统问题，当目标世界是 C++ 时，人工智能代理仍然有更有用的基础。理解这一点的团队可以做出更好的决策，而不会出现戏剧性的情况。他们可以向 Rust 学习，其中 Rust 最强，并且仍然使用 C++ 的巨大累积内存，其中该内存最具经济价值。
## 参考文献
1.GitHub Octoverse 2024：C++
2.GitHub Octoverse 2025：Rust
3. 2023 年 Stack Overflow 开发者调查：CUDA
4. Stack Overflow 开发者调查 2025 技术部分：ONNX Runtime
5. 堆栈数据集卡：API
6. Stack 论文：PyTorch
7. ICLR 2025 关于代码数据对预训练影响的论文：rust
8. CRUST-Bench：C-to-safe-Rust 编译的综合基准：[https://arxiv.org/abs/2504.15254](https://arxiv.org/abs/2504.15254)
9. CUDA C++ 编程指南：[https://docs.nvidia.com/cuda/cuda-c-programming-guide/](https://docs.nvidia.com/cuda/cuda-c-programming-guide/)
10. C++ C/C++ API：[https://onnxruntime.ai/docs/api/c/index.html](https://onnxruntime.ai/docs/api/c/index.html)
11. PyTorch C++ 前端文档：[https://docs.pytorch.org/cppdocs/frontend.html](https://docs.pytorch.org/cppdocs/frontend.html)
12. C++ 核心准则：[https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)
## 当系统已经处于压力下时会是什么样子
人工智能时代系统中的 C++ 与 rust 的对比往往在团队希望有一个安静的季度时变得紧迫。一项功能已经呈现在客户面前，或者一个平台已经具有内部依赖性，并且系统选择了特定的一周来揭示其优雅的理论和运行时行为已经礼貌地分开生活。这就是为什么这么多严肃的工程工作都是从协调开始的。团队需要将其认为系统所做的事情与系统在负载、变化和截止日期下实际所做的事情相协调，这会让每个人都稍微更有创造力，但稍微不那么明智。
在本机基础设施规划中，最重要的情况通常是大型遗留平台、性能敏感的人工智能后端和混合语言现代化程序。这些情况会带来技术、预算、信任、路线图，有时甚至是声誉后果。当多个团队依赖技术问题并且没有人能够完全解释为什么它不断产生噪音、延迟和成本时，技术问题在政治上就会变得更大。
这就是为什么我们建议从运营压力和交付现实的角度来看待这个问题。设计可能在理论上很漂亮，但在操作上却是毁灭性的。另一种设计可能几乎是无聊的，但却可以使产品继续前进多年，因为它是可测量的、可修复的，并且诚实地进行权衡。认真的工程师学会更喜欢第二类。它减少了史诗般的演讲，也减少了紧急回顾，每个人都用被动语态说话，没有人记得谁批准了这条捷径。
## 始终如一的实践第一个持久的做法是不断衡量一条有代表性的路径。团队通常会在定义将改变决策的信号之前收集广泛的遥测数据。选择真正重要的道路，反复衡量，拒绝让讨论变成装饰性的故事讲述。在 AI 时代系统中 C++ 与 Rust 的工作中，有用的衡量标准通常是交付速度、互操作成本、工具成熟度和运行时可观察性。一旦这些决定变得可见，其余的决定就会变得更加人性化，不再那么神秘。
第二个持久的做法是将证据与承诺分开。在系统得出结论之前，工程师常常被迫说方向是正确的。抵制这种压力。首先建立一个狭义的证明，尤其是当主题与客户或金钱密切相关时。经过验证的小改进比未经验证的大目标具有更大的商业价值。这听起来很明显，直到季度末审查将假设变成最后期限，并且整个组织开始将乐观情绪视为日程安排工件。
第三个持久的做法是用所有权语言撰写建议。一段说“提高绩效”或“加强界限”的段落在情感上令人愉快，但在操作上毫无用处。一个段落说明了谁更改了什么、按什么顺序、在什么回滚条件下更改，这些内容实际上在周一早上仍然存在。这是很多技术写作失败的地方。它希望听起来先进，而不是可调度。
## 节省时间的反例
当地的成功并不能证明已经准备好迎接更艰难的环境。在扩展这个想法之前，团队必须升级测量规则并证明相同的行为在更大的压力下仍然存在。
另一个反例是工具通货膨胀。一个新的分析器、一个新的运行时、一个新的仪表板、一个新的代理、一个新的自动化层、一个承诺协调旧包装器的新包装器。这些事情本质上都不是坏事。问题是当他们被要求补偿一个没有人明确命名的边界时会发生什么。然后，系统就会变得更加仪器化、更加令人印象深刻，并且只是偶尔更容易理解。团队很快就能感受到这一点。即使没有这样的措辞，他们也能察觉到堆栈何时成为决策的昂贵替代品。
第三个反例是将人工审查视为自动化的失败。在实际系统中，人工审查通常是保持自动化在商业上可接受的控制措施。成熟的团队知道在哪里积极自动化以及在哪里保持批准或解释可见。不成熟的团队希望机器做所有事情，因为“一切”在幻灯片中听起来都很高效。然后第一个严重事件到来，突然之间，带着转换体验的诚意重新发现了手动审核。
## 我们推荐的交付模式
好的工作首先是通过足够强大的技术阅读来减轻压力，以阻止循环辩论。下一个有界实施改进了一条重要路径，并且复测使工程和领导层能够清楚地了解方向。这个顺序比确切的工具选择更重要，因为它将技术技能转化为前进的动力。
实际上，我们建议缩小第一个周期：收集工件，产生一个硬诊断，发布一个有限的更改，复测真实路径，并用简单的语言编写下一个决策。简单的语言很重要。团队很少会后悔清晰度。团队常常会在收据到达之前后悔给自己留下了深刻的印象。
这也是语气很重要的地方。强大的技术工作听起来应该像以前遇到过生产一样。冷静、精确、精确地进行权衡和证据。该音调携带操作信号。它表明该团队了解系统工程的古老真理：机器速度很快，路线图很脆弱，迟早要为每一个允许保持诗意的假设付出代价。
## 在准备就绪之前我们将使用的清单
在本地基础设施规划中，准备就绪不是一种情绪。这是一个带有后果的清单。在我们将人工智能时代系统中的 C++ 与 Rust 的工作进行更广泛的推广之前，我们希望以尽可能最好的方式让一些事情变得无聊。我们想要一条在代表性负载下表现可预测的路径。我们想要一组不矛盾的测量结果。我们希望团队知道边界在哪里以及打破它意味着什么。我们希望工作的输出足够清晰，以便实施室之外的人仍然可以从中做出正确的决定。
该清单通常涉及交付速度、互操作成本、工具成熟度和运行时可观察性。在昂贵的意外事件投入生产之前，使用该清单来测试解释质量、现场弹性和回滚清晰度。
这也是团队发现他们是否正在解决真正的问题或只是在其周围排练能力的地方。许多技术努力都感觉很成功，直到有人要求提供可重复性、生产证据或会影响预算的决定。在那一刻，弱的工作变得模糊，而强的工作变得异常简单。平淡就好。平淡通常意味着系统已经不再依赖魅力。
## 我们建议如何谈论结果
最终的解释应该足够简短，以便在领导会议上通过，并且足够具体，以便在工程审查中通过。这比听起来更难。过于技术性的语言隐藏了顺序。过于简化的语言隐藏着风险。正确的中间立场是以一种听起来平静而不是胜利的方式描述路径、证据、有限的变化以及下一步建议的步骤。我们推荐这样的结构。首先，说明评估了什么路径以及它为何重要。其次，说出该路径的错误或不确定之处。第三，说明更改、测量或验证的内容。第四，说出尚未解决的问题以及下一步投资将购买什么。这种结构之所以有效，是因为它尊重工程和购买行为。工程师想要细节。团队需要排序。当下一步明确时，每个人都会受益。
以这种方式说话的隐藏好处是文化。清楚地解释技术工作的团队通常也会更清楚地执行它。他们不再将模糊性视为复杂性。他们变得更难用行话打动人心，而更容易通过困难的系统获得信任。这是工程成熟度中最被低估的形式之一。
## 我们仍然拒绝伪造的内容
即使在系统改进之后，成熟的团队也会在本地基础设施规划中保持不确定性。弱测量需要更清晰的证据，硬边界需要简单的语言，更平静的演示需要真正的操作准备。必须减少一些不确定性；有些必须诚实地命名。令人困惑的是这两项工作是如何令人尊敬的项目变成了昂贵的寓言。
同样的规则适用于人工智能时代系统中围绕 C++ 与 Rust 的决策。如果团队仍然缺乏可重复的基准、值得信赖的回滚路径或关键接口的明确所有者，那么最有用的输出可能是更明确的“否”或更窄的下一步，而不是更大的承诺。这种纪律使技术工作与其要改进的现实保持一致。
以这种方式工作会有一种奇怪的轻松感。一旦系统不再依赖乐观的故事讲述，工程对话就会变得更简单，即使工作仍然很困难。在生产中，这通常被视为一种小形式的恩典。
