项目	内容
课程	福州大学软件工程实践 W 班
团队名称	七匹狼
项目名称	食话说（FoodTalk）——校园美食推荐及评论分析平台
本次作业要求	软件工程实践第三次团队作业要求
作业目标	完成系统体系结构、功能模块、接口、类图、安全权限、E-R 图和数据库表结构设计，并根据评审意见修订项目方案。
主要参考资料	GB/T 8567—2006、GB/T 9385—2008、GB/T 25000.51—2016、PostgreSQL 16 文档、Redis 7.2 文档、OWASP ASVS。

本文依据七匹狼团队的系统设计说明书、数据库设计说明书、课堂答辩材料和上次需求分析阶段的评审问题整理。系统设计说明书、数据库设计说明书和答辩 PPT 均已上传到华为云代码仓库。

目录

一、项目概况与交付链接

1.1 项目背景

“食话说”面向校园及周边生活场景，解决用户在“今天吃什么”时需要在多个平台之间反复搜索、比较和询问的问题。项目不是简单地展示全量店铺或按照平台星级排序，而是把用户的口语化需求拆解成预算、距离、场景、口味和忌口等结构化条件，再结合经过治理的公开评论证据完成店铺匹配。

用户输入“最近预算有点紧，想吃经济实惠、分量大一点的”，系统将其解析成结构化标签，召回符合条件的店铺，计算匹配度，并展示推荐理由、命中关键词、评论原句、来源平台和更新时间。对于评论数据，系统采用规则筛查、AI 辅助判定和人工审核的质量控制流程，避免把未经处理的评论直接当成推荐依据。

本次系统设计将产品边界限定为用户账号、口味画像、需求解析与推荐、店铺与决策辅助、评论采集与治理、管理端运营和平台支撑。线上下单、支付、订座、排队、真实地图导航、社交动态、私信和站内发表评分不属于本期开发范围。

1.2 交付链接

1. 华为云代码仓库首页：
   七匹狼团队代码仓库
2. 系统设计说明书：
   七匹狼_系统设计说明书.pdf
3. 数据库设计说明书：
   七匹狼_数据库设计说明书.pdf
4. 系统设计和数据库设计答辩 PPT：
   七匹狼_系统与数据库设计_答辩PPT_终稿.pdf

1.3 本次作业的设计目标

• 让系统结构能够承接上次需求分析中的功能需求和验收标准。
• 让推荐结果有明确的数据来源、匹配条件和可解释的推荐理由。
• 让用户偏好、店铺标签、评论证据和推荐结果之间形成完整的数据链路。
• 让管理端具备评论治理、店铺审批、标签维护、审计和监控能力。
• 为后续编码、测试、部署和答辩提供统一的接口、数据和权限约束。

二、系统设计

2.1 分层体系结构

系统采用分层体系结构，自上而下包括：

1. 用户接入层：接收用户端和管理端请求，处理 HTTPS、网关和访问边界。
2. 展示层：负责用户端页面、管理端页面和交互状态展示。
3. 接口层：提供版本化 REST 接口、参数校验、统一响应体、分页和错误码。
4. 应用服务层：编排注册登录、口语解析、推荐、评论治理和店铺审批等用例。
5. 领域层：封装需求解析、标签匹配、匹配度计算、评论证据和状态流转规则。
6. 数据访问层：通过 Repository 和 MyBatis-Plus 等方式访问数据库，隔离 SQL 细节。
7. 数据存储层：使用 PostgreSQL 保存正式业务数据，使用 Redis 保存会话、限流和可重建缓存。
8. 外部服务层：对接公开平台数据源、LLM、短信或邮件服务和对象存储，并设置超时、重试和降级策略。

跨子系统调用必须通过应用服务接口，禁止直接注入其他模块的 Mapper 或直接修改其他模块的数据表。超过 100 ms 且不影响用户主链路的日志、画像更新和指标汇总采用异步处理。

体系结构设计的核心考虑是“职责隔离、依赖可控和故障可降级”。展示层只负责页面状态和用户交互，接口层负责协议适配和参数校验，应用服务层负责组织业务流程，领域层负责相对稳定的匹配、审核和状态规则，数据访问层负责屏蔽 PostgreSQL 的具体访问方式。这样可以避免把推荐算法、权限判断和 SQL 语句混在控制器中，也便于后续替换 LLM、调整推荐规则或增加管理端页面。请求进入系统后先经过网关鉴权和限流，再依次进入接口、应用服务和领域服务；外部服务调用设置超时、重试和降级边界，避免第三方服务异常阻塞核心推荐流程。

2.1.1 体系结构设计图

