在 C++ 中使用神经网络开源库

简介

现代人工智能通常通过 Python、笔记本、演示环境以及第一次看到模型工作时的兴奋感进入公司。这个阶段是真实的、有用的，甚至有点神奇。这是好奇心廉价且迭代快速的地方。但真正产品的生命并不会在演示中结束。必须为客户提供服务、适合后端、在工厂硬件上运行、在桌面产品内运行或在恶劣的网络条件下生存的模型不再只是一个模型。它成为系统中的一个组件，而系统是工程成熟度开始发挥作用的地方。

那是C++回到房间的那一刻。生产提出的问题是高级实验只能推迟这么长时间的。该进程真正需要多少内存？负载下的稳态延迟是多少？启动时间可以承受自动缩放吗？运行时可以存在于现有的本机应用程序中吗？我们是否可以将相同的推理路径发送到服务器、边缘盒和操作员工作站，而无需围绕研究堆栈重建整个产品？

开源库使得这种转变成为可能，而无需将控制权交给供应商黑匣子。它们为我们提供了稳定的运行时、张量抽象、优化的内核、量化的执行路径、硬件感知后端，以及在最近的LLM时代，令人惊讶的本地推理引擎。但丰富的图书馆也会使环境变得混乱。工程师经常问哪个库最好，而更好的问题是哪个库对我们面前的工作诚实。

本文采取了更为扎实的道路。我们将把人工智能中主要的 C++ 相关库视为具有优势、盲点和操作假设的工程人物。最后，我们的目标是了解 ONNX Runtime、LibTorch、oneDNN、OpenVINO、TensorFlow Lite 和 llama.cpp 何时提供帮助，何时每一项变得太重，何时变得太窄，以及如何在不被时尚左右的情况下进行选择。

为什么人工智能系统不断回归 C++

人工智能交付有一个值得明确命名的节奏，因为一旦你看到它，许多架构选择就会变得更容易理解。首先是发现阶段。安全研究员和产品工程师仍在了解模型可以做什么、需要什么数据以及实际价值可能在哪里。在那个阶段，表现力胜过纪律。快速实验、丰富的 Python 工具和灵活的研究框架正是团队所需要的。

然后是不那么迷人的第二阶段，原型开始积累义务。支持团队必须了解失败。 SRE 团队需要可预测的启动和内存行为。财务部想知道服务账单是暂时的激增还是永久性的泄漏。嵌入式客户询问模型是否可以离线运行。安全审查询问二进制文件中到底包含什么以及可以审核哪些部分。突然之间，模型不再是研究工件，而是成为生产环境的公民。

C++ 在这一点上不断返回，因为它让工程人员可以回答具体问题，而不是对这些问题挥手致意。本机服务可以控制分配策略、线程池、ABI 边界、打包、CPU 特定优化以及与现有性能敏感子系统的集成。这种控制在必要时最为重要，而且很难用言辞来伪装。

一个有用的反例在这里会有所帮助。如果您的团队正在构建一个每小时运行一次的轻负载内部文档分类器，那么阻力最小的路径可能是具有稳定服务框架和很少本机代码的 Python 服务。这并没有什么可耻的。另一方面，如果同一个团队将推理嵌入延迟敏感的 C++ 桌面应用程序中，运送到资源有限的边缘设备，或者将模型执行直接插入到热后端路径中，那么假装运行时语言无关紧要的成本很快就会变得昂贵。换句话说，每当系统本身出现问题时，C++ 仍然是最严重的答案之一。

图书馆作为工程名人

迷失在这个生态系统中的最简单方法就是将每个图书馆都视为在竞争同一个工作。他们不是。面向训练的框架、可移植的推理运行时、内核库和本地 LLM 引擎都可以解决不同的难题。如果我们将它们归入称为人工智能库的一类，我们最终会根据品牌熟悉度而不是系统设计做出选择。

