知食份子——大福食刻：原型设计与需求分析

知食份子队 2026-10-15 23:34:25

知食份子——大福食刻：原型设计与需求分析

这个作业属于哪个课程	2601_FZU_SE 软件工程实践
这个作业要求在哪里	软件工程实践团队作业第二次——原型设计&需求分析
团队名称	知食份子
项目名称	大福食刻——福州大学食堂档口点评 App
这个作业的目标	明确校园餐饮点评的用户需求、业务边界和验收标准，完成需求规格说明书与界面原型，制定团队计划，明确成员分工与协作机制，并准备需求分析和原型设计答辩材料。
其他参考文献	《构建之法》；课程提供的软件需求规格说明书参考结构；《大福食刻软件需求规格说明书》v1.0

知食份子——大福食刻：原型设计与需求分析
一、团队项目整体安排与计划
1.1 项目里程碑规划
1.2 本次作业任务安排
1.3 阶段衔接、进度控制与成果复核
二、项目关键点、难点与风险分析
2.1 点评主线与产品差异化
2.2 基础数据统一与冷启动
2.3 多维评价与场景适配
2.4 就餐记录联动与饮食档案复用
2.5 AI 能力成本、数据条件与服务稳定性
2.6 身份权限、个人隐私与社区治理
2.7 功能范围、阶段依赖与交付进度
2.8 风险跟踪与应对安排
三、组员分工与本次作业贡献度
3.1 组员分工汇总表
3.2 工作量统计与确认方式
四、团队成员分工协作机制
4.1 沟通讨论流程
4.2 版本仓库协作与成果整合
4.3 分歧、版本冲突处理
4.4 任务同步与完成确认
五、软件需求规格说明书
六、界面原型设计
七、需求分析 PPT 链接
八、界面原型答辩 PPT 链接
九、评审表

“大福食刻”是面向福州大学师生的校园餐饮点评 App，围绕档口与菜品查询、评价分享、饮食记录和 AI 辅助推荐，帮助师生更方便地选择就餐地点与菜品。

一、团队项目整体安排与计划

项目需求分析于 2026 年 9 月 29 日启动，按照“需求与设计—核心功能开发—体验增强—扩展与验收”四个阶段推进。当前处于第七周，第八至第十周依次完成核心功能开发、体验增强联调、扩展功能与系统验收，第十周作为整体项目交付节点。

整体计划围绕“浏览点评—发布点评—互动反馈”的核心闭环安排。需求与设计阶段统一用户场景、业务规则、类图、原型及验收标准；开发阶段优先实现分类浏览、搜索筛选、详情、多维评价、评价互动、收藏、登录认证和基础内容管理，让用户能够查找、比较、评价档口与菜品。后续在已有数据基础上完善就餐记录、内容共建、个性化体验，最后完成扩展能力并开展系统验收。

功能划分为核心闭环、体验增强、扩展能力三层交付。横向对比、导览图、打卡日历、手账、成就勋章、规则化推荐、社区通知属于体验增强层；AI饮食计划、智能推荐、虚拟宠物、手账分享等属于扩展层。每一个阶段先校验已有功能和数据逻辑，再接入新增功能，保障主业务流程连贯可用。

1.1 项目里程碑规划

阶段	时间安排	主要任务	里程碑与交付物	完成标准
需求分析与原型设计	2026-09-29—2026-10-15；10 月 13 日整理本次材料，10 月 15 日提交作业，10 月 16 日原型答辩	梳理用户场景与需求分级，形成领域类图、页面与交互设计、功能描述和验收对照，整理答辩材料	P1：需求规格说明书、界面原型、需求分析 PPT、原型答辩 PPT、作业博客	用户场景、功能、页面和验收要求对应；完成组内评审、材料定稿与课程提交
核心功能开发	2026-10-16—2026-10-22	完成分类浏览、搜索筛选、详情、多维评价、评价互动、收藏、登录认证、基础数据管理及审核举报处理	P2：核心点评版本与接口文档	游客可浏览，用户可查找并收藏对象、发布评价和参与互动；评分按场景展示，管理员可维护基础资料与处理审核举报
体验增强与联调	2026-10-23—2026-10-26	完成横向对比、档口导览图、内容共建、一体化打卡、日历足迹、基础手账、头衔成就、规则化推荐与画像、社区长帖和通知中心	P3：联调版本与阶段测试记录	多功能读取统一的点位与菜品数据、饮食档案；一次打卡联动日历、足迹和成就；内容提交、审核与通知衔接，个人记录权限一致
扩展功能与系统验收	2026-10-27—2026-10-30	推进 AI/规则结合的饮食计划、智能饮食推荐、虚拟宠物及换装、手账编辑、H5 预览与分享等扩展内容；结合隐私与举报机制安排饭搭子匹配；集中测试、修复和整理交付材料	P4：最终版本、验收记录、用户说明与演示材料	按需求追踪表核对已纳入交付的功能与验收项，完成主流程及异常流程检查、问题修复复测，统一代码、文档和演示材料版本

