一张神兽、地域、展厅和出处共同组成的知识图谱，最怕的不是节点少，而是关系悄悄失真：新神兽没有连到任何地域，展陈卡缺少出处边，两个互斥的身份标签又落在同一节点上。等这些数据进入推荐、展厅编排或数字馆长上下文后，错误会被放大成不可信的解释。

本文给出山海万灵的图谱质量检测设计：在内容进入读者可见链路前，使用只读快照找出孤立节点、必需关系缺失和冲突关系，并把结论交给审核工作流处理。

从内容录入到读者解释的质量关口

检测器位于内容写入与读者消费之间。它不修改神兽、地域或展厅数据，只生成带版本号的问题报告；审核人员决定修复、忽略或豁免。这样既能保证推荐链路看到稳定数据，也避免一条不确定的规则直接改写文化内容。

先定义哪些关系必须成立

规则不以“关系越多越好”为目标，而是把业务上必须成立的连接写成不变量。神兽可以暂时没有推荐边，却不应缺少所属地域；展厅陈列可以引用多种实体，却必须能追溯到可展示内容；互斥类型不能同时成为同一节点的有效主身份。

type Severity = 'info' | 'warning' | 'blocking' interface GraphIssue { id: string ruleId: 'ORPHAN_NODE' | 'MISSING_REQUIRED_EDGE' | 'CONFLICTING_EDGE' severity: Severity graphVersion: string nodeIds: string[] edgeIds: string[] message: string suggestedAction?: 'link' | 'remove' | 'review' }

graphVersion是报告可追溯的关键字段。审核人面对的不是“有一条边错了”，而是“版本 v42 的白泽节点缺少地域边”；内容在审核期间更新后，旧报告自然失效，避免把旧结论套用到新图谱。

三类规则如何协同工作

孤立检测关注没有有效入边也没有有效出边的节点；缺边检测依据节点类型读取必填关系模板；冲突检测则按关系组检查互斥组合。三类规则共用快照，却分别给出可解释的消息和修复建议。

function inspect(snapshot: GraphSnapshot, rules: RuleSet): GraphIssue[] { return [ ...findOrphanNodes(snapshot), ...findMissingRequiredEdges(snapshot, rules.requiredEdges), ...findConflictingRelations(snapshot, rules.mutualExclusion), ...findBrokenSourceReferences(snapshot) ].sort(bySeverityThenNode) } function findMissingRequiredEdges(snapshot: GraphSnapshot, required: RequiredEdgeRule[]) { return snapshot.nodes.flatMap((node) => required .filter((rule) => rule.appliesTo(node.type)) .filter((rule) => !snapshot.hasOutgoing(node.id, rule.edgeType)) .map((rule) => issue('MISSING_REQUIRED_EDGE', node.id, rule))) }

规则优先级要跟着内容生命周期走

同一条关系在录入、审核和发布阶段的处理并不相同。录入时，编辑人员需要尽早看到缺边提示，但不能因为一条文化材料暂未整理完就丢失草稿；审核时，问题应展示完整上下文，包括关联节点、来源、规则版本和此前的豁免；进入发布候选后，只有会让读者得到错误归属、错误推荐或无法追溯出处的关系才升级为 blocking。

这套分层也为规则迭代留出空间。新规则先以 info 运行，记录命中率与人工处置结果；确认规则稳定后升为 warning；只有在误报率、修复成本和内容风险都得到审核团队认可时，才进入发布门禁。规则版本与报告一起保存，能够回答“这一批内容为何被拦截”以及“规则调整后哪些历史报告需要重算”。

function issue(ruleId: GraphIssue['ruleId'], nodeId: string, rule: RuleDefinition): GraphIssue { return { id: `${rule.version}:${ruleId}:${nodeId}`, ruleId, severity: rule.severity, graphVersion: currentGraphVersion(), nodeIds: [nodeId], edgeIds: [], message: rule.describe(nodeId), suggestedAction: rule.defaultAction } } function bySeverityThenNode(left: GraphIssue, right: GraphIssue) { return severityRank(right.severity) - severityRank(left.severity) || left.nodeIds[0].localeCompare(right.nodeIds[0]) }

对读者可见内容尤其要避免“修复一条边，破坏另一条解释”。因此审核工作台中的修复动作应先产生候选变更，再使用同一规则集重新检测；只有新报告不再包含阻断问题，候选变更才成为可发布版本。这个闭环把人工判断留在合适的位置，同时让每次判断都能被追溯和复现。对于跨地域、跨展厅的关系，报告还应展示最短关联路径，帮助审核人判断这是确实的知识断裂，还是尚未完成编排的临时状态，并减少误修风险。

把规则、报告与豁免拆开保存

检测报告不应混入图谱实体，也不应只靠日志留存。规则会迭代，内容会修订，审核人也需要解释某次发布为何允许通过，因此报告、豁免和修复动作各自拥有稳定身份。

interface InspectionReport { reportId: string graphVersion: string generatedAt: string issues: GraphIssue[] summary: { info: number; warning: number; blocking: number } } interface IssueWaiver { issueId: string reason: string expiresAt?: string reviewerId: string }

豁免必须有理由和到期时间。临时无法补齐出处的历史材料可以带着 warning 发布，但不能因为一次人工确认就永久绕开规则；下次内容版本变化或豁免到期时，检测器会再次提示。

function decidePublication(report: InspectionReport, waivers: IssueWaiver[]) { const activeWaivers = new Set( waivers.filter((item) => !item.expiresAt || item.expiresAt > now()).map((item) => item.issueId) ) const unresolvedBlocking = report.issues.filter((item) => item.severity === 'blocking' && !activeWaivers.has(item.id) ) return unresolvedBlocking.length === 0 ? { allowed: true, reason: 'graph_check_passed', reportId: report.reportId } : { allowed: false, reason: 'graph_check_blocked', reportId: report.reportId, issueIds: unresolvedBlocking.map((item) => item.id) } }

失败、降级与发布策略

规则服务不可用时，发布链路不应悄悄把内容当作已检查。对于已经生成且版本匹配的报告，可以在有效期内继续使用；没有可用报告时，系统将候选标记为“待质量检查”，由审核人员决定暂存或人工复核。只有明确的 blocking 问题才阻断发布，warning 保留在工作台中持续追踪。

实施顺序与验收信号

第一步建立节点类型、必需边和互斥组的规则目录；第二步完成只读快照与版本化报告；第三步在 CMS 中展示定位到节点和关系的问题；最后把 blocking 汇总接入发布候选门禁。每一步都保留独立验收信号，避免把“能跑规则”误认为“已形成可用审核闭环”。

• 构造包含孤立节点、缺边和冲突边的样本图谱，结果能准确定位节点与规则编号。
• 同一图谱版本重复检测得到相同问题顺序；版本改变后，旧报告不再被当作有效结果。
• 审核人能查看问题、提交修复或带期限的豁免，并回读完整操作记录。
• blocking 问题存在时发布候选被拦截；修复或有效豁免后才能继续流转。
• 在模拟器和真机上完成一次“内容修复—重新检测—解除门禁”的完整动作链，并回读审核结果。

这套设计把图谱质量从一次性人工检查转成可追溯的日常能力：内容扩展时能提前发现断开的知识连接，审核和发布也能基于同一份版本化结论协作。ArkTS 的语言与应用开发资料可参阅 OpenHarmony 官方文档仓库。