轻AI越影视觉开发板：Sensor与AI组件教程

进击的雷神

974人浏览 · 2026-11-11 17:48:36

进击的雷神 · 2026-11-11 17:48:36 发布

适用对象：第一次接触端侧视觉开发，想把 Sensor 和 AI Component 串成具体场景的开发者。

验证方式：【轻AI越影视觉开发板】出厂预烧系统、串口终端、LCD 实时预览与现场抓拍。本文把“官方文档可确认的内容”和“我这台设备的现场观察”分开写；源码编译以当前官方构建章节和 sample README 为准。

一、从一个很小的真问题开始

我给这次体验定了一个很窄的目标：桌上放一块带摄像头的小屏，如果有人靠近，设备能认出来，并且留下一张现场照片。网络可连可不连，视频不要先上传到云端，识别和抓拍尽量在设备本地完成。

这个目标听起来不复杂，真正动手时会碰到三个关键点。

第一，摄像头必须先把画面稳定送出来。没有这一帧画面，后面的 AI 没有输入。

第二，屏幕上的“有人”不能靠肉眼判断，要变成终端里看得见的结构化结果，比如 human=1。

第三，结果要能触发动作。只有日志没有用户价值，至少要能抓拍；需要远程通知时，再接消息渠道。

把这三件事串起来，正好对应官方给出的 Sensor 和 AI Component 两个示例。下面按实际调试顺序展开。

图 1 整体体验路线

二、开箱：【轻AI越影视觉开发板】适合“先把链路跑通，再慢慢长产品”

套件到手后，我先把模块摊开看了一遍。主控核心板、摄像头、LCD 屏、WiFi 和 4G 扩展板是分层组合的，接线和固定方式比较直观。对第一次上手的人来说，这种模块化形态有一个好处：哪一段没有出图，可以很快把问题缩到单个模块，不用一上来就怀疑整套设备。

图 2 【轻AI越影视觉开发板】套件

我这次只用了单摄像头、LCD 和本地终端，没有把 4G 模块接进来。桌面看护原型对带宽要求不高，先把本地链路跑顺更重要。

我实际把它放在书桌右后侧：屏幕朝着座位，摄像头斜对门口，镜头高度约 75cm，与进门路线保持一个不大的夹角。这样人走到桌边时，上半身会自然进入画面，不用刻意站到镜头正前方。这个摆位是试出来的，不是唯一答案，但它同时满足了三件事：不挡桌面、能拍到人脸、还能保留身体轮廓。

如果只是做演示，把设备平放在显示器旁边就够了。但要把“有人靠近—识别—抓拍”跑顺，摄像头的高度和朝向比参数表更值得先调。镜头过低时容易只拍到腿，过高时又容易把脸拍变形。

图 3 硬件模块关系

接口布局可以对照下面这张示意图先认一遍。实际接线时仍以随板硬件资料为准，尤其是摄像头排线的方向和卡扣位置，插反或没有压紧都很容易表现为黑屏。

图 4 主板接口布局示意

这张图只用来认位置，不按比例。主控核心板居中，Sensor、LCD、WiFi、4G 是围绕核心板组合的扩展层；左边是 Type-C 供电、USB2.0 通讯和 Debug 串口，右边是网口和 TF 卡槽，下边是接 LCD 的 40PIN 排母和喇叭口。真正接线时，我会先断电，再把排线完全插入并确认卡扣压紧，最后上电。

我接线时只抓三个检查点：摄像头 FPC 是否完全插入并压紧、LCD 排线是否对准方向、上电前扩展板是否已经固定到位。看起来都是小事，但任何一个没做好，最后看到的都是同一块黑屏，很容易把时间浪费在源码和模型上。

开机后先确认三件事

LCD 能进入主页，点开视频预览后有实时画面。
串口或 SSH 能登录系统，终端命令有正常回显。
【轻AI越影视觉开发板】联网后能拿到局域网地址，方便从电脑访问或传文件。

这台【轻AI越影视觉开发板】开机时屏幕时间显示为 1970-01-01。这是联网前系统时间尚未同步时的现场现象。我这次用到的预览、检测和抓拍都不依赖正确日期；设备是否带独立 RTC、具体由哪个服务完成校时，数字FAE 的知识库没有给出明确依据，最终应以硬件指南和系统服务说明为准。