图 1 展示了系统的八层结构：用户接入层、展示层、接口层、应用服务层、领域服务层、数据访问层、数据存储层和外部服务层。设计思路是把变化频繁的页面、接口和推荐算法放在上层，把相对稳定的数据访问和存储放在下层，使算法替换和页面调整不会直接破坏数据库结构。跨层调用遵循自上而下的单向依赖，领域层通过接口反转访问数据层，避免业务代码直接依赖具体数据库实现。

数据存储层采用 PostgreSQL 16 持久化保存业务数据，Redis 7.2 用于会话、缓存和其他可重新生成的派生数据。

2.2 部署结构

项目预期部署在一台云主机上，采用 Docker Compose 管理服务。部署结构包括：

节点	主要职责
Nginx 网关	HTTPS、静态资源、反向代理、基础限流
Web 前端	用户端和管理端页面
应用服务	账号、推荐、店铺、评论治理、管理端接口
PostgreSQL	用户、店铺、评论、标签、推荐和审计等持久化数据
Redis	会话、验证码、接口限流、推荐结果和店铺卡片缓存
采集 Worker	按频率采集允许访问的公开内容，负责去重、重试和归一化
外部服务	LLM、短信/邮件、公开平台和对象存储等依赖

2.3 功能模块层次

系统按照用例聚类、数据归属和变更频率划分为 6 个子系统、24 个二级模块和 29 个三级功能：

编号	子系统	主要功能
M1	用户账号	注册登录、个人资料、口味画像、收藏、推荐历史
M2	需求解析与推荐	口语需求解析、店铺匹配、推荐解释、结果筛选和反馈
M3	店铺与决策辅助	店铺详情、检索、评分聚合、多店对比、评论展示
M4	评论采集与治理	评论采集、规则筛查、AI 辅助判定、人工筛查、举报申诉、规则库
M5	店铺库管理	店铺入库申请、双人审批、下架流转、标签和图片维护
M6	平台支撑与运维	管理端认证、RBAC、审计日志、监控告警、系统配置、健康检查

推荐主链路为：用户输入需求 → 前端校验 → 网关鉴权与限流 → 解析口语条件 → 读取口味画像 → 召回候选店铺 → 过滤预算、距离和营业状态 → 多维打分 → 去重和多样性重排 → 生成推荐理由与证据 → 返回结果并异步记录反馈。

2.3.1 功能模块层次图

图 2 按“用例聚类 + 变更频率 + 数据归属”划分模块。第一层是系统，第二层是 M1～M6 六个子系统，第三层是二级模块，第四层对应可以独立开发和验收的三级功能。这样的层次可以避免按页面机械拆分，也能让接口、数据表、需求编号和缺陷单通过模块编号建立对应关系。

功能模块划分遵循三个原则：第一，按业务职责划分边界，例如推荐模块只负责需求解析、召回、打分和解释，评论治理模块只负责采集、筛查、证据和申诉；第二，按数据归属确定写入责任，用户画像、店铺标签和审核记录分别由对应模块维护；第三，按变更频率安排模块，页面和推荐策略可以较快调整，而账号、审核状态和审计记录需要更稳定的约束。模块之间通过应用服务接口传递数据，不直接访问其他模块的表，从而减少联调时的隐式依赖。推荐主链路被拆成可验收的步骤后，可以分别测试输入解析、条件过滤、匹配打分、理由生成和结果记录，定位问题时也更明确。

2.4 接口设计

接口统一使用版本前缀，用户端使用 /api/v1，管理端使用 /admin/v1。用户端设计 23 个接口，管理端设计 32 个接口，另有外部服务接口。统一响应体包含 code、message、data、traceId、timestamp 和可选的 costMs。

核心接口示例：

接口	作用
POST /api/v1/recommendations	接收用户口语化需求并返回推荐结果、匹配度、理由和证据
GET /api/v1/shops/{shopId}	获取店铺基础信息、评分聚合和有效评论
POST /admin/v1/reviews/{reviewId}/judge	对评论执行通过、拦截或挂起判定
POST /admin/v1/shops/applies/{applyId}/second-review	执行店铺申请复核，复核人不能与申请人、初审人相同

接口设计同时约束分页、错误码、幂等键、权限点、审计日志和并发冲突处理。用户端和管理端令牌相互隔离，避免普通用户令牌访问管理端接口。

接口设计采用“资源 + 动作 + 结果”的思路：查询类接口重点保证筛选条件、分页游标和空结果语义一致；写入类接口使用幂等键和状态校验，避免重复收藏、重复审批或重复判定；管理端接口额外记录操作者、请求来源和操作结果。推荐接口不只返回店铺名称，还返回匹配度、命中条件、排除原因和证据引用，使前端能够解释结果，测试人员也能根据响应内容验证推荐是否符合用户输入。统一响应体和错误码则让前端能够区分参数错误、未登录、无权限、资源不存在和服务降级等情况。

