软件工程第三次作业

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/fzu/202601SofwareEngineering
这个作业要求在哪里	https://edu.cnblogs.com/campus/fzu/202601SofwareEngineering/homework/16743
这个作业的目标	通过需求分析和原型设计初步熟悉结对编程
学号	052403137，182400320
figma链接	拾伴｜校园失物招领 · 交互原型初稿

这里给出全部内容展示，细节可点击链接查看，过程则已呈现在文章里

QQ_1790608761149

0x00 《构建之法》读后感

第三章《软件工程师的成长》让我重新看待“熟练”：能力要靠工作质量与具体记录衡量。这次原以为需求拆解很简单，实际耗时却超过预估；后续应把遗漏的边界、返工原因与耗时一起记录，让估算有依据。熟悉工具之外，还要持续检验自己的判断。

第四章《两人合作》中，驾驶员负责操作，领航员负责检查，两者可以互换。我更看重持续复核的价值。从 PRD 讨论到原型微调，需要有人追问失败后怎么办、状态是否一致；后续应轮换操作与复核，避免一人包办。及时暴露分歧，才能减少后续返工。

第八章《需求分析》提醒我，需求还来自利益相关者。除了失主和拾物者，还要考虑保管、值班与审核人员。第二版补上这些角色，但目前仍是设计假设，需要用访谈和原型验证，并按价值与成本确定功能优先级；界面能走通，不能证明学校愿意接手。

0x01 需求分析

最初让 AI 生成第一版 PRD：

发布、搜索、详情和状态更新虽然齐全，却没回答信息从哪里来、浏览者为何帮忙、谁处理冒领。于是继续追问参与动机和归还过程：

得到了现在的版本refactor: prd: #31468d7。第二版从参与者的动机重新推导功：。拾物者可能赶时间、不方便保管，所以需要短表单和服务点移交；浏览者可能只在群里见过相关消息，所以提供关联记录、提交线索等轻量入口，并反馈帮助是否有效。头衔和现实奖励围绕核实后的贡献设计，保留学校加分的兼容流程，但不按发帖量奖励，也不替学校承诺加分。

这种低频服务并不能靠用户不断拉人、反复刷新首页维持，更值得考虑的是借助学生组织、校园墙和服务点，提高校内有效信息的覆盖。群消息可以自愿转报，但转报人不等于持有人，需要确认来源、关联重复记录，并在结案后反馈原渠道。表单则加入类别建议、同义词和时间地点匹配，减少重复填写与查找；建议错误或服务失败时，仍允许人工修改和继续发布。

对于可信度，第二版同时核验“是不是失主”和“是否真的持有物品”，保留未公开特征，按需授权联系方式，区分单方自报和已核实归还。可编辑的文字和图片还需要审核、举报、申诉与处理责任人。增加这些环节会提高操作成本，因此普通物品保持轻量核对，复杂争议再交由服务点协助，不能让所有用户都填一套繁重的证明材料。

文档结构也随之调整：把页面、流程、异常状态和原型说明合在一起，先用 Mermaid 总览与分流程图串起查找、入库、核验交接和监管，再解释角色在每个节点要做什么。搜索无结果后能订阅或继续发布，提交失败后保留输入，单方确认后进入待确认状态，每个分支都有下一步，也能追溯到它要解决的体验问题。

两次引导还纠正了产品定位的偏移。各学校使用独立的程序实例和服务器，自行运营监管；我们提供软件能力，不集中收集高校学生信息。当前程序只考虑本校身份与访客，没有必要设计跨校账号关系。真实学校的制度只是样例，产品保留可选激励和审核流程，具体认定、校方接入及部署细则留待后续。

不过，第二版列出了运营角色和处理流程，落地时这些分工能否成立，还需要与校方、学生团体实际沟通。独立部署前，应先了解学校已有的失物登记、保管和学生服务方式，确认由哪个部门负责、学生组织愿意承接哪些工作、遇到争议向谁升级。值班人手、假期安排、学生组织换届后的交接，以及故障由谁响应，都影响这套服务能否持续运行。程序能够部署，并不代表学校已经具备接手运营的条件。

德育分等激励尤其需要进一步审视。它可能提高参与意愿，也会给校方增加证据收集、贡献核实、重复申报检查、统计上报和申诉处理等工作。学生组织确认一条线索有效，并不意味着它有权认定德育加分；哪些行为可以认定、采用什么凭据、由谁复核、是否与已有志愿服务记录重复，都需要与有权限的校方人员确认。即使采用实物奖励，也仍有经费来源、名额分配和领取核销的成本，不能只从学生获得奖励的一面考虑。

0x02 原型设计

采用 Figma，入口见文首。下图是设计流程，原型目前仅覆盖基础操作；智能建议、身份与审核仅作交互模拟。页面、异常状态与走查清单见 PRD 第 4—5 节。

1. 查找物品

