26软工实践 OUTFIT合伙人团队展示与选题报告

作业所属课程	H202601软件工程与软件工程实践
作业要求	2026秋软工实践团队作业-第一次（团队展示+选题报告+需求分析）
作业的目标	用真实需求驱动领域 Agent：围绕大学生与上班族的"衣柜满、没衣服穿"痛点，构建一个只盘活已有衣物、不做导购带货的对话式穿搭推理智能体。团队以 171 份真实问卷确定需求优先级，以服装色彩、版型、体型、面料、场景礼仪五类领域知识构建规则引擎与偏好加权双层推理，要求核心功能真实、完整、可运行、可验收。
团队名称	OUTFIT合伙人
团队成员学号-名字	赖彦然-102402106、谢慧彬-102402114、松格拉-102402112、吴佳仪-102402113、李青容-102402111、陈薇薇-102402109、姜思源-102402110、张润-102402115、刘翠华-102402105、阿合加依娜尔-102402108、王凯凤-052403108、王恩嘉-072401214、林诗怡-052402111

本次作业展现内容：团队展示 ———— 软件需求规格说明书（需求分析文档）———— 选题报告

团队展示

团队队名：Outfit 合伙人

十三个人分成四组：开发与知识库组、选题调研组、文档博客组、PPT 答辩组。队名里那个"合伙人"不是玩笑，我们打算让每个人都真的动一次手，而不是只守着自己那一块。

团队成员介绍

队员	学号	姓名	性格	擅长的技术	兴趣爱好	希望的软工角色
队长	052402111	林诗怡	绿老头和尺子姐随机切换	Python 开发、Web 前端页面搭建	睡觉、旅游、陪伴电子产品	PM
队员 1	102402106	赖彦然	可 I 可 E	后端开发	幕墙	后端
队员 2	102402105	刘翠华	ENTP	界面设计、UI	数字交互场景沉浸式体验	测试
队员 3	102402108	阿合加依娜尔	比较内向、有时候 E	Python	听音乐、看电影、跳舞	前端、测试
队员 4	102402109	陈薇薇	INTP	Python、SQL	听音乐、看小说	测试开发辅助
队员 5	102402110	姜思源	INFP	调研、设计方案	玩网游、听音乐	测试、文档撰写
队员 6	102402112	松格拉	I 人一个	Python	睡觉	资料整理与查重
队员 7	102402111	李青容	ISTJ	Python、Web 搭建	看小说、玩电子游戏	测试
队员 8	102402113	吴佳仪	i 人	检索调优、测试设计	小说、漫画	测试
队员 9	052403108	王凯凤	自带 DDL 雷达，不到最后一刻绝不爆发生产力的极限运动爱好者	前端	乒乓球、羽毛球	测试
队员 10	102402114	谢慧彬	i 人	前后端开发	睡觉	前端
队员 11	102402115	张润	INFP	数据处理与分析	画画、睡觉	需求分析与调研
队员 12	072401214	王恩嘉	一般	Python、C	思考人生	前端

首次合照

团队愿景

我们希望做一个不劝你买衣服的穿搭助手，
让衣柜里被忽略的衣服重新被看见，
让每次出门少一点纠结、多一点笃定。
用可解释的推理和真实反馈，
帮大学生和上班族更懂自己的衣橱，
也更理性地消费。

团队分工表

小组	岗位	成员信息 (姓名/学号)	核心职责与交付物
开发与知识库组 (6人)	S1	赖彦然 102402106	平台选型、Agent骨架搭建、API联调、Demo稳定化。 (交付：Agent、接口说明、对比素材)
	S2	谢慧彬 102402114	对话界面、领域功能页、API联调、体验打磨。 (交付：可交互前端页面)
	S3	松格拉 102402112	资料清单、清洗结构化、标注出处、知识库清单。 (交付：知识库文档包、来源清单)
	S4	吴佳仪 102402113	文档切片向量化、验证回答质量、建测试题集、回归测试。 (交付：知识库接入、测试题集)
	S5	李青容 102402111	部署上线拿公网地址、写测试用例及报告、整理测试说明。 (交付：公网链接、测试报告)
	S6	陈薇薇 102402109	答辩演示脚本、录完整演示视频、答辩当天操作与应急。 (交付：演示脚本、备用录屏)
选题调研组 (2人)	S7	姜思源 102402110	备选选题、写论证、输出大纲、起草团队愿景、画思维导图。 (交付：选题报告、大纲、愿景、导图)
	S8	张润 102402115	设计问卷提纲、线上发放与访谈、写调研报告、画用例图。 (交付：调研报告、画像、用例图)
文档博客组 (2人)	S9	刘翠华 102402105	搭国标框架、写介绍与功能描述、整合图表写验收标准、导出PDF。 (交付：需求分析文档PDF)
	S10	阿合加依娜尔 102402108	收集队员信息、写博客初稿、帮主笔排版、发布博客、提交作业。 (交付：发布的博客、排版文档)
PPT 答辩组 (2人)	S11	王凯凤 052403108	搭模板列大纲、收素材、做PPT初稿、按彩排修改终版。 (交付：答辩 PPT 终版)
	S12	王恩嘉 072401214	写10分钟演讲稿并背熟、建问答库、组织模拟问答、现场主讲。 (交付：演讲稿、问答库)
(全局统筹)	队长	林诗怡 052402111	负责分工、检查并改正每个组员的交付物，参与团队工作进度把控，做logo，协调各组联调与进度推进。

组内说明：期望角色是报名时填的意向，实际分工按项目阶段调整。跨组联调由队长牵头，每两天一次进度对齐。

文档信息与迭代记录

项目	内容
文档名称	对话式穿搭推理智能体 软件需求规格说明书
项目代号	outfit
文档版本	v1.0
文档阶段	需求分析（第一次团队作业）
编制	刘翠华（S9）、阿合加依娜尔（S10）
审核	林诗怡（队长）
参照标准	GB/T 8567-2006《计算机软件文档编制规范》
关联文档	选题论证报告、用户调研报告、原始问卷数据、产品功能与前后端实现说明

版本	日期	修订内容	负责人	状态
v0.1	10/13	选题论证、目标用户、领域边界初稿	姜思源（S7）	已完成
v0.2	10/16	171 份问卷设计与发放	张润（S8）	已完成
v0.3	10/19	用户调研报告 v1.0，含九项功能优先级	张润（S8）	已完成
v0.4	10/21	SRS 初稿：功能、接口、数据、非功能需求	刘翠华（S9）	已完成
v0.5	10/22	补入隐私与数据自主功能、异常与边界处理	阿合加依娜尔（S10）	已完成
v1.0	10/23	对齐调研口径、修正第 5 题数据；补需求可追踪性与未决问题	刘翠华（S9）、林诗怡	待评审

本阶段的交付边界：本次作业只交团队展示、选题报告和这份需求分析文档，不含可运行的软件。文档里写的功能是后续阶段的开发目标；第 6 章的验收标准是最终验收时的检查依据，本次不逐条自查；凡是本次还拿不出结果的，只写方法和判定口径，不编结果。

项目具体规划及描述

一、所选领域

面向日常生活场景的对话式穿搭推理与衣橱管理。

拆开看是三件事的组合：

• 对话式 —— 用户用自然语言描述场景和限制（"今晚约会，想温柔一点，不要太正式"），系统听懂并执行，不是一张张点选
• 穿搭推理 —— 依据服装领域知识（色彩、版型、体型、面料、场合礼仪）从用户已有衣物中筛出合法搭配，而不是给一张 AI 生成的搭配图
• 衣橱管理 —— 用户自己的衣物是数据底座，录入、分类、筛选、状态维护，以及买新衣服前的可搭性评估