2.5 类设计

类图按用户端、对比台和管理端三个业务边界组织。核心类包括：用户、口味画像、推荐请求、匹配服务、推荐结果、店铺、菜品、评论、标签证据、收藏、对比台、管理员、评论筛查队列、店铺申请和数据监控。

推荐流程中的核心协作关系如下：

1. 用户维护口味画像并发起推荐请求。
2. 推荐请求提交给匹配服务，匹配服务读取画像和本次输入条件。
3. 匹配服务读取店铺画像、标签证据和有效评论，计算匹配度。
4. 系统生成推荐结果，附带推荐理由、不适合原因和证据引用。
5. 管理员筛查评论和审核店铺信息，合格评论推动店铺画像更新。
6. 用户可以收藏店铺，也可以通过对比台查看 2—4 家店铺的差异。

2.5.1 系统类图

图 3 将用户端、对比台和管理端放在同一业务模型中。用户、口味画像、推荐请求、匹配服务和推荐结果承接推荐主链路；店铺、菜品、评论和标签证据承接店铺画像与评论证据；管理员、评论筛查队列、店铺申请和数据监控承接管理端流程。类图中的业务方法用于封装规则，表结构则负责保存实体属性和流程结果，避免把数据库字段简单堆叠成没有行为的类。

类设计区分实体类、业务服务类和外部接口适配类。实体类保存具有业务含义的状态和约束，例如推荐请求的生命周期、店铺申请的审批状态和评论的治理状态；服务类负责跨实体的业务动作，例如匹配服务读取用户画像、店铺标签和评论证据后生成推荐结果；适配类负责连接数据库、缓存和 LLM 等外部依赖。类之间的关系不是简单复制表之间的外键，而是体现“谁发起行为、谁负责规则、谁保存结果”。例如，推荐请求不直接计算匹配度，而是调用匹配服务；店铺画像不直接信任原始评论，而是读取经过治理的标签证据。这样可以降低类之间的耦合，并让核心业务规则能够独立测试。

三、数据库设计

3.1 数据库选型

数据库设计说明书采用 PostgreSQL 16 作为正式业务数据库，Redis 7.2 作为缓存和会话存储。PostgreSQL 负责保存需要可靠查询、约束和审计的数据；Redis 只保存可以重建的会话、验证码、限流计数、推荐结果快照和热门榜等状态。

数据库选型遵循“正式数据持久化、派生数据可重建”的原则。用户账号、口味画像、店铺、评论、标签证据、推荐记录和审核日志会影响业务判断，因此必须由 PostgreSQL 16 统一保存，并通过外键、唯一约束、检查约束和事务保证一致性。Redis 适合保存短生命周期或高频访问数据，例如登录会话、验证码、限流计数和推荐缓存，但这些数据丢失后可以通过重新登录、重新计算或重新查询恢复，不能把 Redis 当作唯一事实来源。数据库边界明确后，缓存失效不会改变推荐结果的持久化记录，也便于后续进行备份和恢复。

3.2 数据域与实体关系

数据库按数据所有者和写入边界划分为用户与权限域、店铺域、评论治理域、推荐计算域和系统运行域。数据库说明书的核心 E-R 设计分为业务用户域和管理审核域两张图。

业务用户域的主要实体包括用户、口味画像、标签、店铺、评论、标签证据、菜品、推荐请求、推荐结果、收藏和对比记录。管理审核域包括管理端账号、店铺申请、操作日志和系统配置等实体。

主要关系如下：

• 用户与口味画像是一对零或一关系。
• 用户与标签是多对多关系，通过 user_tag 保存偏好极性和权重。
• 店铺与标签是多对多关系，通过 shop_tag 保存命中次数、样本数、比例和统计周期。
• 店铺与评论是一对多关系，评论只有通过治理后才参与画像计算。
• 评论与标签证据是多对多关系，通过 review_tag 保存极性、原文片段、置信度和菜品指向。
• 推荐请求与店铺是多对多关系，通过 match_result 保存匹配度、排序和排除原因。
• 店铺申请由管理员提交并经过另一名管理员复核，申请人、初审人和复核人不能是同一人。

E-R 设计先确定实体的生命周期和数据所有者，再确定实体之间的基数和关联表。对于用户标签、店铺标签和评论标签证据等多对多关系，不把多个标签拼接成一个字符串，而是使用关联表保存权重、极性、置信度、来源和时间等附加属性；对于推荐请求与店铺之间的关系，使用匹配结果表保存当次排序、匹配度和排除原因，保证推荐结果可以回溯。管理端的申请、审核和日志属于不同生命周期，不能只在店铺表中增加几个状态字段替代，因此单独建模并通过管理员 ID 建立操作关系。这样既满足规范化要求，也保留了审核过程和推荐解释所需要的历史信息。

