diff --git a/.claude/skills/ptoas-usability-eval/README.md b/.claude/skills/ptoas-usability-eval/README.md
new file mode 100644
index 000000000..3f8fd8545
--- /dev/null
+++ b/.claude/skills/ptoas-usability-eval/README.md
@@ -0,0 +1,33 @@
+# PTOAS Usability Eval Skill
+
+这是 PTOAS 仓库内的通用 Skill 源目录。
+
+支持的客户端入口：
+- Codex: `.codex/skills/ptoas-usability-eval/`
+- Cursor: `.cursor/skills/ptoas-usability-eval/`
+- Trae: `.trae/skills/ptoas-usability-eval/`
+- Claude Code: `.claude/skills/ptoas-usability-eval/`
+
+当前覆盖的评估场景：
+- `01 算子复现部署`
+- `02 算子迁移部署` 的 PTOAS 支撑子集
+- `04 算子基本功能实现` 的 PTOAS 工程子集
+- `05 特定 shape 性能优化` 的 PTOAS 支撑子集
+- `06 泛化 shape 性能优化` 的 PTOAS 支撑子集
+
+当前附带的汇总规则：
+- 原始指标保留 `10 分制 / 100 分制`
+- 汇总时统一归一到 `100` 分制
+- 默认输出 `总分（支撑）` 和 `总分（实测）`
+- `未实测/N/A` 不进入总分分母
+
+当前评估逻辑：
+- 先按 `touch-point` 体系选取适用于 PTOAS 的触点
+- 再按 `01/02/04/05/06` 场景评分
+- 默认只把适用的 `Core Touch-Points` 放进 repo 级总分
+
+约定：
+- `skills/ptoas-usability-eval/` 作为仓库内的通用主副本
+- 各客户端目录提供可直接发现的副本，便于不同工具开箱即用
+- 修改 Skill 内容时，应同步更新上述四个客户端目录
+- 对 `L3/L4` 依赖 Linux/CANN/NPU 的指标，未实测时必须标 `未实测`，不能因为当前机器缺环境直接给 PTOAS 低分
diff --git a/.claude/skills/ptoas-usability-eval/SKILL.md b/.claude/skills/ptoas-usability-eval/SKILL.md
new file mode 100644
index 000000000..24cc41525
--- /dev/null
+++ b/.claude/skills/ptoas-usability-eval/SKILL.md
@@ -0,0 +1,98 @@
+---
+name: ptoas-usability-eval
+description: Evaluate PTOAS repository usability across scene 01 as the primary template plus the PTOAS-supported subsets of scenes 02, 04, 05, and 06. Always classify the evaluation by environment layer first, use only repo-native docs/scripts/samples/CI as primary evidence, keep the user's mixed 10-point and 100-point scoring rules, compute normalized support and measured totals, and mark unsupported or untested dimensions as 未实测 or N/A.
+---
+
+# PTOAS Usability Eval
+
+当用户要评估 `hw-native-sys/PTOAS` 的易用性，或要按 `01/02/04/05/06` 给 PTOAS 打分时，使用这个 Skill。
+
+## 默认范围
+
+- `01 算子复现部署`：主评估场景，正常评分。
+- `02 算子迁移部署`：纳入，但只评 PTOAS 仓库能直接支撑的迁移入口、样例、IR/脚本、编译验证链路。
+- `04 算子基本功能实现`：纳入，但只评 PTOAS 直接覆盖的示例、编译、验证、反馈子链路。
+- `05 特定 shape 性能优化`：纳入，但只评 PTOAS 的文档、样例、性能数据获取入口、编译验证、精度/性能验证支撑能力。
+- `06 泛化 shape 性能优化`：纳入，但只评 PTOAS 的 dynamic/valid-shape、多 shape 样例与验证支撑能力。
+- `03 builtin 算子定制修改`：默认不纳入量化，标 `N/A`；必要时只做差距说明。
+
+先读 [references/touchpoint-selection.md](references/touchpoint-selection.md) 选定适用触点，再读 [references/scope.md](references/scope.md) 确认各场景的边界和 `未实测/N/A` 规则。
+
+## 先判层级
+
+开始评分前，必须先声明本次评估覆盖到哪一层。没有层级，不能直接混着打分。
+
+可选层级：
+- `L1 文档审阅层`：只看仓库文档、脚本、样例、CI，不做运行。
+- `L2 本地最小运行层`：当前机器已有 `ptoas` / `ptobc` / Python 绑定，可做最小命令验证。
+- `L3 Linux compile-only 层`：需要 Linux + CANN/bisheng + `PTO_ISA_ROOT`，不要求带卡。
+- `L4 NPU 上板层`：需要带卡 Linux、驱动、权限、`/dev/davinci*` 与对应用户组。
+
+约束：
+- 没进入某层，就把该层指标记为 `未实测`，不能因为当前机器缺环境就给 PTOAS 低分。
+- `bisheng` / CANN compile-only 一般属于 `L3`，不应在本地 Mac 上硬打低分。
+- 带卡运行、设备权限、驱动、ACL、用户组属于 `L4`。
+
+## 证据来源
+
+优先只用仓库内证据，不把仓外经验当成主证据。固定入口见 [references/evidence-checklist.md](references/evidence-checklist.md)。
+
+高优先级证据：
+- `README.md`
+- `docs/no_npu_compile_only_guide_zh.md`
+- `docs/PTO_IR_manual.md`
+- `test/samples/runop.sh`
+- `test/npu_validation/scripts/generate_testcase.py`
+- `test/npu_validation/scripts/run_remote_npu_validation.sh`
+- `test/samples/PyPTOIRParser/README.md`
+- `test/samples/FlashAttention/`, `test/samples/GQA/`, `test/samples/FFN/`
+- `test/samples/SetValidShape/`, `test/samples/LayoutInference/`, `test/samples/Partition5D/`, `test/samples/planmemory/`
+- `.github/workflows/ci.yml`
+- `.github/ISSUE_TEMPLATE/performance_issue.yml`
+
+## 工作流
+
+1. 先判断用户要的是 `01`、`02`、`04`、`05`、`06` 中哪些场景；未说明时默认 `01`。
+2. 再判断本次覆盖层级：`L1/L2/L3/L4`。输出中必须显式写出来。
+3. 先读 [references/touchpoint-selection.md](references/touchpoint-selection.md)，按场景选定本次的 `Core / Conditional / Excluded` 触点。
+4. 从仓库内收集证据，记录每次检索轮次、文档跳转次数、执行命令、耗时、成功/失败结果。
+5. `01` 场景读 [references/metrics-01.md](references/metrics-01.md)。
+6. `02` 场景读 [references/metrics-02.md](references/metrics-02.md)。
+7. `04` 场景读 [references/metrics-04.md](references/metrics-04.md)。
+8. `05` 场景读 [references/metrics-05.md](references/metrics-05.md)。
+9. `06` 场景读 [references/metrics-06.md](references/metrics-06.md)。
+10. 需要汇总总分时，读 [references/scoring.md](references/scoring.md)。
+11. 对每个指标都输出：原始观测值、评分、证据路径、说明。没有实测的数据不要猜，记为 `未实测` 或 `N/A`。
+12. 明确区分：
+    - PTOAS 仓库已提供的能力
+    - 外部前置条件，例如 LLVM、CANN、`pto-isa`、NPU、驱动/权限、业务 baseline
+13. 若文档描述与实际运行冲突，以实际命令结果为准，并指出冲突位置。
+14. 默认给两个总分：`总分（支撑）` 和 `总分（实测）`。如果用户只要分项，不强制输出总分。
+
+## 计量规则
+
+- 保留用户原始口径，不强行覆盖各指标的原始分制。
+- 但做总分汇总时，必须按 [references/scoring.md](references/scoring.md) 做归一化。
+- `检索轮次`：每次新的定向搜索或定位尝试算 1 轮。
+- `文档跳转次数`：命中首个目标文档后，每跨一个文档/README/脚本入口算 1 次。
+- `耗时`：尽量记录真实墙钟时间；拿不到就写 `未实测`，不要臆测。
+- `成功率`：只基于当前任务里真实执行或真实定位到的结果计算。
+- `未实测`：当前会话未覆盖到对应环境层级，或该层级前置条件不存在，或缺少前后对照 baseline。
+- `N/A`：只用于超出 PTOAS 能力边界，或当前任务明确不纳入本次评估范围的项。
+
+## 输出格式
+
+按下面顺序输出：
+
+1. `评估范围`
+2. `触点选择`
+3. `评估层级`
+4. `总分（支撑）`
+5. `总分（实测）`
+6. `分场景评分`
+7. `覆盖说明`
+8. `关键证据`
+9. `主要短板`
+10. `建议动作`
+
+如果用户只要简版结论，也要至少保留：场景归类、评估层级、总评、最低分项、证据路径。
diff --git a/.claude/skills/ptoas-usability-eval/agents/openai.yaml b/.claude/skills/ptoas-usability-eval/agents/openai.yaml
new file mode 100644
index 000000000..924e59e3f
--- /dev/null
+++ b/.claude/skills/ptoas-usability-eval/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "PTOAS Usability Eval"
+  short_description: "评估 PTOAS 在 01/02/04/05/06 场景下的易用性"
+  default_prompt: "Use $ptoas-usability-eval to evaluate this PTOAS repo for scene 01 operator reproduction/deployment and the PTOAS-supported subsets of scenes 02, 04, 05, and 06."
diff --git a/.claude/skills/ptoas-usability-eval/references/evidence-checklist.md b/.claude/skills/ptoas-usability-eval/references/evidence-checklist.md
new file mode 100644
index 000000000..89b6f1987
--- /dev/null
+++ b/.claude/skills/ptoas-usability-eval/references/evidence-checklist.md
@@ -0,0 +1,86 @@
+# 证据清单
+
+## 固定证据入口
+
+| 路径 | 主要用途 | 对应场景 | 层级 | 主要触点 |
+| --- | --- | --- | --- | --- |
+| `README.md` | 官方构建、环境变量、CLI、Python 绑定、sample 运行、compile-only/上板验证主入口 | `01`, `02`, `04`, `05`, `06` | `L1-L4` | `TP001-005, TP016-020, TP038, TP049, TP053, TP058` |
+| `docs/no_npu_compile_only_guide_zh.md` | 无卡 compile-only 流程、批量验证流程、`pto-isa`/CANN 依赖说明 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3` | `TP005, TP017-018, TP049, TP051-052, TP058-060, TP062-064` |
+| `docs/PTO_IR_manual.md` | IR 层级、tile/view/valid-shape、layout、dynamic shape、Level-2/3 语义 | `02`, `04`, `05`, `06` | `L1-L4` | `TP019-020, TP028, TP032, TP039, TP045-047` |
+| `test/samples/runop.sh` | 批量样例生成、`ptoas`/`ptobc` 运行、A3/A5 默认参数策略 | `01`, `02`, `04`, `05`, `06` | `L1-L4` | `TP018, TP034-039, TP049, TP051-052, TP062-064` |
+| `test/npu_validation/scripts/generate_testcase.py` | 从 `*-pto.cpp` 生成验证工程，观察 golden/compare/兼容层处理 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3`, `L4` | `TP037-039, TP045-047, TP049, TP052` |
+| `test/npu_validation/scripts/run_remote_npu_validation.sh` | compile-only / sim / npu 运行链路、日志格式、设备与 `pto-isa` 检查 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3`, `L4` | `TP049, TP051-052, TP058-060, TP062-064` |
+| `test/samples/PyPTOIRParser/README.md` | 来自 pypto `ir_parser` 的 vendored `.pto` 快照说明 | `02` | `L1` | `TP035-037, TP039, TP044, TP046-047` |
+| `test/samples/MatMul/` | README 直接引用的基准样例，适合作为 `01` 默认复现模板 | `01`, `04`, `05` | `L1-L4` | `TP018, TP034-039, TP042-047` |
+| `test/samples/FlashAttention/` | 特定 shape 性能样例 | `05` | `L1-L4` | `TP035-041, TP044, TP046` |
+| `test/samples/GQA/` | 特定 shape / attention 相关样例 | `05` | `L1-L4` | `TP035-041, TP044, TP046` |
+| `test/samples/FFN/` | 特定 shape / 算子组合样例 | `05` | `L1-L4` | `TP035-041, TP044, TP046` |
+| `test/samples/SetValidShape/` | dynamic/valid-shape 相关样例 | `06` | `L1-L4` | `TP035-039, TP044, TP046-047` |
+| `test/samples/LayoutInference/` | layout 推断相关样例 | `06` | `L1-L4` | `TP019-020, TP035-039, TP046-047` |
+| `test/samples/Partition5D/` | 多维 partition / shape 泛化相关样例 | `02`, `06` | `L1-L4` | `TP035-039, TP044, TP046-047, TP061` |
+| `test/samples/planmemory/` | alias/planmemory/shape 相关样例 | `06` | `L1-L4` | `TP035-039, TP044, TP046-047` |
+| `.github/workflows/ci.yml` | CI 中的 LLVM/PTOAS 构建、lit、sample test、remote validation 参考配置 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3`, `L4` | `TP003, TP011, TP049, TP052-053, TP058, TP060-064` |
+| `.github/ISSUE_TEMPLATE/performance_issue.yml` | 性能问题受理模板，可用来评估性能数据/复现要求的完备性 | `05`, `06` | `L1` | `TP005, TP017, TP040-041, TP062-063` |
+
+说明：
+- 不要把当前分支不存在的样例 README 当成固定证据源。
+- 对 `02/05/06`，没有“前后对照基线”时，不要硬算迁移完备度或性能提升幅度。
+
+## 推荐检索顺序
+
+1. `README.md`
+2. `docs/no_npu_compile_only_guide_zh.md`
+3. `docs/PTO_IR_manual.md`
+4. `test/samples/MatMul/` 或用户指定样例目录
+5. `test/samples/PyPTOIRParser/`, `FlashAttention/`, `GQA/`, `FFN/`, `SetValidShape/`, `LayoutInference/`, `Partition5D/`, `planmemory/`
+6. `test/samples/runop.sh`
+7. `test/npu_validation/scripts/*.py` / `*.sh`
+8. `.github/workflows/ci.yml`
+9. `.github/ISSUE_TEMPLATE/performance_issue.yml`
+
+## 推荐检索命令
+
+```bash
+rg -n "构建|运行测试|compile-only|runop|generate_testcase|run_remote_npu_validation|level3" README.md docs test .github
+rg -n "valid_shape|layout|partition|reshape|dynamic shape|Level-2|Level-3" docs/PTO_IR_manual.md docs test
+rg -n "FlashAttention|GQA|FFN|MatMul|SetValidShape|LayoutInference|Partition5D|planmemory" test .github
+rg --files test/samples
+find test/samples -maxdepth 2 -type f \( -name '*.py' -o -name '*.pto' -o -name 'README.md' \)
+```
+
+## 迁移 / 性能场景的补充记录项
+
+如果在评 `02/05/06`，额外记录：
+- 是否存在迁移前/迁移后对照物
+- 是否存在性能 baseline
+- baseline 来源路径
+- 是否需要 NPU 实机
+- 当前停在哪一层
+- 哪些分数是实测，哪些是文档侧支撑分
+
+## 记录要求
+
+每个评分项至少要落这些证据字段：
+
+- `证据路径`
+- `检索/执行命令`
+- `检索轮次`
+- `文档跳转次数`
+- `评估层级`
+- `耗时`
+- `结果`
+- `评分`
+- `备注`
+
+## 默认样例
+
+若用户没有指定具体算子或样例，优先使用：
+
+- `test/samples/MatMul/tmatmulk.py`
+- `test/samples/MatMul/tmatmulk.pto`
+- `test/samples/Addc/addc.py`
+- `test/samples/PyPTOIRParser/`
+- `test/samples/FlashAttention/`
+- `test/samples/SetValidShape/`
+
+理由：这些路径要么被 `README.md` 直接引用，要么与迁移/性能/shape 泛化评估强相关，且当前主线可稳定找到。
diff --git a/.claude/skills/ptoas-usability-eval/references/metrics-01.md b/.claude/skills/ptoas-usability-eval/references/metrics-01.md
new file mode 100644
index 000000000..58bcc109d
--- /dev/null
+++ b/.claude/skills/ptoas-usability-eval/references/metrics-01.md
@@ -0,0 +1,119 @@
+# `01 算子复现部署` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP008-018`
+- `源码 & 示例类`: `TP034-035, TP038, TP042, TP044`
+- `工具`: `TP049, TP051-052`
+- `版本`: `TP053, TP058`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP006, TP054, TP057, TP059-061`
+
+默认把 PTOAS 看作“从样例或 `.pto` 输入出发，完成构建、编译、compile-only 或上板验证”的工具链仓库。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+在 `01` 场景里，必须先声明本次评估覆盖的层级：
+
+- `L1 文档审阅层`
+- `L2 本地最小运行层`
+- `L3 Linux compile-only 层`
+- `L4 NPU 上板层`
+
+没有进入对应层，就标 `未实测`，不要把环境缺失当成 PTOAS 负分。
+
+## 默认任务模板
+
+若用户没有指定具体 case，优先用 `test/samples/MatMul/` 作为复现模板：
+
+```bash
+python3 test/samples/MatMul/tmatmulk.py > /tmp/tmatmulk.pto
+./build/tools/ptoas/ptoas /tmp/tmatmulk.pto -o /tmp/tmatmulk.cpp
+```
+
+需要无卡 compile-only 时，继续参考：
+
+```bash
+python3 test/npu_validation/scripts/generate_testcase.py \
+  --input /tmp/tmatmulk.cpp \
+  --run-mode npu \
+  --soc-version Ascend910
+```
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 检索命中成功率 | 统计找到“构建 + sample 运行 + compile-only/上板验证”入口所需检索轮次 | `README.md`, `docs/no_npu_compile_only_guide_zh.md` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+| 文档检索耗时 | 从开始找文档到定位到正确路径的时间 | 同上 | `L1-L4` | `2 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 文档获取成功率 | 目标文档是否都能在仓库内找到 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+### 文档学习
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 文档错误点位密度 | 按文档执行时，检查命令、路径、版本、链接、说明是否错误 | `README.md`, `docs/no_npu_compile_only_guide_zh.md`, `.github/workflows/ci.yml` | `L1-L4` | 零错误 `100`；少量小错 `80`；一般错误 `60`；明显错误 `40`；严重不可用 `20` |
+| 文档跳转次数 | 从首个命中文档到凑齐完整执行路径，跨文档跳转的次数 | `README.md -> docs/... -> test/samples/...` | `L1-L4` | 1 次 `100`；2 次 `80`；3 次 `60`；4-5 次 `40`；>5 次 `20` |
+| 内容覆盖缺失率 | 是否清楚区分本地运行、Linux compile-only、带卡上板等层级前置条件 | `README.md`, `docs/...`, `.github/workflows/ci.yml` | `L1-L4` | 无缺失 `100`；`<=5%` `80`；`5%-15%` `60`；`15%-30%` `40`；`>30%` `20` |
+| 文档学习耗时 | 从开始读到能给出执行方案的时间 | 同上 | `L1-L4` | `5 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 通过文档学习检索成功率 | 需要通过文档解决的问题里，有多少真正被文档回答 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+## 易部署
+
+### 环境下载
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 环境获取场景覆盖率 | 看仓库是否说明源码构建、无卡 compile-only、上板验证所需环境 | `README.md`, `docs/no_npu_compile_only_guide_zh.md` | `L1-L4` | `100%=10`；`80%-99%=8`；`60%-79%=6`；`40%-59%=4`；`<40%=2` |
+| 环境下载耗时 | 真实下载 LLVM/CANN/Python 依赖/`pto-isa` 的时间 | 真实执行记录 | `L3-L4` | `<=5 分钟=10`；`5-7=8`；`7-9=6`；`9-11=4`；`>11=2` |
+| 环境下载成功率 | 下载步骤是否一次完成 | 真实执行记录 | `L3-L4` | `100%=10`，按比例计算 |
+
+说明：如果当前任务没有真的在 Linux/CANN 环境里下载依赖，后两项写 `未实测`。
+
+### 环境安装
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 软硬件配套兼容率 | 检查仓库是否明确 LLVM 版本、Python 包版本、CANN / `pto-isa` 依赖关系 | `README.md`, `docs/no_npu_compile_only_guide_zh.md`, `ci.yml` | `L1-L4` | `100%=10`；`80%-99%=8`；`60%-79%=6`；`40%-59%=4`；`<40%=2` |
+| 部署时长 | 从开始执行安装到可运行 `ptoas`/Python 绑定的时间 | 真实执行记录 | `L2-L4` | `<=5 分钟=10`；`5-7=8`；`7-9=6`；`9-11=4`；`>11=2` |
+| 操作步骤数 | 完成安装所需命令/步骤数量 | `README.md` 构建步骤 | `L1-L4` | `<=8 步=10`；`9-10=8`；`11-12=6`；`13-14=4`；`>14=2` |
+| 环境安装成功率 | 是否能完成 LLVM + PTOAS 构建与安装 | 真实执行记录 | `L2-L4` | `100%=10`，按比例计算 |
+
+### 环境校验
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 环境安装后校验成功率 | 是否有明确校验动作，例如 `ptoas --version`、Python import、sample compile | `README.md`, `ci.yml` | `L2-L4` | `100%=10`，按比例计算 |
+
+推荐最小校验命令：
+
+```bash
+./build/tools/ptoas/ptoas --version
+python3 -c "from mlir.dialects import pto; print('ok')"
+```
+
+## 易开发、易演进
+
+### 获取示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 检索命中成功率 | 统计定位到默认样例目录所需轮次 | `test/samples/MatMul/`, `test/samples/Addc/`, `README.md` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+
+### 运行示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 示例代码运行耗时 | 从运行 sample 到拿到 `.pto` / `.cpp` / compile-only 结果的时间 | `README.md`, `test/samples/MatMul/` | `L2-L4` | `<=2 分钟=10`；`2-4=8`；`4-6=6`；`6-8=4`；`>8=2` |
+| 示例代码运行成功率 | `py -> .pto -> .cpp` 或 compile-only / validation 是否成功 | 同上 | `L2-L4` | `100%=10`，按比例计算 |
+
+## 何时记 `未实测` / `N/A`
+
+- `未实测`：当前任务没有进入对应环境层级，例如在本地 Mac 上没有 Linux/CANN/bisheng，却要评价 compile-only。
+- `N/A`：该项超出 PTOAS 能力边界，或本次任务明确不纳入该项。
+
+不要把二者混用。
diff --git a/.claude/skills/ptoas-usability-eval/references/metrics-02.md b/.claude/skills/ptoas-usability-eval/references/metrics-02.md
new file mode 100644
index 000000000..8ad84dbf6
--- /dev/null
+++ b/.claude/skills/ptoas-usability-eval/references/metrics-02.md
@@ -0,0 +1,77 @@
+# `02 算子迁移部署` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP008-009, TP011, TP013, TP017`
+- `API / 接口`: `TP019-020, TP032`
+- `源码 & 示例类`: `TP035-037, TP039, TP044, TP046-047`
+- `工具`: `TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP040-041, TP033, TP061`
+
+这里只评估 PTOAS 仓库对“迁移到 PTO IR / PTOAS 工具链”的支撑能力，不把 PTOAS 包装成完整业务算子迁移平台。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`02` 场景同样先声明层级：
+
+- `L1 文档审阅层`
+- `L2 本地最小运行层`
+- `L3 Linux compile-only 层`
+- `L4 NPU 上板层`
+
+没有进入对应层，就标 `未实测`。
+
+## 共享易学习项
+
+`02` 的 `文档获取` / `文档学习` 默认复用 [metrics-01.md](metrics-01.md) 中对应规则；只是目标从“复现部署”改成“找到迁移入口、IR 语义、样例和验证链路”。
+
+推荐优先证据：
+- `docs/PTO_IR_manual.md`
+- `test/samples/PyPTOIRParser/README.md`
+- `README.md`
+- `docs/no_npu_compile_only_guide_zh.md`
+
+## 易迁移
+
+### 算子迁移
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| tiling 迁移完备度 | 统计迁移前定义的 tiling 结构中，已成功落到 PTO IR / sample / generated testcase 的比例 | `docs/PTO_IR_manual.md`, `test/samples/*`, 用户提供的前后对照物 | `L1-L4` | `100%=10`；`80%=8`；`60%=6`；`40%=4`；`20%=2` |
+| kernel 迁移完备度 | 统计迁移前 kernel 逻辑中，已能由 PTO case / sample / generated testcase 覆盖的比例 | 同上 | `L1-L4` | `100%=10`；`80%=8`；`60%=6`；`40%=4`；`20%=2` |
+| 算子功能失败率 | 迁移后 compile-only / validation / board case 失败比例 | `runop.sh`, `generate_testcase.py`, `run_remote_npu_validation.sh` | `L3-L4` | `0% 失败=10`；`10%=8`；`20%=6`；`30%=4`；`40%=2` |
+| 算子性能劣化率 | 迁移后相对迁移前 baseline 的性能增幅 | 用户 baseline、`performance_issue.yml`、实测日志 | `L4` | 劣化 `<5%=10`；`10%=8`；`20%=6`；`30%=4`；`40%=2` |
+| tiling 代码修改率 | 迁移时 tiling 相关代码修改行数 / 总行数 | 用户对照 case、PR diff | `L1-L4` | `0%-5%` 高分；`5%-15%` 次高；`15%-25%` 中；`25%-35%` 低；`>35%` 最低 |
+| kernel 代码修改率 | 迁移时 kernel 相关代码修改行数 / 总行数 | 用户对照 case、PR diff | `L1-L4` | `0%-5%` 高分；`5%-15%` 次高；`15%-25%` 中；`25%-35%` 低；`>35%` 最低 |
+| 算子迁移总耗时 | 从开始迁移到迁移完成，不含最终验证环节 | 真实执行记录 | `L2-L4` | `<=10 分钟` 高分；`10-20` 次之；`20-30` 中；`30-60` 低；`>60` 最低 |
+| 算子迁移成功率 | 迁移任务成功率 | 真实执行记录 | `L2-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 在 PTOAS 中如何落地这些指标
+
+### 可直接量化的前提
+
+只有当前任务同时具备以下材料时，才量化迁移完备度/修改率/失败率：
+- 迁移前输入：上游 IR、旧 kernel、旧 tiling，至少一种
+- 迁移后输入：PTO `.pto`、sample、generated testcase，至少一种
+- 对应验证链路：compile-only 或 board validation
+
+### 没有对照物时怎么办
+
+- 只有仓库文档和样例，没有迁移前材料：
+  - 可以评“入口是否清晰”“样例/脚本是否齐全”
+  - 不能给出完备度/修改率/性能劣化率，记 `未实测`
+- 指标本身依赖仓外业务工程，且用户没给材料：
+  - 记 `N/A`
+
+## 推荐默认证据路径
+
+- `docs/PTO_IR_manual.md`
+- `test/samples/PyPTOIRParser/README.md`
+- `test/samples/*`
+- `docs/no_npu_compile_only_guide_zh.md`
+- `test/samples/runop.sh`
+- `test/npu_validation/scripts/generate_testcase.py`
+- `test/npu_validation/scripts/run_remote_npu_validation.sh`
diff --git a/.claude/skills/ptoas-usability-eval/references/metrics-04.md b/.claude/skills/ptoas-usability-eval/references/metrics-04.md
new file mode 100644
index 000000000..d347924a6
--- /dev/null
+++ b/.claude/skills/ptoas-usability-eval/references/metrics-04.md
@@ -0,0 +1,116 @@
+# `04 算子基本功能实现` 的 PTOAS 子集指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP008-009, TP011, TP013, TP017-018`
+- `API / 接口`: `TP019-020, TP028, TP032`
+- `源码 & 示例类`: `TP034-039, TP042-047`
+- `工具`: `TP049, TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP006, TP010, TP014-015, TP033`
+
+这里只评估 PTOAS 真正覆盖到的“示例 / 编译 / 验证 / 反馈”链路，不把 PTOAS 当成完整算子研发平台。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`04` 子集同样先声明层级：
+
+- `L1 文档审阅层`
+- `L2 本地最小运行层`
+- `L3 Linux compile-only 层`
+- `L4 NPU 上板层`
+
+未进入对应层级，只能标 `未实测`。
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 检索命中成功率 | 找到目标样例、相关 CLI、验证脚本所需轮次 | `README.md`, `test/samples/`, `test/npu_validation/scripts/` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+| 文档检索耗时 | 从开始查到定位到目标入口的时间 | 同上 | `L1-L4` | `2 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 文档获取成功率 | 所需文档/脚本/样例是否都能在仓内找到 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+### 文档学习
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 文档错误点位密度 | 样例说明、命令、路径、环境前置条件是否准确 | `README.md`, sample README, `runop.sh`, `ci.yml` | `L1-L4` | 零错误 `100`；少量小错 `80`；一般错误 `60`；明显错误 `40`；严重不可用 `20` |
+| 文档跳转次数 | 为理解 sample 到 compile/validation 链路所需跳转次数 | 同上 | `L1-L4` | 1 次 `100`；2 次 `80`；3 次 `60`；4-5 次 `40`；>5 次 `20` |
+| 内容覆盖缺失率 | 样例定位、编译、验证、环境前置条件说明是否缺失 | 同上 | `L1-L4` | 无缺失 `100`；`<=5%` `80`；`5%-15%` `60`；`15%-30%` `40`；`>30%` `20` |
+| 文档学习耗时 | 从开始看文档到能解释执行路径的时间 | 同上 | `L1-L4` | `5 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 通过文档学习检索成功率 | 依赖文档回答的问题是否被解决 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+## 易开发、易演进
+
+### 获取示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 目标示例定位命中成功率 | 找到适合作为基本功能实现基线的 sample 或 `.pto` 所需轮次 | `test/samples/MatMul/`, `test/samples/Addc/`, `test/samples/PyPTOIRParser/` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+
+### 学习/理解示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 样例场景覆盖度 | 样例是否覆盖目标算子的输入、输出、golden/compare、compile/validation 场景 | 选定样例目录中的 `.py` / `.pto` / `npu_validation/` | `L1-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 样例学习分析 Token 数 | 优先使用平台可见的 AI token 统计；没有统计就写 `未量化` | 同上 | `L1-L4` | `<=500` 高分；`500-1000` 次高；`1000-2000` 中；`2000-3000` 低；`>3000` 最低 |
+| 示例理解耗时 | 从首次打开样例到能讲清输入、生成物、验证链路的时间 | 同上 | `L1-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-15` 中；`15-20` 低；`>20` 最低 |
+
+说明：如果运行环境拿不到 token 统计，第二项保留原值 `未量化`，不要编造 token 数。
+
+### 运行示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 运行成功率 | sample 首次执行是否能生成 `.pto` / `.cpp` / compile-only 验证工程 | `README.md`, `test/samples/runop.sh`, sample 目录 | `L2-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 示例代码运行耗时 | 从开始运行到 sample 结束的时间 | 同上 | `L2-L4` | `<=2 分钟` 高分；`2-4` 次之；`4-6` 中；`6-8` 低；`>8` 最低 |
+
+## 算子编译
+
+### 编译配置
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 新增/修改配置行数 | 按仓库已有说明运行 sample / validation 时，需要额外改多少配置行 | `README.md`, `docs/no_npu_compile_only_guide_zh.md`, `ci.yml` | `L1-L4` | `<5 行=100`；`<10=80`；`<15=60`；`<20=40`；`>20=20` |
+
+记录时只统计“文档外的额外修改”。按 README 就能跑通则记 `0` 行。
+
+### 算子工程编译
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 需要理解的宏/函数个数 | 为改通当前 sample / validation 链路，必须额外读懂多少宏/函数 | `runop.sh`, `generate_testcase.py`, `run_remote_npu_validation.sh`, sample CMake | `L1-L4` | `2 个=10`；`4 个=8`；`6 个=6`；`8 个=4`；`>10 个=2` |
+| 编译报错排障效率 | 从 sample / validation 工程编译到成功，中间修复了几轮 | `ninja`, `cmake --build`, validation 日志 | `L3-L4` | 无报错高分；1 次修复次之；2-3 次中；4-5 次低；>5 次最低 |
+| 编译耗时 | 开始编译到编译完成的总时间 | 同上 | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 编译成功率 | 最终编译是否成功，以及首次是否成功 | 同上 | `L3-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 功能调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 报错携带环境/版本/上下文信息完整率 | `ptoas` / validation 脚本报错时，是否包含 stage、case、路径、依赖、设备、soc/version 等信息 | `run_remote_npu_validation.sh`, sample/CI 日志 | `L2-L4` | 信息完整 `100`；`>=90%` `80`；`70%-89%` `60`；`50%-69%` `40`；`<50%` `20` |
+| 报错自带排障建议比例 | 报错是否已经给出下一步可排查方向 | 同上 | `L2-L4` | 全部带建议 `100`；`>=90%` `80`；`70%-89%` `60`；`50%-69%` `40`；`<50%` `20` |
+| 无效冗余信息占比 | 日志是否大量充斥与当前失败无关的信息 | 同上 | `L2-L4` | 无冗余 `100`；`<=5%` `80`；`5%-15%` `60`；`15%-30%` `40`；`>30%` `20` |
+| 功能调试耗时 | 从第一次失败到定位根因或跑通的时间 | 同上 | `L2-L4` | `<=10 分钟` 高分；`10-20` 次之；`20-30` 中；`30-60` 低；`>60` 最低 |
+| 功能调试成功率 | 当前目标问题是否最终解决 | 同上 | `L2-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 精度调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 精度数据获取耗时 | 获取 golden/output/compare 报告所需时间 | `generate_testcase.py`, sample `golden.py`, `compare.py` | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 定位分析次数 | 从发现精度问题到定位根因的迭代次数 | 真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 代码修改/迭代循环 | 精度修复迭代次数 | PR diff、真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+
+## 默认排除项
+
+这些在 PTOAS 仓库里默认不打分，直接标 `N/A`：
+
+- 算子设计-需求分析
+- 算子设计-方案实现
+- 通用算子代码开发全过程
+- 脱离 PTOAS 仓库的业务工程联调
diff --git a/.claude/skills/ptoas-usability-eval/references/metrics-05.md b/.claude/skills/ptoas-usability-eval/references/metrics-05.md
new file mode 100644
index 000000000..3b05aa815
--- /dev/null
+++ b/.claude/skills/ptoas-usability-eval/references/metrics-05.md
@@ -0,0 +1,82 @@
+# `05 特定 shape 性能优化` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP017`
+- `API / 接口`: `TP019-020`
+- `源码 & 示例类`: `TP035-036, TP039, TP044, TP046`
+- `工具`: `TP049, TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP040-041, TP054, TP061`
+
+这里只评估 PTOAS 对“固定 shape / 特定 shape 性能优化”的支撑能力。没有 benchmark baseline 或没有上板实测时，不要硬造性能结论。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`05` 场景通常至少需要：
+- `L1` 评文档、样例、入口
+- `L3` 评 compile-only 和工程编译
+- `L4` 才能评真实性能、精度一致性、性能提升
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能优化文档检索命中率 | 找到性能相关文档、样例、issue 模板所需轮次 | `README.md`, `docs/PTO_IR_manual.md`, `.github/ISSUE_TEMPLATE/performance_issue.yml`, `test/samples/FlashAttention/`, `GQA/`, `FFN/` | `L1-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 文档检索耗时 | 从开始检索到找到目标文档的时间 | 同上 | `L1-L4` | `<=2 分钟` 高分；`2-4` 次之；`4-6` 中；`6-8` 低；`>8` 最低 |
+
+## 易开发、易演进
+
+### 性能分析
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能数据采集耗时 | 获取 profile/日志/性能数据所需时间 | 用户 benchmark 脚本、sample、remote validation 日志 | `L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 性能报告完备度 | 报告是否包含关键指标、case、shape、参数、耗时 | `performance_issue.yml`、用户日志 | `L1`, `L4` | 数据完整齐全高分；`>=90%` 次之；`70%-89%` 中；`50%-69%` 低；`<50%` 最低 |
+
+### 优化实现
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 优化迭代次数 | 针对固定 shape 调整 pass / IR / sample 的迭代次数 | PR diff、真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 优化耗时 | 完成策略优化的总耗时 | 真实执行记录 | `L3-L4` | `<=30 分钟` 高分；`30-60` 次之；`60-120` 中；`120-180` 低；`>180` 最低 |
+| 优化成功率 | 优化任务成功率 | 真实执行记录 | `L3-L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 编译验证
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 编译报错排障效率 | 调优后重新编译 sample / validation 工程时，修复了几轮 | `cmake`, `ninja`, validation 日志 | `L3-L4` | 无报错高分；1 次修复次之；2-3 次中；4-5 次低；>5 次最低 |
+| 编译耗时 | 从开始编译到编译完成的总时间 | 同上 | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 编译成功率 | 最终编译是否成功 | 同上 | `L3-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 性能调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能提升达成率 | 达到预期性能提升目标的任务比例 | baseline + 实测性能日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 性能提升幅度 | 优化后相对 baseline 的提升幅度 | 同上 | `L4` | 提升 `>=50%` 高分；`30%-50%` 次之；`10%-30%` 中；`0%-10%` 低；无提升或劣化最低 |
+| 对标友商差距 | 优化后性能与友商的差距 | 用户提供对标数据 | `L4` | 超越高分；持平次之；差距 `<20%` 中；`20%-50%` 低；`>50%` 最低 |
+
+说明：`对标友商差距` 没有外部 benchmark 时直接记 `N/A`，因为它超出 PTOAS 仓库单独可证的边界。
+
+### 精度调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 精度验证工具获取耗时 | 获取 golden/compare/验证工具所需时间 | sample `golden.py`, `compare.py`, `generate_testcase.py` | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 精度验证运行成功次数 | 直到精度验证成功所需的尝试次数 | 真实执行记录 | `L3-L4` | 首次成功 `10`；2-3 次 `8`；4-5 次 `6`；6-7 次 `4`；>7 次或无法成功 `2` |
+| 精度一致性验证 | 优化后精度与优化前的一致性 | compare 结果、误差阈值 | `L4` | `100% 一致` 高分；误差 `<1e-5` 次之；`<1e-3` 中；`<1e-1` 低；明显差异最低 |
+| 用例回归通过率 | 原功能精度用例回归通过率 | 回归日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 默认样例
+
+优先选择：
+- `test/samples/FlashAttention/`
+- `test/samples/GQA/`
+- `test/samples/FFN/`
+- `test/samples/MatMul/`
diff --git a/.claude/skills/ptoas-usability-eval/references/metrics-06.md b/.claude/skills/ptoas-usability-eval/references/metrics-06.md
new file mode 100644
index 000000000..1e44532c0
--- /dev/null
+++ b/.claude/skills/ptoas-usability-eval/references/metrics-06.md
@@ -0,0 +1,84 @@
+# `06 泛化 shape 性能优化` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP017`
+- `API / 接口`: `TP019-020`
+- `源码 & 示例类`: `TP035-036, TP039, TP044, TP046-047`
+- `工具`: `TP049, TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP040-041, TP054, TP061`
+
+这里只评估 PTOAS 对“多 shape / dynamic shape / valid-shape 场景”的性能优化支撑能力。没有多 shape 基线矩阵时，不要硬造平均/最大收益。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`06` 场景通常至少需要：
+- `L1` 评文档、IR 语义、样例覆盖度
+- `L3` 评 compile-only、编译验证
+- `L4` 才能评多 shape 真实性能与精度结果
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能优化文档检索命中率 | 找到 dynamic/valid-shape、layout、性能相关文档和样例所需轮次 | `docs/PTO_IR_manual.md`, `README.md`, `test/samples/SetValidShape/`, `LayoutInference/`, `Partition5D/`, `planmemory/` | `L1-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 文档检索耗时 | 从开始检索到找到目标文档的时间 | 同上 | `L1-L4` | `<=2 分钟` 高分；`2-4` 次之；`4-6` 中；`6-8` 低；`>8` 最低 |
+
+## 易开发、易演进
+
+### 性能分析
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能数据采集耗时 | 获取多 shape profile/性能数据所需时间 | 用户 benchmark 脚本、validation 日志 | `L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 性能报告完备度 | 报告是否包含 shape 集合、关键指标、参数、耗时 | 用户日志、`performance_issue.yml` | `L1`, `L4` | 数据完整齐全高分；`>=90%` 次之；`70%-89%` 中；`50%-69%` 低；`<50%` 最低 |
+
+### 优化实现
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 平均优化迭代次数 | 多 shape 场景平均调整次数 | 真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 平均优化耗时 | 多 shape 场景平均完成策略优化的耗时 | 真实执行记录 | `L3-L4` | `<=30 分钟` 高分；`30-60` 次之；`60-120` 中；`120-180` 低；`>180` 最低 |
+| 优化成功率 | 多 shape 策略优化任务成功率 | 真实执行记录 | `L3-L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 编译验证
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 编译报错排障效率 | 多 shape 调优后重新编译 sample / validation 工程时，修复了几轮 | `cmake`, `ninja`, validation 日志 | `L3-L4` | 无报错高分；1 次修复次之；2-3 次中；4-5 次低；>5 次最低 |
+| 编译耗时 | 从开始编译到编译完成的总时间 | 同上 | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 编译成功率 | 最终编译是否成功 | 同上 | `L3-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 性能调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能提升达成率 | 达到预期性能提升目标的任务比例 | 多 shape baseline + 实测日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 平均性能提升幅度 | 多 shape 场景性能平均提升幅度 | 同上 | `L4` | 提升 `>=50%` 高分；`30%-50%` 次之；`10%-30%` 中；`0%-10%` 低；无提升或劣化最低 |
+| 最大性能提升幅度 | 提升最大的单个 shape 收益 | 同上 | `L4` | 提升 `>=60%` 高分；`40%-60%` 次之；`20%-40%` 中；`0%-20%` 低；无提升或劣化最低 |
+| 对标友商差距 | 优化后性能与友商的差距 | 用户提供对标数据 | `L4` | 超越高分；持平次之；差距 `<20%` 中；`20%-50%` 低；`>50%` 最低 |
+
+说明：`对标友商差距` 没有外部 benchmark 时直接记 `N/A`。
+
+### 精度调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 精度验证工具获取耗时 | 获取多 shape 精度验证工具所需时间 | `generate_testcase.py`, sample `golden.py`, `compare.py` | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 精度验证运行成功次数 | 直到精度验证成功所需的尝试次数 | 真实执行记录 | `L3-L4` | 首次成功 `10`；2-3 次 `8`；4-5 次 `6`；6-7 次 `4`；>7 次或无法成功 `2` |
+| 精度保持率 | 优化后精度与优化前的一致性 | compare 结果、误差阈值 | `L4` | `100% 一致` 高分；误差 `<1e-5` 次之；`<1e-3` 中；`<1e-1` 低；明显差异最低 |
+| 用例回归通过率 | 原功能精度用例回归通过率 | 回归日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 默认样例
+
+优先选择：
+- `test/samples/SetValidShape/`
+- `test/samples/LayoutInference/`
+- `test/samples/Partition5D/`
+- `test/samples/planmemory/`
+- 其他带 `valid_shape` / dynamic shape 的样例
diff --git a/.claude/skills/ptoas-usability-eval/references/scope.md b/.claude/skills/ptoas-usability-eval/references/scope.md
new file mode 100644
index 000000000..96e5cb004
--- /dev/null
+++ b/.claude/skills/ptoas-usability-eval/references/scope.md
@@ -0,0 +1,129 @@
+# PTOAS 评估范围映射
+
+## 六大场景映射
+
+| 场景 | 结论 | 处理方式 | PTOAS 中可量化的部分 | 默认不直接量化的部分 |
+| --- | --- | --- | --- | --- |
+| `01 算子复现部署` | 主评估场景 | 正常评分 | 构建、CLI、Python 绑定、sample、compile-only、board-validation | 无 |
+| `02 算子迁移部署` | 有限纳入 | 评“迁移支撑能力” | PTO IR 入口、样例/PyPTO 快照、compile-only/validation、迁移前后对照样例 | 业务框架集成、完整模型接线、仓外工程改造 |
+| `03 builtin 算子定制修改` | 默认不纳入 | 标 `N/A`，必要时只做差距说明 | 无固定模板 | builtin/业务算子定制主流程 |
+| `04 算子基本功能实现` | 次级支撑 | 只评 PTOAS 直接支撑的工程子链路 | 文档、样例、编译配置、工程编译、运行反馈、验证 | 完整需求分析、完整方案设计、通用算子研发全过程 |
+| `05 特定 shape 性能优化` | 条件纳入 | 评“特定 shape 性能优化支撑能力” | 性能文档、固定 shape 样例、性能数据获取入口、编译验证、精度/性能验证 | 没有 baseline 时的性能提升幅度、仓外友商对标 |
+| `06 泛化 shape 性能优化` | 条件纳入 | 评“多 shape / dynamic shape 支撑能力” | `valid_shape`/dynamic shape 文档、泛化样例、多 shape 验证链路 | 没有多 shape 基线矩阵时的平均/最大收益结论 |
+
+## 评估层级
+
+任何量化前都先声明层级：
+
+- `L1 文档审阅层`：只看仓库内容，不跑命令。
+- `L2 本地最小运行层`：当前机器已有 PTOAS 产物，可验证最小命令。
+- `L3 Linux compile-only 层`：Linux + CANN/bisheng + `PTO_ISA_ROOT`，不要求带卡。
+- `L4 NPU 上板层`：带卡 Linux、驱动、ACL、设备节点和用户权限齐全。
+
+评分规则：
+- 某层未覆盖，只能标 `未实测`。
+- 不得因为本机不是 Linux / 没有 `bisheng` / 没有 NPU 就对 PTOAS 本身扣分。
+- 文档是否清楚说明这些前置条件，才属于可评分项。
+
+## `02` 的适用边界
+
+PTOAS 可以支撑 `02`，但只能评“迁移支撑能力”，不能假装它已经覆盖完整业务迁移平台。
+
+可以评分的证据：
+- `docs/PTO_IR_manual.md`：IR 层级、tile/view/valid-shape 语义、Level-2/Level-3 入口
+- `test/samples/PyPTOIRParser/README.md`：来自 pypto `ir_parser` 的 vendored `.pto` 快照
+- `test/samples/*`：迁移后 PTO case、样例目录、`golden.py`/`compare.py`
+- `docs/no_npu_compile_only_guide_zh.md`、`runop.sh`、remote validation 脚本：迁移后 compile/validate 链路
+
+`02` 里这些指标只有在“有前后对照”时才能量化：
+- `tiling 迁移完备度`
+- `kernel 迁移完备度`
+- `tiling/kernel 代码修改率`
+- `功能失败率`
+- `性能劣化率`
+
+如果当前任务没有“迁移前/迁移后”对照 case：
+- 记 `未实测`，不要臆造百分比。
+- 若该项本质依赖仓外业务工程，且用户没有给材料，可记 `N/A` 并说明原因。
+
+## `04` 的适用边界
+
+`04` 只纳入这些与 PTOAS 仓库直接对应的子项：
+- 文档获取
+- 文档学习
+- 获取示例代码
+- 学习/理解示例代码
+- 运行示例代码
+- 编译配置
+- 算子工程编译
+- 功能调试
+- 精度调试中 repo 已有 compare/golden/validation 的部分
+
+默认排除：
+- 算子设计-需求分析
+- 算子设计-方案实现
+- 通用算子代码开发全过程
+- 脱离 PTOAS 仓库的业务工程联调
+
+## `05` 的适用边界
+
+PTOAS 可以支撑 `05`，但重点是“特定 shape 性能优化的仓内支撑能力”。
+
+可直接使用的仓内证据：
+- `docs/PTO_IR_manual.md`：Level-2/Level-3、layout、partition、reshape、valid-shape 等语义
+- `.github/ISSUE_TEMPLATE/performance_issue.yml`：性能问题收集模板
+- `test/samples/FlashAttention/`, `test/samples/GQA/`, `test/samples/FFN/`, `test/samples/MatMul/`：固定 shape 样例
+- `runop.sh`、compile-only 文档、remote validation 脚本：生成、编译、上板验证链路
+
+`05` 里这些项通常至少要到 `L4` 才能量化：
+- 性能数据采集耗时
+- 性能报告完备度
+- 优化迭代次数/耗时/成功率
+- 性能提升幅度
+- 精度一致性验证
+
+如果只有文档和样例，没有真实 benchmark/baseline：
+- 文档和入口可评分
+- 真实性能数字、友商对标、提升幅度一律 `未实测` 或 `N/A`
+
+## `06` 的适用边界
+
+PTOAS 可以支撑 `06`，但重点是“多 shape / dynamic shape / valid-shape 的泛化支撑能力”。
+
+可直接使用的仓内证据：
+- `docs/PTO_IR_manual.md`
+- `test/samples/SetValidShape/`
+- `test/samples/LayoutInference/`
+- `test/samples/Partition5D/`
+- `test/samples/planmemory/`
+- 其他带动态 shape / layout / partition / subview / reshape 的样例
+
+`06` 里这些项没有多 shape 基线矩阵时不能硬算：
+- 平均优化迭代次数
+- 平均优化耗时
+- 平均性能提升幅度
+- 最大性能提升幅度
+- 多 shape 精度保持率
+
+如果当前任务只看到 IR 设计与样例，没有多 shape 实测：
+- 文档、样例覆盖度可评分
+- 多 shape 性能/精度结果记 `未实测`
+
+## `未实测` 与 `N/A` 的使用规则
+
+记 `未实测`：
+- 仓库里有入口，但当前会话没有进入对应层级
+- 缺 Linux/CANN/NPU/baseline，导致只能停在文档或最小运行层
+- 缺迁移前后对照物，无法给出完成度/收益率
+
+记 `N/A`：
+- 指标本身超出 PTOAS 仓库边界
+- 用户要求的是仓外业务工程能力，当前仓库没有独立证据链
+- 友商对标、完整业务迁移、完整 builtin 定制等不是本 Skill 的默认量化对象
+
+## 使用原则
+
+- 如果用户没有特别说明，直接按 `01` 做主评估。
+- 如果用户要求顺带看 `02/04/05/06`，按本文件的边界补相应子集。
+- 可以做“支持度评分”，但不要把仓内文档/样例的存在，夸大成业务侧已经打通。
+- 能量化就量化；不能量化就明确说明为什么是 `未实测` 或 `N/A`。
diff --git a/.claude/skills/ptoas-usability-eval/references/scoring.md b/.claude/skills/ptoas-usability-eval/references/scoring.md
new file mode 100644
index 000000000..ba3d01d6d
--- /dev/null
+++ b/.claude/skills/ptoas-usability-eval/references/scoring.md
@@ -0,0 +1,148 @@
+# 总分汇总规则
+
+本文件定义 PTOAS 易用性评估的总分汇总方法，解决两个问题：
+- 单项指标混用 `10 分制` 和 `100 分制`
+- `未实测` / `N/A` 不能被误当成低分
+
+## 1. 基本原则
+
+- 单项展示时，保留用户原始分制。
+- 汇总总分时，再做统一归一化。
+- 场景分只基于本次选中的 `Core/Conditional Touch-Points` 或其 repo 级代理指标计算。
+- 默认输出两个总分：
+  - `总分（支撑）`
+  - `总分（实测）`
+
+## 2. 单项归一化
+
+把单项分数统一换算到 `100` 分制：
+
+- 原始 `10` 分制：`归一化分 = 原始分 * 10`
+- 原始 `100` 分制：`归一化分 = 原始分`
+
+示例：
+- `8/10 -> 80/100`
+- `60/100 -> 60/100`
+
+## 3. 特殊值处理
+
+- `未实测`：不计入任何总分分母
+- `N/A`：不计入任何总分分母
+- 如果某个场景下所有指标都是 `未实测/N/A`：
+  - 该场景分不输出数值
+  - 标记为 `本次无实测样本`
+
+## 4. 场景分
+
+先算场景分，再算总分。
+
+### 4.1 场景支撑分
+
+定义：该场景下所有“已评分”的指标，归一化后求平均。
+
+纳入范围：
+- 文档
+- 样例
+- 脚本
+- 配置
+- 已实测项
+
+排除范围：
+- `未实测`
+- `N/A`
+
+用途：衡量 PTOAS 仓库本身提供的支撑能力。
+
+### 4.2 场景实测分
+
+定义：该场景下所有“有真实执行证据”的指标，归一化后求平均。
+
+必须满足至少一种证据：
+- 真实命令执行
+- 真实编译/build
+- 真实 sample 运行
+- 真实 validation / compare / board 结果
+
+不纳入：
+- 纯文档发现性分
+- 纯 README/脚本存在性分
+- `未实测`
+- `N/A`
+
+用途：衡量当前会话里真正被跑通或被验证到的易用性。
+
+## 5. 默认场景权重
+
+如果用户没有单独指定权重，默认用：
+
+- `01`：`40%`
+- `02`：`15%`
+- `04`：`15%`
+- `05`：`15%`
+- `06`：`15%`
+
+说明：
+- `01` 是 PTOAS 的主评估场景，所以权重最高。
+- `02/04/05/06` 是补充场景，默认均分剩余权重。
+
+## 6. 权重重分配
+
+不要把没有参与本次评估的场景硬算进总分。
+
+### 6.1 用户只评部分场景
+
+如果本次只评了部分场景，例如只评 `01 + 04`：
+- 先取这两个场景的默认权重 `40` 和 `15`
+- 再重分配到 `100%`
+
+例：
+- `01` 新权重 = `40 / (40+15) = 72.73%`
+- `04` 新权重 = `15 / (40+15) = 27.27%`
+
+### 6.2 计算 `总分（支撑）`
+
+- 只保留“有场景支撑分”的场景
+- 对这些场景的默认权重重分配后加权平均
+
+### 6.3 计算 `总分（实测）`
+
+- 只保留“有场景实测分”的场景
+- 对这些场景的默认权重重分配后加权平均
+
+## 7. 输出要求
+
+建议固定输出以下内容：
+
+- `总分（支撑）`：`xx/100`
+- `总分（实测）`：`xx/100` 或 `本次无法计算`
+- `覆盖场景`：本次实际评了哪些场景
+- `覆盖层级`：`L1/L2/L3/L4` 到了哪一层
+- `实测覆盖说明`：哪些场景只有文档分，哪些场景有真实执行分
+
+## 8. 解释口径
+
+当两个总分差异较大时，优先按下面口径解释：
+
+- `总分（支撑）` 高、`总分（实测）` 低：
+  - 仓库文档/样例/脚本铺得比较全
+  - 但当前会话真实跑通度一般，或存在环境/样例摩擦
+
+- `总分（支撑）` 低、`总分（实测）` 高：
+  - 当前 case 可能能跑
+  - 但仓库的通用文档化、模板化、可发现性较弱
+
+- `总分（实测）` 显示为 `本次无法计算`：
+  - 说明本次基本停留在 `L1`，或者只有文档审阅，没有足够的真实执行证据
+
+## 9. 推荐展示格式
+
+```text
+总分（支撑）: 78.5/100
+总分（实测）: 66.4/100
+覆盖场景: 01, 02, 04, 05, 06
+覆盖层级: L1 + L2
+说明:
+- 01/04 同时形成支撑分和实测分
+- 02/05/06 当前主要形成文档/样例支撑分
+- L3/L4 未实测，不计入实测总分分母
+```
diff --git a/.claude/skills/ptoas-usability-eval/references/touchpoint-selection.md b/.claude/skills/ptoas-usability-eval/references/touchpoint-selection.md
new file mode 100644
index 000000000..d57a6d79e
--- /dev/null
+++ b/.claude/skills/ptoas-usability-eval/references/touchpoint-selection.md
@@ -0,0 +1,154 @@
+# PTOAS Touch-Point 选型
+
+本文件把用户提供的总触点池裁剪成适合 `hw-native-sys/PTOAS` 的 repo 级评估子集。
+
+## 1. 选型原则
+
+- PTOAS 是**编译器 / 工具链 / 样例仓库**，不是完整 CANN 产品矩阵，也不是官方镜像分发平台。
+- 默认优先评估这些触点：
+  - `资料/文档`
+  - `API/接口` 中与 `CLI / Python 绑定 / PTO IR 手册` 直接相关的子项
+  - `源码 & 示例类`
+  - `工具`
+  - `版本` 中 repo 内可自证的子项
+  - `运行反馈`
+- 对需要**产品级生态、仓外对标、跨硬件矩阵、发布渠道运营**的数据，默认不要硬打 repo 分，记 `N/A` 或只做差距说明。
+
+## 2. 默认纳入的 Core Touch-Points
+
+这些触点默认进入 PTOAS repo 级评分。
+
+### 2.1 资料/文档
+
+- `TP001` 检索命中成功率
+- `TP002` 文档跳转次数
+- `TP003` 多入口可达率
+- `TP004` 单次任务文档跳转浏览率
+- `TP005` 知识渐进式发布
+- `TP008` 文档结构风格一致率
+- `TP009` 概念跨文档冲突数
+- `TP011` 文档、版本时效一致性
+- `TP012` 内/外链有效率
+- `TP013` 文档错误点位密度
+- `TP016` 资料交付件完备率
+- `TP017` 文档场景/内容覆盖缺失率
+- `TP018` quick_start / sample 一次跑通率
+
+### 2.2 API / 接口
+
+这里只看 PTOAS repo 自己暴露的接口层：
+- `CLI`: `ptoas`, `ptobc`
+- `Python bindings`
+- `PTO IR` 公开手册/Op 语义
+
+默认纳入：
+- `TP019` 目标接口平均查找检索轮次
+- `TP020` 渐进式复杂披露覆盖度
+- `TP028` 平均入参数 / 参数复杂度
+- `TP032` 接口自解释读懂率
+
+### 2.3 源码 & 示例类
+
+- `TP034` 示例代码无修改一键编译运行成功率
+- `TP035` 示例检索命中成功率
+- `TP036` 样例覆盖度
+- `TP037` 最小功能实现 Demo 覆盖率
+- `TP038` 命令示例覆盖度
+- `TP039` API 调用样例覆盖率
+- `TP042` 样例代码编译语法错误检出率
+- `TP043` 样例使用废弃 / 过期 API 占比
+- `TP044` 业务代码直接复用改编比例
+- `TP045` 编程模型标准对齐率
+- `TP046` 关键链路显性化率
+- `TP047` 认知理解步数
+
+### 2.4 工具
+
+- `TP049` 首次安装部署一次性成功率
+- `TP051` 标准任务平均操作步骤数
+- `TP052` 功能 / 场景覆盖率
+
+### 2.5 版本
+
+只纳入 repo 内可通过 `README / CI / tag / branch / issue template` 自证的部分：
+- `TP053` 版本检索命中成功率
+- `TP058` 版本配套关系准确性
+
+### 2.6 运行反馈
+
+- `TP062` 报错携带环境 / 版本 / 上下文信息完整率
+- `TP063` 报错自带排障建议比例
+- `TP064` 无效冗余信息占比
+
+## 3. 条件纳入的 Conditional Touch-Points
+
+这些触点只有在用户明确要求，或者当前任务确实提供了对应证据时才纳入。
+
+### 3.1 文档 / API 条件项
+
+- `TP006` FAQ 命中率
+- `TP010` 接口文档模板一致率
+- `TP014` API 文档覆盖率
+- `TP015` 错误码文档化率
+- `TP033` N+2 小版本破坏性接口变更频次
+
+### 3.2 示例 / 性能高级项
+
+- `TP040` E2E 实战案例覆盖率
+- `TP041` 行业深度调优案例覆盖率
+
+### 3.3 版本 / 部署高级项
+
+- `TP054` 版本信息完备率
+- `TP057` 版本号规范准确率
+- `TP059` 版本部署命令数
+- `TP060` 开箱部署成功率
+- `TP061` 版本兼容性率
+
+说明：
+- `TP061` 在 PTOAS 里通常要到 `L4`，并且需要 A3/A5/不同硬件的实测证据。
+- `TP040/TP041` 在 PTOAS 里只有当 `FlashAttention/GQA/FFN` 这类样例被当作准业务案例使用时才适合纳入。
+
+## 4. 默认排除的 Excluded Touch-Points
+
+这些触点默认**不进入** PTOAS repo 级总分，除非用户明确要求做生态级差距研究。
+
+### 4.1 产品生态 / 友商对标类
+
+- `TP021` API 业务场景覆盖率
+- `TP022` 主流 AI 应用框架 API 支持覆盖率
+- `TP023` 主流 AI 框架 API 支持覆盖率
+- `TP024` API 主流生态调用一致性
+- `TP025` 原子 API 与标杆 API 数量对比一致性
+- `TP026` 迁移修改代码（CUDA -> AscendC）
+- `TP027` 原子 API 与标杆 API 行为对比一致性
+
+原因：这些指标要求的是**全产品生态**、**仓外框架集成**、**与 CUDA/CANN 大盘对比**，不是 PTOAS 仓库单独可证的事实。
+
+### 4.2 不适合 PTOAS repo 形态的项
+
+- `TP029` 错误返回一致率
+- `TP030` 最小可用代码行数
+- `TP055` 主流镜像仓支持下载覆盖度
+- `TP056` 典型部署模式支持覆盖度
+
+原因：
+- PTOAS 不是以统一 runtime C API 为主的库产品，`TP029/TP030` 不适合直接套。
+- PTOAS repo 不是镜像/安装包分发平台，`TP055/TP056` 默认不打 repo 分。
+
+## 5. 场景到 Touch-Point 的默认映射
+
+| 场景 | 默认 Core Touch-Points | 条件 Touch-Points |
+| --- | --- | --- |
+| `01 算子复现部署` | `TP001-005, TP008-018, TP034-035, TP038, TP042, TP044, TP049, TP051-053, TP058, TP062-064` | `TP006, TP054, TP057, TP059-061` |
+| `02 算子迁移部署` | `TP001-005, TP008-009, TP011, TP013, TP017, TP019-020, TP032, TP035-037, TP039, TP044, TP046-047, TP051-052, TP062-064` | `TP040-041, TP033, TP061` |
+| `04 算子基本功能实现` | `TP001-005, TP008-009, TP011, TP013, TP017-020, TP028, TP032, TP034-039, TP042-047, TP049, TP051-052, TP062-064` | `TP006, TP010, TP014-015, TP033` |
+| `05 特定 shape 性能优化` | `TP001-005, TP017, TP019-020, TP035-036, TP039, TP044, TP046, TP049, TP051-052, TP062-064` | `TP040-041, TP054, TP061` |
+| `06 泛化 shape 性能优化` | `TP001-005, TP017, TP019-020, TP035-036, TP039, TP044, TP046-047, TP049, TP051-052, TP062-064` | `TP040-041, TP054, TP061` |
+
+## 6. 使用要求
+
+- 每次正式评估前，先在输出里给出 `触点选择`。
+- 默认只打 `Core Touch-Points`。
+- `Conditional Touch-Points` 只有在证据存在时才纳入，并明确说明为什么本次纳入。
+- `Excluded Touch-Points` 不进入总分；如果用户追问，可以单独给差距分析，但不要混入 repo 级总分。
diff --git a/.codex/skills/ptoas-usability-eval/README.md b/.codex/skills/ptoas-usability-eval/README.md
new file mode 100644
index 000000000..3f8fd8545
--- /dev/null
+++ b/.codex/skills/ptoas-usability-eval/README.md
@@ -0,0 +1,33 @@
+# PTOAS Usability Eval Skill
+
+这是 PTOAS 仓库内的通用 Skill 源目录。
+
+支持的客户端入口：
+- Codex: `.codex/skills/ptoas-usability-eval/`
+- Cursor: `.cursor/skills/ptoas-usability-eval/`
+- Trae: `.trae/skills/ptoas-usability-eval/`
+- Claude Code: `.claude/skills/ptoas-usability-eval/`
+
+当前覆盖的评估场景：
+- `01 算子复现部署`
+- `02 算子迁移部署` 的 PTOAS 支撑子集
+- `04 算子基本功能实现` 的 PTOAS 工程子集
+- `05 特定 shape 性能优化` 的 PTOAS 支撑子集
+- `06 泛化 shape 性能优化` 的 PTOAS 支撑子集
+
+当前附带的汇总规则：
+- 原始指标保留 `10 分制 / 100 分制`
+- 汇总时统一归一到 `100` 分制
+- 默认输出 `总分（支撑）` 和 `总分（实测）`
+- `未实测/N/A` 不进入总分分母
+
+当前评估逻辑：
+- 先按 `touch-point` 体系选取适用于 PTOAS 的触点
+- 再按 `01/02/04/05/06` 场景评分
+- 默认只把适用的 `Core Touch-Points` 放进 repo 级总分
+
+约定：
+- `skills/ptoas-usability-eval/` 作为仓库内的通用主副本
+- 各客户端目录提供可直接发现的副本，便于不同工具开箱即用
+- 修改 Skill 内容时，应同步更新上述四个客户端目录
+- 对 `L3/L4` 依赖 Linux/CANN/NPU 的指标，未实测时必须标 `未实测`，不能因为当前机器缺环境直接给 PTOAS 低分
diff --git a/.codex/skills/ptoas-usability-eval/SKILL.md b/.codex/skills/ptoas-usability-eval/SKILL.md
new file mode 100644
index 000000000..24cc41525
--- /dev/null
+++ b/.codex/skills/ptoas-usability-eval/SKILL.md
@@ -0,0 +1,98 @@
+---
+name: ptoas-usability-eval
+description: Evaluate PTOAS repository usability across scene 01 as the primary template plus the PTOAS-supported subsets of scenes 02, 04, 05, and 06. Always classify the evaluation by environment layer first, use only repo-native docs/scripts/samples/CI as primary evidence, keep the user's mixed 10-point and 100-point scoring rules, compute normalized support and measured totals, and mark unsupported or untested dimensions as 未实测 or N/A.
+---
+
+# PTOAS Usability Eval
+
+当用户要评估 `hw-native-sys/PTOAS` 的易用性，或要按 `01/02/04/05/06` 给 PTOAS 打分时，使用这个 Skill。
+
+## 默认范围
+
+- `01 算子复现部署`：主评估场景，正常评分。
+- `02 算子迁移部署`：纳入，但只评 PTOAS 仓库能直接支撑的迁移入口、样例、IR/脚本、编译验证链路。
+- `04 算子基本功能实现`：纳入，但只评 PTOAS 直接覆盖的示例、编译、验证、反馈子链路。
+- `05 特定 shape 性能优化`：纳入，但只评 PTOAS 的文档、样例、性能数据获取入口、编译验证、精度/性能验证支撑能力。
+- `06 泛化 shape 性能优化`：纳入，但只评 PTOAS 的 dynamic/valid-shape、多 shape 样例与验证支撑能力。
+- `03 builtin 算子定制修改`：默认不纳入量化，标 `N/A`；必要时只做差距说明。
+
+先读 [references/touchpoint-selection.md](references/touchpoint-selection.md) 选定适用触点，再读 [references/scope.md](references/scope.md) 确认各场景的边界和 `未实测/N/A` 规则。
+
+## 先判层级
+
+开始评分前，必须先声明本次评估覆盖到哪一层。没有层级，不能直接混着打分。
+
+可选层级：
+- `L1 文档审阅层`：只看仓库文档、脚本、样例、CI，不做运行。
+- `L2 本地最小运行层`：当前机器已有 `ptoas` / `ptobc` / Python 绑定，可做最小命令验证。
+- `L3 Linux compile-only 层`：需要 Linux + CANN/bisheng + `PTO_ISA_ROOT`，不要求带卡。
+- `L4 NPU 上板层`：需要带卡 Linux、驱动、权限、`/dev/davinci*` 与对应用户组。
+
+约束：
+- 没进入某层，就把该层指标记为 `未实测`，不能因为当前机器缺环境就给 PTOAS 低分。
+- `bisheng` / CANN compile-only 一般属于 `L3`，不应在本地 Mac 上硬打低分。
+- 带卡运行、设备权限、驱动、ACL、用户组属于 `L4`。
+
+## 证据来源
+
+优先只用仓库内证据，不把仓外经验当成主证据。固定入口见 [references/evidence-checklist.md](references/evidence-checklist.md)。
+
+高优先级证据：
+- `README.md`
+- `docs/no_npu_compile_only_guide_zh.md`
+- `docs/PTO_IR_manual.md`
+- `test/samples/runop.sh`
+- `test/npu_validation/scripts/generate_testcase.py`
+- `test/npu_validation/scripts/run_remote_npu_validation.sh`
+- `test/samples/PyPTOIRParser/README.md`
+- `test/samples/FlashAttention/`, `test/samples/GQA/`, `test/samples/FFN/`
+- `test/samples/SetValidShape/`, `test/samples/LayoutInference/`, `test/samples/Partition5D/`, `test/samples/planmemory/`
+- `.github/workflows/ci.yml`
+- `.github/ISSUE_TEMPLATE/performance_issue.yml`
+
+## 工作流
+
+1. 先判断用户要的是 `01`、`02`、`04`、`05`、`06` 中哪些场景；未说明时默认 `01`。
+2. 再判断本次覆盖层级：`L1/L2/L3/L4`。输出中必须显式写出来。
+3. 先读 [references/touchpoint-selection.md](references/touchpoint-selection.md)，按场景选定本次的 `Core / Conditional / Excluded` 触点。
+4. 从仓库内收集证据，记录每次检索轮次、文档跳转次数、执行命令、耗时、成功/失败结果。
+5. `01` 场景读 [references/metrics-01.md](references/metrics-01.md)。
+6. `02` 场景读 [references/metrics-02.md](references/metrics-02.md)。
+7. `04` 场景读 [references/metrics-04.md](references/metrics-04.md)。
+8. `05` 场景读 [references/metrics-05.md](references/metrics-05.md)。
+9. `06` 场景读 [references/metrics-06.md](references/metrics-06.md)。
+10. 需要汇总总分时，读 [references/scoring.md](references/scoring.md)。
+11. 对每个指标都输出：原始观测值、评分、证据路径、说明。没有实测的数据不要猜，记为 `未实测` 或 `N/A`。
+12. 明确区分：
+    - PTOAS 仓库已提供的能力
+    - 外部前置条件，例如 LLVM、CANN、`pto-isa`、NPU、驱动/权限、业务 baseline
+13. 若文档描述与实际运行冲突，以实际命令结果为准，并指出冲突位置。
+14. 默认给两个总分：`总分（支撑）` 和 `总分（实测）`。如果用户只要分项，不强制输出总分。
+
+## 计量规则
+
+- 保留用户原始口径，不强行覆盖各指标的原始分制。
+- 但做总分汇总时，必须按 [references/scoring.md](references/scoring.md) 做归一化。
+- `检索轮次`：每次新的定向搜索或定位尝试算 1 轮。
+- `文档跳转次数`：命中首个目标文档后，每跨一个文档/README/脚本入口算 1 次。
+- `耗时`：尽量记录真实墙钟时间；拿不到就写 `未实测`，不要臆测。
+- `成功率`：只基于当前任务里真实执行或真实定位到的结果计算。
+- `未实测`：当前会话未覆盖到对应环境层级，或该层级前置条件不存在，或缺少前后对照 baseline。
+- `N/A`：只用于超出 PTOAS 能力边界，或当前任务明确不纳入本次评估范围的项。
+
+## 输出格式
+
+按下面顺序输出：
+
+1. `评估范围`
+2. `触点选择`
+3. `评估层级`
+4. `总分（支撑）`
+5. `总分（实测）`
+6. `分场景评分`
+7. `覆盖说明`
+8. `关键证据`
+9. `主要短板`
+10. `建议动作`
+
+如果用户只要简版结论，也要至少保留：场景归类、评估层级、总评、最低分项、证据路径。
diff --git a/.codex/skills/ptoas-usability-eval/agents/openai.yaml b/.codex/skills/ptoas-usability-eval/agents/openai.yaml
new file mode 100644
index 000000000..924e59e3f
--- /dev/null
+++ b/.codex/skills/ptoas-usability-eval/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "PTOAS Usability Eval"
+  short_description: "评估 PTOAS 在 01/02/04/05/06 场景下的易用性"
+  default_prompt: "Use $ptoas-usability-eval to evaluate this PTOAS repo for scene 01 operator reproduction/deployment and the PTOAS-supported subsets of scenes 02, 04, 05, and 06."
diff --git a/.codex/skills/ptoas-usability-eval/references/evidence-checklist.md b/.codex/skills/ptoas-usability-eval/references/evidence-checklist.md
new file mode 100644
index 000000000..89b6f1987
--- /dev/null
+++ b/.codex/skills/ptoas-usability-eval/references/evidence-checklist.md
@@ -0,0 +1,86 @@
+# 证据清单
+
+## 固定证据入口
+
+| 路径 | 主要用途 | 对应场景 | 层级 | 主要触点 |
+| --- | --- | --- | --- | --- |
+| `README.md` | 官方构建、环境变量、CLI、Python 绑定、sample 运行、compile-only/上板验证主入口 | `01`, `02`, `04`, `05`, `06` | `L1-L4` | `TP001-005, TP016-020, TP038, TP049, TP053, TP058` |
+| `docs/no_npu_compile_only_guide_zh.md` | 无卡 compile-only 流程、批量验证流程、`pto-isa`/CANN 依赖说明 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3` | `TP005, TP017-018, TP049, TP051-052, TP058-060, TP062-064` |
+| `docs/PTO_IR_manual.md` | IR 层级、tile/view/valid-shape、layout、dynamic shape、Level-2/3 语义 | `02`, `04`, `05`, `06` | `L1-L4` | `TP019-020, TP028, TP032, TP039, TP045-047` |
+| `test/samples/runop.sh` | 批量样例生成、`ptoas`/`ptobc` 运行、A3/A5 默认参数策略 | `01`, `02`, `04`, `05`, `06` | `L1-L4` | `TP018, TP034-039, TP049, TP051-052, TP062-064` |
+| `test/npu_validation/scripts/generate_testcase.py` | 从 `*-pto.cpp` 生成验证工程，观察 golden/compare/兼容层处理 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3`, `L4` | `TP037-039, TP045-047, TP049, TP052` |
+| `test/npu_validation/scripts/run_remote_npu_validation.sh` | compile-only / sim / npu 运行链路、日志格式、设备与 `pto-isa` 检查 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3`, `L4` | `TP049, TP051-052, TP058-060, TP062-064` |
+| `test/samples/PyPTOIRParser/README.md` | 来自 pypto `ir_parser` 的 vendored `.pto` 快照说明 | `02` | `L1` | `TP035-037, TP039, TP044, TP046-047` |
+| `test/samples/MatMul/` | README 直接引用的基准样例，适合作为 `01` 默认复现模板 | `01`, `04`, `05` | `L1-L4` | `TP018, TP034-039, TP042-047` |
+| `test/samples/FlashAttention/` | 特定 shape 性能样例 | `05` | `L1-L4` | `TP035-041, TP044, TP046` |
+| `test/samples/GQA/` | 特定 shape / attention 相关样例 | `05` | `L1-L4` | `TP035-041, TP044, TP046` |
+| `test/samples/FFN/` | 特定 shape / 算子组合样例 | `05` | `L1-L4` | `TP035-041, TP044, TP046` |
+| `test/samples/SetValidShape/` | dynamic/valid-shape 相关样例 | `06` | `L1-L4` | `TP035-039, TP044, TP046-047` |
+| `test/samples/LayoutInference/` | layout 推断相关样例 | `06` | `L1-L4` | `TP019-020, TP035-039, TP046-047` |
+| `test/samples/Partition5D/` | 多维 partition / shape 泛化相关样例 | `02`, `06` | `L1-L4` | `TP035-039, TP044, TP046-047, TP061` |
+| `test/samples/planmemory/` | alias/planmemory/shape 相关样例 | `06` | `L1-L4` | `TP035-039, TP044, TP046-047` |
+| `.github/workflows/ci.yml` | CI 中的 LLVM/PTOAS 构建、lit、sample test、remote validation 参考配置 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3`, `L4` | `TP003, TP011, TP049, TP052-053, TP058, TP060-064` |
+| `.github/ISSUE_TEMPLATE/performance_issue.yml` | 性能问题受理模板，可用来评估性能数据/复现要求的完备性 | `05`, `06` | `L1` | `TP005, TP017, TP040-041, TP062-063` |
+
+说明：
+- 不要把当前分支不存在的样例 README 当成固定证据源。
+- 对 `02/05/06`，没有“前后对照基线”时，不要硬算迁移完备度或性能提升幅度。
+
+## 推荐检索顺序
+
+1. `README.md`
+2. `docs/no_npu_compile_only_guide_zh.md`
+3. `docs/PTO_IR_manual.md`
+4. `test/samples/MatMul/` 或用户指定样例目录
+5. `test/samples/PyPTOIRParser/`, `FlashAttention/`, `GQA/`, `FFN/`, `SetValidShape/`, `LayoutInference/`, `Partition5D/`, `planmemory/`
+6. `test/samples/runop.sh`
+7. `test/npu_validation/scripts/*.py` / `*.sh`
+8. `.github/workflows/ci.yml`
+9. `.github/ISSUE_TEMPLATE/performance_issue.yml`
+
+## 推荐检索命令
+
+```bash
+rg -n "构建|运行测试|compile-only|runop|generate_testcase|run_remote_npu_validation|level3" README.md docs test .github
+rg -n "valid_shape|layout|partition|reshape|dynamic shape|Level-2|Level-3" docs/PTO_IR_manual.md docs test
+rg -n "FlashAttention|GQA|FFN|MatMul|SetValidShape|LayoutInference|Partition5D|planmemory" test .github
+rg --files test/samples
+find test/samples -maxdepth 2 -type f \( -name '*.py' -o -name '*.pto' -o -name 'README.md' \)
+```
+
+## 迁移 / 性能场景的补充记录项
+
+如果在评 `02/05/06`，额外记录：
+- 是否存在迁移前/迁移后对照物
+- 是否存在性能 baseline
+- baseline 来源路径
+- 是否需要 NPU 实机
+- 当前停在哪一层
+- 哪些分数是实测，哪些是文档侧支撑分
+
+## 记录要求
+
+每个评分项至少要落这些证据字段：
+
+- `证据路径`
+- `检索/执行命令`
+- `检索轮次`
+- `文档跳转次数`
+- `评估层级`
+- `耗时`
+- `结果`
+- `评分`
+- `备注`
+
+## 默认样例
+
+若用户没有指定具体算子或样例，优先使用：
+
+- `test/samples/MatMul/tmatmulk.py`
+- `test/samples/MatMul/tmatmulk.pto`
+- `test/samples/Addc/addc.py`
+- `test/samples/PyPTOIRParser/`
+- `test/samples/FlashAttention/`
+- `test/samples/SetValidShape/`
+
+理由：这些路径要么被 `README.md` 直接引用，要么与迁移/性能/shape 泛化评估强相关，且当前主线可稳定找到。
diff --git a/.codex/skills/ptoas-usability-eval/references/metrics-01.md b/.codex/skills/ptoas-usability-eval/references/metrics-01.md
new file mode 100644
index 000000000..58bcc109d
--- /dev/null
+++ b/.codex/skills/ptoas-usability-eval/references/metrics-01.md
@@ -0,0 +1,119 @@
+# `01 算子复现部署` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP008-018`
+- `源码 & 示例类`: `TP034-035, TP038, TP042, TP044`
+- `工具`: `TP049, TP051-052`
+- `版本`: `TP053, TP058`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP006, TP054, TP057, TP059-061`
+
+默认把 PTOAS 看作“从样例或 `.pto` 输入出发，完成构建、编译、compile-only 或上板验证”的工具链仓库。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+在 `01` 场景里，必须先声明本次评估覆盖的层级：
+
+- `L1 文档审阅层`
+- `L2 本地最小运行层`
+- `L3 Linux compile-only 层`
+- `L4 NPU 上板层`
+
+没有进入对应层，就标 `未实测`，不要把环境缺失当成 PTOAS 负分。
+
+## 默认任务模板
+
+若用户没有指定具体 case，优先用 `test/samples/MatMul/` 作为复现模板：
+
+```bash
+python3 test/samples/MatMul/tmatmulk.py > /tmp/tmatmulk.pto
+./build/tools/ptoas/ptoas /tmp/tmatmulk.pto -o /tmp/tmatmulk.cpp
+```
+
+需要无卡 compile-only 时，继续参考：
+
+```bash
+python3 test/npu_validation/scripts/generate_testcase.py \
+  --input /tmp/tmatmulk.cpp \
+  --run-mode npu \
+  --soc-version Ascend910
+```
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 检索命中成功率 | 统计找到“构建 + sample 运行 + compile-only/上板验证”入口所需检索轮次 | `README.md`, `docs/no_npu_compile_only_guide_zh.md` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+| 文档检索耗时 | 从开始找文档到定位到正确路径的时间 | 同上 | `L1-L4` | `2 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 文档获取成功率 | 目标文档是否都能在仓库内找到 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+### 文档学习
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 文档错误点位密度 | 按文档执行时，检查命令、路径、版本、链接、说明是否错误 | `README.md`, `docs/no_npu_compile_only_guide_zh.md`, `.github/workflows/ci.yml` | `L1-L4` | 零错误 `100`；少量小错 `80`；一般错误 `60`；明显错误 `40`；严重不可用 `20` |
+| 文档跳转次数 | 从首个命中文档到凑齐完整执行路径，跨文档跳转的次数 | `README.md -> docs/... -> test/samples/...` | `L1-L4` | 1 次 `100`；2 次 `80`；3 次 `60`；4-5 次 `40`；>5 次 `20` |
+| 内容覆盖缺失率 | 是否清楚区分本地运行、Linux compile-only、带卡上板等层级前置条件 | `README.md`, `docs/...`, `.github/workflows/ci.yml` | `L1-L4` | 无缺失 `100`；`<=5%` `80`；`5%-15%` `60`；`15%-30%` `40`；`>30%` `20` |
+| 文档学习耗时 | 从开始读到能给出执行方案的时间 | 同上 | `L1-L4` | `5 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 通过文档学习检索成功率 | 需要通过文档解决的问题里，有多少真正被文档回答 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+## 易部署
+
+### 环境下载
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 环境获取场景覆盖率 | 看仓库是否说明源码构建、无卡 compile-only、上板验证所需环境 | `README.md`, `docs/no_npu_compile_only_guide_zh.md` | `L1-L4` | `100%=10`；`80%-99%=8`；`60%-79%=6`；`40%-59%=4`；`<40%=2` |
+| 环境下载耗时 | 真实下载 LLVM/CANN/Python 依赖/`pto-isa` 的时间 | 真实执行记录 | `L3-L4` | `<=5 分钟=10`；`5-7=8`；`7-9=6`；`9-11=4`；`>11=2` |
+| 环境下载成功率 | 下载步骤是否一次完成 | 真实执行记录 | `L3-L4` | `100%=10`，按比例计算 |
+
+说明：如果当前任务没有真的在 Linux/CANN 环境里下载依赖，后两项写 `未实测`。
+
+### 环境安装
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 软硬件配套兼容率 | 检查仓库是否明确 LLVM 版本、Python 包版本、CANN / `pto-isa` 依赖关系 | `README.md`, `docs/no_npu_compile_only_guide_zh.md`, `ci.yml` | `L1-L4` | `100%=10`；`80%-99%=8`；`60%-79%=6`；`40%-59%=4`；`<40%=2` |
+| 部署时长 | 从开始执行安装到可运行 `ptoas`/Python 绑定的时间 | 真实执行记录 | `L2-L4` | `<=5 分钟=10`；`5-7=8`；`7-9=6`；`9-11=4`；`>11=2` |
+| 操作步骤数 | 完成安装所需命令/步骤数量 | `README.md` 构建步骤 | `L1-L4` | `<=8 步=10`；`9-10=8`；`11-12=6`；`13-14=4`；`>14=2` |
+| 环境安装成功率 | 是否能完成 LLVM + PTOAS 构建与安装 | 真实执行记录 | `L2-L4` | `100%=10`，按比例计算 |
+
+### 环境校验
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 环境安装后校验成功率 | 是否有明确校验动作，例如 `ptoas --version`、Python import、sample compile | `README.md`, `ci.yml` | `L2-L4` | `100%=10`，按比例计算 |
+
+推荐最小校验命令：
+
+```bash
+./build/tools/ptoas/ptoas --version
+python3 -c "from mlir.dialects import pto; print('ok')"
+```
+
+## 易开发、易演进
+
+### 获取示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 检索命中成功率 | 统计定位到默认样例目录所需轮次 | `test/samples/MatMul/`, `test/samples/Addc/`, `README.md` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+
+### 运行示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 示例代码运行耗时 | 从运行 sample 到拿到 `.pto` / `.cpp` / compile-only 结果的时间 | `README.md`, `test/samples/MatMul/` | `L2-L4` | `<=2 分钟=10`；`2-4=8`；`4-6=6`；`6-8=4`；`>8=2` |
+| 示例代码运行成功率 | `py -> .pto -> .cpp` 或 compile-only / validation 是否成功 | 同上 | `L2-L4` | `100%=10`，按比例计算 |
+
+## 何时记 `未实测` / `N/A`
+
+- `未实测`：当前任务没有进入对应环境层级，例如在本地 Mac 上没有 Linux/CANN/bisheng，却要评价 compile-only。
+- `N/A`：该项超出 PTOAS 能力边界，或本次任务明确不纳入该项。
+
+不要把二者混用。
diff --git a/.codex/skills/ptoas-usability-eval/references/metrics-02.md b/.codex/skills/ptoas-usability-eval/references/metrics-02.md
new file mode 100644
index 000000000..8ad84dbf6
--- /dev/null
+++ b/.codex/skills/ptoas-usability-eval/references/metrics-02.md
@@ -0,0 +1,77 @@
+# `02 算子迁移部署` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP008-009, TP011, TP013, TP017`
+- `API / 接口`: `TP019-020, TP032`
+- `源码 & 示例类`: `TP035-037, TP039, TP044, TP046-047`
+- `工具`: `TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP040-041, TP033, TP061`
+
+这里只评估 PTOAS 仓库对“迁移到 PTO IR / PTOAS 工具链”的支撑能力，不把 PTOAS 包装成完整业务算子迁移平台。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`02` 场景同样先声明层级：
+
+- `L1 文档审阅层`
+- `L2 本地最小运行层`
+- `L3 Linux compile-only 层`
+- `L4 NPU 上板层`
+
+没有进入对应层，就标 `未实测`。
+
+## 共享易学习项
+
+`02` 的 `文档获取` / `文档学习` 默认复用 [metrics-01.md](metrics-01.md) 中对应规则；只是目标从“复现部署”改成“找到迁移入口、IR 语义、样例和验证链路”。
+
+推荐优先证据：
+- `docs/PTO_IR_manual.md`
+- `test/samples/PyPTOIRParser/README.md`
+- `README.md`
+- `docs/no_npu_compile_only_guide_zh.md`
+
+## 易迁移
+
+### 算子迁移
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| tiling 迁移完备度 | 统计迁移前定义的 tiling 结构中，已成功落到 PTO IR / sample / generated testcase 的比例 | `docs/PTO_IR_manual.md`, `test/samples/*`, 用户提供的前后对照物 | `L1-L4` | `100%=10`；`80%=8`；`60%=6`；`40%=4`；`20%=2` |
+| kernel 迁移完备度 | 统计迁移前 kernel 逻辑中，已能由 PTO case / sample / generated testcase 覆盖的比例 | 同上 | `L1-L4` | `100%=10`；`80%=8`；`60%=6`；`40%=4`；`20%=2` |
+| 算子功能失败率 | 迁移后 compile-only / validation / board case 失败比例 | `runop.sh`, `generate_testcase.py`, `run_remote_npu_validation.sh` | `L3-L4` | `0% 失败=10`；`10%=8`；`20%=6`；`30%=4`；`40%=2` |
+| 算子性能劣化率 | 迁移后相对迁移前 baseline 的性能增幅 | 用户 baseline、`performance_issue.yml`、实测日志 | `L4` | 劣化 `<5%=10`；`10%=8`；`20%=6`；`30%=4`；`40%=2` |
+| tiling 代码修改率 | 迁移时 tiling 相关代码修改行数 / 总行数 | 用户对照 case、PR diff | `L1-L4` | `0%-5%` 高分；`5%-15%` 次高；`15%-25%` 中；`25%-35%` 低；`>35%` 最低 |
+| kernel 代码修改率 | 迁移时 kernel 相关代码修改行数 / 总行数 | 用户对照 case、PR diff | `L1-L4` | `0%-5%` 高分；`5%-15%` 次高；`15%-25%` 中；`25%-35%` 低；`>35%` 最低 |
+| 算子迁移总耗时 | 从开始迁移到迁移完成，不含最终验证环节 | 真实执行记录 | `L2-L4` | `<=10 分钟` 高分；`10-20` 次之；`20-30` 中；`30-60` 低；`>60` 最低 |
+| 算子迁移成功率 | 迁移任务成功率 | 真实执行记录 | `L2-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 在 PTOAS 中如何落地这些指标
+
+### 可直接量化的前提
+
+只有当前任务同时具备以下材料时，才量化迁移完备度/修改率/失败率：
+- 迁移前输入：上游 IR、旧 kernel、旧 tiling，至少一种
+- 迁移后输入：PTO `.pto`、sample、generated testcase，至少一种
+- 对应验证链路：compile-only 或 board validation
+
+### 没有对照物时怎么办
+
+- 只有仓库文档和样例，没有迁移前材料：
+  - 可以评“入口是否清晰”“样例/脚本是否齐全”
+  - 不能给出完备度/修改率/性能劣化率，记 `未实测`
+- 指标本身依赖仓外业务工程，且用户没给材料：
+  - 记 `N/A`
+
+## 推荐默认证据路径
+
+- `docs/PTO_IR_manual.md`
+- `test/samples/PyPTOIRParser/README.md`
+- `test/samples/*`
+- `docs/no_npu_compile_only_guide_zh.md`
+- `test/samples/runop.sh`
+- `test/npu_validation/scripts/generate_testcase.py`
+- `test/npu_validation/scripts/run_remote_npu_validation.sh`
diff --git a/.codex/skills/ptoas-usability-eval/references/metrics-04.md b/.codex/skills/ptoas-usability-eval/references/metrics-04.md
new file mode 100644
index 000000000..d347924a6
--- /dev/null
+++ b/.codex/skills/ptoas-usability-eval/references/metrics-04.md
@@ -0,0 +1,116 @@
+# `04 算子基本功能实现` 的 PTOAS 子集指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP008-009, TP011, TP013, TP017-018`
+- `API / 接口`: `TP019-020, TP028, TP032`
+- `源码 & 示例类`: `TP034-039, TP042-047`
+- `工具`: `TP049, TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP006, TP010, TP014-015, TP033`
+
+这里只评估 PTOAS 真正覆盖到的“示例 / 编译 / 验证 / 反馈”链路，不把 PTOAS 当成完整算子研发平台。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`04` 子集同样先声明层级：
+
+- `L1 文档审阅层`
+- `L2 本地最小运行层`
+- `L3 Linux compile-only 层`
+- `L4 NPU 上板层`
+
+未进入对应层级，只能标 `未实测`。
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 检索命中成功率 | 找到目标样例、相关 CLI、验证脚本所需轮次 | `README.md`, `test/samples/`, `test/npu_validation/scripts/` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+| 文档检索耗时 | 从开始查到定位到目标入口的时间 | 同上 | `L1-L4` | `2 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 文档获取成功率 | 所需文档/脚本/样例是否都能在仓内找到 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+### 文档学习
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 文档错误点位密度 | 样例说明、命令、路径、环境前置条件是否准确 | `README.md`, sample README, `runop.sh`, `ci.yml` | `L1-L4` | 零错误 `100`；少量小错 `80`；一般错误 `60`；明显错误 `40`；严重不可用 `20` |
+| 文档跳转次数 | 为理解 sample 到 compile/validation 链路所需跳转次数 | 同上 | `L1-L4` | 1 次 `100`；2 次 `80`；3 次 `60`；4-5 次 `40`；>5 次 `20` |
+| 内容覆盖缺失率 | 样例定位、编译、验证、环境前置条件说明是否缺失 | 同上 | `L1-L4` | 无缺失 `100`；`<=5%` `80`；`5%-15%` `60`；`15%-30%` `40`；`>30%` `20` |
+| 文档学习耗时 | 从开始看文档到能解释执行路径的时间 | 同上 | `L1-L4` | `5 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 通过文档学习检索成功率 | 依赖文档回答的问题是否被解决 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+## 易开发、易演进
+
+### 获取示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 目标示例定位命中成功率 | 找到适合作为基本功能实现基线的 sample 或 `.pto` 所需轮次 | `test/samples/MatMul/`, `test/samples/Addc/`, `test/samples/PyPTOIRParser/` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+
+### 学习/理解示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 样例场景覆盖度 | 样例是否覆盖目标算子的输入、输出、golden/compare、compile/validation 场景 | 选定样例目录中的 `.py` / `.pto` / `npu_validation/` | `L1-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 样例学习分析 Token 数 | 优先使用平台可见的 AI token 统计；没有统计就写 `未量化` | 同上 | `L1-L4` | `<=500` 高分；`500-1000` 次高；`1000-2000` 中；`2000-3000` 低；`>3000` 最低 |
+| 示例理解耗时 | 从首次打开样例到能讲清输入、生成物、验证链路的时间 | 同上 | `L1-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-15` 中；`15-20` 低；`>20` 最低 |
+
+说明：如果运行环境拿不到 token 统计，第二项保留原值 `未量化`，不要编造 token 数。
+
+### 运行示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 运行成功率 | sample 首次执行是否能生成 `.pto` / `.cpp` / compile-only 验证工程 | `README.md`, `test/samples/runop.sh`, sample 目录 | `L2-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 示例代码运行耗时 | 从开始运行到 sample 结束的时间 | 同上 | `L2-L4` | `<=2 分钟` 高分；`2-4` 次之；`4-6` 中；`6-8` 低；`>8` 最低 |
+
+## 算子编译
+
+### 编译配置
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 新增/修改配置行数 | 按仓库已有说明运行 sample / validation 时，需要额外改多少配置行 | `README.md`, `docs/no_npu_compile_only_guide_zh.md`, `ci.yml` | `L1-L4` | `<5 行=100`；`<10=80`；`<15=60`；`<20=40`；`>20=20` |
+
+记录时只统计“文档外的额外修改”。按 README 就能跑通则记 `0` 行。
+
+### 算子工程编译
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 需要理解的宏/函数个数 | 为改通当前 sample / validation 链路，必须额外读懂多少宏/函数 | `runop.sh`, `generate_testcase.py`, `run_remote_npu_validation.sh`, sample CMake | `L1-L4` | `2 个=10`；`4 个=8`；`6 个=6`；`8 个=4`；`>10 个=2` |
+| 编译报错排障效率 | 从 sample / validation 工程编译到成功，中间修复了几轮 | `ninja`, `cmake --build`, validation 日志 | `L3-L4` | 无报错高分；1 次修复次之；2-3 次中；4-5 次低；>5 次最低 |
+| 编译耗时 | 开始编译到编译完成的总时间 | 同上 | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 编译成功率 | 最终编译是否成功，以及首次是否成功 | 同上 | `L3-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 功能调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 报错携带环境/版本/上下文信息完整率 | `ptoas` / validation 脚本报错时，是否包含 stage、case、路径、依赖、设备、soc/version 等信息 | `run_remote_npu_validation.sh`, sample/CI 日志 | `L2-L4` | 信息完整 `100`；`>=90%` `80`；`70%-89%` `60`；`50%-69%` `40`；`<50%` `20` |
+| 报错自带排障建议比例 | 报错是否已经给出下一步可排查方向 | 同上 | `L2-L4` | 全部带建议 `100`；`>=90%` `80`；`70%-89%` `60`；`50%-69%` `40`；`<50%` `20` |
+| 无效冗余信息占比 | 日志是否大量充斥与当前失败无关的信息 | 同上 | `L2-L4` | 无冗余 `100`；`<=5%` `80`；`5%-15%` `60`；`15%-30%` `40`；`>30%` `20` |
+| 功能调试耗时 | 从第一次失败到定位根因或跑通的时间 | 同上 | `L2-L4` | `<=10 分钟` 高分；`10-20` 次之；`20-30` 中；`30-60` 低；`>60` 最低 |
+| 功能调试成功率 | 当前目标问题是否最终解决 | 同上 | `L2-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 精度调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 精度数据获取耗时 | 获取 golden/output/compare 报告所需时间 | `generate_testcase.py`, sample `golden.py`, `compare.py` | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 定位分析次数 | 从发现精度问题到定位根因的迭代次数 | 真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 代码修改/迭代循环 | 精度修复迭代次数 | PR diff、真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+
+## 默认排除项
+
+这些在 PTOAS 仓库里默认不打分，直接标 `N/A`：
+
+- 算子设计-需求分析
+- 算子设计-方案实现
+- 通用算子代码开发全过程
+- 脱离 PTOAS 仓库的业务工程联调
diff --git a/.codex/skills/ptoas-usability-eval/references/metrics-05.md b/.codex/skills/ptoas-usability-eval/references/metrics-05.md
new file mode 100644
index 000000000..3b05aa815
--- /dev/null
+++ b/.codex/skills/ptoas-usability-eval/references/metrics-05.md
@@ -0,0 +1,82 @@
+# `05 特定 shape 性能优化` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP017`
+- `API / 接口`: `TP019-020`
+- `源码 & 示例类`: `TP035-036, TP039, TP044, TP046`
+- `工具`: `TP049, TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP040-041, TP054, TP061`
+
+这里只评估 PTOAS 对“固定 shape / 特定 shape 性能优化”的支撑能力。没有 benchmark baseline 或没有上板实测时，不要硬造性能结论。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`05` 场景通常至少需要：
+- `L1` 评文档、样例、入口
+- `L3` 评 compile-only 和工程编译
+- `L4` 才能评真实性能、精度一致性、性能提升
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能优化文档检索命中率 | 找到性能相关文档、样例、issue 模板所需轮次 | `README.md`, `docs/PTO_IR_manual.md`, `.github/ISSUE_TEMPLATE/performance_issue.yml`, `test/samples/FlashAttention/`, `GQA/`, `FFN/` | `L1-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 文档检索耗时 | 从开始检索到找到目标文档的时间 | 同上 | `L1-L4` | `<=2 分钟` 高分；`2-4` 次之；`4-6` 中；`6-8` 低；`>8` 最低 |
+
+## 易开发、易演进
+
+### 性能分析
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能数据采集耗时 | 获取 profile/日志/性能数据所需时间 | 用户 benchmark 脚本、sample、remote validation 日志 | `L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 性能报告完备度 | 报告是否包含关键指标、case、shape、参数、耗时 | `performance_issue.yml`、用户日志 | `L1`, `L4` | 数据完整齐全高分；`>=90%` 次之；`70%-89%` 中；`50%-69%` 低；`<50%` 最低 |
+
+### 优化实现
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 优化迭代次数 | 针对固定 shape 调整 pass / IR / sample 的迭代次数 | PR diff、真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 优化耗时 | 完成策略优化的总耗时 | 真实执行记录 | `L3-L4` | `<=30 分钟` 高分；`30-60` 次之；`60-120` 中；`120-180` 低；`>180` 最低 |
+| 优化成功率 | 优化任务成功率 | 真实执行记录 | `L3-L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 编译验证
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 编译报错排障效率 | 调优后重新编译 sample / validation 工程时，修复了几轮 | `cmake`, `ninja`, validation 日志 | `L3-L4` | 无报错高分；1 次修复次之；2-3 次中；4-5 次低；>5 次最低 |
+| 编译耗时 | 从开始编译到编译完成的总时间 | 同上 | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 编译成功率 | 最终编译是否成功 | 同上 | `L3-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 性能调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能提升达成率 | 达到预期性能提升目标的任务比例 | baseline + 实测性能日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 性能提升幅度 | 优化后相对 baseline 的提升幅度 | 同上 | `L4` | 提升 `>=50%` 高分；`30%-50%` 次之；`10%-30%` 中；`0%-10%` 低；无提升或劣化最低 |
+| 对标友商差距 | 优化后性能与友商的差距 | 用户提供对标数据 | `L4` | 超越高分；持平次之；差距 `<20%` 中；`20%-50%` 低；`>50%` 最低 |
+
+说明：`对标友商差距` 没有外部 benchmark 时直接记 `N/A`，因为它超出 PTOAS 仓库单独可证的边界。
+
+### 精度调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 精度验证工具获取耗时 | 获取 golden/compare/验证工具所需时间 | sample `golden.py`, `compare.py`, `generate_testcase.py` | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 精度验证运行成功次数 | 直到精度验证成功所需的尝试次数 | 真实执行记录 | `L3-L4` | 首次成功 `10`；2-3 次 `8`；4-5 次 `6`；6-7 次 `4`；>7 次或无法成功 `2` |
+| 精度一致性验证 | 优化后精度与优化前的一致性 | compare 结果、误差阈值 | `L4` | `100% 一致` 高分；误差 `<1e-5` 次之；`<1e-3` 中；`<1e-1` 低；明显差异最低 |
+| 用例回归通过率 | 原功能精度用例回归通过率 | 回归日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 默认样例
+
+优先选择：
+- `test/samples/FlashAttention/`
+- `test/samples/GQA/`
+- `test/samples/FFN/`
+- `test/samples/MatMul/`
diff --git a/.codex/skills/ptoas-usability-eval/references/metrics-06.md b/.codex/skills/ptoas-usability-eval/references/metrics-06.md
new file mode 100644
index 000000000..1e44532c0
--- /dev/null
+++ b/.codex/skills/ptoas-usability-eval/references/metrics-06.md
@@ -0,0 +1,84 @@
+# `06 泛化 shape 性能优化` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP017`
+- `API / 接口`: `TP019-020`
+- `源码 & 示例类`: `TP035-036, TP039, TP044, TP046-047`
+- `工具`: `TP049, TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP040-041, TP054, TP061`
+
+这里只评估 PTOAS 对“多 shape / dynamic shape / valid-shape 场景”的性能优化支撑能力。没有多 shape 基线矩阵时，不要硬造平均/最大收益。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`06` 场景通常至少需要：
+- `L1` 评文档、IR 语义、样例覆盖度
+- `L3` 评 compile-only、编译验证
+- `L4` 才能评多 shape 真实性能与精度结果
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能优化文档检索命中率 | 找到 dynamic/valid-shape、layout、性能相关文档和样例所需轮次 | `docs/PTO_IR_manual.md`, `README.md`, `test/samples/SetValidShape/`, `LayoutInference/`, `Partition5D/`, `planmemory/` | `L1-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 文档检索耗时 | 从开始检索到找到目标文档的时间 | 同上 | `L1-L4` | `<=2 分钟` 高分；`2-4` 次之；`4-6` 中；`6-8` 低；`>8` 最低 |
+
+## 易开发、易演进
+
+### 性能分析
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能数据采集耗时 | 获取多 shape profile/性能数据所需时间 | 用户 benchmark 脚本、validation 日志 | `L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 性能报告完备度 | 报告是否包含 shape 集合、关键指标、参数、耗时 | 用户日志、`performance_issue.yml` | `L1`, `L4` | 数据完整齐全高分；`>=90%` 次之；`70%-89%` 中；`50%-69%` 低；`<50%` 最低 |
+
+### 优化实现
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 平均优化迭代次数 | 多 shape 场景平均调整次数 | 真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 平均优化耗时 | 多 shape 场景平均完成策略优化的耗时 | 真实执行记录 | `L3-L4` | `<=30 分钟` 高分；`30-60` 次之；`60-120` 中；`120-180` 低；`>180` 最低 |
+| 优化成功率 | 多 shape 策略优化任务成功率 | 真实执行记录 | `L3-L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 编译验证
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 编译报错排障效率 | 多 shape 调优后重新编译 sample / validation 工程时，修复了几轮 | `cmake`, `ninja`, validation 日志 | `L3-L4` | 无报错高分；1 次修复次之；2-3 次中；4-5 次低；>5 次最低 |
+| 编译耗时 | 从开始编译到编译完成的总时间 | 同上 | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 编译成功率 | 最终编译是否成功 | 同上 | `L3-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 性能调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能提升达成率 | 达到预期性能提升目标的任务比例 | 多 shape baseline + 实测日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 平均性能提升幅度 | 多 shape 场景性能平均提升幅度 | 同上 | `L4` | 提升 `>=50%` 高分；`30%-50%` 次之；`10%-30%` 中；`0%-10%` 低；无提升或劣化最低 |
+| 最大性能提升幅度 | 提升最大的单个 shape 收益 | 同上 | `L4` | 提升 `>=60%` 高分；`40%-60%` 次之；`20%-40%` 中；`0%-20%` 低；无提升或劣化最低 |
+| 对标友商差距 | 优化后性能与友商的差距 | 用户提供对标数据 | `L4` | 超越高分；持平次之；差距 `<20%` 中；`20%-50%` 低；`>50%` 最低 |
+
+说明：`对标友商差距` 没有外部 benchmark 时直接记 `N/A`。
+
+### 精度调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 精度验证工具获取耗时 | 获取多 shape 精度验证工具所需时间 | `generate_testcase.py`, sample `golden.py`, `compare.py` | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 精度验证运行成功次数 | 直到精度验证成功所需的尝试次数 | 真实执行记录 | `L3-L4` | 首次成功 `10`；2-3 次 `8`；4-5 次 `6`；6-7 次 `4`；>7 次或无法成功 `2` |
+| 精度保持率 | 优化后精度与优化前的一致性 | compare 结果、误差阈值 | `L4` | `100% 一致` 高分；误差 `<1e-5` 次之；`<1e-3` 中；`<1e-1` 低；明显差异最低 |
+| 用例回归通过率 | 原功能精度用例回归通过率 | 回归日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 默认样例
+
+优先选择：
+- `test/samples/SetValidShape/`
+- `test/samples/LayoutInference/`
+- `test/samples/Partition5D/`
+- `test/samples/planmemory/`
+- 其他带 `valid_shape` / dynamic shape 的样例
diff --git a/.codex/skills/ptoas-usability-eval/references/scope.md b/.codex/skills/ptoas-usability-eval/references/scope.md
new file mode 100644
index 000000000..96e5cb004
--- /dev/null
+++ b/.codex/skills/ptoas-usability-eval/references/scope.md
@@ -0,0 +1,129 @@
+# PTOAS 评估范围映射
+
+## 六大场景映射
+
+| 场景 | 结论 | 处理方式 | PTOAS 中可量化的部分 | 默认不直接量化的部分 |
+| --- | --- | --- | --- | --- |
+| `01 算子复现部署` | 主评估场景 | 正常评分 | 构建、CLI、Python 绑定、sample、compile-only、board-validation | 无 |
+| `02 算子迁移部署` | 有限纳入 | 评“迁移支撑能力” | PTO IR 入口、样例/PyPTO 快照、compile-only/validation、迁移前后对照样例 | 业务框架集成、完整模型接线、仓外工程改造 |
+| `03 builtin 算子定制修改` | 默认不纳入 | 标 `N/A`，必要时只做差距说明 | 无固定模板 | builtin/业务算子定制主流程 |
+| `04 算子基本功能实现` | 次级支撑 | 只评 PTOAS 直接支撑的工程子链路 | 文档、样例、编译配置、工程编译、运行反馈、验证 | 完整需求分析、完整方案设计、通用算子研发全过程 |
+| `05 特定 shape 性能优化` | 条件纳入 | 评“特定 shape 性能优化支撑能力” | 性能文档、固定 shape 样例、性能数据获取入口、编译验证、精度/性能验证 | 没有 baseline 时的性能提升幅度、仓外友商对标 |
+| `06 泛化 shape 性能优化` | 条件纳入 | 评“多 shape / dynamic shape 支撑能力” | `valid_shape`/dynamic shape 文档、泛化样例、多 shape 验证链路 | 没有多 shape 基线矩阵时的平均/最大收益结论 |
+
+## 评估层级
+
+任何量化前都先声明层级：
+
+- `L1 文档审阅层`：只看仓库内容，不跑命令。
+- `L2 本地最小运行层`：当前机器已有 PTOAS 产物，可验证最小命令。
+- `L3 Linux compile-only 层`：Linux + CANN/bisheng + `PTO_ISA_ROOT`，不要求带卡。
+- `L4 NPU 上板层`：带卡 Linux、驱动、ACL、设备节点和用户权限齐全。
+
+评分规则：
+- 某层未覆盖，只能标 `未实测`。
+- 不得因为本机不是 Linux / 没有 `bisheng` / 没有 NPU 就对 PTOAS 本身扣分。
+- 文档是否清楚说明这些前置条件，才属于可评分项。
+
+## `02` 的适用边界
+
+PTOAS 可以支撑 `02`，但只能评“迁移支撑能力”，不能假装它已经覆盖完整业务迁移平台。
+
+可以评分的证据：
+- `docs/PTO_IR_manual.md`：IR 层级、tile/view/valid-shape 语义、Level-2/Level-3 入口
+- `test/samples/PyPTOIRParser/README.md`：来自 pypto `ir_parser` 的 vendored `.pto` 快照
+- `test/samples/*`：迁移后 PTO case、样例目录、`golden.py`/`compare.py`
+- `docs/no_npu_compile_only_guide_zh.md`、`runop.sh`、remote validation 脚本：迁移后 compile/validate 链路
+
+`02` 里这些指标只有在“有前后对照”时才能量化：
+- `tiling 迁移完备度`
+- `kernel 迁移完备度`
+- `tiling/kernel 代码修改率`
+- `功能失败率`
+- `性能劣化率`
+
+如果当前任务没有“迁移前/迁移后”对照 case：
+- 记 `未实测`，不要臆造百分比。
+- 若该项本质依赖仓外业务工程，且用户没有给材料，可记 `N/A` 并说明原因。
+
+## `04` 的适用边界
+
+`04` 只纳入这些与 PTOAS 仓库直接对应的子项：
+- 文档获取
+- 文档学习
+- 获取示例代码
+- 学习/理解示例代码
+- 运行示例代码
+- 编译配置
+- 算子工程编译
+- 功能调试
+- 精度调试中 repo 已有 compare/golden/validation 的部分
+
+默认排除：
+- 算子设计-需求分析
+- 算子设计-方案实现
+- 通用算子代码开发全过程
+- 脱离 PTOAS 仓库的业务工程联调
+
+## `05` 的适用边界
+
+PTOAS 可以支撑 `05`，但重点是“特定 shape 性能优化的仓内支撑能力”。
+
+可直接使用的仓内证据：
+- `docs/PTO_IR_manual.md`：Level-2/Level-3、layout、partition、reshape、valid-shape 等语义
+- `.github/ISSUE_TEMPLATE/performance_issue.yml`：性能问题收集模板
+- `test/samples/FlashAttention/`, `test/samples/GQA/`, `test/samples/FFN/`, `test/samples/MatMul/`：固定 shape 样例
+- `runop.sh`、compile-only 文档、remote validation 脚本：生成、编译、上板验证链路
+
+`05` 里这些项通常至少要到 `L4` 才能量化：
+- 性能数据采集耗时
+- 性能报告完备度
+- 优化迭代次数/耗时/成功率
+- 性能提升幅度
+- 精度一致性验证
+
+如果只有文档和样例，没有真实 benchmark/baseline：
+- 文档和入口可评分
+- 真实性能数字、友商对标、提升幅度一律 `未实测` 或 `N/A`
+
+## `06` 的适用边界
+
+PTOAS 可以支撑 `06`，但重点是“多 shape / dynamic shape / valid-shape 的泛化支撑能力”。
+
+可直接使用的仓内证据：
+- `docs/PTO_IR_manual.md`
+- `test/samples/SetValidShape/`
+- `test/samples/LayoutInference/`
+- `test/samples/Partition5D/`
+- `test/samples/planmemory/`
+- 其他带动态 shape / layout / partition / subview / reshape 的样例
+
+`06` 里这些项没有多 shape 基线矩阵时不能硬算：
+- 平均优化迭代次数
+- 平均优化耗时
+- 平均性能提升幅度
+- 最大性能提升幅度
+- 多 shape 精度保持率
+
+如果当前任务只看到 IR 设计与样例，没有多 shape 实测：
+- 文档、样例覆盖度可评分
+- 多 shape 性能/精度结果记 `未实测`
+
+## `未实测` 与 `N/A` 的使用规则
+
+记 `未实测`：
+- 仓库里有入口，但当前会话没有进入对应层级
+- 缺 Linux/CANN/NPU/baseline，导致只能停在文档或最小运行层
+- 缺迁移前后对照物，无法给出完成度/收益率
+
+记 `N/A`：
+- 指标本身超出 PTOAS 仓库边界
+- 用户要求的是仓外业务工程能力，当前仓库没有独立证据链
+- 友商对标、完整业务迁移、完整 builtin 定制等不是本 Skill 的默认量化对象
+
+## 使用原则
+
+- 如果用户没有特别说明，直接按 `01` 做主评估。
+- 如果用户要求顺带看 `02/04/05/06`，按本文件的边界补相应子集。
+- 可以做“支持度评分”，但不要把仓内文档/样例的存在，夸大成业务侧已经打通。
+- 能量化就量化；不能量化就明确说明为什么是 `未实测` 或 `N/A`。
diff --git a/.codex/skills/ptoas-usability-eval/references/scoring.md b/.codex/skills/ptoas-usability-eval/references/scoring.md
new file mode 100644
index 000000000..ba3d01d6d
--- /dev/null
+++ b/.codex/skills/ptoas-usability-eval/references/scoring.md
@@ -0,0 +1,148 @@
+# 总分汇总规则
+
+本文件定义 PTOAS 易用性评估的总分汇总方法，解决两个问题：
+- 单项指标混用 `10 分制` 和 `100 分制`
+- `未实测` / `N/A` 不能被误当成低分
+
+## 1. 基本原则
+
+- 单项展示时，保留用户原始分制。
+- 汇总总分时，再做统一归一化。
+- 场景分只基于本次选中的 `Core/Conditional Touch-Points` 或其 repo 级代理指标计算。
+- 默认输出两个总分：
+  - `总分（支撑）`
+  - `总分（实测）`
+
+## 2. 单项归一化
+
+把单项分数统一换算到 `100` 分制：
+
+- 原始 `10` 分制：`归一化分 = 原始分 * 10`
+- 原始 `100` 分制：`归一化分 = 原始分`
+
+示例：
+- `8/10 -> 80/100`
+- `60/100 -> 60/100`
+
+## 3. 特殊值处理
+
+- `未实测`：不计入任何总分分母
+- `N/A`：不计入任何总分分母
+- 如果某个场景下所有指标都是 `未实测/N/A`：
+  - 该场景分不输出数值
+  - 标记为 `本次无实测样本`
+
+## 4. 场景分
+
+先算场景分，再算总分。
+
+### 4.1 场景支撑分
+
+定义：该场景下所有“已评分”的指标，归一化后求平均。
+
+纳入范围：
+- 文档
+- 样例
+- 脚本
+- 配置
+- 已实测项
+
+排除范围：
+- `未实测`
+- `N/A`
+
+用途：衡量 PTOAS 仓库本身提供的支撑能力。
+
+### 4.2 场景实测分
+
+定义：该场景下所有“有真实执行证据”的指标，归一化后求平均。
+
+必须满足至少一种证据：
+- 真实命令执行
+- 真实编译/build
+- 真实 sample 运行
+- 真实 validation / compare / board 结果
+
+不纳入：
+- 纯文档发现性分
+- 纯 README/脚本存在性分
+- `未实测`
+- `N/A`
+
+用途：衡量当前会话里真正被跑通或被验证到的易用性。
+
+## 5. 默认场景权重
+
+如果用户没有单独指定权重，默认用：
+
+- `01`：`40%`
+- `02`：`15%`
+- `04`：`15%`
+- `05`：`15%`
+- `06`：`15%`
+
+说明：
+- `01` 是 PTOAS 的主评估场景，所以权重最高。
+- `02/04/05/06` 是补充场景，默认均分剩余权重。
+
+## 6. 权重重分配
+
+不要把没有参与本次评估的场景硬算进总分。
+
+### 6.1 用户只评部分场景
+
+如果本次只评了部分场景，例如只评 `01 + 04`：
+- 先取这两个场景的默认权重 `40` 和 `15`
+- 再重分配到 `100%`
+
+例：
+- `01` 新权重 = `40 / (40+15) = 72.73%`
+- `04` 新权重 = `15 / (40+15) = 27.27%`
+
+### 6.2 计算 `总分（支撑）`
+
+- 只保留“有场景支撑分”的场景
+- 对这些场景的默认权重重分配后加权平均
+
+### 6.3 计算 `总分（实测）`
+
+- 只保留“有场景实测分”的场景
+- 对这些场景的默认权重重分配后加权平均
+
+## 7. 输出要求
+
+建议固定输出以下内容：
+
+- `总分（支撑）`：`xx/100`
+- `总分（实测）`：`xx/100` 或 `本次无法计算`
+- `覆盖场景`：本次实际评了哪些场景
+- `覆盖层级`：`L1/L2/L3/L4` 到了哪一层
+- `实测覆盖说明`：哪些场景只有文档分，哪些场景有真实执行分
+
+## 8. 解释口径
+
+当两个总分差异较大时，优先按下面口径解释：
+
+- `总分（支撑）` 高、`总分（实测）` 低：
+  - 仓库文档/样例/脚本铺得比较全
+  - 但当前会话真实跑通度一般，或存在环境/样例摩擦
+
+- `总分（支撑）` 低、`总分（实测）` 高：
+  - 当前 case 可能能跑
+  - 但仓库的通用文档化、模板化、可发现性较弱
+
+- `总分（实测）` 显示为 `本次无法计算`：
+  - 说明本次基本停留在 `L1`，或者只有文档审阅，没有足够的真实执行证据
+
+## 9. 推荐展示格式
+
+```text
+总分（支撑）: 78.5/100
+总分（实测）: 66.4/100
+覆盖场景: 01, 02, 04, 05, 06
+覆盖层级: L1 + L2
+说明:
+- 01/04 同时形成支撑分和实测分
+- 02/05/06 当前主要形成文档/样例支撑分
+- L3/L4 未实测，不计入实测总分分母
+```
diff --git a/.codex/skills/ptoas-usability-eval/references/touchpoint-selection.md b/.codex/skills/ptoas-usability-eval/references/touchpoint-selection.md
new file mode 100644
index 000000000..d57a6d79e
--- /dev/null
+++ b/.codex/skills/ptoas-usability-eval/references/touchpoint-selection.md
@@ -0,0 +1,154 @@
+# PTOAS Touch-Point 选型
+
+本文件把用户提供的总触点池裁剪成适合 `hw-native-sys/PTOAS` 的 repo 级评估子集。
+
+## 1. 选型原则
+
+- PTOAS 是**编译器 / 工具链 / 样例仓库**，不是完整 CANN 产品矩阵，也不是官方镜像分发平台。
+- 默认优先评估这些触点：
+  - `资料/文档`
+  - `API/接口` 中与 `CLI / Python 绑定 / PTO IR 手册` 直接相关的子项
+  - `源码 & 示例类`
+  - `工具`
+  - `版本` 中 repo 内可自证的子项
+  - `运行反馈`
+- 对需要**产品级生态、仓外对标、跨硬件矩阵、发布渠道运营**的数据，默认不要硬打 repo 分，记 `N/A` 或只做差距说明。
+
+## 2. 默认纳入的 Core Touch-Points
+
+这些触点默认进入 PTOAS repo 级评分。
+
+### 2.1 资料/文档
+
+- `TP001` 检索命中成功率
+- `TP002` 文档跳转次数
+- `TP003` 多入口可达率
+- `TP004` 单次任务文档跳转浏览率
+- `TP005` 知识渐进式发布
+- `TP008` 文档结构风格一致率
+- `TP009` 概念跨文档冲突数
+- `TP011` 文档、版本时效一致性
+- `TP012` 内/外链有效率
+- `TP013` 文档错误点位密度
+- `TP016` 资料交付件完备率
+- `TP017` 文档场景/内容覆盖缺失率
+- `TP018` quick_start / sample 一次跑通率
+
+### 2.2 API / 接口
+
+这里只看 PTOAS repo 自己暴露的接口层：
+- `CLI`: `ptoas`, `ptobc`
+- `Python bindings`
+- `PTO IR` 公开手册/Op 语义
+
+默认纳入：
+- `TP019` 目标接口平均查找检索轮次
+- `TP020` 渐进式复杂披露覆盖度
+- `TP028` 平均入参数 / 参数复杂度
+- `TP032` 接口自解释读懂率
+
+### 2.3 源码 & 示例类
+
+- `TP034` 示例代码无修改一键编译运行成功率
+- `TP035` 示例检索命中成功率
+- `TP036` 样例覆盖度
+- `TP037` 最小功能实现 Demo 覆盖率
+- `TP038` 命令示例覆盖度
+- `TP039` API 调用样例覆盖率
+- `TP042` 样例代码编译语法错误检出率
+- `TP043` 样例使用废弃 / 过期 API 占比
+- `TP044` 业务代码直接复用改编比例
+- `TP045` 编程模型标准对齐率
+- `TP046` 关键链路显性化率
+- `TP047` 认知理解步数
+
+### 2.4 工具
+
+- `TP049` 首次安装部署一次性成功率
+- `TP051` 标准任务平均操作步骤数
+- `TP052` 功能 / 场景覆盖率
+
+### 2.5 版本
+
+只纳入 repo 内可通过 `README / CI / tag / branch / issue template` 自证的部分：
+- `TP053` 版本检索命中成功率
+- `TP058` 版本配套关系准确性
+
+### 2.6 运行反馈
+
+- `TP062` 报错携带环境 / 版本 / 上下文信息完整率
+- `TP063` 报错自带排障建议比例
+- `TP064` 无效冗余信息占比
+
+## 3. 条件纳入的 Conditional Touch-Points
+
+这些触点只有在用户明确要求，或者当前任务确实提供了对应证据时才纳入。
+
+### 3.1 文档 / API 条件项
+
+- `TP006` FAQ 命中率
+- `TP010` 接口文档模板一致率
+- `TP014` API 文档覆盖率
+- `TP015` 错误码文档化率
+- `TP033` N+2 小版本破坏性接口变更频次
+
+### 3.2 示例 / 性能高级项
+
+- `TP040` E2E 实战案例覆盖率
+- `TP041` 行业深度调优案例覆盖率
+
+### 3.3 版本 / 部署高级项
+
+- `TP054` 版本信息完备率
+- `TP057` 版本号规范准确率
+- `TP059` 版本部署命令数
+- `TP060` 开箱部署成功率
+- `TP061` 版本兼容性率
+
+说明：
+- `TP061` 在 PTOAS 里通常要到 `L4`，并且需要 A3/A5/不同硬件的实测证据。
+- `TP040/TP041` 在 PTOAS 里只有当 `FlashAttention/GQA/FFN` 这类样例被当作准业务案例使用时才适合纳入。
+
+## 4. 默认排除的 Excluded Touch-Points
+
+这些触点默认**不进入** PTOAS repo 级总分，除非用户明确要求做生态级差距研究。
+
+### 4.1 产品生态 / 友商对标类
+
+- `TP021` API 业务场景覆盖率
+- `TP022` 主流 AI 应用框架 API 支持覆盖率
+- `TP023` 主流 AI 框架 API 支持覆盖率
+- `TP024` API 主流生态调用一致性
+- `TP025` 原子 API 与标杆 API 数量对比一致性
+- `TP026` 迁移修改代码（CUDA -> AscendC）
+- `TP027` 原子 API 与标杆 API 行为对比一致性
+
+原因：这些指标要求的是**全产品生态**、**仓外框架集成**、**与 CUDA/CANN 大盘对比**，不是 PTOAS 仓库单独可证的事实。
+
+### 4.2 不适合 PTOAS repo 形态的项
+
+- `TP029` 错误返回一致率
+- `TP030` 最小可用代码行数
+- `TP055` 主流镜像仓支持下载覆盖度
+- `TP056` 典型部署模式支持覆盖度
+
+原因：
+- PTOAS 不是以统一 runtime C API 为主的库产品，`TP029/TP030` 不适合直接套。
+- PTOAS repo 不是镜像/安装包分发平台，`TP055/TP056` 默认不打 repo 分。
+
+## 5. 场景到 Touch-Point 的默认映射
+
+| 场景 | 默认 Core Touch-Points | 条件 Touch-Points |
+| --- | --- | --- |
+| `01 算子复现部署` | `TP001-005, TP008-018, TP034-035, TP038, TP042, TP044, TP049, TP051-053, TP058, TP062-064` | `TP006, TP054, TP057, TP059-061` |
+| `02 算子迁移部署` | `TP001-005, TP008-009, TP011, TP013, TP017, TP019-020, TP032, TP035-037, TP039, TP044, TP046-047, TP051-052, TP062-064` | `TP040-041, TP033, TP061` |
+| `04 算子基本功能实现` | `TP001-005, TP008-009, TP011, TP013, TP017-020, TP028, TP032, TP034-039, TP042-047, TP049, TP051-052, TP062-064` | `TP006, TP010, TP014-015, TP033` |
+| `05 特定 shape 性能优化` | `TP001-005, TP017, TP019-020, TP035-036, TP039, TP044, TP046, TP049, TP051-052, TP062-064` | `TP040-041, TP054, TP061` |
+| `06 泛化 shape 性能优化` | `TP001-005, TP017, TP019-020, TP035-036, TP039, TP044, TP046-047, TP049, TP051-052, TP062-064` | `TP040-041, TP054, TP061` |
+
+## 6. 使用要求
+
+- 每次正式评估前，先在输出里给出 `触点选择`。
+- 默认只打 `Core Touch-Points`。
+- `Conditional Touch-Points` 只有在证据存在时才纳入，并明确说明为什么本次纳入。
+- `Excluded Touch-Points` 不进入总分；如果用户追问，可以单独给差距分析，但不要混入 repo 级总分。
diff --git a/.cursor/skills/ptoas-usability-eval/README.md b/.cursor/skills/ptoas-usability-eval/README.md
new file mode 100644
index 000000000..3f8fd8545
--- /dev/null
+++ b/.cursor/skills/ptoas-usability-eval/README.md
@@ -0,0 +1,33 @@
+# PTOAS Usability Eval Skill
+
+这是 PTOAS 仓库内的通用 Skill 源目录。
+
+支持的客户端入口：
+- Codex: `.codex/skills/ptoas-usability-eval/`
+- Cursor: `.cursor/skills/ptoas-usability-eval/`
+- Trae: `.trae/skills/ptoas-usability-eval/`
+- Claude Code: `.claude/skills/ptoas-usability-eval/`
+
+当前覆盖的评估场景：
+- `01 算子复现部署`
+- `02 算子迁移部署` 的 PTOAS 支撑子集
+- `04 算子基本功能实现` 的 PTOAS 工程子集
+- `05 特定 shape 性能优化` 的 PTOAS 支撑子集
+- `06 泛化 shape 性能优化` 的 PTOAS 支撑子集
+
+当前附带的汇总规则：
+- 原始指标保留 `10 分制 / 100 分制`
+- 汇总时统一归一到 `100` 分制
+- 默认输出 `总分（支撑）` 和 `总分（实测）`
+- `未实测/N/A` 不进入总分分母
+
+当前评估逻辑：
+- 先按 `touch-point` 体系选取适用于 PTOAS 的触点
+- 再按 `01/02/04/05/06` 场景评分
+- 默认只把适用的 `Core Touch-Points` 放进 repo 级总分
+
+约定：
+- `skills/ptoas-usability-eval/` 作为仓库内的通用主副本
+- 各客户端目录提供可直接发现的副本，便于不同工具开箱即用
+- 修改 Skill 内容时，应同步更新上述四个客户端目录
+- 对 `L3/L4` 依赖 Linux/CANN/NPU 的指标，未实测时必须标 `未实测`，不能因为当前机器缺环境直接给 PTOAS 低分
diff --git a/.cursor/skills/ptoas-usability-eval/SKILL.md b/.cursor/skills/ptoas-usability-eval/SKILL.md
new file mode 100644
index 000000000..24cc41525
--- /dev/null
+++ b/.cursor/skills/ptoas-usability-eval/SKILL.md
@@ -0,0 +1,98 @@
+---
+name: ptoas-usability-eval
+description: Evaluate PTOAS repository usability across scene 01 as the primary template plus the PTOAS-supported subsets of scenes 02, 04, 05, and 06. Always classify the evaluation by environment layer first, use only repo-native docs/scripts/samples/CI as primary evidence, keep the user's mixed 10-point and 100-point scoring rules, compute normalized support and measured totals, and mark unsupported or untested dimensions as 未实测 or N/A.
+---
+
+# PTOAS Usability Eval
+
+当用户要评估 `hw-native-sys/PTOAS` 的易用性，或要按 `01/02/04/05/06` 给 PTOAS 打分时，使用这个 Skill。
+
+## 默认范围
+
+- `01 算子复现部署`：主评估场景，正常评分。
+- `02 算子迁移部署`：纳入，但只评 PTOAS 仓库能直接支撑的迁移入口、样例、IR/脚本、编译验证链路。
+- `04 算子基本功能实现`：纳入，但只评 PTOAS 直接覆盖的示例、编译、验证、反馈子链路。
+- `05 特定 shape 性能优化`：纳入，但只评 PTOAS 的文档、样例、性能数据获取入口、编译验证、精度/性能验证支撑能力。
+- `06 泛化 shape 性能优化`：纳入，但只评 PTOAS 的 dynamic/valid-shape、多 shape 样例与验证支撑能力。
+- `03 builtin 算子定制修改`：默认不纳入量化，标 `N/A`；必要时只做差距说明。
+
+先读 [references/touchpoint-selection.md](references/touchpoint-selection.md) 选定适用触点，再读 [references/scope.md](references/scope.md) 确认各场景的边界和 `未实测/N/A` 规则。
+
+## 先判层级
+
+开始评分前，必须先声明本次评估覆盖到哪一层。没有层级，不能直接混着打分。
+
+可选层级：
+- `L1 文档审阅层`：只看仓库文档、脚本、样例、CI，不做运行。
+- `L2 本地最小运行层`：当前机器已有 `ptoas` / `ptobc` / Python 绑定，可做最小命令验证。
+- `L3 Linux compile-only 层`：需要 Linux + CANN/bisheng + `PTO_ISA_ROOT`，不要求带卡。
+- `L4 NPU 上板层`：需要带卡 Linux、驱动、权限、`/dev/davinci*` 与对应用户组。
+
+约束：
+- 没进入某层，就把该层指标记为 `未实测`，不能因为当前机器缺环境就给 PTOAS 低分。
+- `bisheng` / CANN compile-only 一般属于 `L3`，不应在本地 Mac 上硬打低分。
+- 带卡运行、设备权限、驱动、ACL、用户组属于 `L4`。
+
+## 证据来源
+
+优先只用仓库内证据，不把仓外经验当成主证据。固定入口见 [references/evidence-checklist.md](references/evidence-checklist.md)。
+
+高优先级证据：
+- `README.md`
+- `docs/no_npu_compile_only_guide_zh.md`
+- `docs/PTO_IR_manual.md`
+- `test/samples/runop.sh`
+- `test/npu_validation/scripts/generate_testcase.py`
+- `test/npu_validation/scripts/run_remote_npu_validation.sh`
+- `test/samples/PyPTOIRParser/README.md`
+- `test/samples/FlashAttention/`, `test/samples/GQA/`, `test/samples/FFN/`
+- `test/samples/SetValidShape/`, `test/samples/LayoutInference/`, `test/samples/Partition5D/`, `test/samples/planmemory/`
+- `.github/workflows/ci.yml`
+- `.github/ISSUE_TEMPLATE/performance_issue.yml`
+
+## 工作流
+
+1. 先判断用户要的是 `01`、`02`、`04`、`05`、`06` 中哪些场景；未说明时默认 `01`。
+2. 再判断本次覆盖层级：`L1/L2/L3/L4`。输出中必须显式写出来。
+3. 先读 [references/touchpoint-selection.md](references/touchpoint-selection.md)，按场景选定本次的 `Core / Conditional / Excluded` 触点。
+4. 从仓库内收集证据，记录每次检索轮次、文档跳转次数、执行命令、耗时、成功/失败结果。
+5. `01` 场景读 [references/metrics-01.md](references/metrics-01.md)。
+6. `02` 场景读 [references/metrics-02.md](references/metrics-02.md)。
+7. `04` 场景读 [references/metrics-04.md](references/metrics-04.md)。
+8. `05` 场景读 [references/metrics-05.md](references/metrics-05.md)。
+9. `06` 场景读 [references/metrics-06.md](references/metrics-06.md)。
+10. 需要汇总总分时，读 [references/scoring.md](references/scoring.md)。
+11. 对每个指标都输出：原始观测值、评分、证据路径、说明。没有实测的数据不要猜，记为 `未实测` 或 `N/A`。
+12. 明确区分：
+    - PTOAS 仓库已提供的能力
+    - 外部前置条件，例如 LLVM、CANN、`pto-isa`、NPU、驱动/权限、业务 baseline
+13. 若文档描述与实际运行冲突，以实际命令结果为准，并指出冲突位置。
+14. 默认给两个总分：`总分（支撑）` 和 `总分（实测）`。如果用户只要分项，不强制输出总分。
+
+## 计量规则
+
+- 保留用户原始口径，不强行覆盖各指标的原始分制。
+- 但做总分汇总时，必须按 [references/scoring.md](references/scoring.md) 做归一化。
+- `检索轮次`：每次新的定向搜索或定位尝试算 1 轮。
+- `文档跳转次数`：命中首个目标文档后，每跨一个文档/README/脚本入口算 1 次。
+- `耗时`：尽量记录真实墙钟时间；拿不到就写 `未实测`，不要臆测。
+- `成功率`：只基于当前任务里真实执行或真实定位到的结果计算。
+- `未实测`：当前会话未覆盖到对应环境层级，或该层级前置条件不存在，或缺少前后对照 baseline。
+- `N/A`：只用于超出 PTOAS 能力边界，或当前任务明确不纳入本次评估范围的项。
+
+## 输出格式
+
+按下面顺序输出：
+
+1. `评估范围`
+2. `触点选择`
+3. `评估层级`
+4. `总分（支撑）`
+5. `总分（实测）`
+6. `分场景评分`
+7. `覆盖说明`
+8. `关键证据`
+9. `主要短板`
+10. `建议动作`
+
+如果用户只要简版结论，也要至少保留：场景归类、评估层级、总评、最低分项、证据路径。
diff --git a/.cursor/skills/ptoas-usability-eval/agents/openai.yaml b/.cursor/skills/ptoas-usability-eval/agents/openai.yaml
new file mode 100644
index 000000000..924e59e3f
--- /dev/null
+++ b/.cursor/skills/ptoas-usability-eval/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "PTOAS Usability Eval"
+  short_description: "评估 PTOAS 在 01/02/04/05/06 场景下的易用性"
+  default_prompt: "Use $ptoas-usability-eval to evaluate this PTOAS repo for scene 01 operator reproduction/deployment and the PTOAS-supported subsets of scenes 02, 04, 05, and 06."
diff --git a/.cursor/skills/ptoas-usability-eval/references/evidence-checklist.md b/.cursor/skills/ptoas-usability-eval/references/evidence-checklist.md
new file mode 100644
index 000000000..89b6f1987
--- /dev/null
+++ b/.cursor/skills/ptoas-usability-eval/references/evidence-checklist.md
@@ -0,0 +1,86 @@
+# 证据清单
+
+## 固定证据入口
+
+| 路径 | 主要用途 | 对应场景 | 层级 | 主要触点 |
+| --- | --- | --- | --- | --- |
+| `README.md` | 官方构建、环境变量、CLI、Python 绑定、sample 运行、compile-only/上板验证主入口 | `01`, `02`, `04`, `05`, `06` | `L1-L4` | `TP001-005, TP016-020, TP038, TP049, TP053, TP058` |
+| `docs/no_npu_compile_only_guide_zh.md` | 无卡 compile-only 流程、批量验证流程、`pto-isa`/CANN 依赖说明 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3` | `TP005, TP017-018, TP049, TP051-052, TP058-060, TP062-064` |
+| `docs/PTO_IR_manual.md` | IR 层级、tile/view/valid-shape、layout、dynamic shape、Level-2/3 语义 | `02`, `04`, `05`, `06` | `L1-L4` | `TP019-020, TP028, TP032, TP039, TP045-047` |
+| `test/samples/runop.sh` | 批量样例生成、`ptoas`/`ptobc` 运行、A3/A5 默认参数策略 | `01`, `02`, `04`, `05`, `06` | `L1-L4` | `TP018, TP034-039, TP049, TP051-052, TP062-064` |
+| `test/npu_validation/scripts/generate_testcase.py` | 从 `*-pto.cpp` 生成验证工程，观察 golden/compare/兼容层处理 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3`, `L4` | `TP037-039, TP045-047, TP049, TP052` |
+| `test/npu_validation/scripts/run_remote_npu_validation.sh` | compile-only / sim / npu 运行链路、日志格式、设备与 `pto-isa` 检查 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3`, `L4` | `TP049, TP051-052, TP058-060, TP062-064` |
+| `test/samples/PyPTOIRParser/README.md` | 来自 pypto `ir_parser` 的 vendored `.pto` 快照说明 | `02` | `L1` | `TP035-037, TP039, TP044, TP046-047` |
+| `test/samples/MatMul/` | README 直接引用的基准样例，适合作为 `01` 默认复现模板 | `01`, `04`, `05` | `L1-L4` | `TP018, TP034-039, TP042-047` |
+| `test/samples/FlashAttention/` | 特定 shape 性能样例 | `05` | `L1-L4` | `TP035-041, TP044, TP046` |
+| `test/samples/GQA/` | 特定 shape / attention 相关样例 | `05` | `L1-L4` | `TP035-041, TP044, TP046` |
+| `test/samples/FFN/` | 特定 shape / 算子组合样例 | `05` | `L1-L4` | `TP035-041, TP044, TP046` |
+| `test/samples/SetValidShape/` | dynamic/valid-shape 相关样例 | `06` | `L1-L4` | `TP035-039, TP044, TP046-047` |
+| `test/samples/LayoutInference/` | layout 推断相关样例 | `06` | `L1-L4` | `TP019-020, TP035-039, TP046-047` |
+| `test/samples/Partition5D/` | 多维 partition / shape 泛化相关样例 | `02`, `06` | `L1-L4` | `TP035-039, TP044, TP046-047, TP061` |
+| `test/samples/planmemory/` | alias/planmemory/shape 相关样例 | `06` | `L1-L4` | `TP035-039, TP044, TP046-047` |
+| `.github/workflows/ci.yml` | CI 中的 LLVM/PTOAS 构建、lit、sample test、remote validation 参考配置 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3`, `L4` | `TP003, TP011, TP049, TP052-053, TP058, TP060-064` |
+| `.github/ISSUE_TEMPLATE/performance_issue.yml` | 性能问题受理模板，可用来评估性能数据/复现要求的完备性 | `05`, `06` | `L1` | `TP005, TP017, TP040-041, TP062-063` |
+
+说明：
+- 不要把当前分支不存在的样例 README 当成固定证据源。
+- 对 `02/05/06`，没有“前后对照基线”时，不要硬算迁移完备度或性能提升幅度。
+
+## 推荐检索顺序
+
+1. `README.md`
+2. `docs/no_npu_compile_only_guide_zh.md`
+3. `docs/PTO_IR_manual.md`
+4. `test/samples/MatMul/` 或用户指定样例目录
+5. `test/samples/PyPTOIRParser/`, `FlashAttention/`, `GQA/`, `FFN/`, `SetValidShape/`, `LayoutInference/`, `Partition5D/`, `planmemory/`
+6. `test/samples/runop.sh`
+7. `test/npu_validation/scripts/*.py` / `*.sh`
+8. `.github/workflows/ci.yml`
+9. `.github/ISSUE_TEMPLATE/performance_issue.yml`
+
+## 推荐检索命令
+
+```bash
+rg -n "构建|运行测试|compile-only|runop|generate_testcase|run_remote_npu_validation|level3" README.md docs test .github
+rg -n "valid_shape|layout|partition|reshape|dynamic shape|Level-2|Level-3" docs/PTO_IR_manual.md docs test
+rg -n "FlashAttention|GQA|FFN|MatMul|SetValidShape|LayoutInference|Partition5D|planmemory" test .github
+rg --files test/samples
+find test/samples -maxdepth 2 -type f \( -name '*.py' -o -name '*.pto' -o -name 'README.md' \)
+```
+
+## 迁移 / 性能场景的补充记录项
+
+如果在评 `02/05/06`，额外记录：
+- 是否存在迁移前/迁移后对照物
+- 是否存在性能 baseline
+- baseline 来源路径
+- 是否需要 NPU 实机
+- 当前停在哪一层
+- 哪些分数是实测，哪些是文档侧支撑分
+
+## 记录要求
+
+每个评分项至少要落这些证据字段：
+
+- `证据路径`
+- `检索/执行命令`
+- `检索轮次`
+- `文档跳转次数`
+- `评估层级`
+- `耗时`
+- `结果`
+- `评分`
+- `备注`
+
+## 默认样例
+
+若用户没有指定具体算子或样例，优先使用：
+
+- `test/samples/MatMul/tmatmulk.py`
+- `test/samples/MatMul/tmatmulk.pto`
+- `test/samples/Addc/addc.py`
+- `test/samples/PyPTOIRParser/`
+- `test/samples/FlashAttention/`
+- `test/samples/SetValidShape/`
+
+理由：这些路径要么被 `README.md` 直接引用，要么与迁移/性能/shape 泛化评估强相关，且当前主线可稳定找到。
diff --git a/.cursor/skills/ptoas-usability-eval/references/metrics-01.md b/.cursor/skills/ptoas-usability-eval/references/metrics-01.md
new file mode 100644
index 000000000..58bcc109d
--- /dev/null
+++ b/.cursor/skills/ptoas-usability-eval/references/metrics-01.md
@@ -0,0 +1,119 @@
+# `01 算子复现部署` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP008-018`
+- `源码 & 示例类`: `TP034-035, TP038, TP042, TP044`
+- `工具`: `TP049, TP051-052`
+- `版本`: `TP053, TP058`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP006, TP054, TP057, TP059-061`
+
+默认把 PTOAS 看作“从样例或 `.pto` 输入出发，完成构建、编译、compile-only 或上板验证”的工具链仓库。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+在 `01` 场景里，必须先声明本次评估覆盖的层级：
+
+- `L1 文档审阅层`
+- `L2 本地最小运行层`
+- `L3 Linux compile-only 层`
+- `L4 NPU 上板层`
+
+没有进入对应层，就标 `未实测`，不要把环境缺失当成 PTOAS 负分。
+
+## 默认任务模板
+
+若用户没有指定具体 case，优先用 `test/samples/MatMul/` 作为复现模板：
+
+```bash
+python3 test/samples/MatMul/tmatmulk.py > /tmp/tmatmulk.pto
+./build/tools/ptoas/ptoas /tmp/tmatmulk.pto -o /tmp/tmatmulk.cpp
+```
+
+需要无卡 compile-only 时，继续参考：
+
+```bash
+python3 test/npu_validation/scripts/generate_testcase.py \
+  --input /tmp/tmatmulk.cpp \
+  --run-mode npu \
+  --soc-version Ascend910
+```
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 检索命中成功率 | 统计找到“构建 + sample 运行 + compile-only/上板验证”入口所需检索轮次 | `README.md`, `docs/no_npu_compile_only_guide_zh.md` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+| 文档检索耗时 | 从开始找文档到定位到正确路径的时间 | 同上 | `L1-L4` | `2 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 文档获取成功率 | 目标文档是否都能在仓库内找到 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+### 文档学习
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 文档错误点位密度 | 按文档执行时，检查命令、路径、版本、链接、说明是否错误 | `README.md`, `docs/no_npu_compile_only_guide_zh.md`, `.github/workflows/ci.yml` | `L1-L4` | 零错误 `100`；少量小错 `80`；一般错误 `60`；明显错误 `40`；严重不可用 `20` |
+| 文档跳转次数 | 从首个命中文档到凑齐完整执行路径，跨文档跳转的次数 | `README.md -> docs/... -> test/samples/...` | `L1-L4` | 1 次 `100`；2 次 `80`；3 次 `60`；4-5 次 `40`；>5 次 `20` |
+| 内容覆盖缺失率 | 是否清楚区分本地运行、Linux compile-only、带卡上板等层级前置条件 | `README.md`, `docs/...`, `.github/workflows/ci.yml` | `L1-L4` | 无缺失 `100`；`<=5%` `80`；`5%-15%` `60`；`15%-30%` `40`；`>30%` `20` |
+| 文档学习耗时 | 从开始读到能给出执行方案的时间 | 同上 | `L1-L4` | `5 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 通过文档学习检索成功率 | 需要通过文档解决的问题里，有多少真正被文档回答 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+## 易部署
+
+### 环境下载
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 环境获取场景覆盖率 | 看仓库是否说明源码构建、无卡 compile-only、上板验证所需环境 | `README.md`, `docs/no_npu_compile_only_guide_zh.md` | `L1-L4` | `100%=10`；`80%-99%=8`；`60%-79%=6`；`40%-59%=4`；`<40%=2` |
+| 环境下载耗时 | 真实下载 LLVM/CANN/Python 依赖/`pto-isa` 的时间 | 真实执行记录 | `L3-L4` | `<=5 分钟=10`；`5-7=8`；`7-9=6`；`9-11=4`；`>11=2` |
+| 环境下载成功率 | 下载步骤是否一次完成 | 真实执行记录 | `L3-L4` | `100%=10`，按比例计算 |
+
+说明：如果当前任务没有真的在 Linux/CANN 环境里下载依赖，后两项写 `未实测`。
+
+### 环境安装
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 软硬件配套兼容率 | 检查仓库是否明确 LLVM 版本、Python 包版本、CANN / `pto-isa` 依赖关系 | `README.md`, `docs/no_npu_compile_only_guide_zh.md`, `ci.yml` | `L1-L4` | `100%=10`；`80%-99%=8`；`60%-79%=6`；`40%-59%=4`；`<40%=2` |
+| 部署时长 | 从开始执行安装到可运行 `ptoas`/Python 绑定的时间 | 真实执行记录 | `L2-L4` | `<=5 分钟=10`；`5-7=8`；`7-9=6`；`9-11=4`；`>11=2` |
+| 操作步骤数 | 完成安装所需命令/步骤数量 | `README.md` 构建步骤 | `L1-L4` | `<=8 步=10`；`9-10=8`；`11-12=6`；`13-14=4`；`>14=2` |
+| 环境安装成功率 | 是否能完成 LLVM + PTOAS 构建与安装 | 真实执行记录 | `L2-L4` | `100%=10`，按比例计算 |
+
+### 环境校验
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 环境安装后校验成功率 | 是否有明确校验动作，例如 `ptoas --version`、Python import、sample compile | `README.md`, `ci.yml` | `L2-L4` | `100%=10`，按比例计算 |
+
+推荐最小校验命令：
+
+```bash
+./build/tools/ptoas/ptoas --version
+python3 -c "from mlir.dialects import pto; print('ok')"
+```
+
+## 易开发、易演进
+
+### 获取示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 检索命中成功率 | 统计定位到默认样例目录所需轮次 | `test/samples/MatMul/`, `test/samples/Addc/`, `README.md` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+
+### 运行示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 示例代码运行耗时 | 从运行 sample 到拿到 `.pto` / `.cpp` / compile-only 结果的时间 | `README.md`, `test/samples/MatMul/` | `L2-L4` | `<=2 分钟=10`；`2-4=8`；`4-6=6`；`6-8=4`；`>8=2` |
+| 示例代码运行成功率 | `py -> .pto -> .cpp` 或 compile-only / validation 是否成功 | 同上 | `L2-L4` | `100%=10`，按比例计算 |
+
+## 何时记 `未实测` / `N/A`
+
+- `未实测`：当前任务没有进入对应环境层级，例如在本地 Mac 上没有 Linux/CANN/bisheng，却要评价 compile-only。
+- `N/A`：该项超出 PTOAS 能力边界，或本次任务明确不纳入该项。
+
+不要把二者混用。
diff --git a/.cursor/skills/ptoas-usability-eval/references/metrics-02.md b/.cursor/skills/ptoas-usability-eval/references/metrics-02.md
new file mode 100644
index 000000000..8ad84dbf6
--- /dev/null
+++ b/.cursor/skills/ptoas-usability-eval/references/metrics-02.md
@@ -0,0 +1,77 @@
+# `02 算子迁移部署` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP008-009, TP011, TP013, TP017`
+- `API / 接口`: `TP019-020, TP032`
+- `源码 & 示例类`: `TP035-037, TP039, TP044, TP046-047`
+- `工具`: `TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP040-041, TP033, TP061`
+
+这里只评估 PTOAS 仓库对“迁移到 PTO IR / PTOAS 工具链”的支撑能力，不把 PTOAS 包装成完整业务算子迁移平台。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`02` 场景同样先声明层级：
+
+- `L1 文档审阅层`
+- `L2 本地最小运行层`
+- `L3 Linux compile-only 层`
+- `L4 NPU 上板层`
+
+没有进入对应层，就标 `未实测`。
+
+## 共享易学习项
+
+`02` 的 `文档获取` / `文档学习` 默认复用 [metrics-01.md](metrics-01.md) 中对应规则；只是目标从“复现部署”改成“找到迁移入口、IR 语义、样例和验证链路”。
+
+推荐优先证据：
+- `docs/PTO_IR_manual.md`
+- `test/samples/PyPTOIRParser/README.md`
+- `README.md`
+- `docs/no_npu_compile_only_guide_zh.md`
+
+## 易迁移
+
+### 算子迁移
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| tiling 迁移完备度 | 统计迁移前定义的 tiling 结构中，已成功落到 PTO IR / sample / generated testcase 的比例 | `docs/PTO_IR_manual.md`, `test/samples/*`, 用户提供的前后对照物 | `L1-L4` | `100%=10`；`80%=8`；`60%=6`；`40%=4`；`20%=2` |
+| kernel 迁移完备度 | 统计迁移前 kernel 逻辑中，已能由 PTO case / sample / generated testcase 覆盖的比例 | 同上 | `L1-L4` | `100%=10`；`80%=8`；`60%=6`；`40%=4`；`20%=2` |
+| 算子功能失败率 | 迁移后 compile-only / validation / board case 失败比例 | `runop.sh`, `generate_testcase.py`, `run_remote_npu_validation.sh` | `L3-L4` | `0% 失败=10`；`10%=8`；`20%=6`；`30%=4`；`40%=2` |
+| 算子性能劣化率 | 迁移后相对迁移前 baseline 的性能增幅 | 用户 baseline、`performance_issue.yml`、实测日志 | `L4` | 劣化 `<5%=10`；`10%=8`；`20%=6`；`30%=4`；`40%=2` |
+| tiling 代码修改率 | 迁移时 tiling 相关代码修改行数 / 总行数 | 用户对照 case、PR diff | `L1-L4` | `0%-5%` 高分；`5%-15%` 次高；`15%-25%` 中；`25%-35%` 低；`>35%` 最低 |
+| kernel 代码修改率 | 迁移时 kernel 相关代码修改行数 / 总行数 | 用户对照 case、PR diff | `L1-L4` | `0%-5%` 高分；`5%-15%` 次高；`15%-25%` 中；`25%-35%` 低；`>35%` 最低 |
+| 算子迁移总耗时 | 从开始迁移到迁移完成，不含最终验证环节 | 真实执行记录 | `L2-L4` | `<=10 分钟` 高分；`10-20` 次之；`20-30` 中；`30-60` 低；`>60` 最低 |
+| 算子迁移成功率 | 迁移任务成功率 | 真实执行记录 | `L2-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 在 PTOAS 中如何落地这些指标
+
+### 可直接量化的前提
+
+只有当前任务同时具备以下材料时，才量化迁移完备度/修改率/失败率：
+- 迁移前输入：上游 IR、旧 kernel、旧 tiling，至少一种
+- 迁移后输入：PTO `.pto`、sample、generated testcase，至少一种
+- 对应验证链路：compile-only 或 board validation
+
+### 没有对照物时怎么办
+
+- 只有仓库文档和样例，没有迁移前材料：
+  - 可以评“入口是否清晰”“样例/脚本是否齐全”
+  - 不能给出完备度/修改率/性能劣化率，记 `未实测`
+- 指标本身依赖仓外业务工程，且用户没给材料：
+  - 记 `N/A`
+
+## 推荐默认证据路径
+
+- `docs/PTO_IR_manual.md`
+- `test/samples/PyPTOIRParser/README.md`
+- `test/samples/*`
+- `docs/no_npu_compile_only_guide_zh.md`
+- `test/samples/runop.sh`
+- `test/npu_validation/scripts/generate_testcase.py`
+- `test/npu_validation/scripts/run_remote_npu_validation.sh`
diff --git a/.cursor/skills/ptoas-usability-eval/references/metrics-04.md b/.cursor/skills/ptoas-usability-eval/references/metrics-04.md
new file mode 100644
index 000000000..d347924a6
--- /dev/null
+++ b/.cursor/skills/ptoas-usability-eval/references/metrics-04.md
@@ -0,0 +1,116 @@
+# `04 算子基本功能实现` 的 PTOAS 子集指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP008-009, TP011, TP013, TP017-018`
+- `API / 接口`: `TP019-020, TP028, TP032`
+- `源码 & 示例类`: `TP034-039, TP042-047`
+- `工具`: `TP049, TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP006, TP010, TP014-015, TP033`
+
+这里只评估 PTOAS 真正覆盖到的“示例 / 编译 / 验证 / 反馈”链路，不把 PTOAS 当成完整算子研发平台。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`04` 子集同样先声明层级：
+
+- `L1 文档审阅层`
+- `L2 本地最小运行层`
+- `L3 Linux compile-only 层`
+- `L4 NPU 上板层`
+
+未进入对应层级，只能标 `未实测`。
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 检索命中成功率 | 找到目标样例、相关 CLI、验证脚本所需轮次 | `README.md`, `test/samples/`, `test/npu_validation/scripts/` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+| 文档检索耗时 | 从开始查到定位到目标入口的时间 | 同上 | `L1-L4` | `2 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 文档获取成功率 | 所需文档/脚本/样例是否都能在仓内找到 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+### 文档学习
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 文档错误点位密度 | 样例说明、命令、路径、环境前置条件是否准确 | `README.md`, sample README, `runop.sh`, `ci.yml` | `L1-L4` | 零错误 `100`；少量小错 `80`；一般错误 `60`；明显错误 `40`；严重不可用 `20` |
+| 文档跳转次数 | 为理解 sample 到 compile/validation 链路所需跳转次数 | 同上 | `L1-L4` | 1 次 `100`；2 次 `80`；3 次 `60`；4-5 次 `40`；>5 次 `20` |
+| 内容覆盖缺失率 | 样例定位、编译、验证、环境前置条件说明是否缺失 | 同上 | `L1-L4` | 无缺失 `100`；`<=5%` `80`；`5%-15%` `60`；`15%-30%` `40`；`>30%` `20` |
+| 文档学习耗时 | 从开始看文档到能解释执行路径的时间 | 同上 | `L1-L4` | `5 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 通过文档学习检索成功率 | 依赖文档回答的问题是否被解决 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+## 易开发、易演进
+
+### 获取示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 目标示例定位命中成功率 | 找到适合作为基本功能实现基线的 sample 或 `.pto` 所需轮次 | `test/samples/MatMul/`, `test/samples/Addc/`, `test/samples/PyPTOIRParser/` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+
+### 学习/理解示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 样例场景覆盖度 | 样例是否覆盖目标算子的输入、输出、golden/compare、compile/validation 场景 | 选定样例目录中的 `.py` / `.pto` / `npu_validation/` | `L1-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 样例学习分析 Token 数 | 优先使用平台可见的 AI token 统计；没有统计就写 `未量化` | 同上 | `L1-L4` | `<=500` 高分；`500-1000` 次高；`1000-2000` 中；`2000-3000` 低；`>3000` 最低 |
+| 示例理解耗时 | 从首次打开样例到能讲清输入、生成物、验证链路的时间 | 同上 | `L1-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-15` 中；`15-20` 低；`>20` 最低 |
+
+说明：如果运行环境拿不到 token 统计，第二项保留原值 `未量化`，不要编造 token 数。
+
+### 运行示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 运行成功率 | sample 首次执行是否能生成 `.pto` / `.cpp` / compile-only 验证工程 | `README.md`, `test/samples/runop.sh`, sample 目录 | `L2-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 示例代码运行耗时 | 从开始运行到 sample 结束的时间 | 同上 | `L2-L4` | `<=2 分钟` 高分；`2-4` 次之；`4-6` 中；`6-8` 低；`>8` 最低 |
+
+## 算子编译
+
+### 编译配置
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 新增/修改配置行数 | 按仓库已有说明运行 sample / validation 时，需要额外改多少配置行 | `README.md`, `docs/no_npu_compile_only_guide_zh.md`, `ci.yml` | `L1-L4` | `<5 行=100`；`<10=80`；`<15=60`；`<20=40`；`>20=20` |
+
+记录时只统计“文档外的额外修改”。按 README 就能跑通则记 `0` 行。
+
+### 算子工程编译
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 需要理解的宏/函数个数 | 为改通当前 sample / validation 链路，必须额外读懂多少宏/函数 | `runop.sh`, `generate_testcase.py`, `run_remote_npu_validation.sh`, sample CMake | `L1-L4` | `2 个=10`；`4 个=8`；`6 个=6`；`8 个=4`；`>10 个=2` |
+| 编译报错排障效率 | 从 sample / validation 工程编译到成功，中间修复了几轮 | `ninja`, `cmake --build`, validation 日志 | `L3-L4` | 无报错高分；1 次修复次之；2-3 次中；4-5 次低；>5 次最低 |
+| 编译耗时 | 开始编译到编译完成的总时间 | 同上 | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 编译成功率 | 最终编译是否成功，以及首次是否成功 | 同上 | `L3-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 功能调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 报错携带环境/版本/上下文信息完整率 | `ptoas` / validation 脚本报错时，是否包含 stage、case、路径、依赖、设备、soc/version 等信息 | `run_remote_npu_validation.sh`, sample/CI 日志 | `L2-L4` | 信息完整 `100`；`>=90%` `80`；`70%-89%` `60`；`50%-69%` `40`；`<50%` `20` |
+| 报错自带排障建议比例 | 报错是否已经给出下一步可排查方向 | 同上 | `L2-L4` | 全部带建议 `100`；`>=90%` `80`；`70%-89%` `60`；`50%-69%` `40`；`<50%` `20` |
+| 无效冗余信息占比 | 日志是否大量充斥与当前失败无关的信息 | 同上 | `L2-L4` | 无冗余 `100`；`<=5%` `80`；`5%-15%` `60`；`15%-30%` `40`；`>30%` `20` |
+| 功能调试耗时 | 从第一次失败到定位根因或跑通的时间 | 同上 | `L2-L4` | `<=10 分钟` 高分；`10-20` 次之；`20-30` 中；`30-60` 低；`>60` 最低 |
+| 功能调试成功率 | 当前目标问题是否最终解决 | 同上 | `L2-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 精度调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 精度数据获取耗时 | 获取 golden/output/compare 报告所需时间 | `generate_testcase.py`, sample `golden.py`, `compare.py` | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 定位分析次数 | 从发现精度问题到定位根因的迭代次数 | 真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 代码修改/迭代循环 | 精度修复迭代次数 | PR diff、真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+
+## 默认排除项
+
+这些在 PTOAS 仓库里默认不打分，直接标 `N/A`：
+
+- 算子设计-需求分析
+- 算子设计-方案实现
+- 通用算子代码开发全过程
+- 脱离 PTOAS 仓库的业务工程联调
diff --git a/.cursor/skills/ptoas-usability-eval/references/metrics-05.md b/.cursor/skills/ptoas-usability-eval/references/metrics-05.md
new file mode 100644
index 000000000..3b05aa815
--- /dev/null
+++ b/.cursor/skills/ptoas-usability-eval/references/metrics-05.md
@@ -0,0 +1,82 @@
+# `05 特定 shape 性能优化` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP017`
+- `API / 接口`: `TP019-020`
+- `源码 & 示例类`: `TP035-036, TP039, TP044, TP046`
+- `工具`: `TP049, TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP040-041, TP054, TP061`
+
+这里只评估 PTOAS 对“固定 shape / 特定 shape 性能优化”的支撑能力。没有 benchmark baseline 或没有上板实测时，不要硬造性能结论。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`05` 场景通常至少需要：
+- `L1` 评文档、样例、入口
+- `L3` 评 compile-only 和工程编译
+- `L4` 才能评真实性能、精度一致性、性能提升
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能优化文档检索命中率 | 找到性能相关文档、样例、issue 模板所需轮次 | `README.md`, `docs/PTO_IR_manual.md`, `.github/ISSUE_TEMPLATE/performance_issue.yml`, `test/samples/FlashAttention/`, `GQA/`, `FFN/` | `L1-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 文档检索耗时 | 从开始检索到找到目标文档的时间 | 同上 | `L1-L4` | `<=2 分钟` 高分；`2-4` 次之；`4-6` 中；`6-8` 低；`>8` 最低 |
+
+## 易开发、易演进
+
+### 性能分析
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能数据采集耗时 | 获取 profile/日志/性能数据所需时间 | 用户 benchmark 脚本、sample、remote validation 日志 | `L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 性能报告完备度 | 报告是否包含关键指标、case、shape、参数、耗时 | `performance_issue.yml`、用户日志 | `L1`, `L4` | 数据完整齐全高分；`>=90%` 次之；`70%-89%` 中；`50%-69%` 低；`<50%` 最低 |
+
+### 优化实现
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 优化迭代次数 | 针对固定 shape 调整 pass / IR / sample 的迭代次数 | PR diff、真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 优化耗时 | 完成策略优化的总耗时 | 真实执行记录 | `L3-L4` | `<=30 分钟` 高分；`30-60` 次之；`60-120` 中；`120-180` 低；`>180` 最低 |
+| 优化成功率 | 优化任务成功率 | 真实执行记录 | `L3-L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 编译验证
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 编译报错排障效率 | 调优后重新编译 sample / validation 工程时，修复了几轮 | `cmake`, `ninja`, validation 日志 | `L3-L4` | 无报错高分；1 次修复次之；2-3 次中；4-5 次低；>5 次最低 |
+| 编译耗时 | 从开始编译到编译完成的总时间 | 同上 | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 编译成功率 | 最终编译是否成功 | 同上 | `L3-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 性能调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能提升达成率 | 达到预期性能提升目标的任务比例 | baseline + 实测性能日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 性能提升幅度 | 优化后相对 baseline 的提升幅度 | 同上 | `L4` | 提升 `>=50%` 高分；`30%-50%` 次之；`10%-30%` 中；`0%-10%` 低；无提升或劣化最低 |
+| 对标友商差距 | 优化后性能与友商的差距 | 用户提供对标数据 | `L4` | 超越高分；持平次之；差距 `<20%` 中；`20%-50%` 低；`>50%` 最低 |
+
+说明：`对标友商差距` 没有外部 benchmark 时直接记 `N/A`，因为它超出 PTOAS 仓库单独可证的边界。
+
+### 精度调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 精度验证工具获取耗时 | 获取 golden/compare/验证工具所需时间 | sample `golden.py`, `compare.py`, `generate_testcase.py` | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 精度验证运行成功次数 | 直到精度验证成功所需的尝试次数 | 真实执行记录 | `L3-L4` | 首次成功 `10`；2-3 次 `8`；4-5 次 `6`；6-7 次 `4`；>7 次或无法成功 `2` |
+| 精度一致性验证 | 优化后精度与优化前的一致性 | compare 结果、误差阈值 | `L4` | `100% 一致` 高分；误差 `<1e-5` 次之；`<1e-3` 中；`<1e-1` 低；明显差异最低 |
+| 用例回归通过率 | 原功能精度用例回归通过率 | 回归日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 默认样例
+
+优先选择：
+- `test/samples/FlashAttention/`
+- `test/samples/GQA/`
+- `test/samples/FFN/`
+- `test/samples/MatMul/`
diff --git a/.cursor/skills/ptoas-usability-eval/references/metrics-06.md b/.cursor/skills/ptoas-usability-eval/references/metrics-06.md
new file mode 100644
index 000000000..1e44532c0
--- /dev/null
+++ b/.cursor/skills/ptoas-usability-eval/references/metrics-06.md
@@ -0,0 +1,84 @@
+# `06 泛化 shape 性能优化` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP017`
+- `API / 接口`: `TP019-020`
+- `源码 & 示例类`: `TP035-036, TP039, TP044, TP046-047`
+- `工具`: `TP049, TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP040-041, TP054, TP061`
+
+这里只评估 PTOAS 对“多 shape / dynamic shape / valid-shape 场景”的性能优化支撑能力。没有多 shape 基线矩阵时，不要硬造平均/最大收益。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`06` 场景通常至少需要：
+- `L1` 评文档、IR 语义、样例覆盖度
+- `L3` 评 compile-only、编译验证
+- `L4` 才能评多 shape 真实性能与精度结果
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能优化文档检索命中率 | 找到 dynamic/valid-shape、layout、性能相关文档和样例所需轮次 | `docs/PTO_IR_manual.md`, `README.md`, `test/samples/SetValidShape/`, `LayoutInference/`, `Partition5D/`, `planmemory/` | `L1-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 文档检索耗时 | 从开始检索到找到目标文档的时间 | 同上 | `L1-L4` | `<=2 分钟` 高分；`2-4` 次之；`4-6` 中；`6-8` 低；`>8` 最低 |
+
+## 易开发、易演进
+
+### 性能分析
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能数据采集耗时 | 获取多 shape profile/性能数据所需时间 | 用户 benchmark 脚本、validation 日志 | `L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 性能报告完备度 | 报告是否包含 shape 集合、关键指标、参数、耗时 | 用户日志、`performance_issue.yml` | `L1`, `L4` | 数据完整齐全高分；`>=90%` 次之；`70%-89%` 中；`50%-69%` 低；`<50%` 最低 |
+
+### 优化实现
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 平均优化迭代次数 | 多 shape 场景平均调整次数 | 真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 平均优化耗时 | 多 shape 场景平均完成策略优化的耗时 | 真实执行记录 | `L3-L4` | `<=30 分钟` 高分；`30-60` 次之；`60-120` 中；`120-180` 低；`>180` 最低 |
+| 优化成功率 | 多 shape 策略优化任务成功率 | 真实执行记录 | `L3-L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 编译验证
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 编译报错排障效率 | 多 shape 调优后重新编译 sample / validation 工程时，修复了几轮 | `cmake`, `ninja`, validation 日志 | `L3-L4` | 无报错高分；1 次修复次之；2-3 次中；4-5 次低；>5 次最低 |
+| 编译耗时 | 从开始编译到编译完成的总时间 | 同上 | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 编译成功率 | 最终编译是否成功 | 同上 | `L3-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 性能调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能提升达成率 | 达到预期性能提升目标的任务比例 | 多 shape baseline + 实测日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 平均性能提升幅度 | 多 shape 场景性能平均提升幅度 | 同上 | `L4` | 提升 `>=50%` 高分；`30%-50%` 次之；`10%-30%` 中；`0%-10%` 低；无提升或劣化最低 |
+| 最大性能提升幅度 | 提升最大的单个 shape 收益 | 同上 | `L4` | 提升 `>=60%` 高分；`40%-60%` 次之；`20%-40%` 中；`0%-20%` 低；无提升或劣化最低 |
+| 对标友商差距 | 优化后性能与友商的差距 | 用户提供对标数据 | `L4` | 超越高分；持平次之；差距 `<20%` 中；`20%-50%` 低；`>50%` 最低 |
+
+说明：`对标友商差距` 没有外部 benchmark 时直接记 `N/A`。
+
+### 精度调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 精度验证工具获取耗时 | 获取多 shape 精度验证工具所需时间 | `generate_testcase.py`, sample `golden.py`, `compare.py` | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 精度验证运行成功次数 | 直到精度验证成功所需的尝试次数 | 真实执行记录 | `L3-L4` | 首次成功 `10`；2-3 次 `8`；4-5 次 `6`；6-7 次 `4`；>7 次或无法成功 `2` |
+| 精度保持率 | 优化后精度与优化前的一致性 | compare 结果、误差阈值 | `L4` | `100% 一致` 高分；误差 `<1e-5` 次之；`<1e-3` 中；`<1e-1` 低；明显差异最低 |
+| 用例回归通过率 | 原功能精度用例回归通过率 | 回归日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 默认样例
+
+优先选择：
+- `test/samples/SetValidShape/`
+- `test/samples/LayoutInference/`
+- `test/samples/Partition5D/`
+- `test/samples/planmemory/`
+- 其他带 `valid_shape` / dynamic shape 的样例
diff --git a/.cursor/skills/ptoas-usability-eval/references/scope.md b/.cursor/skills/ptoas-usability-eval/references/scope.md
new file mode 100644
index 000000000..96e5cb004
--- /dev/null
+++ b/.cursor/skills/ptoas-usability-eval/references/scope.md
@@ -0,0 +1,129 @@
+# PTOAS 评估范围映射
+
+## 六大场景映射
+
+| 场景 | 结论 | 处理方式 | PTOAS 中可量化的部分 | 默认不直接量化的部分 |
+| --- | --- | --- | --- | --- |
+| `01 算子复现部署` | 主评估场景 | 正常评分 | 构建、CLI、Python 绑定、sample、compile-only、board-validation | 无 |
+| `02 算子迁移部署` | 有限纳入 | 评“迁移支撑能力” | PTO IR 入口、样例/PyPTO 快照、compile-only/validation、迁移前后对照样例 | 业务框架集成、完整模型接线、仓外工程改造 |
+| `03 builtin 算子定制修改` | 默认不纳入 | 标 `N/A`，必要时只做差距说明 | 无固定模板 | builtin/业务算子定制主流程 |
+| `04 算子基本功能实现` | 次级支撑 | 只评 PTOAS 直接支撑的工程子链路 | 文档、样例、编译配置、工程编译、运行反馈、验证 | 完整需求分析、完整方案设计、通用算子研发全过程 |
+| `05 特定 shape 性能优化` | 条件纳入 | 评“特定 shape 性能优化支撑能力” | 性能文档、固定 shape 样例、性能数据获取入口、编译验证、精度/性能验证 | 没有 baseline 时的性能提升幅度、仓外友商对标 |
+| `06 泛化 shape 性能优化` | 条件纳入 | 评“多 shape / dynamic shape 支撑能力” | `valid_shape`/dynamic shape 文档、泛化样例、多 shape 验证链路 | 没有多 shape 基线矩阵时的平均/最大收益结论 |
+
+## 评估层级
+
+任何量化前都先声明层级：
+
+- `L1 文档审阅层`：只看仓库内容，不跑命令。
+- `L2 本地最小运行层`：当前机器已有 PTOAS 产物，可验证最小命令。
+- `L3 Linux compile-only 层`：Linux + CANN/bisheng + `PTO_ISA_ROOT`，不要求带卡。
+- `L4 NPU 上板层`：带卡 Linux、驱动、ACL、设备节点和用户权限齐全。
+
+评分规则：
+- 某层未覆盖，只能标 `未实测`。
+- 不得因为本机不是 Linux / 没有 `bisheng` / 没有 NPU 就对 PTOAS 本身扣分。
+- 文档是否清楚说明这些前置条件，才属于可评分项。
+
+## `02` 的适用边界
+
+PTOAS 可以支撑 `02`，但只能评“迁移支撑能力”，不能假装它已经覆盖完整业务迁移平台。
+
+可以评分的证据：
+- `docs/PTO_IR_manual.md`：IR 层级、tile/view/valid-shape 语义、Level-2/Level-3 入口
+- `test/samples/PyPTOIRParser/README.md`：来自 pypto `ir_parser` 的 vendored `.pto` 快照
+- `test/samples/*`：迁移后 PTO case、样例目录、`golden.py`/`compare.py`
+- `docs/no_npu_compile_only_guide_zh.md`、`runop.sh`、remote validation 脚本：迁移后 compile/validate 链路
+
+`02` 里这些指标只有在“有前后对照”时才能量化：
+- `tiling 迁移完备度`
+- `kernel 迁移完备度`
+- `tiling/kernel 代码修改率`
+- `功能失败率`
+- `性能劣化率`
+
+如果当前任务没有“迁移前/迁移后”对照 case：
+- 记 `未实测`，不要臆造百分比。
+- 若该项本质依赖仓外业务工程，且用户没有给材料，可记 `N/A` 并说明原因。
+
+## `04` 的适用边界
+
+`04` 只纳入这些与 PTOAS 仓库直接对应的子项：
+- 文档获取
+- 文档学习
+- 获取示例代码
+- 学习/理解示例代码
+- 运行示例代码
+- 编译配置
+- 算子工程编译
+- 功能调试
+- 精度调试中 repo 已有 compare/golden/validation 的部分
+
+默认排除：
+- 算子设计-需求分析
+- 算子设计-方案实现
+- 通用算子代码开发全过程
+- 脱离 PTOAS 仓库的业务工程联调
+
+## `05` 的适用边界
+
+PTOAS 可以支撑 `05`，但重点是“特定 shape 性能优化的仓内支撑能力”。
+
+可直接使用的仓内证据：
+- `docs/PTO_IR_manual.md`：Level-2/Level-3、layout、partition、reshape、valid-shape 等语义
+- `.github/ISSUE_TEMPLATE/performance_issue.yml`：性能问题收集模板
+- `test/samples/FlashAttention/`, `test/samples/GQA/`, `test/samples/FFN/`, `test/samples/MatMul/`：固定 shape 样例
+- `runop.sh`、compile-only 文档、remote validation 脚本：生成、编译、上板验证链路
+
+`05` 里这些项通常至少要到 `L4` 才能量化：
+- 性能数据采集耗时
+- 性能报告完备度
+- 优化迭代次数/耗时/成功率
+- 性能提升幅度
+- 精度一致性验证
+
+如果只有文档和样例，没有真实 benchmark/baseline：
+- 文档和入口可评分
+- 真实性能数字、友商对标、提升幅度一律 `未实测` 或 `N/A`
+
+## `06` 的适用边界
+
+PTOAS 可以支撑 `06`，但重点是“多 shape / dynamic shape / valid-shape 的泛化支撑能力”。
+
+可直接使用的仓内证据：
+- `docs/PTO_IR_manual.md`
+- `test/samples/SetValidShape/`
+- `test/samples/LayoutInference/`
+- `test/samples/Partition5D/`
+- `test/samples/planmemory/`
+- 其他带动态 shape / layout / partition / subview / reshape 的样例
+
+`06` 里这些项没有多 shape 基线矩阵时不能硬算：
+- 平均优化迭代次数
+- 平均优化耗时
+- 平均性能提升幅度
+- 最大性能提升幅度
+- 多 shape 精度保持率
+
+如果当前任务只看到 IR 设计与样例，没有多 shape 实测：
+- 文档、样例覆盖度可评分
+- 多 shape 性能/精度结果记 `未实测`
+
+## `未实测` 与 `N/A` 的使用规则
+
+记 `未实测`：
+- 仓库里有入口，但当前会话没有进入对应层级
+- 缺 Linux/CANN/NPU/baseline，导致只能停在文档或最小运行层
+- 缺迁移前后对照物，无法给出完成度/收益率
+
+记 `N/A`：
+- 指标本身超出 PTOAS 仓库边界
+- 用户要求的是仓外业务工程能力，当前仓库没有独立证据链
+- 友商对标、完整业务迁移、完整 builtin 定制等不是本 Skill 的默认量化对象
+
+## 使用原则
+
+- 如果用户没有特别说明，直接按 `01` 做主评估。
+- 如果用户要求顺带看 `02/04/05/06`，按本文件的边界补相应子集。
+- 可以做“支持度评分”，但不要把仓内文档/样例的存在，夸大成业务侧已经打通。
+- 能量化就量化；不能量化就明确说明为什么是 `未实测` 或 `N/A`。
diff --git a/.cursor/skills/ptoas-usability-eval/references/scoring.md b/.cursor/skills/ptoas-usability-eval/references/scoring.md
new file mode 100644
index 000000000..ba3d01d6d
--- /dev/null
+++ b/.cursor/skills/ptoas-usability-eval/references/scoring.md
@@ -0,0 +1,148 @@
+# 总分汇总规则
+
+本文件定义 PTOAS 易用性评估的总分汇总方法，解决两个问题：
+- 单项指标混用 `10 分制` 和 `100 分制`
+- `未实测` / `N/A` 不能被误当成低分
+
+## 1. 基本原则
+
+- 单项展示时，保留用户原始分制。
+- 汇总总分时，再做统一归一化。
+- 场景分只基于本次选中的 `Core/Conditional Touch-Points` 或其 repo 级代理指标计算。
+- 默认输出两个总分：
+  - `总分（支撑）`
+  - `总分（实测）`
+
+## 2. 单项归一化
+
+把单项分数统一换算到 `100` 分制：
+
+- 原始 `10` 分制：`归一化分 = 原始分 * 10`
+- 原始 `100` 分制：`归一化分 = 原始分`
+
+示例：
+- `8/10 -> 80/100`
+- `60/100 -> 60/100`
+
+## 3. 特殊值处理
+
+- `未实测`：不计入任何总分分母
+- `N/A`：不计入任何总分分母
+- 如果某个场景下所有指标都是 `未实测/N/A`：
+  - 该场景分不输出数值
+  - 标记为 `本次无实测样本`
+
+## 4. 场景分
+
+先算场景分，再算总分。
+
+### 4.1 场景支撑分
+
+定义：该场景下所有“已评分”的指标，归一化后求平均。
+
+纳入范围：
+- 文档
+- 样例
+- 脚本
+- 配置
+- 已实测项
+
+排除范围：
+- `未实测`
+- `N/A`
+
+用途：衡量 PTOAS 仓库本身提供的支撑能力。
+
+### 4.2 场景实测分
+
+定义：该场景下所有“有真实执行证据”的指标，归一化后求平均。
+
+必须满足至少一种证据：
+- 真实命令执行
+- 真实编译/build
+- 真实 sample 运行
+- 真实 validation / compare / board 结果
+
+不纳入：
+- 纯文档发现性分
+- 纯 README/脚本存在性分
+- `未实测`
+- `N/A`
+
+用途：衡量当前会话里真正被跑通或被验证到的易用性。
+
+## 5. 默认场景权重
+
+如果用户没有单独指定权重，默认用：
+
+- `01`：`40%`
+- `02`：`15%`
+- `04`：`15%`
+- `05`：`15%`
+- `06`：`15%`
+
+说明：
+- `01` 是 PTOAS 的主评估场景，所以权重最高。
+- `02/04/05/06` 是补充场景，默认均分剩余权重。
+
+## 6. 权重重分配
+
+不要把没有参与本次评估的场景硬算进总分。
+
+### 6.1 用户只评部分场景
+
+如果本次只评了部分场景，例如只评 `01 + 04`：
+- 先取这两个场景的默认权重 `40` 和 `15`
+- 再重分配到 `100%`
+
+例：
+- `01` 新权重 = `40 / (40+15) = 72.73%`
+- `04` 新权重 = `15 / (40+15) = 27.27%`
+
+### 6.2 计算 `总分（支撑）`
+
+- 只保留“有场景支撑分”的场景
+- 对这些场景的默认权重重分配后加权平均
+
+### 6.3 计算 `总分（实测）`
+
+- 只保留“有场景实测分”的场景
+- 对这些场景的默认权重重分配后加权平均
+
+## 7. 输出要求
+
+建议固定输出以下内容：
+
+- `总分（支撑）`：`xx/100`
+- `总分（实测）`：`xx/100` 或 `本次无法计算`
+- `覆盖场景`：本次实际评了哪些场景
+- `覆盖层级`：`L1/L2/L3/L4` 到了哪一层
+- `实测覆盖说明`：哪些场景只有文档分，哪些场景有真实执行分
+
+## 8. 解释口径
+
+当两个总分差异较大时，优先按下面口径解释：
+
+- `总分（支撑）` 高、`总分（实测）` 低：
+  - 仓库文档/样例/脚本铺得比较全
+  - 但当前会话真实跑通度一般，或存在环境/样例摩擦
+
+- `总分（支撑）` 低、`总分（实测）` 高：
+  - 当前 case 可能能跑
+  - 但仓库的通用文档化、模板化、可发现性较弱
+
+- `总分（实测）` 显示为 `本次无法计算`：
+  - 说明本次基本停留在 `L1`，或者只有文档审阅，没有足够的真实执行证据
+
+## 9. 推荐展示格式
+
+```text
+总分（支撑）: 78.5/100
+总分（实测）: 66.4/100
+覆盖场景: 01, 02, 04, 05, 06
+覆盖层级: L1 + L2
+说明:
+- 01/04 同时形成支撑分和实测分
+- 02/05/06 当前主要形成文档/样例支撑分
+- L3/L4 未实测，不计入实测总分分母
+```
diff --git a/.cursor/skills/ptoas-usability-eval/references/touchpoint-selection.md b/.cursor/skills/ptoas-usability-eval/references/touchpoint-selection.md
new file mode 100644
index 000000000..d57a6d79e
--- /dev/null
+++ b/.cursor/skills/ptoas-usability-eval/references/touchpoint-selection.md
@@ -0,0 +1,154 @@
+# PTOAS Touch-Point 选型
+
+本文件把用户提供的总触点池裁剪成适合 `hw-native-sys/PTOAS` 的 repo 级评估子集。
+
+## 1. 选型原则
+
+- PTOAS 是**编译器 / 工具链 / 样例仓库**，不是完整 CANN 产品矩阵，也不是官方镜像分发平台。
+- 默认优先评估这些触点：
+  - `资料/文档`
+  - `API/接口` 中与 `CLI / Python 绑定 / PTO IR 手册` 直接相关的子项
+  - `源码 & 示例类`
+  - `工具`
+  - `版本` 中 repo 内可自证的子项
+  - `运行反馈`
+- 对需要**产品级生态、仓外对标、跨硬件矩阵、发布渠道运营**的数据，默认不要硬打 repo 分，记 `N/A` 或只做差距说明。
+
+## 2. 默认纳入的 Core Touch-Points
+
+这些触点默认进入 PTOAS repo 级评分。
+
+### 2.1 资料/文档
+
+- `TP001` 检索命中成功率
+- `TP002` 文档跳转次数
+- `TP003` 多入口可达率
+- `TP004` 单次任务文档跳转浏览率
+- `TP005` 知识渐进式发布
+- `TP008` 文档结构风格一致率
+- `TP009` 概念跨文档冲突数
+- `TP011` 文档、版本时效一致性
+- `TP012` 内/外链有效率
+- `TP013` 文档错误点位密度
+- `TP016` 资料交付件完备率
+- `TP017` 文档场景/内容覆盖缺失率
+- `TP018` quick_start / sample 一次跑通率
+
+### 2.2 API / 接口
+
+这里只看 PTOAS repo 自己暴露的接口层：
+- `CLI`: `ptoas`, `ptobc`
+- `Python bindings`
+- `PTO IR` 公开手册/Op 语义
+
+默认纳入：
+- `TP019` 目标接口平均查找检索轮次
+- `TP020` 渐进式复杂披露覆盖度
+- `TP028` 平均入参数 / 参数复杂度
+- `TP032` 接口自解释读懂率
+
+### 2.3 源码 & 示例类
+
+- `TP034` 示例代码无修改一键编译运行成功率
+- `TP035` 示例检索命中成功率
+- `TP036` 样例覆盖度
+- `TP037` 最小功能实现 Demo 覆盖率
+- `TP038` 命令示例覆盖度
+- `TP039` API 调用样例覆盖率
+- `TP042` 样例代码编译语法错误检出率
+- `TP043` 样例使用废弃 / 过期 API 占比
+- `TP044` 业务代码直接复用改编比例
+- `TP045` 编程模型标准对齐率
+- `TP046` 关键链路显性化率
+- `TP047` 认知理解步数
+
+### 2.4 工具
+
+- `TP049` 首次安装部署一次性成功率
+- `TP051` 标准任务平均操作步骤数
+- `TP052` 功能 / 场景覆盖率
+
+### 2.5 版本
+
+只纳入 repo 内可通过 `README / CI / tag / branch / issue template` 自证的部分：
+- `TP053` 版本检索命中成功率
+- `TP058` 版本配套关系准确性
+
+### 2.6 运行反馈
+
+- `TP062` 报错携带环境 / 版本 / 上下文信息完整率
+- `TP063` 报错自带排障建议比例
+- `TP064` 无效冗余信息占比
+
+## 3. 条件纳入的 Conditional Touch-Points
+
+这些触点只有在用户明确要求，或者当前任务确实提供了对应证据时才纳入。
+
+### 3.1 文档 / API 条件项
+
+- `TP006` FAQ 命中率
+- `TP010` 接口文档模板一致率
+- `TP014` API 文档覆盖率
+- `TP015` 错误码文档化率
+- `TP033` N+2 小版本破坏性接口变更频次
+
+### 3.2 示例 / 性能高级项
+
+- `TP040` E2E 实战案例覆盖率
+- `TP041` 行业深度调优案例覆盖率
+
+### 3.3 版本 / 部署高级项
+
+- `TP054` 版本信息完备率
+- `TP057` 版本号规范准确率
+- `TP059` 版本部署命令数
+- `TP060` 开箱部署成功率
+- `TP061` 版本兼容性率
+
+说明：
+- `TP061` 在 PTOAS 里通常要到 `L4`，并且需要 A3/A5/不同硬件的实测证据。
+- `TP040/TP041` 在 PTOAS 里只有当 `FlashAttention/GQA/FFN` 这类样例被当作准业务案例使用时才适合纳入。
+
+## 4. 默认排除的 Excluded Touch-Points
+
+这些触点默认**不进入** PTOAS repo 级总分，除非用户明确要求做生态级差距研究。
+
+### 4.1 产品生态 / 友商对标类
+
+- `TP021` API 业务场景覆盖率
+- `TP022` 主流 AI 应用框架 API 支持覆盖率
+- `TP023` 主流 AI 框架 API 支持覆盖率
+- `TP024` API 主流生态调用一致性
+- `TP025` 原子 API 与标杆 API 数量对比一致性
+- `TP026` 迁移修改代码（CUDA -> AscendC）
+- `TP027` 原子 API 与标杆 API 行为对比一致性
+
+原因：这些指标要求的是**全产品生态**、**仓外框架集成**、**与 CUDA/CANN 大盘对比**，不是 PTOAS 仓库单独可证的事实。
+
+### 4.2 不适合 PTOAS repo 形态的项
+
+- `TP029` 错误返回一致率
+- `TP030` 最小可用代码行数
+- `TP055` 主流镜像仓支持下载覆盖度
+- `TP056` 典型部署模式支持覆盖度
+
+原因：
+- PTOAS 不是以统一 runtime C API 为主的库产品，`TP029/TP030` 不适合直接套。
+- PTOAS repo 不是镜像/安装包分发平台，`TP055/TP056` 默认不打 repo 分。
+
+## 5. 场景到 Touch-Point 的默认映射
+
+| 场景 | 默认 Core Touch-Points | 条件 Touch-Points |
+| --- | --- | --- |
+| `01 算子复现部署` | `TP001-005, TP008-018, TP034-035, TP038, TP042, TP044, TP049, TP051-053, TP058, TP062-064` | `TP006, TP054, TP057, TP059-061` |
+| `02 算子迁移部署` | `TP001-005, TP008-009, TP011, TP013, TP017, TP019-020, TP032, TP035-037, TP039, TP044, TP046-047, TP051-052, TP062-064` | `TP040-041, TP033, TP061` |
+| `04 算子基本功能实现` | `TP001-005, TP008-009, TP011, TP013, TP017-020, TP028, TP032, TP034-039, TP042-047, TP049, TP051-052, TP062-064` | `TP006, TP010, TP014-015, TP033` |
+| `05 特定 shape 性能优化` | `TP001-005, TP017, TP019-020, TP035-036, TP039, TP044, TP046, TP049, TP051-052, TP062-064` | `TP040-041, TP054, TP061` |
+| `06 泛化 shape 性能优化` | `TP001-005, TP017, TP019-020, TP035-036, TP039, TP044, TP046-047, TP049, TP051-052, TP062-064` | `TP040-041, TP054, TP061` |
+
+## 6. 使用要求
+
+- 每次正式评估前，先在输出里给出 `触点选择`。
+- 默认只打 `Core Touch-Points`。
+- `Conditional Touch-Points` 只有在证据存在时才纳入，并明确说明为什么本次纳入。
+- `Excluded Touch-Points` 不进入总分；如果用户追问，可以单独给差距分析，但不要混入 repo 级总分。
diff --git a/.trae/skills/ptoas-usability-eval/README.md b/.trae/skills/ptoas-usability-eval/README.md
new file mode 100644
index 000000000..3f8fd8545
--- /dev/null
+++ b/.trae/skills/ptoas-usability-eval/README.md
@@ -0,0 +1,33 @@
+# PTOAS Usability Eval Skill
+
+这是 PTOAS 仓库内的通用 Skill 源目录。
+
+支持的客户端入口：
+- Codex: `.codex/skills/ptoas-usability-eval/`
+- Cursor: `.cursor/skills/ptoas-usability-eval/`
+- Trae: `.trae/skills/ptoas-usability-eval/`
+- Claude Code: `.claude/skills/ptoas-usability-eval/`
+
+当前覆盖的评估场景：
+- `01 算子复现部署`
+- `02 算子迁移部署` 的 PTOAS 支撑子集
+- `04 算子基本功能实现` 的 PTOAS 工程子集
+- `05 特定 shape 性能优化` 的 PTOAS 支撑子集
+- `06 泛化 shape 性能优化` 的 PTOAS 支撑子集
+
+当前附带的汇总规则：
+- 原始指标保留 `10 分制 / 100 分制`
+- 汇总时统一归一到 `100` 分制
+- 默认输出 `总分（支撑）` 和 `总分（实测）`
+- `未实测/N/A` 不进入总分分母
+
+当前评估逻辑：
+- 先按 `touch-point` 体系选取适用于 PTOAS 的触点
+- 再按 `01/02/04/05/06` 场景评分
+- 默认只把适用的 `Core Touch-Points` 放进 repo 级总分
+
+约定：
+- `skills/ptoas-usability-eval/` 作为仓库内的通用主副本
+- 各客户端目录提供可直接发现的副本，便于不同工具开箱即用
+- 修改 Skill 内容时，应同步更新上述四个客户端目录
+- 对 `L3/L4` 依赖 Linux/CANN/NPU 的指标，未实测时必须标 `未实测`，不能因为当前机器缺环境直接给 PTOAS 低分
diff --git a/.trae/skills/ptoas-usability-eval/SKILL.md b/.trae/skills/ptoas-usability-eval/SKILL.md
new file mode 100644
index 000000000..24cc41525
--- /dev/null
+++ b/.trae/skills/ptoas-usability-eval/SKILL.md
@@ -0,0 +1,98 @@
+---
+name: ptoas-usability-eval
+description: Evaluate PTOAS repository usability across scene 01 as the primary template plus the PTOAS-supported subsets of scenes 02, 04, 05, and 06. Always classify the evaluation by environment layer first, use only repo-native docs/scripts/samples/CI as primary evidence, keep the user's mixed 10-point and 100-point scoring rules, compute normalized support and measured totals, and mark unsupported or untested dimensions as 未实测 or N/A.
+---
+
+# PTOAS Usability Eval
+
+当用户要评估 `hw-native-sys/PTOAS` 的易用性，或要按 `01/02/04/05/06` 给 PTOAS 打分时，使用这个 Skill。
+
+## 默认范围
+
+- `01 算子复现部署`：主评估场景，正常评分。
+- `02 算子迁移部署`：纳入，但只评 PTOAS 仓库能直接支撑的迁移入口、样例、IR/脚本、编译验证链路。
+- `04 算子基本功能实现`：纳入，但只评 PTOAS 直接覆盖的示例、编译、验证、反馈子链路。
+- `05 特定 shape 性能优化`：纳入，但只评 PTOAS 的文档、样例、性能数据获取入口、编译验证、精度/性能验证支撑能力。
+- `06 泛化 shape 性能优化`：纳入，但只评 PTOAS 的 dynamic/valid-shape、多 shape 样例与验证支撑能力。
+- `03 builtin 算子定制修改`：默认不纳入量化，标 `N/A`；必要时只做差距说明。
+
+先读 [references/touchpoint-selection.md](references/touchpoint-selection.md) 选定适用触点，再读 [references/scope.md](references/scope.md) 确认各场景的边界和 `未实测/N/A` 规则。
+
+## 先判层级
+
+开始评分前，必须先声明本次评估覆盖到哪一层。没有层级，不能直接混着打分。
+
+可选层级：
+- `L1 文档审阅层`：只看仓库文档、脚本、样例、CI，不做运行。
+- `L2 本地最小运行层`：当前机器已有 `ptoas` / `ptobc` / Python 绑定，可做最小命令验证。
+- `L3 Linux compile-only 层`：需要 Linux + CANN/bisheng + `PTO_ISA_ROOT`，不要求带卡。
+- `L4 NPU 上板层`：需要带卡 Linux、驱动、权限、`/dev/davinci*` 与对应用户组。
+
+约束：
+- 没进入某层，就把该层指标记为 `未实测`，不能因为当前机器缺环境就给 PTOAS 低分。
+- `bisheng` / CANN compile-only 一般属于 `L3`，不应在本地 Mac 上硬打低分。
+- 带卡运行、设备权限、驱动、ACL、用户组属于 `L4`。
+
+## 证据来源
+
+优先只用仓库内证据，不把仓外经验当成主证据。固定入口见 [references/evidence-checklist.md](references/evidence-checklist.md)。
+
+高优先级证据：
+- `README.md`
+- `docs/no_npu_compile_only_guide_zh.md`
+- `docs/PTO_IR_manual.md`
+- `test/samples/runop.sh`
+- `test/npu_validation/scripts/generate_testcase.py`
+- `test/npu_validation/scripts/run_remote_npu_validation.sh`
+- `test/samples/PyPTOIRParser/README.md`
+- `test/samples/FlashAttention/`, `test/samples/GQA/`, `test/samples/FFN/`
+- `test/samples/SetValidShape/`, `test/samples/LayoutInference/`, `test/samples/Partition5D/`, `test/samples/planmemory/`
+- `.github/workflows/ci.yml`
+- `.github/ISSUE_TEMPLATE/performance_issue.yml`
+
+## 工作流
+
+1. 先判断用户要的是 `01`、`02`、`04`、`05`、`06` 中哪些场景；未说明时默认 `01`。
+2. 再判断本次覆盖层级：`L1/L2/L3/L4`。输出中必须显式写出来。
+3. 先读 [references/touchpoint-selection.md](references/touchpoint-selection.md)，按场景选定本次的 `Core / Conditional / Excluded` 触点。
+4. 从仓库内收集证据，记录每次检索轮次、文档跳转次数、执行命令、耗时、成功/失败结果。
+5. `01` 场景读 [references/metrics-01.md](references/metrics-01.md)。
+6. `02` 场景读 [references/metrics-02.md](references/metrics-02.md)。
+7. `04` 场景读 [references/metrics-04.md](references/metrics-04.md)。
+8. `05` 场景读 [references/metrics-05.md](references/metrics-05.md)。
+9. `06` 场景读 [references/metrics-06.md](references/metrics-06.md)。
+10. 需要汇总总分时，读 [references/scoring.md](references/scoring.md)。
+11. 对每个指标都输出：原始观测值、评分、证据路径、说明。没有实测的数据不要猜，记为 `未实测` 或 `N/A`。
+12. 明确区分：
+    - PTOAS 仓库已提供的能力
+    - 外部前置条件，例如 LLVM、CANN、`pto-isa`、NPU、驱动/权限、业务 baseline
+13. 若文档描述与实际运行冲突，以实际命令结果为准，并指出冲突位置。
+14. 默认给两个总分：`总分（支撑）` 和 `总分（实测）`。如果用户只要分项，不强制输出总分。
+
+## 计量规则
+
+- 保留用户原始口径，不强行覆盖各指标的原始分制。
+- 但做总分汇总时，必须按 [references/scoring.md](references/scoring.md) 做归一化。
+- `检索轮次`：每次新的定向搜索或定位尝试算 1 轮。
+- `文档跳转次数`：命中首个目标文档后，每跨一个文档/README/脚本入口算 1 次。
+- `耗时`：尽量记录真实墙钟时间；拿不到就写 `未实测`，不要臆测。
+- `成功率`：只基于当前任务里真实执行或真实定位到的结果计算。
+- `未实测`：当前会话未覆盖到对应环境层级，或该层级前置条件不存在，或缺少前后对照 baseline。
+- `N/A`：只用于超出 PTOAS 能力边界，或当前任务明确不纳入本次评估范围的项。
+
+## 输出格式
+
+按下面顺序输出：
+
+1. `评估范围`
+2. `触点选择`
+3. `评估层级`
+4. `总分（支撑）`
+5. `总分（实测）`
+6. `分场景评分`
+7. `覆盖说明`
+8. `关键证据`
+9. `主要短板`
+10. `建议动作`
+
+如果用户只要简版结论，也要至少保留：场景归类、评估层级、总评、最低分项、证据路径。
diff --git a/.trae/skills/ptoas-usability-eval/agents/openai.yaml b/.trae/skills/ptoas-usability-eval/agents/openai.yaml
new file mode 100644
index 000000000..924e59e3f
--- /dev/null
+++ b/.trae/skills/ptoas-usability-eval/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "PTOAS Usability Eval"
+  short_description: "评估 PTOAS 在 01/02/04/05/06 场景下的易用性"
+  default_prompt: "Use $ptoas-usability-eval to evaluate this PTOAS repo for scene 01 operator reproduction/deployment and the PTOAS-supported subsets of scenes 02, 04, 05, and 06."
diff --git a/.trae/skills/ptoas-usability-eval/references/evidence-checklist.md b/.trae/skills/ptoas-usability-eval/references/evidence-checklist.md
new file mode 100644
index 000000000..89b6f1987
--- /dev/null
+++ b/.trae/skills/ptoas-usability-eval/references/evidence-checklist.md
@@ -0,0 +1,86 @@
+# 证据清单
+
+## 固定证据入口
+
+| 路径 | 主要用途 | 对应场景 | 层级 | 主要触点 |
+| --- | --- | --- | --- | --- |
+| `README.md` | 官方构建、环境变量、CLI、Python 绑定、sample 运行、compile-only/上板验证主入口 | `01`, `02`, `04`, `05`, `06` | `L1-L4` | `TP001-005, TP016-020, TP038, TP049, TP053, TP058` |
+| `docs/no_npu_compile_only_guide_zh.md` | 无卡 compile-only 流程、批量验证流程、`pto-isa`/CANN 依赖说明 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3` | `TP005, TP017-018, TP049, TP051-052, TP058-060, TP062-064` |
+| `docs/PTO_IR_manual.md` | IR 层级、tile/view/valid-shape、layout、dynamic shape、Level-2/3 语义 | `02`, `04`, `05`, `06` | `L1-L4` | `TP019-020, TP028, TP032, TP039, TP045-047` |
+| `test/samples/runop.sh` | 批量样例生成、`ptoas`/`ptobc` 运行、A3/A5 默认参数策略 | `01`, `02`, `04`, `05`, `06` | `L1-L4` | `TP018, TP034-039, TP049, TP051-052, TP062-064` |
+| `test/npu_validation/scripts/generate_testcase.py` | 从 `*-pto.cpp` 生成验证工程，观察 golden/compare/兼容层处理 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3`, `L4` | `TP037-039, TP045-047, TP049, TP052` |
+| `test/npu_validation/scripts/run_remote_npu_validation.sh` | compile-only / sim / npu 运行链路、日志格式、设备与 `pto-isa` 检查 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3`, `L4` | `TP049, TP051-052, TP058-060, TP062-064` |
+| `test/samples/PyPTOIRParser/README.md` | 来自 pypto `ir_parser` 的 vendored `.pto` 快照说明 | `02` | `L1` | `TP035-037, TP039, TP044, TP046-047` |
+| `test/samples/MatMul/` | README 直接引用的基准样例，适合作为 `01` 默认复现模板 | `01`, `04`, `05` | `L1-L4` | `TP018, TP034-039, TP042-047` |
+| `test/samples/FlashAttention/` | 特定 shape 性能样例 | `05` | `L1-L4` | `TP035-041, TP044, TP046` |
+| `test/samples/GQA/` | 特定 shape / attention 相关样例 | `05` | `L1-L4` | `TP035-041, TP044, TP046` |
+| `test/samples/FFN/` | 特定 shape / 算子组合样例 | `05` | `L1-L4` | `TP035-041, TP044, TP046` |
+| `test/samples/SetValidShape/` | dynamic/valid-shape 相关样例 | `06` | `L1-L4` | `TP035-039, TP044, TP046-047` |
+| `test/samples/LayoutInference/` | layout 推断相关样例 | `06` | `L1-L4` | `TP019-020, TP035-039, TP046-047` |
+| `test/samples/Partition5D/` | 多维 partition / shape 泛化相关样例 | `02`, `06` | `L1-L4` | `TP035-039, TP044, TP046-047, TP061` |
+| `test/samples/planmemory/` | alias/planmemory/shape 相关样例 | `06` | `L1-L4` | `TP035-039, TP044, TP046-047` |
+| `.github/workflows/ci.yml` | CI 中的 LLVM/PTOAS 构建、lit、sample test、remote validation 参考配置 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3`, `L4` | `TP003, TP011, TP049, TP052-053, TP058, TP060-064` |
+| `.github/ISSUE_TEMPLATE/performance_issue.yml` | 性能问题受理模板，可用来评估性能数据/复现要求的完备性 | `05`, `06` | `L1` | `TP005, TP017, TP040-041, TP062-063` |
+
+说明：
+- 不要把当前分支不存在的样例 README 当成固定证据源。
+- 对 `02/05/06`，没有“前后对照基线”时，不要硬算迁移完备度或性能提升幅度。
+
+## 推荐检索顺序
+
+1. `README.md`
+2. `docs/no_npu_compile_only_guide_zh.md`
+3. `docs/PTO_IR_manual.md`
+4. `test/samples/MatMul/` 或用户指定样例目录
+5. `test/samples/PyPTOIRParser/`, `FlashAttention/`, `GQA/`, `FFN/`, `SetValidShape/`, `LayoutInference/`, `Partition5D/`, `planmemory/`
+6. `test/samples/runop.sh`
+7. `test/npu_validation/scripts/*.py` / `*.sh`
+8. `.github/workflows/ci.yml`
+9. `.github/ISSUE_TEMPLATE/performance_issue.yml`
+
+## 推荐检索命令
+
+```bash
+rg -n "构建|运行测试|compile-only|runop|generate_testcase|run_remote_npu_validation|level3" README.md docs test .github
+rg -n "valid_shape|layout|partition|reshape|dynamic shape|Level-2|Level-3" docs/PTO_IR_manual.md docs test
+rg -n "FlashAttention|GQA|FFN|MatMul|SetValidShape|LayoutInference|Partition5D|planmemory" test .github
+rg --files test/samples
+find test/samples -maxdepth 2 -type f \( -name '*.py' -o -name '*.pto' -o -name 'README.md' \)
+```
+
+## 迁移 / 性能场景的补充记录项
+
+如果在评 `02/05/06`，额外记录：
+- 是否存在迁移前/迁移后对照物
+- 是否存在性能 baseline
+- baseline 来源路径
+- 是否需要 NPU 实机
+- 当前停在哪一层
+- 哪些分数是实测，哪些是文档侧支撑分
+
+## 记录要求
+
+每个评分项至少要落这些证据字段：
+
+- `证据路径`
+- `检索/执行命令`
+- `检索轮次`
+- `文档跳转次数`
+- `评估层级`
+- `耗时`
+- `结果`
+- `评分`
+- `备注`
+
+## 默认样例
+
+若用户没有指定具体算子或样例，优先使用：
+
+- `test/samples/MatMul/tmatmulk.py`
+- `test/samples/MatMul/tmatmulk.pto`
+- `test/samples/Addc/addc.py`
+- `test/samples/PyPTOIRParser/`
+- `test/samples/FlashAttention/`
+- `test/samples/SetValidShape/`
+
+理由：这些路径要么被 `README.md` 直接引用，要么与迁移/性能/shape 泛化评估强相关，且当前主线可稳定找到。
diff --git a/.trae/skills/ptoas-usability-eval/references/metrics-01.md b/.trae/skills/ptoas-usability-eval/references/metrics-01.md
new file mode 100644
index 000000000..58bcc109d
--- /dev/null
+++ b/.trae/skills/ptoas-usability-eval/references/metrics-01.md
@@ -0,0 +1,119 @@
+# `01 算子复现部署` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP008-018`
+- `源码 & 示例类`: `TP034-035, TP038, TP042, TP044`
+- `工具`: `TP049, TP051-052`
+- `版本`: `TP053, TP058`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP006, TP054, TP057, TP059-061`
+
+默认把 PTOAS 看作“从样例或 `.pto` 输入出发，完成构建、编译、compile-only 或上板验证”的工具链仓库。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+在 `01` 场景里，必须先声明本次评估覆盖的层级：
+
+- `L1 文档审阅层`
+- `L2 本地最小运行层`
+- `L3 Linux compile-only 层`
+- `L4 NPU 上板层`
+
+没有进入对应层，就标 `未实测`，不要把环境缺失当成 PTOAS 负分。
+
+## 默认任务模板
+
+若用户没有指定具体 case，优先用 `test/samples/MatMul/` 作为复现模板：
+
+```bash
+python3 test/samples/MatMul/tmatmulk.py > /tmp/tmatmulk.pto
+./build/tools/ptoas/ptoas /tmp/tmatmulk.pto -o /tmp/tmatmulk.cpp
+```
+
+需要无卡 compile-only 时，继续参考：
+
+```bash
+python3 test/npu_validation/scripts/generate_testcase.py \
+  --input /tmp/tmatmulk.cpp \
+  --run-mode npu \
+  --soc-version Ascend910
+```
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 检索命中成功率 | 统计找到“构建 + sample 运行 + compile-only/上板验证”入口所需检索轮次 | `README.md`, `docs/no_npu_compile_only_guide_zh.md` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+| 文档检索耗时 | 从开始找文档到定位到正确路径的时间 | 同上 | `L1-L4` | `2 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 文档获取成功率 | 目标文档是否都能在仓库内找到 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+### 文档学习
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 文档错误点位密度 | 按文档执行时，检查命令、路径、版本、链接、说明是否错误 | `README.md`, `docs/no_npu_compile_only_guide_zh.md`, `.github/workflows/ci.yml` | `L1-L4` | 零错误 `100`；少量小错 `80`；一般错误 `60`；明显错误 `40`；严重不可用 `20` |
+| 文档跳转次数 | 从首个命中文档到凑齐完整执行路径，跨文档跳转的次数 | `README.md -> docs/... -> test/samples/...` | `L1-L4` | 1 次 `100`；2 次 `80`；3 次 `60`；4-5 次 `40`；>5 次 `20` |
+| 内容覆盖缺失率 | 是否清楚区分本地运行、Linux compile-only、带卡上板等层级前置条件 | `README.md`, `docs/...`, `.github/workflows/ci.yml` | `L1-L4` | 无缺失 `100`；`<=5%` `80`；`5%-15%` `60`；`15%-30%` `40`；`>30%` `20` |
+| 文档学习耗时 | 从开始读到能给出执行方案的时间 | 同上 | `L1-L4` | `5 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 通过文档学习检索成功率 | 需要通过文档解决的问题里，有多少真正被文档回答 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+## 易部署
+
+### 环境下载
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 环境获取场景覆盖率 | 看仓库是否说明源码构建、无卡 compile-only、上板验证所需环境 | `README.md`, `docs/no_npu_compile_only_guide_zh.md` | `L1-L4` | `100%=10`；`80%-99%=8`；`60%-79%=6`；`40%-59%=4`；`<40%=2` |
+| 环境下载耗时 | 真实下载 LLVM/CANN/Python 依赖/`pto-isa` 的时间 | 真实执行记录 | `L3-L4` | `<=5 分钟=10`；`5-7=8`；`7-9=6`；`9-11=4`；`>11=2` |
+| 环境下载成功率 | 下载步骤是否一次完成 | 真实执行记录 | `L3-L4` | `100%=10`，按比例计算 |
+
+说明：如果当前任务没有真的在 Linux/CANN 环境里下载依赖，后两项写 `未实测`。
+
+### 环境安装
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 软硬件配套兼容率 | 检查仓库是否明确 LLVM 版本、Python 包版本、CANN / `pto-isa` 依赖关系 | `README.md`, `docs/no_npu_compile_only_guide_zh.md`, `ci.yml` | `L1-L4` | `100%=10`；`80%-99%=8`；`60%-79%=6`；`40%-59%=4`；`<40%=2` |
+| 部署时长 | 从开始执行安装到可运行 `ptoas`/Python 绑定的时间 | 真实执行记录 | `L2-L4` | `<=5 分钟=10`；`5-7=8`；`7-9=6`；`9-11=4`；`>11=2` |
+| 操作步骤数 | 完成安装所需命令/步骤数量 | `README.md` 构建步骤 | `L1-L4` | `<=8 步=10`；`9-10=8`；`11-12=6`；`13-14=4`；`>14=2` |
+| 环境安装成功率 | 是否能完成 LLVM + PTOAS 构建与安装 | 真实执行记录 | `L2-L4` | `100%=10`，按比例计算 |
+
+### 环境校验
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 环境安装后校验成功率 | 是否有明确校验动作，例如 `ptoas --version`、Python import、sample compile | `README.md`, `ci.yml` | `L2-L4` | `100%=10`，按比例计算 |
+
+推荐最小校验命令：
+
+```bash
+./build/tools/ptoas/ptoas --version
+python3 -c "from mlir.dialects import pto; print('ok')"
+```
+
+## 易开发、易演进
+
+### 获取示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 检索命中成功率 | 统计定位到默认样例目录所需轮次 | `test/samples/MatMul/`, `test/samples/Addc/`, `README.md` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+
+### 运行示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 示例代码运行耗时 | 从运行 sample 到拿到 `.pto` / `.cpp` / compile-only 结果的时间 | `README.md`, `test/samples/MatMul/` | `L2-L4` | `<=2 分钟=10`；`2-4=8`；`4-6=6`；`6-8=4`；`>8=2` |
+| 示例代码运行成功率 | `py -> .pto -> .cpp` 或 compile-only / validation 是否成功 | 同上 | `L2-L4` | `100%=10`，按比例计算 |
+
+## 何时记 `未实测` / `N/A`
+
+- `未实测`：当前任务没有进入对应环境层级，例如在本地 Mac 上没有 Linux/CANN/bisheng，却要评价 compile-only。
+- `N/A`：该项超出 PTOAS 能力边界，或本次任务明确不纳入该项。
+
+不要把二者混用。
diff --git a/.trae/skills/ptoas-usability-eval/references/metrics-02.md b/.trae/skills/ptoas-usability-eval/references/metrics-02.md
new file mode 100644
index 000000000..8ad84dbf6
--- /dev/null
+++ b/.trae/skills/ptoas-usability-eval/references/metrics-02.md
@@ -0,0 +1,77 @@
+# `02 算子迁移部署` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP008-009, TP011, TP013, TP017`
+- `API / 接口`: `TP019-020, TP032`
+- `源码 & 示例类`: `TP035-037, TP039, TP044, TP046-047`
+- `工具`: `TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP040-041, TP033, TP061`
+
+这里只评估 PTOAS 仓库对“迁移到 PTO IR / PTOAS 工具链”的支撑能力，不把 PTOAS 包装成完整业务算子迁移平台。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`02` 场景同样先声明层级：
+
+- `L1 文档审阅层`
+- `L2 本地最小运行层`
+- `L3 Linux compile-only 层`
+- `L4 NPU 上板层`
+
+没有进入对应层，就标 `未实测`。
+
+## 共享易学习项
+
+`02` 的 `文档获取` / `文档学习` 默认复用 [metrics-01.md](metrics-01.md) 中对应规则；只是目标从“复现部署”改成“找到迁移入口、IR 语义、样例和验证链路”。
+
+推荐优先证据：
+- `docs/PTO_IR_manual.md`
+- `test/samples/PyPTOIRParser/README.md`
+- `README.md`
+- `docs/no_npu_compile_only_guide_zh.md`
+
+## 易迁移
+
+### 算子迁移
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| tiling 迁移完备度 | 统计迁移前定义的 tiling 结构中，已成功落到 PTO IR / sample / generated testcase 的比例 | `docs/PTO_IR_manual.md`, `test/samples/*`, 用户提供的前后对照物 | `L1-L4` | `100%=10`；`80%=8`；`60%=6`；`40%=4`；`20%=2` |
+| kernel 迁移完备度 | 统计迁移前 kernel 逻辑中，已能由 PTO case / sample / generated testcase 覆盖的比例 | 同上 | `L1-L4` | `100%=10`；`80%=8`；`60%=6`；`40%=4`；`20%=2` |
+| 算子功能失败率 | 迁移后 compile-only / validation / board case 失败比例 | `runop.sh`, `generate_testcase.py`, `run_remote_npu_validation.sh` | `L3-L4` | `0% 失败=10`；`10%=8`；`20%=6`；`30%=4`；`40%=2` |
+| 算子性能劣化率 | 迁移后相对迁移前 baseline 的性能增幅 | 用户 baseline、`performance_issue.yml`、实测日志 | `L4` | 劣化 `<5%=10`；`10%=8`；`20%=6`；`30%=4`；`40%=2` |
+| tiling 代码修改率 | 迁移时 tiling 相关代码修改行数 / 总行数 | 用户对照 case、PR diff | `L1-L4` | `0%-5%` 高分；`5%-15%` 次高；`15%-25%` 中；`25%-35%` 低；`>35%` 最低 |
+| kernel 代码修改率 | 迁移时 kernel 相关代码修改行数 / 总行数 | 用户对照 case、PR diff | `L1-L4` | `0%-5%` 高分；`5%-15%` 次高；`15%-25%` 中；`25%-35%` 低；`>35%` 最低 |
+| 算子迁移总耗时 | 从开始迁移到迁移完成，不含最终验证环节 | 真实执行记录 | `L2-L4` | `<=10 分钟` 高分；`10-20` 次之；`20-30` 中；`30-60` 低；`>60` 最低 |
+| 算子迁移成功率 | 迁移任务成功率 | 真实执行记录 | `L2-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 在 PTOAS 中如何落地这些指标
+
+### 可直接量化的前提
+
+只有当前任务同时具备以下材料时，才量化迁移完备度/修改率/失败率：
+- 迁移前输入：上游 IR、旧 kernel、旧 tiling，至少一种
+- 迁移后输入：PTO `.pto`、sample、generated testcase，至少一种
+- 对应验证链路：compile-only 或 board validation
+
+### 没有对照物时怎么办
+
+- 只有仓库文档和样例，没有迁移前材料：
+  - 可以评“入口是否清晰”“样例/脚本是否齐全”
+  - 不能给出完备度/修改率/性能劣化率，记 `未实测`
+- 指标本身依赖仓外业务工程，且用户没给材料：
+  - 记 `N/A`
+
+## 推荐默认证据路径
+
+- `docs/PTO_IR_manual.md`
+- `test/samples/PyPTOIRParser/README.md`
+- `test/samples/*`
+- `docs/no_npu_compile_only_guide_zh.md`
+- `test/samples/runop.sh`
+- `test/npu_validation/scripts/generate_testcase.py`
+- `test/npu_validation/scripts/run_remote_npu_validation.sh`
diff --git a/.trae/skills/ptoas-usability-eval/references/metrics-04.md b/.trae/skills/ptoas-usability-eval/references/metrics-04.md
new file mode 100644
index 000000000..d347924a6
--- /dev/null
+++ b/.trae/skills/ptoas-usability-eval/references/metrics-04.md
@@ -0,0 +1,116 @@
+# `04 算子基本功能实现` 的 PTOAS 子集指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP008-009, TP011, TP013, TP017-018`
+- `API / 接口`: `TP019-020, TP028, TP032`
+- `源码 & 示例类`: `TP034-039, TP042-047`
+- `工具`: `TP049, TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP006, TP010, TP014-015, TP033`
+
+这里只评估 PTOAS 真正覆盖到的“示例 / 编译 / 验证 / 反馈”链路，不把 PTOAS 当成完整算子研发平台。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`04` 子集同样先声明层级：
+
+- `L1 文档审阅层`
+- `L2 本地最小运行层`
+- `L3 Linux compile-only 层`
+- `L4 NPU 上板层`
+
+未进入对应层级，只能标 `未实测`。
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 检索命中成功率 | 找到目标样例、相关 CLI、验证脚本所需轮次 | `README.md`, `test/samples/`, `test/npu_validation/scripts/` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+| 文档检索耗时 | 从开始查到定位到目标入口的时间 | 同上 | `L1-L4` | `2 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 文档获取成功率 | 所需文档/脚本/样例是否都能在仓内找到 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+### 文档学习
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 文档错误点位密度 | 样例说明、命令、路径、环境前置条件是否准确 | `README.md`, sample README, `runop.sh`, `ci.yml` | `L1-L4` | 零错误 `100`；少量小错 `80`；一般错误 `60`；明显错误 `40`；严重不可用 `20` |
+| 文档跳转次数 | 为理解 sample 到 compile/validation 链路所需跳转次数 | 同上 | `L1-L4` | 1 次 `100`；2 次 `80`；3 次 `60`；4-5 次 `40`；>5 次 `20` |
+| 内容覆盖缺失率 | 样例定位、编译、验证、环境前置条件说明是否缺失 | 同上 | `L1-L4` | 无缺失 `100`；`<=5%` `80`；`5%-15%` `60`；`15%-30%` `40`；`>30%` `20` |
+| 文档学习耗时 | 从开始看文档到能解释执行路径的时间 | 同上 | `L1-L4` | `5 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 通过文档学习检索成功率 | 依赖文档回答的问题是否被解决 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+## 易开发、易演进
+
+### 获取示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 目标示例定位命中成功率 | 找到适合作为基本功能实现基线的 sample 或 `.pto` 所需轮次 | `test/samples/MatMul/`, `test/samples/Addc/`, `test/samples/PyPTOIRParser/` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+
+### 学习/理解示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 样例场景覆盖度 | 样例是否覆盖目标算子的输入、输出、golden/compare、compile/validation 场景 | 选定样例目录中的 `.py` / `.pto` / `npu_validation/` | `L1-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 样例学习分析 Token 数 | 优先使用平台可见的 AI token 统计；没有统计就写 `未量化` | 同上 | `L1-L4` | `<=500` 高分；`500-1000` 次高；`1000-2000` 中；`2000-3000` 低；`>3000` 最低 |
+| 示例理解耗时 | 从首次打开样例到能讲清输入、生成物、验证链路的时间 | 同上 | `L1-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-15` 中；`15-20` 低；`>20` 最低 |
+
+说明：如果运行环境拿不到 token 统计，第二项保留原值 `未量化`，不要编造 token 数。
+
+### 运行示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 运行成功率 | sample 首次执行是否能生成 `.pto` / `.cpp` / compile-only 验证工程 | `README.md`, `test/samples/runop.sh`, sample 目录 | `L2-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 示例代码运行耗时 | 从开始运行到 sample 结束的时间 | 同上 | `L2-L4` | `<=2 分钟` 高分；`2-4` 次之；`4-6` 中；`6-8` 低；`>8` 最低 |
+
+## 算子编译
+
+### 编译配置
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 新增/修改配置行数 | 按仓库已有说明运行 sample / validation 时，需要额外改多少配置行 | `README.md`, `docs/no_npu_compile_only_guide_zh.md`, `ci.yml` | `L1-L4` | `<5 行=100`；`<10=80`；`<15=60`；`<20=40`；`>20=20` |
+
+记录时只统计“文档外的额外修改”。按 README 就能跑通则记 `0` 行。
+
+### 算子工程编译
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 需要理解的宏/函数个数 | 为改通当前 sample / validation 链路，必须额外读懂多少宏/函数 | `runop.sh`, `generate_testcase.py`, `run_remote_npu_validation.sh`, sample CMake | `L1-L4` | `2 个=10`；`4 个=8`；`6 个=6`；`8 个=4`；`>10 个=2` |
+| 编译报错排障效率 | 从 sample / validation 工程编译到成功，中间修复了几轮 | `ninja`, `cmake --build`, validation 日志 | `L3-L4` | 无报错高分；1 次修复次之；2-3 次中；4-5 次低；>5 次最低 |
+| 编译耗时 | 开始编译到编译完成的总时间 | 同上 | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 编译成功率 | 最终编译是否成功，以及首次是否成功 | 同上 | `L3-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 功能调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 报错携带环境/版本/上下文信息完整率 | `ptoas` / validation 脚本报错时，是否包含 stage、case、路径、依赖、设备、soc/version 等信息 | `run_remote_npu_validation.sh`, sample/CI 日志 | `L2-L4` | 信息完整 `100`；`>=90%` `80`；`70%-89%` `60`；`50%-69%` `40`；`<50%` `20` |
+| 报错自带排障建议比例 | 报错是否已经给出下一步可排查方向 | 同上 | `L2-L4` | 全部带建议 `100`；`>=90%` `80`；`70%-89%` `60`；`50%-69%` `40`；`<50%` `20` |
+| 无效冗余信息占比 | 日志是否大量充斥与当前失败无关的信息 | 同上 | `L2-L4` | 无冗余 `100`；`<=5%` `80`；`5%-15%` `60`；`15%-30%` `40`；`>30%` `20` |
+| 功能调试耗时 | 从第一次失败到定位根因或跑通的时间 | 同上 | `L2-L4` | `<=10 分钟` 高分；`10-20` 次之；`20-30` 中；`30-60` 低；`>60` 最低 |
+| 功能调试成功率 | 当前目标问题是否最终解决 | 同上 | `L2-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 精度调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 精度数据获取耗时 | 获取 golden/output/compare 报告所需时间 | `generate_testcase.py`, sample `golden.py`, `compare.py` | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 定位分析次数 | 从发现精度问题到定位根因的迭代次数 | 真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 代码修改/迭代循环 | 精度修复迭代次数 | PR diff、真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+
+## 默认排除项
+
+这些在 PTOAS 仓库里默认不打分，直接标 `N/A`：
+
+- 算子设计-需求分析
+- 算子设计-方案实现
+- 通用算子代码开发全过程
+- 脱离 PTOAS 仓库的业务工程联调
diff --git a/.trae/skills/ptoas-usability-eval/references/metrics-05.md b/.trae/skills/ptoas-usability-eval/references/metrics-05.md
new file mode 100644
index 000000000..3b05aa815
--- /dev/null
+++ b/.trae/skills/ptoas-usability-eval/references/metrics-05.md
@@ -0,0 +1,82 @@
+# `05 特定 shape 性能优化` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP017`
+- `API / 接口`: `TP019-020`
+- `源码 & 示例类`: `TP035-036, TP039, TP044, TP046`
+- `工具`: `TP049, TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP040-041, TP054, TP061`
+
+这里只评估 PTOAS 对“固定 shape / 特定 shape 性能优化”的支撑能力。没有 benchmark baseline 或没有上板实测时，不要硬造性能结论。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`05` 场景通常至少需要：
+- `L1` 评文档、样例、入口
+- `L3` 评 compile-only 和工程编译
+- `L4` 才能评真实性能、精度一致性、性能提升
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能优化文档检索命中率 | 找到性能相关文档、样例、issue 模板所需轮次 | `README.md`, `docs/PTO_IR_manual.md`, `.github/ISSUE_TEMPLATE/performance_issue.yml`, `test/samples/FlashAttention/`, `GQA/`, `FFN/` | `L1-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 文档检索耗时 | 从开始检索到找到目标文档的时间 | 同上 | `L1-L4` | `<=2 分钟` 高分；`2-4` 次之；`4-6` 中；`6-8` 低；`>8` 最低 |
+
+## 易开发、易演进
+
+### 性能分析
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能数据采集耗时 | 获取 profile/日志/性能数据所需时间 | 用户 benchmark 脚本、sample、remote validation 日志 | `L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 性能报告完备度 | 报告是否包含关键指标、case、shape、参数、耗时 | `performance_issue.yml`、用户日志 | `L1`, `L4` | 数据完整齐全高分；`>=90%` 次之；`70%-89%` 中；`50%-69%` 低；`<50%` 最低 |
+
+### 优化实现
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 优化迭代次数 | 针对固定 shape 调整 pass / IR / sample 的迭代次数 | PR diff、真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 优化耗时 | 完成策略优化的总耗时 | 真实执行记录 | `L3-L4` | `<=30 分钟` 高分；`30-60` 次之；`60-120` 中；`120-180` 低；`>180` 最低 |
+| 优化成功率 | 优化任务成功率 | 真实执行记录 | `L3-L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 编译验证
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 编译报错排障效率 | 调优后重新编译 sample / validation 工程时，修复了几轮 | `cmake`, `ninja`, validation 日志 | `L3-L4` | 无报错高分；1 次修复次之；2-3 次中；4-5 次低；>5 次最低 |
+| 编译耗时 | 从开始编译到编译完成的总时间 | 同上 | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 编译成功率 | 最终编译是否成功 | 同上 | `L3-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 性能调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能提升达成率 | 达到预期性能提升目标的任务比例 | baseline + 实测性能日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 性能提升幅度 | 优化后相对 baseline 的提升幅度 | 同上 | `L4` | 提升 `>=50%` 高分；`30%-50%` 次之；`10%-30%` 中；`0%-10%` 低；无提升或劣化最低 |
+| 对标友商差距 | 优化后性能与友商的差距 | 用户提供对标数据 | `L4` | 超越高分；持平次之；差距 `<20%` 中；`20%-50%` 低；`>50%` 最低 |
+
+说明：`对标友商差距` 没有外部 benchmark 时直接记 `N/A`，因为它超出 PTOAS 仓库单独可证的边界。
+
+### 精度调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 精度验证工具获取耗时 | 获取 golden/compare/验证工具所需时间 | sample `golden.py`, `compare.py`, `generate_testcase.py` | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 精度验证运行成功次数 | 直到精度验证成功所需的尝试次数 | 真实执行记录 | `L3-L4` | 首次成功 `10`；2-3 次 `8`；4-5 次 `6`；6-7 次 `4`；>7 次或无法成功 `2` |
+| 精度一致性验证 | 优化后精度与优化前的一致性 | compare 结果、误差阈值 | `L4` | `100% 一致` 高分；误差 `<1e-5` 次之；`<1e-3` 中；`<1e-1` 低；明显差异最低 |
+| 用例回归通过率 | 原功能精度用例回归通过率 | 回归日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 默认样例
+
+优先选择：
+- `test/samples/FlashAttention/`
+- `test/samples/GQA/`
+- `test/samples/FFN/`
+- `test/samples/MatMul/`
diff --git a/.trae/skills/ptoas-usability-eval/references/metrics-06.md b/.trae/skills/ptoas-usability-eval/references/metrics-06.md
new file mode 100644
index 000000000..1e44532c0
--- /dev/null
+++ b/.trae/skills/ptoas-usability-eval/references/metrics-06.md
@@ -0,0 +1,84 @@
+# `06 泛化 shape 性能优化` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP017`
+- `API / 接口`: `TP019-020`
+- `源码 & 示例类`: `TP035-036, TP039, TP044, TP046-047`
+- `工具`: `TP049, TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP040-041, TP054, TP061`
+
+这里只评估 PTOAS 对“多 shape / dynamic shape / valid-shape 场景”的性能优化支撑能力。没有多 shape 基线矩阵时，不要硬造平均/最大收益。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`06` 场景通常至少需要：
+- `L1` 评文档、IR 语义、样例覆盖度
+- `L3` 评 compile-only、编译验证
+- `L4` 才能评多 shape 真实性能与精度结果
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能优化文档检索命中率 | 找到 dynamic/valid-shape、layout、性能相关文档和样例所需轮次 | `docs/PTO_IR_manual.md`, `README.md`, `test/samples/SetValidShape/`, `LayoutInference/`, `Partition5D/`, `planmemory/` | `L1-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 文档检索耗时 | 从开始检索到找到目标文档的时间 | 同上 | `L1-L4` | `<=2 分钟` 高分；`2-4` 次之；`4-6` 中；`6-8` 低；`>8` 最低 |
+
+## 易开发、易演进
+
+### 性能分析
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能数据采集耗时 | 获取多 shape profile/性能数据所需时间 | 用户 benchmark 脚本、validation 日志 | `L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 性能报告完备度 | 报告是否包含 shape 集合、关键指标、参数、耗时 | 用户日志、`performance_issue.yml` | `L1`, `L4` | 数据完整齐全高分；`>=90%` 次之；`70%-89%` 中；`50%-69%` 低；`<50%` 最低 |
+
+### 优化实现
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 平均优化迭代次数 | 多 shape 场景平均调整次数 | 真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 平均优化耗时 | 多 shape 场景平均完成策略优化的耗时 | 真实执行记录 | `L3-L4` | `<=30 分钟` 高分；`30-60` 次之；`60-120` 中；`120-180` 低；`>180` 最低 |
+| 优化成功率 | 多 shape 策略优化任务成功率 | 真实执行记录 | `L3-L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 编译验证
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 编译报错排障效率 | 多 shape 调优后重新编译 sample / validation 工程时，修复了几轮 | `cmake`, `ninja`, validation 日志 | `L3-L4` | 无报错高分；1 次修复次之；2-3 次中；4-5 次低；>5 次最低 |
+| 编译耗时 | 从开始编译到编译完成的总时间 | 同上 | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 编译成功率 | 最终编译是否成功 | 同上 | `L3-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 性能调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能提升达成率 | 达到预期性能提升目标的任务比例 | 多 shape baseline + 实测日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 平均性能提升幅度 | 多 shape 场景性能平均提升幅度 | 同上 | `L4` | 提升 `>=50%` 高分；`30%-50%` 次之；`10%-30%` 中；`0%-10%` 低；无提升或劣化最低 |
+| 最大性能提升幅度 | 提升最大的单个 shape 收益 | 同上 | `L4` | 提升 `>=60%` 高分；`40%-60%` 次之；`20%-40%` 中；`0%-20%` 低；无提升或劣化最低 |
+| 对标友商差距 | 优化后性能与友商的差距 | 用户提供对标数据 | `L4` | 超越高分；持平次之；差距 `<20%` 中；`20%-50%` 低；`>50%` 最低 |
+
+说明：`对标友商差距` 没有外部 benchmark 时直接记 `N/A`。
+
+### 精度调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 精度验证工具获取耗时 | 获取多 shape 精度验证工具所需时间 | `generate_testcase.py`, sample `golden.py`, `compare.py` | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 精度验证运行成功次数 | 直到精度验证成功所需的尝试次数 | 真实执行记录 | `L3-L4` | 首次成功 `10`；2-3 次 `8`；4-5 次 `6`；6-7 次 `4`；>7 次或无法成功 `2` |
+| 精度保持率 | 优化后精度与优化前的一致性 | compare 结果、误差阈值 | `L4` | `100% 一致` 高分；误差 `<1e-5` 次之；`<1e-3` 中；`<1e-1` 低；明显差异最低 |
+| 用例回归通过率 | 原功能精度用例回归通过率 | 回归日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 默认样例
+
+优先选择：
+- `test/samples/SetValidShape/`
+- `test/samples/LayoutInference/`
+- `test/samples/Partition5D/`
+- `test/samples/planmemory/`
+- 其他带 `valid_shape` / dynamic shape 的样例
diff --git a/.trae/skills/ptoas-usability-eval/references/scope.md b/.trae/skills/ptoas-usability-eval/references/scope.md
new file mode 100644
index 000000000..96e5cb004
--- /dev/null
+++ b/.trae/skills/ptoas-usability-eval/references/scope.md
@@ -0,0 +1,129 @@
+# PTOAS 评估范围映射
+
+## 六大场景映射
+
+| 场景 | 结论 | 处理方式 | PTOAS 中可量化的部分 | 默认不直接量化的部分 |
+| --- | --- | --- | --- | --- |
+| `01 算子复现部署` | 主评估场景 | 正常评分 | 构建、CLI、Python 绑定、sample、compile-only、board-validation | 无 |
+| `02 算子迁移部署` | 有限纳入 | 评“迁移支撑能力” | PTO IR 入口、样例/PyPTO 快照、compile-only/validation、迁移前后对照样例 | 业务框架集成、完整模型接线、仓外工程改造 |
+| `03 builtin 算子定制修改` | 默认不纳入 | 标 `N/A`，必要时只做差距说明 | 无固定模板 | builtin/业务算子定制主流程 |
+| `04 算子基本功能实现` | 次级支撑 | 只评 PTOAS 直接支撑的工程子链路 | 文档、样例、编译配置、工程编译、运行反馈、验证 | 完整需求分析、完整方案设计、通用算子研发全过程 |
+| `05 特定 shape 性能优化` | 条件纳入 | 评“特定 shape 性能优化支撑能力” | 性能文档、固定 shape 样例、性能数据获取入口、编译验证、精度/性能验证 | 没有 baseline 时的性能提升幅度、仓外友商对标 |
+| `06 泛化 shape 性能优化` | 条件纳入 | 评“多 shape / dynamic shape 支撑能力” | `valid_shape`/dynamic shape 文档、泛化样例、多 shape 验证链路 | 没有多 shape 基线矩阵时的平均/最大收益结论 |
+
+## 评估层级
+
+任何量化前都先声明层级：
+
+- `L1 文档审阅层`：只看仓库内容，不跑命令。
+- `L2 本地最小运行层`：当前机器已有 PTOAS 产物，可验证最小命令。
+- `L3 Linux compile-only 层`：Linux + CANN/bisheng + `PTO_ISA_ROOT`，不要求带卡。
+- `L4 NPU 上板层`：带卡 Linux、驱动、ACL、设备节点和用户权限齐全。
+
+评分规则：
+- 某层未覆盖，只能标 `未实测`。
+- 不得因为本机不是 Linux / 没有 `bisheng` / 没有 NPU 就对 PTOAS 本身扣分。
+- 文档是否清楚说明这些前置条件，才属于可评分项。
+
+## `02` 的适用边界
+
+PTOAS 可以支撑 `02`，但只能评“迁移支撑能力”，不能假装它已经覆盖完整业务迁移平台。
+
+可以评分的证据：
+- `docs/PTO_IR_manual.md`：IR 层级、tile/view/valid-shape 语义、Level-2/Level-3 入口
+- `test/samples/PyPTOIRParser/README.md`：来自 pypto `ir_parser` 的 vendored `.pto` 快照
+- `test/samples/*`：迁移后 PTO case、样例目录、`golden.py`/`compare.py`
+- `docs/no_npu_compile_only_guide_zh.md`、`runop.sh`、remote validation 脚本：迁移后 compile/validate 链路
+
+`02` 里这些指标只有在“有前后对照”时才能量化：
+- `tiling 迁移完备度`
+- `kernel 迁移完备度`
+- `tiling/kernel 代码修改率`
+- `功能失败率`
+- `性能劣化率`
+
+如果当前任务没有“迁移前/迁移后”对照 case：
+- 记 `未实测`，不要臆造百分比。
+- 若该项本质依赖仓外业务工程，且用户没有给材料，可记 `N/A` 并说明原因。
+
+## `04` 的适用边界
+
+`04` 只纳入这些与 PTOAS 仓库直接对应的子项：
+- 文档获取
+- 文档学习
+- 获取示例代码
+- 学习/理解示例代码
+- 运行示例代码
+- 编译配置
+- 算子工程编译
+- 功能调试
+- 精度调试中 repo 已有 compare/golden/validation 的部分
+
+默认排除：
+- 算子设计-需求分析
+- 算子设计-方案实现
+- 通用算子代码开发全过程
+- 脱离 PTOAS 仓库的业务工程联调
+
+## `05` 的适用边界
+
+PTOAS 可以支撑 `05`，但重点是“特定 shape 性能优化的仓内支撑能力”。
+
+可直接使用的仓内证据：
+- `docs/PTO_IR_manual.md`：Level-2/Level-3、layout、partition、reshape、valid-shape 等语义
+- `.github/ISSUE_TEMPLATE/performance_issue.yml`：性能问题收集模板
+- `test/samples/FlashAttention/`, `test/samples/GQA/`, `test/samples/FFN/`, `test/samples/MatMul/`：固定 shape 样例
+- `runop.sh`、compile-only 文档、remote validation 脚本：生成、编译、上板验证链路
+
+`05` 里这些项通常至少要到 `L4` 才能量化：
+- 性能数据采集耗时
+- 性能报告完备度
+- 优化迭代次数/耗时/成功率
+- 性能提升幅度
+- 精度一致性验证
+
+如果只有文档和样例，没有真实 benchmark/baseline：
+- 文档和入口可评分
+- 真实性能数字、友商对标、提升幅度一律 `未实测` 或 `N/A`
+
+## `06` 的适用边界
+
+PTOAS 可以支撑 `06`，但重点是“多 shape / dynamic shape / valid-shape 的泛化支撑能力”。
+
+可直接使用的仓内证据：
+- `docs/PTO_IR_manual.md`
+- `test/samples/SetValidShape/`
+- `test/samples/LayoutInference/`
+- `test/samples/Partition5D/`
+- `test/samples/planmemory/`
+- 其他带动态 shape / layout / partition / subview / reshape 的样例
+
+`06` 里这些项没有多 shape 基线矩阵时不能硬算：
+- 平均优化迭代次数
+- 平均优化耗时
+- 平均性能提升幅度
+- 最大性能提升幅度
+- 多 shape 精度保持率
+
+如果当前任务只看到 IR 设计与样例，没有多 shape 实测：
+- 文档、样例覆盖度可评分
+- 多 shape 性能/精度结果记 `未实测`
+
+## `未实测` 与 `N/A` 的使用规则
+
+记 `未实测`：
+- 仓库里有入口，但当前会话没有进入对应层级
+- 缺 Linux/CANN/NPU/baseline，导致只能停在文档或最小运行层
+- 缺迁移前后对照物，无法给出完成度/收益率
+
+记 `N/A`：
+- 指标本身超出 PTOAS 仓库边界
+- 用户要求的是仓外业务工程能力，当前仓库没有独立证据链
+- 友商对标、完整业务迁移、完整 builtin 定制等不是本 Skill 的默认量化对象
+
+## 使用原则
+
+- 如果用户没有特别说明，直接按 `01` 做主评估。
+- 如果用户要求顺带看 `02/04/05/06`，按本文件的边界补相应子集。
+- 可以做“支持度评分”，但不要把仓内文档/样例的存在，夸大成业务侧已经打通。
+- 能量化就量化；不能量化就明确说明为什么是 `未实测` 或 `N/A`。
diff --git a/.trae/skills/ptoas-usability-eval/references/scoring.md b/.trae/skills/ptoas-usability-eval/references/scoring.md
new file mode 100644
index 000000000..ba3d01d6d
--- /dev/null
+++ b/.trae/skills/ptoas-usability-eval/references/scoring.md
@@ -0,0 +1,148 @@
+# 总分汇总规则
+
+本文件定义 PTOAS 易用性评估的总分汇总方法，解决两个问题：
+- 单项指标混用 `10 分制` 和 `100 分制`
+- `未实测` / `N/A` 不能被误当成低分
+
+## 1. 基本原则
+
+- 单项展示时，保留用户原始分制。
+- 汇总总分时，再做统一归一化。
+- 场景分只基于本次选中的 `Core/Conditional Touch-Points` 或其 repo 级代理指标计算。
+- 默认输出两个总分：
+  - `总分（支撑）`
+  - `总分（实测）`
+
+## 2. 单项归一化
+
+把单项分数统一换算到 `100` 分制：
+
+- 原始 `10` 分制：`归一化分 = 原始分 * 10`
+- 原始 `100` 分制：`归一化分 = 原始分`
+
+示例：
+- `8/10 -> 80/100`
+- `60/100 -> 60/100`
+
+## 3. 特殊值处理
+
+- `未实测`：不计入任何总分分母
+- `N/A`：不计入任何总分分母
+- 如果某个场景下所有指标都是 `未实测/N/A`：
+  - 该场景分不输出数值
+  - 标记为 `本次无实测样本`
+
+## 4. 场景分
+
+先算场景分，再算总分。
+
+### 4.1 场景支撑分
+
+定义：该场景下所有“已评分”的指标，归一化后求平均。
+
+纳入范围：
+- 文档
+- 样例
+- 脚本
+- 配置
+- 已实测项
+
+排除范围：
+- `未实测`
+- `N/A`
+
+用途：衡量 PTOAS 仓库本身提供的支撑能力。
+
+### 4.2 场景实测分
+
+定义：该场景下所有“有真实执行证据”的指标，归一化后求平均。
+
+必须满足至少一种证据：
+- 真实命令执行
+- 真实编译/build
+- 真实 sample 运行
+- 真实 validation / compare / board 结果
+
+不纳入：
+- 纯文档发现性分
+- 纯 README/脚本存在性分
+- `未实测`
+- `N/A`
+
+用途：衡量当前会话里真正被跑通或被验证到的易用性。
+
+## 5. 默认场景权重
+
+如果用户没有单独指定权重，默认用：
+
+- `01`：`40%`
+- `02`：`15%`
+- `04`：`15%`
+- `05`：`15%`
+- `06`：`15%`
+
+说明：
+- `01` 是 PTOAS 的主评估场景，所以权重最高。
+- `02/04/05/06` 是补充场景，默认均分剩余权重。
+
+## 6. 权重重分配
+
+不要把没有参与本次评估的场景硬算进总分。
+
+### 6.1 用户只评部分场景
+
+如果本次只评了部分场景，例如只评 `01 + 04`：
+- 先取这两个场景的默认权重 `40` 和 `15`
+- 再重分配到 `100%`
+
+例：
+- `01` 新权重 = `40 / (40+15) = 72.73%`
+- `04` 新权重 = `15 / (40+15) = 27.27%`
+
+### 6.2 计算 `总分（支撑）`
+
+- 只保留“有场景支撑分”的场景
+- 对这些场景的默认权重重分配后加权平均
+
+### 6.3 计算 `总分（实测）`
+
+- 只保留“有场景实测分”的场景
+- 对这些场景的默认权重重分配后加权平均
+
+## 7. 输出要求
+
+建议固定输出以下内容：
+
+- `总分（支撑）`：`xx/100`
+- `总分（实测）`：`xx/100` 或 `本次无法计算`
+- `覆盖场景`：本次实际评了哪些场景
+- `覆盖层级`：`L1/L2/L3/L4` 到了哪一层
+- `实测覆盖说明`：哪些场景只有文档分，哪些场景有真实执行分
+
+## 8. 解释口径
+
+当两个总分差异较大时，优先按下面口径解释：
+
+- `总分（支撑）` 高、`总分（实测）` 低：
+  - 仓库文档/样例/脚本铺得比较全
+  - 但当前会话真实跑通度一般，或存在环境/样例摩擦
+
+- `总分（支撑）` 低、`总分（实测）` 高：
+  - 当前 case 可能能跑
+  - 但仓库的通用文档化、模板化、可发现性较弱
+
+- `总分（实测）` 显示为 `本次无法计算`：
+  - 说明本次基本停留在 `L1`，或者只有文档审阅，没有足够的真实执行证据
+
+## 9. 推荐展示格式
+
+```text
+总分（支撑）: 78.5/100
+总分（实测）: 66.4/100
+覆盖场景: 01, 02, 04, 05, 06
+覆盖层级: L1 + L2
+说明:
+- 01/04 同时形成支撑分和实测分
+- 02/05/06 当前主要形成文档/样例支撑分
+- L3/L4 未实测，不计入实测总分分母
+```
diff --git a/.trae/skills/ptoas-usability-eval/references/touchpoint-selection.md b/.trae/skills/ptoas-usability-eval/references/touchpoint-selection.md
new file mode 100644
index 000000000..d57a6d79e
--- /dev/null
+++ b/.trae/skills/ptoas-usability-eval/references/touchpoint-selection.md
@@ -0,0 +1,154 @@
+# PTOAS Touch-Point 选型
+
+本文件把用户提供的总触点池裁剪成适合 `hw-native-sys/PTOAS` 的 repo 级评估子集。
+
+## 1. 选型原则
+
+- PTOAS 是**编译器 / 工具链 / 样例仓库**，不是完整 CANN 产品矩阵，也不是官方镜像分发平台。
+- 默认优先评估这些触点：
+  - `资料/文档`
+  - `API/接口` 中与 `CLI / Python 绑定 / PTO IR 手册` 直接相关的子项
+  - `源码 & 示例类`
+  - `工具`
+  - `版本` 中 repo 内可自证的子项
+  - `运行反馈`
+- 对需要**产品级生态、仓外对标、跨硬件矩阵、发布渠道运营**的数据，默认不要硬打 repo 分，记 `N/A` 或只做差距说明。
+
+## 2. 默认纳入的 Core Touch-Points
+
+这些触点默认进入 PTOAS repo 级评分。
+
+### 2.1 资料/文档
+
+- `TP001` 检索命中成功率
+- `TP002` 文档跳转次数
+- `TP003` 多入口可达率
+- `TP004` 单次任务文档跳转浏览率
+- `TP005` 知识渐进式发布
+- `TP008` 文档结构风格一致率
+- `TP009` 概念跨文档冲突数
+- `TP011` 文档、版本时效一致性
+- `TP012` 内/外链有效率
+- `TP013` 文档错误点位密度
+- `TP016` 资料交付件完备率
+- `TP017` 文档场景/内容覆盖缺失率
+- `TP018` quick_start / sample 一次跑通率
+
+### 2.2 API / 接口
+
+这里只看 PTOAS repo 自己暴露的接口层：
+- `CLI`: `ptoas`, `ptobc`
+- `Python bindings`
+- `PTO IR` 公开手册/Op 语义
+
+默认纳入：
+- `TP019` 目标接口平均查找检索轮次
+- `TP020` 渐进式复杂披露覆盖度
+- `TP028` 平均入参数 / 参数复杂度
+- `TP032` 接口自解释读懂率
+
+### 2.3 源码 & 示例类
+
+- `TP034` 示例代码无修改一键编译运行成功率
+- `TP035` 示例检索命中成功率
+- `TP036` 样例覆盖度
+- `TP037` 最小功能实现 Demo 覆盖率
+- `TP038` 命令示例覆盖度
+- `TP039` API 调用样例覆盖率
+- `TP042` 样例代码编译语法错误检出率
+- `TP043` 样例使用废弃 / 过期 API 占比
+- `TP044` 业务代码直接复用改编比例
+- `TP045` 编程模型标准对齐率
+- `TP046` 关键链路显性化率
+- `TP047` 认知理解步数
+
+### 2.4 工具
+
+- `TP049` 首次安装部署一次性成功率
+- `TP051` 标准任务平均操作步骤数
+- `TP052` 功能 / 场景覆盖率
+
+### 2.5 版本
+
+只纳入 repo 内可通过 `README / CI / tag / branch / issue template` 自证的部分：
+- `TP053` 版本检索命中成功率
+- `TP058` 版本配套关系准确性
+
+### 2.6 运行反馈
+
+- `TP062` 报错携带环境 / 版本 / 上下文信息完整率
+- `TP063` 报错自带排障建议比例
+- `TP064` 无效冗余信息占比
+
+## 3. 条件纳入的 Conditional Touch-Points
+
+这些触点只有在用户明确要求，或者当前任务确实提供了对应证据时才纳入。
+
+### 3.1 文档 / API 条件项
+
+- `TP006` FAQ 命中率
+- `TP010` 接口文档模板一致率
+- `TP014` API 文档覆盖率
+- `TP015` 错误码文档化率
+- `TP033` N+2 小版本破坏性接口变更频次
+
+### 3.2 示例 / 性能高级项
+
+- `TP040` E2E 实战案例覆盖率
+- `TP041` 行业深度调优案例覆盖率
+
+### 3.3 版本 / 部署高级项
+
+- `TP054` 版本信息完备率
+- `TP057` 版本号规范准确率
+- `TP059` 版本部署命令数
+- `TP060` 开箱部署成功率
+- `TP061` 版本兼容性率
+
+说明：
+- `TP061` 在 PTOAS 里通常要到 `L4`，并且需要 A3/A5/不同硬件的实测证据。
+- `TP040/TP041` 在 PTOAS 里只有当 `FlashAttention/GQA/FFN` 这类样例被当作准业务案例使用时才适合纳入。
+
+## 4. 默认排除的 Excluded Touch-Points
+
+这些触点默认**不进入** PTOAS repo 级总分，除非用户明确要求做生态级差距研究。
+
+### 4.1 产品生态 / 友商对标类
+
+- `TP021` API 业务场景覆盖率
+- `TP022` 主流 AI 应用框架 API 支持覆盖率
+- `TP023` 主流 AI 框架 API 支持覆盖率
+- `TP024` API 主流生态调用一致性
+- `TP025` 原子 API 与标杆 API 数量对比一致性
+- `TP026` 迁移修改代码（CUDA -> AscendC）
+- `TP027` 原子 API 与标杆 API 行为对比一致性
+
+原因：这些指标要求的是**全产品生态**、**仓外框架集成**、**与 CUDA/CANN 大盘对比**，不是 PTOAS 仓库单独可证的事实。
+
+### 4.2 不适合 PTOAS repo 形态的项
+
+- `TP029` 错误返回一致率
+- `TP030` 最小可用代码行数
+- `TP055` 主流镜像仓支持下载覆盖度
+- `TP056` 典型部署模式支持覆盖度
+
+原因：
+- PTOAS 不是以统一 runtime C API 为主的库产品，`TP029/TP030` 不适合直接套。
+- PTOAS repo 不是镜像/安装包分发平台，`TP055/TP056` 默认不打 repo 分。
+
+## 5. 场景到 Touch-Point 的默认映射
+
+| 场景 | 默认 Core Touch-Points | 条件 Touch-Points |
+| --- | --- | --- |
+| `01 算子复现部署` | `TP001-005, TP008-018, TP034-035, TP038, TP042, TP044, TP049, TP051-053, TP058, TP062-064` | `TP006, TP054, TP057, TP059-061` |
+| `02 算子迁移部署` | `TP001-005, TP008-009, TP011, TP013, TP017, TP019-020, TP032, TP035-037, TP039, TP044, TP046-047, TP051-052, TP062-064` | `TP040-041, TP033, TP061` |
+| `04 算子基本功能实现` | `TP001-005, TP008-009, TP011, TP013, TP017-020, TP028, TP032, TP034-039, TP042-047, TP049, TP051-052, TP062-064` | `TP006, TP010, TP014-015, TP033` |
+| `05 特定 shape 性能优化` | `TP001-005, TP017, TP019-020, TP035-036, TP039, TP044, TP046, TP049, TP051-052, TP062-064` | `TP040-041, TP054, TP061` |
+| `06 泛化 shape 性能优化` | `TP001-005, TP017, TP019-020, TP035-036, TP039, TP044, TP046-047, TP049, TP051-052, TP062-064` | `TP040-041, TP054, TP061` |
+
+## 6. 使用要求
+
+- 每次正式评估前，先在输出里给出 `触点选择`。
+- 默认只打 `Core Touch-Points`。
+- `Conditional Touch-Points` 只有在证据存在时才纳入，并明确说明为什么本次纳入。
+- `Excluded Touch-Points` 不进入总分；如果用户追问，可以单独给差距分析，但不要混入 repo 级总分。
diff --git a/skills/ptoas-usability-eval/README.md b/skills/ptoas-usability-eval/README.md
new file mode 100644
index 000000000..3f8fd8545
--- /dev/null
+++ b/skills/ptoas-usability-eval/README.md
@@ -0,0 +1,33 @@
+# PTOAS Usability Eval Skill
+
+这是 PTOAS 仓库内的通用 Skill 源目录。
+
+支持的客户端入口：
+- Codex: `.codex/skills/ptoas-usability-eval/`
+- Cursor: `.cursor/skills/ptoas-usability-eval/`
+- Trae: `.trae/skills/ptoas-usability-eval/`
+- Claude Code: `.claude/skills/ptoas-usability-eval/`
+
+当前覆盖的评估场景：
+- `01 算子复现部署`
+- `02 算子迁移部署` 的 PTOAS 支撑子集
+- `04 算子基本功能实现` 的 PTOAS 工程子集
+- `05 特定 shape 性能优化` 的 PTOAS 支撑子集
+- `06 泛化 shape 性能优化` 的 PTOAS 支撑子集
+
+当前附带的汇总规则：
+- 原始指标保留 `10 分制 / 100 分制`
+- 汇总时统一归一到 `100` 分制
+- 默认输出 `总分（支撑）` 和 `总分（实测）`
+- `未实测/N/A` 不进入总分分母
+
+当前评估逻辑：
+- 先按 `touch-point` 体系选取适用于 PTOAS 的触点
+- 再按 `01/02/04/05/06` 场景评分
+- 默认只把适用的 `Core Touch-Points` 放进 repo 级总分
+
+约定：
+- `skills/ptoas-usability-eval/` 作为仓库内的通用主副本
+- 各客户端目录提供可直接发现的副本，便于不同工具开箱即用
+- 修改 Skill 内容时，应同步更新上述四个客户端目录
+- 对 `L3/L4` 依赖 Linux/CANN/NPU 的指标，未实测时必须标 `未实测`，不能因为当前机器缺环境直接给 PTOAS 低分
diff --git a/skills/ptoas-usability-eval/SKILL.md b/skills/ptoas-usability-eval/SKILL.md
new file mode 100644
index 000000000..24cc41525
--- /dev/null
+++ b/skills/ptoas-usability-eval/SKILL.md
@@ -0,0 +1,98 @@
+---
+name: ptoas-usability-eval
+description: Evaluate PTOAS repository usability across scene 01 as the primary template plus the PTOAS-supported subsets of scenes 02, 04, 05, and 06. Always classify the evaluation by environment layer first, use only repo-native docs/scripts/samples/CI as primary evidence, keep the user's mixed 10-point and 100-point scoring rules, compute normalized support and measured totals, and mark unsupported or untested dimensions as 未实测 or N/A.
+---
+
+# PTOAS Usability Eval
+
+当用户要评估 `hw-native-sys/PTOAS` 的易用性，或要按 `01/02/04/05/06` 给 PTOAS 打分时，使用这个 Skill。
+
+## 默认范围
+
+- `01 算子复现部署`：主评估场景，正常评分。
+- `02 算子迁移部署`：纳入，但只评 PTOAS 仓库能直接支撑的迁移入口、样例、IR/脚本、编译验证链路。
+- `04 算子基本功能实现`：纳入，但只评 PTOAS 直接覆盖的示例、编译、验证、反馈子链路。
+- `05 特定 shape 性能优化`：纳入，但只评 PTOAS 的文档、样例、性能数据获取入口、编译验证、精度/性能验证支撑能力。
+- `06 泛化 shape 性能优化`：纳入，但只评 PTOAS 的 dynamic/valid-shape、多 shape 样例与验证支撑能力。
+- `03 builtin 算子定制修改`：默认不纳入量化，标 `N/A`；必要时只做差距说明。
+
+先读 [references/touchpoint-selection.md](references/touchpoint-selection.md) 选定适用触点，再读 [references/scope.md](references/scope.md) 确认各场景的边界和 `未实测/N/A` 规则。
+
+## 先判层级
+
+开始评分前，必须先声明本次评估覆盖到哪一层。没有层级，不能直接混着打分。
+
+可选层级：
+- `L1 文档审阅层`：只看仓库文档、脚本、样例、CI，不做运行。
+- `L2 本地最小运行层`：当前机器已有 `ptoas` / `ptobc` / Python 绑定，可做最小命令验证。
+- `L3 Linux compile-only 层`：需要 Linux + CANN/bisheng + `PTO_ISA_ROOT`，不要求带卡。
+- `L4 NPU 上板层`：需要带卡 Linux、驱动、权限、`/dev/davinci*` 与对应用户组。
+
+约束：
+- 没进入某层，就把该层指标记为 `未实测`，不能因为当前机器缺环境就给 PTOAS 低分。
+- `bisheng` / CANN compile-only 一般属于 `L3`，不应在本地 Mac 上硬打低分。
+- 带卡运行、设备权限、驱动、ACL、用户组属于 `L4`。
+
+## 证据来源
+
+优先只用仓库内证据，不把仓外经验当成主证据。固定入口见 [references/evidence-checklist.md](references/evidence-checklist.md)。
+
+高优先级证据：
+- `README.md`
+- `docs/no_npu_compile_only_guide_zh.md`
+- `docs/PTO_IR_manual.md`
+- `test/samples/runop.sh`
+- `test/npu_validation/scripts/generate_testcase.py`
+- `test/npu_validation/scripts/run_remote_npu_validation.sh`
+- `test/samples/PyPTOIRParser/README.md`
+- `test/samples/FlashAttention/`, `test/samples/GQA/`, `test/samples/FFN/`
+- `test/samples/SetValidShape/`, `test/samples/LayoutInference/`, `test/samples/Partition5D/`, `test/samples/planmemory/`
+- `.github/workflows/ci.yml`
+- `.github/ISSUE_TEMPLATE/performance_issue.yml`
+
+## 工作流
+
+1. 先判断用户要的是 `01`、`02`、`04`、`05`、`06` 中哪些场景；未说明时默认 `01`。
+2. 再判断本次覆盖层级：`L1/L2/L3/L4`。输出中必须显式写出来。
+3. 先读 [references/touchpoint-selection.md](references/touchpoint-selection.md)，按场景选定本次的 `Core / Conditional / Excluded` 触点。
+4. 从仓库内收集证据，记录每次检索轮次、文档跳转次数、执行命令、耗时、成功/失败结果。
+5. `01` 场景读 [references/metrics-01.md](references/metrics-01.md)。
+6. `02` 场景读 [references/metrics-02.md](references/metrics-02.md)。
+7. `04` 场景读 [references/metrics-04.md](references/metrics-04.md)。
+8. `05` 场景读 [references/metrics-05.md](references/metrics-05.md)。
+9. `06` 场景读 [references/metrics-06.md](references/metrics-06.md)。
+10. 需要汇总总分时，读 [references/scoring.md](references/scoring.md)。
+11. 对每个指标都输出：原始观测值、评分、证据路径、说明。没有实测的数据不要猜，记为 `未实测` 或 `N/A`。
+12. 明确区分：
+    - PTOAS 仓库已提供的能力
+    - 外部前置条件，例如 LLVM、CANN、`pto-isa`、NPU、驱动/权限、业务 baseline
+13. 若文档描述与实际运行冲突，以实际命令结果为准，并指出冲突位置。
+14. 默认给两个总分：`总分（支撑）` 和 `总分（实测）`。如果用户只要分项，不强制输出总分。
+
+## 计量规则
+
+- 保留用户原始口径，不强行覆盖各指标的原始分制。
+- 但做总分汇总时，必须按 [references/scoring.md](references/scoring.md) 做归一化。
+- `检索轮次`：每次新的定向搜索或定位尝试算 1 轮。
+- `文档跳转次数`：命中首个目标文档后，每跨一个文档/README/脚本入口算 1 次。
+- `耗时`：尽量记录真实墙钟时间；拿不到就写 `未实测`，不要臆测。
+- `成功率`：只基于当前任务里真实执行或真实定位到的结果计算。
+- `未实测`：当前会话未覆盖到对应环境层级，或该层级前置条件不存在，或缺少前后对照 baseline。
+- `N/A`：只用于超出 PTOAS 能力边界，或当前任务明确不纳入本次评估范围的项。
+
+## 输出格式
+
+按下面顺序输出：
+
+1. `评估范围`
+2. `触点选择`
+3. `评估层级`
+4. `总分（支撑）`
+5. `总分（实测）`
+6. `分场景评分`
+7. `覆盖说明`
+8. `关键证据`
+9. `主要短板`
+10. `建议动作`
+
+如果用户只要简版结论，也要至少保留：场景归类、评估层级、总评、最低分项、证据路径。
diff --git a/skills/ptoas-usability-eval/agents/openai.yaml b/skills/ptoas-usability-eval/agents/openai.yaml
new file mode 100644
index 000000000..924e59e3f
--- /dev/null
+++ b/skills/ptoas-usability-eval/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "PTOAS Usability Eval"
+  short_description: "评估 PTOAS 在 01/02/04/05/06 场景下的易用性"
+  default_prompt: "Use $ptoas-usability-eval to evaluate this PTOAS repo for scene 01 operator reproduction/deployment and the PTOAS-supported subsets of scenes 02, 04, 05, and 06."
diff --git a/skills/ptoas-usability-eval/references/evidence-checklist.md b/skills/ptoas-usability-eval/references/evidence-checklist.md
new file mode 100644
index 000000000..89b6f1987
--- /dev/null
+++ b/skills/ptoas-usability-eval/references/evidence-checklist.md
@@ -0,0 +1,86 @@
+# 证据清单
+
+## 固定证据入口
+
+| 路径 | 主要用途 | 对应场景 | 层级 | 主要触点 |
+| --- | --- | --- | --- | --- |
+| `README.md` | 官方构建、环境变量、CLI、Python 绑定、sample 运行、compile-only/上板验证主入口 | `01`, `02`, `04`, `05`, `06` | `L1-L4` | `TP001-005, TP016-020, TP038, TP049, TP053, TP058` |
+| `docs/no_npu_compile_only_guide_zh.md` | 无卡 compile-only 流程、批量验证流程、`pto-isa`/CANN 依赖说明 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3` | `TP005, TP017-018, TP049, TP051-052, TP058-060, TP062-064` |
+| `docs/PTO_IR_manual.md` | IR 层级、tile/view/valid-shape、layout、dynamic shape、Level-2/3 语义 | `02`, `04`, `05`, `06` | `L1-L4` | `TP019-020, TP028, TP032, TP039, TP045-047` |
+| `test/samples/runop.sh` | 批量样例生成、`ptoas`/`ptobc` 运行、A3/A5 默认参数策略 | `01`, `02`, `04`, `05`, `06` | `L1-L4` | `TP018, TP034-039, TP049, TP051-052, TP062-064` |
+| `test/npu_validation/scripts/generate_testcase.py` | 从 `*-pto.cpp` 生成验证工程，观察 golden/compare/兼容层处理 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3`, `L4` | `TP037-039, TP045-047, TP049, TP052` |
+| `test/npu_validation/scripts/run_remote_npu_validation.sh` | compile-only / sim / npu 运行链路、日志格式、设备与 `pto-isa` 检查 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3`, `L4` | `TP049, TP051-052, TP058-060, TP062-064` |
+| `test/samples/PyPTOIRParser/README.md` | 来自 pypto `ir_parser` 的 vendored `.pto` 快照说明 | `02` | `L1` | `TP035-037, TP039, TP044, TP046-047` |
+| `test/samples/MatMul/` | README 直接引用的基准样例，适合作为 `01` 默认复现模板 | `01`, `04`, `05` | `L1-L4` | `TP018, TP034-039, TP042-047` |
+| `test/samples/FlashAttention/` | 特定 shape 性能样例 | `05` | `L1-L4` | `TP035-041, TP044, TP046` |
+| `test/samples/GQA/` | 特定 shape / attention 相关样例 | `05` | `L1-L4` | `TP035-041, TP044, TP046` |
+| `test/samples/FFN/` | 特定 shape / 算子组合样例 | `05` | `L1-L4` | `TP035-041, TP044, TP046` |
+| `test/samples/SetValidShape/` | dynamic/valid-shape 相关样例 | `06` | `L1-L4` | `TP035-039, TP044, TP046-047` |
+| `test/samples/LayoutInference/` | layout 推断相关样例 | `06` | `L1-L4` | `TP019-020, TP035-039, TP046-047` |
+| `test/samples/Partition5D/` | 多维 partition / shape 泛化相关样例 | `02`, `06` | `L1-L4` | `TP035-039, TP044, TP046-047, TP061` |
+| `test/samples/planmemory/` | alias/planmemory/shape 相关样例 | `06` | `L1-L4` | `TP035-039, TP044, TP046-047` |
+| `.github/workflows/ci.yml` | CI 中的 LLVM/PTOAS 构建、lit、sample test、remote validation 参考配置 | `01`, `02`, `04`, `05`, `06` | `L1`, `L3`, `L4` | `TP003, TP011, TP049, TP052-053, TP058, TP060-064` |
+| `.github/ISSUE_TEMPLATE/performance_issue.yml` | 性能问题受理模板，可用来评估性能数据/复现要求的完备性 | `05`, `06` | `L1` | `TP005, TP017, TP040-041, TP062-063` |
+
+说明：
+- 不要把当前分支不存在的样例 README 当成固定证据源。
+- 对 `02/05/06`，没有“前后对照基线”时，不要硬算迁移完备度或性能提升幅度。
+
+## 推荐检索顺序
+
+1. `README.md`
+2. `docs/no_npu_compile_only_guide_zh.md`
+3. `docs/PTO_IR_manual.md`
+4. `test/samples/MatMul/` 或用户指定样例目录
+5. `test/samples/PyPTOIRParser/`, `FlashAttention/`, `GQA/`, `FFN/`, `SetValidShape/`, `LayoutInference/`, `Partition5D/`, `planmemory/`
+6. `test/samples/runop.sh`
+7. `test/npu_validation/scripts/*.py` / `*.sh`
+8. `.github/workflows/ci.yml`
+9. `.github/ISSUE_TEMPLATE/performance_issue.yml`
+
+## 推荐检索命令
+
+```bash
+rg -n "构建|运行测试|compile-only|runop|generate_testcase|run_remote_npu_validation|level3" README.md docs test .github
+rg -n "valid_shape|layout|partition|reshape|dynamic shape|Level-2|Level-3" docs/PTO_IR_manual.md docs test
+rg -n "FlashAttention|GQA|FFN|MatMul|SetValidShape|LayoutInference|Partition5D|planmemory" test .github
+rg --files test/samples
+find test/samples -maxdepth 2 -type f \( -name '*.py' -o -name '*.pto' -o -name 'README.md' \)
+```
+
+## 迁移 / 性能场景的补充记录项
+
+如果在评 `02/05/06`，额外记录：
+- 是否存在迁移前/迁移后对照物
+- 是否存在性能 baseline
+- baseline 来源路径
+- 是否需要 NPU 实机
+- 当前停在哪一层
+- 哪些分数是实测，哪些是文档侧支撑分
+
+## 记录要求
+
+每个评分项至少要落这些证据字段：
+
+- `证据路径`
+- `检索/执行命令`
+- `检索轮次`
+- `文档跳转次数`
+- `评估层级`
+- `耗时`
+- `结果`
+- `评分`
+- `备注`
+
+## 默认样例
+
+若用户没有指定具体算子或样例，优先使用：
+
+- `test/samples/MatMul/tmatmulk.py`
+- `test/samples/MatMul/tmatmulk.pto`
+- `test/samples/Addc/addc.py`
+- `test/samples/PyPTOIRParser/`
+- `test/samples/FlashAttention/`
+- `test/samples/SetValidShape/`
+
+理由：这些路径要么被 `README.md` 直接引用，要么与迁移/性能/shape 泛化评估强相关，且当前主线可稳定找到。
diff --git a/skills/ptoas-usability-eval/references/metrics-01.md b/skills/ptoas-usability-eval/references/metrics-01.md
new file mode 100644
index 000000000..58bcc109d
--- /dev/null
+++ b/skills/ptoas-usability-eval/references/metrics-01.md
@@ -0,0 +1,119 @@
+# `01 算子复现部署` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP008-018`
+- `源码 & 示例类`: `TP034-035, TP038, TP042, TP044`
+- `工具`: `TP049, TP051-052`
+- `版本`: `TP053, TP058`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP006, TP054, TP057, TP059-061`
+
+默认把 PTOAS 看作“从样例或 `.pto` 输入出发，完成构建、编译、compile-only 或上板验证”的工具链仓库。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+在 `01` 场景里，必须先声明本次评估覆盖的层级：
+
+- `L1 文档审阅层`
+- `L2 本地最小运行层`
+- `L3 Linux compile-only 层`
+- `L4 NPU 上板层`
+
+没有进入对应层，就标 `未实测`，不要把环境缺失当成 PTOAS 负分。
+
+## 默认任务模板
+
+若用户没有指定具体 case，优先用 `test/samples/MatMul/` 作为复现模板：
+
+```bash
+python3 test/samples/MatMul/tmatmulk.py > /tmp/tmatmulk.pto
+./build/tools/ptoas/ptoas /tmp/tmatmulk.pto -o /tmp/tmatmulk.cpp
+```
+
+需要无卡 compile-only 时，继续参考：
+
+```bash
+python3 test/npu_validation/scripts/generate_testcase.py \
+  --input /tmp/tmatmulk.cpp \
+  --run-mode npu \
+  --soc-version Ascend910
+```
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 检索命中成功率 | 统计找到“构建 + sample 运行 + compile-only/上板验证”入口所需检索轮次 | `README.md`, `docs/no_npu_compile_only_guide_zh.md` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+| 文档检索耗时 | 从开始找文档到定位到正确路径的时间 | 同上 | `L1-L4` | `2 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 文档获取成功率 | 目标文档是否都能在仓库内找到 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+### 文档学习
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 文档错误点位密度 | 按文档执行时，检查命令、路径、版本、链接、说明是否错误 | `README.md`, `docs/no_npu_compile_only_guide_zh.md`, `.github/workflows/ci.yml` | `L1-L4` | 零错误 `100`；少量小错 `80`；一般错误 `60`；明显错误 `40`；严重不可用 `20` |
+| 文档跳转次数 | 从首个命中文档到凑齐完整执行路径，跨文档跳转的次数 | `README.md -> docs/... -> test/samples/...` | `L1-L4` | 1 次 `100`；2 次 `80`；3 次 `60`；4-5 次 `40`；>5 次 `20` |
+| 内容覆盖缺失率 | 是否清楚区分本地运行、Linux compile-only、带卡上板等层级前置条件 | `README.md`, `docs/...`, `.github/workflows/ci.yml` | `L1-L4` | 无缺失 `100`；`<=5%` `80`；`5%-15%` `60`；`15%-30%` `40`；`>30%` `20` |
+| 文档学习耗时 | 从开始读到能给出执行方案的时间 | 同上 | `L1-L4` | `5 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 通过文档学习检索成功率 | 需要通过文档解决的问题里，有多少真正被文档回答 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+## 易部署
+
+### 环境下载
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 环境获取场景覆盖率 | 看仓库是否说明源码构建、无卡 compile-only、上板验证所需环境 | `README.md`, `docs/no_npu_compile_only_guide_zh.md` | `L1-L4` | `100%=10`；`80%-99%=8`；`60%-79%=6`；`40%-59%=4`；`<40%=2` |
+| 环境下载耗时 | 真实下载 LLVM/CANN/Python 依赖/`pto-isa` 的时间 | 真实执行记录 | `L3-L4` | `<=5 分钟=10`；`5-7=8`；`7-9=6`；`9-11=4`；`>11=2` |
+| 环境下载成功率 | 下载步骤是否一次完成 | 真实执行记录 | `L3-L4` | `100%=10`，按比例计算 |
+
+说明：如果当前任务没有真的在 Linux/CANN 环境里下载依赖，后两项写 `未实测`。
+
+### 环境安装
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 软硬件配套兼容率 | 检查仓库是否明确 LLVM 版本、Python 包版本、CANN / `pto-isa` 依赖关系 | `README.md`, `docs/no_npu_compile_only_guide_zh.md`, `ci.yml` | `L1-L4` | `100%=10`；`80%-99%=8`；`60%-79%=6`；`40%-59%=4`；`<40%=2` |
+| 部署时长 | 从开始执行安装到可运行 `ptoas`/Python 绑定的时间 | 真实执行记录 | `L2-L4` | `<=5 分钟=10`；`5-7=8`；`7-9=6`；`9-11=4`；`>11=2` |
+| 操作步骤数 | 完成安装所需命令/步骤数量 | `README.md` 构建步骤 | `L1-L4` | `<=8 步=10`；`9-10=8`；`11-12=6`；`13-14=4`；`>14=2` |
+| 环境安装成功率 | 是否能完成 LLVM + PTOAS 构建与安装 | 真实执行记录 | `L2-L4` | `100%=10`，按比例计算 |
+
+### 环境校验
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 环境安装后校验成功率 | 是否有明确校验动作，例如 `ptoas --version`、Python import、sample compile | `README.md`, `ci.yml` | `L2-L4` | `100%=10`，按比例计算 |
+
+推荐最小校验命令：
+
+```bash
+./build/tools/ptoas/ptoas --version
+python3 -c "from mlir.dialects import pto; print('ok')"
+```
+
+## 易开发、易演进
+
+### 获取示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 检索命中成功率 | 统计定位到默认样例目录所需轮次 | `test/samples/MatMul/`, `test/samples/Addc/`, `README.md` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+
+### 运行示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 示例代码运行耗时 | 从运行 sample 到拿到 `.pto` / `.cpp` / compile-only 结果的时间 | `README.md`, `test/samples/MatMul/` | `L2-L4` | `<=2 分钟=10`；`2-4=8`；`4-6=6`；`6-8=4`；`>8=2` |
+| 示例代码运行成功率 | `py -> .pto -> .cpp` 或 compile-only / validation 是否成功 | 同上 | `L2-L4` | `100%=10`，按比例计算 |
+
+## 何时记 `未实测` / `N/A`
+
+- `未实测`：当前任务没有进入对应环境层级，例如在本地 Mac 上没有 Linux/CANN/bisheng，却要评价 compile-only。
+- `N/A`：该项超出 PTOAS 能力边界，或本次任务明确不纳入该项。
+
+不要把二者混用。
diff --git a/skills/ptoas-usability-eval/references/metrics-02.md b/skills/ptoas-usability-eval/references/metrics-02.md
new file mode 100644
index 000000000..8ad84dbf6
--- /dev/null
+++ b/skills/ptoas-usability-eval/references/metrics-02.md
@@ -0,0 +1,77 @@
+# `02 算子迁移部署` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP008-009, TP011, TP013, TP017`
+- `API / 接口`: `TP019-020, TP032`
+- `源码 & 示例类`: `TP035-037, TP039, TP044, TP046-047`
+- `工具`: `TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP040-041, TP033, TP061`
+
+这里只评估 PTOAS 仓库对“迁移到 PTO IR / PTOAS 工具链”的支撑能力，不把 PTOAS 包装成完整业务算子迁移平台。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`02` 场景同样先声明层级：
+
+- `L1 文档审阅层`
+- `L2 本地最小运行层`
+- `L3 Linux compile-only 层`
+- `L4 NPU 上板层`
+
+没有进入对应层，就标 `未实测`。
+
+## 共享易学习项
+
+`02` 的 `文档获取` / `文档学习` 默认复用 [metrics-01.md](metrics-01.md) 中对应规则；只是目标从“复现部署”改成“找到迁移入口、IR 语义、样例和验证链路”。
+
+推荐优先证据：
+- `docs/PTO_IR_manual.md`
+- `test/samples/PyPTOIRParser/README.md`
+- `README.md`
+- `docs/no_npu_compile_only_guide_zh.md`
+
+## 易迁移
+
+### 算子迁移
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| tiling 迁移完备度 | 统计迁移前定义的 tiling 结构中，已成功落到 PTO IR / sample / generated testcase 的比例 | `docs/PTO_IR_manual.md`, `test/samples/*`, 用户提供的前后对照物 | `L1-L4` | `100%=10`；`80%=8`；`60%=6`；`40%=4`；`20%=2` |
+| kernel 迁移完备度 | 统计迁移前 kernel 逻辑中，已能由 PTO case / sample / generated testcase 覆盖的比例 | 同上 | `L1-L4` | `100%=10`；`80%=8`；`60%=6`；`40%=4`；`20%=2` |
+| 算子功能失败率 | 迁移后 compile-only / validation / board case 失败比例 | `runop.sh`, `generate_testcase.py`, `run_remote_npu_validation.sh` | `L3-L4` | `0% 失败=10`；`10%=8`；`20%=6`；`30%=4`；`40%=2` |
+| 算子性能劣化率 | 迁移后相对迁移前 baseline 的性能增幅 | 用户 baseline、`performance_issue.yml`、实测日志 | `L4` | 劣化 `<5%=10`；`10%=8`；`20%=6`；`30%=4`；`40%=2` |
+| tiling 代码修改率 | 迁移时 tiling 相关代码修改行数 / 总行数 | 用户对照 case、PR diff | `L1-L4` | `0%-5%` 高分；`5%-15%` 次高；`15%-25%` 中；`25%-35%` 低；`>35%` 最低 |
+| kernel 代码修改率 | 迁移时 kernel 相关代码修改行数 / 总行数 | 用户对照 case、PR diff | `L1-L4` | `0%-5%` 高分；`5%-15%` 次高；`15%-25%` 中；`25%-35%` 低；`>35%` 最低 |
+| 算子迁移总耗时 | 从开始迁移到迁移完成，不含最终验证环节 | 真实执行记录 | `L2-L4` | `<=10 分钟` 高分；`10-20` 次之；`20-30` 中；`30-60` 低；`>60` 最低 |
+| 算子迁移成功率 | 迁移任务成功率 | 真实执行记录 | `L2-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 在 PTOAS 中如何落地这些指标
+
+### 可直接量化的前提
+
+只有当前任务同时具备以下材料时，才量化迁移完备度/修改率/失败率：
+- 迁移前输入：上游 IR、旧 kernel、旧 tiling，至少一种
+- 迁移后输入：PTO `.pto`、sample、generated testcase，至少一种
+- 对应验证链路：compile-only 或 board validation
+
+### 没有对照物时怎么办
+
+- 只有仓库文档和样例，没有迁移前材料：
+  - 可以评“入口是否清晰”“样例/脚本是否齐全”
+  - 不能给出完备度/修改率/性能劣化率，记 `未实测`
+- 指标本身依赖仓外业务工程，且用户没给材料：
+  - 记 `N/A`
+
+## 推荐默认证据路径
+
+- `docs/PTO_IR_manual.md`
+- `test/samples/PyPTOIRParser/README.md`
+- `test/samples/*`
+- `docs/no_npu_compile_only_guide_zh.md`
+- `test/samples/runop.sh`
+- `test/npu_validation/scripts/generate_testcase.py`
+- `test/npu_validation/scripts/run_remote_npu_validation.sh`
diff --git a/skills/ptoas-usability-eval/references/metrics-04.md b/skills/ptoas-usability-eval/references/metrics-04.md
new file mode 100644
index 000000000..d347924a6
--- /dev/null
+++ b/skills/ptoas-usability-eval/references/metrics-04.md
@@ -0,0 +1,116 @@
+# `04 算子基本功能实现` 的 PTOAS 子集指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP008-009, TP011, TP013, TP017-018`
+- `API / 接口`: `TP019-020, TP028, TP032`
+- `源码 & 示例类`: `TP034-039, TP042-047`
+- `工具`: `TP049, TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP006, TP010, TP014-015, TP033`
+
+这里只评估 PTOAS 真正覆盖到的“示例 / 编译 / 验证 / 反馈”链路，不把 PTOAS 当成完整算子研发平台。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`04` 子集同样先声明层级：
+
+- `L1 文档审阅层`
+- `L2 本地最小运行层`
+- `L3 Linux compile-only 层`
+- `L4 NPU 上板层`
+
+未进入对应层级，只能标 `未实测`。
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 检索命中成功率 | 找到目标样例、相关 CLI、验证脚本所需轮次 | `README.md`, `test/samples/`, `test/npu_validation/scripts/` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+| 文档检索耗时 | 从开始查到定位到目标入口的时间 | 同上 | `L1-L4` | `2 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 文档获取成功率 | 所需文档/脚本/样例是否都能在仓内找到 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+### 文档学习
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 文档错误点位密度 | 样例说明、命令、路径、环境前置条件是否准确 | `README.md`, sample README, `runop.sh`, `ci.yml` | `L1-L4` | 零错误 `100`；少量小错 `80`；一般错误 `60`；明显错误 `40`；严重不可用 `20` |
+| 文档跳转次数 | 为理解 sample 到 compile/validation 链路所需跳转次数 | 同上 | `L1-L4` | 1 次 `100`；2 次 `80`；3 次 `60`；4-5 次 `40`；>5 次 `20` |
+| 内容覆盖缺失率 | 样例定位、编译、验证、环境前置条件说明是否缺失 | 同上 | `L1-L4` | 无缺失 `100`；`<=5%` `80`；`5%-15%` `60`；`15%-30%` `40`；`>30%` `20` |
+| 文档学习耗时 | 从开始看文档到能解释执行路径的时间 | 同上 | `L1-L4` | `5 分钟=10`；之后每增加 `1` 分钟扣 `1` 分 |
+| 通过文档学习检索成功率 | 依赖文档回答的问题是否被解决 | 同上 | `L1-L4` | `100%=10`，按比例计算 |
+
+## 易开发、易演进
+
+### 获取示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 目标示例定位命中成功率 | 找到适合作为基本功能实现基线的 sample 或 `.pto` 所需轮次 | `test/samples/MatMul/`, `test/samples/Addc/`, `test/samples/PyPTOIRParser/` | `L1-L4` | 1 次 `10`；2 次 `8`；3 次 `6`；4-5 次 `4`；>5 次 `2` |
+
+### 学习/理解示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 样例场景覆盖度 | 样例是否覆盖目标算子的输入、输出、golden/compare、compile/validation 场景 | 选定样例目录中的 `.py` / `.pto` / `npu_validation/` | `L1-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 样例学习分析 Token 数 | 优先使用平台可见的 AI token 统计；没有统计就写 `未量化` | 同上 | `L1-L4` | `<=500` 高分；`500-1000` 次高；`1000-2000` 中；`2000-3000` 低；`>3000` 最低 |
+| 示例理解耗时 | 从首次打开样例到能讲清输入、生成物、验证链路的时间 | 同上 | `L1-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-15` 中；`15-20` 低；`>20` 最低 |
+
+说明：如果运行环境拿不到 token 统计，第二项保留原值 `未量化`，不要编造 token 数。
+
+### 运行示例代码
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 运行成功率 | sample 首次执行是否能生成 `.pto` / `.cpp` / compile-only 验证工程 | `README.md`, `test/samples/runop.sh`, sample 目录 | `L2-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 示例代码运行耗时 | 从开始运行到 sample 结束的时间 | 同上 | `L2-L4` | `<=2 分钟` 高分；`2-4` 次之；`4-6` 中；`6-8` 低；`>8` 最低 |
+
+## 算子编译
+
+### 编译配置
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 新增/修改配置行数 | 按仓库已有说明运行 sample / validation 时，需要额外改多少配置行 | `README.md`, `docs/no_npu_compile_only_guide_zh.md`, `ci.yml` | `L1-L4` | `<5 行=100`；`<10=80`；`<15=60`；`<20=40`；`>20=20` |
+
+记录时只统计“文档外的额外修改”。按 README 就能跑通则记 `0` 行。
+
+### 算子工程编译
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 需要理解的宏/函数个数 | 为改通当前 sample / validation 链路，必须额外读懂多少宏/函数 | `runop.sh`, `generate_testcase.py`, `run_remote_npu_validation.sh`, sample CMake | `L1-L4` | `2 个=10`；`4 个=8`；`6 个=6`；`8 个=4`；`>10 个=2` |
+| 编译报错排障效率 | 从 sample / validation 工程编译到成功，中间修复了几轮 | `ninja`, `cmake --build`, validation 日志 | `L3-L4` | 无报错高分；1 次修复次之；2-3 次中；4-5 次低；>5 次最低 |
+| 编译耗时 | 开始编译到编译完成的总时间 | 同上 | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 编译成功率 | 最终编译是否成功，以及首次是否成功 | 同上 | `L3-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 功能调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 报错携带环境/版本/上下文信息完整率 | `ptoas` / validation 脚本报错时，是否包含 stage、case、路径、依赖、设备、soc/version 等信息 | `run_remote_npu_validation.sh`, sample/CI 日志 | `L2-L4` | 信息完整 `100`；`>=90%` `80`；`70%-89%` `60`；`50%-69%` `40`；`<50%` `20` |
+| 报错自带排障建议比例 | 报错是否已经给出下一步可排查方向 | 同上 | `L2-L4` | 全部带建议 `100`；`>=90%` `80`；`70%-89%` `60`；`50%-69%` `40`；`<50%` `20` |
+| 无效冗余信息占比 | 日志是否大量充斥与当前失败无关的信息 | 同上 | `L2-L4` | 无冗余 `100`；`<=5%` `80`；`5%-15%` `60`；`15%-30%` `40`；`>30%` `20` |
+| 功能调试耗时 | 从第一次失败到定位根因或跑通的时间 | 同上 | `L2-L4` | `<=10 分钟` 高分；`10-20` 次之；`20-30` 中；`30-60` 低；`>60` 最低 |
+| 功能调试成功率 | 当前目标问题是否最终解决 | 同上 | `L2-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 精度调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 精度数据获取耗时 | 获取 golden/output/compare 报告所需时间 | `generate_testcase.py`, sample `golden.py`, `compare.py` | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 定位分析次数 | 从发现精度问题到定位根因的迭代次数 | 真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 代码修改/迭代循环 | 精度修复迭代次数 | PR diff、真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+
+## 默认排除项
+
+这些在 PTOAS 仓库里默认不打分，直接标 `N/A`：
+
+- 算子设计-需求分析
+- 算子设计-方案实现
+- 通用算子代码开发全过程
+- 脱离 PTOAS 仓库的业务工程联调
diff --git a/skills/ptoas-usability-eval/references/metrics-05.md b/skills/ptoas-usability-eval/references/metrics-05.md
new file mode 100644
index 000000000..3b05aa815
--- /dev/null
+++ b/skills/ptoas-usability-eval/references/metrics-05.md
@@ -0,0 +1,82 @@
+# `05 特定 shape 性能优化` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP017`
+- `API / 接口`: `TP019-020`
+- `源码 & 示例类`: `TP035-036, TP039, TP044, TP046`
+- `工具`: `TP049, TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP040-041, TP054, TP061`
+
+这里只评估 PTOAS 对“固定 shape / 特定 shape 性能优化”的支撑能力。没有 benchmark baseline 或没有上板实测时，不要硬造性能结论。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`05` 场景通常至少需要：
+- `L1` 评文档、样例、入口
+- `L3` 评 compile-only 和工程编译
+- `L4` 才能评真实性能、精度一致性、性能提升
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能优化文档检索命中率 | 找到性能相关文档、样例、issue 模板所需轮次 | `README.md`, `docs/PTO_IR_manual.md`, `.github/ISSUE_TEMPLATE/performance_issue.yml`, `test/samples/FlashAttention/`, `GQA/`, `FFN/` | `L1-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 文档检索耗时 | 从开始检索到找到目标文档的时间 | 同上 | `L1-L4` | `<=2 分钟` 高分；`2-4` 次之；`4-6` 中；`6-8` 低；`>8` 最低 |
+
+## 易开发、易演进
+
+### 性能分析
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能数据采集耗时 | 获取 profile/日志/性能数据所需时间 | 用户 benchmark 脚本、sample、remote validation 日志 | `L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 性能报告完备度 | 报告是否包含关键指标、case、shape、参数、耗时 | `performance_issue.yml`、用户日志 | `L1`, `L4` | 数据完整齐全高分；`>=90%` 次之；`70%-89%` 中；`50%-69%` 低；`<50%` 最低 |
+
+### 优化实现
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 优化迭代次数 | 针对固定 shape 调整 pass / IR / sample 的迭代次数 | PR diff、真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 优化耗时 | 完成策略优化的总耗时 | 真实执行记录 | `L3-L4` | `<=30 分钟` 高分；`30-60` 次之；`60-120` 中；`120-180` 低；`>180` 最低 |
+| 优化成功率 | 优化任务成功率 | 真实执行记录 | `L3-L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 编译验证
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 编译报错排障效率 | 调优后重新编译 sample / validation 工程时，修复了几轮 | `cmake`, `ninja`, validation 日志 | `L3-L4` | 无报错高分；1 次修复次之；2-3 次中；4-5 次低；>5 次最低 |
+| 编译耗时 | 从开始编译到编译完成的总时间 | 同上 | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 编译成功率 | 最终编译是否成功 | 同上 | `L3-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 性能调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能提升达成率 | 达到预期性能提升目标的任务比例 | baseline + 实测性能日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 性能提升幅度 | 优化后相对 baseline 的提升幅度 | 同上 | `L4` | 提升 `>=50%` 高分；`30%-50%` 次之；`10%-30%` 中；`0%-10%` 低；无提升或劣化最低 |
+| 对标友商差距 | 优化后性能与友商的差距 | 用户提供对标数据 | `L4` | 超越高分；持平次之；差距 `<20%` 中；`20%-50%` 低；`>50%` 最低 |
+
+说明：`对标友商差距` 没有外部 benchmark 时直接记 `N/A`，因为它超出 PTOAS 仓库单独可证的边界。
+
+### 精度调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 精度验证工具获取耗时 | 获取 golden/compare/验证工具所需时间 | sample `golden.py`, `compare.py`, `generate_testcase.py` | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 精度验证运行成功次数 | 直到精度验证成功所需的尝试次数 | 真实执行记录 | `L3-L4` | 首次成功 `10`；2-3 次 `8`；4-5 次 `6`；6-7 次 `4`；>7 次或无法成功 `2` |
+| 精度一致性验证 | 优化后精度与优化前的一致性 | compare 结果、误差阈值 | `L4` | `100% 一致` 高分；误差 `<1e-5` 次之；`<1e-3` 中；`<1e-1` 低；明显差异最低 |
+| 用例回归通过率 | 原功能精度用例回归通过率 | 回归日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 默认样例
+
+优先选择：
+- `test/samples/FlashAttention/`
+- `test/samples/GQA/`
+- `test/samples/FFN/`
+- `test/samples/MatMul/`
diff --git a/skills/ptoas-usability-eval/references/metrics-06.md b/skills/ptoas-usability-eval/references/metrics-06.md
new file mode 100644
index 000000000..1e44532c0
--- /dev/null
+++ b/skills/ptoas-usability-eval/references/metrics-06.md
@@ -0,0 +1,84 @@
+# `06 泛化 shape 性能优化` 指标
+
+## 本场景默认选用触点
+
+- `资料/文档`: `TP001-005, TP017`
+- `API / 接口`: `TP019-020`
+- `源码 & 示例类`: `TP035-036, TP039, TP044, TP046-047`
+- `工具`: `TP049, TP051-052`
+- `运行反馈`: `TP062-064`
+- `Conditional`: `TP040-041, TP054, TP061`
+
+这里只评估 PTOAS 对“多 shape / dynamic shape / valid-shape 场景”的性能优化支撑能力。没有多 shape 基线矩阵时，不要硬造平均/最大收益。
+
+说明：保留用户原始口径，`10 分制` 与 `100 分制` 混用，不强行归一。
+
+## 先声明层级
+
+`06` 场景通常至少需要：
+- `L1` 评文档、IR 语义、样例覆盖度
+- `L3` 评 compile-only、编译验证
+- `L4` 才能评多 shape 真实性能与精度结果
+
+## 易学习
+
+### 文档获取
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能优化文档检索命中率 | 找到 dynamic/valid-shape、layout、性能相关文档和样例所需轮次 | `docs/PTO_IR_manual.md`, `README.md`, `test/samples/SetValidShape/`, `LayoutInference/`, `Partition5D/`, `planmemory/` | `L1-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 文档检索耗时 | 从开始检索到找到目标文档的时间 | 同上 | `L1-L4` | `<=2 分钟` 高分；`2-4` 次之；`4-6` 中；`6-8` 低；`>8` 最低 |
+
+## 易开发、易演进
+
+### 性能分析
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能数据采集耗时 | 获取多 shape profile/性能数据所需时间 | 用户 benchmark 脚本、validation 日志 | `L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 性能报告完备度 | 报告是否包含 shape 集合、关键指标、参数、耗时 | 用户日志、`performance_issue.yml` | `L1`, `L4` | 数据完整齐全高分；`>=90%` 次之；`70%-89%` 中；`50%-69%` 低；`<50%` 最低 |
+
+### 优化实现
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 平均优化迭代次数 | 多 shape 场景平均调整次数 | 真实执行记录 | `L3-L4` | 1 次高分；2 次次之；3 次中；4-5 次低；>5 次最低 |
+| 平均优化耗时 | 多 shape 场景平均完成策略优化的耗时 | 真实执行记录 | `L3-L4` | `<=30 分钟` 高分；`30-60` 次之；`60-120` 中；`120-180` 低；`>180` 最低 |
+| 优化成功率 | 多 shape 策略优化任务成功率 | 真实执行记录 | `L3-L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 编译验证
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 编译报错排障效率 | 多 shape 调优后重新编译 sample / validation 工程时，修复了几轮 | `cmake`, `ninja`, validation 日志 | `L3-L4` | 无报错高分；1 次修复次之；2-3 次中；4-5 次低；>5 次最低 |
+| 编译耗时 | 从开始编译到编译完成的总时间 | 同上 | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 编译成功率 | 最终编译是否成功 | 同上 | `L3-L4` | `100%` 高分；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+### 性能调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 性能提升达成率 | 达到预期性能提升目标的任务比例 | 多 shape baseline + 实测日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+| 平均性能提升幅度 | 多 shape 场景性能平均提升幅度 | 同上 | `L4` | 提升 `>=50%` 高分；`30%-50%` 次之；`10%-30%` 中；`0%-10%` 低；无提升或劣化最低 |
+| 最大性能提升幅度 | 提升最大的单个 shape 收益 | 同上 | `L4` | 提升 `>=60%` 高分；`40%-60%` 次之；`20%-40%` 中；`0%-20%` 低；无提升或劣化最低 |
+| 对标友商差距 | 优化后性能与友商的差距 | 用户提供对标数据 | `L4` | 超越高分；持平次之；差距 `<20%` 中；`20%-50%` 低；`>50%` 最低 |
+
+说明：`对标友商差距` 没有外部 benchmark 时直接记 `N/A`。
+
+### 精度调试
+
+| 指标 | 在 PTOAS 中怎么测 | 主要证据 | 可评分层级 | 打分规则 |
+| --- | --- | --- | --- | --- |
+| 精度验证工具获取耗时 | 获取多 shape 精度验证工具所需时间 | `generate_testcase.py`, sample `golden.py`, `compare.py` | `L3-L4` | `<=5 分钟` 高分；`5-10` 次之；`10-20` 中；`20-30` 低；`>30` 最低 |
+| 精度验证运行成功次数 | 直到精度验证成功所需的尝试次数 | 真实执行记录 | `L3-L4` | 首次成功 `10`；2-3 次 `8`；4-5 次 `6`；6-7 次 `4`；>7 次或无法成功 `2` |
+| 精度保持率 | 优化后精度与优化前的一致性 | compare 结果、误差阈值 | `L4` | `100% 一致` 高分；误差 `<1e-5` 次之；`<1e-3` 中；`<1e-1` 低；明显差异最低 |
+| 用例回归通过率 | 原功能精度用例回归通过率 | 回归日志 | `L4` | `100%=10`；`80%-99%` 次之；`60%-79%` 中；`40%-59%` 低；`<40%` 最低 |
+
+## 默认样例
+
+优先选择：
+- `test/samples/SetValidShape/`
+- `test/samples/LayoutInference/`
+- `test/samples/Partition5D/`
+- `test/samples/planmemory/`
+- 其他带 `valid_shape` / dynamic shape 的样例
diff --git a/skills/ptoas-usability-eval/references/scope.md b/skills/ptoas-usability-eval/references/scope.md
new file mode 100644
index 000000000..96e5cb004
--- /dev/null
+++ b/skills/ptoas-usability-eval/references/scope.md
@@ -0,0 +1,129 @@
+# PTOAS 评估范围映射
+
+## 六大场景映射
+
+| 场景 | 结论 | 处理方式 | PTOAS 中可量化的部分 | 默认不直接量化的部分 |
+| --- | --- | --- | --- | --- |
+| `01 算子复现部署` | 主评估场景 | 正常评分 | 构建、CLI、Python 绑定、sample、compile-only、board-validation | 无 |
+| `02 算子迁移部署` | 有限纳入 | 评“迁移支撑能力” | PTO IR 入口、样例/PyPTO 快照、compile-only/validation、迁移前后对照样例 | 业务框架集成、完整模型接线、仓外工程改造 |
+| `03 builtin 算子定制修改` | 默认不纳入 | 标 `N/A`，必要时只做差距说明 | 无固定模板 | builtin/业务算子定制主流程 |
+| `04 算子基本功能实现` | 次级支撑 | 只评 PTOAS 直接支撑的工程子链路 | 文档、样例、编译配置、工程编译、运行反馈、验证 | 完整需求分析、完整方案设计、通用算子研发全过程 |
+| `05 特定 shape 性能优化` | 条件纳入 | 评“特定 shape 性能优化支撑能力” | 性能文档、固定 shape 样例、性能数据获取入口、编译验证、精度/性能验证 | 没有 baseline 时的性能提升幅度、仓外友商对标 |
+| `06 泛化 shape 性能优化` | 条件纳入 | 评“多 shape / dynamic shape 支撑能力” | `valid_shape`/dynamic shape 文档、泛化样例、多 shape 验证链路 | 没有多 shape 基线矩阵时的平均/最大收益结论 |
+
+## 评估层级
+
+任何量化前都先声明层级：
+
+- `L1 文档审阅层`：只看仓库内容，不跑命令。
+- `L2 本地最小运行层`：当前机器已有 PTOAS 产物，可验证最小命令。
+- `L3 Linux compile-only 层`：Linux + CANN/bisheng + `PTO_ISA_ROOT`，不要求带卡。
+- `L4 NPU 上板层`：带卡 Linux、驱动、ACL、设备节点和用户权限齐全。
+
+评分规则：
+- 某层未覆盖，只能标 `未实测`。
+- 不得因为本机不是 Linux / 没有 `bisheng` / 没有 NPU 就对 PTOAS 本身扣分。
+- 文档是否清楚说明这些前置条件，才属于可评分项。
+
+## `02` 的适用边界
+
+PTOAS 可以支撑 `02`，但只能评“迁移支撑能力”，不能假装它已经覆盖完整业务迁移平台。
+
+可以评分的证据：
+- `docs/PTO_IR_manual.md`：IR 层级、tile/view/valid-shape 语义、Level-2/Level-3 入口
+- `test/samples/PyPTOIRParser/README.md`：来自 pypto `ir_parser` 的 vendored `.pto` 快照
+- `test/samples/*`：迁移后 PTO case、样例目录、`golden.py`/`compare.py`
+- `docs/no_npu_compile_only_guide_zh.md`、`runop.sh`、remote validation 脚本：迁移后 compile/validate 链路
+
+`02` 里这些指标只有在“有前后对照”时才能量化：
+- `tiling 迁移完备度`
+- `kernel 迁移完备度`
+- `tiling/kernel 代码修改率`
+- `功能失败率`
+- `性能劣化率`
+
+如果当前任务没有“迁移前/迁移后”对照 case：
+- 记 `未实测`，不要臆造百分比。
+- 若该项本质依赖仓外业务工程，且用户没有给材料，可记 `N/A` 并说明原因。
+
+## `04` 的适用边界
+
+`04` 只纳入这些与 PTOAS 仓库直接对应的子项：
+- 文档获取
+- 文档学习
+- 获取示例代码
+- 学习/理解示例代码
+- 运行示例代码
+- 编译配置
+- 算子工程编译
+- 功能调试
+- 精度调试中 repo 已有 compare/golden/validation 的部分
+
+默认排除：
+- 算子设计-需求分析
+- 算子设计-方案实现
+- 通用算子代码开发全过程
+- 脱离 PTOAS 仓库的业务工程联调
+
+## `05` 的适用边界
+
+PTOAS 可以支撑 `05`，但重点是“特定 shape 性能优化的仓内支撑能力”。
+
+可直接使用的仓内证据：
+- `docs/PTO_IR_manual.md`：Level-2/Level-3、layout、partition、reshape、valid-shape 等语义
+- `.github/ISSUE_TEMPLATE/performance_issue.yml`：性能问题收集模板
+- `test/samples/FlashAttention/`, `test/samples/GQA/`, `test/samples/FFN/`, `test/samples/MatMul/`：固定 shape 样例
+- `runop.sh`、compile-only 文档、remote validation 脚本：生成、编译、上板验证链路
+
+`05` 里这些项通常至少要到 `L4` 才能量化：
+- 性能数据采集耗时
+- 性能报告完备度
+- 优化迭代次数/耗时/成功率
+- 性能提升幅度
+- 精度一致性验证
+
+如果只有文档和样例，没有真实 benchmark/baseline：
+- 文档和入口可评分
+- 真实性能数字、友商对标、提升幅度一律 `未实测` 或 `N/A`
+
+## `06` 的适用边界
+
+PTOAS 可以支撑 `06`，但重点是“多 shape / dynamic shape / valid-shape 的泛化支撑能力”。
+
+可直接使用的仓内证据：
+- `docs/PTO_IR_manual.md`
+- `test/samples/SetValidShape/`
+- `test/samples/LayoutInference/`
+- `test/samples/Partition5D/`
+- `test/samples/planmemory/`
+- 其他带动态 shape / layout / partition / subview / reshape 的样例
+
+`06` 里这些项没有多 shape 基线矩阵时不能硬算：
+- 平均优化迭代次数
+- 平均优化耗时
+- 平均性能提升幅度
+- 最大性能提升幅度
+- 多 shape 精度保持率
+
+如果当前任务只看到 IR 设计与样例，没有多 shape 实测：
+- 文档、样例覆盖度可评分
+- 多 shape 性能/精度结果记 `未实测`
+
+## `未实测` 与 `N/A` 的使用规则
+
+记 `未实测`：
+- 仓库里有入口，但当前会话没有进入对应层级
+- 缺 Linux/CANN/NPU/baseline，导致只能停在文档或最小运行层
+- 缺迁移前后对照物，无法给出完成度/收益率
+
+记 `N/A`：
+- 指标本身超出 PTOAS 仓库边界
+- 用户要求的是仓外业务工程能力，当前仓库没有独立证据链
+- 友商对标、完整业务迁移、完整 builtin 定制等不是本 Skill 的默认量化对象
+
+## 使用原则
+
+- 如果用户没有特别说明，直接按 `01` 做主评估。
+- 如果用户要求顺带看 `02/04/05/06`，按本文件的边界补相应子集。
+- 可以做“支持度评分”，但不要把仓内文档/样例的存在，夸大成业务侧已经打通。
+- 能量化就量化；不能量化就明确说明为什么是 `未实测` 或 `N/A`。
diff --git a/skills/ptoas-usability-eval/references/scoring.md b/skills/ptoas-usability-eval/references/scoring.md
new file mode 100644
index 000000000..ba3d01d6d
--- /dev/null
+++ b/skills/ptoas-usability-eval/references/scoring.md
@@ -0,0 +1,148 @@
+# 总分汇总规则
+
+本文件定义 PTOAS 易用性评估的总分汇总方法，解决两个问题：
+- 单项指标混用 `10 分制` 和 `100 分制`
+- `未实测` / `N/A` 不能被误当成低分
+
+## 1. 基本原则
+
+- 单项展示时，保留用户原始分制。
+- 汇总总分时，再做统一归一化。
+- 场景分只基于本次选中的 `Core/Conditional Touch-Points` 或其 repo 级代理指标计算。
+- 默认输出两个总分：
+  - `总分（支撑）`
+  - `总分（实测）`
+
+## 2. 单项归一化
+
+把单项分数统一换算到 `100` 分制：
+
+- 原始 `10` 分制：`归一化分 = 原始分 * 10`
+- 原始 `100` 分制：`归一化分 = 原始分`
+
+示例：
+- `8/10 -> 80/100`
+- `60/100 -> 60/100`
+
+## 3. 特殊值处理
+
+- `未实测`：不计入任何总分分母
+- `N/A`：不计入任何总分分母
+- 如果某个场景下所有指标都是 `未实测/N/A`：
+  - 该场景分不输出数值
+  - 标记为 `本次无实测样本`
+
+## 4. 场景分
+
+先算场景分，再算总分。
+
+### 4.1 场景支撑分
+
+定义：该场景下所有“已评分”的指标，归一化后求平均。
+
+纳入范围：
+- 文档
+- 样例
+- 脚本
+- 配置
+- 已实测项
+
+排除范围：
+- `未实测`
+- `N/A`
+
+用途：衡量 PTOAS 仓库本身提供的支撑能力。
+
+### 4.2 场景实测分
+
+定义：该场景下所有“有真实执行证据”的指标，归一化后求平均。
+
+必须满足至少一种证据：
+- 真实命令执行
+- 真实编译/build
+- 真实 sample 运行
+- 真实 validation / compare / board 结果
+
+不纳入：
+- 纯文档发现性分
+- 纯 README/脚本存在性分
+- `未实测`
+- `N/A`
+
+用途：衡量当前会话里真正被跑通或被验证到的易用性。
+
+## 5. 默认场景权重
+
+如果用户没有单独指定权重，默认用：
+
+- `01`：`40%`
+- `02`：`15%`
+- `04`：`15%`
+- `05`：`15%`
+- `06`：`15%`
+
+说明：
+- `01` 是 PTOAS 的主评估场景，所以权重最高。
+- `02/04/05/06` 是补充场景，默认均分剩余权重。
+
+## 6. 权重重分配
+
+不要把没有参与本次评估的场景硬算进总分。
+
+### 6.1 用户只评部分场景
+
+如果本次只评了部分场景，例如只评 `01 + 04`：
+- 先取这两个场景的默认权重 `40` 和 `15`
+- 再重分配到 `100%`
+
+例：
+- `01` 新权重 = `40 / (40+15) = 72.73%`
+- `04` 新权重 = `15 / (40+15) = 27.27%`
+
+### 6.2 计算 `总分（支撑）`
+
+- 只保留“有场景支撑分”的场景
+- 对这些场景的默认权重重分配后加权平均
+
+### 6.3 计算 `总分（实测）`
+
+- 只保留“有场景实测分”的场景
+- 对这些场景的默认权重重分配后加权平均
+
+## 7. 输出要求
+
+建议固定输出以下内容：
+
+- `总分（支撑）`：`xx/100`
+- `总分（实测）`：`xx/100` 或 `本次无法计算`
+- `覆盖场景`：本次实际评了哪些场景
+- `覆盖层级`：`L1/L2/L3/L4` 到了哪一层
+- `实测覆盖说明`：哪些场景只有文档分，哪些场景有真实执行分
+
+## 8. 解释口径
+
+当两个总分差异较大时，优先按下面口径解释：
+
+- `总分（支撑）` 高、`总分（实测）` 低：
+  - 仓库文档/样例/脚本铺得比较全
+  - 但当前会话真实跑通度一般，或存在环境/样例摩擦
+
+- `总分（支撑）` 低、`总分（实测）` 高：
+  - 当前 case 可能能跑
+  - 但仓库的通用文档化、模板化、可发现性较弱
+
+- `总分（实测）` 显示为 `本次无法计算`：
+  - 说明本次基本停留在 `L1`，或者只有文档审阅，没有足够的真实执行证据
+
+## 9. 推荐展示格式
+
+```text
+总分（支撑）: 78.5/100
+总分（实测）: 66.4/100
+覆盖场景: 01, 02, 04, 05, 06
+覆盖层级: L1 + L2
+说明:
+- 01/04 同时形成支撑分和实测分
+- 02/05/06 当前主要形成文档/样例支撑分
+- L3/L4 未实测，不计入实测总分分母
+```
diff --git a/skills/ptoas-usability-eval/references/touchpoint-selection.md b/skills/ptoas-usability-eval/references/touchpoint-selection.md
new file mode 100644
index 000000000..d57a6d79e
--- /dev/null
+++ b/skills/ptoas-usability-eval/references/touchpoint-selection.md
@@ -0,0 +1,154 @@
+# PTOAS Touch-Point 选型
+
+本文件把用户提供的总触点池裁剪成适合 `hw-native-sys/PTOAS` 的 repo 级评估子集。
+
+## 1. 选型原则
+
+- PTOAS 是**编译器 / 工具链 / 样例仓库**，不是完整 CANN 产品矩阵，也不是官方镜像分发平台。
+- 默认优先评估这些触点：
+  - `资料/文档`
+  - `API/接口` 中与 `CLI / Python 绑定 / PTO IR 手册` 直接相关的子项
+  - `源码 & 示例类`
+  - `工具`
+  - `版本` 中 repo 内可自证的子项
+  - `运行反馈`
+- 对需要**产品级生态、仓外对标、跨硬件矩阵、发布渠道运营**的数据，默认不要硬打 repo 分，记 `N/A` 或只做差距说明。
+
+## 2. 默认纳入的 Core Touch-Points
+
+这些触点默认进入 PTOAS repo 级评分。
+
+### 2.1 资料/文档
+
+- `TP001` 检索命中成功率
+- `TP002` 文档跳转次数
+- `TP003` 多入口可达率
+- `TP004` 单次任务文档跳转浏览率
+- `TP005` 知识渐进式发布
+- `TP008` 文档结构风格一致率
+- `TP009` 概念跨文档冲突数
+- `TP011` 文档、版本时效一致性
+- `TP012` 内/外链有效率
+- `TP013` 文档错误点位密度
+- `TP016` 资料交付件完备率
+- `TP017` 文档场景/内容覆盖缺失率
+- `TP018` quick_start / sample 一次跑通率
+
+### 2.2 API / 接口
+
+这里只看 PTOAS repo 自己暴露的接口层：
+- `CLI`: `ptoas`, `ptobc`
+- `Python bindings`
+- `PTO IR` 公开手册/Op 语义
+
+默认纳入：
+- `TP019` 目标接口平均查找检索轮次
+- `TP020` 渐进式复杂披露覆盖度
+- `TP028` 平均入参数 / 参数复杂度
+- `TP032` 接口自解释读懂率
+
+### 2.3 源码 & 示例类
+
+- `TP034` 示例代码无修改一键编译运行成功率
+- `TP035` 示例检索命中成功率
+- `TP036` 样例覆盖度
+- `TP037` 最小功能实现 Demo 覆盖率
+- `TP038` 命令示例覆盖度
+- `TP039` API 调用样例覆盖率
+- `TP042` 样例代码编译语法错误检出率
+- `TP043` 样例使用废弃 / 过期 API 占比
+- `TP044` 业务代码直接复用改编比例
+- `TP045` 编程模型标准对齐率
+- `TP046` 关键链路显性化率
+- `TP047` 认知理解步数
+
+### 2.4 工具
+
+- `TP049` 首次安装部署一次性成功率
+- `TP051` 标准任务平均操作步骤数
+- `TP052` 功能 / 场景覆盖率
+
+### 2.5 版本
+
+只纳入 repo 内可通过 `README / CI / tag / branch / issue template` 自证的部分：
+- `TP053` 版本检索命中成功率
+- `TP058` 版本配套关系准确性
+
+### 2.6 运行反馈
+
+- `TP062` 报错携带环境 / 版本 / 上下文信息完整率
+- `TP063` 报错自带排障建议比例
+- `TP064` 无效冗余信息占比
+
+## 3. 条件纳入的 Conditional Touch-Points
+
+这些触点只有在用户明确要求，或者当前任务确实提供了对应证据时才纳入。
+
+### 3.1 文档 / API 条件项
+
+- `TP006` FAQ 命中率
+- `TP010` 接口文档模板一致率
+- `TP014` API 文档覆盖率
+- `TP015` 错误码文档化率
+- `TP033` N+2 小版本破坏性接口变更频次
+
+### 3.2 示例 / 性能高级项
+
+- `TP040` E2E 实战案例覆盖率
+- `TP041` 行业深度调优案例覆盖率
+
+### 3.3 版本 / 部署高级项
+
+- `TP054` 版本信息完备率
+- `TP057` 版本号规范准确率
+- `TP059` 版本部署命令数
+- `TP060` 开箱部署成功率
+- `TP061` 版本兼容性率
+
+说明：
+- `TP061` 在 PTOAS 里通常要到 `L4`，并且需要 A3/A5/不同硬件的实测证据。
+- `TP040/TP041` 在 PTOAS 里只有当 `FlashAttention/GQA/FFN` 这类样例被当作准业务案例使用时才适合纳入。
+
+## 4. 默认排除的 Excluded Touch-Points
+
+这些触点默认**不进入** PTOAS repo 级总分，除非用户明确要求做生态级差距研究。
+
+### 4.1 产品生态 / 友商对标类
+
+- `TP021` API 业务场景覆盖率
+- `TP022` 主流 AI 应用框架 API 支持覆盖率
+- `TP023` 主流 AI 框架 API 支持覆盖率
+- `TP024` API 主流生态调用一致性
+- `TP025` 原子 API 与标杆 API 数量对比一致性
+- `TP026` 迁移修改代码（CUDA -> AscendC）
+- `TP027` 原子 API 与标杆 API 行为对比一致性
+
+原因：这些指标要求的是**全产品生态**、**仓外框架集成**、**与 CUDA/CANN 大盘对比**，不是 PTOAS 仓库单独可证的事实。
+
+### 4.2 不适合 PTOAS repo 形态的项
+
+- `TP029` 错误返回一致率
+- `TP030` 最小可用代码行数
+- `TP055` 主流镜像仓支持下载覆盖度
+- `TP056` 典型部署模式支持覆盖度
+
+原因：
+- PTOAS 不是以统一 runtime C API 为主的库产品，`TP029/TP030` 不适合直接套。
+- PTOAS repo 不是镜像/安装包分发平台，`TP055/TP056` 默认不打 repo 分。
+
+## 5. 场景到 Touch-Point 的默认映射
+
+| 场景 | 默认 Core Touch-Points | 条件 Touch-Points |
+| --- | --- | --- |
+| `01 算子复现部署` | `TP001-005, TP008-018, TP034-035, TP038, TP042, TP044, TP049, TP051-053, TP058, TP062-064` | `TP006, TP054, TP057, TP059-061` |
+| `02 算子迁移部署` | `TP001-005, TP008-009, TP011, TP013, TP017, TP019-020, TP032, TP035-037, TP039, TP044, TP046-047, TP051-052, TP062-064` | `TP040-041, TP033, TP061` |
+| `04 算子基本功能实现` | `TP001-005, TP008-009, TP011, TP013, TP017-020, TP028, TP032, TP034-039, TP042-047, TP049, TP051-052, TP062-064` | `TP006, TP010, TP014-015, TP033` |
+| `05 特定 shape 性能优化` | `TP001-005, TP017, TP019-020, TP035-036, TP039, TP044, TP046, TP049, TP051-052, TP062-064` | `TP040-041, TP054, TP061` |
+| `06 泛化 shape 性能优化` | `TP001-005, TP017, TP019-020, TP035-036, TP039, TP044, TP046-047, TP049, TP051-052, TP062-064` | `TP040-041, TP054, TP061` |
+
+## 6. 使用要求
+
+- 每次正式评估前，先在输出里给出 `触点选择`。
+- 默认只打 `Core Touch-Points`。
+- `Conditional Touch-Points` 只有在证据存在时才纳入，并明确说明为什么本次纳入。
+- `Excluded Touch-Points` 不进入总分；如果用户追问，可以单独给差距分析，但不要混入 repo 级总分。