团队项目第一次作业团队展示+选题报告+需求分析

校易集 CampusSwap

项目	内容
作业所属课程	2024级计算机78班-软件工程
作业要求	团队项目第一次作业：团队展示+选题报告+需求分析
作业的目标	用一次完整的"真实调研 → 选题论证 → 需求规格 → 可验收标准"闭环，说明我们要做的东西确实有人需要、智能体是长在系统里的而不是外挂一个聊天框、功能范围在七个人的时间里真能交付；同时把分工、迭代节奏和验收方式固定下来，作为后续开发和期末验收的依据。
团队名称	拾集小队
团队成员	3124004429-廖炳程、3124004447-叶浚轩、3224004345-翁佳华、3224004305-柯燕纯、3124004428-赖声雄、3224004307-廖颖欣、3224004304-胡俐伶
项目名称	校易集 CampusSwap
github链接	https://github.com/LB-CC-summer/campusswap/blob/main/README.md
需求文档	【腾讯文档】校易集需求规格说明书https://docs.qq.com/doc/DSEVibVp1YnppdGh4
在线体验	迭代一交付后提供

一、队名

拾集小队

"拾"是把闲置捡回来，"集"是集市、也是聚集。合起来就是我们想做的事：把散落在各个宿舍、各个群里卖不掉的闲置，重新聚成一个能被检索、能被信任的集市。

队里七个人，正好一场羽毛球双打多两个人——调研时我们才发现，七个人里有四个喜欢打羽毛球（翁佳华、柯燕纯、赖声雄、廖颖欣），团建不用另外约。

二、团队项目的具体规划及描述

2.1 一句话定位

校易集是一个面向广东工业大学在校学生的校园二手交易平台，覆盖大学城、东风路、龙洞、番禺、揭阳五个校区，内嵌智能交易助手：买家说一句"我想买宿舍写代码用的显示器，300 以内，只要大学城校区"，就能拿到真实在售的商品清单、推荐理由和缺失信息提示；卖家拍张照片说一句话，就能拿到一份可以直接改的发布草稿。全程在平台内沟通，不公开手机号与微信。

2.1.1 校区覆盖

广工是多校区办学，不同校区的通勤距离和履约方式差别很大，这直接决定了我们对"校区"这一字段的建模方式：

校区	所在区域	与其他校区的关系	平台内的履约方式
大学城校区	广州市番禺区	广州校区之间，跨区通勤约 1 小时	校内 / 跨校区面交
东风路校区	广州市越秀区	同上	校内 / 跨校区面交
龙洞校区	广州市天河区	同上	校内 / 跨校区面交
番禺校区	广州市番禺区（钟村）	与大学城同区但不相邻，仍需跨区	校内 / 跨校区面交
揭阳校区	揭阳市	跨市，面交不可行	需邮寄

两个必须说清的设计决定：

校区是一张表，不是写死的枚举。 沙河校区目前以大学科技园和办公用途为主，日常学生活动较少，暂不列入；但如果学校后续在那边的教学活动变多，后台加一条校区记录即可，前端筛选器与发布表单会自动出现新选项，不需要改代码。这样"适合广工所有校区"才是一句能兑现的话。
广州四校区与揭阳校区走两套履约逻辑。 同城校区之间是"距离问题"，用户愿意多走一段；广州与揭阳之间是"能不能当面拿到手的问题"，所以商品需要额外标记"是否支持邮寄"，筛选器也要能选"不限校区，支持邮寄"。

2.2 我们调研到的真实问题

2.2.1 调研方式与样本

我们在本校做了一轮问卷与访谈：共发放问卷 30 份，回收有效问卷 30 份（覆盖大学城、东风路、龙洞、番禺、揭阳五个校区，其中广州四校区 26 人、揭阳校区 4 人）；另外对 5 名近期有过闲置买卖经历的同学做了一对一访谈，每次 20–30 分钟。

问卷的 30 位同学里，26 人有过闲置交易经历，其中 23 人选过闲鱼/转转类平台，21 人选过校内群或校园墙；19 人在两个渠道都遇到过"想买的东西搜不到"或"聊到一半对方说已经卖了"。

2.2.2 需求聚类：五类真实需求

把 30 份问卷的开放题和 5 份访谈记录按"它到底在抱怨什么"归类，收敛出五类需求（一人可计入多类）：

需求聚类	提及人数	典型原话	现有方案为什么解决不了
发布成本太高	24 / 30	"挂闲鱼要拍图、想标题、填一堆属性，我嫌麻烦就直接扔了"	平台表单是按"商品"设计的，不是按"学生随手一发"设计的；描述含糊，买家就不敢问
不知道搜什么词	21 / 30	"我就想买个便宜的台灯，不知道搜什么词"	关键词搜索要求用户先知道商品名叫什么
状态不可信、白跑一趟	19 / 30	"约好晚上去看，走到半路跟我说卖了"	群聊和全平台都靠卖家口头，没有强制流转的状态；已售商品不下架
跨校区不便	18 / 30	"以为同城就一起送，结果人在东风路，我在大学城" / "揭阳这边基本都自己买新的，没人带二手过来"	全平台只到"同城"，广工四个广州校区横跨越秀、番禺、天河；揭阳跨市，连"同城"都不成立
不敢留联系方式	17 / 30	"群里发个手机号，之后天天有人加我微信"	手机号、微信号直接暴露给全群，无法撤回；没有拉黑和举报的抓手

