【寻迹校园 HarmonyOS NEXT 实战 01】从校园痛点到可上架 MVP：失物招领应用产品设计

这是"寻迹校园 HarmonyOS NEXT 实战"系列第 1 篇。项目使用 ArkTS、ArkUI、Stage Model、RelationalStore 和 Agent Framework Kit，目标不是堆功能，而是做出一条可以验证、可以降级、可以交付的校园失物招领闭环。

上图为本文原创生成的产品概念图：分散的失物线索经由移动端入口收束为可确认、可追踪的处理闭环。它用于表达产品结构，不是项目运行截图，也不包含用户真实失物数据。

一、为什么校园失物招领不能只做成"另一个信息流"

校园里的失物信息通常散落在班级群、表白墙、社团群和线下值班点。看起来只要做一个"发帖 + 搜索"的 App 就够了，但真正使用时会出现四个问题：

描述不结构化。同一个地点可能被写成"一教""第一教学楼""一教门口"，普通关键词很难稳定召回。
信息很快沉底。用户看到的不是最相关记录，而是最新发布的记录。
认领缺少安全门禁。公开所有细节会泄露核验答案，直接交换联系方式又会扩大隐私风险。
状态没有闭环。发布之后缺少"申请---核验---交接---双方确认---结案"的权威状态。

因此，"寻迹校园"从一开始就没有把自己定义为校园论坛，而是一个结构化失物招领工具。它的最小产品闭环是：

text 复制代码

发布结构化记录
  -> 筛选和召回相反类型候选
  -> 展示相似理由与冲突点
  -> 提交私密核验信息
  -> 发布者审核
  -> 选择固定校内交接点
  -> 双方确认完成
  -> 两条关联记录结案

这个闭环比"做一个聊天机器人"更重要。AI 可以增强其中的解释环节，但不能成为整个产品是否可用的前提。

二、先写目标，也要写清楚非目标

一个比赛项目最容易失控的地方，是把所有听起来先进的能力都塞进首版。我们给 V1.0 设定了明确边界。

首版必须完成：

丢失物和拾得物的结构化发布；
关键词、类型、类别、地点、时间、颜色组合筛选；
相反类型候选召回、信息相似分、理由与冲突展示；
匿名认领、私密特征核验、同意或拒绝；
固定交接点、时间段、双方确认和结案；
举报、撤回、删除、消息和本机设置；
小艺不可用时仍能完成原生流程。

首版明确不做：

陌生人自由聊天；
支付、悬赏金和广告；
精确实时定位、通讯录、人脸和证件照片采集；
AI 自动判定物品归属；
私有 MCP、私有云插件和复杂后端协作。

"不做什么"不是能力不足，而是为了保护核心流程、隐私边界和交付确定性。尤其是即时聊天，看似方便，实际上会立即引入账号体系、实时服务、内容审核、骚扰治理和联系方式泄露问题。

三、把用户目标压缩成一条可验收的产品路径

项目主要服务三类用户：失主、拾得者、校园志愿者或值班人员。三类人的共同目标不是"多看内容"，而是让物品安全回到主人身边。

这张原创流程图把 MVP 压缩成五个连续动作：发现线索、结构化发布、解释性匹配、身份核验和安全交接。任何新增功能都应该先回答一个问题：它是否让这条闭环更短、更可靠或更可验证？

以失主路径为例：

text 复制代码

首页
  -> 发布"我丢了物品"
  -> 填写物品、日期、模糊区域和公开特征
  -> 查看候选
  -> 对某条拾得记录申请核验
  -> 等待发布者审核
  -> 到固定交接点线下核验
  -> 双方确认
  -> 已找回

拾得者路径与之相反。拾得记录在发布时必须增加一项"私密核验特征"，例如包内某个不适合公开的细节。这个字段不进入首页搜索、不进入公开描述，也不能发送给小艺。

这让系统拥有两套信息：

公开信息：帮助召回候选；
私密信息：帮助线下确认所有权。

四、AI 应该放在哪一层

项目采用"两层匹配"：