WiFi 配网可以用手机通过 BLE 完成。串口现场日志里能看到 Ble-Wifi 广播；数字FAE 的知识库中，WS53 的示例广播名是 ble_wifi_config，说明广播名会随模组和固件版本变化，做自动化时不要硬编码一个固定名称。扩展板使用 WS73 时不支持 5GHz，配网应选择 2.4GHz 网络。这个细节看起来小，实际很容易卡住人：手机能搜到热点，但把 5GHz 密码发过去，设备仍然上不了网。

三、Sensor：先让【轻AI越影视觉开发板】稳定“看见”

Sensor 示例的价值不只是“摄像头能亮”。它把一条媒体通路完整跑出来了：

摄像头采集 → VI 视频输入 → VPSS 视频处理 → VO 显示或 RTSP 推流

从这条链路的设计看，AI 检测应从 VPSS 处理后的画面里取帧，而不是另外接一颗摄像头。数字FAE 的知识库没有给出 sample 级的逐行说明，所以这里先按媒体通路的职责划分理解；Sensor 这条链路不通，AI Component 再正确也没有可靠输入，这一点在我的现场调试顺序里也成立。

图 5 Sensor 媒体通路

我一开始也想跳过出图，直接跑检测看“能不能认人”。结果终端没有结果，屏幕上也没有可用画面，排查时同时怀疑模型文件、摄像头和命令参数，反而更慢。后来把顺序改回“先看本地屏幕，再拉 RTSP，最后跑检测”，问题就变得很简单：每一步只回答一个问题。

我实际验证的顺序

先把摄像头排线插到位，卡扣压紧，再给设备上电。LCD 进入主页后打开视频预览，画面能实时出现，说明这台设备从采集、处理到显示这一段已经通了。这里记录的是“最终结果”，不是对 VI、VPSS、VO 每一级单独打点；如果我需要确认首帧时延或每一级是否掉帧，会改用官方 quick_start_demo，它在 VI 和 VPSS 取帧处打印 PTS，并把阶段时间戳写入内核日志，更适合做链路级测量。

图 6 LCD 实时预览

接着在电脑上验证 RTSP。先通过串口执行 ifconfig 确认设备的局域网地址，再用 VLC 打开：

rtsp://<设备IP>:554/livestream/0

有线网络最省事，WiFi 也可以用，但调试阶段不要让网络问题混进来。先确认本地屏幕有画面，再排查推流地址，定位会快很多。数字FAE 的知识库只确认了方案和 push_stream sample 支持 RTSP，没有给出统一默认 URL，因此上面是这台设备现场看到的地址，不应直接当成所有固件版本的固定值。

如果要从源码编译示例，官方“构建首个项目”章节会把目标拆成板卡、应用分类和案例名。公开文章里不写死具体板卡标识，先保留为 <板卡构建目标>，实际值以当前 SDK 的构建章节为准。基本形式是：

bash scripts/build.sh build --target <板卡构建目标> samples base

base 只是文档中的入门案例，编译 sensor/single 时把案例路径换成对应目录。数字FAE 的知识库中没有查到 -DSENSOR 这个编译参数的取值说明，所以我把它从“可直接照抄的官方命令”降级为待核对项。构建前应查看当前分支的 sensor/single/README.md 和构建脚本帮助。这也是我更愿意先验证出厂固件、再动源码的原因：把“接线问题”和“配置问题”分开。

这一段最容易踩的坑

现象	我优先检查什么	处理方式
LCD 黑屏	摄像头排线是否压紧，方向是否正确	断电重插，确认卡扣到位后再上电
有系统界面，没有摄像头画面	使用的是出厂固件还是自编 sample	先用出厂预览确认硬件，再核对 sample README
电脑打不开 RTSP	设备是否联网，IP 是否变化	串口执行 ifconfig，重新确认地址
屏幕时间回到 1970 年	当前系统时间尚未同步	不影响本地预览和检测，联网后观察时间是否更新