3.2.1 E-R 分析图

业务端 E-R 图围绕用户、口味画像、店铺、评论、标签证据、推荐请求和推荐结果展开。用户标签通过关联关系保存偏好权重，店铺标签通过评论证据聚合形成店铺画像，推荐请求和店铺之间的多对多关系由匹配结果承接。

管理端 E-R 图强调评论审核、店铺申请、管理员和操作日志之间的关系。店铺申请由提交、初审和复核组成，申请人、初审人和复核人需要相互隔离；评论判定结果、判定理由和操作记录保留在内部审计链路中。

3.3 关键表结构

数据库设计说明书正文给出了 13 张业务端表和 4 张管理端表的核心字段设计，主要表如下：

图 6 展示了标签表、用户标签表和店铺表的字段、数据类型、约束和含义。表结构设计遵循以下思路：实体表使用统一主键，关联表保存多对多关系及其附加属性，外键保证引用完整性，唯一约束防止重复标签和重复关联，状态字段支撑审核状态机；金额、评分、比例和时间分别采用适合业务范围的数据类型。核心实体保持规范化，推荐理由和查询快照等需要保留历史状态的内容再使用 JSONB 做有意识的反规范化。

数据对象	代表表	作用
用户与画像	user、taste_profile、user_tag	保存账号、预算、场景、口味偏好和忌口标签
标签字典	tag	统一保存口味、忌口、场景、价格、口碑和菜品等标签
店铺画像	shop、shop_tag	保存店铺基础资料及由有效评论聚合出的标签统计
评论与证据	review、review_tag、dish	保存公开评论、可信度、筛选状态、关键词证据和菜品附带指向
推荐记录	search_query、match_result	保存用户原始输入、解析结果、推荐结果和排除原因
用户决策	favorite、comparison	保存收藏标记、收藏理由和多店对比结论
管理审核	admin_user、shop_request、operation_log、sys_config	支持管理员账号、店铺审批、操作审计和配置管理

核心字段设计体现了以下约束：

• 主键统一使用对应表的 _id，邮箱、工号、平台评论 ID 和申请单号设置唯一约束。
• 评论筛选状态、可信度、匹配度和店铺标签比例均设置取值范围。
• 密码保存 Argon2id 或 bcrypt 摘要，验证码只保存哈希并设置短 TTL。
• 评论只保留匿名编号、来源平台、评分、时间和正文，不保存评论者昵称、头像、电话和精确位置。
• 推荐请求中的关键词、理由、快照和对比店铺列表可以使用 JSONB 保存，便于保留当时的推荐依据。
• 核心实体满足 3NF，派生字段由批处理回写；高频查询使用复合索引、部分索引和游标分页。

表结构设计还考虑了“写入约束”和“查询路径”的对应关系：账号登录需要按邮箱或工号唯一查询，推荐列表需要按状态、价格、距离和更新时间筛选，评论治理需要按审核状态、可信度和创建时间分页，审批流程需要按申请状态和操作者查询。因此索引不按字段数量盲目增加，而是围绕实际接口建立组合索引和部分索引；高频列表使用游标分页，避免深分页造成性能下降。对推荐理由、解析结果和当时使用的证据快照使用 JSONB，是为了保留历史解释而不是替代核心实体关系，关键字段仍保持可检索和可约束。

3.4 菜品数据的处理边界

数据库中保留 dish 表以及 review_tag.dish_id 字段，用于把评论中的菜品名称归一后作为证据的附带指向。当前版本的主推荐对象仍然是店铺，菜品不直接参与店铺排序，避免在菜品数据覆盖不足时产生虚假的精确推荐。

后续如果有足够的菜单和评论数据，可以在现有结构上增加菜品名称归一、菜品级评论统计和菜品推荐接口；这属于对当前设计的增量扩展，不需要推翻店铺推荐主链路。

四、上次评审问题的回应与设计改进

4.1 问题一：用户有“口味标签”属性，店铺是否也应该有这个属性？否则该如何进行匹配？

这个问题直接影响推荐是否能够落地。用户侧的口味标签不能只停留在用户画像中，店铺侧也需要有可计算的标签画像，否则系统只能做字符串搜索，无法解释“为什么推荐这家店”。

本次设计调整为：

1. 用户偏好保存在 user_tag 中，包含标签、正负极性、偏好权重和来源。
2. 店铺标签保存在 shop_tag 中，包含标签、正负极性、命中次数、样本数、比例和统计周期。
3. 评论证据通过 review_tag 连接评论和标签，并保存原文片段、置信度和菜品指向。
4. 推荐服务先把用户口语输入解析为标签，再把用户标签与店铺标签进行匹配，结合关键词命中率、语义相似度、口碑和距离计算匹配度。
5. 推荐理由回溯到具体评论证据，并展示来源平台、时间和原文片段，避免只展示一个无法核对的分数。

