Gamers2｜拾光 FindBack 原型设计

本文为提交前初版。讨论照片已补入第 8 节，实际分工、团队协作感受和队友评价已补充，公开源码与 PPT/PDF 地址已列在第 2 节。正文中的截图来自课程演示系统，物品与身份均为示例。

目录

目录

1 项目延续与本次范围

本次继续做校园失物招领系统。原型包含发布、查找、认领申请、拾主核验和双方确认。先把这几个操作做完整，再考虑图像匹配等扩展功能。

早期需求规格说明书还规划了图像候选匹配、小程序和校园认证。本次先实现清晰、可验证的基础流程，没有把这些规划能力写成已经完成。图像匹配只应帮助发现候选物品，不能代替私密证据的人工判断。

本次还完成了前后端演示实现：浏览器页面通过 HTTP API 读写数据库。它用来验证原型中的状态和权限能否实际落地，不代表已经开展校园试点或完成原 SRS 的全部需求。

2 原型与附件入口

• 打开墨刀交互原型，答辩主入口
• 墨刀编辑项目：需要项目权限。
• 前后端演示站：当前账号私有，课堂优先演示上方墨刀原型或本地系统。
• **下载 PPT（配图版·链接修正版）**：第 1、11 页可点击墨刀链接。
• 查看 PDF 备用稿。
• GitHub 公共源码仓库；全部源码 ZIP。

原型分享面板当前显示访问权限为“所有人”。墨刀原型使用独立模拟数据，刷新会重置；实际前后端使用持久化数据库，两者用途不同。墨刀的 HTML 组件支持导入页面并保留交互，设计源文件随源码一同归档，可参考墨刀官方 HTML 导入说明。本次没有将所有控件转换成独立的墨刀原生图层。

3 用户角色与主流程

正常认领流程为：浏览与筛选 → 查看物品详情 → 提交私密特征 → 拾主人工作出核验结论 → 双方交接 → 拾主确认交出、失主确认收到 → 已归还。

公开内容审核与认领核验使用不同状态。前者决定信息能否出现在广场，后者判断一次认领是否通过。只有一方确认时仍处于“交接中”；双方均确认，物品才进入“已归还”。

4 页面设计与交互细节

4.1 首页与搜索

首页右上方提供“发布寻物”和“发布招领”，下方是搜索与筛选；列表展示标题、地点、日期和业务状态。用户可组合关键词、信息类型、类别、地点和状态筛选，并用“清除筛选”回到完整列表。空结果提供明确提示，避免让用户误以为页面加载失败。

页面采用浅色背景、低饱和绿色按钮与图片卡片，首页保留搜索、筛选和发布入口，没有大幅宣传区。六件示例物品配有内置生图工具生成的示例图片，卡片和详情页均有标注，不代表真实失物照片；其他未上传照片的记录仍显示“暂无照片”。状态同时用文字说明。

4.2 物品详情与认领

详情公开物品的基本信息和核验问题，但不公开拾主的私密参考答案。申请者通过弹窗描述公开图片中看不到的细节。证据只对申请者与本帖拾主显示，后台内容审核不因此获得全部私密认领证据。

重复提交会被限制；申请提交后，按钮显示等待状态，页面保留申请进度。核验未通过时记录原因，申请者可以修正证据后重新申请。

4.3 发布与内容审核

发布页区分公开描述、核验问题和私密参考信息。文字字段有长度及日期校验，公开文本限制直接填写手机号；上传图片在前端压缩后提交，图片中的信息由管理员人工审核。提交后显示“待审核”，只有审核通过才进入公共列表。

这套检查不能保证自动识别所有个人信息，因此演示环境不使用真实证件或联系方式。审核意见会形成站内通知，让发布者知道下一步如何处理。

4.4 人工核验与双向交接

拾主可以看到本人保存的核验参考信息和申请者证据，并记录核验结论。通过后进入交接，不能直接将物品标为归还。界面分别显示“拾主确认交出”和“失主确认收取”，让双方知道还缺哪一步。

