个人笔记

外观

eboxcli 20分钟宣贯 PPT 逐页讲稿版 ​

使用方式 ​

  • 每页按“展示内容 + 讲稿 + 强调句 + 转场句”执行
  • 默认总时长 20 分钟，已包含 1 分钟机动时间
  • 若时间不足，优先保留第 1/3/5/8/10 页

总体时间安排 ​

  • 第 1-2 页：2 分钟（背景与目标）
  • 第 3-4 页：4 分钟（架构与能力地图）
  • 第 5-7 页：7 分钟（现场演示）
  • 第 8-9 页：5 分钟（扩展与规范）
  • 第 10 页：2 分钟（落地与行动）

第 1 页：标题页与结论先行（1 分钟） ​

页标题建议：eboxcli：统一命令入口与可扩展调试能力平台

页面展示内容：

  • 一句话定位：统一入口 + 插件化扩展
  • 一句话价值：提效联调、标准化排障、低成本扩展

讲稿（可直接读）：
今天这 20 分钟我只讲一件事：为什么 eboxcli 应该成为我们调试与联调的统一入口。
它的价值不在“命令多”，而在“标准统一”：统一命令、统一排障路径、统一扩展方式。

强调句：
eboxcli 不是一个工具集合，而是协作标准。

转场句：
先看我们过去的问题，为什么需要统一入口。

第 2 页：为什么要做（1 分钟） ​

页面展示内容：

  • 过去痛点：工具分散、命令口径不一致、排障路径不统一
  • 当前目标：一套命令体系覆盖观测、发布、调用、扩展

讲稿（可直接读）：
过去同一个问题，研发、测试、联调常用不同脚本和不同命令，导致“问题描述一致，但复现路径不一致”。
eboxcli 的目标是把常见动作统一成标准命令，让排查和协作都可复制。

强调句：
统一入口的核心收益是“降低沟通损耗”。

转场句：
有了目标之后，下一步看它是怎么实现可扩展的。

第 3 页：架构总览（3 分钟） ​

页面展示内容：

  • 执行链路：eboxcli -> plugin -> verb
  • 核心组件：PluginManager、IPlugin、Verb、VerbRegistry
  • 关键机制：动态库加载 + 工厂注册

讲稿（可直接读）：
从调用上看，用户输入主命令后，PluginManager 负责发现并加载插件动态库，然后把对应 verb 注册进 CLI。
从扩展上看，新增能力只需要新增插件或 Verb，不需要改动主程序核心。
这就是它“低耦合、可演进”的关键。

强调句：
新增能力优先走“加插件/加 Verb”，而不是改主流程。

转场句：
了解架构后，接下来看它今天已经覆盖了哪些能力。

第 4 页：能力地图（1 分钟） ​

页面展示内容：

  • topic：list/info/echo/hz/bw/delay/pub
  • service call：请求-响应链路调用
  • 双传输支持：ZMQ 与 Iceoryx

讲稿（可直接读）：
能力可以归纳成两大类：
第一类是 Topic 观测与诊断，第二类是 Service 调用验证。
再加上 ZMQ 与 Iceoryx 双通路，基本覆盖了我们联调和排障的高频动作。

强调句：
先把高频动作标准化，再讨论高级自动化。

转场句：
下面用三段演示，快速走完“查、测、验”闭环。

第 5 页：演示 1 - 观测链路（3 分钟） ​

页面展示内容（命令）：

bash
./eboxcli -h
./eboxcli topic list
./eboxcli topic echo pub_sub_server11 /aa/bb/ datacenter.proto.TestData

讲稿（可直接读）：
第一步先看命令入口是否完整，也就是 -h 能看到对应插件。
第二步用 topic list 确认资源存在。
第三步 topic echo 直接看消息内容，验证“有没有数据、类型对不对”。

强调句：
排障第一原则：先确认“可见性”，再确认“正确性”。

转场句：
消息看到了，下一步就进入性能维度：频率、带宽、时延。

可删减内容（时间不足时）：
可只演示 topic echo，其余命令口头说明。