因此，店铺确实具有标签属性，但它不是人工随意填写的一列，而是由店铺信息和通过审核的评论证据聚合形成的可更新画像。

4.2 问题二：不考虑店铺菜品推荐吗？

菜品推荐有价值，但如果一开始就把菜品推荐作为与店铺推荐同等规模的主链路，需要额外解决菜单来源、同名菜归一、价格变化、菜品上下架和菜品评论数量不足等问题。直接承诺“所有店铺都能精确推荐到菜品”，反而会放大数据不完整带来的误导。

本次设计采取分层处理：

• 第一层仍以店铺为主推荐对象，保证“找一家合适的店”这条主链路完整可验收。
• 第二层在评论证据中记录菜品指向，店铺详情和推荐理由可以展示“哪些菜品被评论提及”。
• 数据库保留 dish 和 review_tag.dish_id，为后续菜品名称归一和菜品级统计留出扩展位置。
• 菜品暂不直接参与店铺排序，只有当菜品证据达到数量和可信度要求后，再增加菜品级推荐接口。

这样既回应了菜品推荐需求，也控制了本次作业的交付范围：先完成可解释的店铺推荐，再在证据充足的情况下扩展到菜品推荐。

4.3 问题三：注意修改用例图 Actor 与 use-case 的联系，简化 use-case 之间的联系。

本次设计对用例关系采用“直接发起、必要复用、可选扩展”的原则：

1. Actor 只连接自己直接发起或直接参与的用例，不通过其他 Actor 间接连接。
2. 用户与注册登录、画像维护、需求输入、查看推荐、收藏和对比等直接用例相连。
3. 管理员与评论筛查、举报处理、店铺申请审批、标签维护、监控和配置等直接用例相连。
4. 只有当一个用例必然复用另一个用例时才使用 include，例如推荐结果必须经过匹配计算；可选的反馈或补充行为才使用 extend。
5. 删除没有实际业务含义的用例链、重复的 Actor 连接和把页面跳转误画成业务关系的连线。

调整后的用例图更关注业务边界和数据流转，避免通过过多箭头制造“功能很多但关系不清楚”的问题。系统设计说明书中的模块层次、接口和类图再分别承接具体实现，不把所有细节都塞进用例图。

4.4 三个问题对应的改进闭环

评审问题	设计调整	可检查结果
用户口味如何匹配店铺	增加店铺标签画像、评论标签证据和匹配结果表	可以从用户标签追溯到店铺标签，再追溯到评论原句
是否支持菜品推荐	菜品先作为评论证据附带指向，暂不参与主排序	店铺推荐主流程可验收，菜品扩展有表和字段承接
用例关系过于复杂	Actor 只连接直接用例，精简 include/extend	用例图职责更清楚，接口和模块边界更容易核对

4.5 驱动 LLM 协助完成设计的 3 个示例

本阶段没有把 LLM 当作“一次生成最终文档”的工具，而是让它参与检查、提出修改建议和核对多份产物之间的一致性。每次使用后，团队成员都结合系统设计说明书、数据库设计说明书、答辩 PPT 和实际需求进行人工判断，再决定是否采纳。

示例一：检查系统设计说明书的结构和明显错误

使用场景：系统设计说明书初稿完成后，章节目录、接口数量、图表数量和部分章节内容存在可能不一致的问题，需要先进行结构化检查。

代表性提示词：

请检查《食话说系统设计说明书 v3》中的明显错误，并删除目录中标红的 6.5、6.6 部分。请重点核对目录、章节编号、接口数量、图表数量、章节引用和前后表述是否一致；修改前保留备份，并列出仍需人工确认的问题。

AI 输出摘要：AI 对目录和正文进行了逐项检查，指出了目录章节、接口数量、错误码、审批约束等可能存在的不一致，并给出了修改后的目录页码。同时，它明确提示仍有“依赖矩阵与禁止循环依赖的表述”和“关联实体是否在表清单中体现”等问题需要人工确认。

人工修改与采纳理由：团队采纳了目录清理、页码更新和明显编号错误修正，因为这些内容属于可直接核对的格式和一致性问题；没有直接采纳所有设计判断，而是由成员回看需求和数据库设计后再决定，避免把 LLM 的推测当成最终设计。

示例二：根据评审意见修订实体、字段和跨文档内容

使用场景：评审提出用户口味画像需要能够与用户关联，同时项目不涉及城市、商圈等超出当前范围的内容。系统设计说明书、数据库设计说明书和答辩 PPT 需要同步调整，不能只修改其中一份。

