为什么cannbot-knowledge坚持DSL隔离shared、技术专属与跨技术知识的完整边界【免费下载链接】cannbot-knowledgecannbot算子开发知识库插件依赖的知识库本体仓给cannbot提供统一的知识底座。项目地址: https://gitcode.com/cann/cannbot-knowledgecannbot-knowledge 是 cannbot 的算子开发知识库本体仓它为 NPU 算子开发提供统一的知识底座。仓库中最容易被忽视、却最关键的设计就是DSL 隔离Ascend C、Triton、TileLang、PyPTO 四类算子编程技术的知识各占一隅只有真正不依赖单一技术的结论才能进入shared跨技术映射则被严格圈定在interoperability之下。本文带你快速看懂这套边界是如何划定的以及它为什么让知识检索更可靠。为什么算子知识必须按 DSL 隔离同一个算子目标在不同 DSL 上的实现路径、编译行为和约束完全不同API 不同一个数据搬运方法在 Ascend C 里是 DataCopy 系列接口在 Triton-Ascend 里则是al.*扩展 API用法和适用条件互不相同编译器不同Tiling 策略、内存层级、同步原语在每个 DSL 里的语义都可能不一样经验不可平移某个 DSL 上有效的优化技巧换个 DSL 可能直接失效甚至报错。如果把这些知识混在一个大杂烩目录里检索时最危险的不是找不到而是找到了不适用的结论。cannbot-knowledge 的设计原则写得很直接一个 DSL 的经验不能直接当成另一个 DSL 的结论。只有真正不依赖单一技术的知识才能放进shared。完整原则见 设计原则。三层边界技术专属、shared、interoperability仓库用路径本身来表达知识的归属。算子领域ops只允许以下五类 route知识卡必须声明 DSL 或使用shared不能省略这一层边界层路径位置放什么不放什么技术专属knowledge/ops/ascendc/、knowledge/ops/triton/等该 DSL 的概念、API、样例、算子、优化与 Runbook其他 DSL 的结论sharedknowledge/ops/shared/不依赖单一 DSL API、语法和编译行为的公共结论带任何单一技术色彩的通用经验interoperability只能位于shared/之下两种技术间可复用与必须重推导的映射单一技术的实现细节几个典型例子Ascend C 的 Kernel 调用、Tiling 知识 → Ascend C 目录Triton 的 IR 方言、设计期约束与优化改写 → Triton 目录并且设计期与优化期知识明确不可混用靠标签过滤区分Triton→Ascend C 的 Tiling 对照 → 只能放在knowledge/ops/shared/interoperability/例如合法路径knowledge/ops/shared/interoperability/triton_to_ascendc_tiling.mdTileLang、PyPTO 目前作为独立 route 预建入口随真实知识逐步填充。算子知识总入口 用一句话概括了这层设计按 DSL 隔离语言、API、编译器和实现约束只有真正不依赖单一 DSL 的结论进入 shared。路径规则把边界写进目录结构shared不是什么都可以放的兜底目录它的准入条件由路径规范强制执行知识卡只有两种路径形态算子知识必须声明 DSL 或sharedknowledge/domain/technology-or-scope/profile/…interoperabilityProfile 只能放在同一领域的shared/下不能挂在任何单一 DSL 目录下每张 interop 卡必须声明两个不同且已注册的技术端点source_technology与target_technology同技术两端会被直接拒绝。合法与非法路径的对照示例摘自 知识路径规范knowledge/ops/shared/interoperability/triton_to_ascendc_tiling.md # 合法跨技术映射在 shared 下 knowledge/ops/apis/data_copy.md # 非法缺少 technology/scope 层 knowledge/ops/ascendc/patterns/double_buffer.md # 非法未注册的 Profile knowledge/ops/ascendc/runbooks/timeout.md # 非法Runbook 缺少 area 层级注意一个细节shared 目录当前知识卡极少这不是缺陷而是门槛——宁缺毋滥避免伪通用结论污染检索结果。机器校验边界不是靠自觉而是靠 Contract光靠规范文档约束不住贡献者仓库把边界规则做成了可执行的机器检查registries.yaml 注册了全部合法技术ascendc/triton/tilelang/pypto与 scope含shared未注册的 DSL 名称无法出现在路径中interoperability 检查 逐卡校验技术端点必须已注册、且两端必须不同知识契约 统一加载这些规则Ingest 写入前拒绝、Query 加载失败即停止、Lint 只读报告——同一套规则服务三类消费者不存在某个脚本例外放行。这套机制保证了一张卡放错 DSL 目录、或 interop 卡声明了相同技术端点都会在入库前被拦截而不是混进索引后误导使用者。检索视角隔离如何帮你更快找到正确知识对使用者来说DSL 隔离带来的是少踩坑的检索体验先定技术再查知识确定自己用的是 Ascend C 还是 Triton直接进对应 route返回的候选天然与你的技术栈匹配shared 是安全补充只有显式要求时查询才会附加同领域shared卡作为补充且不会放宽到其他 DSL跨技术迁移有专门出口做 GPU 算子 NPU 化、或在 Triton 与 Ascend C 之间对照 Tiling 时去interoperability找映射卡它明确告诉你哪些可直接复用、哪些必须重推导。相关规则说明见 Skills 规范 与 治理规范。总结cannbot-knowledge 坚持 DSL 隔离本质上是把经验适用性从人的判断变成了路径与机检共同约束的硬边界技术专属知识→ 各 DSL 独立目录经验不串味shared→ 只收真正 DSL 无关的结论宁缺毋滥interoperability→ 唯一合法的跨技术映射出口端点必须不同且已注册。理解了这三层边界你在算子开发中检索、贡献知识时就能清楚地知道一条经验该放哪里、查到的结论能不能用在自己的 DSL 上。【免费下载链接】cannbot-knowledgecannbot算子开发知识库插件依赖的知识库本体仓给cannbot提供统一的知识底座。项目地址: https://gitcode.com/cann/cannbot-knowledge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
