تشغيل أي مهارة في Manus بنقرة واحدة

acc-rootcause

النجوم٠

التفرعات٠

آخر تحديث٩ يوليو ٢٠٢٦ في ٠٦:٣٧

OpRunway 验收里任何 FAIL 归因前的解耦纪律薄壳——先验证「任务书↔PR 对应」本身，再用被测物自己的东西（自 build + 声明 dtype + 手算 golden + custom↔builtin 对照）解耦「被测物 vs 我们的 harness」，才下归因。P2 规划的原子能力 skill：尚未接入 op-acceptance live 流、勿自动触发、无脚本判定（纪律 skill，不产 verdict）。真机 FAIL 要归因、或复盘一次归因翻案时阅读。

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

lllyys

lllyys/OpRunway

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·SOC 15-1252

مستكشف الملفات

2 ملفات

SKILL.md

readonly

name

acc-rootcause

description

acc-rootcause — FAIL 解耦纪律（原子能力 skill）

定位（诚实，P2 边界）：本 skill 是 P2 规划的纪律 skill——只装「FAIL 该怎么归因、什么前提下才能下结论」的推理纪律，无脚本判定、不产 verdict、不落盘。裁决仍唯一归确定性脚本链（validator.py / perf_compare.py / validate_acceptance_state.py，ADR 0007 canonical）；本 skill 只约束「下结论前先做什么解耦」。

未登记进 AGENTS.md（诚实先例）：本 skill 不列入 plugin/AGENTS.md 的 skills: 清单——登记 = 声称已接入 live 流，而本 skill 未接入（live 归因由 acc-verify-rootcause subagent（P1，dispatch_mode=rootcause）承载）。分发 / 发现由 init.sh 扇出保证（symlink plugin/skills/ 下全部 skill 目录、不依赖 AGENTS.md 登记）。待 P1 / 后续真接线再登记；本 skill 勿被自动触发。
血教训来源：Equal（2026-07-08→07-09 三度翻案），见 canon Verify spec-PR correspondence before acceptance（proposed）+ Root-cause decoupling before attribution（proposed）。

0. 更上游前提（比解耦更早）· 先验证「任务书↔PR 对应」本身

任何 FAIL 归因、乃至任何验收裁决之前，先确认：

这个 PR 确是这份任务书的交付 PR（靠 issue/追踪号 + 改动落点目录，不靠算子名字面匹配——名字常是常见子串、易误配）；
该任务确有已验收的交付（不是「任务书要了但未落地/未验收」的空任务）。

配错对应、或对应的其实是空任务 → 下游一切裁决作废，哪怕精度/性能门再严、解耦做得再干净。识别并跳过「未验收空任务」正是 OpRunway 的应有能力。（Equal：#2890 系误配、Equal 社区任务未验收，前「A3 真阳性」结论整体作废——refine 了三遍归因，却始终没质疑最上游。）

1. 解耦纪律（对应确认后，归因前）· 被测物 vs 我们的 harness

「输出全 0 / 未被写」既可能是 harness 没绑定/没回写，也可能是被测 kernel 压根没执行/没写——区分靠对照，不靠直觉：

同一份 runner 换内置 op 做对照：输出正确 → runner/harness 清白、锅在被测 op；仍错 → 才轮到查 harness。
跑被测物自带的 example（官方调用样例）：它对 → 被测物本身可用；它也错 → 被测物真坏。
查已编 vendor 包制品（op-info / kernel binary 是否真生成）：制品缺失即实锤。
dtype 逐个做 op 级测：分清整体不通还是某 dtype 路不通。
被测物自 build + 声明支持的 dtype + 手算 golden 独立复现：小用例逐元素比，坐实范围。

2. 下结论的红线

源码「一行诊断」须经真机重编坐实范围：读源码得「缺一行、一处即修」是假设、非结论——补上重编后可能暴露更深缺陷（补一处、另一处仍炸）。范围以真机复现为准。
技术判定与官方/程序口径分开记：「实测是被测物缺陷」是技术判定、可下；「是否算官方验收失败 / 该不该对外上报」是程序口径，未确认前留口、不外发、不来回改口。
验收职责边界：把缺陷定性清楚即可，不替被测 PR 作者把算子修到底。
裁决归脚本：本 skill 不产 pass/fail；解耦结论供人/编排理解，最终 verdict 仍由确定性脚本链出（ADR 0007）。

详规见 references/rootcause-decoupling.md（对应校验三证据 · 解耦四对照 · 全 0 决策树 · 归因红线，按 canon tier 引）。

المزيد من هذا المستودع

نفس المستودع

acc-spec

lllyys/OpRunway

把算子任务书（md 本地路径或链接）+ PR 链接，抽成中立的 <op>.spec.json（OpRunway 验收流水线 Layer 0 契约）。当你拿到「算子任务书 + 对应 PR」要开始 NPU 算子验收、或需要从任务书生成 spec 时用。一份任务书含多个算子时产出多份 spec。规则由真实社区任务书语料归纳、经三个已建 spec 验证。

2026-07-230

acc-runner

lllyys/OpRunway