调研结论：校园二手的核心矛盾不是"没有供给"，而是供给的表达成本太高、需求没有被翻译成可执行的查询、交易状态与联系方式都缺乏约束。这三件事恰好分别对应"语言模型擅长的事"和"系统设计擅长的事"——这就是我们把智能体放进系统的原因，而不是为了"用 AI 而用 AI"。

2.2.3 从需求到功能：我们做了哪些取舍

调研里用户提的需求很多，但不是每条都能、或都该在这一轮做。我们把 30 份问卷 + 5 份访谈里出现的全部诉求先列成 21 条，再用三道筛子过一遍：安不安全、七个人四轮做不做得完、是否真的推动成交。最后留下来的，就是下面这张映射表：

用户说的话	我们判断的真实需求	落地功能
"不知道搜什么词"	用户能描述用途和预算，但不会描述商品名	智能找物：自然语言条件抽取
"搜出来一堆不相关的"	硬条件必须被严格执行，不能"大概符合"	后端 SQL 过滤，模型无权放宽
"看了半天发现接口不对"	决策缺的是关键参数，不是更多商品	推荐卡片标注"符合什么 / 缺什么"
"发个闲置要填十几个框"	发布成本是最大的流失点，先降低它	智能发布：图片 + 一句话 → 草稿
"快到了人家说卖了"	状态必须可信，否则跑一趟就是白跑	商品状态机 + 已预订机制
"不给手机号谈不成，给了又被骚扰"	联系必须发生，但必须可控、可撤回	站内聊天 + 联系方式交换申请 + 打码
"以为是同城，结果跨区"	校区是能不能成交的前提，不是偏好	校区硬条件 + 跨市"支持邮寄"标记
"找了个同校的，结果对方是外校混进来的"	需要一点身份边界，但不需要敏感信息	学号邮箱做轻量校内认证，只显示"已认证"徽章

2.2.4 被筛掉的需求：哪些我们明确不做

这一节比上一节更重要。用户提的需求里有一批听起来很合理、但我们判断做不了、做了不安全、或者做了反而不成立，我们选择明确写出来并说明理由：

被筛掉的需求	提及人数	筛掉理由	归类
平台担保支付、资金托管	12	涉及支付资质与资金责任，一旦出问题学生团队无法承担；对账、退款、分账在课程周期内也做不完	不安全 + 太难
实名认证（上传身份证 / 学生证）	8	要收集并保管敏感证件，泄露后果远超项目收益；改用学号邮箱做轻量校内认证已经够用	不安全
精确到宿舍楼的定位、校园地图	7	会暴露具体住址，风险高于收益；只到校区级 + 聊天里文字约定面交地点更稳妥	不安全
AI 自动议价、代聊砍价	6	让模型替用户承诺价格，一旦说错就是真实损失，责任无法界定	不安全
送货上门、校内跑腿	7	涉及人身安全与责任划分，且与"当面交接"的定位冲突	不安全 + 不合实际
信用评分 / 互评体系	9	冷启动没有交易数据，评不出东西；学生圈小，容易被熟人刷分或恶意差评	不合实际
AI 智能定价	6	二手成色高度主观，估价误差会直接引发纠纷，且我们没有成交数据可训练	不合实际
拍卖 / 竞价	2	学生二手议价空间小，拍卖反而拉长成交周期	不合实际
校园社区 / 闲置论坛	5	与本项目"把东西卖掉"的核心链路无关，会把范围摊薄	不合实际
以图搜图（拍照找同款）	6	需要图像向量检索和足够大的商品库，我们的商品量级撑不起来，投入产出比低	太难
视频验货 / 直播看货	3	带宽、存储、实时性成本远超课程项目承受范围	太难
站内一键生成交易合同	2	合同效力依赖真实身份与法律背书，我们两者都没有	不合实际

需要说明的是："被筛掉"不等于"不重要"，大部分已经写进需求文档的"本期不做"清单里，属于后续可以再评估的方向。我们宁愿在答辩时说清"这 12 项我们想过、理由是这些"，也不愿意写一张看起来很全、实际上做不完的功能表——毕竟最终验收是拿着需求文档逐条对照的。

经过这一轮筛选，最初的 21 条诉求最终收敛为 7 个 MVP 模块（见 2.4），每一模块都能在 2.2.3 的映射表里找到出处。

2.3 智能体在系统里的位置

智能体不是外挂的聊天框，它是系统的一个入口层，与页面按钮共用同一套业务服务：

              用户自然语言 / 图片
                     │
                     ▼
   智能体：意图理解 → 条件抽取 → 选择工具 → 组织回答
                     │  调用固定 JSON 结构的工具
                     ▼
        业务服务（检索 / 详情 / 对比 / 草稿创建）  ←── 同一套服务 ──→  页面筛选按钮
                     │
                     ▼
                  MySQL 真实数据

三条硬规矩：

商品名称、价格、状态、卖家信息一律由数据库返回，模型不得生成；模型只负责"理解需求"和"解释结果"。
硬条件（预算上限、校区、类别）由后端 SQL 过滤执行，模型不能自行放宽；要放宽必须先问用户。
信息缺失必须明示（"接口类型未填写"），不允许模型用常识补齐。

2.4 功能范围：做什么，也明确不做什么

