2026秋软件工程结对作业（第一次）：校园失物招领小程序需求分析与原型设计

课程	H202601软件工程与软件工程实践
作业要求	2026秋软件工程个人作业（第三次）
作业目标	完成「校园失物招领小程序」需求分析和原型设计
学号姓名	102401231 赵紫龙、102401228 林彦翔

一、《构建之法》读后感

这次读的是《构建之法》第 3 章和第 8 章，读完之后最直接的感受是：以前我对“会写代码”的理解太窄了。

第 3 章先给了一个很有意思的对比。书里贴出职业篮球运动员的赛季数据——出场时间、命中率、篮板、助攻、失误——然后反问：软件工程师有没有类似的数据来说明自己的能力？答案是几乎没有，唯一比较清楚的数据可能是加班时间。作者随后列出初级工程师成长的几个方面：技术技能、对问题领域的了解、对软件设计和软件工程思想的理解、职业技能（自我管理、表达交流、与人合作、按质按量完成任务），最后一条是实际成果——你参与的产品到底有没有价值，你在其中起了什么作用。书里那句话我记住了：“行胜于言，实际的工作成果，是最重要的评价标准。”

这一章还引了 Bill Buxton 的文章《The Opposite of Skill》：技能的反面不是“没技能”，而是“还在解决基础问题”。书里把问题分成三层：低层次的问题练到变成自动操作才算精通，中间层次的问题要花脑力，高层次的问题往往根本无暇顾及。看到这里我有点惭愧——这次不少时间我花在“把卡片对齐、把颜色调好看”这类低层次的事情上，而不是先把流程想清楚。

第 8 章讲需求分析和估计，最扎心的是“探险者总是高估自己的能力，低估未知的困难”：早期西班牙探险者站在科罗拉多大峡谷边上，觉得那不过是一条小溪，一天就能过去，结果下去一半就人困马乏地撤了回来。作者给了一个经验公式：实际耗时 = 估计时间 X ± N，N 是你做过同类工作的次数；如果第一次做，N 等于 0，估计值的偏差可以大到没有意义。所以要么参考前人的经验——书里说“问一问当地人跨越大峡谷要几天”；要么把任务拆到能估准为止，8.7 节的 WBS（分而治之）讲的就是这件事：从最终要交付的东西出发一层层往下拆，拆到叶子节点，而每个叶子节点的成本最好不要超过两周。

还有一处印象很深：作者说估计要区分“客观估计”和“主观决心”。这句话对我们这次作业特别贴切——我们一开始列了十几个功能，地图定位、站内聊天、信用积分都想要，冷静下来才发现那是“决心”，不是我们真能做完的东西。把范围收敛到浏览、发布、搜索、详情和状态管理之后，反而每一步都说清楚了。

我们这次是两个人结对做的，书里第 4 章讲两人合作的部分（一个人操作、另一个人检查，之后交换角色）我们算是照着走了一遍。最大的收获是：先把要解决的问题想清楚，比把页面画好看重要得多。

二、题目来源

校园里丢东西是很常见的事：校园卡、钥匙、水杯、雨伞、耳机、课本，几乎每个同学都丢过或者捡到过。

现在的做法是在班级群、宿舍群、朋友圈里发消息。问题有三个：一是分散，不同的人在不同的群里，看到的信息范围完全不同；二是很快被刷走，群聊消息一多，几天前的招领信息就翻不到了；三是没有"结束"机制，东西早就还回去了，消息还挂着，让人白高兴一场。

我们想做的"校园失物招领小程序"，就是给学生一个统一的入口：寻物和招领信息集中放在一起，可以按关键词搜索，并且能标明信息当前是否还有效。

三、用户需求分析

主要用户有两类。 第一类是失主，丢了东西以后希望尽快找回，一方面自己发布寻物信息，另一方面主动去查有没有人捡到。第二类是拾获者，捡到东西后想尽快交给失主，但不愿意为了这件事花费太多精力，所以发布操作必须尽量短。