四、AI Component：把“画面里有人”变成可用的数据

AI Component 的重点不是屏幕上出现一个很酷的框，而是让应用拿到可判断的结果。当前出厂系统里，我通过 fw_cli 调用检测任务，终端返回的是类别和数量。

整个调用可以拆成四步：创建任务、启动任务、订阅结果、销毁任务。

/root/fw_cli aidetect_create /root/det_hvf_hor.bin

/root/fw_cli aidetect_start 0

/root/fw_cli aidetect_listen 0 5

/root/fw_cli aidetect_destroy 0

aidetect_listen 0 5 在我的现场输出中出现了 6 帧汇总。数字FAE 的知识库中没有这个 CLI 命令的参数说明，不能仅凭输出反推出“5 一定代表 5 帧”或“6 是包含首帧”。我只把它当作“连续观察一小段并输出汇总”的命令；后面的判断依赖日志本身，不把尚未核实的参数语义写进结论。如果要做严谨测试，应以当前固件自带的 CLI 帮助和源码实现为准。

站到镜头前，把距离控制在约一米，让上半身完整入镜。终端给出的结果是：

[aidetect] 6 frames: 1 objects — human=1

图 7 人形检测日志

把构图再调整一下，让脸和上半身都清楚出现在画面里，结果变成：

[aidetect] 6 frames: 2 objects — face=1 human=1

图 8 人脸与人形同时识别

图 9 上半身入镜画面

这组结果说明了一个很实用的边界：检测结果与拍摄距离、目标大小和构图有关。只把脸凑得很近，脸占据了大部分画面，未必会稳定得到单独的人脸结果；退到合适距离、保留上半身轮廓，反而更容易同时拿到人脸和人形。

另外要分清“检测”和“识别身份”。接口文档中有 OT_AIDETECT_CLASS_FACE，表示“人脸”这一检测类别；但 face=1 这个终端字段的精确语义并没有在数字FAE 的知识库中找到。按现场输出，我最多把它解释为“这一轮结果里出现了人脸类目标”，不能解释为已经知道这个人是谁。要做门禁或家庭成员识别，还需要人脸注册、特征比对和权限管理；数字FAE 的知识库也没有给出这套身份识别流程，不能把通用检测模型直接当成身份系统。

模型决定能力边界

数字FAE 的知识库明确给出：det_hvf_hor.bin 支持人脸、人形、机动车三类，最大支持三类；推荐阈值分别是人脸 0.4、人形 0.62、机动车 0.63。det_pet_hor.bin 和 det_pkg_hor.bin 分别面向宠物和包裹，单类推荐阈值是 0.7 和 0.55。来源是 SVP 开发参考中的 ot_aidetect_threshold 数据结构和模型阈值表。

画面里出现模型没有覆盖的类别时，结果可能是 0 objects。这不一定是算法坏了，更可能是我拿错了模型。数字FAE 没有提供这些模型的统一下载入口，因此换模型前应对照当前 SDK 的 ot_aidetect_threshold 文档和实际模型目录，确认文件名、类别和阈值完全匹配。下面这张表按接口文档整理，下载路径仍以当前 SDK 的发布包为准。

模型文件	文档中的类别	推荐阈值	适合验证什么
det_hvf_hor.bin	人脸、人形、机动车	0.4 / 0.62 / 0.63	当前桌面看护场景
det_hvf_ver.bin	人脸、人形、机动车	人脸 0.4；其余以当前 SDK 表为准	另一版检测配置
det_hv_hor.bin	人形、机动车	以当前 SDK 表为准	不启用人脸分支
det_hv_ver.bin	人形、机动车	以当前 SDK 表为准	另一版人形配置
det_pet_hor.bin	宠物	0.7	宠物看护
det_pkg_hor.bin	包裹	0.55	包裹、快递场景

预烧整机和 sample：先把边界说清楚

这次主要用出厂整机验证实时画面检测和抓拍。源码里的 ai_component 示例，官方说明只写到“调用 NPU/SVP 实现目标检测与识别”；至于它一定采用离线单图输入、输出检测框坐标，数字FAE 的知识库没有明确依据，不能当成官方结论。