模块	内容
账号与个人中心	注册登录、校内身份认证（学号邮箱）、校区设置（五校区单选）、我的发布 / 收藏 / 交易
商品集市	发布（含图片上传）、分类浏览、条件筛选（校区为硬条件，支持"不限校区"与"支持邮寄"）、详情、状态管理（在售 / 已预订 / 已售出 / 已下架）
智能找物	自然语言条件抽取、多轮补充与修改、真实商品检索、推荐解释、无结果处理、商品卡片直连详情 / 收藏 / 咨询
智能发布	图片 + 一句话 → 追问缺失信息 → 生成可编辑草稿 → 用户确认后发布
站内沟通与隐私	站内聊天（不公开手机号 / 微信）、联系方式需双方同意后才可见、消息自动打码、拉黑与举报、面交地点建议
沟通与交易	交易申请、卖家确认（并发只允许一单）、双方确认完成
基础后台	用户管理、校区管理（增删改，用于后续新增校区）、商品下架、举报处理

完成主线后增加

商品对比（2–3 件，维度随类目变化，缺失项明示）
求购发布 + 新商品规则匹配提醒（可按校区 + 是否支持邮寄匹配）
浏览统计

本期不做：在线支付与资金托管、平台代收快递费、跨校运营到其他高校、实名身份证认证、精确定位与地图导航、信用评分与互评、AI 自动议价与智能定价、拍卖竞价、校内跑腿、以图搜图、视频验货、站内交易合同、个性化推荐算法（首版用规则排序）、向量检索（先用结构化筛选 + 关键词）。

2.5 技术方案

层次	选型	理由
交付形态	响应式 Web（主，答辩用）+ 微信小程序（同一套 API）	小程序贴近学生使用习惯；Web 便于答辩现场演示与后续维护
前端	Vue 3 + TypeScript + Vite + Element Plus	电脑答辩、手机体验都能用；团队上手快
后端	Python FastAPI	与智能体 SDK 同语言，工具调用与流式输出好写
数据库	MySQL 8	事务能力用于交易并发控制；分类属性用 JSON 字段，避免为每个类目建表
智能体平台	扣子（Coze）编排 + 自建 FastAPI 业务工具（HTTP 回调）	可视化调试工具调用链，答辩能直接展示编排图；业务数据始终留在自己的库里
实时消息	WebSocket	聊天体验；会话鉴权在服务端完成
图片存储	开发期本地目录，部署期对象存储	先跑通再优化；图片随机文件名，不可枚举
部署	云服务器 + Nginx + HTTPS + Docker Compose	保证"能上线、能被点开验收"

2.6 迭代计划

分四轮推进，每轮结束都要有能演示的增量，并尽早部署上线：

迭代	目标	主要交付
第一轮	基础可运行	账号、校区、商品发布与浏览、详情页，首次外网部署
第二轮	智能体主线	一句话找货、多轮改条件、无结果引导（杀手级功能）
第三轮	站内沟通与交易	站内聊天、隐私打码与联系方式交换、交易状态闭环
第四轮	完善与验收	智能发布、商品对比、验收用例与演示录屏

具体日期按教研组公布的验收时间倒排，扩展项可随时裁剪，MVP 范围不动。

三、队员风采

#	学号	姓名	性格	擅长技术	兴趣爱好	期望角色
1	3224004345	翁佳华	热情开朗外向	产品需求文档（PRD）撰写、HTML / CSS / JavaScript 前端基础、Figma 原型设计、Python	唱歌、羽毛球	PM / 产品经理
2	3224004304	胡俐伶	踏实稳重、认真严谨、积极主动	需求梳理与文档撰写、产品原型绘制（流程图 / 页面 / 思维导图）、版面设计	书法、篆刻	UI / UX 设计
3	3224004307	廖颖欣	乐于沟通	熟悉 HTML / CSS / JavaScript，能独立完成页面还原与响应式布局	羽毛球	前端负责人
4	3224004305	柯燕纯	性格偏内向，做事细心踏实、有耐心	熟悉关系型数据库设计与 SQL、C 语言，具备 Java 基础	运动，平时喜欢打羽毛球	后端负责人
5	3124004428	赖声雄	开朗乐观	Java 后端开发基础，了解面向对象设计与常用数据结构	羽毛球	后端
6	3124004447	叶浚轩	好学	Python 编程；学习能力强，能快速上手新框架与 API	游戏	智能体 / AI 工程
7	3124004429	廖炳程	沉稳理性	Python 脚本与自动化、Linux 命令行与服务器部署基础	摄影	运维 / 部署 + 测试

每人一句话

翁佳华（PM）：性格外向，喜欢把复杂的事拆成一条条能做的事。这次我来盯需求和进度，保证大家做出来的和文档里写的是同一件事。
胡俐伶（UI / 需求）：练书法篆刻很多年，习惯一个笔画反复改；做产品原型也是这个性子——页面上的每一处，我都想让它有理由。
廖颖欣（前端）：乐于沟通，前端是我最想深入的方向。希望这个平台每个页面，同学点进去都知道下一步该点哪。
柯燕纯（后端）：性格偏内向，但做事细心踏实。数据库和接口交给我，我会把边界条件一条条列清楚。
赖声雄（后端）：开朗乐观，喜欢打羽毛球。交易状态流转和消息模块我来分担，出问题大家一起扛。
叶浚轩（智能体）：好学，喜欢游戏，也很好奇大模型到底怎么"听懂人话"。智能体这块我来啃。
廖炳程（运维 + 测试）：沉稳理性，喜欢摄影。服务器和部署我盯着，尽量不让大家最后一天还在配环境。