在许多生产环境中，ONNX Runtime 是最严格且最不戏剧化的选择。它是围绕一个明确的承诺构建的：将模型导出为稳定的格式，通过专注于执行的运行时加载它，并让应用程序拥有系统的其余部分。这听起来很简单，而简单正是它如此强大的原因。当研究阶段已经在其他地方发生时，ONNX Runtime 通常是正确的答案，剩下的就是重复、可移植且具有可预测操作行为的冷静工作。接收图像、标准化张量、运行已知图形并将结果返回到现有 C++ 服务的计算机视觉后端是一个理想的 ONNX Runtime 故事。不合适的产品是其核心价值取决于动态训练时间行为、应用程序内频繁的图形手术或一组不断变化的自定义操作符，这些操作符会使导出变得脆弱。在这种情况下，起初看起来干净的运行时边界可能会成为摩擦的根源。LibTorch 的性质不同。它的主要作用比轻量级执行边界更广泛。它是完整深度学习框架的C++面貌。这使它更重，但也使其更具表现力。当本机应用程序真正需要张量所有权、模型构建、类似训练的操作或跨开发和生产的紧密 PyTorch 语义时，LibTorch 变得比 ONNX Runtime 更引人注目。当产品真正需要框架而不是运行时边界时，选择它是有一定诚实性的。反例同样重要。团队有时会采用 LibTorch 进行简单的静态推理，因为它给人一种久负盛名或面向未来的感觉。然后他们发现他们引入了比所需工作负载大得多的概念和操作表面。只需要加载稳定模型图的小型推理服务可能会在包大小、复杂性和调试工作方面付出代价。

oneDNN 和 OpenVINO 更接近金属，并奖励更加注重性能的心态。当 CPU 内核、内存格式和操作员级效率变得重要到值得直接关注时，oneDNN 是您欣赏的库。许多团队通过更高级别的运行时间接使用它，这通常是明智的。与此同时，OpenVINO 处于更具战略意义的位置。它可以帮助关心面向英特尔的部署、图形优化和硬件感知执行的团队，而无需手动管理每个低级细节。在实践中，当业务问题不再只是“运行模型”而是“在我们实际可以购买、部署和维护的硬件上高效运行模型”时，这些工具就开始发挥作用。这种区别在会议中听起来很小，但在预算中却变得非常大。

TensorFlow Lite 完全代表了另一种气质。这是克制的声音。在边缘设备、移动目标和资源受限的系统上，完整性通常不如适应性更有价值。工程师不需要在那里有一个雄伟的框架；他们需要一个能够加载、执行并保持在内存、包大小、能源使用和启动时间等严格限制内的模型。当部署目标本身是塑造架构的主要力量时，TensorFlow Lite 就有意义了。反例也很常见：团队从边缘运行时开始，因为它听起来很高效，然后慢慢地将其扩展到更广泛的服务器平台或具有比其构建支持的更多动态需求的工作流程。边缘的效率不会自动转化为其他地方的舒适度。

然后是llama.cpp，它值得特别关注，因为它改变了局部推理的情感图谱。在 llama.cpp 和类似项目成为主流之前，许多工程师认为本地大语言模型服务仍然是研究玩具或企业设备。 llama.cpp 展示了一些更有趣的东西：通过积极的量化、仔细的内核工作和严格的工程，现代的 LLM 可以成为普通系统内的本地组件。这种洞察力的重要性超出了一个项目的范畴。它提醒整个领域，本机执行、模型压缩和实际部署的进展速度比集中式叙述通常暗示的要快得多。但llama.cpp也有一个自然的边界。当作业在本地高效地运行受支持的变压器模型时，效果非常好。它无法取代整个深度学习生态系统，当团队要求它承担这一角色时就会遇到麻烦。

如何选择而不被炒作所诱惑