代表性提示词：

请根据以下两项设计决定检查并修改相关产物：
1. 项目不涉及城市、商圈内容，只保留距离相关的表达；
2. 口味画像类图中加入用户 id，并与 user_profile.profile_id 对齐。
请分别列出系统设计说明书、数据库设计说明书、答辩 PPT 和博客中需要同步修改的地方，并指出可能出现的数量、字段、索引和图表引用不一致。

AI 输出摘要：AI 将修改拆分为“去除城市/商圈概念”和“口味画像加入用户编号”两条线，进一步检查了店铺实体、推荐记录、表结构、索引、E-R 图和 PPT 统计数据，提醒团队同步更新表数量、图数量、页码和目录信息。

人工修改与采纳理由：团队采纳了“口味画像与用户主键对齐”和“删除城市、商圈实体及相关字段”的建议，因为它们直接回应评审意见并符合当前项目边界；对于 AI 自动推断的数量和表名，团队以实际文档和代码仓库文件为准，逐项复核后才写入交付材料。

示例三：检查关联关系是否在表结构中有合理落点

使用场景：系统设计说明书中的关系分析比较丰富，但数据库设计说明书的表清单不一定需要为每一种关系都新增实体表。团队需要区分“必须落库的关系”和“通过已有字段或业务过程表达的关系”。

代表性提示词：

请对照系统设计说明书 6.2 节的关系描述和 6.3 节的数据库表清单，找出没有明确对应表或字段的关系。请按“关系名称—当前落点—是否需要新增表—建议修改文字”的格式输出，并区分持久化数据与推荐过程中的临时关系。

AI 输出摘要：AI 找出了用户—标签偏好、评论—标签证据、用户—店铺对比等关系，并指出它们未必都需要新增实体表：用户标签可以落到画像字段或关联表，评论标签需要有证据记录或规则表支撑，用户对比则可根据是否持久化决定是否建表。

人工修改与采纳理由：团队采纳了“关系必须有明确数据落点”的检查原则，并补充了 user_favorite、recommend_item、shop_tag_rel 等已有关系的对应说明；没有机械地为每个关系新增表，因为用户对比可能只是前端临时状态，强行落库会扩大当前开发范围。最终在说明书中补充“是否持久化由业务需求决定”的边界说明。

三个示例的协作结论

三个案例分别覆盖了文档结构检查、评审意见落地和关系—表结构一致性核对。LLM 提高了问题发现和修改清单整理的效率，但最终设计仍由团队根据需求范围、已有产物和可实现性确认。团队实际采用的协作方式是“LLM 提出检查结果—成员核对证据—修改相关产物—再次交叉检查”，而不是直接复制 AI 生成内容。

五、系统安全与权限设计

5.1 账号和认证

系统分为用户端账号体系和管理端账号体系，两者独立建表、独立签发令牌、独立限流。管理端采用工号、密码和 TOTP 动态口令的两步登录方式，失败次数达到阈值后锁定账号；密码不保存明文，验证码只保存哈希。

认证流程采用“登录身份确认—令牌签发—接口校验—操作审计”的闭环。用户端令牌只允许访问 /api/v1 下的用户功能，管理端令牌只允许访问 /admin/v1 下的运营功能；网关先校验令牌有效期和签发方，应用服务再根据角色和资源范围进行二次校验。密码采用 Argon2id 或 bcrypt 保存摘要，TOTP 密钥和验证码不进入普通业务日志，令牌失效、账号锁定和异常登录都写入安全日志。这样可以避免只依赖前端隐藏按钮，也避免普通用户通过直接构造请求访问管理接口。

5.2 RBAC 权限模型

管理端采用 RBAC。权限点按照“资源:动作:范围”的形式命名，覆盖评论任务查看、评论通过/拦截、规则管理、举报处理、店铺申请、初审、复核、标签维护、监控、日志、配置和数据导出等操作。

店铺申请采用状态机约束，申请人、初审人和复核人必须互不相同；评论判定只对外显示“审核员”，但在内部审计记录账号、时间、IP 和判定理由，兼顾追责和隐私保护。

RBAC 模型由“用户—角色—权限”三层组成，权限再按照资源、动作和范围细分。例如，评论审核员可以查看和判定评论，但不能修改系统配置；店铺审核员可以处理申请和复核，但不能导出全部用户数据；管理员可以分配角色，但不能绕过双人审批规则。对于店铺申请和评论判定等高风险操作，RBAC 只解决“能不能进入”，状态机和数据级规则继续解决“当前能不能执行”。每个操作都要同时通过角色权限、资源归属、当前状态和互斥审批人校验，体现最小权限和职责分离。