二、项目标志

今遂在闽南语中音译过来就是真好看！

三、目标用户

大学生、上班族，以及不擅长穿搭的人。

用户类型	典型特征	核心诉求
大学生	单品数量中等、预算有限，场合以上课与社团为主，早上时间紧	快速得到"今天穿什么"的可行方案，不出错
上班族	通勤与办公场合要求较正式，单品多但搭配时间少	兼顾场合得体与舒适，减少早晨决策负担
不擅长穿搭者	缺少色彩、版型、面料的结构化知识，依赖模仿	要能讲清"为什么这样搭"，逐步建立自己的判断

第三类群体在调研里有 39.5%——他们知道自己不擅长，但说不清问题在哪，这正是我们想用可解释规则去接住的人。

四、调研情况

2026 年 10 月在问卷星发放，共回收 171 份有效问卷。样本以大学生（71.93%）和上班族（25.73%）为主，年龄集中在 18–22 岁（73.10%），女性 74.85%。

1、用户核心痛点占比

排第一的是"衣柜里衣服很多，但总觉得没衣服穿"（50.9%），第二是"有衣服，但不知道怎么互相搭配"（39.5%），第三是"网购新衣服时，不确定能不能和现有衣服搭"（33.5%）。这三项加起来覆盖了 124% 的受访者——平均每三个人里就有四个人被至少一个问题绊住。

2、大家现在怎么解决

主力是社交平台穿搭内容（65.3%）和天气 App（49.7%），而衣橱类 App 只有 6.6%。这个数字挺说明问题的：不是没人想要这种工具，是现有的东西没做到用户心里去。

3、现有做法差在哪

这题限选 2 项，所以比例加起来会超过 100%。最前面的是"推荐的是别人的衣服，不是我已有的衣服"（31.7%）和"不能结合我的体型"（31.1%），再往后是"偏导购带货，总让我买新衣服"（19.8%）、"不能根据我当天的想法调整"（15.6%）、"不能结合我的场合"（15.6%）、"不能解释为什么这样搭"（14.4%）、"录衣服太麻烦"（10.2%）。

4、需求真不真实

83 人（49.7%）非常愿意，60 人（35.9%）愿意试试，合计 85.6%；只有 2 人（1.2%）明确不愿意。需求是真的。

5、功能重要度排序

九项功能按"非常需要 + 需要"排：

排序	功能	重要度
1	结合场合（上课/通勤/面试/约会）推荐	86.8%
1	隐私保护（照片、身材数据、穿着记录）	86.8%
3	可以对话调整，如"不要黑色""换长裤"	85.6%
3	买新衣服前判断能不能和现有衣橱搭配	85.6%
5	记录穿着反馈，越用越懂我	84.4%
6	结合天气推荐今天穿什么	82.6%
7	一次给 3 套不同搭配，自己挑	69.5%
8	建立自己的数字衣橱（录入已有衣服）	68.3%
9	解释为什么这样搭（颜色、比例、场合）	62.9%

有两件事和直觉不太一样。隐私保护和结合场合并列第一，这直接推翻了"穿搭工具的核心是好看"这个默认假设；而"建立数字衣橱"和"解释为什么这样搭"排在最后两位——不是需求不重要，是这两个功能的实现成本恰好落在用户最不想付的地方（录入要花时间，解释要花注意力）。我们的应对是：录入靠 Excel 批量导入和下拉标签压到最低，解释挂在方案卡片上做成展开就看的形式，不强迫阅读。

6、软件形态偏好

微信小程序 37.7%、App 31.1%、都可以 29.3%、PC 网页 1.8%。这里的"Web"指 PC 端网页，1.8% 说明用户要的是"掏手机就能用"，不是"坐在电脑前用"。形态不是决定性因素，隐私和场合才是。

7、用户顾虑排序

录入太麻烦 48.5%、身材数据的隐私 47.9%、照片隐私 46.7%、穿着记录隐私 43.7%、推荐不准 43.1%、不想被引导消费 38.3%、不信任 AI 建议 25.1%。

前七项里三项是隐私，都在 43% 以上。这条数据我们后来返工了需求——原本隐私只写在安全需求里当一句约束话，实际上它该是一个独立功能，有独立页面，能让用户自己操作。

8、开放题诉求分布

回收 171 条，去掉 46 条"无/无明确需求"，剩 125 条有效诉求。排第一的是"不会搭配（配色/比例/成套）"（33.6%），然后是"按风格/天气/场合推荐"（24.8%）、"不知道穿什么"（24.0%）、"盘活已有衣物"（16.0%）。

"不会搭配"排第一，而且说的是配色、比例、成套这些具体维度——说明用户的困扰是技术性的，不是"我审美不行"这种模糊的困扰。所以系统必须能讲清颜色怎么配、比例怎么分，而不是给一句"这样搭很显瘦"。

关于样本的坦白话：这批样本以 18–22 岁女性大学生为主，结论更可能描述的是"年轻女性的穿衣痛点"。上班族这组只有 44 人，样本偏薄，后面我们对上班族的描述会相应保守一些。

五、智能体定制思路及主要任务

• 分层规则引擎：通过硬过滤、通用打分、差异化规则，筛出合法的公共穿搭集合
• 偏好加权：结合临时与长期偏好，对合法集合进行二次排序，实现个性化推荐
• 执行顺序：执行规则引擎 → 叠加偏好加权 → 输出最终结果

硬规则只做过滤、不参与排序打分——这一条反复确认过，因为一旦让硬规则参与打分，解释就没法做了。我们也加了一条硬约束：AI 只负责解析语义和组织解释文案，参与选品的一定是后端从用户真实衣橱里取出来并校验过的单品，不允许虚构。 这条不只是技术选择，也直接冲着调研里 25.1% 的"不信任 AI 建议"去的。

主要任务：通过"用户负责输入真实数据与主观意图，系统负责底层约束校验与客观推理生成"的流程，形成"操作触发 → 功能响应 → 结果反馈"的完整闭环。

---

软件需求规格说明书

1. 引言

1.1 编写目的

本文档为对话式穿搭推理智能体软件需求规格说明书，定义软件全部功能、非功能、接口与数据需求。作为项目概要设计、详细设计、编码、测试、课程评审的依据，面向项目开发人员、测试人员与课程评审教师。

1.2 项目背景

1.2.1 调研依据

现有衣橱类应用多以"图片识别 + 电商导购"为主线，重点是把衣服卖出去，而非盘活用户已有衣物。本项目反向定位：不做导购带货，以"组合已有衣物 + 解释搭配原理 + 减少冲动购买"为核心价值。"衣柜很满、却没有衣服穿"是城市年轻群体中普遍存在的穿衣困境。调研将其拆解为五类具体问题：

序号	痛点	具体表现	调研支撑
1	决策耗时	早上出门为"穿什么"反复犹豫，挤占通勤与早餐时间	45.5% 每天花 1 分钟以上；6.0% 超 5 分钟或经常反复纠结
2	组合困难	单品数量多，但不知道哪些能互相搭配，形成"衣柜满、没衣服穿"	50.9% 觉得衣服多却没衣服穿；39.5% 不知道怎么互相搭配；开放题第 1 类
3	购前失判	网购时无法预判新衣能否与已有衣服搭配，容易重复购买同类单品	33.5% 网购时不确定能否搭配；12.0% 买回来发现重复
4	条件复杂	天气、场合变化后，需要同时兼顾体型、色彩与场合规范，普通人缺少结构化知识	28.7% 天气变不会调整；16.2% 场合变不会穿
5	审美主观	固定模板式推荐难以适应用户当天的临时风格想法	15.6% 不能按当天想法调整；开放题第 1 类指向配色/比例等具体维度