1.2 本次作业任务安排

本次作业聚焦需求与原型设计阶段，为后续开发输出统一依据。需求规格说明书、原型相关PDF材料在2026‑10‑13完成定稿，博客与课程作业按照规定时间节点提交。

任务	计划节点	工作内容	输出成果	承担成员
需求规格说明书	2026-10-15	组织需求章节，整理用户场景、业务规则、类图与验收标准	需求规格说明书	林青妍
原型草稿设计	2026-10-15	梳理页面结构、主要布局和核心跳转，整理线稿与设计素材	原型草稿与页面设计材料	郑春天
原型说明文档	2026-10-15	说明页面用途、交互关系和设计思路，汇总原型展示内容	原型说明文档	郭杰颖
Figma 接入	2026-10-15	对接 Figma 原型文件及共享展示入口，协助组织页面材料	Figma 原型与展示入口	张伟林
原型答辩 PPT	2026-10-15	整理主要页面、交互流程与设计展示，组织演示顺序	原型答辩 PPT	杨雨薇
需求分析 PPT	2026-10-15	整理背景、用户场景、类图、功能与验收内容，衔接答辩讲述	需求分析 PPT	方韵希、王一帆
博客撰写	2026-10-15	整理项目计划、关键难点、成员分工、工作量比例及协作机制	本次作业博客	邱语堂
材料上传与作业提交	2026-10-15	上传材料、汇总链接，完成博客发布与课程作业提交	材料链接、博客链接与提交记录	邱语堂
原型答辩	2026-10-16	展示主要页面与核心流程，讲解原型设计并记录评审意见	原型答辩展示	王一帆
需求分析答辩	2026-10-16	讲解用户需求、类图、功能与验收标准，汇总答辩反馈	需求分析答辩展示	方韵希
组内评审与修订	2026-10-15	交叉检查需求、类图、页面与验收规则，汇总修改意见	复核与修订材料	全体成员

1.3 阶段衔接、进度控制与成果复核

需求到设计的衔接：以用户场景为起点，将业务任务映射到功能描述、数据对象、页面以及验收标准。开发前核对映射关系，保证业务规则落地。

设计到开发的衔接：模块间复用点位、档口、菜品、饮食档案公共数据对象，接口基于统一对象标识。跨模块对接先确认数据源、实体关系、权限、状态流转，再分配开发任务，避免多模块各自维护数据造成不一致。

开发到测试、交付的衔接：按照“核心闭环—体验增强—扩展能力”分批验证功能；功能完成对照验收项复核，缺陷修复后回归测试；阶段交付统一代码、需求文档、原型、演示材料版本。

进度检查与变更处理：拆解任务清单，记录负责人、交付物、截止时间；每周至少一次集中同步；任务延期或者需求变更，需要评估对类图、原型、验收标准的影响，同步更新全部关联材料，优先保障核心流程。

成果复核：需求设计阶段重点校验“场景—功能—页面—验收项”一致性。本次作业复核清单如下：

成果	复核重点	复核人	计划完成时间
需求规格说明书	用户场景、业务规则、类图、输入输出和验收标准的一致性	林青妍	2026-10-15
界面原型与说明	页面结构、核心跳转、操作反馈及 Figma 展示入口	林青妍、郑春天、张伟林	2026-10-15
需求分析 PPT	与规格书的对应关系、类图与验收内容、讲述结构	林青妍、方韵希、王一帆	2026-10-15
原型答辩 PPT	与原型材料的对应关系、页面展示与演示顺序	林青妍、杨雨薇	2026-10-15
作业博客	项目计划、风险、分工比例、协作说明与材料链接	林青妍、邱语堂	2026-10-15

二、项目关键点、难点与风险分析

2.1 点评主线与产品差异化

项目的关键是建立细化到档口和具体菜品的点评体系，让用户能够完成“浏览点评—发布点评—互动反馈”。搜索、榜单、对比和推荐都需要消费点评数据；如果功能分散推进，页面数量增加后仍可能缺少连贯的就餐决策路径。同时，校园美食产品常见功能较为接近，只有浏览、点评和打卡，难以体现本项目的特色。