5.2.1 RBAC 权限矩阵

图 7 展示了管理端 RBAC 权限点及其功能说明。权限点按照“资源:动作:范围”的形式命名，覆盖评论审核、规则管理、举报处理、店铺申请与审批、标签维护、监控告警、审计日志、系统配置、账号管理和数据导出等操作。两步认证、网关拦截、数据级权限校验和审计策略分别在本节前后的文字中说明。

5.3 数据安全和健壮性

• 评论采集采用字段白名单，剥离评论者昵称、头像、主页链接和精确位置。
• 所有 SQL 使用参数化查询，评论正文、店铺名称和用户输入进行长度、字符集和 XSS 校验。
• 推荐接口采用限流和缓存；LLM 或外部平台超时时，降级到规则解析和本地数据。
• 两人同时审批或判定同一对象时使用版本号和唯一约束，冲突返回明确的 409 错误。
• 审计日志采用追加写入和哈希链校验，定期进行数据巡检、备份和恢复演练。

安全设计按“入口防护、数据保护、业务约束和故障降级”四个层次展开：入口层通过 HTTPS、网关限流、参数校验和令牌校验阻断未授权请求；数据层通过参数化 SQL、敏感字段摘要、字段白名单和最小化采集降低泄露风险；业务层通过状态机、版本号、唯一约束和审计日志防止重复审批、越权修改和并发覆盖；外部服务层通过超时、重试、熔断和本地规则降级保证推荐主链路可用。安全策略不是附加在功能完成后的检查项，而是和接口、数据表、权限矩阵及测试用例一起设计，后续可以按权限越界、非法输入、重复提交、并发审批和外部服务不可用等场景验收。

六、团队协作、分工与贡献度

6.1 协作方式

团队主要通过 QQ 群进行任务分配、文件传递、问题讨论和进度同步，必要时安排线下会议集中审查。成员完成阶段产物后，在群内发布版本并说明修改点；组长统一整理最终材料、检查链接和提交内容，其他成员负责对文档、图表和答辩材料进行复核。

6.2 成员分工

成员	本次分工
林明阳（组长）	任务安排、组员协调、进度跟进、作业博客撰写、上传并核查华为云文件和链接、审查成员产物
梁强	汇报答辩、审查成员产物、核查代码仓库产物内容并提出修改建议
罗悦翔	编写系统设计说明书
林宇轩	编写系统设计说明书
林铭宏	编写数据库设计说明书
林荣皓	编写数据库设计说明书
林佳鹏	整合成员产物，制作系统设计和数据库设计答辩 PPT，完成系统设计和数据库设计评审表，整理课堂答辩材料

6.3 贡献度估算

本表依据本次系统设计与数据库设计阶段的实际任务范围、产物责任和审查投入进行估算，七名成员贡献度合计为 100%。

学号	姓名	主要工作	贡献度
102400320	林明阳（组长）	任务安排、组员协调、进度跟进、博客、仓库文件与链接核查、产物审查	15%
102400318	梁强	汇报答辩、成员产物审查、代码仓库内容核查和修改建议	15%
052404137	罗悦翔	系统设计说明书编写	14%
102400324	林宇轩	系统设计说明书编写	14%
102400321	林铭宏	数据库设计说明书编写	14%
102400323	林荣皓	数据库设计说明书编写	14%
102400319	林佳鹏	产物整合、答辩 PPT、评审表和课堂答辩材料	14%
	合计		100%

6.4 协作中的交付检查

每个阶段至少检查以下内容：

• 系统设计说明书中的模块、接口、类图和数据库设计是否能够互相对应。
• 数据库字段、标签关系、状态值和权限约束是否能支撑需求验收标准。
• PPT、评审表和博客中的项目名称、成员分工、链接和版本是否一致。
• 华为云仓库中的文件是否可以打开，目录层次和文件名是否清楚。

七、预期开发计划与项目里程碑

以下为七匹狼团队在完成系统设计和数据库设计后制定的建议开发计划，日期为计划日期，不代表已经完成的开发记录；如果课程后续冲刺时间发生变化，将以实际任务看板为准。

7.1 个人角色与开发任务分工

下表按照当前系统设计中的 M1～M6 模块进行开发阶段分工。角色划分用于明确后续开发的主要责任人，接口联调、测试和问题修复仍由全体成员共同参与。