理论依据来源于服装与形象设计领域的成熟知识体系：服装色彩构成理论、服装造型与版型设计理论、人体体型服饰适配规则、服装材料学面料特性知识、场景着装礼仪规范，以及胶囊衣橱 / 极简衣橱管理理论；同时参考服装设计、形象美学、现代礼仪相关教材与期刊文献。项目运行过程中积累的用户穿搭评价，作为偏好学习的动态数据来源。

1.2.2 调研结果

调研问题：

第一、目标用户是否存在真实的日常穿搭困扰
第二、痛点集中在哪些具体场景
第三、现有解决方式有哪些不足
第四、用户对数字衣橱、天气结合、场合推荐、多轮调整、购前评估等功能的需求程度

调研结论

痛点高频且普遍：45.5% 的受访者每天在穿搭决策上花费 1 分钟以上，6.0% 超过 5 分钟或经常反复纠结。穿搭选择是高频的日常负担。

核心矛盾在于"不会组合"：50.9% 的用户觉得"衣服多却没衣服穿"，39.5% 觉得"有衣服但不会互相搭配"，45.5% 觉得"经常穿的就那几件，很多衣服闲置"。这里要说清楚：45.5% 说的是有多少人觉得衣服在闲置，不是"有 45.5% 的衣服是闲置的"。用户面对的不是缺衣服，是衣柜没有被盘活。

现有工具存在错位：31.7% 的用户反感现有工具"推荐别人的衣服"，31.1% 认为"不能结合自身体型"，19.8% 抵触"偏导购带货"。衣橱类 App 的实际使用率只有 6.6%，说明问题不在需求侧。

需求高度聚焦：按"非常需要 + 需要"排，结合场合推荐与隐私保护并列第一（86.8%），对话调整与购前评估并列第三（85.6%）。隐私保护是本次调研中排名最高的诉求，也是我们产品定位里最容易被忽略的一条。

顾虑集中在隐私与录入成本：前七项顾虑中三项与隐私相关——身材数据隐私 47.9%、照片隐私 46.7%、穿着记录隐私 43.7%；"录入太麻烦"以 48.5% 排第一；"不想被引导消费"38.3%。

形态偏好明确但非决定性因素：微信小程序 37.7%、App 31.1%、都可以 29.3%、PC 网页 1.8%。1.0 版交付移动端优先的 Web，小程序留到后续阶段（取舍理由见文末《选题论证报告》「三、领域边界」）。

1.3 项目介绍

1.3.1 项目概况

本项目是一个面向大学生、上班族的对话式穿搭推理智能体。用户通过下拉标签表单搭建轻量数字衣橱，系统对接天气接口、获取使用场景，结合用户体型、本次临时偏好与长期历史偏好，一次性输出 3 套差异化穿搭方案，并给出可解释的搭配理由。项目 1.0 版不做人工智能图片识别，图片仅做前端预览，衣物信息靠下拉标签录入，重点放在穿搭推理与可解释推荐。系统支持购前新品搭配评估，记录穿搭评价，持续学习用户长期偏好，帮助用户减少盲目买衣服。

核心目的：盘活用户已有衣物，不做导购带货。

1.3.2 智能体定制思路

• 分层规则引擎：通过硬过滤、通用打分、差异化规则，筛出合法的公共穿搭集合。
• 偏好加权：结合临时与长期偏好，对合法集合进行二次排序，实现个性化推荐。
• 执行顺序：执行规则引擎 → 叠加偏好加权 → 输出最终结果。

通过"用户负责输入真实数据与主观意图，系统负责底层约束校验与客观推理生成"的流程，形成"操作触发 → 功能响应 → 结果反馈"的完整闭环。

1.3.3 目标用户

用户类型	典型特征	核心诉求
大学生	单品数量中等、预算有限，场合以上课与社团为主，早上时间紧	快速得到"今天穿什么"的可行方案，不出错
上班族	通勤与办公场合要求较正式，单品多但搭配时间少	兼顾场合得体与舒适，减少早晨决策负担
不擅长穿搭者	缺少色彩、版型、面料的结构化知识，依赖模仿	要能讲清"为什么这样搭"，逐步建立自己的判断

1.3.4 典型使用场景

编号	场景	用户动作	系统响应
场景1	打开首页	进入应用	展示城市与当日天气，读取衣橱生成最多 3 套今日搭配及理由；衣橱为空时引导添加衣物，不虚构
场景2	早八上课	输入"帮我搭配今天上课的穿搭"	读取当日天气，结合课业场合与衣橱单品，输出 3 套方案及理由
场景3	通勤 / 面试	选择场合"面试"，勾选临时偏好"暗色 + 基础款"	按正式度筛选单品，控制色彩数量，给出偏稳重的 3 套方案
场景4	网购前评估	录入待购单品（参考图 + 标签）	判断能否与现有衣橱搭配、是否与已有单品相似，给出购买建议
场景5	多轮微调	"把长裤换成半身裙，不要黑色衣物"	在上一轮方案基础上替换单品，保持其余条件不变并重新解释理由
场景6	偏好沉淀	对穿过的方案评价"喜欢 / 一般 / 不喜欢"，或标记"今天穿了"	记录反馈并更新长期偏好权重，影响后续推荐排序

1.3.5 思维导图

思维导图自中心"对话式穿搭推理智能体"展开六个一级分支，分别对应衣橱、场景、偏好与推荐、多轮对话、购前评估、偏好学习。

1.4 项目范围

1.4.1 本版本（1.0 版）包含功能

1. 首次资料填写与登录注册
2. 数字衣橱录入：衣物图片上传预览、下拉标签录入衣物属性、电子表格批量导入衣物
3. 场景信息获取：对接天气接口获取温湿度、降雨、天气状况；支持手动选择场合、自然语言输入穿搭需求
4. 偏好选择、穿搭推荐、多轮对话调整（核心）：临时偏好选择，智能体生成 3 套差异化穿搭方案与搭配理由，支持文字 / 快捷按钮修改搭配
5. 新品购前评估：录入待购衣物信息，智能体分析搭配能力、判断相似单品
6. 用户偏好学习：对穿搭方案评价并提交穿着反馈，系统持续学习个人长期穿搭偏好
7. 历史记录：推荐评价、对话历史、购前评估历史分开展示，支持查询与删除
8. 隐私与数据自主：数据查看、导出、一键删除，长期偏好查看与重置

功能顺序按调研的"非常需要 + 需要"重要度排列：结合场合推荐与隐私保护并列最高，所以场合作为硬规则贯穿全部推荐链路，隐私作为独立功能模块而非附带说明。

1.4.2 本版本（1.0 版）不包含

1. 衣物图片人工智能识别（1.0 版不做，理由和后续验证条件见文末《选题论证报告》「一、为什么选择本课题」）
2. 近场通信衣柜标签碰一碰录入衣物功能
3. 服饰电商导购、商品跳转购买与支付
4. AI 生成穿搭效果图、人体虚拟试衣
5. 服装工业 CAD、服装设计生产相关功能
6. 换季整理与胶囊衣橱盘点功能（调研中该场景未进入前三优先项，后续阶段再评估）
7. 从电商订单批量导入衣橱（调研中 24.6% 的用户有此期待，后续阶段再评估）

