想确认 HelixWorld 能不能支撑你要做的实时交互，最省事的做法不是读功能描述，而是把仓库自带的示例脚本全部跑一遍，再按跑出来的结果列能力清单。示例脚本能跑通的部分，算作已有能力；仓库里找不到对应脚本、也 grep 不到相关接口的部分，先按没有处理，需要自己补。下面这套动作只解决一件事：把「看起来应该有」和「实际能用」分开。

适用场景：准备基于 HelixWorld 接入，但不确定某项交互能力是否已内置。操作动作：先列出示例目录下所有脚本，逐个执行 `--help` 与默认启动，记录输入形式与可见输出。验证方式：能跑出输出、改输入后能看到变化，才算可用；只有文字描述、没有对应脚本的，按未提供处理。风险边界：示例覆盖不等于完整功能覆盖，示例跑通只说明该路径在当前环境可用，实时性、并发量、长期稳定性仍需在接入阶段单独确认。

列出仓库里所有示例入口和它们各自做了什么

先从文件系统拿清单，不要从 README 的目录树抄。目录树经常滞后于代码，抄错一个文件名，后面所有判断都会偏。

# 在仓库根目录执行
ls -R examples scripts demo 2>/dev/null
find . -maxdepth 3 -name '*demo*' -o -maxdepth 3 -name '*example*'
grep -rn 'if __name__' `--include`=*.py .

把命中的脚本逐个跑一次 help 和默认启动，边跑边填下面这张表。文件名一栏写实际路径，不要写占位符。

观察输出的重点是「有没有可核对的结果」：打印了帧数、写出了结果文件、弹出了可视窗口，都属于可核对；只打印一行启动信息然后退出，属于没验证到任何东西，需要继续看源码确认脚本在做什么。

逐个记录每个示例接受的输入形式

输入形式决定你手上的素材能不能直接喂进去，这是最容易误判的一步。用一条 grep 先分类，再分别验证。

grep -n 'add_argument\|argparse\|open(\|Path(\|VideoCapture\|/dev/' examples/*.py

文件输入

• 验证动作：找到示例里读取路径的位置，把路径改成一个自己准备的样例文件再跑一次。
• 观察结果：能正常读出并进入后续处理，说明这条路径可用；报 FileNotFound 或编码错误，说明格式或路径规则有额外约束，需要记下来。

设备输入

• 验证动作：查看示例里是否出现设备索引、设备路径一类的参数，把索引或路径换一个值再跑。
• 观察结果：换值后能打开并持续出数据，说明设备接入是示例覆盖到的；换值直接报错退出，说明示例只验证过单一设备，多设备需要自己补。

参数输入

• 验证动作：执行 python 示例脚本 `--help`，把列出的参数抄进表格，再挑两三个改值运行。
• 观察结果：参数改了、输出跟着变，说明参数真正生效；改了没变化，说明该参数只是预留位，不能当成已实现能力。

把示例没有覆盖的环节单独列出来

这一节只写能被检索结果证实的缺失项，不用「估计没有」填空。判断依据统一为三类：示例目录里没有对应脚本、源码里 grep 不到相关关键字、代码里只有注释或 TODO。

• 实时流与帧率控制：判断依据是示例中 grep 不到推流或节奏控制相关调用；如果示例只做单次推理，实时链路需要自己搭。
• 鉴权与密钥管理：判断依据是示例里密钥直接写在代码或配置里，没有读取环境变量的分支。
• 多路并发调度：判断依据是示例为单进程顺序处理，没有队列、线程池或任务分发的代码。
• 断线重连与异常恢复：判断依据是示例里没有重试逻辑，出错直接退出。
• 结果持久化与日志：判断依据是示例只打印到控制台，没有写库或写文件的模块。

每一条都在表里写清「检索命令 + 检索结果」，例如 grep -rn 'reconnect' . 无输出，就记为缺失。后面接入时按缺失项排期，而不是按猜测排期。

做一次最小改动测试扩展性

目的不是做功能，而是确认改动落在哪一层最省事。选一个最接近你场景的示例，只改一行。

cd repo
git checkout -b probe/example-extend
# 改动点：把示例里的输入路径或某个参数默认值换成自己的值
python examples/<实际文件名>.py `--help`
python examples/<实际文件名>.py `--input` ./sample

git diff
git checkout -- examples/<实际文件名>.py   # 回退

观察三件事：改动后脚本是否仍能启动；新输入是否走到同一段处理逻辑；报错信息指向配置层还是代码层。如果改一个参数就能达到目的，说明扩展点在配置层，接入成本低；如果需要改示例内部的调用链，说明示例只是演示，接入层要自己写。回退方式统一用 git checkout 恢复单文件，避免把探测改动带进主分支。

整理成接入前的检查表

把前面几节的结论压缩成可执行条目，每条都配一个验证动作，做完打勾再动手写业务代码。

• 示例清单已列全：执行 ls -R examples 与 grep -rn 'if __name__'，确认没有遗漏脚本。
• 每个示例都能启动：逐个执行默认启动命令，记录是否产生可核对输出。
• 输入形式已确认：对文件、设备、参数三类各跑一次，记录成功与失败的具体表现。
• 参数真实生效：改两三个参数值，确认输出随之变化。
• 缺失项有检索依据：每条缺失都附一条 grep 命令和无输出的结果，不写推测。
• 扩展点已定位：最小改动测试通过，并明确改动落在配置层还是代码层。
• 回退路径可用：探测分支和单文件恢复命令都验证过一次。
• 未覆盖环节已排期：实时链路、鉴权、并发、重连这些缺失项，明确由自己补还是暂不需要。

做完这张表，能力边界就是一张有命令、有输出、有回退记录的清单，而不是对功能描述的印象。