因此这一段我只写自己现场看到的边界：当前预烧整机通过终端返回类别和数量，我看到的 LCD 预览画面没有叠加检测框。但这不能推出所有固件都统一如此，也不能推出 ai_component sample 默认没有检测框。要做带框界面，应先阅读 sample 源码确认输出结构，再决定是应用层绘制还是在视频通路上叠加 OSD。

个人调试时最值得记录的四条规律

距离稳定在一米左右、上半身入镜，人形结果最稳定。
脸和身体都出现在画面里，通常比只拍一张大脸更容易得到 face=1 human=1。
非模型目标出现 0 objects 时，先查模型能力，不要先怀疑硬件。
单帧掉到 0、下一帧恢复，优先看多帧汇总，再看光照和运动影响。

五、把两个示例拼成一个场景：桌面有人看护

现在回到开头那个问题：有人靠近时，设备能不能认出来并留下证据？

答案是能，而且链路并不复杂。Sensor 提供实时画面，AI Component 给出 human=1，应用在检测到人之后触发抓拍。需要远程提醒时，再把事件交给 ZeroClaw 的消息渠道。

图 10 桌面看护数据流

场景一：门口或桌边有人靠近

把摄像头对着门口或桌面边缘，人进入画面后，终端先出现 human=1。应用收到这个结果，就调用抓拍命令保存当前画面：

/root/fw_cli camera_capture /mnt/photo 1 1

ls -t /mnt/photo*.jpg | head -1

这里记录的是这台预烧设备的现场可用命令，但数字FAE 的知识库没有查到 camera_capture 的参数说明，因此不逐个解释 1 1 的含义，也不把它当成跨固件稳定的 CLI 契约。随后可以通过 TF 卡或 scp 把照片取回电脑；如果要写进团队脚本，应先在当前固件执行 --help、查看源码用法或向社区确认。

这个场景里，视频不需要上传云端，检测和抓拍都在设备本地完成。

这条链路的实际价值在于“事件化”：原始视频流很大，不适合频繁传输；一张带时间点的抓拍图更轻，也更适合做通知、留档和后续人工复核。

场景二：家里老人或孩子短时间停留

把设备放在客厅桌面，摄像头覆盖沙发或活动区域。检测到人形后记录时间，再配合抓拍形成简单的停留记录。

这里要说清楚一个限制：当前示例能回答“画面里有没有人”，不能直接回答“这是谁”“是否摔倒”“是否长时间不动”。这些属于更复杂的姿态、行为和时间序列分析，需要另一层应用逻辑和更合适的模型。

场景三：把事件推到手机

数字FAE 的知识库可以确认，方案提供 ZeroClaw Skill 与火山、百炼云引擎的端云协同能力，【轻AI越影视觉开发板】上也有 zeroclaw_base 案例；但“默认监控 5 分钟、目标数量变化就通知”这些细节，知识库没有给出明确依据。因此这里只把它写成扩展方向，不写成已经验证过的官方触发规则。

如果要做这个场景，应先查看当前固件里 ZeroClaw 的实际配置和案例源码，确认监控时长、触发条件、消息渠道和重试策略，再决定是否接入 QQ 或飞书。

这条路径适合做原型演示，但产品化还要补三件事：通知失败重试、误报抑制和隐私告知。尤其是指向公共区域或他人生活空间时，抓拍和通知都应该有明确告知，不能因为数据留在本地就忽略隐私边界。

所以我也没把“推到手机”放进前面那几条已经通过验收的链路里。它更像下一步要补的应用层功能，而不是这次现场验证已经完成的结果。

我给自己设的四条验收

验收项	通过标准	我实际看到的结果
实时出图	LCD 能持续显示摄像头画面	通过，可正常预览
人形检测	人进入画面后返回 human=1	通过，连续帧汇总稳定
人脸结果	合适构图下返回 face=1 human=1	通过，近距离大脸不作为唯一构图
抓拍存证	/mnt/ 生成新的 JPEG	现场通过，可用 TF 卡或 scp 取回

这套原型还能往哪里走

如果目标是 AI 台灯，可以把“有人”扩展成坐姿和距离判断，但这需要坐姿模型以及屏幕、灯光联动。

