RDK Model Zoo 演示评审

安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install rdk-model-zoo-demo-review
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 rdk-model-zoo-demo-review。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

RDK Model Zoo 演示评审是 Openclaw Skills 工作流，用于评审 RDK X3、RDK X5 和 RDK S 分支中的新增、变更、迁移或合并前示例。它会确定正确的仓库目标，收集路径和行号证据，并从两个独立维度评估示例：Model Zoo 标准和交付规格。
该技能帮助评审者发现合规缺口、缺失构件、错误的运行时行为、文档不一致和未经验证的声明，避免将仓库约定与交付要求混淆。它会生成按严重性排序的问题、已通过检查、待解决问题、验证级别和总体结论。

应用场景

在合并前评审新的 RDK Model Zoo 示例。
根据分支特定要求验证迁移或修改后的演示。
检查目录结构、生成文件、命名、双语文档、运行时路径和默认命令。
确认模型下载、转换与评估器边界、共享工具复用和公开代码注释。
根据 issue、PR 或规格，对比请求的板卡、模型格式、运行时、能力和文档。
审核承诺的准确率、性能、结果图片或基准证据。
在无法运行板卡硬件时，生成基于证据的评审。
区分静态评审、主机验证、板卡验证和未验证状态。

工作原理

根据提供的仓库和示例路径、当前 Git 仓库与分支，或唯一匹配的示例目录确定评审目标。
如果无法识别目标，则询问仓库路径和示例路径；不得仅凭模型名称推断平台或分支。
阅读目标分支指南、根目录 README 文件、相关示例文件和评审清单。
使用分支矩阵和匹配的系列模式识别例外及预期约定，并根据分支文档和最接近的同类示例进行验证。
仅收集相关证据，包括目录列表、文档、转换和评估器文件、模型与运行时资源、测试数据、入口点、包装器、脚本、构建文件、索引和交付源文件。
按以下优先级评审 Model Zoo 标准：分支规则、分支文档、目标代码与文件、最接近的同类示例，然后是示例模板。
独立评审交付规格，检查所需功能、板卡、格式、运行时范围、转换、评估器、文档和承诺的证据。
为每个问题记录严重性、维度、位置、规则或要求、证据、影响及最小修复措施。
使用支持已通过检查的文件或命令进行标记；除非确实观察到，否则不得声称执行过板卡。
先报告问题，然后报告 Model Zoo 标准、交付规格、已通过检查、待解决问题、验证级别和总体结论。

配置指南

通过主机 Openclaw Skills 环境安装或暴露该技能，然后确保引用的文件位于技能旁边，包括 references/review-checklist.md、references/branch-matrix.md 和 references/family-patterns.md。源代码未定义包管理器命令或额外运行时依赖。
提供仓库路径、示例路径、分支上下文，以及（如果有）issue、PR 描述、规格或用户请求。在已检出的仓库中，可以使用以下命令进行基本目标发现：
git rev-parse --show-toplevel
git branch --show-current
find . -maxdepth 4 -type d -iname 'sample' -o -iname 'model'
评审者应在提出问题前检查适用的分支文档和示例树。只有在具备适当证据时，才可运行主机命令或板卡命令；否则应将结果归类为 static-reviewed 或 not-verified，而不是暗示已执行。
RDK Model Zoo 演示评审 数据架构与分类体系
该技能围绕目标、证据、两个独立评审维度和最终验证状态组织评审数据。
数据区域 必需或预期内容
评审目标 仓库、分支、平台上下文、示例名称和示例路径
证据 path:line 引用或带相关输出的命令；支持已通过检查的文件和命令
标准维度 分支/平台匹配、目录形态、生成文件、命名、双语文档、运行时路径、下载、转换/评估器边界、注释、共享工具、索引和跨文档一致性
交付维度 请求的模型、任务行为、板卡、格式、Python/C++ 范围、转换、评估器、文档、性能、准确率、图片和基准证据
问题 严重性（blocking、major 或 minor）、维度、位置、规则或要求、证据、影响和最小修复措施
交付来源 issue、PR 描述、规格或用户请求；缺失时明确写出 No delivery specification available
验证级别 static-reviewed、host-verified、board-verified 或 not-verified
最终结果 已通过检查、未解决的待答问题，以及结论：pass、pass with fixes 或 needs rework
相关仓库构件包括顶层文档、conversion/、evaluator/、model/、runtime/ 和 test_data/ 内容、运行时入口点、包装器、run.sh、构建文件、根目录和类别索引，以及适用的视觉示例 README 文件。板卡验证必须指出命令、板卡、模型构件、输入和观察到的结果。