还有一类间接相关的角色是宿舍管理员和保卫处，他们经常收到同学送来的失物。不过这次作业不涉及线下交接流程，我们只把它当作背景，不设计专门的角色和功能。

用户真正的问题不是"没有功能"，而是"信息找不到、也不敢信"。 由此我们整理出四条核心需求：

1. 统一入口：打开小程序就能看到最近的寻物和招领信息，不需要先加入某个群。
2. 能搜到：用户通常已经知道自己丢了什么，用"校园卡""雨伞"这样的关键词直接搜，比一条条翻列表快得多。
3. 信息够判断：一条信息要能支持用户判断"这是不是我的东西"。因此物品名称、时间、地点和特征描述是必填的；照片有帮助，但很多同学拿不到照片，所以设为选填。
4. 状态要准：物品找回或归还后信息应当可以结束，避免占用别人的注意力。

四、功能设计

需求整理完之后，我们把功能收敛成五件事，对应五个页面。

① 首页：顶部是搜索入口，下方是"全部 / 寻物 / 招领"三个分类，主体区域用卡片展示最近发布的信息。卡片只放浏览时需要的信息——物品名称、类型、地点、日期和状态，特征描述和联系方式留给详情页。这样做是为了让用户一眼扫过去就能判断"这条和我有没有关系"。

② 发布信息页面：寻物和招领共用一套表单，用户先选择类型，再填写物品名称、时间、地点、描述和联系方式，照片选填。选择"寻物"时字段是"丢失时间""丢失地点"，选择"招领"时自动变成"拾取时间""拾取地点"，避免两套页面各写一遍。

③ 搜索页面：解决"我知道自己丢了什么"的情况。用户可以输入关键词，也可以只看寻物或只看招领。搜索结果的展示方式与首页保持一致，不再单独设计一套卡片，减少用户的认知负担。

④ 信息详情页面：展示一条信息的完整内容，包括物品图片、名称、类型、时间、地点、特征描述、联系方式和当前状态。底部提供一个"我已确认是这件物品，联系发布者"的按钮，让"确认信息 → 联系对方"成为一个明确的动作。

⑤ 我的发布：管理自己发布过的信息。物品找回或归还后，可以把状态改成"已找回"或"已归还"，也可以继续编辑内容。这个页面是为了让信息有终点，否则列表里会堆满已经无效的内容。

五、原型设计

我们使用的原型设计工具是 Figma（Figma Design），原型在线链接：

校园失物招领小程序 · 可点击原型

打开上面的链接后，点右上角的播放按钮进入演示模式，就可以点着走完整流程：首页点一下进入信息详情，搜索页点一下查看结果对应的详情，发布信息页点一下进入发布成功页，发布成功页可以返回首页，「我的发布」可以进入编辑信息页。

下面是五个界面的状态图。每一张里从左到右是同一个界面在不同情况下的样子——原型不只画了“一切顺利”的那一版，加载中、加载失败、没有结果、必填项没填这些容易出问题的地方也单独画了出来。

首页：① 已有同学发布信息（正常浏览）② 加载中（骨架屏占位，不出现白屏）③ 加载失败（给出重试入口）④ 只看寻物（分类筛选后的列表）。

搜索：① 还没输入（给出最近搜索和热门搜索）② 输入关键词后筛选（只看寻物 / 只看招领）③ 搜索中（骨架屏）④ 没有匹配结果（空状态 + 返回首页浏览）。

信息详情：① 正常（完整信息 + 联系方式）② 加载中（图片和字段都用骨架屏占位）③ 已失效（物品已归还，信息只读、不再接受联系）④ 复制联系方式成功（提示已复制）。

发布信息：① 招领表单 ② 切到“寻物”后字段自动变成“丢失时间 / 丢失地点”③ 必填项没填（字段标红并逐条提示）④ 提交中（按钮显示“发布中…”，避免重复提交）。

发布成功、我的发布（修改状态前会二次确认）、编辑信息（必填校验）、个人资料页。