项目以标准化的点评数据为基础，引入 AI 助手健康饮食辅助，将用户忌口、过敏、预算、口味和饮食目标与校园实际菜品关联。口味画像、饮食计划与智能推荐围绕已有就餐数据展开，使“哪家好吃”的评价信息能够进一步支持“吃什么更合适”的选择。推进时先完成核心点评流程，再逐步接入个性化能力，保持数据积累与功能扩展之间的联系。

阶段检查以完整操作路径为依据：用户能否从分类或搜索进入具体对象、理解适用评分、发布评价并获得互动反馈；推荐和对比能否回到同一档口或菜品详情。由此核对各功能是否共同服务于校园就餐任务。

2.2 基础数据统一与冷启动

点位、档口、菜品是平台多个功能共用的基础对象。同一菜品可能出现简称、别名和不同写法，如果直接将自由文本作为独立条目，搜索、评价归属和横向对比就容易分散。上线初期还存在点位、菜品和评价数量不足的问题，即使页面与接口完成，用户也可能搜索不到内容，推荐结果缺少参考依据。

基础数据采用统一条目维护，新增菜品时先匹配已有记录，未匹配到的内容再提交新增申请并进入审核。分类浏览、搜索、详情、排序、对比和推荐读取同一份点位与菜品数据；食堂档口资料通过用户提交和管理员维护，具有商家主体的外卖、微商等点位通过相应后台更新菜品。

冷启动阶段先整理核心食堂、档口、菜品及示例评价，检查价格、位置和名称等基本字段，再通过班级群、社团群、校园自媒体及食堂二维码触达首批用户，鼓励提交缺失点位与纠错内容。验收既检查重复名称的归并与新增审核，也检查主要就餐场景是否有可查询、可比较的基础内容。

2.3 多维评价与场景适配

平台采用口味、份量、包装、排队体验和配送速度五个评分维度，不同就餐场景适用的内容不同。食堂档口不需要填写配送速度，外卖与微商也不应填写排队时间。难点在于让评价发布、详情聚合和列表排序遵循同一套适用规则，避免用户填写无关评分，或按某一维度排序时与详情展示不一致。

评分项按场景配置，发布页只展示对应维度，列表允许从适用评分项中选择一个维度排序，详情展示相同口径的聚合结果。评价同时结合标签、正文和图片，便于用户了解评分对应的具体体验。

测试分别覆盖食堂与外卖等场景，核对评分项展示、必填规则、评价提交后的聚合更新和维度排序；对同类对象进行横向比较时，还要检查字段是否一致、结果是否能够跳转到正确详情。

2.4 就餐记录联动与饮食档案复用

一条就餐打卡需要同时影响日历、足迹、手账、成就及宠物奖励。如果这些功能各自创建记录，容易出现统计不同步、重复点亮或重复发放奖励。另一方面，筛选、推荐、口味画像和饮食计划都需要读取用户偏好，分别维护设置会增加重复填写，也可能导致同一用户在不同功能中得到不一致的结果。

系统以一条打卡记录组织就餐主线，日历、足迹和成就围绕同一记录更新，照片与随笔作为可选手账内容挂载到对应打卡。忌口、过敏、预算、口味偏好与饮食目标统一维护为饮食档案，相关功能按授权和权限读取最新设置。

联调重点检查首次打卡、重复操作和后续修改：首次到访正确点亮足迹，重复打卡不重复点亮同一点位，当日奖励按规则发放；手账关联正确就餐记录且默认私有。修改饮食档案后，再核对筛选、推荐和计划是否使用同一份更新后的偏好。

2.5 AI 能力成本、数据条件与服务稳定性

AI 助手需要将自然语言需求、用户饮食档案和平台真实菜品关联。实现中的难点包括菜品数据不足、预算与忌口等条件同时约束，以及外部接口费用、响应时间和可用性。若推荐结果与平台菜品脱节，用户就难以继续查看详情和评价；若核心操作等待外部接口，局部服务异常也会影响整体使用。

饮食计划先以规则与模板组织基础能力，再按版本规划接入 AI 增强；AI 不可用时切换为规则化推荐或热门内容。浏览、搜索、评价、收藏和打卡保持独立运行。推荐与计划使用平台真实菜品，展示预算和对应详情入口，并与用户统一饮食档案衔接。

验收覆盖数据不足、多条件组合、无匹配结果和接口异常，核对推荐对象、预算、条件与跳转结果。对需要行为积累的画像功能，检查数据条件与结果说明，使用户能够理解画像形成的依据和后续使用方式。