1.4.3 硬件联动

本期不做硬件联动。

作业评分里硬件是可选加分项，规则写得很清楚：只展示硬件、播放无联动的效果或提出未实现的设想不加分；纯软件项目仍可参与全部奖项评选，硬件不是获奖的必要条件。所以我们不为了加分硬凑一个。

调研这边的理由也很直接。"录入太麻烦"以 48.5% 排在顾虑首位，任何要求用户额外购买硬件、额外佩戴或额外操作的方案，都会加重这个负担，跟产品方向是反的。

如果后续阶段有余力，我们会先验证最小可行路径：选一款低成本温湿度传感器，把实时读数作为天气数据的补充来源接入天气服务，看它是否真的能改善推荐结果。验证通过再考虑 NFC 衣物标签这类需要用户购买和管理的方案。在真正跑通之前，我们不在文档里写具体的数据流设计。

1.5 术语与缩写

术语	说明
穿搭智能体	后端推理模块，依据服装理论、天气、场合、用户偏好筛选、打分，生成穿搭方案
临时偏好	单次穿搭推荐生效的用户偏好，优先级高于长期偏好
长期偏好	用户多次穿搭评价积累得到的个人风格权重，用于推荐排序
硬规则	客观筛选条件（季节、温度、场合、可穿状态），仅过滤衣物，不参与打分排序
通用打分	对通过硬过滤的单品组合打基础分，不含个人偏好成分
差异化规则	区分场合与场景的补充规则，如正式场合控制色彩数量
知识库	经清洗结构化与切片向量化后供检索的服装领域知识条目集合
软件需求规格说明书	本文档的文档类型

1.6 参考资料

1.6.1 国际软件需求规范标准

GB/T 8567-2006《计算机软件文档编制规范》

1.6.2 对话式穿搭推理智能体项目计划书

〔待补：文档链接〕

1.6.3 选题报告

见附录腾讯文档链接

1.6.4 知识来源

1. 服装色彩构成理论
2. 服装造型与版型设计理论
3. 人体体型服饰适配规则
4. 服装材料学面料特性知识
5. 场景着装礼仪规范
6. 胶囊衣橱与极简衣橱管理理论
7. 参考服装设计、形象美学、现代礼仪相关专业教材与期刊文献
8. 项目运行过程中的用户穿搭评价反馈，作为偏好学习的数据来源

〔待补：1–7 项的具体出处（书名 / 期刊名 / 作者 / 年份 / 章节），以及知识库文档包链接。〕

2. 总体描述

2.1 产品视角

本产品为移动端优先的网页应用，分为前端交互层、后端业务服务层、穿搭智能体推理模块、知识库模块、数据库。

• 前端：页面展示、图片预览、收集用户输入、文件上传、基础表单校验，不执行穿搭推理；将用户请求发给后端，展示后端返回结果。
• 后端：负责数据持久存储、电子表格文件解析、调用第三方天气接口；穿搭智能体全部推理逻辑（过滤、打分、生成搭配、新品评估、偏好学习）均在后端执行，返回结构化结果给前端。
• 智能体推理模块：规则引擎 + 偏好加权两层，单品只能取自用户真实衣橱。
• 知识库模块：领域知识条目的检索与出处回填，为理由生成提供依据。

初期在一个后端应用内按业务划分模块，不拆微服务。

2.2 用户特征

目标用户为大学生、年轻上班族。可以操作网页表单、上传图片文件；无编程基础；需求是利用已有衣柜衣物获取穿搭方案，网购前评估新衣服适配性。

2.3 运行环境

• 前端：主流移动端浏览器（微信内置浏览器、Chrome、Safari）与桌面浏览器，布局以移动端为基准
• 后端：网页后端服务，搭配关系型数据库
• 网络：联网用于调用天气接口；天气接口失效时系统支持手动输入参数降级使用
• 图像识别：1.0 版不涉及，不作为识别结果的数据来源

2.4 约束

1. 1.0 版不开发图像识别，图片仅前端预览，衣物属性依靠下拉标签手动录入。后续阶段若接入图像识别，只用于预填标签供用户确认，不得直接作为推荐依据
2. 近场通信衣物标签功能属于二期拓展，本版本不实现
3. 用户输入表单必须做合法性校验，防止非法数据入库
4. 不同用户的数据相互隔离，用户仅可访问自身衣橱数据
5. 偏好优先级规则：本次临时偏好 > 长期历史偏好 > 系统客观硬性过滤规则；硬规则只做过滤，不参与排序打分
6. 智能体不得虚构用户衣橱中不存在的单品；AI 仅负责语义解析与理由组织，选品由后端从真实衣橱取值并校验
7. 用户衣物图片、身材数据、穿着记录不得用于模型训练或对外共享
8. 1.0 版交付移动端优先的 Web 应用，小程序形态列入后续阶段；后端接口设计需满足小程序接入
9. 单套方案不强制包含鞋履。系统不假设用户拥有鞋子、外套或其他单品，组合规则按实际库存和天气决定，有效搭配不足时允许少于 3 套并说明原因

2.5 假设与依赖

1. 假设用户手动填写衣物标签信息，愿意对穿搭方案给出评价反馈
2. 依赖第三方天气接口获取温度、降雨信息；接口不可用，允许用户手动输入天气参数，系统继续运行
3. 用户浏览器支持图片上传与预览功能
4. 依赖可用的大模型 API 完成语义解析与理由组织
5. 依赖可用的对象存储保存衣物图片，数据库存储结构化数据

3. 具体需求

3.1 外部接口需求

3.1.1 用户界面需求（前端）

系统页面包含登录注册、首次资料填写、首页、电子衣橱、衣物录入与编辑、电子表格导入、AI 对话穿搭、购前评估、历史记录、个人资料与设置、隐私与数据管理共 11 个页面。

1. 登录注册页：账号注册与登录入口
2. 首次资料填写页：性别、常用城市、身高体型风格
3. 衣橱录入页面：图片上传预览组件、下拉标签表单、电子表格文件上传控件
4. 场景页面：天气展示区域、场合选择下拉框、自然语言需求输入框
5. 穿搭对话页面：临时偏好快捷选择按钮、对话输入框、穿搭方案与搭配理由展示区域、多轮调整快捷按钮
6. 新品评估页面：新品图片预览、新品标签勾选表单、评估结果展示
7. 评价组件：喜欢 / 一般 / 不喜欢评价按钮，穿着反馈表单
8. 隐私与数据管理页：数据总览、导出、删除、偏好重置

3.1.2 第三方软件接口

天气接口：传入位置信息，返回温度、降雨、天气状况参数；接口调用失败支持降级，允许用户手动填写天气信息。

大模型 API：传入结构化上下文（衣橱候选、场景约束、偏好、需求文本），返回结构化语义解析结果与理由文案。系统需对返回做 schema 校验，解析失败时降级为规则模板文案。

3.1.3 通信接口

前端向后端发送业务请求，后端返回结构化数据。接口需覆盖用户注册登录与资料读写、城市天气查询、衣物增删改查与筛选、图片上传、Excel 模板下载与批量导入、首页推荐与换一批、对话创建与调整、方案评价、标记已穿与穿着反馈、购前评估与追问、偏好查看与重置、历史查询与删除、用户数据导出与清除。方案评价和穿着反馈必须关联具体方案编号；每次对话调整必须关联会话编号。

〔待补：完整接口清单见 SRS 完整版文档。〕

3.2 功能需求

3.2.1 前端功能