高级特性

独立的双维度分析可避免合规评审良好却掩盖交付要求缺失，也避免交付完整性掩盖仓库违规。
references/branch-matrix.md
处理分支相关例外。
references/family-patterns.md
比较示例系列，同时受目标分支文档和同类示例证据约束。
以证据为先的问题，提供精确的
path:line
引用或可复现的命令输出。
明确区分硬性要求、平台要求和约定。
没有规格时验证交付来源，但不臆造要求。
具备验证意识的报告，将静态评审、主机执行、目标板执行和不可用验证分开。
结构化严重性级别和最小修复措施，提高整改效率。
控制范围，关注合规、回归和缺失的交付内容，而不是重写示例。

name: rdk-model-zoo-demo-review description: Use when reviewing a new, changed, migrated, or pre-merge RDK Model Zoo sample/demo for repository compliance or delivery completeness across RDK X3, X5, and RDK S branches.

RDK Model Zoo Demo Review

Review a sample on two independent axes. Do not let a clean convention review hide a missing delivery requirement, or vice versa.

Resolve the target

Use this order to identify the review target:

A repository and sample path explicitly supplied by the user.
The current Git repository root, branch, and the supplied model/sample name.
A uniquely matching sample directory in the current repository.

If those do not identify one target, ask for the repository path and sample path. Do not infer a platform or branch from a model name alone.

Read the target branch's docs/Model_Zoo_Repository_Guidelines.md, root README files, and the relevant sample tree. Read references/review-checklist.md before judging any finding. Use references/branch-matrix.md to select branch exceptions and references/family-patterns.md only for the matching sample family; validate both against target-branch documentation and the closest sibling sample.

Gather evidence

Inspect only material relevant to the target:

The target sample's complete path listing, top-level docs, and applicable conversion/, evaluator/, model/, runtime/, and test_data/ contents.
Runtime entry points, wrappers, run.sh, build files, and only the shared utilities needed to judge possible duplication.
Root and category indexes affected by the sample; for vision, include samples/vision/README* when that branch uses them.
The issue, PR description, specification, or user request when one exists; this is the delivery source.

Each finding needs a path:line citation, or a command plus the relevant output. A passed check must name the files or command that support it. Never claim board execution unless it was actually run.

Review axes

Model Zoo standards

Apply the precedence order in the checklist: target branch rules, target branch documentation, target sample code/files, closest family sibling, then sample_template. Report whether each rule is a hard requirement, platform requirement, or convention.

Check only applicable categories: branch/platform fit; directory shape and generated files; required names; bilingual docs; runtime paths and default commands; model download artifacts; conversion/evaluator boundaries; public-code comments; shared-utils reuse; and repository/category index and cross-document consistency.

Delivery specification

When a delivery source exists, independently check:

Requested model, task capabilities, and input/output behavior.
Requested boards, model formats, Python/C++ runtime scope, conversion, evaluator, and documentation deliverables.
Promised accuracy, performance, result images, or benchmark evidence.
Missing or partial requirements, incorrect-looking implementations, and scope that was added without a stated need.

If no delivery source exists, state No delivery specification available; do not invent one from repository conventions.

Verification level

End the report with one level and its evidence:

static-reviewed — files, paths, docs, and code were inspected for consistency.
host-verified — a host-side build, script, or test was run successfully.
board-verified — the stated command, board, model artifact, input, and result were observed on target hardware.
not-verified — state the missing environment, artifact, or access.

board-verified includes static-reviewed; it does not excuse standards findings.

Output

Produce findings first. For every finding include:

Severity: blocking, major, or minor (use the checklist guidance).
Axis: Model Zoo standards or Delivery specification.
Location, rule/requirement, evidence, impact, and the smallest corrective action.

Then provide, in this order:

Model Zoo Standards

Delivery Specification

Passed Checks

Open Questions — only unresolved facts.

Verification Level

Overall Verdict — pass, pass with fixes, or needs rework.

Keep the two axes separate; do not merge or rerank their findings. If no finding exists on an axis, say so explicitly.

Boundaries

Focus on compliance, regressions, and missing delivery pieces. Do not rewrite the sample unless asked. Treat board execution as unverified unless evidence is available.

GoBuy 产品信任检查

WS QuickStatus