当用户要生成连接 token，或要为某个 peer_id （设备） 生成 token 时使用；默认通过 TiRTC DevTools CLI 从环境变量读取 access_id 和 secret_key，并返回 token 与二维码 PNG 路径。
用户侧最小输入只需要：
TIRTC_CONN_ACCESS_IDTIRTC_CONN_SECRET_KEYpeer_idSkill 内部默认：
local_id，则默认使用同一个 peer_id 作为 local_idopenapi_entry、service_entry、TTL、二维码参数默认不要求用户手动传递，只有在用户明确提出时才展开access_id 和 secret_key，而不是直接从命令位置参数接收。TIRTC_CONN_ACCESS_ID、TIRTC_CONN_SECRET_KEY。--access-id、--secret-key 传入。peer_id；local_id 缺省时走内部默认值，不额外打扰用户。access_id、secret_key 直接写入源码、文档、截图或长期配置文件。tokenpayload 或 payloadJsonqrCodePngPathpeer_idlocal_iduser_ttl_secondschannel_ttl_secondsgenerated_at--json 模式运行且宽度足够，可附带 ASCII 二维码open <qrCodePngPath> 后回报结果结果转述必须遵守：
channel_ttl_seconds 总结成“整个 token 的有效期”user_ttl_seconds=<...>、channel_ttl_seconds=<...>、generated_at=<...>npm install -g tirtc-devtools-cli@latest，确保使用的是最新正式版；不要复用未知旧版本peer_id；access_id、secret_key 默认由 CLI 自己从环境变量读取local_id，内部默认令 local_id = peer_id--json 调用 tirtc-devtools-cli token issue <peer_id>，拿到 token 与 qrCodePngPathTIRTC_CONN_ACCESS_ID、TIRTC_CONN_SECRET_KEYopen <qrCodePngPath>当 access_id / secret_key 已在环境变量中时，推荐命令形态：
export TIRTC_CONN_ACCESS_ID="<ACCESS_ID>"
export TIRTC_CONN_SECRET_KEY="<SECRET_KEY>"
tirtc-devtools-cli --json token issue \
"<PEER_ID>"
如果用户明确要求直接在终端看 ASCII 二维码，可去掉 --json，并按需加入：
--qr-error-correction-level <L|M|Q|H>--ascii-max-columns <columns>消费侧工具只需要把诉求收成这类最小表达：
peer_id 生成一个 tokenSkill 内部应自动做这些事：
TIRTC_CONN_ACCESS_ID、TIRTC_CONN_SECRET_KEYnpm install -g tirtc-devtools-cli@latestpeer_idlocal_id = peer_id--json 调用 CLIecho、printenv 或其他 preflight 命令探测环境变量；直接调用 CLI，让 CLI 自己做缺失校验token、qrCodePngPath、peer_id、local_id、user_ttl_seconds、channel_ttl_seconds、generated_atopen <qrCodePngPath>npm install -g tirtc-devtools-cli@latest 后重试TIRTC_CONN_ACCESS_ID / TIRTC_CONN_SECRET_KEY，或在其明确同意时显式提供一次性参数qrCodePngPath