flowchart TD home["P01 首页：失物、招领与分类入口"] -->|输入关键词或选择筛选| search["P03 搜索与筛选"] home -->|点击信息卡片| detail["P04 详情：来源、保管人与处理状态"] search --> result{"查询结果"} result -->|读取失败| retry["保留条件，提示重试"] retry --> search result -->|无匹配| empty["放宽条件、订阅或预填寻物信息"] empty -->|调整条件| search empty -->|继续发布| publish["P02 发布寻物"] result -->|有匹配| detail detail --> current{"记录是否仍可操作？"} current -->|已完成、过期或不可用| stale["说明最新状态，提供继续查找入口"] stale --> search current -->|有效| act["通过身份与权限判断后进入 P06"]

无结果可继续寻找，读取失败保留条件重试。

2. 发布与转报

flowchart TD relation["P02 选择关系：寻物、持有、已交服务点或转报"] --> fill["填写必要信息，确认分类建议与公开范围"] fill --> match{"候选匹配结果"} match -->|存在相似记录| candidates["查看候选与匹配理由，保留当前草稿"] candidates --> choice{"如何处理候选？"} choice -->|关联同一物品| link["确认关联说明与来源，P05 关联待处理"] link --> linkedReview["O01 核实关联，结果回到原事项"] choice -->|修改信息| fill choice -->|不是同一件，继续发布| preview["公开预览与私密字段检查"] match -->|无候选或推荐失败| preview preview -->|字段或图片有问题| fill preview -->|检查通过| submit["提交一次，进入发送状态"] submit --> receipt{"本次提交结果"} receipt -->|确认未收到| failed["保留输入，允许重试"] failed --> preview receipt -->|暂时不确定| query["查询本次结果，可在 P05 查看处理进度"] query --> receipt receipt -->|确认收到| review["内容与来源检查，需人工处理时进入 O01"] review -->|转报来源尚未确认| pending["P05 待核实，仅限相关人员查看"] pending -->|补充来源或持有人确认| review review -->|需要修改| returned["P05 展示退回原因与修改入口"] returned --> fill review -->|符合公开条件| published["P04 公开详情，并更新首页与我的事项"]

区分提交与公开，未确认来源先待核实。

3. 协助、认领与交接

flowchart TD detail["P04 有效事项"] --> form["P06 选择参与关系，提交线索或私密证据"] form --> kind{"本次参与方式"} kind -->|提供线索| clue["O01 核实或转交线索"] clue --> feedback["P05 协助记录与采纳反馈"] kind -->|认领或回应| verify["P07 双向核验归属与实际持有情况"] verify --> verdict{"核验结果"} verdict -->|材料不足| form verdict -->|不匹配| mismatch["说明结果，可补证、退出或申诉"] mismatch -->|补充材料| form mismatch -->|申诉| dispute["O01 争议处理，必要时暂停交接"] verdict -->|存在争议| dispute dispute -->|处理后允许继续| verify verdict -->|通过| communicate["站内事项沟通或服务点中转，直接联系另行授权"] communicate -->|双方约定交接| appointment["P07 预约与交接记录"] communicate -->|服务点协助| point["P09 核对范围、开放时间与接收能力"] point --> available{"服务点是否可接收？"} available -->|关闭、已满或不接收此类物品| reschedule["换点、改约或取消本次预约"] reschedule -->|重新选择| point available -->|可接收| appointment appointment --> confirm{"交接凭据是否齐全？"} confirm -->|仅单方确认或尚无回复| waiting["P05 待确认，P08 保留提醒与协助入口"] waiting -->|补齐确认| confirm confirm -->|双方确认或服务点凭据加领取人确认| completed["P05 已核实完成，进入贡献核实流程"]

核验通过后交接，单方确认不算找回成功。

4. 事项处理与贡献反馈

flowchart TD incoming["需人工处理的发布、转报、线索、举报与交接材料"] --> duty["O01 按权限分派值班待办"] duty -->|内容或争议处理| outcome["核实、补证、退回、公开或限制，并说明理由"] outcome --> status["P05 处理状态与 P08 待办通知"] status -->|提出申诉| appeal["O02 独立复核，回避原经办人"] appeal -->|维持、调整或恢复| status outcome -->|需要反馈外部来源| callback["来源联络人回告原渠道，记录是否完成"] callback --> status duty -->|有效贡献已核实| enabled{"本校是否启用对应激励？"} enabled -->|未启用| thanks["P05 感谢与贡献反馈"] enabled -->|已启用| rewards["O02 贡献去重、规则检查与奖励复核"] rewards --> result{"材料、资格与额度是否满足？"} result -->|满足| rewardState["P05 待领取或已领取，学校认定另列进度"] result -->|待补证、重复或额度不足| explanation["P05 保留真实贡献，说明原因与申诉方式"] explanation -->|申诉| appeal rewardState --> message["P08 结果通知与下一步待办"] thanks --> message

进展回到原事项，关闭激励也能完成寻物。