如果目标是泛 AI 摄像头，可以把人形检测和 RTSP 推流组合起来，做成低成本的本地智能监控。

如果目标是 AI 玩具或桌面助手，可以把人脸出现当成唤醒条件，再接入语音和屏幕互动。

这些都建立在同一条基础链路上：先拿到稳定画面，再把模型结果变成应用事件，最后接一个用户能感知的动作。

六、数字FAE：一个“能给出处、也会说不知道”的技术助手

调试过程中，我用数字FAE核对了几类问题：Sensor 最小验证、模型类别、AI 检测接口、BLE 配网和构建入口。它的定位很明确：专门解答海思产品和技术问题，支持芯片规格、硬件设计指南、软件开发指南、技术问题排查和文档推荐。它最有价值的地方不是“什么都能答”，而是把答案限定在产品知识库里，并明确告诉你哪些没有依据。

这次最典型的例子是模型文件。它从 ot_aidetect_threshold 文档中给出了 det_hvf_hor.bin 的类别和阈值，也列出了 det_pet_hor.bin、det_pkg_hor.bin 等文件名。这样的回答可以继续沿文档核对，不是一段无法验证的经验。

反过来，当我问 aidetect_listen、camera_capture 的参数含义、RTSP 默认地址、Ble-Wifi 广播名和“1970 年是否因为没有 RTC”时，它没有直接给结论，而是说明知识库缺少依据。这个表现比猜一个看似合理的答案更有用，也提醒我：博客里必须把“官方文档可确认”“设备现场观察”和“待核对”分开写。

它的能力边界也写得很清楚：只回答海思产品相关问题；如果问题超出知识库范围，会引导回到产品话题，而不是用通用经验硬凑一个结论。对开发者来说，这种“不越界”比回答得多更难得。

先用它做一次“可核查的排错”

我拿 AI 检测链路做了个小测试，不问“为什么检测不到”，而是拆成可以核对的事实：

det_hvf_hor.bin 支持哪些类别，推荐阈值是多少？
检测接口里的 count 参数是什么语义？
face 在类别枚举里代表什么？
哪些内容它没有文档依据？

前三个问题能得到文档名称、章节和接口定义；第四个问题它明确回答“未找到”。这比一次性问“怎么让检测更准”更容易判断答案是否可靠。

三种模式怎么选

数字FAE 提供快速、思考、开放三种模式。快速模式适合查文件名、接口名、参数表这类边界清楚的问题；思考模式适合把现象、日志和排查步骤放在一起分析；开放模式会联网扩展范围，更适合查生态资料或社区经验。

我自己的用法是：先用快速模式确认一个事实，再用思考模式追问原因。比如先确认 det_hvf_hor.bin 的类别，再问“人在一米左右、上半身入镜时，为什么有时只有 human=1 而没有 face=1”。如果问题涉及当前固件的 CLI 行为，而知识库没有对应文档，就直接把它标成待核对，不靠开放模式的搜索结果替代官方说明。

用下来，三种模式不是“高级/低级”的关系，而是三种不同的取证方式：快速模式解决“这个参数是什么”，思考模式解决“这几条线索怎么串”，开放模式解决“官方知识库之外还有没有公开资料”。真正写技术结论时，最终仍要回到能核对的文档或现场日志。

提问时把设备上下文一次给全

数字FAE 的官方提问建议很实用：芯片完整型号、SDK、硬件平台、故障现象、报错日志、复现步骤、已经做过的排查和结果。对【轻AI越影视觉开发板】，我会再补三项：是出厂预烧系统还是自编 sample、当前使用的模型文件、LCD 和 RTSP 是否已经单独验证。

这样问的好处是，它更容易把问题定位到“Sensor 没出图”“模型类别不匹配”“CLI 参数不明确”中的某一类，而不是给出一长串通用检查项。

但这里有一个实际矛盾：越是要求用户补全信息，越会暴露当前上下文传递方式不够顺手。源码片段和日志直接粘贴到对话里还可以；一份几 MB 的 PDF、Word 或完整编译日志，如果上传后不能稳定解析，用户就会被迫删减材料。附件能力不是附属功能，它决定了这个助手能不能从“查文档”走到“看现场证据”。