六、用户使用流程

主要流程有两条。找东西：打开小程序 → 首页浏览或搜索 → 查看信息详情 → 核对物品特征 → 复制联系方式联系发布者。发信息：点击底部"发布" → 选择寻物或招领 → 填写物品信息 → 校验必填项 → 发布成功 → 在"我的发布"里管理状态。

除了正常路径，原型也把容易出问题的状态画了出来：列表和搜索结果加载时用骨架屏占位，避免用户看到白屏；加载失败时给出重试入口；搜索没有匹配结果时给出空状态提示和「返回首页浏览」的出口；发布信息时必填项没填会标红并逐条提示，提交过程中按钮变成“发布中…”避免重复提交；物品归还后信息会变成已失效的只读状态；修改自己发布的信息状态前还会二次确认。

flowchart TD A[打开小程序] --> B[首页：浏览全部 / 寻物 / 招领] B --> C{是否已经知道要找什么} C -->|否| D[浏览信息卡片] C -->|是| E[搜索页：输入物品名称] E --> F[查看搜索结果] D --> G[查看信息详情] F --> G G --> H[核对物品特征与地点时间] H --> I[复制联系方式，联系发布者] B --> J[点击底部发布] J --> K[选择寻物或招领，填写物品信息] K --> L{必填项是否完整} L -->|否| M[标出缺失字段，保留已填内容] M --> K L -->|是| N[立即发布] N --> O[发布成功，可查看信息] O --> P[我的发布：管理自己发布的信息] P --> Q[标记为已找回 / 已归还]

七、结对过程

我们两人是同一个宿舍的，所以讨论大多是面对面完成的。整个过程大致分三轮。

第一轮是理需求。 我们先各自写一份"用户会遇到什么问题"，然后放在一起对比。我负责记录场景和功能点，林彦翔负责反问"这个功能真的需要吗"。第一版我们列出了十几个功能，讨论之后砍掉了大半，最后只留下浏览、发布、搜索、详情和状态管理五项。

第二轮是画页面。 一人操作原型工具，另一人对照需求清单逐条检查页面上有没有对应的元素，检查完一轮再交换角色。这个过程里我们发现了一个问题：最初详情页没有"发布者联系方式"以外的任何引导，用户看完信息不知道下一步该做什么。后来才加上了底部那个确认按钮。

第三轮是走流程。 我们按"找东西"和"发信息"两条路径，把每个页面从头到尾点一遍，重点看跳转是否连贯、字段是否前后一致、状态有没有终点。这一轮改动最多的是文案，比如把"提交"改成"立即发布"，把"无人认领"改成"待认领"。

八、PSP 表格

PSP 阶段	预估时间 / min	赵紫龙实际 / min	林彦翔实际 / min
阅读任务并讨论需求	40	35	35
阅读《构建之法》第 3、8 章	60	50	50
用户需求分析	50	60	45
功能与页面规划	40	35	35
整理用户使用流程	30	25	30
原型页面制作	300	260	240
结对检查与修改	60	55	55
博客整理	90	70	50
个人总结	30	20	20
合计	700	610	560

九、个人总结

赵紫龙

这次作业让我最意外的收获是“敢砍功能”。刚开始我兴致很高，觉得失物招领可以加地图定位、站内聊天，甚至做信用积分。但读完第 8 章那句“探险者总是高估自己的能力，低估未知的困难”，再回头看我们列的功能清单，我才发现那些大多是“主观决心”，不是我们真能做完的东西。把功能收敛到五页之后，反而每一页为什么存在都能说清楚了。

另一个体会来自第 3 章。书里说工程师成长有五个方面，最后一条“实际成果”才是最重要的评价标准。这句话让我把注意力从“页面好不好看”挪到了“这个设计下一次真动手做起来，到底能不能做完”。我还照着书里的估计公式反省了自己的 PSP：我从来没做过原型设计，N 大概是 0，所以预估 300 分钟、实际用了 260 分钟。