试点已在本地与板端 Linux 容器完成双树对照验证（kb_master 基线 vs kb_pilot 应用 30 卡导航补丁，同基点 19883c1d）。结论：检索轮次 -79%、候选列表输出 -50%、模式卡链接可达 0% → 100%，且不引入任何门禁回归。
1. 门禁验证（check.sh，Linux 容器）
内容相关门禁全部通过且 pilot ≡ master：
| 门禁 | 结果 |
|---|---|
| knowledge_lint --strict-navigation | checked=7867，P0/P1/P2=0（164 个新链接全部解析） |
| sync-indexes --check | 662 indexes，stale 0 |
| index build + verify --level full | ok，cards=7205 |
| 检索回归 run_retrieval.py | 29/29 PASS，recall@k=1.000，MRR=1.000（无排序污染） |
| trace-ingest 单测 / field_notes / bash -n / archive diff-check | 36 OK / PASS / OK / RC=0 |
check.sh 中另有 4 个 evals 单测失败、ruff 206 错、quality p95 时延超标——经同机基线树对照确认全部先存于 master 19883c1d（p95：基线 3139.5ms vs pilot 3174.8ms，差 1.1%；4 个测试与 ruff 基线完全同败），与本变更无关，明细见第 3 节。
2. A/B 检索动线实测（核心数据）
方法：6 个链路拼装任务（队列生命周期 / DataCopyPad UB→GM / Tensor API 搬运构造链 / 核内同步 / 核间同步 / Matmul 链），固定确定性策略模拟 ascendc-api-knowledge-query 动线——入口卡标题检索 → BFS 深度 2 正文链接 → 未覆盖卡片按标题补搜（含 skill 规定的 stable 零命中后 draft 补搜回退）；对 master 公平计入其既有正文链接可达性（含经算子卡的回链）。
| 指标 | master 基线 | pilot | 变化 |
|---|---|---|---|
| 检索调用次数（search） | 34 | 7 | -79% |
| 候选列表输出总量 | 34,747 B | 17,455 B | -50% |
| 链路成员经链接直达 | 15/24 | 24/24 | +9 |
| 模式卡经链接直达 | 0/8 | 8/8 | 0% → 100% |
| 模式卡最终可获取（含补搜） | 7/8¹ | 8/8 | — |
¹ guides/matmul/k_partition_and_partial_sum_reduction.md 在基线上连 draft 补搜也无法召回（文本匹配不中），链接是唯一路径。
逐任务明细（searches / cand_bytes，master → pilot）：T1 队列 10/11991B → 1/2621B；T2 DataCopyPad 7/4640B → 1/2881B；T3 Tensor 链 5/3955B → 1/2261B；T4 核内同步 3/1670B → 1/1146B；T5 核间同步 3/5521B → 1/2434B；T6 Matmul 6/6970B → 2/6112B（入口 matmul_config 为 draft，双侧对称多 1 次 stable 零命中 + draft 补搜）。
说明：轮次降幅高于 Issue 预估的 30-50%，主因是模式卡（跨 API 联动约束的载体）在基线上完全不可链达、且多为 draft + 空 platforms 导致标准平台过滤检索不可见——补链不仅省轮次，而是把"唯一可达路径"接通了。每次省掉的 search 调用还伴随一次 agent 推理回合与子进程执行，实际时延收益与轮次成正比。
3. 先存问题清单（与本变更无关，建议另行 Issue 处理）
- guides 蒸馏模式卡普遍 draft + 空 platforms：标准检索动线（--platform 过滤 + stable）完全不可见，draft 补搜也只能按"平台待核验线索"使用；正文链接是其唯一 sanctioned 可达路径——本 PR 补链后 8/8 直达。
knowledge/ops/ascendc/optimizations/fa_cross_core_sync_workspacequeue.md与p_p9_simd_vs_simt_selection.mdfrontmatter 引号未闭合（yaml ScannerError），是 test_knowledge_cards_use_okf_core_fields ERROR 的根因。- 3 张 runbooks 卡尾随空格（test_markdown_structure FAIL 根因，如
ol_412_dav_m200_ascend310p3_compute_dtype_scope_is_fp32.md）。 - ruff 版本差异：板端 ruff 0.16.9 对存量代码报 206 错（基线与 pilot 完全相同），CI 环境应为较旧版本。
- 4 个 evals 单测失败（上述 2/3 项 + retired a5 引用 + registered structure）在 master 19883c1d 即存在，CI 未见拦截，建议核对 CI 实际执行的门禁范围。
PR 可提交，欢迎 committer 检视。
【Issue #23 评论 · 第 2 批：全量关系挖掘 + 对抗验证 + 64 卡落地】
第 1 批试点（4 链路 30 卡）验证了动线价值后，第 2 批将组合关系从"人工选链"升级为"全量证据挖掘 + 对抗验证"，并首次覆盖 C API 与 SIMT 体系。
1. 方法流水线
四层证据全量挖掘（2,865 API 卡、581 张算子卡声明的 6,926 个固定提交源码文件、331 个 SDK 官方样例 kernel、908 张模式卡）：
| 证据层 | 内容 | 产出 |
|---|---|---|
| A 卡内示例 | API 卡调用示例代码块的调用语法抽取 | 8,899 条边 |
| B 模式卡提及 | guides 正文 API 提及（回链缺口定位） | 8,925 组 |
| C 算子源码 | 算子卡声明源码的独立直挖（token 级，注释剥离） | 41,746 共现对 |
| D SDK 样例 | .asc kernel 全量扫描 | 8,690 共用对 |
度量引擎：全部 47,656 对计算 lift、双向条件概率、场景多样性、场景内条件率，自动四档分类（hub_noise / low_support / gray / scenario / deterministic）。
对抗验证：16 个独立 subagent 分批评审 512 对 + 12 链（每对附度量 + 原始代码行证据，可读知识卡反驳），112 对 LINK 存活、390 对反驳成立。
2. 对抗验证发现的 10 类系统性噪声（原始共现数据不可直接使用的原因）
类级同名方法碰撞（GetTiling/GetPhyAddr/Reset 等多类同名，占反驳 30%）、L0 op 层级碰撞（l0op::GroupNorm 制造 lift=193 假确定性）、互斥替代路径误读（LayerNorm vs Welford 二选一分支）、字符串/幽灵伪影（Broadcast 匹配报错字符串、AsyncGetTensorC 全语料零调用）、注册样板标志链全对共现、lift 与机制负相关实证（lift>2.0 几乎全为噪声）、hub 内机制例外、arch 变体错配（2201 卡配 3510 证据）、方向错配（store/load l2 cache 枚举方向特异）、转换环 vs 分支伪共现。
期间还修复了挖掘词典的命名盲区：原过滤器漏掉 C API（asc_* 小写）与 SIMT（__* 内建），修复后 C API 95 卡、SIMT 23 卡获得使用证据——C API 的组合证据源是 36 个官方样例（生产算子仓为 C++ 不用 C API），SIMT 主要来自算子源码层。
3. 第 2 批落地（PR：feature/kb-api-combo-navigation-b2）
64 卡文末导航段 / 131 链接，来自 112 对验证组合中的 76 对（25 对涉及第 1 批已改卡推迟第 3 批避免冲突、1 对变体错配剔除、1 对低置信剔除）。覆盖九条链路：
| 链路 | 代表组合（机制） |
|---|---|
| 事件同步 | GetTPipePtr→FetchEventID→SetFlag/WaitFlag（返回值直接入参） |
| tiling 流水线 | 结构定义↔注册↔按名解析↔TPL key 编码（顺序/类型契约） |
| 950 Reg 类型集 | RegTensor/MaskReg/MaskMergeMode/RegLayout/SatMode（同一指令操作数与修饰组） |
| matmul 操作数契约 | SetTensorA/B、SetAType/BType/CType×TPosition（跨 host/kernel 侧位置声明一致） |
| C API 同步/搬运 | AscSyncNotify↔AscSyncWait（卡片明文配对）、asc_copy×asc_loadalign/storealign（数据流闭环） |
| SIMT 转换环 | __float2half↔__half2float（下变换→计算→上变换） |
| Welford / MrgSort / user workspace / 架构门控 | 管线内配对、寻址配对、跨核协作、GetCurNpuArch 门控 |
4. 验证
- lint --strict-navigation：checked=7867，P0/P1/P2=0
- 检索回归（--quality-gate，70 真实场景用例）：43 PASS 0 FAIL，recall@k=0.548 / MRR=0.459 与 93caf63f 干净基线逐位一致
- 归档镜像卡正文零改动（文末追加受控例外 + updated_at 提升）
- 112 对验证组合每条附机制全文 + 证据代码行 + 卡片路径，可人工复核（对抗报告 1,400+ 行）
完整方法论与数据（含 512 对逐对裁决、10 类噪声分析、12 条验证链）：adversarial_report.md / curated_relations.json（可复现脚本与 16 个裁决文件一并归档）。
第 1 批 PR 合入后，第 3 批将补上推迟的 25 对（队列生命周期补全、事件同步接入批次 1 卡片）。
【合并说明】两批组合导航 PR 已合并为单一交付，并完成机制知识进卡。
变更
- PR 合并：原 PR #99（试点 4 链路，30 卡）已并入 PR #100（对抗验证批次），#99 关闭。两批本就是同形态变更（文末导航段），拆分仅因先后完成；合并后零文件冲突，评审一次完成。
- 机制摘要进卡：导航段从纯指针升级为"指针 + 机制一句话"——
修改前：- [FetchEventID](...)
修改后：- [FetchEventID](...)——FetchEventID 返回的 TEventID 直接作为 SetFlag/WaitFlag 入参
共 147 条既有链接获得机制注解（取对抗验证裁决核心句），17 对此前因两 PR 冲突而推迟的组合补入（34 条双向链接）。 - 覆盖闭环：101 对卡片路径有效的验证组合全部实现卡间双向可达（95 对经导航段、6 对原正文已有官方交叉引用如 asc_sync_notify↔asc_sync_wait 的卡面配对声明）。
交付形态（PR #100）
- 95 张知识卡、330 个链接、三个提交（试点 + 对抗验证批次 + 合并富化）
- 验证：lint strict-navigation 7867 卡 0 问题；检索回归 43 PASS，recall@k=0.548 / MRR=0.459 与基线逐位一致
- 链路覆盖 13 条：队列生命周期、UB↔GM 搬运、同步配对、matmul、事件同步、tiling 流水线、950 Reg 类型集、matmul 操作数契约、C API 同步/搬运、SIMT 转换环、Welford、MrgSort、user workspace/架构门控
后续
组合卡蒸馏（链路骨架代码 + 成员职责 + 跨 API 联动约束的知识密度层）将作为独立提案另行推进——本 PR 的 112 对验证机制与 12 条验证链即其原料。
注：上一条评论是提交脚本误操作重发的旧内容（batch-2 交付评论，原文见此前发布），内容本身仍然有效，请以时间线最早的那条为准，本条可忽略。
效果证据补强：真实 Agent 算子生成任务 A/B 验证（PR #101 提交 bd86f5f6）
在板端检索层 A/B（34→7 轮，-79%）基础上，补充了端到端 Agent 验证：4 个独立 general agent（2 任务 × 2 组），同一 prompt 模板（强制"先检索后编码、禁止使用先验知识"），唯一差异是知识库版本——A 组 master 基线（93caf63f），B 组含组合卡的 PR 分支。
定量结果：
| 指标 | 任务 1（静态 Tensor matmul） | 任务 2（Cube+Vector 融合） |
|---|---|---|
| 检索次数 | A:7 → B:2（-71%） | A:6+5 次目录探查 → B:5（-55%） |
| 读卡数 | A:20 → B:14 | A:14 → B:18 |
| 产出 checklist | A:5.5/7 → B:7/7 | 双方 5/5（但路线不同，见下） |
定性发现（比轮次更重要的是产出质量差异）：
- 范式污染消除：A 组任务 1 产出 C++ tensor_api 混搭 C API 同步接口的骨架（
asc_lock替代Mutex::Lock、asc_init替代InitSocState）——每个 API 单独合法，组合后跨命名空间不可编译，这是碎片化检索的典型产物；B 组首查 rank-1 命中tensor_api_static_cube_full_chain，全链 C++ 形态无混用，且资源级 MutexID 映射、L0C 跨 K 循环持有、init_with_zero首块语义、2201/3510 arch 边界全部正确。 - 信息完整度改变实现路线：任务 2 中 A 组因信息碎片化选保守路线（
__mix__(1,1)单 AIV + 高阶 API + 30 行手写 ND2NZ 重排，自声明未验证）；B 组经cube_vector_fusion_pattern直接掌握 950 双 AIV 完整约束（mode=4、flagId+16、WaitFlag 显式 modeId、DataCopyPad 非对齐搬运），实现了完整__mix__(1,2)双 AIV 形态。 - B 组读卡量不必然减少（任务 2 反而更多），但阅读从"盲搜-修正螺旋"变为沿组合卡链接的定向遍历——组合卡的核心价值是把检索收敛到正确的起点，并防止跨 API 层混搭。
局限（如实说明）：单次运行无重复采样（agent 行为有方差）、checklist 评分非盲评、产出代码未上板编译；结论与板端检索层 A/B 方向互证。
请先说明问题和使用场景，再描述建议方案。单纯申请补充某项技术知识时，请使用“Knowledge-Request|知识需求”。
Scope / 建议范围
检索、索引或图谱
Background / 背景与问题
现状：knowledge/ops/ascendc/apis/ 按一卡一 API 组织（3234 个 md：SIMD 1890、SIMT 766、Utils 183、附录 23、AI CPU 3），API 卡为官方文档归档镜像，单卡内容完整但相互独立。而真实算子开发中 API 几乎总是成链使用：TPipe.InitBuffer → AllocTensor → EnQue → DeQue → FreeTensor 队列生命周期；make_frame_layout → make_tensor → copy 搬运构造链；SetFlag/WaitFlag 配对；Matmul init/compute/tiling 链——跨 API 的联动约束（对齐 × 步长 × 队列深度 × 事件时序）分散在多张卡中。
组合知识其实已存在：guides/ 树有 100+ 张蒸馏模式卡（memory 24、data_movement 7、matmul 21 等），例如 tquebind_reuse_and_intermediate_compute 完整覆盖 TQueBind+DeQue+EnQue+SetWaitFlag+FreeTensor 的联动约束。但检索动线断裂：
受影响用户与场景：所有使用 ascendc-api-knowledge-query / knowledge-query 进行 Ascend C 算子生成、API 问答、跨 API 适配的 Agent 与开发者。Agent 生成一个算子典型需要 5-15 轮检索（每轮 = 候选列表数百 token + 卡片全文 2-6k token + 一次推理回合），链路成员靠逐轮发现；联动约束自行拼合，拼错则进入成本更高的 debug 轮次。
Desired outcome / 期望结果
期望行为：Agent 按准确 API 名检索并阅读任一高频 API 卡时，能在该卡文末直接看到「配套 API 与常见组合」导航段，一次阅读即获知整条链路的成员 API 与对应模式卡，并通过现有 read --card --link 机制直达；模式卡反向链接成员 API 卡，双向可达。归档镜像正文零改动（仅文末追加，符合 AGENTS.md「可在文末追加普通知识卡链接」受控例外）。
可验收结果（试点 4 链路已在本地实现并验证）：
Proposal / 建议方案
两步走，本 Issue 为第 1 步（纯导航、零新卡）。
形态与规则：
试点范围（已本地完成，30 files +284/-30，其中 30 行为 updated_at 变更）：
第 2 步（视试点反馈另行提案）：为无模式卡覆盖的高频组合蒸馏组合卡，放 guides 树，形态为「链路骨架代码 + 成员职责 + 联动约束 + 成员卡链接」，预计 20-50 张覆盖大头，不按 API 两两组合展开。
Impact / 影响与兼容性
Alternatives / 备选方案
Checklists / 提交确认