2.6 身份权限、个人隐私与社区治理

评价可信度需要校园身份与操作权限共同支撑，公开餐饮信息、用户评价、饮食档案和个人手账则具有不同的可见范围。社区长帖及饭搭子等互动还涉及广告、骚扰和违规内容处理。难点在于同时保持公开浏览便利、个人记录权限清晰，以及举报后处理状态可追踪。

认证服务与点评、打卡等业务逻辑分离，写操作按登录状态和用户权限校验，公开页面采用认证标识并保护个人信息。手账默认私有，个人内容由用户决定是否分享；举报、审核、纠错和通知关联内容状态及操作记录，保证处理结果能够反馈到提交者。

社区先落实审核和举报机制，再按版本安排扩展沟通能力。饭搭子匹配采用用户主动开启、脱敏资料、退出、拉黑和举报等规则。检查时覆盖游客浏览与写操作、跨用户访问、公开与私有切换、举报审核及状态通知，验证页面展示与实际访问权限一致。

2.7 功能范围、阶段依赖与交付进度

项目同时包含点评、就餐记录、AI 助手、社区、个人中心、内容共建和管理后台，若一次性并行完成全部功能，接口、页面和数据关系会产生较多交叉依赖。需求或原型修改后未同步下游材料，也会造成开发与测试返工，挤占最终联调时间。

团队按核心闭环、体验增强和扩展能力分阶段交付。核心版本先完成查询、评价、互动和基础管理；体验阶段接入对比、导览、打卡、手账、规则化推荐与画像、社区和通知；扩展阶段再推进 AI 饮食计划、智能推荐、宠物及饭搭子等能力。每次推进前检查上游数据、接口和材料，优先处理阻塞主流程与阶段交付的问题。

需求变化按“提出—评估—确认—记录—关联更新”处理，由相关成员核对功能、类图、原型、输入输出及验收要求是否同步。任务延期时结合影响范围调整顺序或协调协助人员，阶段结束时对照里程碑复核成果及修订记录，保留集中联调与测试的时间。

2.8 风险跟踪与应对安排

项目风险由全体成员共同关注，在 QQ 群和阶段同步中汇总。风险记录结合影响对象、处理措施和复核结果持续更新，先处理影响核心闭环、上游依赖及阶段交付的事项。

风险	重点观察情况	应对安排
功能范围过大、核心任务延期	扩展任务占用核心功能、联调或测试时间，上游成果影响下游推进	按三阶段功能规划交付，优先完成核心闭环，结合依赖调整顺序并协调协作
产品同质化、功能主线分散	新功能与点评数据联系弱，不能帮助用户完成就餐选择	以档口与菜品点评为基础，将饮食档案、画像、计划与真实菜品关联，复核完整操作路径
菜品名称与数据口径不统一	同一菜品重复建条目，搜索、评分和对比引用不同数据	统一基础对象和标准条目，新增前匹配，新增及纠错内容经审核后更新
冷启动数据不足	主要食堂资料或评价缺失，搜索与推荐难以提供有效内容	先录入核心食堂、档口、菜品和示例评价，通过校园渠道引导使用及内容共建
打卡联动与偏好数据不一致	日历、足迹、成就重复更新，推荐与筛选使用不同设置	围绕同一打卡记录联动，统一维护饮食档案，复核重复操作与设置更新后的结果
AI 费用或服务稳定性影响体验	响应延迟、接口异常、数据不足或推荐无法关联真实菜品	规则与模板先行，按版本接入 AI；异常时切换规则化或热门内容，检查条件与详情入口
个人信息与社区内容处理不完善	私有记录被错误展示，广告、骚扰或举报处理状态不清	按权限控制内容可见性，完善审核、举报与通知，按规则推进匹配及沟通能力
需求修改后关联材料未同步	功能、类图、原型、接口与验收标准出现不同口径	评估变更影响并记录决定，逐项更新关联成果，重新验证受影响流程

风险处理后，通过重新操作受影响流程、核对数据及材料版本、复查里程碑交付物确认改进结果，并在下一次任务同步中回看处理情况。

三、组员分工与本次作业贡献度

团队由组长林青妍统筹，采用任务拆分与交叉协作相结合的方式。组长协调阶段进度、成果整合与跨方向问题，成员围绕需求文档、类图、原型、评审、展示材料与博客承担具体工作。各项任务明确工作范围、交付形式和时间节点，关联材料由参与成员共同核对，保证需求、原型和展示内容一致。

3.1 组员分工汇总表

