作者 | “寻迹校园”APP开发者 hei

在校园里丢了东西，最难的往往不是登记失物，而是说不清它最后出现在哪里、找不到有效线索，也不知道接下来该怎么找。一张照片、一段文字描述，能记录的信息始终有限；如果能把失物现场记录得更立体，让系统智能体帮忙查询线索、整理行动计划，寻物过程或许就能变得更高效。这正是寻迹校园 APP 尝试解决的问题。作为一款以本机数据为主的校园失物记录与线索比对应用，它已经具备失物登记、候选匹配、行动计划和处理进度等基础能力。而在 HarmonyOS 7 的新特性加持下，我开始思考：能不能不推翻现有架构，就让 APP 拥有更直观的现场记录方式、更自然的智能交互入口，以及更高效的开发与验证流程？

这次实践，我围绕三个方向展开探索：利用 HarmonyOS 7 空间计算中的 3DGS 能力，规划失物现场的空间记录与回看；通过 API 26 App Skill，将 APP 中部分已有业务能力开放给系统智能体调用，提高寻物功能的效率；再借助 DevEco Code 和 DevEco CLI，检查工程配置、SDK 兼容性与构建环境。

从失物现场的空间化记录，到系统智能体对应用能力的调用，再到 AI 开发工具链辅助工程检查，这三条实践链路分别对应用户体验、智能交互和开发效率。结合寻迹校园 APP 的具体设计与接入过程，看看这些能力如何融入现有应用，以及实际落地时有哪些值得注意的工程问题。

失物招领难点：从口述变为用 3DGS 记录失物最后出现的空间现场

校园里的很多位置靠文字很难描述清楚。“二教三楼靠窗座位”可能对应一整排桌椅，“食堂入口旁边”也会因为视角不同产生歧义。单张照片能记录画面，却不容易说明物品与桌角、门口、书架或通道之间的空间关系。基于这个问题，我把 Spatial Recon Kit 的 3DGS 能力规划为“失物现场空间记录”，而不是把它做成与主业务无关的 3D 展示。

HarmonyOS 7 空间计算 3DGS 能力分为端侧重建和端侧渲染。寻迹校园 APP 的流程是让用户围绕最后见到物品的区域进行多角度采集，在支持设备上重建场景，再由用户手工放置“最后见到位置”标记。标记表达的是用户回忆的位置，不是系统定位结果，也不能作为物品归属证据。

我梳理了一条本机失物记录的完整流程：检查设备是否支持空间重建→ 展示采集范围与隐私提示→ 多角度采集现场→ 创建并观察重建任务→ 本机保存场景模型与元数据→ 用户手工标记最后见到位置→ 在失物详情中回看空间现场。

这一流程需要独立的 feature module。页面只保存预览、采集进度、暂停状态和当前视角；SpatialCaptureService 负责采集编排，SpatialReconRepository 负责模型文件、重建记录和标记元数据，真正的重建与渲染再调用 Spatial Recon Kit 和图形能力。这样可以避免把大文件生命周期、权限状态和设备能力判断堆进入口页面。

图一：寻迹校园 APP 手机端智能能力中心与空间现场入口设计

图二：寻迹校园 APP 的 PC 与二合一设备端智能能力工作区设计

其中，需要重点规避 3DGS 空间数据的隐私风险。APP 采集的不是一张孤立照片，而是一组能重建环境关系的数据。教室、宿舍、实验室和办公室可能同时出现人脸、证件、屏幕内容或其他个人物品。因此，这个模块必须把隐私提示放在采集前，而不是等模型生成后再补充。寻迹校园 APP 的隐私设置是：

• 采集前说明数据用途、保存位置和删除方式；
• 默认本机重建和本机保存，不自动上传或同步；
• 检测到不支持设备时退回普通照片和文字位置描述；
• 模型与失物记录解除绑定后提供可理解的清理入口；
• 分享模型或导出视频属于新的外部影响，需要再次确认。

另外，3DGS 模块会使用相机、媒体文件和较多计算资源，不能只根据接口名称开始编码。开发前应先确认支持设备、相机和媒体权限、模型存储空间，以及长时间重建时的发热和功耗。只有这些条件明确后，才适合进入采集、重建、渲染和性能测试。

寻迹校园 APP 目前先完成页面、服务链路和降级方案设计，不提前加入无效权限或占位实现。设备不支持空间重建时，用户仍可使用普通照片和文字位置描述，原有失物记录流程不会被新模块阻断。

寻迹校园 APP 接入 API 26 App Skill 思考：四项低风险能力

从 API 26.0.0 开始，Ability Kit 支持把应用内业务能力以 Skill 形式开放给系统智能体调用，当前只支持 Stage 模型。系统智能体根据 SKILL.md 中的描述完成意图与能力的匹配，再调用 ArkTS 入口脚本。这个机制适合寻迹校园 APP，但前提是 Skill 必须复用现有业务边界，不能为了展示新特性另建一套平行数据。

我为寻迹校园 APP 选择了四项低风险能力。它们都能在当前设备的数据范围内完成，而且不会替用户删除记录、发布内容或判断物品归属。

模块注册与声明契约，Skill 目录名、SKILL.md 中的 name 和 module.json5 中的 skillProfiles 名称必须一致。寻迹校园 APP 把 Skill 注册到 EntryAbility，并将 ArkTS 入口指向独立脚本。入口和应用壳保持分离，后续可以单独审查系统智能体真正能调用的函数。

