做一个小型展品的 3D 展示，采集人员常常觉得“已经拍了很多张”，却忘记某个背面或底部几乎没有素材。照片数量不是空间覆盖的同义词：同一个方向拍了二十张，仍然可能留下不容易补救的空白区域。3DGS 的重建流程通常会把图像采集与后续建模连接起来，前面漏掉的视角，后面未必能靠调高参数弥补。我想把工程问题放在进入重建任务之前，而不是直接写一套未经设备验证的空间重建接口。本篇设计一个 ArcInspect 采集质检页：先把业务采集记录离散到 12 个方位格，再把清晰度、曝光和运动状态作为应用侧的参考条件，输出“可继续”或“建议补拍”的可解释提示。它只是采集辅助，不把格子填满等同于重建必然成功。## 一、拍摄张数不能替代覆盖率Demo 的对象是一件摆在工作台上的陶瓷展品。为便于沟通，业务将绕物体的一周粗略划分成 12 个扇区，编号 00 到 11。这里的扇区不是 Spatial Recon Kit 官方返回的重建网格，也不是相机姿态估计结果，而是产品层为人工采集计划定义的采样格。开发者可以从自己的采集工作流拿到“这一帧对应哪个方位”的标注，再交给本页。没有可靠的方位来源时，只能让工作人员手动选择，不能伪装成系统自动测量。本轮人工测试素材中总共登记 24 帧，按下面的业务规则得到 18 帧可作为候选、6 帧不建议使用。这些候选分散在 9 个扇区；03、07、10 三个格子仍无有效素材，因此页面显示 9/12 = 75%，状态为 NEED_RETAKE。这些值专为解释逻辑而设，不是真机拍摄统计，也不是官方推荐采集数量。为什么不只看 24 呢？因为数量会奖励重复拍摄：工作人员站在同一个点反复点击快门，数量增加，覆盖却没有改善。为什么也不能仅看 75%？因为同一扇区里可能缺少高度变化、遮挡变化，或者物体材质反光非常严重。12 格只是最粗的一层提醒，并没有模拟真实光照、镜头内参和运动视差。## 二、先统一输入记录，再谈“好帧”真正容易混乱的是指标来源。相机设备能给到怎样的曝光、稳定度和清晰度数据，需要另外以 Camera Kit 或业务图像处理链的实际输出为准。本文不声明存在名为 getSharpnessScore() 的系统接口，也不声称空间重建框架直接提供每帧质量分。我们只约定一份已经被上游验证或人工标注的业务对象，然后在 ArkTS 层进行门禁计算。第一段代码定义输入类型与筛选规则。sharpness 是业务自定义的 0～1 指标，0.62 是为演示设定的经验阈值，不是 SDK 常量。exposureOk 与 motionOk 也是上游提供的布尔判断。现场产品如果暂时拿不到这三项，就应该改成人工“合格/不合格”标记，并记录判定来源。arktsinterface CaptureSample { id: string; sector: number; // 0..11，来自业务方位标注 sharpness: number; // 应用侧归一化指标，不是系统API返回值 exposureOk: boolean; motionOk: boolean;}function usable(sample: CaptureSample): boolean { return Number.isFinite(sample.sharpness) && sample.sharpness >= 0.62 && sample.sharpness <= 1 && sample.exposureOk && sample.motionOk && Number.isInteger(sample.sector) && sample.sector >= 0 && sample.sector < 12;}阈值能够让演示结果确定，却也有代价：较暗场景未必不适合所有算法，单一清晰度分数也不等于模型重建的整体质量。如果把这个函数写成“系统判定可建模”，就已经越过了它的能力边界。比较合理的页面文案是“按当前采集规则，建议补拍”，并为人工审核提供覆盖情况和原始指标。## 三、以覆盖格为单位组织补拍建议可用帧和可用扇区是两种不同计数。一帧只有一个 sector，一个扇区却可能被许多帧覆盖。在页面上需要同时显示 18/24 的质量筛选统计和 9/12 的空间覆盖统计，避免用户看到 18 就误以为已有 18 个不同视角。第二段代码将帧列表转换成覆盖状态。为了让人工质检容易读懂，结果记录 missing 的扇区编号、可用帧数量、覆盖扇区数和状态。若录入信息不在 0～11 范围内，usable 会直接把它视为不可用记录，而不是让数组越界。对实际采集系统，建议另行记录错误类型，区分“质量较差”和“方位数据缺失”。arktsinterface CoverageReport { frames: number; accepted: number; covered: number; missing: number[]; state: 'READY_TO_REVIEW' | 'NEED_RETAKE';}function evaluateCoverage(samples: CaptureSample[]): CoverageReport { const set: Set<number> = new Set<number>(); let accepted = 0; samples.forEach((sample: CaptureSample) => { if (usable(sample)) { accepted++; set.add(sample.sector); } }); const missing: number[] = []; for (let s = 0; s < 12; s++) { if (!set.has(s)) { missing.push(s); } } return { frames: samples.length, accepted, covered: set.size, missing, state: missing.length === 0 ? 'READY_TO_REVIEW' : 'NEED_RETAKE' };}注意这里写的是 READY_TO_REVIEW，而不是 RECONSTRUCTION_SUCCESS。即便所有扇区都有一张可用照片，仍要经过更完整的几何重叠、纹理分布和重建任务校验；覆盖完整只表示允许进入下一步人工或算法评估。如果做批量作业，也应该把当前规则版本和每次报告一同存下来，避免半年后阈值变化，旧任务的补拍结论突然失去可解释性。## 四、补拍提示不应该制造“已完成”的错觉演示界面顶部只放必要的信息：采集任务号 CAP-204、对象名“陶瓷展品”、总帧数 24、候选帧 18、覆盖率 75%。中间用 12 个小格呈现方位，已覆盖格用绿色，缺口 03、07、10 使用橙色。底部提供“查看补拍建议”，而不是立即放一个误导性的“开始重建”。这一点很重要：用户需要的是知道下一步去哪拍，而不是看到一个漂亮的进度条。第三段代码演示最小页面。它没有调用任何虚构的 3DGS 建模方法。页面数据来自固定人工样例，实际接入时应由 evaluateCoverage 对真实采集记录计算之后再传入。使用 ArkUI 的 Progress、ForEach 和状态变量组织展示，避免把视觉配色和质量判断混在一个函数里。arkts@Entry@Componentstruct CaptureCoveragePage { @State frameCount: number = 24; @State accepted: number = 18; @State covered: number = 9; @State missing: string[] = ['03', '07', '10']; @State message: string = 'NEED_RETAKE · 建议补拍'; build() { Column({ space: 16 }) { Text('ArcInspect · CAP-204').fontSize(24).fontWeight(FontWeight.Bold) Text('陶瓷展品｜采集前质检') Row({ space: 12 }) { Text(`已登记 ${this.frameCount} 帧`) Text(`候选 ${this.accepted} 帧`) } Progress({ value: this.covered, total: 12, type: ProgressType.Linear }) Text(`方位覆盖 ${this.covered}/12 · 75%`) Text(this.message).fontColor(Color.Orange) Text('待补拍扇区') Row({ space: 12 }) { ForEach(this.missing, (sector: string) => { Text(sector).padding(12).backgroundColor(0xFFF0D4) }, (sector: string) => sector) } Button('查看补拍建议').onClick(() => { this.message = '优先补拍 03、07、10 方向'; }) }.padding(20).width('100%') }}这样的页面只处理可解释的业务状态，不必为了“像真工具”而发明硬件接口名称。想把方位格和真实拍摄数据连接，必须先确认相机/传感器方案能否提供可靠姿态。如果没有，就采用人工标注，直到设备数据通路验证充分再升级。配图中的项目树、ArkTS 和 HiLog 是演示界面，并不证明 ArcInspect 已在 DevEco 上实际跑过。## 五、调试时优先检查四组反例第一组是“拍得多但集中”：把 24 帧全部放在相邻两格，accepted 可能很高，covered 却应该只有 2。第二组是“方向分散但质量差”：每格都有记录，然而一半 sharpness 低于当前示例阈值，这些格子不应提前被计为有效覆盖。第三组是“重复编号或乱序输入”：Set 只决定方位是否存在，不应该因为同一扇区出现多张照片而增加覆盖格数量。第四组是录入 sector = 12、负数或者非有限分数，业务规则应让它们失效，并提示工作人员检查元数据。建议的结构化诊断字段是 captureId、ruleVersion、frames、accepted、covered 和 missing。像 CAP-204, frames=24, accepted=18, covered=9, missing=03|07|10 这样的行，可以帮助团队确认补拍列表是根据哪些采集记录产生的。这里仍然是人为构造的验证样例，不是从设备 HiLog 捕获的事实。若实际记录含位置、照片路径或拍摄时间，也应考虑权限与隐私最小化，不要把原始内容直接写进日志。另一个应该提前明确的异常场景是补拍以后旧报告未更新。如果工作人员补了 03 方向两张图，报告必须绑定采集数据的版本号重新计算；不能只在 UI 上把 03 涂绿，却保留上一版报表。更好的做法是让页面展示一份完整的 CoverageReport 快照，任何补拍动作都重新生成快照，并在展示前比较任务 ID 和记录版本。这样日志和界面才有同一个事实来源。## 六、从“允许复核”到真正重建，还差几层验证华为官方空间计算页面介绍了 3DGS 端侧重建与渲染的应用场景，Spatial Recon Kit 的实际重建管线仍有具体输入格式、能力开放、设备与版本等条件。本文并未复刻这些系统接口；设计目标是解决重建前的采集组织和解释性提示。接入实际工程时，应重新核对目标设备是否支持所需能力、帧序列及模型输出的约束，再决定报告怎样传递给管线。从产品角度看，还要留下人工跳过入口。某些展品底部无法拍摄，某些场地因安全原因不能绕到背面。把缺失扇区一律锁死，可能使本来可以接受的任务无法继续；但无条件允许跳过又会让质量门禁失去意义。因此更合适的协议是“未覆盖 → 建议补拍 → 人工注明原因 → 允许进入复核”，同时保留原因和操作者，不把跳过当作自动通过。结果说明：本文给出的 24/18/9/12 和 03、07、10 是用于说明规则的演示数据；没有声称已完成真实 3DGS 建模，没有虚构重建时间、成功率和模型精度。只有在实际采集、重建和模型审查三条证据链都完成后，才能写“任务成功”。工程上先把补拍范围说清楚，比用一个未经验证的绿色进度条更可靠。> 资料核对：华为官方 空间计算能力简介 与 空间重建管线资料入口。方位分箱、归一化分数和业务门禁均为应用层设计，不是华为官方规定的算法参数或验收标准。