cannbot-knowledge知识卡生命周期与信任层级draft、stable、deprecated与verified全解【免费下载链接】cannbot-knowledgecannbot算子开发知识库插件依赖的知识库本体仓给cannbot提供统一的知识底座。项目地址: https://gitcode.com/cann/cannbot-knowledgecannbot-knowledge 是 CANN 社区 CANNBot 算子开发知识库的本体仓为算子开发智能体提供统一的知识底座。本文带你一次看懂它治理知识卡的两个核心字段statusdraft / stable / deprecated 生命周期与verifiedunverified / machine-confirmed / human-reviewed 信任层级以及它们如何被自动检查守住。1. 什么是知识卡cannbot-knowledge 的统一知识底座cannbot-knowledge 不把算子工程代码当正文提交而是把可追溯的工程结论整理成 Markdown知识卡正文讲结论、适用条件与失效边界文件开头的 Frontmatter 保存类型、平台、版本、生命周期和来源等结构化信息。CANNBot 通过knowledge-query等 Skill 检索这些卡片复用经过治理的结论。中可见本仓是整个 CANNBot 仓群中唯一保存技术知识正文的地方所有卡片都位于knowledge/目录下。仓库整体工作流是官方文档 / 固定版本源码 / 可复现实验 → Ingest 生产 Markdown 知识卡 →knowledge-lint检查结构与治理规则 →knowledge-query检索 → CANNBot 阅读正文并核对来源。理解这条链路后再看生命周期与信任层级就不难了。2. 生命周期draft、stable、deprecated 三种状态怎么定每张非index.md知识卡都必须显式填写status字段且只允许三个取值机器事实源见 frontmatter.schema.jsonstatus含义默认 Query 是否返回对sources的要求draft尚未评审、来源不足或适用范围未确认❌ 不返回允许sources: []stable✅可以在卡片声明的范围内消费✅ 返回至少 1 项来源deprecated为历史引用保留不再代表当前推荐结论❌ 不返回至少 1 项来源几个新手最容易踩的点draft 不等于质量差只是还不能被检索到——platforms: []适用范围未确认只允许出现在 draft 卡上确认错误但仍需解释历史行为的卡片也用deprecated并在正文和当天日志说明原因而不是直接删除完整规则见 Frontmatter 与证据。2.1 deprecated 卡片必须用replaced_by指路一旦填写replaced_byLint 会强制以下约束实现见 lifecycle.pystatus必须是deprecated否则报status.replaced_by错误值必须是 Bundle 内不带.md的规范 Concept ID如ops/ascendc/apis/new_api不能以/或knowledge/开头、不能含..目标必须是一张真实存在的知识卡不能指向自身、index.md也不能经符号链接越出 Bundle。也就是说废弃不是终点而是一次带路——读者总知道去哪里找当前结论。仓库中真实的 deprecated API 卡片例如 v1版本TilingData废弃正文顶部直接标注了该结构体废弃请使用 HCCL Tiling 提供的接口。3. 信任层级verified 字段与三级可信度status回答这张卡能不能被检索verified回答这张卡被谁核实过。它使用 OKF verification event记录真实发生过的复核verified: - by: human:reviewer_id at: 2026-08-15T08:00:00Zbyactor只允许三种形式human:id、process:id或producer/version单个事件可写成 mapping多个事件用数组查询侧会统一解释为事件列表。根据事件内容卡片落入三个信任层级信任层级判定条件通俗理解unverified没有任何 verified 事件刚入库仅结构合规machine-confirmed有事件但 actor 全部不是human:被流程/工具核对过human-reviewed至少一个human:actor有人工真实复核两条红线值得记住status与信任层级相互独立——stable 有sources不等于人工复核过不能伪造验证Linttrust.py只校验 actor 格式Lint 通过固定来源都不能自动转换成 verified 事件。4. 实战如何读懂一张真实知识卡的 Frontmatter拿一张 API 卡看完整生命周期字段一目了然type: API title: v1版本TilingData废弃 tags: [task.lookup, topic.implementation.api_layer.high_level_api] status: draft # 生命周期草稿默认查询不返回 sources: # 证据入口本地登记来源指向原始文档 - resource: cann-docs-raw/asc-devkit/docs/zh/api/SIMD-API/adv_api/HCCL_communication/HCCL_Tiling/v1_TilingData_deprecated.md role: primary created_at: 2026-08-18T14:51:00Z updated_at: 2026-09-12T03:09:26Z platforms: [] # 空数组只允许 draft对照 lifecycle 检查规则 就能推出它的状态无replaced_by、无verified→ 这是一张draft unverified的卡等待来源补齐和范围确认后升级为stable。写卡时的建议顺序先 draft 立卡 → 补全 sources 与平台范围 → 人工复核写入 verified → 升 stable → 结论过期后标 deprecated 并填 replaced_by。贡献流程详见 贡献知识。5. 自动检查如何守住这些规则knowledge-lint规则不止写在文档里而是被 Contract 统一执行且每条规则只在一个机器文件中定义机器事实源职责frontmatter.schema.json字段类型与形状如 status 三值枚举、verified 事件结构profiles.yaml路径 Profile → 必选字段与 OKF type 映射registries.yaml平台、标签等受控值表lifecycle.pystatus 与 replaced_by 的跨字段约束trust.pyverified 事件 actor 格式提交前运行仓库统一入口即可触发全部检查bash check.sh它执行知识 Lint、导航检查、索引与检索回归、单元测试等保证生命周期与信任字段写了就合规。规则体系总览见 Schema、Registry 与 Contract设计动机见 设计原则——其中明确写道稳定有来源经过复核不是一回事。6. 常见疑问FAQQ1stable的卡片可以直接照抄结论吗不能。Query 只按平台和技术范围过滤并返回候选当前不按 CANN 版本过滤使用前仍需打开正文核对版本边界、平台适用范围和来源。Q2为什么我搜不到刚写的卡大概率status还是draft或deprecated。两者默认都不被 Query 返回补齐来源和范围后升为stable即可被检索。Q3卡片结论错了怎么办标deprecated、填replaced_by指向修正后的卡片在正文和当天日志说明原因——历史引用不断链。Q4sources有内容就能算已验证吗不算。sources回答结论能回到哪里核验verified才记录谁在何时复核过两者独立。7. 延伸阅读Frontmatter 与证据生命周期/信任/来源/标签完整规范OKF Bundle 与 CANNBot Profile形成可追溯回答检索与证据实践安装与使用指南掌握status三态与verified三级信任后你既能看懂每张知识卡现在能不能用、被谁信过也能在贡献知识时一次通过 Lint成为 CANNBot 知识底座上可靠的写作者 【免费下载链接】cannbot-knowledgecannbot算子开发知识库插件依赖的知识库本体仓给cannbot提供统一的知识底座。项目地址: https://gitcode.com/cann/cannbot-knowledge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