在这些库中进行选择的最可靠方法是从产品开始，然后再为工具命名。首先询问您的应用程序真正拥有什么以及它仅消耗什么。如果系统主要使用稳定的模型并且需要可移植的、有边界的推理，那么 ONNX Runtime 通常是最冷静的答案。如果系统本身必须使用张量、模块和框架语义的语言，那么 LibTorch 值得讨论。如果 CPU 效率、图形优化或英特尔密集部署是困难部分，那么 oneDNN 和 OpenVINO 更接近中心。如果目标较小、离线、电池敏感或嵌入式，TensorFlow Lite 会变得更加自然。如果该产品明确是关于在本机环境中运行本地量化语言模型，那么 llama.cpp 就应该尽早出现。

第二个问题同样重要：工程难题实际上将在哪里得到解决？团队经常根据基准标题选择库，然后发现他们真正的痛苦在其他地方。如果导出不稳定、预处理混乱或部署打包变得脆弱，那么具有惊人吞吐量的运行时可能仍然不合适。如果运行时间稍慢一些，它可以在模型生成者和系统维护者之间创建更清晰的边界，那么它仍然可能是更好的业务选择。交付了多个人工智能产品的工程师深刻地吸取了这一教训：最好的库让整个系统在凌晨两点更容易推理；基准测试的胜利本身并不能解决决定。

这就是反例变得健康的地方。考虑一个构建本机文档分析服务的团队。时尚的选择可能是使用现有的最重的框架，因为它感觉是面向未来的。但如果模型是静态的，预处理管道很简单，并且真正需要的是现有 C++ 服务内的稳定推理，ONNX Runtime 可能会产生较少的长期阻力。现在考虑相反的情况。一个团队正在使用自定义张量流、频繁的架构更改以及与基于 PyTorch 的训练逻辑的紧密耦合进行本机实验。因为听起来“生产就绪”而强制通过 ONNX 进行所有操作可能会创建一个脆弱的以导出为中心的工作流程，而没有人真正喜欢这种工作流程。在每种情况下，错误都是相同的：团队在选择工作负载之前选择了身份。## 良好的集成实际上是什么样的

成熟的集成工作流程从数据契约开始，而不是从库开始。在讨论运行时之前，请确定应用程序向模型提供什么以及模型向应用程序返回什么。命名张量形状、数据类型、标准化规则、标记化路径、填充行为、批处理假设和错误条件。这听起来几乎是官僚作风，但却是许多成功部署的安静源泉。当运行时的边界模糊时，系统就会失败。

一旦数据契约稳定，导出或模型打包就变得更容易验证。团队可以在代表性输入下比较研究路径和生产路径之间的输出、测量容差并检测保真度漂移的位置。在这里，工程师们可以发现他们优雅的架构是否能够经受住现实的考验。有时导出的图很好，唯一的问题是预处理不匹配。有时运行时是完美的，真正的问题是服务中其他地方的线程超额订阅。有时，一个所谓的小模型无法承受真正并发的内存压力。这些发现中的每一项都是有用的。这意味着该系统已经开始变得可见。

之后是基准测试和分析，这里同样适用旧规则：测量您打算发布的系统，而不是您过去认为很聪明的玩具。在实际请求形状、批量大小、输入可变性和硬件条件下对模型进行基准测试。预处理和后处理也是如此，因为许多团队无意识地只对模型核心进行基准测试，而忘记了客户为整个路径付费。在生产人工智能中，被六十毫秒可避免的胶水包围的十毫秒图表仍然是一个七十毫秒的特征。

最后，使部署具有可重复性。原生人工智能堆栈奖励纪律。引脚版本、文档编译器和运行时假设、决定需要哪些执行提供程序或 CPU 功能，并保留一组狭窄的受支持配置。如果队友在没有考古的情况下无法在另一台机器上重现相同的推理路径，那么无论演示多么令人印象深刻，堆栈都还没有准备好。良好的C++人工智能工程使系统足够平静，速度仍然可以理解。

不断重复的错误

最常见的错误是将研究真理误认为生产真理。一个在笔记本上看起来很出色的模型，一旦导出、量化、嵌入、观察并在真正的并发下运行，可能会变得很尴尬。这并不意味着该模型不好。这意味着系统比实验更大。第二个经常出现的错误是假装预处理和后处理是次要的。在实际产品中，它们通常只完成了一半的工作。图像调整大小策略、分词器行为、特征归一化、校准阈值和输出解码所有形状正确性和延迟都与核心运行时一样确定。

