本篇速览综合实战的真正难点不是会用每个组件而是编排决定数据在组件间怎么流、什么节奏流、哪个慢了怎么办。本讲把 AidStream视频、AidLite检测、AidGen/AidGenSE大模型、AidConnect跨系统装成一个智能摄像头解说应用摄像头看画面 → 检测出目标 → 大模型生成中文解说 → 推送到 Android 展示。多组件系统最大的两个工程风险是节奏不匹配大模型慢、检测快帧会堵和资源叠加各组件内存加起来爆掉两者都要在设计期解决而不是跑起来再补。联调的铁律是分阶段先把每一段单独跑通再逐段拼接每接一段就验证一段切忌一次全连通再排错。一、从会用每个零件到攒出一台机器1.1 先盘点一下家底到第 10 讲为止这套工具链的零件你已经逐个摸过了AidLite 管推理底座AIMO/Model Farm 管模型供给AidCV 管图像处理AidStream 管视频流水线AidGen/AidGenSE 管大模型AidConnect 管跨系统通信AidVoice 管语音。每一个你都单独跑通过知道它的接口长什么样、坑在哪里。但请注意一个事实这些实战都是单组件 Demo——一次只让一个组件干活。真实产品从来不长这样。真实产品是多个组件同时运转、互相喂数据、彼此等结果。从会用每个零件到攒出一台能跑的机器中间隔着一道很多教程都不讲的坎系统集成。这一讲就专门过这道坎。1.2 集成的难点不在会在编排为什么单组件都会、攒一起就翻车因为集成引入了一类单组件时不存在的问题——编排orchestration节奏问题视频是 30fps 连续来的检测每帧几十毫秒大模型生成一句话要一两秒。三者节奏完全不同谁等谁帧来了大模型还在忙是丢帧还是排队资源问题每个组件单独跑内存都够一起跑就可能爆。视频缓冲、检测模型、大模型权重、KV Cache全挤在一块板子的内存里。状态问题组件分布在不同进程甚至不同系统Linux/Android它们之间的状态怎么保持一致一个重启了其他的怎么知道依赖问题大模型服务没起好检测就先来了通道没建连结果就要发。启动顺序、依赖等待都得有人管。这些问题单组件教程不会教因为它们只在攒起来时才出现。这正是本讲的价值。1.3 选什么做综合案例智能摄像头解说综合实战需要一个能把所有零件都用上的案例。我们选智能摄像头解说——它在第 5、6、7 讲就埋过伏笔摄像头实时看画面检测到有意思的目标比如有人经过、出现某个物体就让大模型用一句自然的中文把画面说出来推送到 Android 界面上展示。这个案例几乎是工具链的全科考试用AidStream采视频、AidLite跑检测、AidGen/AidGenSE生成解说、AidConnect把结果送上 Android。它不追求功能多花哨而追求链路完整、结构清晰——把这套骨架吃透换成你自己的业务工业巡检、门店客流、园区安防只是替换检测目标和解说逻辑的事。1.4 目标、硬件与做到什么算成先把做成什么样定义清楚免得跑偏。最终效果摄像头对着一个场景当画面里出现设定目标时Android 界面上隔几秒就刷新一句中文解说如画面中有一个人正从左侧走过过程流畅不卡死。硬件用犀牛派 X1QCS8550——要同时扛视频解码、检测推理和大模型需要它的算力与内存。模型沿用第 7、8 讲的 Qwen2.5-0.5B-Instruct 做解说生成检测用一个轻量目标检测模型如 YOLO 系列跑在 AidLite 上。成功的判据在第八节细化为可测的指标这里先记住一句话链路通、节奏顺、不崩溃。二、系统总体设计先画蓝图再动手2.1 数据流总览动手前先把整张蓝图铺开。数据怎么从摄像头一路流到 Android 屏幕一张图看清是否摄像头AidStream采集/解码AidLite目标检测触发判断有新目标?AidGen/AidGenSE生成中文解说AidConnect跨系统通道Android 界面展示解说注意中间那个触发判断菱形——它是整个系统的节拍器。不是每一帧都惊动大模型那样大模型根本忙不过来而是只有画面里出现了值得关注的变化时才调用一次。这个设计决策是系统不卡死的关键第三章会重点讲。2.2 模块划分与职责边界把系统切成几个职责单一的模块每个只做一件事采集检测模块从 AidStream 拿帧、喂给 AidLite 检测、产出当前画面有哪些目标。节奏快跟随帧率。触发决策模块盯着检测结果的流判断值不值得让大模型说一次。做节流与去抖。解说生成模块拿到触发把检测结果组织成 prompt调 AidGenSE 生成解说。节奏慢秒级。结果上报模块把解说文本经 AidConnect 发到 Android。编排器orchestrator把上面几个模块串起来管启动顺序、数据传递、异常兜底。职责边界划清的好处每个模块可单独开发、单独测试出问题能立刻定位到模块。这和前面每讲封装成模块的思想一脉相承只是这次是把多个模块再往上组一层。2.3 线程/进程模型谁快谁慢怎么共处节奏不同的模块不能挤在一个同步循环里——否则大模型生成的那一两秒视频帧就全堵死了。经典解法是生产者-消费者 队列解耦采集检测在一个线程/进程里跑把值得解说的事件丢进一个队列解说生成在另一个线程/进程里从队列取事件慢慢处理。这样检测不被大模型拖慢大模型也不被帧率压垮。队列要有界如果大模型处理不过来事件会堆积。队列满了怎么办常见策略是丢旧留新解说这种场景旧画面的事件丢了就丢了最新才重要或直接丢弃新事件太忙就不添乱。选哪种看业务但队列必须有界、必须有满的策略是铁律——无界队列等于把内存炸弹埋进系统。2.4 资源预算先算账再分配多组件共享一块板子内存是最先撞的墙。动手前粗算一笔视频解码缓冲几帧 × 每帧几 MB 检测模型权重与激活几十到几百 MB 大模型权重0.5B 量化后几百 MB 到 1GB KV Cache随 cl 增长 各进程运行时开销。把这些加起来对照 X1 的可用内存确认有富余。如果紧张优先级是先缩大模型 cl、再缩视频缓冲帧数、再降视频分辨率。这笔账不用精确到字节但先估算、再动手能避免攒起来才发现内存不够返工的尴尬。具体占用以真机实测为准。2.5 配置驱动 vs 硬编码让系统可调多组件系统的参数远比单组件多抽帧率、冷却时间、队列长度、置信度阈值、模型路径、通道名、服务地址……如果硬编码在代码各处联调时改一个参数要翻半天、还容易改漏。工程上的好习惯是配置驱动把所有可调参数集中到一份配置如 6.1 的 CONFIG或独立的 YAML/JSON代码只读配置、不写死数值。好处有三联调改参不用动代码、不同部署开发板/量产机用不同配置、参数一目了然便于审查。多组件系统的复杂度一半来自参数太多太散配置驱动正是治这个病。把哪些该进配置想清楚——凡是可能随场景、随硬件、随部署而变的都该进配置而不是埋进代码。三、关键技术决策把零件连成线3.1 帧的流转与检测节奏视频是连续的但不是每帧都要检测。检测本身要几十毫秒30fps 全检会把算力吃光。常见做法是抽帧检测每秒只取几帧比如 5fps喂给检测既能跟上画面变化又给大模型和其他组件留出算力。抽帧间隔按画面变化多快定——场景稳定就少检变化快就多检。这是第一道节奏调节阀。3.2 “什么时候让大模型说话”触发策略这是整个系统最值得琢磨的设计。如果每检到一个目标就叫大模型大模型会被淹没生成一次要秒级而检测每秒好几次。触发策略要回答什么变化值得说。几个常用思路常组合用目标集合变化当画面里的目标种类/数量发生变化出现了新类别、人走了才触发而不是一直有人就一直说。冷却时间两次解说之间至少间隔 N 秒避免大模型连轴转。显著性过滤太小的框、置信度太低的框不值得解说过滤掉。把这三条叠起来大模型的调用频率就从每秒数次降到画面真有变化时才说一次系统节奏一下就顺了。触发逻辑写成一个独立函数输入检测结果、输出要不要说 说什么的事由便于单测。3.3 检测与 LLM 的衔接从框到话检测输出的是结构化数据一堆框类别、位置、置信度大模型要的是自然语言 prompt。中间需要一道翻译把检测结果组织成大模型能理解的描述。比如把[{person, 左侧, 0.9}, {dog, 中间, 0.8}]组织成 prompt画面左侧有一个人置信度高中间有一只狗。请用一句自然的中文描述这个画面。这道结构化 → 自然语言的转换是视觉和大模型衔接的关键。prompt 里带上位置、数量、类别大模型生成的解说才会有依据、不空洞。3.4 结果上行Linux → Android 的通道设计解说文本要从 Linux 侧送上 Android。这正是第 9 讲 AidConnect 的用武之地解说文本是小数据一句话几十上百字节走 AidConnect 的轻量通道即可不必动用为零拷贝准备的大通道。设计上把结果上报单独成一个模块封装 AidConnect 的连接管理、发送、断线重连复用第 9 讲 6.5 的封装思路。Android 侧收到文本切主线程更新界面——和第 9 讲的接法完全一致。3.5 降级与容错某个零件慢了/挂了怎么办多组件系统必须假设任何零件都可能慢或挂。为每个关键环节想好降级大模型服务暂时不可用是跳过这次解说、还是用一句模板话“检测到 N 个目标”兜底Android 通道断了是缓存结果等重连、还是直接丢弃检测模型加载失败整个系统要不要降级为只预览不解说把这些万一提前想清楚、写进编排器系统才不会因为一个小零件抽风就整体瘫痪。容错设计的核心原则任何一个非核心组件失效系统都应降级运行而非整体崩溃。3.6 数据在组件间怎么过手拷贝、引用还是消息组件之间传数据有三种过手方式选错了性能和正确性都会受影响。一是拷贝把数据完整复制一份给对方简单安全但大数据图像帧拷贝开销大二是引用/共享传一个指向共享内存的句柄或索引第 9 讲的零拷贝思路快但要管好这块内存谁在用、用到什么时候的生命周期三是消息只传一个小描述“第 N 帧在缓冲区的哪个位置、检测结果是什么”数据本体不动动的只是描述。本讲的实践是混合用帧这种大数据走共享/引用别来回拷检测结果、解说文本这种小数据走消息/拷贝。原则一句话大数据传引用小数据传消息能不拷就不拷。四、环境调研组件清单与依赖核对4.1 组件与模型清单把这次要用到的东西列成清单逐条确认就绪组件/资源用途来源/前置讲AidStream视频采集解码第 06 讲AidLite 检测模型目标检测第 02、04 讲AidGenSE Qwen2.5生成解说第 07、08 讲AidConnect结果上行 Android第 09 讲摄像头画面来源第 05、06 讲每一项都应在前序章节单独跑通过。若有任何一项还没验证先回到对应讲把它跑通再回来——综合实战不是验证单组件的地方。4.2 版本对齐总表终极版到这一讲版本总表已经攒了不少行。把它更新到终极版QNN 版本、AidLite 版本、AidStream 插件版本、AidGen/AidGenSE 版本、AidConnect 版本Linux/Android 两侧、检测模型版本、大模型版本全部对齐并记录。多组件系统里版本错配的概率比单组件高得多——任何一个组件版本对不上链路就断在那一环。这张表是联调期排障的第一参考。4.3 资源预算落地各组件限多少把 2.4 的粗算落成具体限额视频缓冲限几帧、检测每秒限几帧、大模型 cl 限多大、解说队列限多长。把这些写成配置项而不是散落代码里的魔法数字联调时改起来方便也能一目了然看到资源都分给谁了。资源限额是系统稳定的第一道闸宁可保守起步再逐步放开。五、操作步骤分阶段搭建与联调铁律先立不要试图一次把整个系统连通再调。分四个阶段每阶段独立验证通过再进下一段。5.1 阶段一视频采集 检测跑通先把 AidStream 采集和 AidLite 检测接起来摄像头出画面检测实时出框在 Linux 侧能把框画到画面上复用第 6 讲的管线。这一阶确认看得清、检得出且不涉及大模型和 Android问题域最小。5.2 阶段二接入大模型生成解说在阶段一基础上加触发判断和解说生成检测到目标变化时组织 prompt 调 AidGenSE把生成的解说打印到 Linux 终端。这一阶确认检得出 → 说得出重点调触发策略别太频繁和 prompt解说要言之有物。先在终端看效果不接 Android。5.3 阶段三结果上 Android 展示把解说文本经 AidConnect 推到 Android 界面。这一阶确认说得出 → 看得见重点调通道的稳定断线重连和 Android 侧的 UI 更新切主线程。到这一步端到端链路就通了。5.4 阶段四加节流与容错成型最后把节奏调顺、把容错补齐抽帧间隔、冷却时间、队列上限、降级策略都配上做压力测试连续跑、目标频繁变化观察是否卡顿、是否内存爬升。这一阶把能跑打磨成跑得稳。5.5 联调顺序的纪律四阶段顺序不能乱背后是排障效率的考量每接一段就验证一段出问题时你确切知道是新接的这段出了问题而不是在五个组件里大海捞针。这条分而治之、逐段验证的纪律是一切多系统集成的通用心法远比记住本讲的具体代码重要。5.6 一份可复用的联调清单把四阶段联调落成一份可勾选的清单以后做类似系统可直接复用每路组件单独跑通采集 / 检测 / 大模型 / 通道各自验证过版本总表对齐依赖检查脚本通过4.2、4.4阶段一采集 检测出框帧率达标阶段二触发 解说终端能看到合理文本阶段三解说上 Android显示正确、断线能重连阶段四节流 / 容错配齐压测不卡、内存不涨埋点日志能看清每环耗时与队列长度8.5优雅启停反复 start/stop 无资源泄漏6.6把联调从凭经验摸索变成按清单逐项确认效率和覆盖率都会高得多。这份清单和第 12 讲的量产验收清单是上下衔接的——联调清单管拼得对不对量产清单管跑得久不久。4.4 依赖检查脚本联调前先过一遍在正式联调前用一个脚本把所有依赖自动检查一遍能省下大量东漏一个西缺一个的时间。脚本要做的事检测模型文件是否存在、大模型服务是否探活对 8888 发一个最小请求、AidConnect 通道能否建连、摄像头设备是否可打开。每一项通过打勾、失败给出明确提示。把这个脚本作为联调的第 0 步跑通了再进四阶段——很多系统不起来的问题其实是某个依赖压根没就绪而脚本能在 10 秒内告诉你缺的是哪一个。六、关键代码主编排器下面给一个把各模块串起来的编排器骨架。各组件 API 以官方文档为准这里重点看编排结构初始化 → 检测循环 → 触发 → 解说 → 上报。6.1 配置与组件初始化# orchestrator.py —— 智能摄像头解说 编排器骨架API 以官方文档为准importqueue,threading,time CONFIG{detect_fps:5,# 抽帧检测每秒检几帧cooldown_s:4,# 两次解说最小间隔queue_max:4,# 解说事件队列上限min_conf:0.5,# 置信度阈值llm_url:http://127.0.0.1:8888/v1/chat/completions,model:qwen2.5-0.5b-instruct,channel:caption,# AidConnect 通道名}event_qqueue.Queue(maxsizeCONFIG[queue_max])# 有界队列解耦快慢两端把所有节奏与资源参数集中在 CONFIG联调时只改这里。6.2 检测循环 触发判断生产者defdetection_loop(detector,frames):last_labelsset()last_fire0.0forframeinframes:# AidStream 帧流已抽帧到 detect_fpsdetsdetector.infer(frame)# AidLite 检测labels{d.labelfordindetsifd.scoreCONFIG[min_conf]}nowtime.time()# 触发目标集合有变化 且 过了冷却期iflabels!last_labelsandnow-last_fireCONFIG[cooldown_s]:try:event_q.put_nowait({labels:sorted(labels),ts:now})last_firenow last_labelslabelsexceptqueue.Full:pass# 队列满则丢弃本次保护大模型生产者的职责是快检测、判断、丢事件绝不等大模型。队列满了就丢这是保护慢端的关键。6.3 调 LLM 生成解说消费者importrequestsdefcaption_loop(channel):whileTrue:evevent_q.get()# 阻塞等事件不忙时自然休眠prompt(画面中出现以下目标、.join(ev[labels])。请用一句简洁自然的中文描述这个监控画面。)try:rrequests.post(CONFIG[llm_url],json{model:CONFIG[model],messages:[{role:user,content:prompt}],},timeout60)captionr.json()[choices][0][message][content]exceptException:caption检测到、.join(ev[labels])# 降级模板话兜底channel.send_text(caption)# 上报 Android消费者从队列取事件、调大模型、上报。大模型挂了就用模板话兜底不让链路断。6.4 经 AidConnect 上报复用第 9 讲封装classResultChannel:# 复用第 9 讲的通道封装思路def__init__(self,name):importaidconnect self.chaidconnect.create_channel(namename,roleserver)self.ch.wait_connected(timeout10)defsend_text(self,text):try:self.ch.send(text.encode(utf-8))exceptException:self.reconnect()# 断线重连defreconnect(self):pass# 重连逻辑见第 9 讲6.5 组装主函数defmain():channelResultChannel(CONFIG[channel])detector,framesinit_pipeline()# 初始化 AidStream AidLitetthreading.Thread(targetcaption_loop,args(channel,),daemonTrue)t.start()# 消费者在后台线程跑detection_loop(detector,frames)# 生产者在主线程跑if__name____main__:main()两个线程、一个有界队列快慢两端解耦——这就是整个系统的骨架。真正的工程细节帧的解码、检测后处理、通道重连填进各函数即可但生产者-消费者 有界队列这个结构是灵魂。6.6 优雅启停与资源释放产品要能干净地启动和停止。启动时按依赖顺序拉起先 AidGenSE 服务、再通道、再检测管线停止时先停帧流、再清空队列、再关通道、最后释放模型。用 try/finally 或上下文管理器确保异常时也能释放资源显存、内存、文件句柄。能干净地停和能跑起来同等重要——量产时进程要被反复启停资源泄漏会在长跑后爆发。6.7 把解说做成流式推送6.3 里解说是生成完一整句才上报Android 要等一两秒才看到完整一句话。可以做得更好利用第 8 讲的流式 SSE让大模型边生成、Android 边逐字显示打字机效果。改法是caption_loop里把非流式请求换成流式请求每收到一个增量就经 AidConnect 推一小段给 AndroidAndroid 侧追加显示。这样用户从画面变化到看到第一个字的等待大幅缩短体验接近实时对话。代价是通道消息变多每 token 一条但文本极小AidConnect 完全扛得住。要不要上流式看产品对响应感的要求——监控解说这种场景流式是明显的体验加分项。6.8 一份完整的配置文件长这样把 CONFIG 落到一份独立文件如config.yaml便于审查与分部署管理# config.yaml —— 智能摄像头解说 配置detect_fps:5# 抽帧检测帧率cooldown_s:4# 两次解说最小间隔(秒)queue_max:4# 解说事件队列上限min_conf:0.5# 检测置信度阈值llm:url:http://127.0.0.1:8888/v1/chat/completionsmodel:qwen2.5-0.5b-instructtimeout_s:60channel:name:caption# AidConnect 通道名role:servercamera:device:/dev/video0resolution:[1280,720]把这份配置纳入版本管理每次改动有迹可循不同部署开发板 / 量产机各维护一份启动时加载对应那份。配置即文档——看这份文件就知道系统当前是怎么调的也为第 12 讲的量产部署打好了环境可分的基础。七、坑点7.1 帧率被大模型拖垮节奏不匹配最经典的坑把检测和大模型写在一个同步循环里大模型生成的那一两秒视频全卡住。对策就是 2.3/6.2 的生产者-消费者解耦——检测绝不等大模型靠有界队列传递。出现画面卡先查是不是快慢两端没解耦。7.2 内存叠加爆掉每个组件单跑都够一起跑就崩——资源叠加没算2.4。对策先缩大模型 cl、再减视频缓冲帧、再降分辨率把各组件内存限额写进 CONFIG 并监控实际占用。内存问题要在设计期解决别等跑了才补。7.3 触发过于频繁 / 解说抖动解说刷得太快、内容反复横跳是触发策略没做好3.2。对策加冷却时间、要求目标集合稳定变化再触发、过滤低置信度框。让大模型少而精地说比喋喋不休体验好得多。7.4 跨进程 / 跨系统状态不一致大模型服务没起好检测就来了、通道没连上结果就发了——启动依赖没管好。对策编排器按依赖顺序启动并做就绪检查服务探活、通道 wait_connected未就绪不进入主循环。7.5 一个组件崩全链路瘫某个非核心组件如解说生成挂了整个系统跟着死。对策按 3.5 做降级——非核心组件失效时系统降级运行如只检测不解说、用模板话兜底核心链路采集→检测保持可用。7.6 调试多组件的方法论缩小问题域多组件系统排障最大的陷阱是在五六个组件里漫无目的地找。正确的心法是持续缩小问题域先用埋点日志8.5定位是哪一环异常——是检测、大模型、还是通道再把那一环单独抽出来复现检测异常就用固定图片单测检测大模型异常就用固定 prompt 单测服务通道异常就用第 9 讲的回环测试单测通道。把系统级的问题降解成单组件的问题而单组件问题你早就会解了。这套定位到环 → 抽出来单测的动作和第五章的分阶段联调是同源思想——都拒绝整体揉在一起调坚持分而治之。记住一句在多组件系统里找到问题出在哪一环往往比修复它更难、也更关键。八、验证端到端跑起来8.1 功能正确性对着摄像头制造几个已知场景没人、一个人走过、出现特定物体看 Android 上的解说是否与实际相符、是否在该说的时候才说。正确性首先看说的对不对其次看说的时机对不对。8.2 端到端延迟分解从画面出现变化到Android 显示解说的总延迟拆开打点检测耗时 触发判断 大模型生成 通道传输 UI 刷新。大头通常是大模型生成秒级其余都是毫秒级。知道时间花在哪才知道优化哪——这个场景里延迟基本由大模型决定优化方向是缩 cl、换更小模型或减少调用频率。8.3 帧率与资源占用跑稳后看两项检测通路的实际帧率是否达到 detect_fps、有没有被拖慢和整体内存占用是否有富余、长跑是否爬升。这两项直接反映节奏顺不顺、资源够不够。长跑几小时观察内存是否泄漏6.6。8.4 异常对照表综合系统出问题按现象对号入座“画面卡死” → 快慢端没解耦7.1“跑一会儿崩” → 内存叠加或泄漏7.2、6.6“解说刷屏/抖动” → 触发策略7.3“启动就乱” → 依赖顺序7.4“大模型一挂全瘫” → 缺降级7.5“Android 收不到” → 通道未连或断开5.3、第 9 讲。多组件系统排障的第一原则是先定位到哪一环再深挖那一环。8.5 多组件系统的可观测性给每一环埋点单组件出问题好查多组件出问题常卡在不知道是哪一环慢了、哪一环错了。解法是可观测性在每个关键环节埋点记录——每帧检测耗时、每次触发的理由、每次大模型调用的延迟、每次上报的成功与否、队列的实时长度。把这些指标定期打进日志或暴露成一个简单的查询接口出问题时翻一眼就知道瓶颈在哪。比如发现队列持续满说明慢端跟不上、该调节奏发现大模型延迟飙升说明资源不够。可观测性不是锦上添花而是多组件系统的仪表盘——没有它你就是在盲开。量产阶段更系统的监控与告警第 12 讲会展开。8.6 把这次实战变成回归基线这套端到端系统跑通后别急着拆——把它固化成一份回归基线。做法固定几个测试场景无人、单人经过、特定物体、固定预期结果该触发几次、解说大意写成可重复执行的验收用例。以后每次升级某个组件换检测模型、换大模型版本、改触发参数都用这套基线跑一遍立刻知道这次改动让端到端效果变好还是变坏。单组件有单组件的基线第 8 讲的 LLM 验收、第 10 讲的语音测试集系统也要有系统级基线——它衡量的是拼起来之后的整体表现这是任何单组件基线都替代不了的。到第 12 讲量产这份基线会是你每次升级决策的依据。九、FAQQ1为什么一定要解耦直接顺序调用不行吗顺序调用意味着快组件要等慢组件。视频 30fps、大模型秒级顺序执行会让视频被大模型拖死。生产者-消费者加有界队列让两端各按各的节奏跑是实时多组件系统的标准解法。Q2队列设多大合适看慢端的处理速度和解说的时效性。解说这类旧事件意义不大的场景小队列3~5加满则丢弃即可若每个事件都必须处理则要更慢的触发或更快的慢端而不是无限加大队列。Q3检测模型和解说大模型能同时放内存吗能但要把两者的内存占用加起来对照板子内存2.4、4.3。紧张时优先缩大模型 cl、再缩视频缓冲。X1 跑轻量检测 0.5B 大模型通常可行以实测为准。Q4这个案例能换成我的业务吗完全可以。把检测模型换成你的目标缺陷、客流、车牌把 prompt 换成你的解说逻辑把触发条件换成你的业务规则骨架不变。本讲的价值就在这副可复用的骨架。Q5语音能加进来吗能。把第 10 讲的 ASR 接成另一路输入“听到指令 → 触发特定解说”或把解说文本经 TTS 读出来。注意语音和大模型都吃算力资源预算要重算。Q6为什么用 AidConnect 而不是直接 Android 调 AidGenSE 的 HTTP两者都行。若 Android 能直连 Linux 的 8888 端口用 HTTP 更省事AidConnect 的优势在跨系统大数据零拷贝第 9 讲。本案例解说文本很小HTTP 或 AidConnect 轻量通道均可按你的部署形态选。Q7多路摄像头怎么办每路一套采集检测事件汇入同一个或各自的队列但要重新核算算力与内存——多路是资源的倍数级增长。大模型通常仍是共享的一个触发策略要更严格。Q8触发判断能用大模型做吗可以但通常不值——触发要高频低成本用大模型做触发等于每次都调用违背节流初衷。触发用规则/小模型大模型只负责值得说时怎么说。Q9怎么测试触发策略好不好录几段典型场景的视频离线跑触发逻辑统计触发次数、漏触发、误触发和人工标注对比。把触发策略做成可离线回放测试的纯函数迭代会快很多。Q10这套系统怎么变成能交付的产品那就要解决进程守护、开机自启、日志监控、远程升级这些量产问题了——正是下一讲的主题把综合实战这台能跑的机器变成能交付、能长期稳定运行的产品。十、结论这一讲我们把前九讲的零件真正装配成了一台机器AidStream 采视频、AidLite 跑检测、AidGen/AidGenSE 生成解说、AidConnect 把结果送上 Android一个智能摄像头解说的端到端应用就跑起来了。但比这个应用本身更重要的是你掌握了多组件集成的通用方法论先画数据流蓝图、再划模块边界、用有界队列解耦快慢、给每个零件想好降级、然后分阶段逐段联调。这套方法论不绑定本讲的具体案例——把检测换成你的业务目标、把解说换成你的生成逻辑骨架照样成立。可以说到这里你已经具备了用这套工具链做一个完整端侧 AI 应用的全部技术能力。剩下最后一块拼图Demo 跑得再好也只是能跑。要把它变成能交付、能 7×24 小时稳定运行、能远程维护升级的产品还有一段工程化的路要走——进程守护、日志监控、量产升级。这正是下一讲、也是本系列收官之作要解决的问题从综合实战到量产部署。本文多组件编排结构、AidStream/AidLite/AidGenSE/AidConnect 的组合用法参考 AidLux 官方文档与前序各讲生产者-消费者、有界队列、触发节流等为实时系统通用工程方法帧率、延迟、内存占用等指标随模型、算力与场景而异精确值以真机实测与当前版本文档为准。文中 API、类名、代码为结构示意具体以各组件 SDK 与官方文档为准。