四、团队首次合照

五、团队愿景

我们希望校易集成为广工所有校区里"默认的那一个"二手入口：不管你在大学城、东风路、龙洞、番禺还是揭阳，都不必再加十个群、翻几百条消息才能卖掉一台旧显示器，也不必先想好关键词才能找到想要的东西。它应该像一个熟悉校园的同学——你说清楚要什么、有多少钱、在哪个校区，它就把真实存在的选择摆到你面前，并诚实告诉你哪些信息还不知道、哪些东西跨校区拿不到。它也应该让每一次联系都停在一个安全的地方：不用把手机号撒进群里，也能把东西交接完。

六、选题报告

6.1 选题来源

选题来自广工的真实观察与调研：每学期末都有一批搬宿舍、毕业的同学要处理闲置，每学期初都有一批新生要买便宜的日用品和教材，但两边始终靠 QQ 群、微信群和校园墙撮合。我们在调研中把 30 份问卷与 5 份访谈收敛出五类需求、并筛掉了 12 条不合适的诉求（见 2.2），最终把方案聚焦到"降低表达成本 + 把需求翻译成查询 + 把联系留在站内"这三件事上。

一个必须说明的本地条件：广工是多校区办学，广州的大学城、东风路、龙洞、番禺四个校区分别位于番禺、越秀、天河，彼此通勤动辄一小时以上；揭阳校区更是在粤东，跨市。这意味着"校区"不是可有可无的筛选项，而是能不能成交的前提——所以我们把它做成硬条件而不是偏好条件，并且为跨市场景单独准备了"支持邮寄"这条履约路径。

6.2 同类产品对比

维度	闲鱼 / 转转等全平台 C2C	校内 QQ / 微信群、校园墙	校易集
校区 / 校内范围过滤	无（只到同城，同城也常跨区）	群成员天然同校，但无法按校区筛选	有，大学城 / 东风路 / 龙洞 / 番禺 / 揭阳五校区，校区可后台扩展
跨市场景	支持邮寄，但与"校内自取"混在一起	无法区分	商品标记"是否支持邮寄"，筛选器可单独选
商品可检索性	有搜索，但要求先知道关键词	无检索，信息流刷屏即沉底	结构化筛选 + 自然语言描述需求
商品状态是否可信	大量已售不更新	全靠卖家口头	在售 / 已预订 / 已售出状态机强制流转
交易过程是否有记录	有平台担保	无	有交易单与双方确认（线下交接，不做支付）
发布成本	表单长、类目属性多	"出个台灯 25" 极简但信息不全	图片 + 一句话 → 追问 → 草稿预填
信息完整性	依赖卖家自觉	极低	缺失字段强制明示，AI 只建议不编造
联系方式暴露	需私下交换手机号或微信，无脱敏	直接暴露给全群，无法撤回	全程站内沟通，手机号与微信默认打码，双方同意后才可见
骚扰防护	有拉黑举报，但骚扰多来自站外	无拉黑、无举报，只能退群	站内拉黑即时生效、举报进后台、新会话限频

6.3 创新点

需求驱动检索：用户从"用途 + 预算 + 约束"出发描述，系统把它转成可执行的查询条件，而不是要求用户先猜对商品名。
基于平台真实数据的推荐与对比：所有候选都关联真实在售记录，推荐解释里明确写出"符合什么、缺什么"，把 AI 的不确定性变成看得见的取舍。
隐私优先的站内闭环：从找货、沟通到成交全在平台内完成，联系方式必须双方授权才可见，让"卖个东西"不必以暴露个人信息为代价。

6.4 杀手级功能：需求直达

一句话 → 真实在售清单 → 站内直接咨询。

演示脚本：

输入：我想买台宿舍写代码用的显示器，300 以内，只要大学城校区

→ 抽出条件标签：显示器 / ≤¥300 / 大学城校区 / 用途：编程
→ 检索到 3 件真实商品，卡片标注"符合预算""大学城校区""接口类型未填写"
→ 提示：你还没说电脑接口，买之前要确认能否直连
→ 接着说"预算降到 200" → 只更新预算，其余条件保留，结果实时变化
→ 点卡片 → 进详情 → 点"咨询卖家" → 进入站内会话（不显示对方手机号）→ 发送消息

它同时展示了感知（理解模糊需求）、决策（追问还是直接给结果）、工具调用（查真实数据库）、反馈（结果可解释、可继续操作）四件事，缺任何一件都做不出这个效果——这是"套一个聊天框"做不到的。

跨校区的处理也是演示的一部分：

输入：有没有便宜点的教材，我在揭阳校区

→ 抽出条件：教材 / 揭阳校区
→ 提示：揭阳校区距广州校区较远，当面交接不便。
        已为你筛选"支持邮寄"的商品，共 2 件
→ 若关闭"支持邮寄"筛选：本校区暂无在售教材，可保存求购或扩大至全校

第二亮点：智能发布——上传照片 + "毕业出台灯 25 块，东风路校区自取" → 追问"能正常用吗 / 带电源线吗 / 有损坏吗" → 生成预填表单，用户改完点确认才入库。

七、需求分析

需求规格说明书按《软件需求规范》组织，单独维护在在线文档中：

校易集需求规格说明书 V1.0

7.1 文档结构