页面	主要功能	关键交互
登录与注册	账号注册、登录	表单校验、错误提示不暴露技术细节
首次资料填写	性别（男/女必选）、常用城市（必填）、身高/体型/风格（选填）	选择性别和城市后才允许提交；选填项不阻挡进入；提交后进入首页。
首页（今日推荐）	展示城市与天气（温度/降雨/状况）、最多3套今日搭配、搭配理由与注意事项；衣橱为空时引导添加衣物（不虚构）	查看详情、换一批、喜欢/一般/不喜欢、继续调整；人工智能对话/电子衣橱/购前评估入口。当天首次生成并保存，再次进入默认展示已有方案；处理天气失败、加载中等状态。
电子衣橱页	按品类（T恤/衬衫/裤子/裙子/风衣/毛衣/鞋子/配饰）分组展示及数量统计；按颜色/季节/场合筛选；查看详情、编辑、删除、修改状态（可穿/清洗中/暂不可穿）	点击分类查看单品；下拉标签筛选；提供新增衣物、电子表格导入入口。排除不可穿衣物进入推荐。
衣物录入/编辑页	新增或编辑衣物：名称/品类/主颜色（必填，或图片与名称至少提供一项）、季节或厚薄（至少一项）、版型/面料/场合/备注（选填）、图片（选填，仅预览）	全部为下拉或点选（支持"其他"）；图片上传后显示预览，支持替换或删除；控制必填项数量。
电子表格批量导入页	模板下载、文件上传、逐行导入结果展示	展示成功条数；失败行返回具体原因，支持用户修正。
人工智能对话穿搭页	展示对话消息与最多3套方案卡片（单品、理由）；支持文本输入和多轮调整	快捷调整项（如"换成裙子""不要黑色""更休闲"）；方案卡片提供喜欢/一般/不喜欢评价。
对话调整/反馈区	选定方案后标记"今天穿了"；提交实际穿着反馈（舒适度/保暖性/场合适配度及原因标签，可选文字）	推荐反馈（喜欢/一般/不喜欢）与穿着反馈分开保存；保留每轮消息和方案供查看调整过程。
购前评估页	上传新品参考图并填写标签（复用衣物表单控件）；展示可搭配衣物、代表性组合、组合数量、相似单品及判断依据（基于标签）	提供追问入口；明确提示"基于用户填写的标签"，不给出"肯定重复"等超出数据能力的结论。
历史记录页	区分展示推荐评价、对话历史、购前评估历史；历史方案使用生成时的快照展示	查看历史详情；支持查询和删除历史记录。
个人资料与设置页	修改基础资料（性别/城市等）；查看或重置长期偏好	提供偏好重置入口；资料修改后同步更新后端。
隐私与数据管理页	查看数据存储范围、导出衣橱/偏好/历史、清除全部数据、重置长期偏好	一键清除需二次确认；删除后不可恢复；导出以文件形式提供。

3.2.2 后端功能

服务模块	功能说明	输入 / 输出
用户与鉴权服务	用户注册/登录；维护用户资料（性别仅限男/女，城市非空）	账号、资料字段 / 用户对象、令牌
衣橱服务	衣物增删改查；维护归属关系；按属性筛选；排除已删除/清洗中/暂不可穿的衣物进入推荐	衣物对象 / 筛选结果集
图片与导入服务	保存衣物及新品图片，返回预览地址（不解析内容）；解析电子表格并校验字段	图片文件/电子表格文件 / 图片链接地址、成功条数及失败原因
场景与天气服务	对接天气接口（温度/降雨/状况）；获取并缓存天气数据；合并用户输入场景（约会/通勤等）与自然语言限制	日期、城市、场合文本 / 天气快照、场景对象
规则约束引擎	硬性约束：天气/场合/库存/可穿状态筛选；校验候选衣物必须属于当前用户且可穿；衣橱中该类无可穿单品时需说明原因并给替代方案	候选单品集 / 合规单品集
方案生成与解析	从真实衣橱中生成候选搭配（上装+下装，视天气和库存加外套，鞋履不强制；连衣裙作为主体）；人工智能仅负责解析语义和组织解释，禁止虚构单品；最多返回3套有效方案	合规单品集、用户偏好、对话意图 / 合规组合（≤3套）、冲突询问/确认
理由生成	为每套方案生成可解释文案（色彩、比例、面料、场合四个维度），从知识库召回依据并标注出处	方案 / 搭配理由文本、知识出处
对话理解与多轮调整	解析"把长裤换成半身裙""不要黑色"等指令，定位待替换单品槽位；关联会话编号保存消息和调整记录	指令文本 / 约束条件、会话编号
反馈与偏好学习	区分记录推荐反馈和穿着反馈；仅凭用户主动提交的反馈更新长期偏好（不自动记录不喜欢）；简单权重汇总偏好；提供重置能力	方案编号、反馈类型、评价、原因 / 偏好权重
购前评估服务	保存新品标签和图片地址；与现有衣橱按品类/颜色/季节/版型/场合比较；生成可行组合并统计；识别相似单品	新品标签 / 评估报告（可搭数量、相似度依据）
历史快照服务	保存推荐结果和天气快照；保存方案中的衣物编号及生成时的衣物信息快照，确保衣物删除后历史仍可展示；保留历史记录并支持删除	会话编号、方案编号 / 历史记录列表、删除结果
隐私与数据服务	提供数据总览、导出打包、一键删除、偏好重置；数据仅限本人访问，不用于模型训练	用户标识、操作类型 / 导出文件、删除结果
统一推荐规则	首页推荐与对话推荐共用同一套搭配校验与排序逻辑；本轮临时偏好优先于长期偏好进行排序	用户数据、场景约束 / 排序后的推荐方案

3.2.3 类图

类图给出后端领域模型的主要实体、属性与关键方法。用户与衣物单品、穿搭方案、偏好档案之间为一对多关系；穿搭方案组合多个衣物单品，并关联场景与临时偏好；推荐智能体依赖规则引擎与偏好档案完成分层推理；购前评估器查询衣橱数据完成购前评估。

类名	职责	关键属性	关键方法
用户资料	用户基本信息与体型	性别、城市、身高、体型、风格	获取资料、更新体型
衣物单品	衣橱中的单件衣物	品类、颜色、季节、厚薄、版型、面料、场合、状态	颜色匹配、适用场合判断
天气快照	生成方案时的天气	城市、日期、温度、降雨、状况	是否需要防水、正式程度
推荐会话	一次首页推荐或对话会话	会话编号、来源、原始输入	关联消息与方案
对话消息	会话中的一条消息	角色、内容、时间	—
穿搭方案	一套搭配方案	单品集合、得分、理由、是否选中	生成理由、替换单品
方案单品	方案与衣物的关联	槽位、衣物编号、生成时快照	—
反馈记录	穿搭反馈记录	方案编号、反馈类型、评价、原因标签	转权重增量
偏好档案	长期偏好权重	颜色/风格/版型权重、更新时间	应用反馈、重置
购前评估	购前评估记录	新品标签、图片地址、关联衣物、依据	可搭数量、相似单品判断
规则引擎	客观硬性规则集	规则集	按天气过滤、按场合过滤、状态过滤、三色校验、体型校验
推荐智能体	分层推理与方案生成	规则引擎、偏好档案	生成推荐、排序、生成理由、多轮调整
购前评估器	购前可搭性与相似度评估	衣橱	可搭配数量、相似单品判断、评估报告
知识检索器	领域知识检索与出处回填	知识库索引	检索、返回出处

3.3 用例

