@cannbot-plugin/cannbot-harness 0.0.0-stage → 0.1.5

package/assets/ops-direct-invoke/skills/cannbot-dsl-unit-planner/references/decomposition-checks.md

@@ -0,0 +1,46 @@
+# 可实现性与边界检查
+
+规划时阅读本文件；字段见 [Unit 格式](unit-format.md)。
+
+## 设计约束与实现选择
+
+先区分资料中的强制承诺、允许选项、示意伪码和待定候选。只将强制承诺纳入 `design_constraints`；候选机制通过补证定选，不把所有候选同时冻结。约束应来自规格、用户要求或明确的设计结论，并指向实际章节。
+
+数值语义与实现结构分别验收。设计规定的执行域、数据通路、同步、资源上界、精度域、复杂度和发布契约，不能只凭 Golden 通过证明。选项范围内的 API 替换或内部重构，可以由实现选择；改变强制承诺时返回设计，说明失败证据、替代路线、语义/结构/资源/规模影响和受影响 Unit。既有设计修订授权沿用，不增加泛化的审批要求。
+
+设计是否允许逐步演进需明确：中间实现可只覆盖合法子域或部分调度规模，但必须保持该子域的数值语义与必需契约，并将最终机制分配给后继 Unit。子域最小数值闭环不必同时交付全域最终流水；若某机制不能后置且无法实现，应返回设计，而非扩大首 Unit 掩盖不可实现性。
+
+## 关键能力在首次使用前闭合
+
+从“待验证”“机制候选”“实现期定选”等条目中识别影响关键路径的事实。API 签名、单独编译和通用环境通过，不证明组合通路的设备语义。
+
+每项前置补证记录设计依据、已有证据层级、待确认事实、适用环境/输入域、成功判据、首次使用动作和失败返回点。证据层级应与承诺相匹配：
+
+- 组合计算和搬运需覆盖实际采用的数据布局、类型、形状与边界，而非空程序编译。
+- 跨执行域交接需真实生产/消费及多代复用的可见性证据，单一执行域的程序序不能替代。
+- 新原语或自实现算法需验证实际采用的转换、索引、mask、资源与复杂度。
+- 发布/加载契约若影响前序工厂或 ABI，在首次真实路径先确认；全变体完整枚举留给全部能力完成后的 Unit。
+
+规划引用已有证据或声明待补证，不虚写通过。补证归属于首次使用它的 Unit，证据落实为验证义务或明确的检查；孤立实验本身不冒充算子能力。失败后该能力的 `provides` 不成立，依赖它的后继不具备实现前提。已知失败且没有保留承诺的路线时，返回设计并重划，不能用“实现期定选”放行。
+
+## 能力边界、依赖与保留面
+
+首个计算 Unit 可限定布局、类型、分支和属性组合，明确取值与规模；当前子域必需的校验、数学语义、边界与初始化随闭环交付。其他合法域在 out_of_scope 指明后继归属。仅按接口分支名称宣布覆盖，不足以证明输入域完整。
+
+独立流水框架要能验证实际执行域之间的数据交接、等待/释放和覆盖保护；若设计要求重叠，还需能够区分串行和重叠执行。后继计算引入后仍须验证框架成立。占位计算、阶段名称和不同断言类型不是独立能力的依据。
+
+增量按可分离的交付能力与主要故障面组织，例如分块累积、边界安全、布局解释、可选语义或路径组合。前序行为与设计承诺保持，内部实现可以重构；记录受影响契约并回归相关能力。若前序只是假骨架、后继必然推翻其已验收结论，调整边界。
+
+`dependency_reasons` 说明能力来源或设计要求的先后关系。能力依赖须满足完整输入域、输出、错误与生命周期契约，字符串匹配不足以证明兼容。正交能力不因编号或共享文件自动串联；实际修改文件写入 `scope.source_files`，未知路径保留空列表，不假定可以同时修改共享文件。
+
+## 可区分验证与实际触发条件
+
+每项义务说明正确实现必须成立的行为、至少一种错误实现、输入触发条件和证据来源。若正确性依赖数值与结构同时成立，应明确要求同一次真实调用提供联合证据；分别通过的输入不能替代这一要求。
+
+- 多块义务按实际参与计算的有效工作量跨块定义，不能用分配形状代替。检查后续块的只读输入生命周期、累积状态、重标定、写回与复用。
+- 多槽义务按真实在途任务及复用代次定义；连续调用变化输入与形状，区分旧值复用。需要调用序列时写清顺序、状态存活期和每次结果的判据。
+- 集合/去重/筛选义务使用非退化输入，使遗漏该步骤确实改变输出；退化输出不能证明实现了步骤。
+- 结构义务指明真实事件采集来源、可执行判定和错误实现的差异；静态配置或按预期返回的 snapshot 不能自证。
+- 规模检查算法复杂度、资源峰值和状态生命周期，耗时门槛只采用设计或用户提供值，并明确测量条件。
+
+不能表达触发输入、调用序列或所需结构判定时，记录证据缺口交调用方处理；不以“关联了一个 TDD Case”替代义务成立。