引言（目的、范围、术语、参考资料）
总体描述（产品前景、用户角色、运行环境、约束与假设）
迭代记录表
项目标志（Logo 与视觉说明）
业务思维导图
类图与数据模型
功能需求：按模块逐条编号，每条含"前置条件 / 主流程 / 异常流程 / 涉及接口"
- 前端部分：11 个页面的布局、交互、页面状态（加载 / 空 / 失败 / 降级）
- 后端部分：模块划分、接口清单、权限矩阵
- 智能体接口约定：6 个工具的 JSON 参数与返回结构、上下文维护规则、不得编造数据的约束
校区与履约设计（五校区配置、同步 / 跨市两种履约路径）
隐私与安全设计（数据最小化、脱敏规则、权限边界）
非功能需求（性能、安全、可用性、兼容性）
验收标准（AC-01 ~ AC-16，可逐条勾选）
附录：AI 固定测试集与通过率记录表

7.2 迭代记录表

版本	日期	修订人	修订内容
V0.1	2026-11-08	翁佳华	建立文档骨架，确定范围与角色
V0.5	2026-11-08	胡俐伶	补充思维导图、页面清单与交互说明
V0.8	2026-11-08	柯燕纯、叶浚轩	补充类图、接口清单、智能体工具约定与验收标准
V1.0	2026-11-08	翁佳华、赖声雄	补充五校区建模与跨市履约、站内沟通与隐私设计、新增 AC-15 / AC-16

7.3 业务思维导图

校易集 CampusSwap
├── 账号与个人中心
│   ├── 注册 / 登录
│   ├── 校内身份认证（学号邮箱，仅显示"已认证"徽章）
│   ├── 校区（大学城 / 东风路 / 龙洞 / 番禺 / 揭阳，可后台扩展）
│   └── 我的发布 / 我的收藏 / 我的交易
├── 商品集市
│   ├── 商品发布（图片上传）
│   ├── 分类浏览、条件筛选（校区硬条件 + 是否支持邮寄）
│   ├── 商品详情
│   └── 商品状态管理（在售 / 已预订 / 已售出 / 已下架）
├── 智能交易助手
│   ├── 自然语言找物
│   ├── 需求追问与多轮修改
│   ├── 真实商品检索
│   ├── 推荐解释（符合什么 / 缺什么 / 跨校区提示）
│   ├── 多商品对比
│   └── 智能发布草稿
├── 站内沟通与隐私
│   ├── 商品咨询、站内聊天
│   ├── 联系方式交换申请（双方同意）
│   ├── 敏感信息自动打码
│   ├── 面交地点建议（按校区）
│   └── 拉黑 / 举报 / 发送频率限制
├── 沟通与交易
│   ├── 交易申请、卖家确认
│   ├── 面交 / 邮寄两种履约标记
│   └── 双方确认完成
├── 求购与提醒
│   ├── 发布求购
│   └── 新商品匹配提醒（按校区 + 邮寄筛选）
└── 后台管理
    ├── 用户管理
    ├── 校区管理（新增 / 停用校区）
    ├── 商品管理（下架）
    └── 举报处理（按次授权查看、操作留痕）

7.4 类图与数据模型

核心实体 14 个：Campus、User、UserProfile、Product、ProductImage、Category、Favorite、Conversation、Message、ContactExchange、Block、Trade、AgentSession、Report。

主要关系：

Campus        1 ──< Product          校区归属
Campus        1 ──< UserProfile      用户所在校区
User          1 ──< Product          发布
Category      1 ──< Product          分类
User          * ──* Product          收藏（中间表 Favorite，用户+商品唯一）
Product       1 ──< Conversation     关联会话（商品ID + 买家ID + 卖家ID）
Conversation  1 ──< Message          包含消息
Conversation  1 ──< ContactExchange  联系方式交换申请（状态：待同意 / 已同意 / 已关闭）
User          1 ──< Block            拉黑关系（拉黑人与被拉黑人唯一）
Product       1 ──< Trade            交易申请
Trade         * ──  User             买家 / 卖家
User          1 ──< AgentSession     使用智能助手
User          1 ──< Report           举报

关键字段：

Campus：ID、名称、所在城市、是否跨市、排序、是否启用（后台可增删）
Product：ID、卖家ID、分类ID、标题、描述、价格、校区ID、是否支持邮寄、状态、发布时间、attributes JSON
Conversation：ID、商品ID、买家ID、卖家ID、最后消息时间、联系方式交换状态、买家是否已拉黑卖家
ContactExchange：ID、会话ID、申请人ID、被申请人ID、状态、同意时间
UserProfile：用户ID、昵称、头像、校区ID、认证状态（不存真实姓名、不存身份证）

校区用独立的表而不是枚举，是为了让"沙河校区后续启用"这类变化靠数据配置完成，不用改代码、不用发版。

分类属性用 JSON 字段存，避免给教材、显示器、自行车各建一套表：

{
  "book_name": "高等数学",
  "edition": "第七版",
  "isbn": "卖家填写",
  "has_notes": true,
  "condition_description": "有少量笔记"
}

数据库层约束：收藏表"用户ID + 商品ID"唯一；拉黑表"拉黑人ID + 被拉黑人ID"唯一；商品价格非负；聊天记录仅会话参与者可读；商品仅发布者可改；交易状态只能按规定流程变化；手机号、微信号、QQ 号在库中单独加密存储，不进入商品表与消息表明文。

7.5 功能描述（前端）

