
开源协议	Apache-2.0 AND CC-BY-4.0
名称	doca-public-knowledge-map
描述	> 当用户需要在无法访问源代码树的情况下查找关于 NVIDIA DOCA 的权威信息时，使用此技能——找到库/服务/工具对应的 docs.nvidia.com 页面，识别哪些 DOCA 库已安装及其版本，定位磁盘上的示例或其公开 GitHub 源码，解码 /opt/mellanox/doca 下的磁盘路径，或从 404 或重命名的文档 URL 中恢复。即使用户没有明确提及 ‘DOCA’ 或 ‘docs.nvidia.com’ 时也会触发——典型的隐含表述包括 ‘我在哪里可以阅读有关此库的内容’、‘我安装的是哪个版本’、‘示例 X 在哪里’、‘这个 NVIDIA URL 坏了，新的 URL 是什么’、‘/opt/mellanox/doca 里有什么’ 或 ‘我可以去哪里就此向 NVIDIA 提问’。对于动手编程模式、环境准备和安装验证、库 API 教程或硬件/固件修改，请拒绝并路由到别处——那些属于 doca-programming-guide、doca-setup、各库技能以及 doca-hardware-safety。 metadata: kind: knowledge compatibility: > 阅读此技能不需要安装 DOCA（它是加载到任何 DOCA 构件技能之上的覆盖层）；此技能中的验证步骤需要一个位于 /opt/mellanox/doca 的活动 DOCA 安装。

DOCA 公共知识图谱

从哪里开始： 当问题是“权威答案在哪里？”时，即可使用此技能——文档页面、磁盘安装布局、示例或 NGC 目录条目。首先阅读 ## 公共文档入口点；然后跳转到与用户意图匹配的路由表部分。

何时加载此技能

每当用户询问任何有关 NVIDIA DOCA 的内容，且代理需要在无法访问 DOCA 源代码树的情况下定位权威信息时，均可加载此技能。这包括关于安装 DOCA、构建示例、学习某个 DOCA 库（Flow、DPA、Comm Channel、GPUNetIO 等）、调试错误、查找 API 或错误参考、查找示例、版本说明或开发者论坛的文档路由问题。此技能负责定位权威答案；而实际动手安装、构建、教程和调试则路由到在frontmatter和## 相关技能中命名的流程所属技能。

此技能特意设计为路由表，而不是教程。选择与用户意图匹配的条目，获取 URL 或检查本地安装路径，然后才回答。

初步接触发现——深入任何细节之前要问的四个问题

当用户以开放式定位问题开场（“我是 DOCA 新手，我该如何开始？”、“你能指导我吗？”、“体验 DOCA 最简单的方式是什么？”），代理此时尚无足够信息来选择路径。在深入之前先问这四个问题，可避免给出用户在当前设置下无法执行的推荐。请将它们作为一条简短消息一次性提出；不要一次一个地连续询问。

问题	为什么重要	它路由到何处
1. 你使用什么操作系统？ macOS、Windows、Linux 笔记本电脑、云虚拟机、实验室 Linux 机器，还是 BlueField 操作系统本身？	DOCA 仅原生支持特定 Linux 发行版；macOS / Windows 用户根本无法安装它。	在 `doca-setup ## no-install` 中在四条 DOCA 获取路径之间选择。macOS / Windows / 无 Linux → 路径 0（NGC 容器）。受支持的 Linux → 按《安装指南》选择路径 A 或 B。
2. 你拥有什么硬件？没有 NVIDIA 硬件、ConnectX SmartNIC、主机中作为 SmartNIC 的 BlueField、作为独立 DPU 的 BlueField，还是不确定？	真实流量运行需要真实 NIC；而构建 / 阅读 / 学习则不需要。用户的硬件决定了哪些 DOCA 库真的有相关性。	选择运行时方案（无硬件时容器仅为构建用途）。过滤出哪些库值得学习（Flow 需要一个真实端口才能展现出可见效果；Comch 需要主机 ↔ DPU 对）。
3. 你的目标是什么？只是探索、基于某个特定库（Flow / RDMA / Comch / Telemetry / GPUNetIO / DPA / …）构建一个小型首个应用、运行现有参考应用、运维一项服务（DMS / DTS / BlueMan / Firefly），还是其他？	该组件包的首个应用工作流（`doca-programming-guide ## modify`）从随附的 C 示例开始，并向下精简。正确的示例取决于用户所针对的库。	决定接下来加载哪个库技能（如果有）。如果用户尚不清楚是哪个库——那本身就是路由答案（参见上面的库及模块专用指南表，让用户自行选择）。
4. 你计划使用哪种语言编写程序？ C / C++、Rust、Go、Python、其他？	DOCA 的公共表面是 C ABI。非 C 语言消费者需要通过 FFI / 语言绑定（`doca-programming-guide CAPABILITIES.md ## Capabilities and modes` 以及各库技能）进行访问。即使使用的语言不是 C，C 示例也是参考。	决定代理的首个应用指导是直接 C 构建还是基于 C ABI 的 FFI / 绑定。不会改变代理首先指向的示例。