这次回答里确认了什么，没确认什么

这次核对覆盖了构建、模型、接口、设备行为和平台能力。结论可以压成一句话：接口文档能回答的问题，它能给出处；CLI 细节和平台产品能力，它不会猜。

核对项	回答情况	我的处理
板卡构建目标	确认构建命令采用 --target <板卡构建目标> samples base 的形式	具体标识以当前 SDK 构建章节为准
模型类别与阈值	确认 det_hvf_hor.bin 支持人脸、人形、机动车	作为模型边界
AI 检测 API	确认 count=-1 表示持续检测	与 CLI 参数分开
face 类别	确认存在 OT_AIDETECT_CLASS_FACE	不扩展成身份识别
-DSENSOR	未确认取值	标为待核对
RTSP 默认地址	未确认统一值	只写现场地址
aidetect_listen、camera_capture	未确认 CLI 参数	不解释未核实参数
ZeroClaw 通知	未确认 5 分钟与触发条件	只写扩展方向
RTC、NTP、BLE 名	RTC/NTP 未确认；WS53 为 ble_wifi_config	区分现场与版本
引用、上传、错误码	未确认	只作为体验建议

这组结论也解释了为什么“答不出来”不是坏事。技术写作最怕把一次偶然输出写成稳定规律；数字FAE 明确区分“检索到了”和“没有依据”，反而让文章更容易保持可信。

真正连续用下来，工作流还有五处摩擦

体验痛点	希望补的能力	可以怎样验收
调试记录散在十几轮对话里	单会话、批量导出 Markdown/PDF	代码块、引用、时间和附件名不丢
回答中的资料出处无法直接核对	引用卡片可点击，能回到章节或原文	外部链接可跳转，内部文档按权限打开
一段好答案难以转给同事	分享单条答案或多轮对话	只读、有效期、脱敏，不暴露私有会话
试错会话越来越多	会话多选、批量删除、撤销或回收站	删除前可确认，误删可恢复
约 2MB 文件上传后补提示词会异常	上传与提问分阶段，支持分片和重试	文件 ID 可复用，失败原因和请求编号明确

这五条不是“功能许愿单”，而是从上面那条排错路径里长出来的。下面按“为什么卡住、希望怎么改、怎么判断真的改好了”展开。

6.1 会话导出：调试记录应该能直接进入项目文档

一次排错往往会问十几轮，最后真正有用的结论散在对话里。现在要整理，只能手动复制，引用、代码块和上下文很容易丢，事后回看也难还原当时的判断过程。

希望支持单会话导出和批量导出，至少提供 Markdown 和 PDF 两种格式。Markdown 适合放进 Git 仓库或知识库，PDF 适合发给同事评审。导出时保留提问时间、引用来源、代码块和附件名称；如果涉及内部资料，还要在导出前给出敏感信息提醒。

验收标准很直接：导出的 Markdown 在常见编辑器里能正常显示代码块和链接，PDF 不丢表格，重新打开后仍能追溯每条结论来自哪一轮对话。

6.2 引用可点开：答案要能回到原文核对

这次回答已经给出了文档名称和章节，例如 Hi-AIoT-Solution_software-guide_api-reference_framework_api_aidetect.md 下的接口说明；但回答里仍然没有可直接打开原文的链接。对技术问答来说，引用不能只是装饰，它决定了答案能不能被复核。

希望把已有的“文件名 + 章节”升级成可点击的来源卡片：显示文档名、章节或页码、命中的原文片段，以及打开原文的入口。外部链接直接跳转；内部文档则按账号权限打开，没有权限时明确提示，而不是给一个失效链接。

开发者需要知道结论来自哪份手册、哪个版本。当前回答会标注来源文档，但不会稳定给出适用 SDK 或固件版本；后面换了固件或 SDK，仍需要人工判断答案是否仍然适用。

6.3 答案分享：让一次排错变成团队资产

团队里经常有人遇到同一个问题。现在把一段回答发给同事，要么截图，要么复制一大段文字，上下文和引用都没了。