页面	主要内容与交互
登录注册页	账号、密码、昵称、校区选择（大学城 / 东风路 / 龙洞 / 番禺 / 揭阳）、学号邮箱校内认证
首页 / 集市页	搜索栏、分类入口、校区筛选（默认当前校区，可切"不限校区"）、"支持邮寄"开关、商品列表、智能找物入口
智能找物页	对话区、需求条件标签、推荐卡片、对比入口（对话 + 结果组合布局）
商品详情页	图片、价格、属性、校区、履约方式（面交 / 可邮寄）、卖家（昵称 + 已认证徽章，无手机号）、收藏、咨询、申请交易
发布商品页	普通表单、智能发布入口、图片上传、校区选择、是否支持邮寄、草稿预览
商品对比页	2–3 件商品对比表（含校区与履约方式）、智能分析、联系卖家
消息中心	会话列表、聊天记录、关联商品卡片、联系方式交换入口、举报与拉黑
交易中心	买入 / 卖出、交易状态、完成确认
个人中心	个人信息、隐私设置（谁可以联系我 / 是否允许交换联系方式）、我的发布、收藏、求购
管理后台	商品、用户、校区管理、举报管理（查看聊天片段需按次授权）
安全提示页 / 弹窗	面交安全提示（按校区给建议）、防诈骗提醒、举报入口

智能找物页在电脑端左右分栏（左对话、右结果），手机端改为上下排列。必须补齐的页面状态：加载中、空结果、接口失败、智能体暂不可用；模型调用失败时，普通搜索与手动发布表单仍然可用。

7.6 功能描述（后端）

模块划分：

auth       注册、登录、权限、校内身份认证
users      用户资料、校区、隐私设置
campus     校区配置（增删改查、启用状态）
products   商品、分类、图片、收藏
chat       会话、消息（WebSocket）
privacy    联系方式脱敏、交换申请、拉黑、举报
trades     交易申请、状态变更（事务）
agent      模型调用、工具调用、上下文
needs      求购与匹配
admin      管理、举报处理、校区维护

主要接口：

接口	作用
`GET /api/campuses`	获取已启用校区列表（前端筛选器与发布表单共用）
`GET /api/products`	条件查询商品（含校区硬过滤、是否邮寄过滤）
`GET /api/products/{id}`	商品详情
`POST /api/products`	确认发布商品
`PATCH /api/products/{id}`	修改自己的商品
`POST /api/agent/sessions`	创建智能会话
`POST /api/agent/sessions/{id}/messages`	发送需求并获取智能回复
`POST /api/listing-drafts`	创建发布草稿
`POST /api/conversations`	发起商品咨询（需校验商品在售、非本人商品、未被拉黑）
`GET /api/conversations/{id}/messages`	拉取会话消息（仅参与者）
`POST /api/conversations/{id}/contact-exchanges`	申请交换联系方式
`POST /api/contact-exchanges/{id}/accept`	对方同意交换
`DELETE /api/contact-exchanges/{id}`	关闭已交换的联系方式
`POST /api/users/{id}/block`	拉黑用户
`POST /api/trades`	提交交易申请
`POST /api/trades/{id}/accept`	卖家接受
`POST /api/trades/{id}/complete`	当前用户确认完成
`POST /api/reports`	举报商品或用户
`POST /api/admin/campuses`	新增校区（管理员）

交易接受、完成等操作走专用接口，由后端校验身份与状态，不允许客户端任意修改状态字段。卖家接受交易时，必须在同一数据库事务中检查"商品仍在售"并更新状态，防止两个买家同时抢到同一件商品。

7.7 智能体工具约定

工具	作用	关键参数
`search_products`	按结构化条件查询商品	分类、预算上限、校区（接受校区名或"不限"）、是否支持邮寄、关键词
`get_product_detail`	获取商品完整信息	商品 ID
`compare_products`	读取多件商品并整理可比较字段	商品 ID 列表
`get_category_schema`	查询某类商品需要哪些信息	分类 ID
`create_listing_draft`	创建商品发布草稿	标题、价格、属性、描述、校区
`save_purchase_need_draft`	将购买条件保存为求购草稿	预算、分类、校区、描述

执行流程：

用户输入需求 → 识别意图与条件 → {是否缺少关键条件}
  ├─ 是 → 向用户追问 → 回到识别
  └─ 否 → 调用商品检索工具 → 后端返回真实商品 → {是否有匹配结果}
        ├─ 有 → 读取详情并解释推荐 → 用户查看 / 收藏 / 对比 / 咨询
        └─ 无 → 提示调整条件或保存求购（不自行放宽硬条件）

工具调用参数使用固定 JSON 结构校验；工具结果返回商品 ID 与字段，前端据此渲染卡片；商品描述作为待分析的数据处理，不能改变智能体的系统规则（防提示词注入）。收藏、发消息这类普通操作由页面按钮直接调用业务接口，不必都绕一遍模型。

校区参数由后端解析，不由模型自由发挥：模型只输出用户提到的校区名称字符串，后端把它映射到 Campus 表的 ID；匹配不到就在追问里让用户从下拉框选择，避免模型拼出一个不存在的校区。

智能体拿不到也不需要拿到手机号：工具返回值里不包含任何联系方式字段，模型无法"顺口"说出卖家的电话。

7.8 检索与排序

首版不引入向量数据库，采用结构化筛选 + 关键词检索 + 规则排序：

智能体把自然语言解析成结构化条件（区分硬条件与偏好条件，校区、预算、分类为硬条件）；
后端按硬条件过滤：仅在售、价格上限、校区、分类，跨市场景另加"支持邮寄"；
对候选做可解释的规则排序：类别精确匹配、关键词命中、偏好满足、信息完整度、发布时间。