"skillProfiles": [
 {
 "name": "xunji-campus-assistant",
 "abilityName": "EntryAbility",
 "srcEntries": [
 "../../skills/xunji-campus-assistant/scripts/XunjiCampusSkill.ets"
 ],
 "version": "1.0.0"
 }
]

其中，SKILL.md 不是普通说明文件。它同时承担触发条件、不要调用的情况、参数格式和返回契约。比如“帮我看看校园卡有哪些可能的线索”可以触发候选比较，但“删除这条记录”“替我确认就是他的物品”必须被排除。把不要调用的情况写清楚，可以减少系统智能体把查询能力误当成修改能力。

为保证调用链保持薄入口，App Skill 的入口脚本只做三件事：接收系统传入的字符串参数，完成长度、范围和必填项校验，再把业务请求交给 HarmonyOS 7 SkillService。它不直接操作 RelationalStore，也不把页面状态当成业务数据。完整调用链如下。

系统智能体
 → xunji-campus-assistant 与 SKILL.md
 → XunjiCampusSkill.ets 参数校验与 ExecuteResult 回包
 → HarmonyOS 7 SkillService 业务编排与隐私裁剪
 → ReportService 或 SearchPlanService
 → Repository 与 RelationalStore

这个分层让新增 Skill 与原应用共享同一份规则。记录筛选、候选计算和计划生成仍由原 Service 处理，Skill 只负责把结果转换为外部可消费的结构。即使未来关闭系统智能入口，应用中的登记、比对和行动计划也能独立使用。

另外，失物记录可能包含照片、私人特征、联系方式和详细描述。即使数据保存在本机，也不代表这些字段可以自动交给系统智能体。因此 HarmonyOS 7 SkillService 对输出做了二次裁剪，只保留完成任务需要的字段，确保隐私边界写进服务层。

DevEco Code、DevEco CLI 工具链实践：让 AI Coding 先理解工程边界

HarmonyOS 7 将 DevEco Code 定位为 HarmonyOS 应用开发专属 AI Agent，覆盖代码生成、问题修复、编译构建和功能验证等开发过程；DevEco CLI 提供工程创建、语法检查、编译构建、运行验证以及官方知识库和精品 Skills。对已有工程而言，两者更有价值的用法不是直接生成大量代码，而是先读取项目结构、规则文件和 SDK 配置，再决定能否实施某项能力。

开发中我接入工具链后，先回读 DevEco Code 和 DevEco CLI 版本，再读取官方 Skill、检查 IDE 兼容性和 SDK。工具使用独立目录安装，不修改项目依赖和 lockfile，出现版本冲突时也更容易回滚。

接着是用 DevEco CLI 读取官方 Skill 列表并形成检查顺序。本次执行 skills list 返回 45 项，包含 ArkUI 开发、ArkTS 语法检查、MVVM 模式、多设备适配、本地测试和运行时修复等方向。开发时可以按当前任务选择 Skill，不必把所有规则一次性加载进上下文。

deveco --version
devecocli --version
devecocli skills list
devecocli check compat versions
devecocli build --product default --modules entry@default --build-mode debug

我把工具链检查固定为“版本回读、官方 Skill、IDE 兼容性、SDK、工程配置、同步构建、设备验证”七步。这个顺序能够尽早发现环境问题。否则，开发者可能在业务代码上反复排查，实际阻塞点却是 IDE 或 SDK 版本。

兼容检查中，当前 build-profile.json5 已将 targetSdkVersion 调整为 7.0.0(26)，entry 模块也已注册 xunji-campus-assistant。配置检查能够通过，但 devecocli check compat versions 检测到本机 DevEco Studio 为 6.1.1.290，低于工具要求的 26.0.0.810，因此兼容检查失败。随后执行构建时，ohpm install 可以完成，hvigor sync 因本机缺少 API 26 SDK 停止，尚未进入新增 ArkTS Skill 的正式编译阶段。

这个结果说明 AI 工具链可以帮助定位环境问题，却不能替代底层 SDK。DevEco Code 能分析工程，DevEco CLI 能给出兼容结论，但只要 API 26 SDK 不存在，就不能把本地 JavaScript 契约测试升级为 ArkTS 正式构建结果。

让 HarmonyOS 7 新特性真正服务于 APP 体验

回看这次寻迹校园 APP 的 HarmonyOS 7 实践，我更关注的不是接入了多少新 API，而是这些能力能否切实改善应用原有的使用体验。这次实践也让我更加明确：HarmonyOS 7 新特性的价值，不在于给 APP 简单增加几个技术标签，而在于重新审视原有业务中那些长期存在、却难以解决的体验难点。例如 3DGS 让失物现场记录有机会从平面描述走向空间化表达，App Skill 让既有业务有机会从应用内操作走向智能体驱动，AI 工具链则帮助开发者更高效地完成工程检查与问题定位。

对寻迹校园 APP 来说，这些能力共同指向一个目标：让失物记录更清楚、线索查询更便捷、寻物行动更有方向，同时让新能力的接入不破坏原有业务的稳定性。目前，相关模块已完成相应的设计与工程接入探索，但 3DGS 完整采集与重建、App Skill 正式编译及设备端调用等环节，仍需在满足要求的开发环境和设备上进一步验证。接下来，随着兼容性问题解决和真机测试推进，我也期待把这些新能力逐步转化为用户真正能够感知、使用的 APP 功能。