package/assets/ops-direct-invoke/skills/cannbot-dsl-unit-planner/references/unit-format.md

@@ -0,0 +1,77 @@
+# Unit YAML 格式
+
+每份 `U*.yaml` 只有一个 `unit` 对象，描述可交付能力、实现边界、前置事实与检验义务。
+
+```yaml
+unit:
+  unit_id: U01
+  title: <可交付的纵向能力>
+  kind: minimal_operator # 或 pipeline_framework / feature_increment
+  design_sources:
+    - file: <设计资料中的实际文件路径>
+      section: <对应章节或阶段>
+    - file: <相关执行路径的实际文件路径>
+      section: <对应分支内容>
+  depends_on: []
+  dependency_reasons: {} # 非 root：每个依赖 ID 对应真实能力或明确的先后要求
+  requires: []
+  provides: [<完成后可使用的能力>]
+  boundary:
+    independent_capability: <可观察的新能力>
+    failure_isolation: <失败时可保留的前序结果>
+    merge_rejected_because: <为何不与前一单元合并；首单元写 root>
+  design_constraints:
+    - source: <设计实际文件与章节>
+      commitment: <受约束的执行域/数据通路/同步/资源/复杂度等>
+      obligation_ids: [VO-U01-CORE] # 可引用自身或依赖闭包义务
+      review_evidence: [] # 或 [{artifact: <计划核对的产物>, check: <检查内容>, pass_criteria: <通过判据>}]
+  scope:
+    supported_domain: <完成时支持的布局、dtype、分支、属性、可选输入及规模>
+    implementation_surfaces: [<设计中的模块、阶段或分支>]
+    source_files: [] # 只填已确认的实际路径
+    out_of_scope: [<后续能力>]
+  implementation:
+    feasibility_checks: [] # 关键未决项按下方格式填写；没有则为空
+    entry: <最小端到端或增量实现>
+    steps: [<必要的实现动作>]
+  verification_obligations:
+    - id: VO-U01-CORE
+      kind: numerical # 或 structural / semantic / device
+      design_sources: [<Validation.md 的实际路径>, <设计资料中的实际文件路径>]
+      behavior: <必须成立的行为>
+      must_distinguish: [<至少一种可能混淆的错误实现>]
+      observable_result: <可从输出或运行证据观察的结果>
+      coverage_axes: [<需要变化的输入或执行维度>]
+      input_conditions: [] # 可选；可物化验证的 dimension/numel/count/unique_count 条件
+  failure_return: <具体失败证据、返回的设计章节、受影响能力与后继阻断；修订后同步重划>
+```
+
+`supported_domain`、`dependency_reasons`、`design_constraints` 与 `feasibility_checks` 为新增规划字段，不改变原有 kind 和检验义务 kind。无相关设计承诺时 `design_constraints` 可为空；约束引用自身或前序义务，增量只记录新增或改变的约束。已有 Unit 迁移时补充实际事实，不虚填已验证。
+
+关键未决项格式（置于 `implementation` 内）：
+
+```yaml
+feasibility_checks:
+  - design_source: <实际文件与章节/未决项 ID>
+    question: <需要确认的组合能力或设备行为>
+    known_evidence: <已有证据路径及层级；无证据写未验证>
+    required_evidence: <补证适用环境、真实形状/执行路径及成功判据>
+    before_step: <本 Unit 首次依赖该能力的动作>
+    obligation_ids: [<验证该补证判据的真实义务 ID>]
+    review_evidence: [] # 独立检查按 artifact/check/pass_criteria 声明
+    on_failure: <返回具体设计章节，阻断本能力及依赖后继>
+```
+
+补证是 Unit 内的前置实现动作，不新增 probe Unit kind 或性能义务 kind。`provides` 仅在补证、实现与检验义务均通过后成立；记录前置检查不代表已经通过。
+
+首个 `minimal_operator` 应有数值检验义务；独立的 `pipeline_framework` 应有验证真实生产/消费及设计执行域的结构义务。已有设计 Case 可作为来源线索，但 Unit 不预分配 Case ID。若某项义务无法设计可区分的测试，应调整 Unit 边界或回到设计文档澄清事实。
+
+新增规划字段描述证据要求与边界，不代表自然语言设计承诺或人工证据已经通过。可测试的设计约束与补证判据必须同时写入 `verification_obligations`；不能由公开输入和可观察结果判定的项，明确源码、编译产物或设备证据的检查方法。多块、特殊输入关系、连续调用或并行关系等覆盖要求，不能仅因关联的 Case ID 存在就算完成。
+
+验证义务必须有可执行判定：numerical 检查独立参考结果；structural 检查真实执行事件、编译产物或设备 trace；semantic 检查输出形状、类型、与输入的关系或可观察行为；device 检查实际设备行为。错误码行为须有公开接口异常验证。性能目标写入设计验证方案，明确测量条件与通过判据，不用普通数值验证代替性能证据；无法判定的义务应指出缺口，不能仅关联 Case ID 算覆盖。
+
+结构义务的 `must_distinguish` 应覆盖设计可能被数学等价路线替代的风险；`observable_result` 指明事件的实际采集来源与断言，不以静态常量、阶段名称或 Host 按预期生成的事件自证。多块/复用的 `coverage_axes` 使用实际有效工作量与状态存活条件，具体判别示例见 [可实现性与边界检查](decomposition-checks.md)。
+
+`design_constraints` 与 `feasibility_checks` 每项至少填写 obligation_ids 或 review_evidence，后者每项必须有 artifact、check、pass_criteria。不要只写自由文本 evidence。可测试内容写到义务，源码/编译/设备检查由调用方验收。
+
+`input_conditions` 描述检验义务成立所需的输入事实，例如 `{input: x, metric: dimension, axis: -1, relation: ge, value: 129}`；数值取自当前设计，不使用案例中的固定阈值。metric 为 dimension（必须有 axis）、numel、count 或 unique_count；count/unique_count 可按 axis 逐行检查，并以 where 的 min（含下界）、max（不含上界）、eq 过滤有效值。过滤边界为有限数或 `{input: <公开输入名>, dimension: <轴>}`；relation 为 eq/ne/ge/gt/le/lt，value 为有限数。条件应在实际输入上成立；无法表达的事实明确证据缺口。coverage_axes 仍描述需要覆盖的完整行为，不以输入谓词替代设计符合性检查。