第三个错误是过度依赖某个框架，因为它感觉很现代或很全面。工程师有时会选择尽可能大的工具来预测永远不会到来的需求。然后，该产品为其不使用的功能付费。相反的错误也存在：以纯粹的名义选择最轻的运行时，然后发现动态行为、自定义操作或框架级语义毕竟不是可选的。智慧在于只为你能真正解释的能力付费。

还有一种更微妙的态度失败。一些团队将库的选择视为解决了整个工程故事。事实并非如此。好的结果来自于重复、谦虚的工作：验证输出、测量热路径、删除可避免的副本、减少启动摩擦、简化打包以及保持运行时边界清晰。开源库使这项工作成为可能；他们不代表我们执行此操作。

一个值得记住的小部署故事

想象一下一个从 Python 愿景原型开始的团队。该演示足够强大，足以赢得内部支持，很快话题就转向与现有的 C++ 服务集成，该服务已经处理图像摄取、规则评估和报告。该团队面临多种诱惑。一是永远将模型保留在单独的 Python 服务后面，因为这在短期内很容易。另一个方法是立即将所有内容转移到重量级本机框架中，因为这听起来很严肃。第三种方法是在稳定输入合同之前花数周时间讨论架构。

越成熟的道路越安静。首先，团队仔细定义预处理和输出语义。然后它测试代表性图像的导出保真度。它选择 ONNX Runtime 因为问题是静态推理而不是框架驱动的实验。随后，对于具有更严格硬件限制的边缘变体，它会评估 TensorFlow Lite 或更积极优化的运行时路径对该产品分支是否有意义。几个月后，如果公司添加本地助手功能，当每个工具在系统的不同角落赢得一席之地时，llama.cpp 也可能会进入架构。

这是所有这些库背后更深刻的教训。严肃的人工智能工程很少会奖励纯粹性。它奖励合适。最好的开源库并不是拥有最多追随者的库。它可以让您的模型成为真实系统的一部分，而不会迫使系统的其余部分变得不合理。

动手实验室：构建一个小型 ONNX Runtime CLI

理论在编译后变得更有说服力。

让我们在 C++ 中构建最小的有用本机推理程序。目标不是训练模型。目标是亲手感受本机运行时边界是什么样子的。

对于本练习，您需要：

• C++17编译器
• CMake
• 来自官方版本的预构建 ONNX Runtime 包
• 输入为平浮点张量的任何小型 CPU 模型