用例编号	用例名称	参与角色	关系类型	用例描述与操作逻辑
用例1	录入/导入衣物	用户	基础操作	用户通过表单下拉录入或电子表格导入衣物属性。系统校验并保存，衣橱为空时无法进行后续推荐。
用例2	输入需求与临时偏好	用户	基础操作	用户选择穿搭场景、输入自然语言需求并勾选本次临时偏好。系统解析这些约束条件。
用例3	多轮对话调整	用户	基础操作	用户对已生成的方案提出修改（如"换裙子"）。系统在真实衣橱中重新匹配替换单品。
用例4	评估新品可搭性	用户	基础操作	用户上传新品标签，系统与现有衣橱比对，输出可搭配数量及相似度参考。
用例5	提交穿搭反馈	用户	基础操作	用户对方案进行"喜欢/一般/不喜欢"评价，或提交实际穿着的舒适度反馈。
用例6	生成 3 套搭配方案	系统	核心用例	系统的核心业务逻辑。基于用户衣橱、硬性规则引擎和偏好加权，生成最多 3 套合法方案。
用例7	获取天气信息	系统	包含	被用例6包含。系统生成方案前必须尝试拉取当地天气作为硬过滤条件，失败则按降级策略提示用户。
用例8	查看搭配理由	系统	包含	被用例6包含。系统生成方案后，必须同步生成色彩、版型/比例、面料、场合四个维度的解释文案并标注知识出处。
用例9	更新长期偏好	系统	包含	被用例5包含。系统必须根据用户主动提交的反馈进行偏好权重更新计算。
用例10	管理隐私与数据	用户	基础操作	用户查看数据范围、导出或一键删除自己的衣橱、偏好与历史记录。系统二次确认后执行且不可恢复。

3.4 异常与边界处理

编号	异常场景	系统响应	用户提示口径
EX-01	衣橱为空	不生成搭配，引导添加衣物	"先添加几件衣服，我才能帮你搭配"
EX-02	候选衣物不足	返回少于 3 套的有效方案并说明原因	"按当前条件只凑出 2 套，缺一条合适的下装"
EX-03	用户要求衣橱中不存在的单品	解释当前库存不满足，给出可行替代	"你衣柜里没有半身裙，这两套用了阔腿裤替代"
EX-04	天气服务失败	允许继续，提示本次未使用实时天气	"本次未使用实时天气，天气数据是手动填的"
EX-05	衣物不可穿	该衣物不参加推荐	列表中标注"清洗中 / 暂不可穿"
EX-06	Excel 部分行出错	成功行可导入，错误行返回原因	逐行列出行号与失败原因，可修正后重传
EX-07	AI 服务失败	保留输入和会话内容，允许重试	"生成没成功，你的话我留着，点一下重试"
EX-08	用户需求冲突	询问优先项，或让用户确认系统的理解	"你说要正式但又想穿得休闲，以哪个为准？"
EX-09	衣物后来被删除	历史方案用快照继续展示	历史页正常显示，标注"该单品已从衣橱移除"
EX-10	新品信息不足	要求补充必要标签，不给肯定的重复判断	"再选一下颜色和季节，我才能比"
EX-11	用户数据删除	二次确认后清除，不可恢复	"删除后无法恢复，确认吗？"

---

4. 非功能需求

4.1 性能需求

1. 穿搭推荐后端生成耗时 ≤ 2 秒（天气接口网络耗时不计入）
2. 端到端渲染完成 ≤ 5 秒（本地或测试环境），与 6.3 节定制效果检查口径一致
3. 单用户衣橱至少可存储 200 件衣物
4. 支持至少 10 名用户并发使用系统

4.2 可用性需求

1. 核心穿搭、衣橱管理功能可用率 ≥ 95%
2. 天气第三方接口故障可降级，系统不会崩溃，允许手动输入天气参数
3. AI 服务故障不影响衣橱浏览、录入、设置等非生成类功能

4.3 安全需求

1. 用户数据隔离，用户只能查看、修改自己衣橱内数据
2. 所有前端输入进行校验，防止非法数据存入数据库
3. 用户上传图片仅本人可见
4. 密码不以明文存储，登录态使用带有效期的令牌

4.4 隐私需求

这一节单列，因为它在调研里是并列第一的功能诉求（86.8%），不该只是安全需求里的一句话。

1. 用户的衣物图片、身材数据、穿着记录仅存储在自有数据库，不用于任何模型训练或对外共享
2. 用户可随时查看系统存储了哪些数据（数据总览）
3. 用户可导出自己的衣橱、偏好与历史记录
4. 用户可一键清除全部数据，删除后不可恢复，需二次确认
5. 长期偏好可单独重置而不影响衣橱数据
6. AI 生成的建议均标注推断依据，不做"一定好看""绝对重复"这类绝对化承诺
7. 购前评估结果必须显式说明"基于用户填写的标签"，让用户知道结论的数据来源和局限

4.5 可维护性需求

1. 穿搭硬规则、偏好打分逻辑与业务代码解耦，便于后续修改穿搭理论规则
2. 模块低耦合，方便二期扩展近场通信标签功能
3. 知识库条目与规则实现分离，调整知识条目不需要改动代码逻辑
4. 前后端共用同一套标签枚举，枚举值集中在配置中维护

4.6 易用性需求

1. 尽量使用下拉、快捷按钮，减少大段文字输入
2. 报错提示面向普通用户，不展示底层技术错误信息
3. 移动端为布局基准，重要操作在单手可及范围内
4. 空状态、加载中、失败状态都有明确文案和下一步动作，不出现空白页

4.7 适应性与计算机资源需求

1. 前端不依赖特定浏览器特性的主流私有 API，在 Chrome、Safari、微信内置浏览器上功能一致
2. 后端不与特定云厂商绑定，数据库与对象存储通过适配层接入，可迁移到其他云环境
3. 应用服务器 2 核 4G 起步支持 10 并发，可弹性扩容；单用户 200 件衣物、1 年历史记录的数据量在 1G 以内

5. 数据需求

系统持久化存储以下数据：

1. 用户账号与资料：账号标识、性别、常用城市、身高、体型、常用风格
2. 用户衣橱衣物数据：图片存储地址、名称、品类、主颜色、季节或厚薄、版型、面料、适用场合、状态、备注
3. 天气快照数据：城市、日期、温度、降雨、天气状况、获取时间
4. 用户长期穿搭偏好权重数据：颜色、风格、版型三类权重及更新时间
5. 穿搭会话数据：会话编号、来源（首页/对话）、用户原始输入、关联天气快照
6. 对话消息数据：消息编号、会话编号、角色、内容、时间
7. 穿搭方案数据：方案编号、所属会话、得分、搭配理由、是否被选中
8. 方案-衣物关联数据：方案编号、衣物编号、槽位、生成时的衣物信息快照
9. 用户穿搭评价记录：方案编号、反馈类型（推荐评价/穿着反馈）、评价、原因标签、评论、时间
10. 购前评估记录：新品标签、图片地址、评估结果、关联衣物、评估依据

数据量约定：单用户衣物上限 200 件；单次会话保留最近 50 轮消息；历史方案保留 1 年，用户可主动删除；偏好权重每次更新后覆盖写入，不保留历史版本。

6. 验收标准

6.1 验收原则

验收不比对"绝对好看"，而以可核查的三类指标判定：① 任务能否完成（代表性领域任务）；② 结果是否合规可解释（规则与理由检查）；③ 偏好是否真的生效（定制效果检查）。