package/assets/ops-direct-invoke/skills/npu-arch/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: npu-arch
+description: Ascend NPU 架构知识查询技能。通过芯片型号映射、架构代际划分和 archXX 特性说明，帮助判断目标平台能力、特性支持与条件编译策略。当需要确认芯片型号、NpuArch/SocVersion、架构差异、特性支持或编译分支条件时使用。
+---
+
+# Ascend NPU 架构知识
+
+## 架构代际概述
+
+| 概念 | 说明 |
+|-----|------|
+| **NpuArch** | 芯片架构号，定义指令集和微架构，运行时通过 `GetCurNpuArch()` 获取 |
+| **SocVersion** | 片上系统版本，软件命名标识，运行时通过 `GetSocVersion()` 获取 |
+| **__NPU_ARCH__** | Device 侧编译宏，四位数值，用于条件编译 |
+| **archXX** | 算子仓目录简写，取 DAV 编号前两位（如 DAV_3510 → arch35） |
+| **__DAV_C310__** | 构建系统内部宏，等价于 `NpuArch::DAV_3510` / `arch35` / `__NPU_ARCH__=3510`，不可按数值推断 |
+
+## 完整映射表
+
+完整产品系列 / SocVersion / NpuArch / 芯片型号映射见 [`npu-hardware-params.md` §0 产品映射表](references/npu-hardware-params.md#0-产品映射表)。
+
+## 获取当前架构
+
+```cpp
+#include "utils/tiling/platform/platform_ascendc.h"
+
+auto ascendcPlatform = platform_ascendc::PlatformAscendC(context->GetPlatformInfo());
+NpuArch npuArch = ascendcPlatform.GetCurNpuArch();         // DAV_2201 / DAV_3510 / ...
+platform_ascendc::SocVersion socVer = ascendcPlatform.GetSocVersion();
+```
+
+`GetCurNpuArch()` 失败返回 `NpuArch::DAV_RESV`，`GetSocVersion()` 失败返回 `SocVersion::RESERVED_VERSION`。
+
+## DAV_3510 相对 DAV_2201 的关键变化
+
+> 详细硬件参数真值见 `references/npu-hardware-params.md`。运行时必须以 `PlatformAscendC` 接口获取实际值，禁止硬编码。
+
+### Buffer（同架构内通常一致）
+
+| Buffer | DAV_2201 | DAV_3510 |
+|--------|----------|----------|
+| L0C | 128 KB | 256 KB |
+| UB | 192 KB | 248 KB |
+| BT | 1 KB | 4 KB |
+
+### 频率/核数/L2/Memory（因子型号/形态而异）
+
+| 参数 | Ascend910B2 (DAV_2201) | Ascend950PR PCIE | Ascend950PR Server |
+|------|------------------------|------------------|-------------------|
+| Cube 核数 | 24 | 28 | 32 |
+| 频率 | 1.8 GHz | 1.65 GHz | 1.65 GHz |
+| L2 | 192 MB | 112 MB | 128 MB |
+| Memory | 64 GB | 112 GB | 128 GB |
+
+> 详见 [典型SKU示例](references/npu-hardware-params.md#子型号变化参数)。
+>
+> Memory 带宽：950PR 1.6/1.4 TB/s 已由 950 白皮书表3-1 证实，910B2 仍为公开资料与经验值，详见 `npu-hardware-params.md` §4。
+
+### 指令集与微架构
+
+| 类别 | 变化 |
+|------|------|
+| 数据格式 | 新增 FP8 / MXFP8 / MXFP4 / HiF8 Cube MMAD |
+| CV 直通通路 | 新增 L0C→UB、UB→L1、SSBuffer 消息 |
+| 同步机制 | BufferID 替代 set/wait 强配对 |
+| 编程模型 | 新增 SIMT、SIMD-Regbase、NDDMA、CCU 通算融合 |
+
+## 详细文档索引
+
+`references/` 按需加载：
+
+- **`npu-hardware-params.md`** — 硬件参数参考：各架构子型号一致参数、典型SKU示例、基于公开资料与经验值的规格
+- **`simt-arch-guide.md`** — SIMT 架构概念参考：线程层次结构、Warp调度机制、内存空间、UB分区、数据类型、函数调用层级、LAUNCH_BOUND与寄存器数量、SIMT与SIMD核心差异
+- **`npu-arch-guide.md`**：
+  - **典型硬件参数与获取方式**：核数 / Buffer 容量典型值，`GetCoreNumA*` / `GetCoreMemSize` / `aclrtGetDeviceInfo` 接口用法（含硬编码反例）
+  - **DAV_3510 微架构**：AI Core Buffer 层级、MTE 引擎、CV 数据通路改动、BufferID 同步
+  - **SIMT vs SIMD**：硬件能力差异与适用场景
+  - **SIMD-Regbase**：寄存器组、核心优势、代码形态变化
+  - **数据格式扩展**：完整数据类型表、C++ 类型名映射、MXFP Tiling 约束
+  - **NDDMA / CCU**：高维 DMA 用法、CCU 三种通信范式、KFC 调度模型
+  - **架构兼容性检查清单 / 参考信息来源**
+
+## 官方资料来源
+
+- 《[昇腾950 NPU架构白皮书](https://public-download.obs.cn-east-2.myhuaweicloud.com/ascend/%E6%98%87%E8%85%BE950%20NPU%E6%9E%B6%E6%9E%84%E7%99%BD%E7%9A%AE%E4%B9%A6.pdf)》—— Ascend950PR/950DT（DAV_3510）官方规格与微架构真源，章节内容地图见 `references/npu-arch-guide.md` §参考信息来源
+
+> **范围边界**：本技能聚焦架构判断与硬件能力识别。算子目录结构、CMake 配置、文件命名约定等工程模板内容不在本技能范围内。

package/assets/ops-direct-invoke/skills/npu-arch/evals/evals.json

@@ -0,0 +1,356 @@
+{
+  "eval_mode": "text",
+  "evals": [
+    {
+      "id": 1,
+      "title": "架构代际概述与核心概念",
+      "config": {
+        "max_tokens": 150000,
+        "max_tokens_by_model": {
+          "deepseek-v4-flash": 180000,
+          "glm-5": 160000
+        },
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "请介绍 Ascend NPU 的架构代际划分，包括 NpuArch、SocVersion、__NPU_ARCH__、archXX 这几个核心概念的含义和关系。",
+      "expected_output": "回复应说明 Ascend NPU 架构的核心概念：\n- NpuArch：芯片架构号，定义指令集和微架构，运行时通过 GetCurNpuArch() 获取\n- SocVersion：片上系统版本，软件命名标识，运行时通过 GetSocVersion() 获取\n- __NPU_ARCH__：Device 侧编译宏，四位数值，用于条件编译\n- archXX：算子仓目录简写，取 DAV 编号前两位（如 DAV_2201 → arch22，DAV_3510 → arch35）\n- 一对多关系：一个 NpuArch 可对应多个 SocVersion（如 DAV_2201 对应 Ascend910B1~B4、Ascend910B2C、Ascend910_93）",
+      "files": [],
+      "expectations": []
+    },
+    {
+      "id": 2,
+      "title": "产品映射表查询",
+      "config": {
+        "max_tokens": 150000,
+        "max_tokens_by_model": {
+          "deepseek-v4-flash": 180000,
+          "glm-5": 160000
+        },
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "Ascend910B 和 Ascend950PR 分别对应什么 NpuArch 和 SocVersion？Ascend910_93 呢？",
+      "expected_output": "回复应基于产品映射表给出准确映射：\n- Ascend910B：SocVersion=ASCEND910B，NpuArch=DAV_2201，__NPU_ARCH__=2201\n- Ascend950PR：SocVersion=ASCEND950，NpuArch=DAV_3510，__NPU_ARCH__=3510\n- Ascend910_93：SocVersion 运行时映射到 ASCEND910B（非独立枚举值），NpuArch=DAV_2201\n- 说明一对多关系：DAV_2201 对应 Ascend910B1~B4、Ascend910B2C、Ascend910_93",
+      "files": [],
+      "expectations": []
+    },
+    {
+      "id": 3,
+      "title": "硬件参数获取方式",
+      "config": {
+        "max_tokens": 150000,
+        "max_tokens_by_model": {
+          "deepseek-v4-flash": 180000,
+          "glm-5": 160000
+        },
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "在 Ascend C 算子开发中，如何正确获取核数、UB 容量等硬件参数？为什么不能硬编码？",
+      "expected_output": "回复应说明正确的硬件参数获取方式：\n- 使用 PlatformAscendC API：GetCoreNumAic()（Cube 核数）、GetCoreNumAiv()（Vector 核数）、GetCoreMemSize()（Buffer 容量）\n- 反例说明：硬编码典型值（如 constexpr uint32_t CORE_NUM = 32）在跨型号或裁剪 SKU 上会越界或浪费\n- 正确做法：运行时通过接口获取实际值，避免硬编码\n- 示例代码：ascendcPlatform.GetCoreNumAiv() / GetCoreMemSize(CoreMemType::UB, ubSize)",
+      "files": [],
+      "expectations": []
+    },
+    {
+      "id": 4,
+      "title": "DAV_3510 vs DAV_2201 关键差异",
+      "config": {
+        "max_tokens": 150000,
+        "max_tokens_by_model": {
+          "deepseek-v4-flash": 180000,
+          "glm-5": 160000
+        },
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "DAV_3510 相比 DAV_2201 在 Buffer 容量、指令集和数据通路方面有哪些关键变化？",
+      "expected_output": "回复应覆盖 DAV_3510 的关键变化：\n- Buffer 容量：L0C 128→256 KB，UB 192→248 KB，BT 1→4 KB\n- 数据格式：新增 FP8/MXFP8/MXFP4/HiF8 Cube MMAD\n- CV 直通通路：新增 L0C→UB、UB→L1、SSBuffer 消息通路，避免 GM workspace 中转\n- 同步机制：BufferID 替代 set/wait 强配对，简化多流水算子同步\n- 稀疏支持：DAV_3510 不再支持 4:2 稀疏矩阵计算",
+      "files": [],
+      "expectations": []
+    },
+    {
+      "id": 5,
+      "title": "SIMT vs SIMD 架构差异",
+      "config": {
+        "max_tokens": 150000,
+        "max_tokens_by_model": {
+          "deepseek-v4-flash": 180000,
+          "glm-5": 160000
+        },
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "Ascend C 中 SIMT 和 SIMD 两种编程模型有什么区别？分别适用于什么场景？",
+      "expected_output": "回复应对比 SIMT 和 SIMD 的核心差异：\n- SIMT：标量编程（线程视角），Warp 调度（32 线程分组），每 AIV 4 个 Warp Scheduler\n- SIMD：矢量编程（VF 内连续计算），软件展开循环\n- SIMT 适用场景：Gather/Scatter、Hash 插入、随机数、排序（含原子操作）\n- SIMD 适用场景：大块 dense BF16/FP16 矩阵乘/卷积、长向量顺序计算\n- SIMT 仅 DAV_3510 支持，前代架构无法使用\n- SIMT 独有硬件：DCache（最大 128KB，复用 UB 作 Cacheline）、支持 GM 离散访问",
+      "files": [],
+      "expectations": []
+    },
+    {
+      "id": 6,
+      "title": "数据格式扩展与 SIMD-Regbase",
+      "config": {
+        "max_tokens": 150000,
+        "max_tokens_by_model": {
+          "deepseek-v4-flash": 180000,
+          "glm-5": 160000
+        },
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "DAV_3510 新增了哪些数据格式？SIMD-Regbase 架构有什么优势？",
+      "expected_output": "回复应说明 DAV_3510 的数据格式扩展和 Regbase 架构：\n- 新增数据格式：FP8（E5M2/E4M3）、MXFP8（E5M2/E4M3）、MXFP4（E2M1/E1M2）、HiF8\n- C++ 类型名映射：fp8_e5m2_t、fp8_e4m3fn_t、hifloat8_t\n- SIMD-Regbase 核心优势：\n  - 寄存器内计算：减少 UB 访问带宽\n  - OOO 指令双发：Vector 性能提升\n  - 支持非 32B 对齐数据处理\n- 代码形态变化：Membase 的 block/repeat 参数 → Regbase 的 for-loop 显式循环",
+      "files": [],
+      "expectations": []
+    },
+    {
+      "id": 7,
+      "title": "算力公式推导",
+      "config": {
+        "max_tokens": 150000,
+        "max_tokens_by_model": {
+          "deepseek-v4-flash": 180000,
+          "glm-5": 160000
+        },
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "Ascend950PR Server 的 Cube BF16 算力和 FP8 算力分别是多少？怎么推导的？",
+      "expected_output": "回复应给出算力推导公式和计算过程：\n- Cube BF16 算力公式：TFLOPS = M × K × N × 核数 × freq(MHz) × 2 ÷ 10^6\n- BF16/FP16 的 Cube MAC 阵列：M×K×N = 16×16×16 = 4096\n- 950PR Server BF16：4096 × 32 × 1650 × 2 ÷ 10^6 = 432 TFLOPS\n- FP8 的 Cube MAC 阵列更大：M×K×N = 16×32×16 = 8192\n- 950PR Server FP8：8192 × 32 × 1650 × 2 ÷ 10^6 = 865 TFLOPS\n- Vector 算力公式：TFLOPS = vec_calc_size × vector_core_cnt × vec_freq(MHz) × 2 ÷ 10^6",
+      "files": [],
+      "expectations": []
+    },
+    {
+      "id": 8,
+      "title": "正向看护-多 skill 环境下正确触发",
+      "config": {
+        "max_tokens": 150000,
+        "ascend_platforms": [
+          "A2"
+        ],
+        "distractor_skills": [
+          "ascendc-env-check",
+          "ascendc-api-best-practices",
+          "ascendc-docs-search"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "Ascend910B 和 Ascend950 的架构有什么区别？DAV_2201 和 DAV_3510 的 UB 容量分别是多少？",
+      "expected_output": "回复应正确激活 npu-arch skill，回答架构差异和 UB 容量：\n- DAV_2201（Ascend910B）：UB = 192 KB\n- DAV_3510（Ascend950）：UB = 248 KB\n- 架构差异：L0C 容量、BT 容量、数据格式支持、SIMT/SIMD 支持等\n即使在 ascendc-env-check、ascendc-api-best-practices 等相似 skill 共存的环境下，也应正确选择 npu-arch。",
+      "files": [],
+      "expectations": []
+    },
+    {
+      "id": 9,
+      "title": "信息不足时的追问机制",
+      "config": {
+        "max_tokens": 100000,
+        "max_tokens_by_model": {
+          "deepseek-v4-flash": 120000,
+          "glm-5": 110000
+        },
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "请介绍 npu-arch 技能在用户提问信息不足时应该如何处理。当用户只说\"NPU 的参数是什么\"这样模糊的问题时，技能应该追问哪些方面？请简要说明。不需要执行任何操作，只需要介绍知识。",
+      "expected_output": "回复应说明 npu-arch 技能在信息不足时的追问机制：\n- 应主动追问用户具体想了解哪方面信息，而不是直接罗列所有架构知识\n- 可追问的方向包括：架构映射（芯片型号→NpuArch）、硬件参数（核数/Buffer/算力）、SIMT/SIMD 编程模型、数据格式支持、特定芯片的详细规格\n- 追问的目的是缩小范围，提供精准回答而非信息轰炸",
+      "files": [],
+      "expectations": []
+    },
+    {
+      "id": 10,
+      "title": "使用边界-不适用于算子开发模板",
+      "config": {
+        "max_tokens": 100000,
+        "max_tokens_by_model": {
+          "deepseek-v4-flash": 120000,
+          "glm-5": 110000
+        },
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "请介绍 npu-arch 技能的使用边界。它适合什么场景？不适合什么场景？如果要创建算子工程模板应该用什么技能？不需要执行任何操作，只需要介绍知识。",
+      "expected_output": "回复应说明 npu-arch 技能的适用边界：\n- 适合场景：架构判断与硬件能力识别（芯片映射、架构差异、硬件参数、数据格式、算力推导）\n- 不适合场景：算子目录结构、CMake 配置、文件命名约定等工程模板内容不在本技能范围内\n- 推荐替代：创建算子工程模板应使用 ascendc-direct-invoke-template（Kernel 直调工程）或 ascendc-registry-invoke-template（完整自定义算子工程）\n- 核心区别：npu-arch 提供架构知识查询，工程模板类技能提供项目脚手架",
+      "files": [],
+      "expectations": []
+    },
+    {
+      "id": 11,
+      "title": "构建宏不可按名字数值推断",
+      "config": {
+        "max_tokens": 150000,
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "构建系统里的 __DAV_C310__ 是否代表 __NPU_ARCH__=310？它与 arch35、DAV_3510 的关系是什么？",
+      "expected_output": "回复应说明 __DAV_C310__ 是构建系统内部宏，不可从 C310 字样按数值推断；它等价于 NpuArch::DAV_3510、arch35 和 __NPU_ARCH__=3510，应以明确映射而非猜测命名",
+      "expectations": [],
+      "files": []
+    },
+    {
+      "id": 12,
+      "title": "架构查询失败的保留值处理",
+      "config": {
+        "max_tokens": 150000,
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "PlatformAscendC 查询当前芯片时 GetCurNpuArch 和 GetSocVersion 失败，会返回什么？可以继续按 DAV_2201 默认分支执行吗？",
+      "expected_output": "回复应说明失败分别返回 NpuArch::DAV_RESV 和 SocVersion::RESERVED_VERSION，不能静默假定 DAV_2201；应把未知架构作为显式错误或安全兜底路径处理，再补充平台信息",
+      "expectations": [],
+      "files": []
+    },
+    {
+      "id": 13,
+      "title": "同架构不同 SKU 参数不能套典型值",
+      "config": {
+        "max_tokens": 150000,
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "既然 Ascend950PR PCIE 和 Server 都是 DAV_3510，能否把 Server 的 32 个 Cube 核、128GB Memory 和频率硬编码给所有 arch35 产品？",
+      "expected_output": "回复应拒绝硬编码，说明同一 NpuArch 下频率、核数、L2 和 Memory 会随子型号或形态变化；应运行时通过 PlatformAscendC 或设备接口获取实际值，参考表中的典型 SKU 只能作说明，不能当所有 arch35 的真值",
+      "expectations": [],
+      "files": []
+    },
+    {
+      "id": 14,
+      "title": "Vector BF16 支持与总算力构成",
+      "config": {
+        "max_tokens": 150000,
+        "max_tokens_by_model": {
+          "deepseek-v4-flash": 180000,
+          "glm-5": 160000
+        },
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "Ascend950PR（DAV_3510）的 Vector Core 支持 BF16 吗？950PR Server 的 BF16 峰值算力是多少，Cube 和 Vector 各贡献多少？",
+      "expected_output": "回复应明确（昇腾950 NPU架构白皮书 §4.1.2/表3-1）：\n- DAV_3510 的 Vector Core 原生支持 BF16，不存在 BF16 只能用 Cube 的限制\n- 950PR Server BF16 总算力 486 TFLOPS = Cube 432T + Vector 54T\n- 950PR PCIE 档总算力 425T = Cube 378T + Vector 47T\n- 不得再声称 Vector 不支持 bfloat16（过时错误表述）",
+      "files": [],
+      "expectations": []
+    },
+    {
+      "id": 15,
+      "title": "UB 容量口径（512KB vs 248KB）",
+      "config": {
+        "max_tokens": 150000,
+        "max_tokens_by_model": {
+          "deepseek-v4-flash": 180000,
+          "glm-5": 160000
+        },
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "昇腾950 白皮书表4-2 写 UB 是 512KB per AI Core，但 GetCoreMemSize 返回 248KB，这两个数值矛盾吗？Tiling 时应该用哪个？",
+      "expected_output": "回复应说明 UB 容量口径：\n- 不矛盾：白皮书表4-2 的 512KB 是按 AI Core 组（1 AIC + 2 AIV）计的物理容量，即每 AIV 物理 256KB × 2\n- 248KB（INI ub_size=253952）是每 AIV 用户可用值，即物理 256KB − 8KB 预留\n- 结论：单 AIV 物理 256KB / 可用 248KB，组级物理 512KB\n- Tiling 一律以 GetCoreMemSize(CoreMemType::UB) 返回值为准，禁止硬编码",
+      "files": [],
+      "expectations": []
+    },
+    {
+      "id": 16,
+      "title": "950DT/950PR 规格档位与定位",
+      "config": {
+        "max_tokens": 150000,
+        "max_tokens_by_model": {
+          "deepseek-v4-flash": 180000,
+          "glm-5": 160000
+        },
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "Ascend950DT 和 Ascend950PR 分别面向什么场景？各自的核数档位和 Memory 规格是什么？",
+      "expected_output": "回复应说明 950 系列定位与规格（昇腾950 NPU架构白皮书 §2/§3/表3-1）：\n- 950PR：面向高性能推荐、大模型 Prefill 及多模态推理；Cube 32/28 核两档，Memory 128/112GB @ 1.6/1.4TB/s\n- 950DT：覆盖预训练、后训练及推理（含 Decode 与 Prefill）全流程；Cube 36/32/28 核三档，Memory 144/96GB @ 4TB/s\n- (Decode)/(Prefill) 仅为场景侧重标注，并非唯一用途",
+      "files": [],
+      "expectations": []
+    },
+    {
+      "id": 17,
+      "title": "Memory 带宽与信息来源分级",
+      "config": {
+        "max_tokens": 150000,
+        "max_tokens_by_model": {
+          "deepseek-v4-flash": 180000,
+          "glm-5": 160000
+        },
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "Ascend950PR Server 和 PCIE 的 Memory 带宽分别是多少？Ascend910B2 的带宽呢？这些数据的来源是否经过官方证实？",
+      "expected_output": "回复应说明 Memory 带宽及来源可信度：\n- 950PR Server 1.6 TB/s、PCIE 1.4 TB/s：已由昇腾950 NPU架构白皮书表3-1/§4.3 证实\n- 950DT 最高 4 TB/s：白皮书证实\n- 910B2 1.6 TB/s：基于公开资料与经验值，未在 INI 及白皮书中找到直接可核验字段\n- 技能对信息来源分级标注：已证实条目给出白皮书章节，未验证条目明确标注为公开资料/经验值",
+      "files": [],
+      "expectations": []
+    },
+    {
+      "id": 18,
+      "title": "NDDMA 与 BufferID 机制细节",
+      "config": {
+        "max_tokens": 150000,
+        "max_tokens_by_model": {
+          "deepseek-v4-flash": 180000,
+          "glm-5": 160000
+        },
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "DAV_3510 的 NDDMA 指令有什么能力？BufferID 同步机制相比 set/wait 有什么变化？",
+      "expected_output": "回复应说明 NDDMA 与 BufferID（昇腾950 NPU架构白皮书 §4.1.5/§4.1.6）：\n- NDDMA：对全局内存数据最多 5 个维度重排后直接写入 UB，搬运与重排/转置一步完成；内置缓存自动发掘数据局部性，将多个数据元素粒度的读合并为 128 字节读\n- BufferID：替代 set/wait 强制配对，get_buf() 对应加锁、rel_buf() 对应解锁，类似互斥锁语义，内聚性更强、与其他流水线解耦",
+      "files": [],
+      "expectations": []
+    },
+    {
+      "id": 19,
+      "title": "CCU 通算融合能力",
+      "config": {
+        "max_tokens": 150000,
+        "max_tokens_by_model": {
+          "deepseek-v4-flash": 180000,
+          "glm-5": 160000
+        },
+        "ascend_platforms": [
+          "A2"
+        ],
+        "eval_mode": "text"
+      },
+      "prompt": "DAV_3510 新增的 CCU 是什么？支持哪些集合通信算法？对算子开发有什么影响？",
+      "expected_output": "回复应说明 CCU（昇腾950 NPU架构白皮书 §4.6.4）：\n- CCU（Collective Communication Unit）：IO-Die 上新增的集合通信专用引擎\n- CCUA 集成 MemorySlice（数据存储）与 Reduce Unit（数据计算），URMA 搬运与 Reduce 计算由硬件判定执行，完成后通过 Mission 任务接口上报状态\n- 支持 Broadcast / ReduceScatter / AllGather / AllReduce / All2All / All2Allv 典型算法\n- 对算子开发者的影响：通算融合算子有了新的开发选型",
+      "files": [],
+      "expectations": []
+    }
+  ],
+  "skill_name": "npu-arch"
+}