企业官网建设流程全解析

CANN graph-autofusion 的 SK 算子流水线路由规则详解：从主入口到子 skill 的智能分发

【免费下载链接】graph-autofusionGraph-autofusion 是一个面向昇腾（Ascend）芯片的轻量级、解耦式组件集合，旨在通过自动融合技术加速模型执行。 目前已开源 SuperKernel 组件和 Autofuse 组件，未来将持续开放更多自动融合相关模块。项目地址: https://gitcode.com/cann/graph-autofusion

导读

本文围绕 CANN graph-autofusion 开源仓库中 SuperKernel 组件配套的sk-operator-pipeline内置 skill 的 路由规则文档，系统拆解 SK（SuperKernel）算子适配主流水线的入口职责、路由表设计、关键词匹配实现，以及当前能力缺口。读完本文，你将掌握：何时该走完整流水线run-sk-pipeline、何时该用route/index辅助命令、每个子 skill 的职责边界与调用入口，以及路由规则在源码中的落地方式。

一、路由规则文档的定位

.claude/skills/sk-operator-pipeline/目录是仓库内置 skill 的完整实现，包含：

• SKILL.md：skill 声明、流水线 CLI 全量参数与状态机摘要；
• references/routing.md：本文核心，定义主入口职责与路由规则；
• references/workflow.md：统一运行合同与第一版范围；
• references/dependencies.md：skill 间依赖边界与算子构建依赖；
• references/pipeline-state-machine.md：流水线阶段图、布局与状态结构；
• scripts/operator_pipeline.py：CLI 主程序，路由规则的源码实现。

routing.md是流水线的"导航中枢"文档：它不实现流水线本身，而是回答"一个任务进来后该交给谁处理"这一关键问题。

二、主入口职责：承接、调度、路由、索引

根据 routing.md 的"主入口职责"章节，sk-operator-pipeline承担四项职责：

1. 承接 SK 算子适配主流水线：作为算子从源码到 SK（SuperKernel）交付的总入口，任何 SK 算子适配工作都从这里发起；
2. 调度子 skill：把资产接入、源码适配、校验、样例生成、构建打包等子 skill 组织成可迭代的闭环流水线；
3. 按需路由：当用户只需要"定位能力"而非完整流水线时，把自由文本问题路由到其它 built-in skill；
4. 生成能力索引：在需要本地资料导航时，输出本地能力索引，帮助用户快速找到可用的 skill 与入口。

在源码中，这一入口统一收敛为固定调用合同：

python3 <skills_root>/sk-operator-pipeline/scripts/operator_pipeline.py <subcommand> ...

对应 SKILL.md 中的"入口"一节。<skills_root>默认取 skill 所在目录的父目录（即.claude/skills），由_resolve_skills_root()解析，见 operator_pipeline.py。

主流程与辅助命令的分工是：完整闭环走run-sk-pipeline，轻量定位走route/index。后两者默认运行base mode——不依赖联网、不依赖大模型，纯本地规则与文件扫描（见 workflow.md 的"统一运行合同"）。

三、完整路由规则：六类任务与六个目标 skill

3.1 路由表

routing.md 的"路由规则"章节给出了完整的任务分类到目标 skill 的映射：

3.2 路由表在源码中的落地

这张表并非仅存在于文档，operator_pipeline.py 中的ROUTING_RULES列表就是它的程序化实现。每条规则由"目标 skill 名 + 关键词列表"组成：

• sk-model-analysis：融合、性能、hang、coredump、卡死、scope、task、queue、update；
• sk-operator-asset-adapter：资产、asset、layout、adapter、接入、仓库、repo；
• sk-operator-validate：校验、validate、规范、lint、风险、spec、compat、兼容、cann、sdk、driver、acl、版本；
• sk-operator-build-package：编译、build、打包、wheel、pybind；
• sk-operator-sample-gen：样例、sample、runtime、correctness、verdict、oracle；
• sk-operator-codegen：算子、operator、codegen、使能、scaffold、intake。

路由匹配由_route_query()实现（operator_pipeline.py）：将查询文本转为小写后，按规则顺序对关键词做子串匹配，命中即返回对应 skill；若全部未命中，则回退到sk-operator-pipeline自身。因此关键词是大小写不敏感的，且支持中英文混写（如"兼容"与"compat"）。

cmd_route命令（operator_pipeline.py）在路由命中后，还会为每个目标 skill 生成一条可直接执行的"下一步入口"命令（entry），并输出confidence: "rule-based"（基于规则的置信度标记）以及路由报告operator-pipeline-route-report.md与结构化结果operator-pipeline-route.json。

3.3 一个完整的 route 示例

假设用户提问"帮我检查这个算子有没有违反 SK 编码规范的风险代码"，命令如下：

python3 .claude/skills/sk-operator-pipeline/scripts/operator_pipeline.py route \ "检查算子 SK 编码规范风险" \ --output-dir operator-pipeline-output

_route_query()会命中sk-operator-validate规则中的"规范""风险"关键词，输出路由报告建议下一步调用：