这一节是最终验收时的检查依据，不是本阶段的完成承诺。 本次作业只交付需求侧文档，软件尚未开发，下面 6.2 的十项任务都要到系统可运行之后才能逐条自查。我们把判定口径先定死，是为了后面的开发有个明确的目标，也免得验收时各说各话。

6.2 代表性领域任务

编号	任务	操作步骤	通过判定
任务1	建立初始衣橱	录入 10 件衣物：5 件用手动标签，5 件用 电子表格批量导入	10 件全部入库，属性与填写一致，列表可见
任务2	天气驱动的推荐	输入"今天上课穿什么"，当日有降雨	3 套方案均不含与雨天明显冲突的品类（如棉麻长裙、浅色帆布鞋），且至少 1 套在理由中给出防水或保暖提示；衣橱无可穿外套时允许给出少于 3 套并说明原因
任务3	临时偏好生效	同一衣橱、同一场景，分别选"亮色"和"暗色"各生成一次	两次方案的主色系明显不同，且各自符合所选色彩倾向
任务4	搭配理由可核查	打开任一方案的理由	理由至少覆盖色彩、版型/比例、面料、场合四个维度中的三项，且与方案单品一致
任务5	多轮调整	在方案基础上输入"把长裤换成半身裙"	该套方案裤装被替换为半身裙，其余单品与场景条件不变
任务6	排除类指令	输入"不要黑色衣物"	重生成后方案中不含颜色为黑色的单品
任务7	购前评估	录入一件与现有衣橱同品类、同色系新品	系统给出"根据当前标签，可与现有 N 件搭配"的结论，并提示"与已有 X 件在品类、颜色、季节上相似"，不出现"肯定重复"字样
任务8	偏好学习闭环	对 5 套方案给出"喜欢/不喜欢"后重新生成	推荐排序发生可观察变化，喜欢的风格权重上升
任务9	隐私与数据自主	进入隐私与数据管理页，查看数据范围并导出	能看到系统存储的数据条目清单，导出文件包含衣橱、偏好与历史三部分
任务10	异常降级	断网后请求推荐	系统提示未使用实时天气或生成失败，保留用户已输入内容，允许重试，不出现崩溃或空白页

6.3 定制效果检查方式

检查项	检查方法	量化口径
规则合规率	对生成的 N 套方案逐条核对硬性规则（气温、场合、三色原则、体型避坑）	合规方案数 / 总方案数 ≥ 95%
理由一致性	抽检方案理由与单品属性是否矛盾（如理由称"亮色"但单品为深色）	抽检 30 套，矛盾数 = 0
偏好生效度	固定衣橱与场景，仅切换临时偏好（亮色/暗色），比较两次结果的主色与款式分布	两次生成中至少 1 次的主色分布出现预期方向变化
多轮保持度	执行"替换单品"指令后，核对未涉及的槽位是否被误改	未涉及槽位变动数 = 0
响应时延	从提交需求到 3 套方案渲染完成	≤ 5 秒（本地或测试环境）
购前判断可用性	人工核对评估结论与实际可搭组合是否相符	抽检 10 件，结论正确率 ≥ 80%
隐私声明一致性	检查隐私页文案与后端实际行为是否一致	不一致项数 = 0
主观满意度（辅助）	邀请 5–10 名目标用户对 20 套方案打分（1–5）	平均分 ≥ 3.5，且不得出现明显不合场合方案

说明：本项目不以"所有用户都觉得好看"为目标，因此验收以"合规 + 可解释 + 偏好可感知 + 数据自主"为主，主观满意度仅作为辅助参考。初稿阶段的量化阈值可在详细设计后按实际数据微调。

6.4 需求可追踪性

需求编号	需求名称	所属页面	对应用例	验收项	优先级
FR-01	登录注册与鉴权	登录注册页	—	—	P0
FR-02	首次资料填写（性别/城市必填）	首次资料填写页	—	任务1	P0
FR-03	数字衣橱录入（标签 + 图片预览）	衣物录入页	用例1	任务1	P0
FR-04	Excel 批量导入	Excel 导入页	用例1	任务1	P0
FR-05	衣橱分类、筛选、状态管理	电子衣橱页	用例1	任务1	P0
FR-06	天气与场合获取（含降级）	首页、对话页	用例7	任务2、10	P0
FR-07	三套方案生成（真实衣橱取样）	首页、对话页	用例6	任务2、3	P0
FR-08	搭配理由生成（四维度 + 出处）	方案卡片	用例8	任务4	P0
FR-09	多轮对话调整与槽位保持	对话页	用例3	任务5、6	P0
FR-10	推荐评价与穿着反馈分离保存	评价组件、穿着反馈区	用例5	任务8	P0
FR-11	长期偏好学习与重置	设置页	用例9	任务8	P0
FR-12	购前评估与相似度依据	购前评估页	用例4	任务7	P0
FR-13	历史快照与记录管理	历史记录页	—	—	P1
FR-14	隐私与数据自主（总览/导出/删除）	隐私与数据管理页	用例10	任务9	P0
FR-15	异常降级与错误提示	全局	—	任务10	P0
NFR-01	推荐后端生成 ≤ 2 秒	—	—	响应时延	P0
NFR-02	数据隔离与访问控制	—	—	隐私声明一致性	P0
NFR-03	规则与代码解耦	—	—	—	P1
NFR-04	移动端优先与多浏览器一致	—	—	—	P0
NFR-05	前端可移植、小程序可复用	—	—	—	P1
NFR-06	资源占用与并发	—	—	—	P1

6.5 尚未解决的问题

下面这些是现在确实还没定的事，不是我们忘了写。列出来是为了下一次作业开始时能直接拿这张表过一遍、逐条拍板。其中 Q-01、Q-02、Q-03、Q-05、Q-11 属于技术选型，答案会影响架构和接口，建议在下一次作业启动前定下来；Q-06、Q-07 要等知识出处填完才能判断；Q-12 需要实测数据支撑，不能凭感觉定。

编号	待确认事项	影响范围	当前倾向	决策人
Q-01	智能体平台与模型选型	架构、API 形态、成本	〔待补〕	S1 赖彦然
Q-02	知识库检索方案（切片粒度、向量库、召回策略）	理由生成质量、延迟	〔待补〕	S3 松格拉 / S4 吴佳仪
Q-03	天气服务来源与缓存时长	推荐硬过滤准确性、可用性	〔待补〕	S1 / S5
Q-04	每套搭配必须包含哪些类别，鞋履与连衣裙如何处理	组合规则、推荐结果、接口字段	1.0 版不强制含鞋履，库存不足允许少于 3 套	刘翠华 / 全体评审
Q-05	衣物标签枚举与必填项、Excel 模板格式	前后端契约、导入校验	〔待补〕	S3 松格拉
Q-06	需不需要"三色原则"的明确判定阈值	规则引擎、理由文案	〔待补：色彩构成知识出处〕	S3 / 刘翠华
Q-07	体型规则在用户未填体型时如何降级	规则引擎、验收合规率	〔待补〕	S3 / 刘翠华
Q-08	用户没有实时天气时是否允许继续推荐	推荐可用性	允许，提示"本次未使用实时天气"	全体评审
Q-09	购前相似度比较哪些属性，结果如何表达	购前评估输出文案	品类、颜色、季节、版型、场合；只说"相似"不说"重复"	刘翠华 / 王凯凤
Q-10	推荐和对话历史保留多久，用户如何删除数据	存储成本、隐私合规	保留 1 年，用户可主动删除	全体评审
Q-11	大模型调用成本与频率限制方案	成本、并发	〔待补〕	S1 / S5
Q-12	衣物图像识别是否在后续阶段接入	录入成本、属性准确率	待实测：先在 50 件真实衣物上测通用视觉模型的主色/季节/厚薄准确率，达标才接，且只用于预填标签供用户确认	S3 / S4