不展示"匹配度 97%"这类没有依据的数字，改用"符合预算""大学城校区""配件信息缺失"等标签。

7.9 隐私与站内联系设计

这一节解决两个问题：买卖双方在平台内怎么联系，以及怎么保证过程中不泄露个人信息。

7.9.1 站内联系流程（不加好友、不交换手机号也能成交）

① 商品详情页点「咨询卖家」
      └→ 后端校验：商品在售？不是自己的商品？未被对方拉黑？
          └→ 通过则创建会话（商品ID + 买家ID + 卖家ID），预填一句开场白

② 进入聊天页（站内）
      ├→ 文本、图片（≤9 张）、商品卡片转发
      ├→ 顶部常驻商品卡片：标题、价格、校区、履约方式、状态
      └→ 全部消息走 WebSocket，服务端鉴权，只有会话双方可读

③ 卖家收到通知
      ├→ 小程序：订阅消息通知；Web：消息中心红点
      └→ 首次会话限制：买家首轮最多发 3 条，卖家回复后解锁（防骚扰刷屏）

④ 需要打电话 / 加微信时
      └→ 任一方点「申请交换联系方式」→ 对方同意 → 会话内才显示完整号码
          └→ 任一方随时可「关闭交换」，关闭后立即恢复打码

⑤ 谈成后推进交易
      └→ 买家点「申请购买」→ 卖家接受（商品转已预订）→ 双方收到系统消息
          └→ 同校区：按聊天约定的地点面交
          └→ 跨市：按约定邮寄，双方各自确认收发
          └→ 各自点「确认完成」

7.9.2 敏感信息打码规则

用户在聊天中发送的手机号、微信号、QQ 号，服务端用正则识别后自动替换为 [联系方式已隐藏，可申请交换]，并附「申请交换联系方式」按钮；原文不落库、不推送。
商品标题与描述同样过滤：出现手机号时在发布前提示"请勿在描述中填写联系方式"，提交后强制打码。
打码在服务端完成，前端只拿到已处理文本，防止绕过前端直接调接口。
双方同意后，脱敏字段通过独立接口按会话单独返回，不进入消息列表的批量返回。

7.9.3 数据最小化与展示边界

数据	是否收集	对外展示
昵称、头像	是	展示
校区	是	展示（只到校区级）
学号邮箱	是（仅用于校内认证）	不展示，只显示"已认证 · 广工"徽章
真实姓名	不收集	—
手机号	选填（登录 / 找回）	默认不展示，双方同意后可见
微信号 / QQ	不收集，聊天中出现即打码	双方同意后可见
宿舍楼栋 / 精确地址	不收集，只到校区	面交地点由聊天约定
精确经纬度	不收集	—

7.9.4 权限与后台边界

聊天记录仅会话参与者可读；接口按 conversation_id + 当前用户身份 双重校验。
管理员默认看不到任何聊天内容；仅在处理举报时，按单次授权查看被举报的会话片段，查看行为写审计日志（谁、何时、看了哪条举报）。
日志脱敏：手机号、邮箱、会话内容在应用日志中一律打码或只记长度。
用户可删除会话、可注销账号；注销即删除个人信息，交易凭证去标识化保留（保留订单号、金额、时间，去掉身份关联）。

7.9.5 面交与邮寄安全

聊天内提供「面交地点建议」快捷按钮，

按校区给不同建议

：
- 大学城 / 东风路 / 龙洞 / 番禺：图书馆门口、宿舍楼下、校区门卫、食堂门口
- 揭阳校区：建议用校门快递驿站，寄件当面称重
只发文字，不发定位，不收集经纬度。
首次进入聊天页展示一次安全提示：建议白天、在校内公共区域面交、不提前转账。
因为不做在线支付，所有资金往来在平台外发生，平台明确提示"先验货再付款"，并把这条写进商品详情页底部。跨市邮寄的商品额外提示"建议平台外使用可查询的快递单号，收货后当场验货"。

7.10 交易流程与状态

课程项目采用校内当面交接、平台记录交易进度的方式，不做支付。

商品状态：  草稿 → 在售 → 已预订 → 已售出
                     ↓        ↓
                    下架   取消后恢复在售

交易状态：  待确认 → 已确认 → 已完成
                       ├── 已取消
                       └── 已拒绝

关键规则：不能申请购买自己的商品；一件商品同一时间只能有一笔已确认交易；买家可取消待确认申请；已确认交易取消后商品恢复在售；单方确认完成时显示"等待对方确认"；交易完成后其他未处理申请关闭。

7.11 验收标准