项目布局```text

tiny-ort/ CMakeLists.txt main.cpp third_party/ onnxruntime/ model.onnx ``###CMakeLists.txt````cmake cmake_minimum_required(VERSION 3.16) project(tiny_ort LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON)

set(ORT_ROOT "${CMAKE_SOURCE_DIR}/third_party/onnxruntime")

add_executable(tiny_ort main.cpp) target_include_directories(tiny_ort PRIVATE "${ORT_ROOT}/include")

if (WIN32) target_link_directories(tiny_ort PRIVATE "${ORT_ROOT}/lib") target_link_libraries(tiny_ort PRIVATE onnxruntime) else() target_link_directories(tiny_ort PRIVATE "${ORT_ROOT}/lib") target_link_libraries(tiny_ort PRIVATE onnxruntime) endif() ``###main.cpp````cpp

include <onnxruntime_cxx_api.h>

include <array>

include <iostream>

include <numeric>

include <vector>

int main() { Ort::Env env{ORT_LOGGING_LEVEL_WARNING, "tiny-ort"}; Ort::SessionOptions opts; opts.SetIntraOpNumThreads(1); opts.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_EXTENDED);

const ORTCHAR_T* model_path = ORT_TSTR("model.onnx");
Ort::Session session{env, model_path, opts};

std::vector<int64_t> shape{1, 4};
std::vector<float> input{0.25f, 0.50f, 0.75f, 1.0f};

auto mem_info = Ort::MemoryInfo::CreateCpu(
    OrtArenaAllocator,
    OrtMemTypeDefault
);

Ort::Value tensor = Ort::Value::CreateTensor<float>(
    mem_info,
    input.data(),
    input.size(),
    shape.data(),
    shape.size()
);

const char* input_names[] = {"input"};
const char* output_names[] = {"output"};

auto outputs = session.Run(
    Ort::RunOptions{nullptr},
    input_names,
    &tensor,
    1,
    output_names,
    1
);

float* out = outputs[0].GetTensorMutableData<float>();
auto out_shape = outputs[0].GetTensorTypeAndShapeInfo().GetShape();
auto out_count = std::accumulate(
    out_shape.begin(),
    out_shape.end(),
    int64_t{1},
    std::multiplies<int64_t>{}
);

std::cout << "Output values:\n";
for (int64_t i = 0; i < out_count; ++i) {
    std::cout << "  [" << i << "] = " << out[i] << "\n";
}

return 0;

}

在 Linux 或 macOS 上：```bash
cmake -S . -B build
cmake --build build -j
./build/tiny_ort
```在 Windows 上使用 MSVC：```powershell
cmake -S . -B build
cmake --build build --config Release
.\build\Release\tiny_ort.exe
```### 这教给你什么

这个小项目已经迫使您面对几个生产现实：

* 运行时所在的位置
* 原生依赖是如何打包的
* 张量的名称和形状实际上是什么
* 显式内存处理在本机推理边界中的感觉如何

这正是重点。库不再是一个营销术语，而是成为一种工程选择。


## 爱好者测试任务

如果您想将本文变成周末实验室，以下是有用的后续步骤：

1. 将硬编码输入向量替换为从小文本或二进制文件加载的值。
2. 动态打印输入和输出张量形状，而不是假设它们。
3. 在 ONNX Runtime 周围添加简单的延迟测量，并比较 LibTorch、Python 和 C++ 操作内线程。
4. 在类似的玩具推理应用程序中将 ONNX Runtime 替换为 LibTorch，并记下哪些变得更容易，哪些变得更重。
5. 从 Python 导出一个微型模型，将其加载到这个 C++ 程序中，并验证预处理差异不会默默地改变结果。

如果你诚实地完成这五项任务，你将比许多能够背诵框架名称一个小时的人更了解人工智能部署。


## 总结

C++ 的开源神经网络库并没有齐头并进。它们源于不同的工程需求，当我们尊重这些起源时，它们仍然最有用。 ONNX Runtime 非常强大，因为它缩小了问题范围并为生产团队提供了稳定的推理边界。当本机应用程序真正需要跨模型路径的张量和模块所有权时，LibTorch 很有价值。当低效率和特定硬件系列上的部署不再是次要问题时，oneDNN 和 OpenVINO 就很重要。当设备本身是硬约束时，TensorFlow Lite 就会大放异彩。 llama.cpp 很重要，因为它非常公开地证明，仔细的本机工程可以将现代语言模型转变为实用的本地组件，而不是远程服务。

因此，最好的选择很少是最时尚的。正是它让整个系统变得更加平静。好的运行时是您的团队可以理解、基准测试、分析、打包、测试和操作的运行时，而无需神话。当工程师从这个地方进行选择时，开源人工智能不再看起来像一个令人困惑的框架动物园，而是开始看起来像它真正的样子：一个足够丰富的工具箱，可以支持严肃的本地产品。

## 参考文献

1. ONNX Runtime C/C++ API: oneDNN
2.ONNX官方项目：OpenVINO
3. PyTorch C++ 前端文档：TensorFlow Lite
4. oneDNN官方文档：llama.cpp
5. OpenVINO 文档：API
6. LiteRT / TensorFlow Lite C++ API 文档：PyTorch
7. llama.cpp 存储库：[https://github.com/ggml-org/llama.cpp](https://github.com/ggml-org/llama.cpp)
8. LibTorch GitHub 存储库：[https://github.com/microsoft/onnxruntime](https://github.com/microsoft/onnxruntime)
9. PyTorch 存储库：[https://github.com/pytorch/pytorch](https://github.com/pytorch/pytorch)
## 当系统已经处于压力下时会是什么样子

C++ 在团队希望季度安静的时刻，人工智能运行时的选择往往变得紧迫。一项功能已经呈现在客户面前，或者一个平台已经具有内部依赖性，并且系统选择了特定的一周来揭示其优雅的理论和运行时行为已经礼貌地分开生活。这就是为什么这么多严肃的工程工作都是从协调开始的。团队需要将其认为系统所做的事情与系统在负载、变化和截止日期下实际所做的事情相协调，这会让每个人都稍微更有创造力，但稍微不那么明智。

在本机人工智能部署中，最重要的情况通常是便携式服务器推理、受限硬件上的边缘部署以及在现有本机产品中嵌入模型。这些情况会带来技术、预算、信任、路线图，有时甚至是声誉后果。当多个团队依赖技术问题并且没有人能够完全解释为什么它不断产生噪音、延迟和成本时，技术问题在政治上就会变得更大。

这就是为什么我们建议从运营压力和交付现实的角度来看待这个问题。设计可能在理论上很漂亮，但在操作上却是毁灭性的。另一种设计可能几乎是无聊的，但却可以使产品继续前进多年，因为它是可测量的、可修复的，并且诚实地进行权衡。认真的工程师学会更喜欢第二类。它减少了史诗般的演讲，也减少了紧急回顾，每个人都用被动语态说话，没有人记得谁批准了这条捷径。

## 始终如一的实践

第一个持久的做法是不断衡量一条有代表性的路径。团队通常会在定义将改变决策的信号之前收集广泛的遥测数据。选择真正重要的道路，反复衡量，拒绝让讨论变成装饰性的故事讲述。在围绕 C++ AI 运行时选择进行工作时，有用的衡量标准通常是运行时适配、集成摩擦、打包成本和稳态延迟。一旦这些决定变得可见，其余的决定就会变得更加人性化，不再那么神秘。第二个持久的做法是将证据与承诺分开。在系统得出结论之前，工程师常常被迫说方向是正确的。抵制这种压力。首先建立一个狭义的证明，尤其是当主题与客户或金钱密切相关时。经过验证的小改进比未经验证的大目标具有更大的商业价值。这听起来很明显，直到季度末审查将假设变成最后期限，并且整个组织开始将乐观情绪视为日程安排工件。

第三个持久的做法是用所有权语言撰写建议。一段说“提高绩效”或“加强界限”的段落在情感上令人愉快，但在操作上毫无用处。一个段落说明了谁更改了什么、按什么顺序、在什么回滚条件下更改，这些内容实际上在周一早上仍然存在。这是很多技术写作失败的地方。它希望听起来先进，而不是可调度。

## 节省时间的反例

当地的成功并不能证明已经准备好迎接更艰难的环境。在扩展这个想法之前，团队必须升级测量规则并证明相同的行为在更大的压力下仍然存在。

另一个反例是工具通货膨胀。一个新的分析器、一个新的运行时、一个新的仪表板、一个新的代理、一个新的自动化层、一个承诺协调旧包装器的新包装器。这些事情本质上都不是坏事。问题是当他们被要求补偿一个没有人明确命名的边界时会发生什么。然后，系统就会变得更加仪器化、更加令人印象深刻，并且只是偶尔更容易理解。团队很快就能感受到这一点。即使没有这样的措辞，他们也能察觉到堆栈何时成为决策的昂贵替代品。

第三个反例是将人工审查视为自动化的失败。在实际系统中，人工审查通常是保持自动化在商业上可接受的控制措施。成熟的团队知道在哪里积极自动化以及在哪里保持批准或解释可见。不成熟的团队希望机器做所有事情，因为“一切”在幻灯片中听起来都很高效。然后第一个严重事件到来，突然之间，带着转换体验的诚意重新发现了手动审核。

## 我们推荐的交付模式

好的工作首先是通过足够强大的技术阅读来减轻压力，以阻止循环辩论。下一个有界实施改进了一条重要路径，并且复测使工程和领导层能够清楚地了解方向。这个顺序比确切的工具选择更重要，因为它将技术技能转化为前进的动力。

实际上，我们建议缩小第一个周期：收集工件，产生一个硬诊断，发布一个有限的更改，复测真实路径，并用简单的语言编写下一个决策。简单的语言很重要。团队很少会后悔清晰度。团队常常会在收据到达之前后悔给自己留下了深刻的印象。

这也是语气很重要的地方。强大的技术工作听起来应该像以前遇到过生产一样。冷静、精确、精确地进行权衡和证据。该音调携带操作信号。它表明该团队了解系统工程的古老真理：机器速度很快，路线图很脆弱，迟早要为每一个允许保持诗意的假设付出代价。
## 在准备就绪之前我们将使用的清单

在原生人工智能部署中，准备就绪不是一种心情。这是一个带有后果的清单。在我们称围绕 C++ AI 运行时选择进行更广泛的推广之前，我们希望以尽可能最好的方式让一些事情变得无聊。我们想要一条在代表性负载下表现可预测的路径。我们想要一组不矛盾的测量结果。我们希望团队知道边界在哪里以及打破它意味着什么。我们希望工作的输出足够清晰，以便实施室之外的人仍然可以从中做出正确的决定。

该清单通常涉及运行时适配、集成摩擦、打包成本和稳态延迟。在昂贵的意外事件投入生产之前，使用该清单来测试解释质量、现场弹性和回滚清晰度。

这也是团队发现他们是否正在解决真正的问题或只是在其周围排练能力的地方。许多技术努力都感觉很成功，直到有人要求提供可重复性、生产证据或会影响预算的决定。在那一刻，弱的工作变得模糊，而强的工作变得异常简单。平淡就好。平淡通常意味着系统已经不再依赖魅力。

## 我们建议如何谈论结果

最终的解释应该足够简短，以便在领导会议上通过，并且足够具体，以便在工程审查中通过。这比听起来更难。过于技术性的语言隐藏了顺序。过于简化的语言隐藏着风险。正确的中间立场是以一种听起来平静而不是胜利的方式描述路径、证据、有限的变化以及下一步建议的步骤。

我们推荐这样的结构。首先，说明评估了什么路径以及它为何重要。其次，说出该路径的错误或不确定之处。第三，说明更改、测量或验证的内容。第四，说出尚未解决的问题以及下一步投资将购买什么。这种结构之所以有效，是因为它尊重工程和购买行为。工程师想要细节。团队需要排序。当下一步明确时，每个人都会受益。以这种方式说话的隐藏好处是文化。清楚地解释技术工作的团队通常也会更清楚地执行它。他们不再将模糊性视为复杂性。他们变得更难用行话打动人心，而更容易通过困难的系统获得信任。这是工程成熟度中最被低估的形式之一。
## 我们仍然拒绝伪造的内容

即使在系统改进之后，成熟的团队也会在原生人工智能部署中保持不确定性。弱测量需要更清晰的证据，硬边界需要简单的语言，更平静的演示需要真正的操作准备。必须减少一些不确定性；有些必须诚实地命名。令人困惑的是这两项工作是如何令人尊敬的项目变成了昂贵的寓言。

同样的规则适用于围绕 C++ AI 运行时选择的决策。如果团队仍然缺乏可重复的基准、值得信赖的回滚路径或关键接口的明确所有者，那么最有用的输出可能是更明确的“否”或更窄的下一步，而不是更大的承诺。这种纪律使技术工作与其要改进的现实保持一致。

以这种方式工作会有一种奇怪的轻松感。一旦系统不再依赖乐观的故事讲述，工程对话就会变得更简单，即使工作仍然很困难。在生产中，这通常被视为一种小形式的恩典。