学号	姓名	主要职责方向	具体工作内容	贡献度
102400102	方韵希	需求分析与文档、类图与数据模型、产品设计与界面原型	调研用户需求；撰写需求规格说明书第四部分“领域类图与数据要求”；设计原型图初步布局方案；参与答辩。	13.5%
102400104	林青妍	项目统筹与组长、需求分析与文档、产品设计与界面原型	负责项目整体统筹与进度跟进，组织会议、拆分任务并分配；撰写并整合需求规格说明书主要章节；提供初版界面原型与核心交互设计；统一术语、修正章节结构并补充性能、约束与属性内容；参与需求评审与修改；负责博客撰写与排版。	13.5%
102400124	邱语堂	PPT 与博客	负责项目各阶段作业博客的撰写与 Markdown 排版，汇总相关文档和展示材料链接，完成博客内容核对、材料上传与作业提交。	8.5%
102400207	王一帆	需求分析与文档、PPT 与博客、产品设计与界面原型	制作并审核需求分析文档；汇报原型设计 PPT；提供原型设计思路；审核相关文件。	13.5%
102400208	杨雨薇	PPT 与博客、产品设计与界面原型	参与团队选题汇报 PPT 的制作；参与产品设计方案讨论；负责原型设计展示 PPT 的制作。	12%
102400209	郑春天	产品设计与界面原型、前端开发、测试与验收、PPT 与博客	参与用户需求调研与整理；完成产品方案设计与原型布局草图；设计视觉风格与图标素材；负责前端页面编码与样式调试；开展功能测试并跟进修复；制作各阶段汇报 PPT。	13.5%
102400232	张伟林	产品设计与界面原型、AI 与第三方接入	搭建“本地 Agent + 墨刀 AI”协同流水线，通过 MCP 接口分批生成 33 页可交互原型；脚本化完成素材预处理、指令编排与素材映射；开发自动化验收脚本全站比对并回灌迭代修正，产出可交互原型链接供团队评审。	13.5%
102400301	郭洁颖	产品设计与界面原型、需求分析与文档	负责规格书《界面原型》章节的编写与交付，将手绘线稿整理转写为页面清单、布局结构与跳转关系；整理全站素材与视觉规范，对高保真与前端原型提出修改建议，并核对原型与文档口径一致性。	12%
合计	—	—	—	100%

3.2 工作量统计与确认方式

贡献度结合成员承担的任务、成果交付、评审修订与整合工作进行汇总，以上八名成员的贡献度合计为 100%。多人共同完成一项任务时，分别说明各自承担的部分；需求整理、类图与原型设计、材料制作、博客撰写及评审修改均纳入工作量统计。

成员在 QQ 群同步本人工作与对应材料，由组长组织核对任务范围及成果，再汇总分工与贡献度。后续阶段按同样方式记录任务变化与协作情况，使工作内容、交付物和工作量比例对应。

四、团队成员分工协作机制

本项目采用“即时同步—集中讨论—结论记录—任务落实—结果回看”整套协作流程。沟通载体以QQ群作为日常通知、进度同步、资料共享；复杂方案讨论、页面评审、方案抉择使用腾讯会议。会议记录、回放文件留存，方便未能参会成员补全信息。

4.1 沟通讨论流程

讨论准备：发起问题时说明关联任务、当前现状、已有材料、期望解决目标。组织者提前整理议题，相关成员提前准备文档、原型截图等支撑材料；简单问题群内直接处理，复杂议题纳入会议议程。

讨论与决策：讨论围绕用户场景、阶段目标、实现成本、关联影响展开，对比不同方案优缺点。讨论结束后整理会议结论，明确修改对象、负责人与截止时间；跨模块事项由相关成员共同确认，避免不同成员依据不同版本方案开展工作。

记录与落实：会议纪要记录议题、结论、待办任务；回放文件发送QQ群。成员根据纪要开展工作，未参会成员阅读纪要和回放了解会议内容。下一次团队同步校验上一轮待办是否落地，形成闭环。

作业沟通安排：需求阶段任务密集时连续多天组织讨论；其余阶段每周至少一次集中会议。会议由组长林青妍组织，会议记录由林青妍维护，回放发送至QQ群。

沟通实例：健康与社交功能规划及需求、原型协作讨论。

会议通过头脑风暴讨论食堂评价平台的差异化方向，围绕健康辅助与社交互动两条主线提出功能设想。健康辅助方向包括 AI 个性化饮食计划、菜品识图与食材分析、粗略热量参考，以及与饮食习惯关联的趣味形象；社交互动方向包括日历打卡与图文分享、口味同好匹配与关注、档口地图及排队计时。