编号	功能	验收场景与预期
AC-01	商品发布	必填项（含校区）完整且图片上传成功后，可发布并在集市中查询到；缺少必填项时提示具体原因
AC-02	条件搜索	设置分类、价格上限和校区后，返回商品均满足全部筛选条件；校区选"大学城"时不出现东风路、龙洞、番禺、揭阳的商品
AC-03	自然语言找物	输入"大学城校区 300 元以内的显示器"，能提取条件并返回对应在售商品
AC-04	连续对话	接着输入"预算降到 200"，保留其他已确认条件，只更新预算
AC-05	无结果处理	没有符合条件商品时明确提示，不编造商品、不自行放宽硬条件（不会自动跨校区推荐）
AC-06	推荐依据	推荐卡片可打开真实商品详情，价格、校区、履约方式与状态与商品数据一致
AC-07	智能发布	上传图片并输入描述后生成草稿，卖家修改并确认后才正式发布
AC-08	商品对比	能对 2–3 件商品展示已知属性（含校区与履约方式），缺失项明确标记
AC-09	聊天	买卖双方能收发消息，刷新后历史记录仍存在，其他用户无法读取
AC-10	交易并发	两名买家同时申请时，卖家只能成功确认其中一笔有效交易
AC-11	交易完成	单方确认显示等待，双方确认后商品变为已售出
AC-12	权限管理	普通用户无法修改他人商品，也无法访问管理员接口
AC-13	服务降级	模型调用失败时显示重试提示，普通搜索与手动发布仍可操作
AC-14	上线访问	外部浏览器通过部署地址可完成登录、找物、咨询、交易主流程
AC-15	隐私脱敏	商品详情、聊天页、推荐卡片中均不出现对方手机号或微信号；在聊天中发送手机号后，接收方看到的是打码文本与"申请交换"按钮；双方都同意后才显示完整号码，任一方关闭交换后立即恢复打码
AC-16	骚扰防护	被拉黑后对方无法继续发送消息并提示"消息发送失败"；举报提交后可在后台看到待处理记录；同一买家首轮超过 3 条且卖家未回复时被限频
AC-17	校区可扩展	管理员后台新增一个校区并启用后，发布表单与筛选器无需改动代码即出现该校区选项，新发布的商品可正确归属
AC-18	跨市履约	揭阳校区用户搜索时，若商品不勾选"支持邮寄"，则不参与匹配；勾选后可返回跨市商品并标注"需邮寄"

AI 功能具有不确定性，另备一套固定测试集（明确条件查询、模糊需求、修改预算、多轮补充、无结果、信息不完整、商品已售出、描述含干扰文字共 8 类），记录通过情况与失败原因，先测再写指标。

八、团队分工与协作机制

8.1 分工

角色	成员	主责	本轮交付物
PM / 产品经理	翁佳华	需求文档单点维护、排期与风险跟踪、博客、答辩主讲（兼 Figma 原型与前端协助）	需求说明书 V1.0、答辩 PPT、博客
UI / UX 设计	胡俐伶	页面原型、视觉规范、Logo 与图标、隐私相关交互（打码展示、交换申请、安全提示）	11 个页面原型、视觉规范
前端负责人	廖颖欣	前端工程与规范、集市 / 首页 / 详情 / 发布 / 个人中心、校区筛选与邮寄开关	页面骨架、集市全流程
后端负责人	柯燕纯	数据库设计、校区表与配置接口、账号权限、商品 / 分类 / 图片 / 收藏、检索排序、OpenAPI 契约	表结构、接口契约 v1
后端	赖声雄	聊天 WebSocket、隐私模块（打码、交换申请、拉黑、举报）、交易状态机与并发事务、后台	交易事务方案、隐私模块、管理后台
智能体 / AI 工程	叶浚轩	提示词与工具定义、校区名到校区ID 的映射校验、结构化输出校验、草稿生成、AI 测试集	6 个工具 POC、条件抽取通过率记录
运维 / 部署 + 测试	廖炳程	服务器与 CI、校区种子数据、验收用例、回归、录屏与演示兜底	可访问地址、用例表、演示录屏

每个核心模块至少两人能跑起来（前端互审、后端互审、AI 模块 PM 也能照着文档演示），不允许出现"只有一个人会部署"的情况。隐私模块额外安排 PM 做一次"陌生人视角"走查：用两个测试账号走完咨询 → 交换 → 成交，确认全程看不到对方手机号。校区扩展额外安排一次验证：由运维在后台加一个测试校区，确认前端无需发版即可出现。

8.2 协作流程

环节	做法
契约先行	每轮迭代开头先定接口契约（Apifox / 语雀），前端用 Mock 数据并行开发，不被后端阻塞
分支与评审	`main` 永远可演示，日常集成在 `develop`，功能走 `feat/` 分支；PR 需 1 人 Review 才能合
每日同步	每晚线上站会 10 分钟：昨天做完什么 / 今天做什么 / 什么卡住了
每周评审	每周在 `develop` 上跑一遍真实流程，当场记问题，不演示 PPT
完成定义	接口有文档、有基本测试、已部署到测试环境，三条齐了才算完成
文档与安全	需求文档单一主版本；`README.md` 放部署手册；`.env` 不入库，密钥只在后端
演示兜底	提前完成一次完整录屏，准备离线种子数据与"模型不可用"降级开关

8.3 风险与应对

风险	应对
七人协作接口对不上	契约先行 + Mock + 每日集成
大模型输出不稳定 / 编造商品	工具返回结构化数据、前端只渲染后端字段、固定测试集回归
隐私设计被绕过	打码与鉴权全放服务端；工具返回值不含联系方式；上线前"陌生人视角"走查
校区写死在代码里	校区独立成表 + 后台可维护
跨市场景被忽略	商品增加"支持邮寄"字段，筛选与推荐都当作一等条件
部署踩坑拖到最后	第一轮就上线，之后持续部署
期末多门课冲突	扩展项可裁剪，MVP 范围不动

拾集小队 · 2026-11-08

posted @ 2026-11-08 22:42 化合态阅读(8) 评论(0) 收藏举报

刷新页面返回顶部

化合态

团队项目第一次作业 团队展示+选题报告+需求分析