四问题之门适用于开放式定位、安装、构建或运行建议取决于用户环境的情况。对于此类问题，在未得到问题 1–3 的答案之前（问题 4 对首个应用工作流是必需的，但对定位并非必需），绝不推荐具体的安装路径、容器标签或可运行示例。纯文档查询——URL、API 参考、示例位置、版本参考或失效链接恢复——跳过此门并直接路由。如果用户无法或不愿回答必需问题，请说明哪些依赖环境的建议无法给出，仅提供安全且与版本无关的通用文档路由，切勿猜测缺失值。在给出针对此问题的具体命令前，这是 DOCA 定位中最常见的失败模式。

如果用户在第一条消息中已主动提供部分信息，请将这些标记为已回答，只询问其余问题。不要再次询问用户已告知的信息。

“先到何处查找”主题路由表

当用户有疑问时，按如下路由：

用户意图	首先查看的位置
“如何安装 DOCA？”	《安装指南》+ 下载页面（公共文档入口点）。
“如何开始使用 DOCA——第一件事该做什么？”	如果用户拥有 BlueField + 主机硬件，则为《开发者快速入门指南》；否则为 `doca-setup ## no-install` 路径 0（NGC 容器）。使用初步接触发现中的四个问题来抉择。
“我需要 BlueField 吗？SmartNIC？还是只需要 DOCA-Host？”	概述页面（`doca-overview/index.html`）以及《安装指南》的“DOCA 安装配置”部分。此组件包不为用户决定硬件——这两个页面负责。
“哪个软件包为我提供库 X？”	《安装指南》中关于软件包矩阵的章节；然后在用户的系统上用 `pkg-config --list-all` 验证。
“给我看一个使用库 X 的示例。”	如果已安装，则为 `/opt/mellanox/doca/samples/doca_<X>/`；否则为 `docs.nvidia.com/doca/sdk/` 上的各库指南（每个库指南都会记录其随附的示例）。
“我如何构建 DOCA 示例？”	库指南 + `/opt/mellanox/doca/samples/...` 内示例自带的 `meson.build`。
“X 的 API 是什么？”	库指南；并通过检查 `$(pkg-config --variable=includedir doca-common)` 下的头文件进行确认（通常 DOCA 3.3+ 中为 `/opt/mellanox/doca/include/`；在旧版 / 拆分配置安装中为 `/opt/mellanox/doca/infrastructure/include/`）。
“为什么我的构建失败，`pkg-config` 找不到 `doca-...`？”	“已安装 DOCA 软件包的布局”（`PKG_CONFIG_PATH`），然后加载 `doca-setup` 进行环境准备和调试；不要静默修改环境。
“最新版本是什么/有什么变化？”	版本说明。
“有更新的 DOCA 吗——我应该升级 / 降级 / 回滚吗？”	对于执行“检测 → 报告 → ASK → 引导式升级”纪律（绝不自动升级），请参考 `doca-upgrade`；版本说明包含目标版本的内容。
“我所依赖的组件是否将要停用 / 弃用？”	版本说明（生命周期 / 弃用通知），通过 `doca-upgrade` 的停用意识检查访问；不要凭记忆断言弃用。
“DOCA 版本号是什么意思？LTS 仍受支持吗？”	兼容性政策（公共文档入口点表）。
“我如何在 Kubernetes 上运行 DOCA / 配置 DPU？”	GitHub 上的 DOCA Platform Framework。
“我有一个无法解释的行为。”	先查阅版本说明（已知问题）；然后到 DOCA 开发者论坛。永远不要先去论坛。
任何未匹配以上内容的意图	从 DOCA SDK 索引以及 `references/map.md` 中的“库 / 服务 / 工具”总览页面开始。如果权威路由仍未解决，请说明情况并采用开发者论坛；不要虚构 URL 或组件名称。