python3 <skills_root>/sk-operator-validate/scripts/operator_validate.py \ validate-operator --asset <asset> --output-dir <dir>

该命令由cmd_route内的entry()辅助函数按目标 skill 拼装，完整映射见 operator_pipeline.py。

四、路由与索引的运行模式：base mode 与 ai mode

workflow.md 明确了route/index的两种执行模式：

• base mode（默认）：不依赖联网、不依赖大模型，纯本地完成能力索引与规则路由，是路由可靠性的基石；
• ai mode：通过--with-ai显式触发，只做增强提示（AI hints），不替代基础索引与路由结果。

在源码中，ai mode 的落地体现在三处：

1. CLI 参数--with-ai同时注册在index与route子命令上（operator_pipeline.py）；
2. payload 中记录ai_requested与ai_status，未配置真实模型后端时标记为not-configured（operator_pipeline.py）；
3. 开启--with-ai时额外落盘operator-pipeline-*-ai-hints.md，内容固定说明"AI 增强层位置已固定但未接入真实模型后端"，并建议先基于本地索引/路由结果确定目标 skill，再交给后续 AI 层做精细提示（_render_ai_hints()，operator_pipeline.py）。

这一设计体现了文档中的原则：AI 只做锦上添花，路由与索引的确定性由本地规则保证，避免把 skill 设计成只能依赖大模型的统一入口（见 workflow.md 的"当前不做"）。

五、index：本地能力索引的构建边界

index子命令用于构建本地能力索引。其核心边界规则是：

• 默认只扫描skills_root（即.claude/skills）；
• 只有显式传入--index-root时才扫描用户工作区路径。

源码实现上，cmd_index（operator_pipeline.py）在没有--index-root时把索引根收敛为[skills_root]，每个索引根生成一节sections（记录根路径与文件数），最终输出：

• operator-pipeline-index.json：结构化索引；
• operator-pipeline-index-report.md：Markdown 报告，含 base mode / ai requested 标记与各根目录文件统计；
• （开启--with-ai时）operator-pipeline-index-ai-hints.md：AI 增强提示。

这一边界同样在 dependencies.md 的"Skill 包边界"中被强调：index默认只扫描skills_root，索引用户工作区必须显式传--index-root，从依赖层面防止索引逻辑越权扫描无关路径。

六、路由与流水线的分工边界

路由规则文档明确指出："route / index 仍是辅助能力，不替代run-sk-pipeline"。二者的分工是：

• 需要完整闭环时（单算子源码 → 资产接入 → 源码适配 → 校验 → 样例生成 → 构建打包），使用run-sk-pipeline，它按 stage 落盘输入、输出、状态和交付物索引，并通过自动修复收敛，不能收敛时明确升级给人工（needs-human）；
• 只需要定位能力时（"这个问题该找哪个 skill"），使用route；
• 需要本地资料导航时（"当前仓有哪些能力可用"），使用index。

路由是流水线的"前端导航"，流水线是路由的"后端闭环"。用户在拿到route输出的目标 skill 与入口命令后，既可以直接执行该入口，也可以回到run-sk-pipeline走完整链路。从源码结构看，ROUTING_RULES中甚至为sk-operator-pipeline自身预留了回退目标：当查询无法命中任何关键词时，_route_query()返回流水线自身，由它引导用户走完整流程或index，形成自洽闭环（operator_pipeline.py）。

七、当前缺口与演进方向

routing.md 的"当前缺口"章节坦陈了第一版的四项限制：

1. 还没有 issue 索引；
2. 还没有方案回顾索引；
3. 还没有统一的问题模板；
4. route / index 仍是辅助能力，不替代run-sk-pipeline。

对应 workflow.md 的"当前第一版范围"与"当前不做"：第一版只交付run-sk-pipeline、index、route三个子命令；不做复杂 issue 平台集成。这些缺口为后续演进（如接入 issue 平台、引入统一问题模板）预留了明确方向，也与 ai mode 中"后续如果接入 AI，只能在这份基础索引之上补更细的提示和关联"的设计意图一致（见_render_index_report的"Current Note"，operator_pipeline.py）。

八、延伸阅读

• SKILL.md：流水线全量 CLI 参数、阶段输出布局、状态与返回码、完整路由表；
• references/workflow.md：统一运行合同与第一版范围；
• references/dependencies.md：skill 间依赖边界、算子构建依赖声明规则；
• references/pipeline-state-machine.md：阶段图、强依赖约束、Artifact Layout v2 与pipeline-state.json状态结构；
• scripts/operator_pipeline.py：路由规则、索引与路由命令的源码实现；
• SuperKernel 组件开发指南 super_kernel/docs/developer_guide.md：从算子源码到 SK 的工程化配套文档。

【免费下载链接】graph-autofusionGraph-autofusion 是一个面向昇腾（Ascend）芯片的轻量级、解耦式组件集合，旨在通过自动融合技术加速模型执行。 目前已开源 SuperKernel 组件和 Autofuse 组件，未来将持续开放更多自动融合相关模块。项目地址: https://gitcode.com/cann/graph-autofusion