会议还讨论跨食堂的相似菜品价格与评分对比、打卡互动的成就勋章，以及在评论区使用 AI 总结高分和低分评价。上述方向用于后续需求筛选、优先级讨论与原型设计，使新增功能围绕校园就餐场景展开。

协作上，会议提出需求组 3 人、原型组 5 人的安排。需求组由林青妍、方韵希、王一帆负责需求分析整理，原型组围绕 UI 设计与页面展示推进工作；具体材料任务按本次作业分工执行。会议安排次日 14:30—15:30 进行 UI 评审，相关小组至少一名成员参会展示，未参会成员提前在群内投票选择偏好的方案，以便集中讨论。

讨论方向	主要内容	后续安排
健康辅助	饮食计划、食材与热量参考、饮食习惯关联形象	结合饮食档案梳理使用场景，明确所需数据与功能优先级
社交与分享	打卡分享、同好匹配、关注、地图与排队记录	对照校园就餐流程整理页面与交互，讨论分阶段安排
评价与激励	菜品对比、成就勋章、AI 评论总结	将功能与评价、打卡数据衔接，纳入需求与原型讨论
分组与评审	3 人需求组、5 人原型组；群内预选与 UI 集中评审	完成各自材料，汇总预选意见并形成设计修改方向

会议日期：2026.10.12。

4.2 版本仓库协作与成果整合

项目文档、原型、代码和答辩材料按类别管理。文档使用统一的材料名称、版本号与日期标识，成员开始修改前同步当前版本，完成后说明变更对象、修改原因和需要同步的关联内容。课程提交材料由组长组织复核后统一汇总。

文件目录按需求文档、原型材料、代码、答辩材料和协作记录分类，分别归入 docs/requirements、docs/prototypes、src、presentations 与 records。文档文件名采用“材料名称_版本号_日期”，同一成果的可编辑源文件与阅读版放在同一类别下，便于更新和查看。

文档协作按章节或页面拆分，由对应成员修改、林青妍整合。代码协作计划采用主分支保存统一版本，具体任务在对应任务分支推进，合并前由相关成员核对接口和数据规则。文件整合后保留修改摘要，以便后续成员查找依据和继续工作。

提交与合并流程。 成员开始任务前获取仓库最新版本，在任务分支完成修改；提交说明写明修改对象和目的，例如“完善档口详情页的评分维度说明”。提交合并请求时列出改动范围、关联页面或需求、验证结果及需要共同确认的事项。由另一位相关成员复核后整合到主分支，合并后的成果再检查一次关联文档、页面和接口，确保后续任务使用同一版本。

交付材料管理。 每次阶段交付在材料目录中保存可编辑源文件与 PDF 阅读版，以材料名称、版本号和日期对应同一次定稿。上传后检查文件能否打开、内容是否完整，以及老师使用链接时的访问权限；确认后再更新博客中的材料入口。后续修订保留提交记录，并同步替换博客和答辩引用的版本。

需求、原型或接口发生调整时，关联材料同步更新。例如，评分维度修改后，同步评价页面、接口字段和验收标准。阶段结束时，林青妍与对应材料成员复核版本和内容，邱语堂负责材料上传、链接整理与课程提交。

仓库协作安排	具体信息
华为云代码仓库	大福食刻项目仓库
主分支	`master`，用于保存统一的阶段版本
目录与命名约定	按需求、原型、代码、答辩和协作记录分类；材料采用“名称_版本号_日期”命名
分支或文件协作约定	文档按章节或页面分工后集中整合；代码按任务分支修改，复核后合并至统一版本
材料整合与上传	林青妍统筹整合和复核，对应同学核对材料；邱语堂负责上传、链接汇总与课程提交
本次版本与提交记录	2026-10-15 归档最新版需求规格说明书、界面原型说明阅读版、原型设计答辩材料与需求分析答辩材料，具体文件、提交时间及提交号见下表

本次需求规格说明书、原型说明及两份答辩材料由邱语堂统一上传至 master 分支，分别填写提交说明，保留文件版本及归档记录，供后续成员查阅和修订。

提交时间（北京时间）	材料版本与文件	修改摘要	提交记录
2026-10-15 22:49:55	最新版需求规格说明书：`大福食刻App-软件需求规格说明书.pdf`	更新软件需求规格说明书，替换原归档文件	1389a74f
2026-10-15 23:13:26	界面原型设计答辩材料：`大福食刻-界面原型设计说明.pdf`	更新原型设计答辩 PPT 的 PDF 版，共 37 页	f32ed064
2026-10-15 21:34:59	需求分析答辩材料：`大福食刻-需求分析答辩.pdf`	归档需求分析答辩 PPT 的 PDF 版，共 15 页	966538d6