OpRunway 验收的代码产出 skill，两件事：(a) gen_golden——据任务书为任意算子产 <ops_root>/<op>/golden.py（真值口径走两档链、PR/仓内参考实现禁作 golden 源、后端生成期定死、check_golden.py 自检），纯 CPU、不需 NPU、不受 runner scope gate 约束；(b) gen_runner/verify_runner——为 ops-<族> 仓、aclnn 两段式接口、opp 安装型的算子（含非 experimental 子树，引擎目录/后缀已生成化），据 spec + PR 事实（算子自带 example + op_def）生成一个「锚定算子实测路径」的 per-op NPU runner（oprunway_<op.lower()>_runner.cpp），并按 runner 自检证据满足/不满足纪律（未满足则停在 CP-C、不上真机）后才交真机跑测。OpRunway 验收 ③：spec 已就绪、要在真 NPU 上跑一个此类算子的正确性/性能时用。catlass（换构建体系）/非 aclnn 接口/双实现当前不支持（需先扩 adapter，见 doc/oprunway-batch6b-design.md）。

2026-07-230

acceptance-workflow

lllyys/OpRunway

OpRunway 算子验收编排的 CP-A..E 检查点状态机——定义薄 primary orchestrator 如何调度 3 个 subagent、串工件门禁、把 pass/fail 判定唯一交给确定性脚本链（validator/perf_compare/三级验收门），供 op-acceptance primary 首响应加载。

2026-07-230

acc-casegen

lllyys/OpRunway

把算子任务书拆成原语组合、按 rule-catalog 拉每原语的必测 case 模式、实例化去重后出「功能/精度/性能」覆盖矩阵——OpRunway 验收 Task1 用例生成的展开规则。参考草案：尚未接入 op-acceptance live 流、勿自动触发；仅在需理解或扩展「任务书→用例集」的展开规则时阅读。live 用例生成由确定性 gen_cases.py 负责。

2026-07-220

acc-perf

lllyys/OpRunway

OpRunway 验收性能维的方法论薄壳——msprof kernel-only 采集 + timing_scope 必填同口径 + 基线按任务书参考源（TBE/GPU）+ 小 shape 例外，供理解「一个算子的性能该怎么比、为什么」。P2 规划的原子能力 skill：尚未接入 op-acceptance live 流、勿自动触发、不落盘、不算达标（比值/裁决唯一归确定性 perf_compare.py，ADR 0007 canonical；timing_scope 口径见 ADR 0006·proposed）。需要读懂或扩展性能对比口径、排查性能裁决时阅读。

2026-07-090

acc-precision

lllyys/OpRunway

OpRunway 验收精度维的方法论薄壳——oracle 分层（谁当真值）+ dtype 分层度量（哪套标准、什么口径），供理解「一个算子的精度该怎么判、为什么」。P2 规划的原子能力 skill：尚未接入 op-acceptance live 流、勿自动触发、不落盘、不算 pass/fail（判定唯一归确定性 validator.py + precision_policy.py，ADR 0007）。需要读懂或扩展精度判定口径、排查精度裁决时阅读。

2026-07-090

name

acc-rootcause

description

acc-rootcause — FAIL 解耦纪律（原子能力 skill）

未登记进 AGENTS.md（诚实先例）：本 skill 不列入 plugin/AGENTS.md 的 skills: 清单——登记 = 声称已接入 live 流，而本 skill 未接入（live 归因由 acc-verify-rootcause subagent（P1，dispatch_mode=rootcause）承载）。分发 / 发现由 init.sh 扇出保证（symlink plugin/skills/ 下全部 skill 目录、不依赖 AGENTS.md 登记）。待 P1 / 后续真接线再登记；本 skill 勿被自动触发。
血教训来源：Equal（2026-07-08→07-09 三度翻案），见 canon Verify spec-PR correspondence before acceptance（proposed）+ Root-cause decoupling before attribution（proposed）。

0. 更上游前提（比解耦更早）· 先验证「任务书↔PR 对应」本身

任何 FAIL 归因、乃至任何验收裁决之前，先确认：

这个 PR 确是这份任务书的交付 PR（靠 issue/追踪号 + 改动落点目录，不靠算子名字面匹配——名字常是常见子串、易误配）；
该任务确有已验收的交付（不是「任务书要了但未落地/未验收」的空任务）。

1. 解耦纪律（对应确认后，归因前）· 被测物 vs 我们的 harness

「输出全 0 / 未被写」既可能是 harness 没绑定/没回写，也可能是被测 kernel 压根没执行/没写——区分靠对照，不靠直觉：

同一份 runner 换内置 op 做对照：输出正确 → runner/harness 清白、锅在被测 op；仍错 → 才轮到查 harness。
跑被测物自带的 example（官方调用样例）：它对 → 被测物本身可用；它也错 → 被测物真坏。
查已编 vendor 包制品（op-info / kernel binary 是否真生成）：制品缺失即实锤。
dtype 逐个做 op 级测：分清整体不通还是某 dtype 路不通。
被测物自 build + 声明支持的 dtype + 手算 golden 独立复现：小用例逐元素比，坐实范围。

2. 下结论的红线

源码「一行诊断」须经真机重编坐实范围：读源码得「缺一行、一处即修」是假设、非结论——补上重编后可能暴露更深缺陷（补一处、另一处仍炸）。范围以真机复现为准。
技术判定与官方/程序口径分开记：「实测是被测物缺陷」是技术判定、可下；「是否算官方验收失败 / 该不该对外上报」是程序口径，未确认前留口、不外发、不来回改口。
验收职责边界：把缺陷定性清楚即可，不替被测 PR 作者把算子修到底。
裁决归脚本：本 skill 不产 pass/fail；解耦结论供人/编排理解，最终 verdict 仍由确定性脚本链出（ADR 0007）。

详规见 references/rootcause-decoupling.md（对应校验三证据 · 解耦四对照 · 全 0 决策树 · 归因红线，按 canon tier 引）。