成员	开发阶段角色	负责的详细开发部分	主要协作与验收内容
林明阳	项目负责人、产品与交付协调	拆分迭代任务，维护需求、接口和版本基线；负责环境配置、部署准备、仓库目录和最终交付材料整理	跟进各模块进度，协调跨模块问题，检查核心流程、博客和交付链接是否一致
梁强	测试与质量负责人、后端联调	编写接口测试和核心业务测试；重点验证登录鉴权、推荐结果、评论审核、店铺审批、异常返回和权限边界	组织代码审查和联调，登记缺陷并跟踪修复，核对测试记录和验收结果
罗悦翔	后端开发负责人（用户与推荐）	负责 M1 用户账号和口味画像接口；实现 M2 口语需求解析、条件抽取、候选召回、匹配打分、推荐理由和反馈接口	与林宇轩约定用户端 API，与林铭宏核对用户、画像和推荐相关表结构
林宇轩	前端开发负责人（用户端）	负责用户端首页、需求输入、口味画像、店铺检索、推荐结果、店铺详情和多店对比页面；完成筛选、加载、空状态和异常状态交互	对接推荐和店铺接口，保证用户可以走通“输入需求—查看推荐—查看详情—收藏/对比”的主流程
林铭宏	数据库开发负责人（业务数据）	根据数据库设计说明书完成用户、口味标签、店铺、菜品、收藏和推荐结果相关表的迁移脚本、索引和初始化数据	与后端核对字段、约束和查询性能，保证店铺标签、菜品信息和用户偏好能够支持匹配查询
林荣皓	数据治理与管理端后端开发	负责 M4 评论采集与治理、M5 店铺入库申请和双人审批的数据流程；实现评论状态、标签证据、举报申诉、规则库和审计记录接口	与林铭宏核对评论、审核和申请相关表结构，配合梁强完成状态流转和越权场景测试
林佳鹏	管理端开发与系统集成	负责管理端评论筛查、店铺审批、标签维护、数据监控和基础配置页面；完成管理端接口接入、权限按钮显示和演示数据整理	配合林明阳完成前后端集成、答辩演示和交付材料更新，检查管理端流程能够完整演示

里程碑	计划时间	主要任务	主要负责人	验收标准
M1 设计基线冻结	2026-10-23 至 2026-10-25	确认系统设计、数据库字段、接口命名和评审问题修改点	林明阳、罗悦翔、林宇轩、林铭宏、林荣皓	设计文档、数据库文档和接口编号能够互相对应
M2 工程骨架与数据库初始化	2026-10-26 至 2026-10-30	创建前后端工程、配置环境、初始化 PostgreSQL 和 Redis	罗悦翔、林宇轩、林铭宏、林荣皓	项目可以启动，数据库迁移脚本可以执行，健康检查返回成功
M3 用户、画像和店铺基础模块	2026-10-31 至 2026-11-06	完成注册登录、口味画像、店铺详情、标签字典和基础查询	罗悦翔、林宇轩、林铭宏	可以登录、维护画像、查询店铺和保存标签
M4 推荐主链路	2026-11-07 至 2026-11-13	完成口语解析、条件抽取、候选召回、匹配打分和推荐解释	罗悦翔、林宇轩	输入一句话后返回推荐店铺、匹配度、推荐理由和证据
M5 评论治理和店铺审批	2026-11-14 至 2026-11-20	完成评论筛查、标签证据、人工判定、店铺申请和双人审批	林铭宏、林荣皓、梁强	评论状态可流转，店铺申请不能由同一人完成全部审批
M6 前后端联调和管理端	2026-11-21 至 2026-11-27	完成用户端、管理端、接口联调、权限和审计日志	全体成员，林佳鹏负责材料同步	核心功能可完整演示，越权请求返回正确错误码
M7 测试、安全和性能修复	2026-11-28 至 2026-12-04	执行正常、边界、异常、权限、限流和数据一致性测试	梁强、林宇轩、林佳鹏	P0/P1 缺陷闭环，核心接口和权限测试有记录
M8 部署与最终交付	2026-12-05 至 2026-12-11	部署、备份恢复演练、整理演示脚本、更新博客和仓库	林明阳、林佳鹏、全体成员	网站可访问，代码仓库、博客和答辩材料链接有效

项目关键路径为：设计基线 → 数据库初始化 → 用户与店铺基础模块 → 推荐主链路 → 评论治理 → 前后端联调 → 测试修复 → 部署交付。推荐主链路和评论治理是主要风险点，前者涉及解析、匹配和解释的一致性，后者涉及数据来源、审核状态和证据可信度，因此计划中优先安排这两个部分。

八、总结

本次系统设计把“食话说”从需求和原型层面的想法进一步落到了体系结构、功能模块、接口、类、数据表、安全策略和开发计划上。针对评审提出的三个问题，团队补充了店铺标签与评论证据的匹配关系，明确了菜品推荐的阶段边界，并简化了用例之间的联系。后续开发将以本次设计文档作为基线，通过可验证的里程碑逐步完成推荐主链路、评论治理和系统交付。