---

智能衣橱穿搭 Agent 项目选题论证报告

一、 为什么选择本课题

"衣柜满满、出门不知道穿什么"是大学生和上班族的日常状态，团队那 171 份问卷把它的量级测了出来。而市面上多数衣橱类应用的重心在衣物图像识别和服饰导购带货，缺的是以盘活用户已有衣物为核心的工具。

把这四类现有做法的问题摊开看，就知道我们该往哪个方向做：

现有做法的问题	具体表现	用户的反应
导向导购带货	推荐的是别人的衣服，最终目的是让你下单	31.7% 反感"推荐的是别人的衣服"，19.8% 抵触"偏导购带货"；38.3% 明确说"不想被引导消费"
AI 生成的穿搭不能改	一次性给你一张搭配图或一套方案，用户想调整只能重新生成或者放弃	15.6% 指出"不能根据我当天的想法调整"
不记用户偏好	每一次推荐都是一次性的，用得越久越不懂你	84.4% 认为"记录穿着反馈，越用越懂我"重要
不解释原理	只给结果不给理由，用户无法判断这套搭得好不好，也学不到东西	14.4% 指出"不能解释为什么这样搭"；开放题里"不会搭配（配色/比例/成套）"以 33.6% 排第一

这四条不是我们拍脑袋想的，是问卷第 10 题和第 12 题直接问出来的。它们合起来指向同一件事：穿搭这件事需要一个能对话、能记忆、能讲道理的助手，而不是一个图片识别加商品链接。

本项目核心聚焦穿搭推理 Agent、可解释穿搭推荐、双层偏好机制，对应的正是上表后三条；第一条"不导购"则是产品定位的红线。核心业务逻辑集中在知识工程、大模型 Agent 任务拆解、用户偏好学习。

• 技术可行性：大模型对话能力成熟，使"多轮自然语言调整穿搭"成为可能；天气 API、结构化标签录入等技术门槛低，适合学生团队在课程周期内落地。
• 工作量可控：项目功能划分清晰，区分核心功能与后续拓展功能，开发工作量可控。
• 场景契合度：场景贴近真实日常生活，非常适合作为课程项目落地。

关于图像识别：目前主流的衣橱类应用都会做衣物图像识别，但我们不把它写进 1.0 版的范围。这不是说技术上做不到——通用视觉模型对"这是件什么衣服"的粗分类已经能做得不错。真正的问题是细粒度属性能不能可靠地给出来：主色、季节厚薄、版型、面料、适用场合，这些恰恰是搭配推理要用的字段。品类认错了顶多是标签选错，颜色认错了整套推荐就废了。

所以 1.0 版用下拉标签录入属性，把准确率问题彻底绕开；如果后续阶段实测发现通用视觉模型在具体属性上的准确率能到可用水平，再考虑接入，用它来预填标签、让用户确认，而不是替用户做决定。这个判断的依据写在 SRS 6.5 节的 Q-12 里。

二、 需求是否真实

1. 用户痛点真实：171 份问卷里，45.5% 的人每天在"今天穿什么"上花 1 分钟以上，6.0% 超过 5 分钟或经常反复纠结；50.9% 觉得衣服多却没衣服穿，39.5% 不知道怎么互相搭配，45.5% 觉得"经常穿的就那几件，很多衣服闲置"。社交平台上关于早晨纠结、买了不会搭的讨论量也很大。
2. 现有产品存在短板：衣橱类 App 的使用率只有 6.6%，用户用社交平台内容和天气 App 凑合（65.3% / 49.7%）。他们不满的地方很具体：推荐的是别人的衣服（31.7%）、不能结合体型（31.1%）、偏导购带货（19.8%）、不能按当天想法调整（15.6%）、不能结合场合（15.6%）、不能解释为什么这样搭（14.4%）。
3. 使用场景明确：覆盖上课、通勤、面试、出游等日常真实场景；同时支持网购前新品适配评估。
4. 需求具备持续性：用户穿搭偏好会随季节、场合、心情变化，需要"使用—评价—更新偏好"的循环来持续贴合，而不是一次性推荐。

三、 领域边界

（一）项目核心实现范围（本期做）

1. 标签表单式数字衣橱录入：图片仅用于前端预览，衣物属性依靠下拉标签录入，支持 Excel 批量导入；
2. 场景与天气结合：对接天气 API 获取温度、降雨、天气状况，支持用户输入场合、自然语言提交穿搭需求；
3. Agent 智能推理：基于服装专业客观规则，结合本次临时偏好、长期用户偏好，输出 3 套附带搭配原理的穿搭方案，支持多轮对话调整搭配；
4. 新品购前评估：分析新品与现有衣橱适配程度、相似单品情况；
5. 偏好学习：收集用户穿搭评价，迭代更新用户长期穿搭偏好；
6. 隐私与数据自主：用户能看到、能导出、能删除自己的数据。

软件载体：1.0 版做移动端优先的 Web 应用（手机浏览器直接打开可用），小程序留到后续阶段。

这个决定有点反直觉，解释一下。调研里 37.7% 的人第一选择是微信小程序，29.3% 说"都可以"，只有 1.8% 选了 Web。这里的"Web"指的是 PC 端网页，1.8% 说明大家要的是"掏手机就能用"，不是"坐在电脑前用"。

所以 1.0 版做的是移动端优先的响应式 Web：不做 PC 专属布局，首页就是手机版的天气卡片加穿搭卡片，扫码或点链接即用，体感接近小程序。同时后端 API 按小程序的调用习惯设计（轻量、无状态、鉴权走 token），后续做小程序时前端能直接复用，不用重写后端。

选择 Web 而不是直接做小程序，还有一个现实原因：本课程后面还有三次作业，13 个人要在这条时间线上完成 Agent 骨架、11 个页面、规则引擎、偏好学习和购前评估。移动端 Web 的交付风险明显低于小程序——少一层审核、少一套组件库、多一份"能演示"的确定性。

（二）此次版本不实现（本期不做）

1. 衣物 AI 图像识别解析（图片仅前端预览）；
2. NFC 硬件打卡记录穿搭；
3. 服饰电商导购、商品跳转购买；
4. AI 生成穿搭效果图、人体虚拟试衣；
5. 服装工业 CAD、服装设计生产相关功能；
6. 换季整理与胶囊衣橱盘点、电商订单批量导入衣橱。

注：本文档为智能衣橱穿搭 Agent 课程项目选题论证材料。

附录

文档	内容说明	链接
软件需求规格说明书（SRS）	完整版，含功能、接口、数据、非功能需求与验收标准	https://docs.qq.com/doc/DZHFya3Rkb3diZ1RV
选题报告	为什么选这个课题、需求真实性、领域边界、定制效果对比	https://docs.qq.com/doc/DZG9BWHZEZkN3ZFVy
用户调研报告	171 份问卷的样本构成、九项功能优先级、用户顾虑分析	https://docs.qq.com/doc/DZHBwdExiZGZYdG10
原始问卷数据	问卷星导出的原始数据表	https://docs.qq.com/sheet/DZEJyeUhjckhBaXhM
问卷原始链接	问卷星填写入口，可自行填写	https://v.wjx.cn/vm/tFGCJEw.aspx#

知识库文档包与来源清单、测试题集与测试报告、公网访问地址、演示视频等，在后续阶段随开发进度补充。