4.3 分歧、版本冲突处理

协作冲突分为内容分歧和文件版本冲突。内容分歧多集中在功能范围、页面结构、评分规则、数据模型；版本冲突来自多人并行修改同一文档、使用不同底稿，造成多份材料口径不一致。

处理内容分歧：梳理各方方案，结合用户场景、业务规则、实现成本、阶段目标讨论；有条件的通过原型对比方案效果；无法达成统一时由组长组织仲裁，记录决策理由、影响范围，分配负责人落地修改。

处理文件版本冲突：相关成员对照基准版本比对各自修改内容；由该模块负责人完成整合，原修改人复核修改完整性。代码合并后验证受影响流程；文档、原型冲突处理完成后校验术语、类图、验收标准全部对齐。

冲突记录模板用于留存分歧处理过程，下面是本次作业实际发生冲突与处理记录：

发生日期	问题与涉及材料	参与成员	讨论依据与最终结论	修改负责人及复核结果
2026-10-12	类图组织方式争议：初期计划绘制一张包含所有实体的大类图，后期讨论是否拆解为多模块分图。涉及材料：需求说明书第4章领域类图与数据要求、数据库逻辑设计内容。	需求组（方韵希、王一帆）	依据文档4.1、4.3章节设计原则，单张大图实体冗余、连线杂乱，不符合高内聚低耦合的设计逻辑，不利于开发维护。最终结论：采用1张领域总览图+6张业务模块分图架构，分图涵盖用户与身份、餐饮基础数据、点评与互动、打卡与成长、社区与内容治理、推荐与AI助手，总览图仅保留核心业务骨架与关键关系。	方韵希按七图架构重绘全套类图，补写4.3节类图结构说明；王一帆对照分图实体、属性、关联关系完成数据库表结构设计，复核确认无实体遗漏、关系错位，完全匹配文档规范。
2026-10-12	AI助手模块版本归属争议：部分成员建议首版仅保留基础点评功能，AI健康辅助模块延后迭代；部分成员坚持AI为核心差异化创新，需纳入首版。涉及材料：需求说明书1.2项目背景、2.6需求分级与版本规划、6.1AI助手功能需求。	全体组员（组长林青妍主持）	依据文档1.2节差异化定位、2.6节版本规划、9.1核心设计思路，AI健康饮食辅助是项目区别于同类校园点评产品的核心优势，贴合“健康中国2030”政策导向，不可删减。结合第三方接口不稳定的约束条件综合研判。最终结论：首版保留AI助手核心入口（口味画像、个性化饮食计划、智能饮食推荐），采用规则+模板模式实现；大模型智能增强能力划入三期迭代，配置接口降级机制，AI服务异常时自动切换热门/规则推荐，保障核心流程可用。	方韵希优化4.2.7推荐与AI助手类图，补充接口降级、数据授权关联关系；组长林青妍复核2.6版本规划、1.2创新定位、6.5系统约束等章节，确保AI模块设计、版本划分、降级逻辑与全文需求完全统一。
2026-10-14	原型文档交付质量返工问题：首批交付的高保真原型及原型说明文档，存在页面跳转逻辑错误、功能入口缺失、交互逻辑与需求规格不符等问题，未匹配5.4核心交互说明规范，文档审核驳回返工，小幅延后项目进度。涉及材料：5.界面原型章节、墨刀高保真原型文件、核心交互说明文档	原型设计组负责人郑春天、组长林青妍	依据文档第5章界面原型全套规范，包含页面清单、核心交互跳转、功能权限、游客/登录用户逻辑、降级规则等要求，原型交付未完成前置自检，出现逻辑偏差。最终结论：原型组全量修正页面跳转、交互逻辑、功能权限等问题，严格对标P01‑P33全部页面规范、核心交互链路、场景适配规则；团队新增文档交付自检机制，所有输出材料必须对标最终需求文档核验，杜绝返工问题。	原型组负责人郑春天完成全部原型页面修正与文档迭代；组长林青妍对照第5章界面原型、核心交互规则、页面清单逐项复核，确认原型与需求文档100%匹配，同步更新项目进度计划，弥补工期偏差。
2026-10-13	文档版本冲突与字段不一致问题：需求说明书第4章类图、第6章功能需求由两名成员并行修改，形成双版本底稿，出现数据结构矛盾，“评价类”字段定义不统一，类图拆分的评分明细结构与功能需求描述错位。涉及材料：福州大学食堂档口点评App软件需求规格说明书v1.0	需求组（方韵希）、组长林青妍	对照文档4.4核心类设计、4.6数据库逻辑需求、6.1.3点评模块功能需求逐项核对，类图已将五维评分从评价主类拆分独立评分明细子表，而功能需求仍沿用旧结构描述。最终结论：以标准化类图数据结构为唯一基准，评价主类仅保留基础文本、时间、关联对象字段，五维评分、标签、图片均拆分独立子表，同步改写6.1功能需求、6.2输入输出格式对应内容，统一全文术语与数据结构。	方韵希整合双版文档，统一全文术语规范（点位、档口、菜品、收藏等），对齐类图与功能需求数据结构；组长林青妍复核点评模块、评分体系、互动逻辑等全部修改内容，确认字段完整、逻辑自洽、无内容丢失，完全符合最终版文档标准。