4.5 消息中心

新申请、审核结论和交接变化通过站内消息反馈，消息链接回到对应物品。通知按当前用户隔离，支持标记已读。本次没有接入微信、短信或邮件。

5 设计过程、困难与解决情况

6 前后端实现与验证

前端采用 HTML、CSS 和 JavaScript；本地后端采用 Node.js HTTP 服务、共享业务模块与 SQLite。云端部署复用同一业务模块，适配 Workers/D1。此基础版技术栈与早期 SRS 的 Java/Spring Boot 计划存在调整，后续应在团队评审后更新相应技术文档。

已实现账号登录、发布、筛选搜索、详情、认领、人工审核、双向交接、通知和内容审核。会话与权限在服务端检查，数据库使用参数绑定；密码带盐哈希保存。示例角色切换用于课堂演示，不代表校园身份认证。

验证结果：18 项接口测试全部通过，覆盖匿名与越权请求、私密字段隔离、审核后公开、重复认领、竞争申请只批准一条、双方确认、通知隔离、会话及数据库重开等情形。本地 D1 浏览器操作完成了认领至归还的全流程，并提交了一条笔袋信息，刷新后仍可读取。云端构建和发布成功，当前保持账号私有权限。

这些验证不包含真实校园用户研究、压力测试、图像匹配准确率或生产运行指标，不能据此宣称原 SRS 的性能目标已经达到。

7 团队分工、贡献与进度

7.1 本次分工与贡献比例

成员与角色沿用已有组队材料。本次贡献比例为：Sun Zikun 13%、Luo Yuhan 11%、Zhou Shengdong 9%、Wu Junjia 7%，其余 10 人各 6%，合计 100%。下表列出本次实际完成的工作与贡献比例。

贡献比例合计：13% + 11% + 9% + 7% + 10 × 6% = 100%。上述比例为本次作业口径，具体工作说明应与实际完成记录一致。

7.2 当前产物与提交安排

本次主要以宿舍为单位分配任务，个人实际完成的工作和贡献比例见上表。关于这种协作方式的体会，见第 8.3 节。

8 讨论照片、感受与成员评价

8.1 团队原型讨论照片

图：团队提供的本次原型讨论现场照片。成员围绕电脑查看原型页面。

8.2 设计复盘

例如，拾主点击了“交出物品”，失主还没有确认收到，这时应保留“交接中”。实际检查时还发现，双方已经确认后，一处旧提示仍写着等待完成，现已与物品状态统一。后续评审会继续检查核验失败、单方确认和重复申请等情况。

8.3 成员感受与相互评价

这次作业中，我们小组主要以宿舍为单位分配任务。熟悉的同学一起合作，沟通和讨论都更方便，也更容易配合彼此的做事习惯，因此能更快地推进任务。这种方式也给了大家更多自由度：在明确任务后，各宿舍可以结合自己的时间和工作习惯安排具体做法。对我们来说，这次合作的一个体会是，分工既要明确任务，也要考虑成员之间是否方便沟通。和熟悉的队友一起完成作业，让配合更自然，也让整个过程更灵活。

这次合作中，队友们各有侧重。Sun Zikun 负责统筹，让任务安排更清楚；Luo Yuhan 负责接口、部署和归档，为系统运行和材料交付提供支持；Wu Junjia 负责原型视觉、布局和演示准备，让功能展示更直观；Zhou Shengdong 负责兼容与材料一致性检查，帮助完善细节。其他成员在页面、业务规则和测试上的工作也同样重要。以宿舍为单位合作，让我们沟通更方便，也更容易配合彼此的时间和习惯。

9 答辩演示与提交检查

本次原型演示由 Wu Junjia 负责。答辩时直接点击 PPT 中的墨刀链接：先浏览和筛选，再以失主身份申请认领，切换拾主核验，分别完成双方确认，最后查看消息。不要只展示截图。原型刷新会重置模拟数据，适合重新演练；本地实际系统的数据会保留。