希望提供“分享本次回答”或“分享选中的多轮对话”。分享页要能保留问题、结论、代码和引用，同时支持只读权限、有效期和脱敏。分享的是答案快照，不应把整个私有会话和附件一起暴露出去。

如果团队里有人继续追问，最好能基于分享快照新建会话，而不是让所有人挤在同一个私有对话里。

6.4 多会话批量删除：历史记录需要基本的整理能力

调试期会产生大量试探性会话，有些只问了一句就废弃了。逐个删除很费时间，全部清空又容易误删仍然有用的记录。

希望在会话列表增加多选、全选当前页、按时间筛选和批量删除。删除前显示会话数量和标题，重要会话可以加星保护；删除后提供短时间撤销，或者进入回收站保留一段时间。

这个需求的优先级不一定最高，但它直接影响长期使用意愿。一个工具如果只能不断产生会话，却不能低成本整理，最后会变成另一个信息垃圾场。

6.5 大文件上传：不要把“文件上传”和“提示词请求”绑成一个脆弱动作

我遇到的另一个问题更影响实际工作：文件稍大一点，大约 2MB 左右就可能上传失败；有时候文件已经选上了，再补充提示词提交，整个请求会异常。数字FAE 没有给出文件格式、大小上限或错误码说明，所以这里只能按用户体验问题记录，不能反过来推断平台一定有某个固定限制。

希望把上传和提问拆成两个阶段。第一阶段分片上传、断点续传、显示解析进度；第二阶段只提交文件 ID 和提示词。这样用户可以先确认文档解析完成，再发起提问，失败时也能单独重试，不必把大文件重新传一遍。

同时，错误提示要说人话。是文件超过单文件上限、总空间不足、格式不支持，还是解析超时，应该分别提示，并给出可操作的下一步。服务端返回 413、415 或 422 时，不要把统一错误页丢给用户。

验收标准可以这样定：上传 10MB 文档时能看到进度和解析状态；解析失败可以单独重试；文件上传成功后补充提示词不会重复上传；请求失败时显示具体原因和请求编号。

如果只能先做三项

如果站在产品体验的角度排优先级，我会先解决大文件上传和引用可核查，再补会话导出，最后做分享和批量管理。

原因很简单。大文件失败会让任务直接做不下去，引用不可核查会影响技术结论的可信度；导出和分享决定成果能不能沉淀，批量删除则属于使用体验的长期维护。

七、HiSpark社区介绍：从资料获取到案例复现与上架

HiSpark社区是上海海思面向开发者打造的一站式开发与交流平台，服务对象覆盖芯片开发者、企业伙伴、高校师生和开源技术爱好者。社区以芯片解决方案和多元硬件为基础，整合权威开发文档、SDK 与工具链、开源代码仓、sample、课程培训、技术论坛和案例中心，既支持从环境搭建、示例验证到问题排查，也为代码、文档、开发板和应用案例的规范化贡献与上架提供指引。对于第一次接触【轻AI越影视觉开发板】的开发者，可以先在开发中心和在线文档确认 SDK、工具链及 sample，用论坛补充 FAQ 与调试经验，再到案例中心参考可复现方案；跑通后，还可以按社区模板整理文档、提交代码或分享案例。它的价值不只是“下载资料”，而是把学习入门、资源获取、技术问答、成果沉淀和生态合作串成一条相对完整的路径。

这个桌面看护原型已经具备一个案例的基本条件：有明确问题、有硬件组合、有操作步骤、有终端结果，也有抓拍结果。整理上架时，内容要落到四块。

第一块是场景说明。用一句话讲清楚“谁在什么环境下，需要设备完成什么动作”，不要只写“测试了 Sensor 和 AI”。

第二块是最小复现路径。列出硬件组合、系统版本、摄像头连接方式、检测命令和抓拍命令，让读者能按顺序复现。

第三块是真实现象。放 LCD 画面、human=1 日志、face=1 human=1 日志和一张抓拍图。截图比“效果很好”更有说服力。

第四块是边界。写清楚哪些能力来自当前模型，哪些还需要额外开发，哪些指标没有测试。一个可信的案例，应该让读者知道它不能做什么。