第一层是本地确定性召回。App 根据类别、地点、日期、颜色和公开关键词计算候选，展示信息相似分、相似理由和冲突点。这一层不依赖网络，也不依赖小艺平台状态。

第二层是小艺增强。App 只把少量脱敏候选摘要交给小艺，让它帮助用户比较差异、补充追问。小艺不读取完整数据库、不接收私密核验答案、不修改业务状态，也不判断所有权。

对应的产品路径是：

text 复制代码

本地规则召回
  ├─ 证据足够：展示候选、理由和冲突
  └─ 证据不足：提示补充公开信息

用户主动选择"小艺辅助"
  ├─ 能力可用：打开系统 FunctionComponent
  └─ 能力不可用：返回原生候选，业务继续

这种设计避免了一个常见误区：把聊天界面当成 AI 产品本身。真正有价值的是可追溯的数据、可解释的候选和安全的后续动作。

五、HarmonyOS NEXT 工程如何支撑这条闭环

当前工程采用 Stage Model，并拆分为四个模块：

text 复制代码

entry
  -> 页面壳、Navigation、页面组装

common-ui HAR
  -> 主题 Token、共享组件和图标

common-core HAR
  -> 模型、路由参数、词表和纯筛选规则

shared-business HSP
  -> Service、Repository、RelationalStore 和能力适配器

业务依赖方向保持单向：

text 复制代码

ArkUI Page
  -> Service
  -> Repository / Capability Adapter
  -> RelationalStore / Preferences / File / Huawei Kit

页面只保存输入草稿、选中项、loading 和错误提示等短生命周期状态。校验、状态迁移、匹配、持久化和系统能力调用都不放进 build()。

六、隐私不是一张协议页，而是数据流约束

失物招领天然包含隐私风险。项目把数据分为四级：

级别	示例	处理方式
PUBLIC	类别、颜色、模糊地点、公开描述	可进入列表和匹配
RESTRICTED	用户标识、认领状态、举报人	仅业务授权范围读取
SENSITIVE	联系方式、私密核验答案、精确位置	不进入搜索、日志和 Agent
PROHIBITED	密码、支付信息、完整证件号	产品不采集

这比"写一份隐私政策"更接近工程问题。每个字段都要回答：谁能读、是否持久化、是否进入搜索、是否可能进入日志、是否会被发送给外部能力。

七、比赛演示必须区分五个证明层级

为了避免把"能编译"说成"已发布"，项目统一使用五级证据：

Contract：模型、状态机、纯规则和自动化测试；
Build：HAP 或 APP 构建成功；
Runtime：安装、冷启动、前台 Ability 和进程存活；
Capability：Photo Picker、小艺等真实系统能力在支持设备上工作；
Platform：AGC 或小艺平台的注册、提交、审核和发布状态。

当前项目已有核心 App 真机运行证据，但这不自动证明外部 Agent 已审核通过，也不证明 AGC 已发布。所有文章和答辩材料都必须按证据层级描述。

八、这套 MVP 方法可以复用到哪些项目

如果你正在做校园互助、二手交换、志愿服务、任务协作或本地 AI 应用，可以复用这套方法：

先定义一个不依赖 AI 的完整闭环；
把公开信息和私密证据拆开；
把状态机和副作用放进 Service；
把数据源放进 Repository；
为所有系统能力设计 unsupported、cancel、error 和 fallback；
用分层证据描述真实完成度。

下一篇将进入工程结构，具体拆解 entry、HAR 与 HSP 的职责和依赖关系。

九、本文小结

"寻迹校园"的核心不是失物信息流，也不是一个聊天入口，而是一条可解释、可核验、可结案的业务闭环。HarmonyOS NEXT 提供了 ArkUI、RelationalStore、Photo Picker 和 Agent Framework Kit 等能力，但产品是否可靠，最终取决于边界、状态、降级和证据是否清晰。

系列导航：第 1 篇 / 共 50 篇。下一篇：《HarmonyOS NEXT 多模块工程拆解：entry、HAR 与 HSP 应该如何分工》。