第 6 页：演示 2 - 性能诊断（2 分钟） ​

页面展示内容（命令）：

bash
./eboxcli topic hz pub_sub_server11 /aa/bb/ -w 100
./eboxcli topic bw pub_sub_server11 /aa/bb/
./eboxcli topic delay pub_sub_server11 /aa/bb/ -w 100

讲稿（可直接读）：
hz 看发送节奏是否稳定，bw 看吞吐是否异常，delay 看链路时延是否可接受。
窗口参数建议从 100 起步，先看趋势，再看极值，不要只盯单次波动。

强调句：
同一条链路至少看三个指标，单指标结论容易误判。

转场句：
性能初筛后，我们再看如何主动注入测试数据并验证调用链路。

第 7 页：演示 3 - 注入与调用（2 分钟） ​

页面展示内容（命令）：

bash
./eboxcli topic pub data_channel position_data Position --r 10 --t 100
./eboxcli service call --channel cmd_channel --req-type SetSpeed --rsp-type SetSpeedAck --req-data "{speed:100}"

讲稿（可直接读）：
topic pub 用来主动构造输入流量，帮助快速复现或回归。
service call 用来确认请求-响应链路是否可用，特别适合接口联调阶段。

强调句：
“能注入 + 能调用”意味着我们具备了最小闭环验证能力。

转场句：
会用只是第一步，接下来讲研发如何在这套框架上扩展新能力。

第 8 页：研发扩展路径（4 分钟） ​

页面展示内容：

  • 新插件 5 步法：目录、类、导出、Verb 注册、CMake
  • 常见宏：EXPORT_CLI_PLUGIN、REGISTER_VERB_FOR_PLUGIN
  • 传输扩展：新增 message_type 的注册要求

讲稿（可直接读）：
扩展时建议固定为 5 步：先建目录，再实现 IPlugin，再导出工厂函数，然后新增 Verb 并注册，最后补 CMake 输出与安装。
如果是 Iceoryx 通路，还要保证消息类型与 Subscriber 工厂注册完整。
这样新能力可以独立演进，不会影响主命令稳定性。

强调句：
扩展流程标准化，才能把个人经验变成团队产能。

转场句：
扩展能力落地后，还需要统一规范，避免“同框架不同写法”。

第 9 页：规范与 FAQ（2 分钟） ​

页面展示内容：

  • 命名规范：插件小写、Verb 类后缀、库命名规则
  • 常见问题：-h 不可见、--iox 失败、消息无法解析
  • 统一排障顺序：入口可见 -> 资源可见 -> 数据可见 -> 性能诊断

讲稿（可直接读）：
规范的目的不是约束，而是保障跨团队协作效率。
建议把排障顺序固定成四步，这样不同角色交接时上下文一致，避免重复劳动。

强调句：
口径统一比技巧更重要，流程统一比经验更可复制。

转场句：
最后给出两周内可以执行的落地动作。

第 10 页：落地计划与行动项（2 分钟） ​

页面展示内容：

  • 两周计划：上手卡片、扩展模板、示范改造
  • 行动要求：
    • 使用侧：每人完成 1 次 topic 排障演练
    • 研发侧：每组完成 1 个 Verb 扩展示例

讲稿（可直接读）：
第一周解决“会用”，第二周解决“会扩展”。
宣贯结束不是终点，关键是把动作转成可考核、可复用的产出：演练记录、模板工程、示范插件。

强调句：
宣贯的交付物不是 PPT，而是统一的工程行为。

结束语：
我们今天达成的共识只有一个：以后优先用统一命令解决问题，再讨论脚本和个性化工具。

讲师速记（可复制到备注区） ​

开场白（30 秒） ​

今天不讲“更多命令”，只讲三件事：统一入口、标准排障、低成本扩展。20 分钟后大家至少能做到：会查、会测、会扩展。

收尾话术（30 秒） ​

eboxcli 的核心不是命令本身，而是协作标准。只要大家按同一套插件与命令规范演进，后续需求接入成本会持续下降。

基于 VitePress 构建

Copyright © 2026 ww1820