4.4 任务同步与完成确认

任务同步采用统一清单，贯穿需求、设计、开发、联调和交付阶段。每项任务明确工作对象、承担成员、时间节点和输出成果，执行中更新状态，完成后进入复核。清单既用于安排后续工作，也用于记录已形成材料和接下来需要推进的事项。

进展汇报围绕已完成内容、下一步工作和需要协调的问题展开。影响其他任务的事项及时在群内同步，由林青妍组织相关成员讨论并调整安排；调整后更新清单中的任务范围、时间与关联成果。

完成确认以可检查的文档、页面、接口或修改记录为依据。复核意见落实到修改对象和承担成员，检查通过后更新任务状态。里程碑前集中核对未完成任务与材料版本，保证规格书、原型、PPT、博客和提交链接保持一致。

示例如下：
项目通用任务记录模板

任务	承担成员	计划节点	当前状态	成果位置	待协调事项与下一步

本次作业提交状态安排

本次作业按以下完成状态组织交付，答辩相关项目记录材料与讲述准备。

任务	承担成员	计划节点	提交时完成状态	交付内容
需求规格说明书	林青妍	2026-10-15	已完成	需求规格说明书 v1.0
原型草稿与设计材料	郑春天	2026-10-15	已完成	原型 PDF 与页面设计材料
原型说明文档	郭杰颖	2026-10-15	已完成	页面用途、交互关系与设计说明
Figma 接入	张伟林	2026-10-15	已完成	原型文件与共享展示入口
原型答辩 PPT	杨雨薇	2026-10-15	已完成	原型展示 PPT 与演示顺序
需求分析 PPT	方韵希、王一帆	2026-10-15	已完成	需求分析 PPT 与讲述内容
作业博客	邱语堂	2026-10-15	已完成	项目计划、风险、分工比例、协作机制与材料链接
材料上传与作业提交	邱语堂	2026-10-15	已完成	公开材料链接与课程提交记录
原型答辩准备	王一帆	答辩日期 2026-10-16	未完成	原型讲述与演示准备
需求分析答辩准备	方韵希	答辩日期 2026-10-16	未完成	需求分析讲述准备

任务同步实例：原型与需求材料的分工、进度汇总和接收确认

本次作业通过 QQ 群将分工发布、时间确认与进度反馈串联起来。以下聊天记录分别展示任务安排、成员回应和阶段进度汇总，作为上述同步机制的实际应用。

同步环节	群内实际记录	协作作用
发布任务与确认分工	王一帆在群内列出需求答辩、原型答辩、两份 PPT、原型接入、说明文档、草稿设计、规格书和博客等任务，组长林青妍回复“是的”确认安排	将各项材料与承担成员对应，形成共同执行的任务清单
明确节点与接收确认	林青妍提出原型设计于周三中午 12:00 完成的安排，提醒有问题及时反馈，并要求收到后回复；张伟林回复“OK的”，邱语堂回复“OK”	通过成员回应确认任务通知已送达，并建立问题反馈入口
汇总进度与衔接后续任务	林青妍汇总需求规格书修改、原型修改意见与配合修订、PPT 制作和博客撰写等事项，提出当晚定稿安排；郑春天随后转发原型修改意见的聊天记录	将已开展工作、定稿节点与后续材料依赖放在同一次同步中，便于相关成员衔接

图 1 展示任务发布与组长确认，图 2 展示计划节点及成员接收回应，图 3 展示阶段进度汇总与修改意见转发。执行过程中，成员按任务清单更新成果位置，材料完成后再由相关成员复核并更新状态。

图 1：任务分配与组长确认